Learn Objective-C on the Mac - Mark Dalrymple [76]
You’ve now made a pretty cool-looking app entirely by defining a model, dragging an entity into Interface Builder, and then adjusting and swapping out some controls in the GUI. This is a great example of the kind of visual programming model that Cocoa has always enabled, and with the addition of Cocoa Bindings and Core Data in the past few years it’s become even more complete. Of course, underlying all this stuff are frameworks and APIs that enable all this “magic” to happen in Xcode and Interface Builder, and there are times when you will want or need to access Core Data functionality from code. The rest of this chapter will introduce you to some aspects of programming (in the traditional, code-based sense) with Core Data.
Exploring the Template Code
When you created the MythBase project, an application delegate class called MythBase_AppDelegate was created for you. This class contains code to load the model information from the Core Data model files contained within your application. It also opens up the on-disk storage where Core Data reads and writes its model objects, or creates this storage if it doesn’t already exist. And finally, it provides access to the data storage via an NSManagedObjectContext, which other objects can in turn bind to (such as the array controller in our nib file) in order to read from and write to storage.
All the code shown here has been reformatted to better fit the format of this book, so your version may look slightly different, but should be syntactically identical.
The App Delegate Interface
Let’s jump right in and take a look at the header file, MythBase_AppDelegate.h, shown in the following listing. This is the autogenerated code created by the version of Xcode available for Snow Leopard. The version created by Leopard’s Xcode may be slightly different, and if you like you can change it to match the version shown here:
As you can see, this declares a simple class with four instance variables, all of them declared as properties. The window variable also features IBOutlet in its property declaration which makes it into an outlet, available for connecting to a window in Interface Builder. The other three variables are instances of some important Core Data classes:■NSManagedObjectModel loads information about entities and their properties from one or more model files (normally contained inside your application bundle), and acts as a sort of metadata repository containing the structure of your application’s managed objects. Many applications will never need to interact with this directly.
■NSPersistentStoreCoordinator manages the back-storage, giving access to one or more instances of NSPersistentStore, which each represent a storage location (in a file, or in memory). The purpose of the coordinator is to let the application access several persistent stores as if they were one. Some applications may want to use this to partition application data across multiple stores. For example, you may want to distinguish between normal entities, whose objects that are saved to disk, and transient entities, whose objects that are only held in memory, and will disappear when the user quits the app. Even though they’re not saved to disk, the transient objects will still benefit from the other features of Core Data (simple undo support, integration with Cocoa Bindings, and the like).
■NSManagedObjectContext is responsible for dealing with the life-cycle of all managed objects (the model objects that we’re storing via Core Data). It accesses the objects themselves through an NSPersistentStoreCoordinator,