Phát triển ứng dụng cho iPhone và iPad - part 17 doc

Using Core Data: A Simple Task Manager
❘
129
initWithManagedObjectModel:[self managedObjectModel]];
if (![persistentStoreCoordinator
addPersistentStoreWithType:NSSQLiteStoreType
configuration:nil URL:storeUrl
options:nil
error: & error]) {
/*
Replace this implementation with code to handle the error
appropriately.

abort() causes the application to generate a crash log and terminate.
You should not use this function in a shipping application, although
it may be useful during development. If it is not possible to recover
from the error, display an alert panel that instructs the user to quit
the application by pressing the Home button.

Typical reasons for an error here include:
* The persistent store is not accessible
* The schema for the persistent store is incompatible with current
managed object model
Check the error message to determine what the actual problem was.
*/
NSLog(@”Unresolved error %@, %@”, error, [error userInfo]);
abort();
}

return persistentStoreCoordinator;
}

TasksAppDelegate.m
The code fi rst determines if the Persistent Store Coordinator already exists. If it exists, the method
returns it to you.
If the coordinator does not exist, the code must create it. In order to create the coordinator, you need
to pass in a URL that points to the data store. The template uses the
fileURLWithPath: method on
the
NSURL class to create the URL. You can see that the store name will be Tasks.sqlite .
Next, the code allocates an
NSError object to hold the error data that the Persistent Store
Coordinator generates if there is a problem confi guring the coordinator.
The next line allocates and initializes the coordinator using the Managed Object Model. You will
look at the
managedObjectModel getter method in a moment. Remember that you use the Persistent
Store Coordinator to mediate between the Managed Object Context, the Managed Object Model,
and the data store. Therefore, it makes sense that the coordinator would need to have a reference to
the model.
Now that the coordinator knows about the model, the code goes on to tell it about the data store.
The next line of code adds the data store to the coordinator. You will notice that the type
of the data store is
NSSQLiteStoreType . This indicates that the template uses the SQLite backing
data store. If you wanted to use the binary store, you would change this enumeration value to

NSBinaryStoreType , and if you wanted to use the in - memory store, you would set the value
to
NSInMemoryStoreType . Remember that most often you will be using the SQLite backing store.
CH005.indd 129CH005.indd 129 9/18/10 9:34:23 AM9/18/10 9:34:23 AM
130
❘
CHAPTER 5 INTRODUCING CORE DATA

The rest of the code logs an error if there was a problem adding the SQLite store to the coordinator.
If there was no error, the method returns the coordinator.
The getter function to return the Managed Object Model is very straightforward:
- (NSManagedObjectModel *)managedObjectModel {

if (managedObjectModel != nil) {
return managedObjectModel;
}
managedObjectModel = [[NSManagedObjectModel
mergedModelFromBundles:nil] retain];
return managedObjectModel;
}
TasksAppDelegate.m
If the model already exists, the getter method returns it. If not, the code creates a new Managed Object
Model by merging all of the model fi les contained in the application bundle. The
Tasks.xcdatamodel
fi le in the Resources folder contains the object model. This fi le is included with the application bundle,
so this method takes that fi le and uses it to create the
NSManagedObjectModel object.
The last bit of interesting code in the App Delegate is the
managedObjectContext getter method:
- (NSManagedObjectContext *) managedObjectContext {

if (managedObjectContext != nil) {
return managedObjectContext;
}

NSPersistentStoreCoordinator *coordinator =
[self persistentStoreCoordinator];
if (coordinator != nil) {

managedObjectContext = [[NSManagedObjectContext alloc] init];
[managedObjectContext setPersistentStoreCoordinator: coordinator];
}
return managedObjectContext;
}
TasksAppDelegate.m
This method works similarly to the previous two. The fi rst thing it does is check to see if the context
already exists. If the context exists, the method returns it.
Next, the code gets a reference to the
persistentStoreCoordinator . If you refer back to
Figure 5 - 1, you will see that the Managed Object Context needs only a reference to the Persistent
Store Coordinator.
If the code successfully gets a reference to the coordinator, it goes on to create the context. Then, the
code sets the coordinator for the context and returns the context.
CH005.indd 130CH005.indd 130 9/18/10 9:34:23 AM9/18/10 9:34:23 AM
Using Core Data: A Simple Task Manager
❘
131
I hope that the way in which all of the objects in the Core Data stack fi t together is becoming a bit
clearer. Remember that you did not have to write any code to create the data store, the Persistent
Store Coordinator, the Managed Object Model, or the Managed Object Context. The template code
takes care of all of this for you automatically. You will see that the only interface that you need to
deal with is that of the Managed Object Context.
The Data Model
Before you examine the RootViewController and how to use it to create your TableView using
Core Data, let ’ s look at the template Managed Object Model. If you open the Resources folder in
Xcode and double - click on
Tasks.xcdatamodel , you should see something similar to Figure 5 - 3.
FIGURE 5 - 3: The default Object Model
The code template creates a default entity called “ Event. ” The blue highlighting and resize handles

