views:

614

answers:

2

In a multi-view application, do you think its better to let views automatically get unloaded in memory tight situations, or to actually only ever have one View Controller allocated at a time, and when you switch views, the new one is created, the old one removed, the new one adde d and the old one released. Deallocating every time also means that there is a slight delay when switching to a new tab (very slight). So What do you think?

Also, I'm a bit confused about how and when and where and by who views are released (through viewDidUnload) automatically. If someone could clarify that for me, thanks.

A: 

Depends, if you have a bunch of Views that the user switch back on forth from often then I would say to keep those in memory at that time, if theres views where the user wont come back to for awhile then you can probably unload that viewController and save memory. However if you have views that are taking up a ton of memory each then it might be wise to unload the viewcontroller when its not in use. Its really a matter of how often you are going back to the views and how much memory the view takes, also how many views you have. Taking these things into consideration you should be able to make a good decision of when to keep the viewControllers around and when the unload them. I believe that the view is a round as long as the ViewController is around (unless u release it explictly, which might have bad side effects (dont know)) , viewdidUnload just tells you that the view was unloaded of the screen, not too sure on that point tho.

Daniel
What if you have no clue how often the user will switch between them?
Mk12
You should have some idea of how often a user will be on a screen for example the u ser will probably be in the main menu screen of your app a whole lot more than the settings screen. Anyway, you have to decide whats best for you.
Daniel
+1  A: 

In general, don't unload views unless you have to (didReceiveMemoryWarning) or it makes sense (something like a login form that's unlikely going to be used again).

You can't really assume that you have a fixed amount of memory. iPhone's have less memory than iPod touches. iPhone 3GS's have more memory than either. Jail-broken handsets often have substantially less memory.

By only releasing views when you have to you're making your app run faster on the 3GS and allowing it to run when there's less memory available.

The didReceiveMemoryWarning method releases the view if it is not visible. The following is from the documentation (v3.x):

The default implementation of this method checks to see if the view controller can safely release its view. This is possible if the view itself does not have a superview and can be reloaded either from a nib file or using a custom loadView method. If the view can be released, this method releases it and calls the viewDidUnload method.

Obviously you also need to release any cached data. SDK2.x does not have the viewDidUnload method.

Stephen Darlington
Does didReceiveMemoryWarning automatically deallocate the view if its not visisble?
Mk12
I edited the question to clarify.
Stephen Darlington
So didReceiveMemoryWarning is to free up memory, and viewDidUnload is the place to release all other things associated with your view when the view gets released, which could happen in didReceiveMemory warning if it can safely release the view (which triggers viewDidUnload), correct? Also, if my root View Controller gets a memory warning, does it pass it on too all the other View Controllers? Or do all View Controllers in an App get the memory warning at the same time?
Mk12