didReceiveMemoryWarning

didReceiveMemoryWarning

practices

As you said, the controller's default implementation of

didReceiveMemoryWarning

releases its
view if it is 'safe to do so'. While it's not clear from Apple's documents what 'safe to do so' means, it is generally recognized as it has no superview (thus there is no way that the view is currently visible), and its

loadView

method
can rebuild the entire view without problems.

The best practice when you override

didReceiveMemoryWarning

is, not to try releasing any view
objects at all. Just release your custom data, if it is no longer necessary. Regarding views, just let the superclass's implementation deal with them.

Sometimes, however, the necessity of the data may depend on the state of your view. In most cases, those custom data is set in

viewDidLoad

method.
In these cases, 'safe to release custom data' means that you know that

loadView

and

viewDidLoad

will
be invoked before the view controller uses the custom data again.

Therefore, in your

didReceiveMemoryWarning

, call the superclass implementation first, and if
its view is unloaded, then release the custom data because you know that

loadView

and

viewDidLoad

will
be invoked again for sure. For example,

-(void)didReceiveMemoryWarning {
/* This is the view controller's method */
[super didReceiveMemoryWarning];
if(![self isViewLoaded]){
/* release your custom data which will be rebuilt in loadView or viewDidLoad */
}
}

Be careful not to use

self.view == nil

, because

self.view

assumes
that the view is needed for someone and will immediately load the view again.

viewDidUnload

method

viewDidUnload

is called when the
view controller unloaded the view due to a memory warning. For example, if you remove
the view from the superview and set the

view

property of the controller to

nil

,

viewDidUnload

method
will not be invoked. A subtle point is that even if the view of a view controller is already
released and set to nil by the time the controller receives

didReceiveMemoryWarning

, so actually
there is no view to unload for the controller,

viewDidUnload

will be invoked if you call the
superclass's implementation of

didReceiveMemoryWarning

.

That's why it's not a good practice to manually set the

view

property of a view controller to
nil. If you do, you may better send a

viewDidUnload

message as well. I guess your understanding
of

viewDidUnload

is more desirable, but apparently it's not the current behavior.

Popping view controllers

If you mean 'removing from the superview' by 'popping', it does decrease the retain count of the view, but not necessarily deallocate it.

If you mean popping out from a UINavigationController, it actually decrease the retain count of the view controller itself. If the view controller is not retained by another object, it will be deallocated, desirably with its view. As I explained,

viewDidUnload

will not be
invoked this time.

Others...

Technically, the retain count may not go down to zero. The object is more likely to be just deallocated without setting the count to zero beforehand.

Just to make sure, the view controller itself is normally not deallocated by default behaviors due to the memory warning.