indicate that the Event entity is selected. Click anywhere else in the diagram to de - select the Event
entity and it will turn pink to indicate that it is no longer selected. Click on the Event entity again to
select it.
There are three panes in the top of the data - modeling tool. From left to right they are the Entities
pane, the Properties pane, and the Detail pane. The Entities pane provides a list of all of the entities
in your model. The Properties pane lists the properties of the currently selected entity, and the
Detail pane shows details related to whatever is currently selected, either an entity or property. The
bottom portion of the tool displays a graphical representation of your model called the Diagram
View. The next chapter provides more detail on using the data - modeling tool.
CH005.indd 131CH005.indd 131 9/18/10 9:34:24 AM9/18/10 9:34:24 AM
132
❘
CHAPTER 5 INTRODUCING CORE DATA
You can see in Figure 5 - 3 that the Event entity has an attribute called timeStamp . If you select the
Event entity and then select the
timeStamp property in the Properties pane, you will see the details
of the
timeStamp attribute in the Detail pane. You should see that the timeStamp attribute is
optional and that it is a Date type.
Your managed object context will manage the objects defi ned by the Event entity. Remember that
when you created the Persistent Store Coordinator, you initialized it with all of the managed object
models in the bundle. Then, when you created the context, it used the Persistent Store Coordinator.
Next, you will see how you use the Event entity to create and manage Core Data Managed Objects
in code.
RootViewController
The RootViewController is a subclass of UITableViewController and contains the TableView
that you will use to display your data. This class has a property that holds the context,
which the Application Delegate sets when it creates the
RootViewController instance. The

RootViewController also has a property that holds an

NSFetchedResultsController .
The
NSFetchedResultsController class is the
glue that binds the results of a fetch request against
your datasource to a
TableView . You will look at the

NSFetchedResultsController class in more detail in
Chapter 6.
Figure 5 - 4 shows a high - level view of how the

NSFetchedResultsController class works. The
class takes a fetch request and a context as its inputs
and calls delegate methods when the data in the fetch
request changes. The controller implements methods
that you use when implementing the
TableView
delegate methods that you are familiar with from
Chapter 3.
The fi rst thing to notice is that the
RootViewController implements the

NSFetchedResultsControllerDelegate protocol. You can see this in the RootViewController.h
header fi le. Remember that declaring that you implement a protocol is a contract that commits you
to implementing certain methods. Classes that do not implement this protocol cannot be delegates
for an
NSFetchedResultsController .
The following is the code for the getter method for the

