dealloc
Deallocates the memory occupied by the receiver.
Discussion
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.
didReceiveMemoryWarning
Sent to the view controller when the application receives a memory warning.
Discussion
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.
viewDidUnload
Called when the controller’s view is released from memory.
Discussion
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
.