(Just so you know I am learning to develop for iphone, without interfacae builder)
I’m coding my first multi-view app, which has a root viewcontroller and two other viewcontrollers, and the root viewcontroller uses lazy loading, so when viewDidLoad, it creates the first viewcontroller and adds its view to the subview, but doesn’t create the other one until it is needed. But, after the second one has loaded, they both stay there until the application ends (unless it receives a memory warning).
So I’m wondering: when the user switches two the other view, should I unload the other one that’s being removed (by setting it to nil — its a retaining property) ? So everytime the user clicks the button, the current viewcontroller is unloaded (after being removed from the superview) and the next one is loaded and added as a subview?
So is this the right thing to do, or is it right, but only when the application has many views and mine isn’t complicated enough to justify doing this, or is it bad to do it at all and I should just let didReceiveMemoryWarning take care of it (In didReceiveMemoryWarning I set the viewcontroller that isn’t currently being displayed to nil) ?
The answer really depends. Typically, you should release and set to nil the view that isn’t displaying, but if the user is going to switch between them frequently you may want to keep the hidden view retained ( cached ).
You don’t really want your app to push the user’s phone to didReceiveMemoryWarning. When you get that warning, other things are happening in the phone that may cause your application to freeze for a moment while the iPhone dumps cached Safari pages, cached UIImageView objects, etc… this process can be noticeable to the end user and your application may not feel as smooth as it should.
It is also important to remember that some users may be using first gen iPhones, iPod Touches, and 3Gs so they won’t have the extra memory of the 3GS.
That being said, I err on the side of being conservative with memory so I would release and nullify the view, then re-instantiate it when the user wants to see it. The impact of your alloc’ing the view versus the system’s cleanup due to didReceiveMemoryWarning will typically be much less on your application’s user.