fetchedResultsController property:
- (NSFetchedResultsController *)fetchedResultsController {

if (fetchedResultsController != nil) {
return fetchedResultsController;
}

/*
NSFetchedResultsController
Fetched Results Controller
Delegate
Fetch Request
Managed Object
Context
FIGURE 5 - 4: NSFetchedResultsController
usage
CH005.indd 132CH005.indd 132 9/18/10 9:34:24 AM9/18/10 9:34:24 AM
Using Core Data: A Simple Task Manager
❘
133
Set up the fetched results controller.
*/
// Create the fetch request for the entity.
NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
// Edit the entity name as appropriate.
NSEntityDescription *entity =
[NSEntityDescription entityForName:@”Event”
inManagedObjectContext:managedObjectContext];
[fetchRequest setEntity:entity];

// Set the batch size to a suitable number.
[fetchRequest setFetchBatchSize:20];

// Edit the sort key as appropriate.
NSSortDescriptor *sortDescriptor =
[[NSSortDescriptor alloc] initWithKey:@”timeStamp”
ascending:NO];
NSArray *sortDescriptors =
[[NSArray alloc] initWithObjects:sortDescriptor, nil];

[fetchRequest setSortDescriptors:sortDescriptors];

// Edit the section name key path and cache name if appropriate.
// nil for section name key path means “no sections”.
NSFetchedResultsController *aFetchedResultsController =
[[NSFetchedResultsController alloc]
initWithFetchRequest:fetchRequest
managedObjectContext:managedObjectContext
sectionNameKeyPath:nil cacheName:@”Root”];

aFetchedResultsController.delegate = self;
self.fetchedResultsController = aFetchedResultsController;

[aFetchedResultsController release];
[fetchRequest release];
[sortDescriptor release];
[sortDescriptors release];

return fetchedResultsController;
}

RootViewController.m
The fi rst part of the code should be familiar. It checks to see if you have already created the

fetchedResultsController . If it already exists, the method returns the controller. If not, the code
goes on to create it.
The next section of code creates and confi gures the objects needed by the

fetchedResultsController . As you can see from Figure 5 - 4, you need a fetch request and a
context to be able to use the
fetchedResultsController . Because you already have a context, in
the
managedObjectContext property, the code only needs to create a fetch request.
You can think of a fetch request as a SQL
SELECT statement. The code creates a FetchRequest
object, creates an entity based on the
“ Event ” entity in the context, and then sets the entity used by
CH005.indd 133CH005.indd 133 9/18/10 9:34:25 AM9/18/10 9:34:25 AM
134
❘
CHAPTER 5 INTRODUCING CORE DATA
the fetchRequest . Next, the code sets the batch size of the fetchRequest to a reasonable number
of records to receive at a time.
The next bit of code creates an
NSSortDescriptor . You use the NSSortDescriptor to sort
the results in the
fetchRequest . You can think of the NSSortDescriptor as a SQL ORDER BY
clause. Here, you order the result set based on the
timeStamp fi eld in descending order. The

NSSortDescriptor then sets the sort descriptor used by the fetch request.

Finally, calling the
initWithFetchRequest:managedObjectContext:sectionNameKeyPath:
cacheName:
method creates and initializes fetchedResultsController . The template then sets the
delegate to
self , assigns the fetchedResultsController property, and then the template releases
the local objects.
The only delegate method from the
NSFetchedResultsControllerDelegate protocol implemented
by the template is
controllerDidChangeContent: . The fetchedResultsController calls this
method when all changes to the objects managed by the controller are complete. In this case, you
tell the table to reload its data.
- (void)controllerDidChangeContent:(NSFetchedResultsController *)controller {
// In the simplest, most efficient, case, reload the table view.
[self.tableView reloadData];
}
RootViewController.m
Now that you have seen how you create and confi gure the fetchedResultsController , let ’ s look
at how you confi gure the
RootViewController at startup. You do this in the viewDidLoad method:
- (void)viewDidLoad {
[super viewDidLoad];

// Set up the edit and add buttons.
self.navigationItem.leftBarButtonItem = self.editButtonItem;

UIBarButtonItem *addButton = [[UIBarButtonItem alloc]
initWithBarButtonSystemItem:UIBarButtonSystemItemAdd
target:self

action:@selector(insertNewObject)];

self.navigationItem.rightBarButtonItem = addButton;
[addButton release];

NSError *error = nil;
if (![[self fetchedResultsController] performFetch: & error]) {
// Log the error
NSLog(@”Unresolved error %@, %@”, error, [error userInfo]);

// Quit
abort();
}
}
RootViewController.m
CH005.indd 134CH005.indd 134 9/18/10 9:34:25 AM9/18/10 9:34:25 AM
Using Core Data: A Simple Task Manager
❘
135
The method fi rst calls the superclass version of viewDidLoad to ensure that you perform any
initialization required by the superclass.
Next, the code confi gures the Edit button, creates the Add button and adds the buttons to the
navigation at the top of the screen. You can see in the initialization of the
addButton that
the
insertNewObject method will be called when someone taps the Add button.
Finally, you call the
performFetch: method on the fetchedResultsController to execute the
fetch request and retrieve the desired data.
Now, you will look at how you use the

