Scratch Pad

Predicting user behavior on the iPhone is difficult. One can never know how many pages of Safari someone might have in the background hogging up valuable resources. Every now and then, I get reports of our application crashing for no apparent reason. More often than not, it’s caused by the phone running low on memory. It’s amazing how little memory we have to work with on the iPhone. With Safari taking up 8 pages in the background, our application was crashing at mere 8 MB of memory usage.

Load Late and Lazily

Sometimes you have to sacrifice the snappy UI for a low memory footprint. It’s better than your application crashing. This means never preloading resources but waiting until the moment you need it. If your XIB (NIB) file has a lot of views, try separating them into multiple NIB files so that you can load it individually when you need it. When a view is not visible, the system will free it from memory.

- (void) didReceiveMemoryWarning

The didReceiveMemoryWarning message will be called when the iPhone is running load on memory. It is highly recommended that you override this message in all your view controllers and print out a simple debug message in it. Also, do not forget to call [super didReceiveMemoryWarning].

- (void) setView:(UIView*) view

If you receive the didReceiveMemoryWarning message, the setView message will be called with a nil parameter. It will be called to release the view if the view is not the active view. This is where you will want to release as much resources as you can, such as all your IBOutlet variables. Also, do not forget to call [super setView:view] or your application will crash.

Initialization

Once your view is freed, the NIB will be read back into memory when it is needed. This means the viewDidLoad message will be called again. So take care not to place initialization code that should only be initialized once per application in that message.

CLANG Analyzer

If you haven’t tried this tool already, then you are truly missing out. Check out this extremely helpful post by Jeff Lamarche, the author of Beginning iPhone Development. CLANG will analyze your code and give you a detailed report of problems your code may have, including memory leaks.

Also, If you’ve missed my previous post about the dangers of UIImage, you can check it out here.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Development, Objective-C, iPhone Development didReceiveMemoryWarning, iPhone memory leak, Low Memory, safari, setView

Why is it that it always takes longer than what you expected? I stayed up way past my bed time last night trying to get iHappyBirthday 1.1 out the door.

We will also be doing a photoshoot of someone actually using the application as well as uploading a video to Youtube in the near future.

Version 1.1 delivers more features:

• More full cakes (chocolate and a vanilla cake).
• Randomized candle blow-outs.
• New finale animation. You can choose from different finale animations.
• Some bug fixes.

We’ll post a link to screen shots and the video once we have them.

For any users who experience random crashes with iHappyBirthday, please be rest assured that it is not a problem with the application. It is because the iPhone is running low on memory. For some reason, the iPhone does not seem to be too good at releasing memory when misbehaving applications are terminated. Also, you may have applications running in the background (mail, Safari, etc) that are taking up memory. We’ve added a warning message when the memory is running low so that you can take appropriate course of action. It usually suffices to turn the phone off and on to free up the memory. Or you can even download applications from the App store that will let you free memory as well.

Also, my partner will be posting our sales figure. We thought about keeping it private, but it is our belief that knowledge should be shared!

So keep your eyes peeled!

If you enjoyed this post, make sure you subscribe to my RSS feed!

News and Updates Happy Birthday, iHappyBirthday 1.1, Low Memory, Sales Figure, Update