To assign or change a field value in the record, use
setValue:forKey:. Pass the value as a Cocoa object and the field label as an
NSString. To read a field value, use
valueForKey:. Again, pass the field label as an
Each record field is represented by an
NSAttributeDescription or an
NSRelationshipDescription class (Figure 8). But we usually do not interact with these two classes. Nor do we create them explicitly. Instead, we use an Xcode feature to define the record schema.
Figure 8: The two classes for representing a record field.
Introducing the Schema Editor
Starting with Xcode 4.x, only three iOS project templates have optional support for Core Data (Figure 9). The other templates do not, but you can add to them the files and frameworks needed for Core Data.
Figure 9: The templates that have built-in support for Core Data.
The Master-Detail template creates the traditional navigation-style app. It provides two panel views, one to show a list of records, another to show a record's details. The Utility template creates an app with a single panel view. It is meant for loading and viewing records one at a time. Finally, the Empty template is generic. It does not provide any panel views, giving you the freedom to define your own.
Suppose you want to use the Master-Detail template. Select the template from the Project Assistant and click Next. On the options panel (Figure 10), fill in the project details. Make sure to set the checkbox labelled Use Core Data. Click Next and set the project's location and source repository. Then click Create to save the project and its support files.
Figure 10: The options panel of the Project Assistant.
Figure 11 lists the files supplied by the template. One file, FooTriage.xcdatamodeld, will carry the database schema being defined. Selecting it displays the new schema editor shown on the right. The editor then divides the schema into three main groups. For now, we will focus only on the Entities group, which the editor shows by default.
Figure 11: The files supplied by the template.
Next, the schema editor divides each Entities group item into three subpanels. The Attributes subpanel will house the record fields that hold user data.Tthe Relationships subpanel will house fields that link one table entity to another. And the Fetched Properties subpanel will house fields that hold weak static queries.
Below the schema editor is its toolbar. The Add Entity button inserts a new table entity to the database schema. The Add Attributes button inserts a new field attribute. Both buttons use a popup-menu to list alternate options. And the Editor Style button changes the editor's display mode.
Defining the Database Schema
Let's use the schema editor to define the database structure in Figure 12. This is a bare-bones triage database used by some medical applications. The Person table is the primary table. It holds specifics about a patient such as name, age and gender. The Vitals table is the secondary; it holds the health readings for each patient.
Figure 12: The database structure of the sample app.
The Injury table assigns each patient one of eight possible injuries. The Status table files each patient under one of four possible states. Both Injury and Status are constant tables; their records stay unchanged during usage.