Objective-C Fundamentals

Summary
199
addObserver:selector:name:object: provides a lot of flexibility
The addObserver:selector:name:object: message provides a lot of flexibility
when it comes to deciding how notifications are handled by an observer.
Since it’s possible to call addObserver:selector:name:object: multiple times for
the same observer object, with a different name argument each time, it’s possible for
a single object to process more than one type of notification.
Likewise, via use of the selector argument, you can determine if different notification
types are handled by separate methods or lumped together and processed by a
single method.
If you decide a single method can process multiple types of notifications, the NSNotification
object passed into the method has a name property, which can help distinguish
why it is currently invoked.
receive notification events. This can be done by sending a removeObserver:name:
object:, as demonstrated here:
- (void)dealloc {
[[NSNotificationCenter defaultCenter]
removeObserver:self
name:UIApplicationDidReceiveMemoryWarningNotification
object:nil];
}
[address release];
[super dealloc];
It’s important to unregister your observers before your object is deallocated. Otherwise,
when the notification is next generated, the NSNotificationCenter will attempt
to send a message to the nonexistent object and your application may crash.
9.7 Summary
Responsibility for correct memory management in Objective-C rests significantly with
you, the developer. Unlike in garbage-collected environments, which tend to be useand-forget
type environments, the deallocation of objects in Objective-C will occur at
the correct point in time only through the proper use of the retain, release, and
autorelease messages. Make a mistake, and the object will never be deallocated or,
worse yet, it may be deallocated too early and lead to application crashes.
To make things easier, most Objective-C classes strive to stick to a common memory
management pattern, which was discussed in section 9.5. By handling memory
allocation in a consistent manner, you won’t need to constantly refer to documentation
in order to determine who’s responsible for keeping track of a given object.
An autorelease pool enables some of the benefits of a garbage-collected environment
without the implied overhead. An object can be registered to be sent a release
message at some point in the future. This means you don’t use the traditional retain