Chapter saving, Loading, and application state

Chapter 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 is from the data.

Classes whose instances need to being archived and unarchived must conform to the Nscoding protocol and implement its-req Uired 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 was passed the instance of Nskeyedarchiver as an argument.

3. In order to has objects that is not view controllers respond to low memory warning, you must use the notification cen ter. 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 Regis tered observers. Whenever a low-memory warning occurs, Uiapplicationdidreceivememorywarningnotification is posted to the notification cent Er. 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 controllers is simply too busy handling the interactions between M Odel and view objects to deal with the details about how objects is fetched and saved. Therefore, it's useful to move the logic of deals with where model objects come from and where they be saved to into a nother 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 are 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 CO Ntroller.

Chapter saving, Loading, and application state