TableView delegate methods to display your data. These
should be familiar to you from Chapter 3.
The fi rst method is
numberOfSectionsInTableView :.
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
return [[fetchedResultsController sections] count];
}
RootViewController.m
As you may recall, the TableView calls this method when it needs to know how many sections to
display. Here, the code simply asks the
fetchedResultsController for the number of sections.
The next
TableView delegate method is numberOfRowsInSection :.
- (NSInteger)tableView:(UITableView *)tableView
numberOfRowsInSection:(NSInteger)section {

id < NSFetchedResultsSectionInfo > sectionInfo =
[[fetchedResultsController sections] objectAtIndex:section];
return [sectionInfo numberOfObjects];
}
RootViewController.m
Again, you call upon the fetchedResultsController to return the number of rows to display.
Finally, you confi gure the cell in the
cellForRowAtIndexPath : method.
- (UITableViewCell *)tableView:(UITableView *)tableView
cellForRowAtIndexPath:(NSIndexPath *)indexPath {

static NSString *CellIdentifier = @”Cell”;

UITableViewCell *cell = [tableView

dequeueReusableCellWithIdentifier:CellIdentifier];
if (cell == nil) {
cell = [[[UITableViewCell alloc]
initWithStyle:UITableViewCellStyleDefault
reuseIdentifier:CellIdentifier] autorelease];
}

CH005.indd 135CH005.indd 135 9/18/10 9:34:26 AM9/18/10 9:34:26 AM
136
❘
CHAPTER 5 INTRODUCING CORE DATA
// Configure the cell.
NSManagedObject *managedObject = [fetchedResultsController
objectAtIndexPath:indexPath];
cell.textLabel.text =
[[managedObject valueForKey:@”timeStamp”] description];

return cell;
}
RootViewController.m
This code should be familiar down to the point where it retrieves the managed object. Again, the
code asks
fetchedResultsController for the object pointed to by the index path. Once it obtains
this object, the code uses key - value coding to get the value for the
timeStamp property. You learn
more about key - value coding in Chapter 6.
The
commitEditingStyle:forRowAtIndexPath: method contains the code to handle editing rows
in the
TableView . The TableView calls this method when editing of the TableView will cause a

change to the underlying data. In this case, deleting an object in the
TableView should delete the
object from the context.
- (void)tableView:(UITableView *)tableView
commitEditingStyle:(UITableViewCellEditingStyle)editingStyle
forRowAtIndexPath:(NSIndexPath *)indexPath {

if (editingStyle == UITableViewCellEditingStyleDelete) {
// Delete the managed object for the given index path
NSManagedObjectContext *context =
[fetchedResultsController managedObjectContext];

[context deleteObject:
[fetchedResultsController objectAtIndexPath:indexPath]];

// Save the context.
NSError *error = nil;
if (![context save: & error]) {
NSLog(@”Unresolved error %@, %@”, error, [error userInfo]);
abort();
}
}
}
RootViewController.m
The code fi rst determines if the user has deleted a cell. Then, it gets a reference to the context and
tells the context to delete the object that was deleted from the
TableView . Last, the context changes
are committed to disk by calling the
save: method.
The last interesting bit of code in the

