When the system is running low on RAM, it issues a low memory warning to the running application. The application responds by freeing up any resources that it does not need at the moment and can easily recreate. View controllers, during a low memory warning, are sent the message didReceiveMemoryWarning.
Objects other than view controllers may have data that they are not using and can recreate later. The BNRImageStore is such an object – when a low-memory warning occurs, it can release its ownership of the images by emptying its dictionary. Then if another object ever asks for a specific image again, that image can be loaded into memory from the filesystem.
In order to have objects that are not view controllers respond to low memory warnings, you must use the notification center. Every application has an instance of NSNotificationCenter, which works like a smart bulletin board. An object can register as an observer (“Send me ‘lost dog’ notifications”). When another object posts a notification (“I lost my dog”), the notification center forwards the notification to the registered observers.
Whenever a low-memory warning occurs, UIApplicationDidReceiveMemoryWarningNotification is posted to the notification center. Objects that want to implement their own low-memory warning handlers can register for this notification.
In BNRImageStore.m, edit the initPrivate method to register the image store as an observer of this notification.
- (instancetype)initPrivate
{
self = [super init];
if (self) {
_dictionary = [[NSMutableDictionary alloc] init];
NSNotificationCenter *nc = [NSNotificationCenter defaultCenter];
[nc addObserver:self
selector:@selector(clearCache:)
name:UIApplicationDidReceiveMemoryWarningNotification
object:nil];
}
return self;
}
Now your image store is registered as an observer with the notification center (Figure 18.8).
Now, when a low-memory warning is posted, the notification center will send the message clearCache: to the BNRImageStore instance (Figure 18.9).
In BNRImageStore.m, implement clearCache: to remove all the instances of UIImage from the BNRImageStore’s dictionary.
- (void)clearCache:(NSNotification *)note
{
NSLog(@"flushing %d images out of the cache", [self.dictionary count]);
[self.dictionary removeAllObjects];
}
Removing an object from a dictionary relinquishes ownership of the object, so flushing the cache causes all of the images to lose an owner. Images that are not being used by other objects are destroyed, and when they are needed again, they will be reloaded from the filesystem. If an image is currently displayed in the BNRDetailViewController’s imageView, then it will not be destroyed since it is owned by the imageView. When the BNRDetailViewController’s imageView loses ownership of that image (either because the BNRDetailViewController was popped off the stack or a new image was chosen), then it is destroyed. It will be reloaded later if needed.
Build and run the app in the simulator. Create or load in some images. Then select Simulate Memory Warning in the Hardware menu. You should see a log statement indicating that the cache has been flushed out.
Notifications are another form of callbacks, like delegation and target-action pairs. However, unlike delegation and target-action pairs, which require that the object responsible for an event send a message directly to its delegate or targets, notifications use a middle-man: the NSNotificationCenter.
Notifications in Objective-C are represented by instances of NSNotification. Each NSNotification has a name (used by the notification center to find observers), an object (the object that is responsible for posting the notification), and an optional user info dictionary that contains additional information that the poster wants observers to know about. For example, if for some reason the status bar’s frame changes, UIApplication posts a UIApplicationDidChangeStatusBarFrameNotification with a user info dictionary. In the dictionary is the new frame of the status bar. If you received the notification, you could get the frame like this:
- (void)statusBarMovedOrResized:(NSNotification *)note
{
NSDictionary *userInfo = [note userInfo];
NSValue *wrappedRect = userInfo[UIApplicationStatusBarFrameUserInfoKey];
CGRect newFrame = [wrappedRect CGRectValue];
...use frame here...
}
Notice that the CGRect had to be wrapped in an NSValue because only objects can go into dictionaries.
How can you know what is in the userInfo dictionary? Each notification is documented in the class reference. Most say “This notification does not contain a userInfo dictionary.” For notifications with userInfo dictionaries, all the keys and what they map to will be listed.
The last argument of addObserver:selector:name:object: is typically nil – which means, no matter what object posted a “Fire!” notification, the observer will get sent its message. You can specify a pointer to an object for this argument and the observer will only get notified if that object posts the notification it has registered for, while ignoring any other object that posts the same notification.
One purpose of the notification center is to allow multiple objects to register a callback for the same event. Any number of objects can register as an observer for the same notification name. When the notification occurs, all of those objects are sent the message they registered with (in no particular order). Thus, notifications are a good solution when more than one object is interested in an event. For example, many objects might want to know about a rotation event, so Apple used notifications for that.
One final point: the NSNotificationCenter has nothing to do with inter-app communication, push notifications, or local notifications. It is simply for communication between objects in a single application.