cmar.me

If you create a new iOS project and include Core Data, the AppDelegate has three members in the “Core Data Stack”. NSManagedObjectModel, NSPersistentStoreCoordinator and NSManagedObjectContext work together to provide Object Relational Mapping (ORM) to the data store. These perform the same functions as Hibernate’s Session or Rails ActiveRecord.

These objects are lazy loaded. They initialize in a chain. When you ask for the managedObjectContext, it will lazy load the persistentStoreCoordinator. In turn, the persistentStoreCoordinator will lazy load the managedObjectModel. This diagram shows the 4 requests used to initialize the objects.

To access the persisted data, you request the managedObjectContext by calling the accessor on the AppDelegate.. This will return a perviously initialized object or lazy load it. The managedObjectContext does not access the data directly. It must use a persistentStoreCoordinator to retrieve or persist data to your storage. It makes a call to the persistentStoreCoordinator accessor.

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

The persistentStoreCoordinator accessor will return a previously initialized copy or construct a new one. For the persistentStoreCoordinator to work, it must know 3 things: the location of the storage (MyApp.sqlite), the type of storage (NSSQLiteStoreType) and a description of the data stored (managedObjectModel) . For the managedObjectModel, it calls the managedObjectModel accessor on the AppDelegate.

- (NSPersistentStoreCoordinator *)persistentStoreCoordinator
{
    if (__persistentStoreCoordinator != nil)
    {
        return __persistentStoreCoordinator;
    }
    
    NSURL *storeURL = [[self applicationDocumentsDirectory] URLByAppendingPathComponent:@"MyApp.sqlite"];
    
    NSError *error = nil;
    __persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:[self managedObjectModel]];
    if (![__persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeURL options:nil error:&error])

The managedObjectModel accessor is the last method in our lazy initialization chain. It gets initialized with the xcdatamodeld file. That file contains the schema of your data. It includes entity object descriptions and relationships. The ManagedObjectModel is used by the PersistentStoreCoordinator to understand the names of the tables, fields and relationships in the sqlite database.

- (NSManagedObjectModel *)managedObjectModel
{
    if (__managedObjectModel != nil)
    {
        return __managedObjectModel;
    }
    NSURL *modelURL = [[NSBundle mainBundle] URLForResource:@"MyApp" withExtension:@"momd"];
    __managedObjectModel = [[NSManagedObjectModel alloc] initWithContentsOfURL:modelURL];    
    return __managedObjectModel;
}

Thats it! The three objects required to use all the goodness of core data. The source code above is generated in XCode 4. You create a new iOS Window based project and check the box to use “core data”. This is just a quick introduction to the big 3. As you dive deeper, you’ll learn that you can create multiple persistentStoreCoordinators and aggregate them together in the ManagedObjectContext. You can also use different storage types. For most iOS applications, the generated template methods above are all you need.