When should I release objects in -(void)viewDidUnload rather than in -dealloc?

Question

I wonder what the -(void)viewDidUnload is good for. Could I not just relase everything in -dealloc? If view did unload, wouldn't -dealloc be called anyways?

Answer 1

As the documentation says:

It is called during low-memory conditions when the view controller needs to release its view and any objects associated with that view to free up memory.

In the same situation dealloc is not called. This method is only available in OS3 and above. Dealing with the same situation in iPhone OS 2.x was a real pain!

Answer 2

You can release any subviews you hold on to, for example that UIImageView you retained in your loadView method, or better yet the image that was on that UIImageView.

Answer 3

Remember that viewDidUnload is a method in the view controller, not in the view. The view's dealloc method will get called when the view unloads, but the view controller's dealloc method may not be called until later.

If you get a low memory warning and your view isn't showing, which will happen for instance about any time you use a UIImagePickerController to let the user take a picture, your view will get unloaded and will need to get reloaded after that.

Answer 4

In addition to what has already been indicated, I wanted to elaborate more about logic behind -viewdDidUnload.

One of the most important reasons for implementing it is that UIViewController subclasses commonly also contain owning references to various subviews in the view hierarchy. These properties could have been set through IBOutlets when loading from a nib, or programmatically inside -loadView, for instance.

The additional ownership of subviews by the UIViewController means that even when its view is removed from the view hierarchy and released to save memory, through which the subviews are also released by the view, they will not actually be deallocated because the UIViewController itself still contains its own outstanding retaining references to those objects as well. Releasing the UIViewController's additional ownership of these objects ensures they will be deallocated as well to free memory.

The objects that you release here are usually recreated and set again when the UIViewController's view is re-loaded, either from a Nib or through an implementation of -loadView.

Also note that the UIViewController's view property is nil by the time this method is called.

Answer 5

Conclusion:

View Controllers have a view property. Typically a nib or piece of code adds other views to this view. This happens often inside a -viewDidLoad method, like this:

- (void)viewDidLoad {
    [super viewDidLoad];
    [self createManyViewsAndAddThemToSelfDotView];
}

in addition, a nib file may create a button and append it to the view controller's view.

On iPhone OS 2.2, when -didReceiveMemoryWarning was invoked from the system, you had to release something to free up memory. You could release the whole view controller's view if that made sense. Or just big memory-consuming contents in it.

- (void)didReceiveMemoryWarning {
    [super didReceiveMemoryWarning]; // Releases the view if it doesn't have a superview
    // Release anything that's not essential, such as cached data
}

Now, in the new OS 3.0, there is an -viewDidUnload method, which will be invoked from the system when the view has been unloaded because of low memory (please correct me: when exactly does this get called?)

-viewDidUnload is used to release all objects that were owned both by the view controller itself and the view. The reason: If a view controller holds references to childs of the view, i.e. a button, the referenced child views will not get released, because their retain count is >= 1. After they are released in -viewDidUnload, they can get freed up from memory.

Answer 6

Why we should not do releases of objects and do only self.property = nil in a ViewDidUnload method?

Answer 7

This is because you will typically set the @property as "(nonatomic, retain)" and as such the setter that is created for you releases the current object and then retains the argument i.e.

self.property = nil;

...does something along the lines of:

[property release]; property = [nil retain];

Therefore you are killing two birds with one stone: memory management (releasing the existing object) and assigning the pointer to nil (since sending any message to a nil pointer will return nil).

Hope that helps.

Answer 8

What happens to the viewDidUnload method once the view controller´s dealloc method is called?

For example: When a view controller is popped from a navigation controller stack, the dealloc is called. Should I set all the views created in loadView to nil there too?

My guess is that the viewDidUnload is no good when dealloc is called, right?

Answer 9

If the view controller is popped from the navigation controller stack and is not retained anywhere else, it will be deallocated, and dealloc will be called instead of viewDidUnload. You should release the views created in loadView in dealloc, but it is not necessary to set the variables to nil, because soon after dealloc is called the variables will no longer exist.