Although you won't typically access your application's data model directly, you should be aware of the fact that there is an Objective-C class that represents the data model in memory. This class is called NSManagedObjectModel, and the template automatically creates an instance of NSManagedObjectModel based on the data model file in your project. Let's take a look at the code that creates it now.

In your project window's Groups & Files pane, open the Classes group and single-click CoreDataAppDelegate.m. At the top of the editor pane, click the function menu to bring up a list of the methods in this class (see Figure 2-5). Select -managedObjectModel, which will take you to the method that creates the object model based on the CoreData.xcdatamodel file.

Figure 2.5. The editor pane's pop-up menu

The method should look like this:

/**
 Returns the managed object model for the application.
 If the model doesn't already exist, it is created by merging all of the models
 found in the application bundle.
 */
- (NSManagedObjectModel *)managedObjectModel {
    if (managedObjectModel != nil) {
        return managedObjectModel;
    }
    managedObjectModel = [[NSManagedObjectModel mergedModelFromBundles:nil] retain];
    return managedObjectModel;
}

The first thing it does is check the instance variable managedObjectModel to see if it's nil. This accessor method uses a form of lazy loading. The underlying instance variable doesn't actually get instantiated until the first time the accessor method is called. For this reason, you should never, ever access managedObjectModel directly (except within the accessor method itself, of course). Always make sure to use the accessor methods. Otherwise, you could end up trying to make calls on an object that hasn't been created yet.

If managedObjectModel is nil, we'll go get our data models. Remember how we said that a persistent store was associated with a single data model? Well, that's true, but it doesn't tell the whole story. You can combine multiple .xcdatamodel files into a single instance of NSManagedObjectModel, creating a single data model that combines all the entities from multiple files. This line of code takes any .xcdatamodel files that might be in your Xcode project and combines them together into a single instance of NSManagedObjectModel:

managedObjectModel = [[NSManagedObjectModel mergedModelFromBundles:nil] retain];

So, for example, if you were to create a second data model file and add it to your project, that new file would be combined with CoreData.xcdatamodel into a single managed object model that contained the contents of both files. This allows you to split up your application's data model into multiple smaller and more manageable files.

The vast majority of iPhone applications that use Core Data have a single persistent store and a single data model, so the default template code will work beautifully most of the time, and will let you spread your data model out over multiple files. That said, Core Data does support the use of multiple persistent stores. You could, for example, design your application to store some of its data in a SQLite persistent store and some of it in a binary flat file. If you find that you need to use multiple data models, remember to change the template code here to load the managed object models individually, using initWithContentsOfURL:.

The persistent store isn't actually represented by an Objective-C class. Instead, a class called NSPersistentStoreCoordinator controls access to the persistent store. In essence, it takes all the calls coming from different classes that trigger reads or writes to the persistent store and serializes them so that multiple calls against the same file are not being made at the same time, which could result in problems due to file or database locking.

As is the case with the managed object model, the template provides us with a method in the application delegate that creates and returns an instance of a persistent store coordinator. Other than creating the store and associating it with a data model and a location on disk (which is done for you in the template), you will rarely need to interact with the persistent store coordinator directly. You'll use high-level Core Data calls, and Core Data will interact with the persistent store coordinator to retrieve or save the data.

Let's take a look at the method that returns the persistent store coordinator. In CoreDataAppDelegate.m, select -persistentStoreCoordinator from the function pop-up menu. Here's the method:

/**
 Returns the persistent store coordinator for the application.
 If the coordinator doesn't already exist, it is created and the application's store
 added to it.
 */
- (NSPersistentStoreCoordinator *)persistentStoreCoordinator {

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

    NSURL *storeUrl = [NSURL fileURLWithPath: [[self applicationDocumentsDirectory]
        stringByAppendingPathComponent: @"CoreData.sqlite"]];

    NSError *error;
    persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc]
        initWithManagedObjectModel: [self managedObjectModel]];
    if (![persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType
        configuration:nil URL:storeUrl options:nil error:&error]) {
        // Handle error
    }

    return persistentStoreCoordinator;
}

