Dynamic Parameters - Core Data - page 176

In this example, that is exactly what we are going to do. As we discussed
briefly in Chapter 8, OS X: Bindings, KVC, and KVO , on page 137 , every object
responds to the -valueForUndefinedKey: and -setValue:forUndefinedKey: methods. We
can use (or abuse) these methods and make them do all of the heavy lifting
for us.

10.1 Building the Xcode Example Project

To start this project, we'll use the Core Data Document-based Application
template from within Xcode. In a document-based application, each document
object has its own Core Data stack, as opposed to a single Core Data stack
for the entire application.

Once we have created the project, named CDPreferences, we need to create
the data model. For this example, we are going to focus only on the parameters
and build the parameters table shown in Figure 41, Parameter table model ,
on page 181 . Each parameter has two properties: a name that is a nonoptional
string and a value that is an optional string. By making the value optional,
we can have parameters that are nullable.

Figure 41—Parameter table model

With no additional code changes, our application will correctly start up and
display an empty document. Since each document has its own persistent
store, the persistent store becomes the document that is being saved to disk.
The next step is to build the object that will manage the parameters.

10.2 The DocumentPreferences Object

To build a system that imitates the NSUserDefaults , we need to have a single
object that manages the parameters table for us. By doing so, we can treat
the entire parameters table as if it were a single object with a dynamic number
of accessors. However, we do not want to have to write an accessor every time
that we add a parameter; ideally, we want to just call -valueForKey: and -setVal-
ue:forKey: and not worry about the persistence of these values. Lastly, we want
to be able to set up some default values.