Question

After using Instruments, I have found the a spot in my code that is very long running and blocking my UI: lots of Core Data fetches (it’s part of a process of ingesting a large JSON packet and building up managed objects while making sure that objects have not be duplicated).

While my intentions are to break up this request into smaller pieces and process them serially, that only means I’ll be spreading out those fetches – I anticipate the effect will be small bursts of jerkiness in the app instead of one long hiccup.

Everything I’ve read both in Apple’s docs and online at various blog posts indicates that Core Data and concurrency is akin to poking a beehive. So, timidly I’ve sat down to give it the ol’ college try. Below is what I’ve come up with, and I would appreciate someone wiser pointing out any errors I’m sure I’ve written.

The code posted below works. What I have read has me intimidated that I’ve surely done something wrong; I feel like if pulled the pin out of a grenade and am just waiting for it to go off unexpectedly!

NSBlockOperation *downloadAllObjectContainers = [NSBlockOperation blockOperationWithBlock:^{
    NSArray *containers = [webServiceAPI findAllObjectContainers];
}];

[downloadAllObjectContainers setCompletionBlock:^{

    NSManagedObjectContext *backgroundContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
    [backgroundContext setPersistentStoreCoordinator:[_managedObjectContext persistentStoreCoordinator]];

    [[NSNotificationCenter defaultCenter] addObserverForName:NSManagedObjectContextDidSaveNotification
                                                      object:backgroundContext
                                                       queue:[NSOperationQueue mainQueue]
                                                  usingBlock:^(NSNotification *note) {
                                                      [_managedObjectContext mergeChangesFromContextDidSaveNotification:note];
                                                  }];


        Builder *builder = [[Builder alloc] init];
        [builder setManagedObjectContext:backgroundContext];

        for (ObjectContainer *objCont in containers) {  // This is the long running piece, it's roughly O(N^2) yuck!
            [builder buildCoreDataObjectsFromContainer:objCont];
        }

    NSError *backgroundContextSaveError = nil;
    if ([backgroundContext hasChanges]) {
        [backgroundContext save:&backgroundContextSaveError];
    }
}];

NSOperationQueue *background = [[NSOperationQueue alloc] init];
[background addOperation:downloadAllObjectContainers];

Answer 1

Since you are using NSPrivateQueueConcurrencyType you must be doing it for iOS5, you do not have to go through all the trouble of creating context in a background thread and merging it in the main thread.

All you need is to create a managed object context with concurrency type NSPrivateQueueConcurrencyType in the main thread and do all operations with managed objects inside a block passed in to managedObjectContext:performBlock method.

I recommend you take a look at WWDC2011 session 303 – What’s New in Core Data on iOS.
Also, take a look at Core Data Release Notes for iOS5.

Here’s a quote from the release notes:

NSManagedObjectContext now provides structured support for concurrent operations. When you create a managed object context using initWithConcurrencyType:, you have three options for its thread (queue) association

Confinement (NSConfinementConcurrencyType).

This is the default. You promise that context will not be used by any thread other than the one on which you created it. (This is exactly the same threading requirement that you’ve used in previous releases.)

Private queue (NSPrivateQueueConcurrencyType).

The context creates and manages a private queue. Instead of you creating and managing a thread or queue with which a context is associated, here the context owns the queue and manages all the details for you (provided that you use the block-based methods as described below).

Main queue (NSMainQueueConcurrencyType).

The context is associated with the main queue, and as such is tied into the application’s event loop, but it is otherwise similar to a private queue-based context. You use this queue type for contexts linked to controllers and UI objects that are required to be used only on the main thread.