So it's been a couple of weeks since my last post, I thought I'd bring you up to speed on the latest iphone app's status. I submitted it to the app store almost 2 weeks ago, and it's STILL in review. Apple has changed the status from waiting for review to in review, but as of now, it is still in review (6 days now) and has not been approved for sale in the app store.
I'll post again when the app goes live.
Friday, November 27, 2009
Saturday, November 14, 2009
The app is ready, now, the website....
Ok, as you know, I'm building yet another "top secret" application for the iPhone to be deployed in the Apple App Store. Of course, this won't be top secret for much longer. I hope to get it submitted to the app store this weekend. I've decided to take a much more interactive marketing strategy this time, one I didn't take with the bracket manager. First, I've actually thought about the sales copy and website design before submission. The web design isn't the best, but certainly isn't the worst either. I'm using some CSS to format it better, and putting pictures throughout the site rather than all in a row like my first apps pages. I will be going back and retrofitting the other sites as well, but that can wait a few weeks until I get new releases ready for the app store. I'll post again when the current app has been submitted to the iPhone App Store. Hopefully that will be sometime this weekend!
Monday, November 9, 2009
The next app is close
I'm getting really close to submitting my next iPhone app to the App Store. How close? Well, let's just say I'm now working on documentation and a website more than the app itself. I did a quick look through the store, and only found two apps doing something close to what I'm doing. One is $.99 and does very little compared to mine, and the other is quite expensive and does about what mine does, but with a prettier interface. I figure marketing at a reasonable price should make mine sell quite well.
So, given it's so close to going out, I figure now is the time to really go over some lessons learned in this app, some technical, others more project management.
First, technical lessons learned.
It's Really Bad to Return alloc'd Objects
This sounds like a no brainer, but, if you need to return an object, make sure you didn't alloc the memory for it yourself. These objects are easy to leak, and if you try to clean them up yourself, you can end up releasing objects not retained anywhere, resulting in a crash.
Instead, if you return objects (Like a list for example) instead of using "alloc" to create it, use other options. Instead of:
use this:
The resulting object is safe to pass from method to method, and you don't have to worry about cleaning them up.
The Analyze tool is your friend
The build menu has a "build and analyze" option. At first, I thought this was nice, although not very handy. I was wrong. This is probably the most useful tool in XCode's build menu. Using this, before fixing my methods, I saw 30 or 40 potential issues. I ignored them, because upon looking at them, I was releasing the objects later in the code (again, BAD idea). Using this feature, I fixed all those pesky memory leaks in one swoop, in about 30 minutes, instead of hours it would have taken to run leaks to find the leaks in the first place.
Instance variables need to be referenced with "self"
This is another one of those "duh" moments. In Java, you have the "this" keyword, which references an instance variable. It's not required in Java, but can make your code easier to read, especially in areas where you're assigning an instance variable from a local variable, or visa versa, like in this method:
It's far clearer to use this instead:
and later try to use that array like:
you'll crash, or at least I did.
instead, both those examples should use the self keyword, like...
or
Now, the Project Management lessons learned:
Watch Out for Creep
No, I don't mean that crazy guy down the street who...
I mean scope creep. We all know what scope creep is, but in small projects, in a platform so easy to code in, it's really easy to expand beyond what you were thinking. My original thought was a small app, perhaps two or three views, and within a couple of days, that had exploded to five or six screens and a lot more functionality. Today, as I get ready to release, it's over 15 views, and does a lot more than I wanted originally. Will it make it sell better? Probably. Was it worth the extra time? Don't know, but I'd guess probably not. The only way to know that for sure, would be to go back and build my original idea, and put it out at the same time. But, given that my original time frame was three weeks to get it onto the store, and it's been about six weeks already, with probably another two before going live, I overspent on my time. Had I thought about what I wanted to do a little more, this might have not happened. I may have planned to make this much larger from the start, and I could have budgeted more time (since this is a side project, money is only opportunity lost rather than real dollars).
Find Help if You Need it
As I just stated, this app turned out to be much larger than expected. A little planning on my part, and I might have found some friends to help me bang out some code early on, making this happen quicker. The downside to that, is I would have had to either pay them, or share my profits. Of course, if the first app is any indication, there probably won't be a lot of profit in this one, but my luck, I'd give someone 1/2 my profits on a real winner of an app.
This was really just some of my findings and lessons learned in this project. I'll post about this app again once I get it into the approval process in a couple of days, and again when it goes live. I'll say what it is at that point (I don't want to give anyone a chance at catching up to me ;) )
So, given it's so close to going out, I figure now is the time to really go over some lessons learned in this app, some technical, others more project management.
First, technical lessons learned.
It's Really Bad to Return alloc'd Objects
This sounds like a no brainer, but, if you need to return an object, make sure you didn't alloc the memory for it yourself. These objects are easy to leak, and if you try to clean them up yourself, you can end up releasing objects not retained anywhere, resulting in a crash.
Instead, if you return objects (Like a list for example) instead of using "alloc" to create it, use other options. Instead of:
NSArray *array = [[NSArray alloc] init...]; //bad idea
use this:
NSArray *array = [[NSArray array] init...]; //bad idea
The resulting object is safe to pass from method to method, and you don't have to worry about cleaning them up.
The Analyze tool is your friend
The build menu has a "build and analyze" option. At first, I thought this was nice, although not very handy. I was wrong. This is probably the most useful tool in XCode's build menu. Using this, before fixing my methods, I saw 30 or 40 potential issues. I ignored them, because upon looking at them, I was releasing the objects later in the code (again, BAD idea). Using this feature, I fixed all those pesky memory leaks in one swoop, in about 30 minutes, instead of hours it would have taken to run leaks to find the leaks in the first place.
Instance variables need to be referenced with "self"
This is another one of those "duh" moments. In Java, you have the "this" keyword, which references an instance variable. It's not required in Java, but can make your code easier to read, especially in areas where you're assigning an instance variable from a local variable, or visa versa, like in this method:
String str; //instance variable
public void setStr(String str){
str = str; // which "str" are you setting?
}
It's far clearer to use this instead:
String str; //instance variable
public void setStr(String str){
this.str = str;
}
@synthesize array;
array = [[NSArray alloc]... //retain count not incremented.
and later try to use that array like:
[array objectAtIndex:...];
you'll crash, or at least I did.
instead, both those examples should use the self keyword, like...
@synthesize array;
self.array = [[NSArray alloc]...];
...
[self.array objectAtIndex:...];
or
@synthesize array;
[self setArray:[[NSArray alloc]...]];
...
[[self array] objectAtIndex:...];
Now, the Project Management lessons learned:
Watch Out for Creep
No, I don't mean that crazy guy down the street who...
I mean scope creep. We all know what scope creep is, but in small projects, in a platform so easy to code in, it's really easy to expand beyond what you were thinking. My original thought was a small app, perhaps two or three views, and within a couple of days, that had exploded to five or six screens and a lot more functionality. Today, as I get ready to release, it's over 15 views, and does a lot more than I wanted originally. Will it make it sell better? Probably. Was it worth the extra time? Don't know, but I'd guess probably not. The only way to know that for sure, would be to go back and build my original idea, and put it out at the same time. But, given that my original time frame was three weeks to get it onto the store, and it's been about six weeks already, with probably another two before going live, I overspent on my time. Had I thought about what I wanted to do a little more, this might have not happened. I may have planned to make this much larger from the start, and I could have budgeted more time (since this is a side project, money is only opportunity lost rather than real dollars).
Find Help if You Need it
As I just stated, this app turned out to be much larger than expected. A little planning on my part, and I might have found some friends to help me bang out some code early on, making this happen quicker. The downside to that, is I would have had to either pay them, or share my profits. Of course, if the first app is any indication, there probably won't be a lot of profit in this one, but my luck, I'd give someone 1/2 my profits on a real winner of an app.
This was really just some of my findings and lessons learned in this project. I'll post about this app again once I get it into the approval process in a couple of days, and again when it goes live. I'll say what it is at that point (I don't want to give anyone a chance at catching up to me ;) )
Saturday, November 7, 2009
A quick thought on memory management
So, the iPhone, with as great of a platform as it is for developers, isn't without its flaws. As I've mentioned before, my "day" job, is software development, with about 99.99999% of that, in Java. I won't go into why Java is better than Objective-C, because quite honestly, I think both are exceptional object oriented languages. One thing Java has, however, that Objective-C (well, on the iPhone anyways) does not, is garbage collection. For those who aren't programmers, garbage collection is a memory management system, where objects that are no longer used automatically release the memory they're holding onto. While garbage collection doesn't guarantee you will never have a memory leak, it certainly goes a long way into ensuring you don't have them. Apple, in their infinite wisdom, decided on the iPhone to not have garbage collection. The reasons for this were sited as it takes too much processing, it slows things down and is heavy. All of which, I firmly believe to be correct.
Because of this, I suspect many apps on the app store have not been properly profiled, or written by their developers, perhaps causing some unnecessary headaches for users.
Here are just some quick ways developers can prevent leaks in their code.
1) Any time you create a new object (retain, copy, or alloc), release it. Best practice is to release it in the same method that created it, otherwise you risk releasing an object that is no longer referenced (VERY bad idea)
2) Make sure your dealloc method contains a release for every property in the header file.
3) Use Build => Build and Analyze to determine if you have any potential memory leaks as you code. If it finds any issues, they're probably legitimate issues that should be addressed.
Because of this, I suspect many apps on the app store have not been properly profiled, or written by their developers, perhaps causing some unnecessary headaches for users.
Here are just some quick ways developers can prevent leaks in their code.
1) Any time you create a new object (retain, copy, or alloc), release it. Best practice is to release it in the same method that created it, otherwise you risk releasing an object that is no longer referenced (VERY bad idea)
2) Make sure your dealloc method contains a release for every property in the header file.
3) Use Build => Build and Analyze to determine if you have any potential memory leaks as you code. If it finds any issues, they're probably legitimate issues that should be addressed.
Subscribe to:
Posts (Atom)
