bunnyhero dev

I recently learned another important newbie lesson about viewDidLoad: : it may be called multiple times during your application’s lifetime for any given UIViewController if its view is ever hidden and shown during low-memory situations.

Here’s the story: I am currently making a monkey app which features a single monkey. It was running fine in the simulator, but sometimes when I ran it on the device, an extra monkey was spawned every time I switched between the main view and the settings view! A couple of view switches and I’d have a bunch of monkeys onscreen, which was amusing but also very slow and not what was intended. Who was making the new monkeys?

My first iPhone test apps did a lot of initialization in viewDidLoad:. It makes sense because it is called right after a view has finished loading from its nib, and it feels like a good time to do your final initialization of things since the system has basically done everything it needs to do to display a window.

What I forgot was that the default behaviour of UIViewController didReceiveMemoryWarning is to release its view if it’s currently hidden (due to navigation, say). All well and good. But when the view becomes visible again, the view will be reloaded from its nib, and viewDidLoad: will be called again.

This is why I kept getting new monkeys: I was making the monkey in my MainViewController‘s viewDidLoad:. When I switched to the settings view when memory was short, the MainViewController purged its view. Switching back to the main view caused the MainViewController to reload the view from the nib, thus calling viewDidLoad: again, and thus creating another monkey.

So, any initialization code that goes into viewDidLoad: should make sense in that situation: i.e. view-specific stuff when recreating the UIView object, not application-level initialization stuff. Or, if your app-level initialization stuff needs a view to be loaded before running, then at least check to make sure that it hasn’t run already.

It’s been a long time since I messed around with Objective-C, even a little bit.

A couple of things that have bitten me lately:

• @selector(apply:) is different than @selector(apply)! Note the lack of a colon in the second one. The colon means that there is one parameter to be passed with the message. No colon, no parameter. This makes a big difference when passing a selector as an argument to something like NSArray makeObjectsPerformSelector:.
• I keep forgetting to pass nil as the terminating argument to methods like NSArray initWithObjects:. Forgetting the terminating nil will cause the iPhone to crash with a Bad Access exception as it runs off the end of the stack into the weeds.

And one very valuable debugging tip I found here:
how to find out what exception was thrown in the Xcode debugger. When an uncaught exception kills your iPhone app, Xcode doesn’t really have much information at that point. To remedy that, go to Run -> Show -> Breakpoints and in the Breakpoints window double-click on the entry that says “Double-Click for Symbol.” Enter “objc_exception_throw” and press Return. Now, when you run your app in the debugger, any exception will stop there and let you see the exception type.