---

Object Graphs

Object-oriented applications contain complex webs of interrelated objects. Objects are linked to each other by one object either owning or containing another object or holding a reference to another object to which it sends messages. This web of objects is called an object graph.

Even with very few objects, an application’s object graph becomes very entangled with circular references and multiple links to individual objects. Figure 1 shows an incomplete object graph for a simple Cocoa application. (Many more connections exist than are shown in this figure.) Consider the window’s view hierarchy portion of the object graph. This hierarchy is described by each view containing a list of all of its immediate subviews. However, views also have links to each other to describe the responder chain and the keyboard focus loop. Views also link to other objects in the application for target-action messages, contextual menus, and much more.

There are situations where you may want to convert an object graph, usually just a section of the full object graph in the application, into a form that can be saved to a file or transmitted to another process or machine and then reconstructed. Nib files and property lists are two examples in Mac OS X where object graphs are saved to a file. Nib files are archives that represent the complex relationships within a user interface, such as a window’s view hierarchy. Property lists are serializations that store the simple hierarchical relationship of basic value objects. More details on archives and serializations, and how you can use them, are described in the following sections.

Contents:

Archives
Serializations

Archives

Mac OS X archives store an arbitrarily complex object graph. The archive preserves the identity of every object in the graph and all the relationships it has with all the other objects in the graph. When unarchived, the rebuilt object graph should, with few exceptions, be an exact copy of the original object graph.

Interface Builder uses archives (nib files) to store the objects and relationships that make up a user interface. A Cocoa application loads the nib archive to reconstruct a window, menu, or view that was designed in Interface Builder.

Your application can use an archive as the storage medium of your data model. Instead of designing (and maintaining) a special file format for your data, you can leverage Cocoa’s archiving infrastructure and store the objects directly into an archive. With minimal effort, you can implement Save and Open in your application.

To support archiving, an object must implement the NSCoding protocol, which consists of two methods. One method encodes the object’s important instance variables into the archive and the other decodes and restores the instance variables from the archive.

All of the Foundation value objects (NSString, NSArray, NSNumber, and so on) and most of the Application Kit user interface objects implement NSCoding and can be put into an archive. Each class’s reference document identifies whether they implement NSCoding.

Serializations

Mac OS X serializations store a simple hierarchy of value objects, such as dictionaries, arrays, strings, and binary data. The serialization only preserves the values of the objects and their position in the hierarchy. Multiple references to the same value object might result in multiple objects when deserialized. The mutability of the objects is not maintained.

Property lists are examples of serializations. Application attributes (the Info.plist file) and user preferences are stored as property lists.

Arbitrary objects cannot be serialized. Only instances of NSArray, NSDictionary, NSString, NSDate, NSNumber, and NSData (and some of their subclasses) can be serialized. The contents of array and dictionary objects must also contain only objects of these few classes.

---