Chapter 18 Saving, Loading, and Application State
1. Archiving is one of the most common ways of persisting model objects on iOS. Archiving an object involves recording all of its properties and saving to the filesystem. Unarchiving recreates the object that from the data.
Classes whose instances need to be archived and unarchived must conform to the NSCoding protocol and implement its two required methods, encodeWithCoder: and initWithCoder:
2. Below is how archiverRootObject:toFile: works:
The method begins by creating an instance of NSKeyedArchiver. (NSKeyedArchiver is a concrete subclass of the abstract class NSCoder.)
privateItems is sent the message encodeWithCoder: and is passed the instance of NSKeyedArchiver as an argument.
3. In order to have objects that are not view controllers respond to low memory warning, 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. Objets that want to implement their own low-memory warning handlers can register for this notification.
NSNotificationCenter *notificationCenter = [NSNotificationCenter defaultCenter];
[notificationCenter addObserver:self
selector:@selector(clearCaches:) name:UIApplicationDidReceiveMemoryWarningNotification object:nil];
4. The standard Model-View-Controller design pattern calls for the controller to be bear the burden of saving and loading model objects. However, in practice, this can become overwhelming - the controller is simply too busy handling the interactions between model and view objects to deal with the details of how objects are fetched and saved. Therefore, it is useful to move the logic that deals with where model objects come from and where they are saved to into another type of object: a store.
A store exposes a number of methods that allow a controller object to fetch and save model objects. The details of where these model objects come from or how they get there is led to the store. The store could access a database, talk to a web service, or use some other method to produce the model objects for the controller.