As with the managed object model, this persistentStoreCoordinator accessor method uses lazy loading and doesn't instantiate the persistent store coordinator until the first time it is accessed. Then it creates a path to a file called CoreData.sqlite in the documents directory in your application's sandbox. The template will always create a filename based on your project's name. If you want to use a different name, you can change it here, though it generally doesn't matter what you call the file, since the user will never see it.

Take a look at this line of code:

if (![persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType
        configuration:nil URL:storeUrl options:nil error:&error]) {

The first parameter to this method, NSSQLiteStoreType, determines the type of the persistent store. NSSQLiteStoreType is a constant that tells Core Data to use a SQLite database for its persistent store. If you want your application to use a single, binary flat file instead of a SQLite database, you could specify the constant NSBinaryStoreType instead of NSSQLiteStoreType. The vast majority of the time, the default setting is the best choice, so unless you have a compelling reason to change it, leave it alone.

Before we move on to other parts of Core Data, let's quickly review how the pieces we've looked at so far fit together. You might want to refer back to Figure 2-3.

The persistent store (or backing store) is a file on the iPhone's file system that can be either a SQLite database or a binary flat file. A data model file, contained in one or more files with an extension of .xcdatamodel, describes the structure of your application's data. This file can be edited in Xcode. The data model tells the persistent store coordinator the format of all data stored in that persistent store. The persistent store coordinator is used by other Core Data classes that need to save, retrieve, or search for data. Easy enough, right? Let's move on.

As we said before, the rounded rectangle in the center is an entity. In effect, an entity is like an Objective-C class declaration. Each data model class you would create if you didn't use Core Data translates to an entity when you do use Core Data.

Each entity has a name—in this case, Event—which must begin with a capital letter. In the template application you ran earlier, each time you pressed the plus button, a new instance of Event was created and stored in the application's persistent store.

In the data model editor, you can tell if an entity is selected by its color. A selected entity will have a blue title bar and be surrounded by eight resize handles. An unselected entity will have a reddish-gray title bar, and it will not have any resize handles. Single-click the Event entity title bar to select it.

As you select the Event entity, take a look at the top-left pane, known as the entity pane. The entity pane is a list of all the entities that have been defined in this data model. The template we used for this project creates a single entity, Event. Selecting Event in the entity pane is the same as selecting the rounded rectangle in the bottom pane. Try it: Click outside the entity in the bottom pane to deselect it, and then click the Event line in the entity pane. The entity in the bottom pane will also be selected. The upper-left and bottom panes show two different views of the same entity list.

While the entity pane lists all the data model's entities, the upper-middle pane, known as the property pane, lists the properties that belong to the selected entity.

The entity itself has no mechanism for storing data. Instead, entities are made up of one or more properties that define it. When you select an entity in the entity pane, its properties are displayed in the property pane.

An entity can be made up of any number of properties. There are four different types of properties: attributes, relationships, fetched properties, and fetch requests.

Attributes

The property that you'll use the most when creating entities is the attribute, which serves the same function in a Core Data entity as an instance variable does in an Objective-C class—they both hold data. If you look at your data model editor (or at Figure 2-4), you'll see that the Event entity has one property: an attribute named timeStamp. The timeStamp attribute holds the date and time when a given Event instance was created. In our sample application, when you click the plus sign, a new row is added to the table displaying a single Event's timeStamp.

Just like an instance variable, each attribute has a type, which is set using a pop-up menu in the third column of the attribute pane. Let's take a look at that pop-up menu. Make sure Event is selected in the entity pane, and then select timeStamp in the attribute pane. Note the word Date in the third column of the timeStamp attribute. That's a pop-up menu (see Figure 2-6). Select it, but don't change its value (leave it as Date). You can see the range of options for attribute type. We'll look at the different attribute types in the next few chapters when we begin building our own data models.

A date attribute, such as timeStamp, corresponds to an instance of NSDate. If you want to set a new value for a date attribute, you need to provide an instance of NSDate to do so. A string attribute corresponds to an instance of NSString, and most of the numeric types correspond to an instance of NSNumber.

Tip

Don't worry too much about all the other buttons, text fields, and check boxes in the data model editor. As you make your way through the next few chapters, you'll get a sense of what each does.

Figure 2.6. The attribute type pop-up menu appears when you click an attribute in the Type or Destination column.

The NSDictionary class allows you to store objects in a data structure and retrieve an object using a unique key. Like the NSDictionary class, NSManagedObject supports the key-value methods valueForKey: and setValue:forKey: for setting and retrieving attribute values. It also has additional methods for working with relationships. You can, for example, retrieve an instance of NSMutableSet representing a specific relationship. Adding managed objects to this mutable set, or removing them will add or remove objects from the relationship it represents.

If the NSDictionary class is new to you, take a few minutes to fire up Xcode and read about NSDictionary in the documentation viewer. The important concept to get your head around is key-value coding, or KVC. Core Data uses KVC to store and retrieve data from its managed objects.

In our template application, consider an instance of NSManagedObject that represents a single Event. We could retrieve the value stored in its timeStamp attribute by calling valueForKey:, like so:

NSDate *timeStamp = [managedObject valueForKey:@"timeStamp"];

Since timeStamp is an attribute of type date, we know the object returned by valueForKey: will be an instance of NSDate. Similarly, we could set the value using setValue:ForKey:. The following code would set the timeStamp attribute of managedObject to the current date and time:

[managedObject setValue:[NSDate date] forKey:@"timeStamp"];

KVC also includes the concept of a keypath. Keypaths allow you iterate through object hierarchies using a single string. So, for example, if we had a relationship on our Employee entity called whereIWork, which pointed to an entity named Employer, and the Employer entity had an attribute called name, then we could get to the value stored in name from an instance of Employee using a keypath like so:

NSString *employerName = [managedObject valueForKeyPath:@"whereIWork.name"];

Notice that we use valueForKeyPath: instead of valueForKey:, and we provide a dot-separated value for the keypath. KVC parses that string using the dots, so in this case, it would parse it into two separate values: whereIWork, and name. It uses the first one (whereIWork) on itself, and retrieves the object that corresponds to that key. It then takes the next value in the keypath (name) and retrieves the object stored under that key from the object returned by the previous call. Since Employer is a to-one relationship, the first part of the keypath would return a managed object instance that represented the Employee's employer. The second part of the keypath would then be used to retrieve the name from the managed object that represents the Employer.

Core Data maintains an object that acts as a gateway between your entities and the rest of Core Data. That gateway is called a managed object context (often just referred to as a context). The context maintains state for all the managed objects that you've loaded or created. The context keeps track of changes that have been made since the last time a managed object was saved or loaded. When you want to load or search for objects, for example, you do it against a context. When you want to commit your changes to the persistent store, you save the context. If you want to undo changes to a managed object, you just ask the managed object context to undo. (Yes, it even handles all the work needed to implement undo and redo for your data model.)

When building iPhone applications, the vast majority of the time, you will have only a single context. However, you can have more than one context. For example, if your application supports threading or some other form of concurrency, such as NSOperationQueue, you'll need more than one context, since contexts are not thread-safe and cannot be shared across threads. This means that the same managed object can exist in two different places with different values if you're not careful.

Because every application needs at least one managed object context to function, the template has very kindly provided us with one. Click CoreDataAppDelegate.m again, and select -managedObjectContext from the function menu. You will see a method that looks like this:

/**
 Returns the managed object context for the application.
 If the context doesn't already exist, it is created and bound to the persistent
 store coordinator for the application.
 */
- (NSManagedObjectContext *) managedObjectContext {

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

    NSPersistentStoreCoordinator *coordinator = [self persistentStoreCoordinator];
    if (coordinator != nil) {
        managedObjectContext = [[NSManagedObjectContext alloc] init];
        [managedObjectContext setPersistentStoreCoordinator: coordinator];
    }
    return managedObjectContext;
}

This method is actually pretty straightforward. Using lazy loading, managedObjectContext is checked for nil. If it is not nil, its value is returned. If managedObjectContext is nil, we check to see if our NSPersistentStoreCoordinator exists. If so, we create a new managedObjectContext, then use setPersistentStoreCoordinator: to tie the current coordinator to our managedObjectContext. When we're finished, we return managedObjectContext.

Note that managed object contexts do not work directly against a persistent store; they go through a persistent store coordinator. As a result, every managed object context needs to be provided with a pointer to a persistent store coordinator in order to function. Multiple managed object contexts can work against the same persistent store coordinator, however.

While we're in the application delegate, let's scroll up to another method called applicationWillTerminate:, which saves changes to the context if any have been made. The changes are saved to the persistent store. As its name implies, this method is called just before the application exits.

/**
 applicationWillTerminate: saves changes in the application's managed object context before the application terminates.
 */
- (void)applicationWillTerminate:(UIApplication *)application {

    NSError *error;
    if (managedObjectContext != nil) {
        if ([managedObjectContext hasChanges] && ![managedObjectContext
            save:&error]) {
            // Handle error.
            NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
            exit(-1);  // Fail
        }
    }
}

This is a nice bit of functionality, but there may be times when you don't want the data to be saved. For example, what if the user quits after creating a new entity, but before entering any data for that entity? In that case, do you really want to save that empty managed object into the persistent store? Possibly not. We'll look at dealing with situations like that in the next few chapters.

You start by creating a fetch request, and then use that fetch request to create a fetched results controller. In our template, this is done in RootViewController.m, in the fetchedResultsController method. fetchedResultsController starts by creating a new fetch request. A fetch request is basically a specification that lays out the details of the data to be fetched. You'll need to tell the fetch request which entity to fetch. In addition, you'll want to add a sort descriptor to the fetch request. The sort descriptor determines the order in which the data is organized.

Once the fetch request is complete, the fetched results controller is created. The fetched results controller is an instance of the class NSFetchedResultsController. Remember that the fetched results controller's job is to use the fetch request to keep its associated data as fresh as possible.

Once the fetched results controller is created, you'll do your initial fetch. We do this in RootViewController.m at the end of ViewDidLoad, by sending our fetched results controller the PerformFetch message.

Now that you have your data, you're ready to be a data source and a delegate to your table view. When your table view wants the number of sections for its table, it will call numberOfSectionsInTableView:. In our version, we get the section information by passing the appropriate message to fetchResultsController. Here's the version from RootViewController.m:

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {

return [[fetchedResultsController sections] count];
}

The same strategy applies in tableView:numberOfRowsInSection:

- (NSInteger)tableView:(UITableView *)tableView
        numberOfRowsInSection:(NSInteger)section {
    id <NSFetchedResultsSectionInfo> sectionInfo =
        [[fetchedResultsController sections] objectAtIndex:section];
    return [sectionInfo numberOfObjects];
}

You get the idea. You used to need to do all this work yourself. Now you can ask your fetched results controller to do all the data management for you. It's an amazing time-saver!

Let's take a closer look at the creation of the fetched results controller. In RootViewController.m, use the function menu to go to the method -fetchedResultsController. It should look like this:

- (NSFetchedResultsController *)fetchedResultsController {
    if (fetchedResultsController != nil) {
        return fetchedResultsController;
    }

    /*
     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;
}

This method uses lazy loading. The first thing it does is check fetchedResultsController for nil. If fetchedResultsController already exists, it is returned; otherwise, the process of creating a new fetchedResultsController is started.

As the first step, we'll need to create an NSFetchRequest and NSEntityDescription, and then attach the NSEntityDescription to the NSFetchRequest:

NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
    // Edit the entity name as appropriate.
    NSEntityDescription *entity = [NSEntityDescription entityForName:@"Event"
        inManagedObjectContext:managedObjectContext];
    [fetchRequest setEntity:entity];

Remember, we're building a fetched results controller, and the fetch request is part of that. Next, we set the batch size to 20. This tells Core Data that this fetch request should retrieve its results 20 at a time. This is sort of like a file system's block size.

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

Next, we build an NSSortDescriptor and specify that it use timeStamp as a key, sorting the timestamps in ascending order (earlier dates first).

// Edit the sort key as appropriate.
    NSSortDescriptor *sortDescriptor = [[NSSortDescriptor alloc]
        initWithKey:@"timeStamp" ascending:YES];

Now we create an array of sort descriptors. Since we'll be using only one, we pass in sortDescriptor and follow it with nil to let initWithObjects know we'll just have a single element in the array. (Note that the template could have used initWithObject instead.)

NSArray *sortDescriptors = [[NSArray alloc] initWithObjects:sortDescriptor,
        nil];

    [fetchRequest setSortDescriptors:sortDescriptors];

Try this experiment: Change ascending:YES to ascending:NO and run the application again. What do you think will happen? Don't forget to change it back when you are finished.

Now we create an NSFetchedResultsController using our fetch request and context. We'll cover the third and fourth parameters, sectionNameKeyPath and cacheName, in Chapter 3.

// 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"];

Next, we set self as the delegate, and set fetchedResultsController to the fetched results controller we just created.

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

Finally, we release our locals and return our newly created fetchedResultsController:

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

   return fetchedResultsController;
}

Don't worry too much about the details here. Try to get your head around the big picture. As you make your way through the next few chapters, the details will come into focus.

The fetched results controller must have a delegate, and that delegate must provide four methods, which we will describe in the pages that follow. These four methods are defined in the protocol NSFetchedResultsControllerDelegate. The fetched results controller monitors its managed object context and calls its delegates as changes are made to its context.

- (void)controllerWillChangeContent:(NSFetchedResultsController *)controller {
    [self.tableView beginUpdates];
}

- (void)controllerDidChangeContent:(NSFetchedResultsController *)controller {
    [self.tableView endUpdates];
}

- (void)controller:(NSFetchedResultsController *)controller
   didChangeObject:(id)anObject
       atIndexPath:(NSIndexPath *)indexPath
     forChangeType:(NSFetchedResultsChangeType)type
      newIndexPath:(NSIndexPath *)newIndexPath {
    switch(type) {
        case NSFetchedResultsChangeInsert:
            [self.tableView insertRowsAtIndexPaths:[NSArray
                arrayWithObject:newIndexPath]
                withRowAnimation:UITableViewRowAnimationFade];
            break;
        case NSFetchedResultsChangeDelete:
            [self.tableView deleteRowsAtIndexPaths:[NSArray

arrayWithObject:indexPath]
                withRowAnimation:UITableViewRowAnimationFade];
            break;
        case NSFetchedResultsChangeUpdate: {
            NSString *sectionKeyPath = [controller sectionNameKeyPath];
            if (sectionKeyPath == nil)
                break;
            NSManagedObject *changedObject = [controller
                objectAtIndexPath:indexPath];
            NSArray *keyParts = [sectionKeyPath componentsSeparatedByString:@"."];
            id currentKeyValue = [changedObject valueForKeyPath:sectionKeyPath];
            for (int i = 0; i < [keyParts count] - 1; i++) {
                NSString *onePart = [keyParts objectAtIndex:i];
                changedObject = [changedObject valueForKey:onePart];
            }
            sectionKeyPath = [keyParts lastObject];
            NSDictionary *committedValues = [changedObject
                committedValuesForKeys:nil];

            if ([[committedValues valueForKeyPath:sectionKeyPath]
                isEqual:currentKeyValue])
                break;

            NSUInteger tableSectionCount = [self.tableView numberOfSections];
            NSUInteger frcSectionCount = [[controller sections] count];
            if (tableSectionCount != frcSectionCount) {
                // Need to insert a section
                NSArray *sections = controller.sections;
                NSInteger newSectionLocation = −1;
                for (id oneSection in sections) {
                    NSString *sectionName = [oneSection name];
                    if ([currentKeyValue isEqual:sectionName]) {
                         newSectionLocation = [sections indexOfObject:oneSection];
                        break;
                    }
                }
                if (newSectionLocation == −1)
                    return; // uh oh
                if (!((newSectionLocation == 0) && (tableSectionCount == 1)
                        && ([self.tableView numberOfRowsInSection:0] == 0)))
                    [self.tableView insertSections:[NSIndexSet
                        indexSetWithIndex:newSectionLocation]
                        withRowAnimation:UITableViewRowAnimationFade];
                NSUInteger indices[2] = {newSectionLocation, 0};
                newIndexPath = [[[NSIndexPath alloc] initWithIndexes:indices
                    length:2] autorelease];
            }
        }
        case NSFetchedResultsChangeMove:
            if (newIndexPath != nil) {
                [self.tableView deleteRowsAtIndexPaths:[NSArray
                    arrayWithObject:indexPath]
                    withRowAnimation:UITableViewRowAnimationFade];
                [self.tableView insertRowsAtIndexPaths: [NSArray
                    arrayWithObject:newIndexPath]
                    withRowAnimation: UITableViewRowAnimationRight];
            }

else {
                [self.tableView reloadSections:[NSIndexSet
                    indexSetWithIndex:[indexPath section]]
                    withRowAnimation:UITableViewRowAnimationFade];
            }
            break;
        default:
            break;
    }
}

case NSFetchedResultsChangeUpdate: {
            NSString *sectionKeyPath = [controller sectionNameKeyPath];
            if (sectionKeyPath == nil)
                break;
            NSManagedObject *changedObject = [controller
                objectAtIndexPath:indexPath];

NSArray *keyParts = [sectionKeyPath
                componentsSeparatedByString:@"."];

id currentKeyValue = [changedObject valueForKeyPath:sectionKeyPath];
            for (int i = 0; i < [keyParts count] - 1; i++) {
                NSString *onePart = [keyParts objectAtIndex:i];
                changedObject = [changedObject valueForKey:onePart];
            }

sectionKeyPath = [keyParts lastObject];
            NSDictionary *committedValues = [changedObject
                committedValuesForKeys:nil];

            if ([[committedValues valueForKeyPath:sectionKeyPath]
                isEqual:currentKeyValue])
                break;

NSUInteger tableSectionCount = [self.tableView numberOfSections];
            NSUInteger frcSectionCount = [[controller sections] count];
            if (tableSectionCount != frcSectionCount) {

// Need to insert a section
                NSArray *sections = controller.sections;
                NSInteger newSectionLocation = −1;
                for (id oneSection in sections) {
                    NSString *sectionName = [oneSection name];
                    if ([currentKeyValue isEqual:sectionName]) {
                         newSectionLocation = [sections
                         indexOfObject:oneSection];

break;
                    }
                }

if (newSectionLocation == −1)
                    return; // uh oh

if (!((newSectionLocation == 0) && (tableSectionCount == 1)
                            && ([self.tableView numberOfRowsInSection:0] == 0)))
                        [self.tableView insertSections:[NSIndexSet
                            indexSetWithIndex:newSectionLocation]
                            withRowAnimation:UITableViewRowAnimationFade];

NSUInteger indices[2] = {newSectionLocation, 0};
                newIndexPath = [[[NSIndexPath alloc] initWithIndexes:indices
                    length:2] autorelease];
            }
        }

case NSFetchedResultsChangeMove:
...

- (void)controller:(NSFetchedResultsController *)controller
  didChangeSection:(id <NSFetchedResultsSectionInfo>)sectionInfo
           atIndex:(NSUInteger)sectionIndex
     forChangeType:(NSFetchedResultsChangeType)type {


    switch(type) {
        case NSFetchedResultsChangeInsert:
            if (!((sectionIndex == 0) && ([self.tableView numberOfSections] == 1)
                    && ([self.tableView numberOfRowsInSection:0] == 0)))
                [self.tableView insertSections:[NSIndexSet
                    indexSetWithIndex:sectionIndex]
                    withRowAnimation:UITableViewRowAnimationFade];
            break;
        case NSFetchedResultsChangeDelete:
            if (!((sectionIndex == 0) && ([self.tableView numberOfSections] == 1)
                    && ([self.tableView numberOfRowsInSection:0] == 0)))
                [self.tableView deleteSections:[NSIndexSet
                    indexSetWithIndex:sectionIndex]
                    withRowAnimation:UITableViewRowAnimationFade];
            break;
        case NSFetchedResultsChangeMove:
        case NSFetchedResultsChangeUpdate:
        default:
            break;
    }
}

Our table view delegate methods became much shorter and more straightforward, since our fetched results controller does much of the work that we previously did in those methods. For example, to retrieve the object that corresponds to a particular cell, which we often need to do in tableView:cellForRowAtIndexPath: and tableView:didSelectRowAtIndexPath:, we can just call objectAtIndexPath: on the fetched results controller and pass in the indexPath parameter, and it will return the correct object:

NSManagedObject *managedObject = [fetchedResultsController
    objectAtIndexPath:indexPath];

From the function menu in the editor pane, select insertNewObject, which is the method that is called when the plus button is pressed in the sample application. It's a nice, simple example of how to create a new managed object, insert it into a managed object context, and then save it to the persistent store.

- (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;
    if (![context save:&error]) {
        // Handle the error...
    }
}

Notice that the first thing the code does is to retrieve a managed object context from the fetched results controller. In this simple example, where there's only one context, we could also have retrieved the same context from the application delegate. There are a few reasons why the default code uses the context from the fetched results controller. First of all, we already have an instance variable that points to the fetched results controller, so we can get to the context in just one line of code:

NSManagedObjectContext *context =
        [fetchedResultsController managedObjectContext];

More important, though, a fetched results controller always knows which context its managed objects are contained by, so even if you decide to create an application with multiple contexts, you'll be sure that you're using the correct context if you pull it from the fetched results controller.

Just as we did when we created a fetch request, when inserting a new object, we need to create an entity description to tell Core Data which kind of entity we want to create an instance of. The fetched results controller also knows what entity the objects it manages are, so we can just ask it for that information:

NSEntityDescription *entity = [[fetchedResultsController fetchRequest] entity];

Then it's simply a matter of using a class method on NSEntityDescription to create the new object and insert it into a context:

NSManagedObject *newManagedObject = [NSEntityDescription
    insertNewObjectForEntityForName:[entity name]
     inManagedObjectContext:context];

It does seem a little odd that we use a class method on NSEntityDescription, rather than an instance method on the context we want to insert the new object into, but that's the way it's done.

Though this managed object has now been inserted into the context, it still exists in the persistent store. In order to insert it from the persistent store, we must save the context, which is what happens next in this method:

NSError *error;
if (![context save:&error]) {
    // Handle the error...
}

Notice that we don't call reloadData on our table view. The fetched results controller will realize that we've inserted a new object that meets its criteria and call the delegate method, which will automatically reload the table.

#import <Cocoa/Cocoa.h>
@interface NSManagedObjectContext(insert)
-(NSManagedObject *) insertNewEntityWithName:(NSString *)name;
@end

#import "NSManagedObjectContext-insert.h"

@implementation NSManagedObjectContext(insert)
-(NSManagedObject *) insertNewEntityWithName:(NSString *)name
{
    return [NSEntityDescription insertNewObjectForEntityForName:name
        inManagedObjectContext:self];
}
@end

NSManagedObject *newManagedObject = [NSEntityDescription
     insertNewObjectForEntityForName:[entity name]
     inManagedObjectContext:context];

[context insertNewEntityWityName:[entity name]];

Deleting managed objects is pretty easy when using a fetched results controller. Use the function menu to navigate to the method called tableView:commitEditingStyle:forRowAtIndexPath:. That method should look like this:

// Override to support editing the table view.
- (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;
        if (![context save:&error]) {
            // Update to handle the error appropriately.
            NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
            exit(-1);  // Fail
        }
    }
}

The method first makes sure that we're in a delete transaction (remember that this same method is used for deletes and inserts):

if (editingStyle == UITableViewCellEditingStyleDelete) {

Next, we retrieve the context:

NSManagedObjectContext *context =
        [fetchedResultsController managedObjectContext];

Then the context is asked to delete that object:

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

Next, the managed object context's save: method is called to cause that change to be committed to the persistent store:

NSError *error;
        if (![context save:&error]) {
            // Update to handle the error appropriately.
            NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
            exit(-1);  // Fail
        }

And that's all there is to deleting managed objects.