RootViewController is the insertNewObject method. Recall
that this is the method that will be called when a user taps the Add button at the top of the screen.
CH005.indd 136CH005.indd 136 9/18/10 9:34:27 AM9/18/10 9:34:27 AM
Using Core Data: A Simple Task Manager
❘
137
- (void)insertNewObject {

// Create a new instance of the entity managed by the fetched results
// controller.
NSManagedObjectContext *context =
[fetchedResultsController managedObjectContext];
NSEntityDescription *entity =
[[fetchedResultsController fetchRequest] entity];
NSManagedObject *newManagedObject =
[NSEntityDescription insertNewObjectForEntityForName:[entity name]
inManagedObjectContext:context];

// If appropriate, configure the new managed object.
[newManagedObject setValue:[NSDate date] forKey:@”timeStamp”];

// Save the context.
NSError *error = nil;
if (![context save: & error]) {
NSLog(@”Unresolved error %@, %@”, error, [error userInfo]);
abort();
}
}
RootViewController.m
Like the commitEditingStyle:forRowAtIndexPath: method, this code fi rst gets a

reference to the context. Next, the code creates a new entity based on the entity that the

fetchedResultsController uses. The code then creates a new managed object based on that entity
and inserts it into the context. Next, the code confi gures the managed object with the appropriate
data; in this case, a timestamp. Finally, the context is committed to disk with the
save: method.
Modifying the Template Code
Now that you are familiar with how the template code works, you will modify it to create tasks
instead of timestamps. To build the task application, you will modify the data model by creating
a Task entity, create a new
ViewController that you will use to create tasks, and update the

RootViewController to use the new Task entity.
The fi rst thing that you will do is to modify the data model by changing the existing Event entity to
make it a Task entity. If you make a change to the data model and attempt to run your application,
you will get an error that looks something like this:
2010-03-31 12:50:34.595 Tasks[2424:207] Unresolved error Error
Domain=NSCocoaErrorDomain Code=134100 UserInfo=0x3d12140
“Operation could not be completed. (Cocoa error 134100.)”, {
metadata = {
NSPersistenceFrameworkVersion = 248;
NSStoreModelVersionHashes = {
Location = < fa099c17 c3432901 bbaf6eb3 1dddc734 a9ac14d2 36b913ed
97ebad53 3e2e5363 > ;
Task = < 40414517 78c0bd9f 84e09e2a 91478c44 d85394f8 e9bb7e5a
abb9be27 96761c30 > ;
};
CH005.indd 137CH005.indd 137 9/18/10 9:34:27 AM9/18/10 9:34:27 AM
138
❘

CHAPTER 5 INTRODUCING CORE DATA
NSStoreModelVersionHashesVersion = 3;
NSStoreModelVersionIdentifiers = (
);
NSStoreType = SQLite;
NSStoreUUID = “762ED962-367C-476C-B4BD-076A6D1C33A9”;
“_NSAutoVacuumLevel” = 2;
};
reason = “The model used to open the store is incompatible with the one
used to create the store”;
}
RootViewController.m
This error says that “ The model used to open the store is incompatible with the one used to create
the store. ” This means exactly what it sounds like: The data store on the device is not compatible
with your revised data model, so Core Data cannot open it. When you encounter this situation, you
will need to use Core Data migration to move your data from one data model to another. Core Data
migration is covered in detail in Chapter 9. For now, simply delete the existing application from the
simulator or device before trying to run it again. This will force Core Data to build a new data store
that is compatible with the data model.
Open the
Tasks.xcdatamodel fi le, and then select the Event entity. Change the name of the entity
to “ Task ” in the Detail pane. Add a new property to the Task entity by clicking the plus icon below
the Properties pane and selecting Add Attribute. Call the attribute
taskText and set its type to

String in the Properties pane. You will use the new attribute to store the text for your tasks. Your
data model should look like Figure 5 - 5.
FIGURE 5 - 5: Revised Tasks data model
CH005.indd 138CH005.indd 138 9/18/10 9:34:28 AM9/18/10 9:34:28 AM