Allocating UIViewControllers in viewDidLoad. Was this a mistake?

A colleague and I have been designing our code so that our view controller objects are being allocated within the viewDidLoad method of our controller objects. We did this a lot and the object graph seemed to come out just fine. After a while we found the need to add another layer above our current view controller hierarchy that would own, allocate, and release our previous parent view controller.

This got me thinking about low memory warnings and view did load. Before, our views were always visible and thus wouldn't be released if a low memory warning occurred, but now there is a chance of that happening. If it does, it seems like when the views are reloaded, they will allocated new memory for new view controllers.

Will this cause widespread memory leaks? Or will the fact that we used retained declared properties save us, since the old controllers will b开发者_运维技巧e released automatically? Are there styles or conventions I should consider? Thanks for the help!

---

If you do create your view controllers in viewDidLoad, you should release them in viewDidUnload. True for pretty much any object, not just view controllers.

But I would not be surprised if you say "Wut!?" If your view controllers need to keep their state through memory warnings, then you don't want to release them. But it will be no better if you replace them with new ones that have fresh state.

It probably doesn't make sense to create view controllers in viewDidLoad. Create them in initWithNibName:bundle: (and release them in dealloc). The design pattern is that view controllers stay around, their views can come and go. If your subordinate view controllers have anything memory-intensive, release just that object in their viewDidUnload. Then on a memory warning, you will still free up a lot of memory, but all your view controllers will stay around in a low-memory usage state, retaining only a few flags, lists of indexes, etc., that they will need to restore their views when requested.

---

If you are explicitly releasing each view controller that is not needed any more you will not cause any memory leaks. Usually when you present a view controller the object that is doing the presenting will retain the controller for you, so you can release it if you don't need access to it anymore. But if you are using a UINavigationController and you are pushing new view controller's then you should be implementing the viewDidUnload method. This is straight from Apple's documentation:

After it is loaded into memory, a view controller’s view remains in memory until a low-memory condition occurs or the view controller itself is deallocated. In the case of a low-memory condition, the default UIViewController behavior is to release the view object stored in the view property if that view is not currently being used. However, if your custom view controller class stores outlets or pointers to any views in the view hierarchy, you must also release those references when the top-level view object is released. Failure to do so prevents those objects from being removed from memory right away and could potentially cause memory leaks later if you subsequently overwrite any pointers to them.

There are two places where your view controller should always clean up any references to view objects:

The dealloc method The viewDidUnload method If you use a declared property to store a reference to your view, and that property uses retain semantics, assigning a nil value to it is enough to release the view. Properties are by far the preferred way to manage your view objects because of their convenience. If you do not use properties, you must send a release message to any view that you explicitly retained before setting the corresponding pointer value to nil