Deallocates the memory occupied by the receiver.

- (void)dealloc

Subsequent messages to the receiver may generate an error indicating that a message was sent to a deallocated object (provided the deallocated memory hasn’t been reused yet).

You never send a dealloc message directly. Instead, an object’s dealloc method is invoked indirectly through therelease NSObject protocol method (if the release message results in the receiver's retain count becoming 0). SeeMemory Management Programming Guide for more details on the use of these methods.

Subclasses must implement their own versions of dealloc to allow the release of any additional memory consumed by the object—such as dynamically allocated storage for data or object instance variables owned by the deallocated object. After performing the class-specific deallocation, the subclass method should incorporate superclass versions of dealloc through a message to super:

- (void)dealloc {
    [companion release];
    NSZoneFree(private, [self zone])
    [super dealloc];

Important: Note that when an application terminates, objects may not be sent a dealloc message since the process’s memory is automatically cleared on exit—it is more efficient simply to allow the operating system to clean up resources than to invoke all the memory management methods. For this and other reasons, you should not manage scarce resources in dealloc—see Object Ownership and Disposal in Memory Management Programming Guide for more details.





Sent to the view controller when the application receives a memory warning.

- (void)didReceiveMemoryWarning

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 customloadView method. If the view can be released, this method releases it and calls the viewDidUnload method.

You can override this method (as needed) to release any additional memory used by your view controller. If you do, be sure to call the super implementation at some point to allow the view controller to release its view. In iOS 3.0 and later, if your view controller holds references to objects in the view hierarchy, you should release those references in the viewDidUnload method instead. In earlier versions of iOS, you should continue to release them from this method. See the discussion in the viewDidUnload method for information about how to safely release outlets and other objects.





Called when the controller’s view is released from memory.

- (void)viewDidUnload

This method is called as a counterpart to the viewDidLoad method. 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. Because view controllers often store references to views and other view-related objects, you should use this method to relinquish ownership in those objects so that the memory for them can be reclaimed. You should do this only for objects that you can easily recreate later, either in your viewDidLoad method or from other parts of your application. You should not use this method to release user data or any other information that cannot be easily recreated.

Typically, a view controller stores references to objects using an outlet, which is a variable or property that includes the IBOutlet keyword and is configured using Interface Builder. A view controller may also store pointers to objects that it creates programmatically, such as in the viewDidLoad method. The preferred way to relinquish ownership of any object (including those in outlets) is to use the corresponding accessor method to set the value of the object tonil. However, if you do not have an accessor method for a given object, you may have to release the object explicitly. For more information about memory management practices, see Memory Management Programming Guide.

By the time this method is called, the view property is nil.

Special Considerations

If your view controller stores references to views and other custom objects, it is also responsible for relinquishing ownership of those objects safely in its dealloc method. If you implement this method but are building your application for iOS 2.x, your dealloc method should release each object but should also set the reference to that object to nil before calling super.