Is asynchronous Core Data needed in most cases?

Question

I've learned that generally, intensive tasks should take place on background threads, as if they're on the main thread they'll block user interaction and interface updates.

Does Core Data fall under that umbrella? I received a great answer to my question about loading images asynchronously in a UITableView, but I'm curious how to then work with Core Data as the backend.

I know Apple has a Core Data Concurrency guide, but I'm curious in which cases one is supposed to use Core Data in the background.

As a quick example, say I'm making a Twitter client and want to get all the tweet information (tweet text, username, user avatar, linked images, etc.). I asynchronously download that information and receive some JSON from the Twitter API that I then parse. Should I then do a dispatch_async(dispatch_get_main_queue()...) when I add the information to Core Data?

I also then want to download the user's avatar, but I want to do that separately from presenting the tweet, so I can present the tweet quickly as possible, then present the image when ready. So I asynchronously download the image. Should I then update that Core Data item asynchronously?

Am I in a situation where I don't need multi-threaded Core Data at all? If so, when would be a situation where I need it?

Answer 1

I've learned that generally, intensive tasks should take place on background threads, as if they're on the main thread they'll block user interaction and interface updates.

Does Core Data fall under that umbrella?

Yes, actually.

Core Data tasks can and should - where possible - be executed on background threads or on non-main queues.

It's important to note though, that each managed object is associated to a certain execution context (a thread or a dispatch queue). Accessing a managed object MUST be executed only from within this execution context. This association comes from the fact that each managed object is registered with a certain Managed Object Context, and this managed object context is associated to a certain execution context when it is created.

See also:

• [NSManagedObjectContext initWithConcurrencyType](),
• [NSManagedObjectContext performBlock]
• [NSManagedObjectContext performBlockAndWait]

Consequently, when displaying properties of managed objects, this involves UIKit, and since UIKit methods MUST be executed on the main thread, the managed object's context must be associated to the main thread or main queue.

Otherwise, Core Data and user code can access managed objects from arbitrary execution contexts, as long as this is the one to which the managed object is associated with.

The below picture is an Instrument Time Profile which shows quite clearly how Core Data tasks can be distributed on different threads:

The highlighted "spike" in the CPU activity shows a task which performs the following:

• Load 1000 JSON objects from origin (this is just a local JSON file),
• Create managed objects in batches of 100 on a private context
• Merge them into the Cora Data Stack main context
• Save the context (each batch)
• Finally, fetch all managed objects into the main context

As we can see, only 26.4% of the CPU load will be executed on the main thread.

Answer 2

As I alluded to in your other question, it's largely going to be a matter of how long the manipulations are going to take. If the computation required doesn't have a noticeable delay, by all means be lazy about and do your core data on the main thread.

In your other example, you're requesting 20 items from twitter, parsing 20 items and sticking them into CoreData isn't going to be noticeable. The best approach here is to probably continue to just fetch 20 at a time and update in the foreground as each chunk becomes available.

Downloading all items from twitter in one request will take a significant amount of time and computation and it's probably worth creating a separate ManagedObjectModel and synchronizing it with the foreground model. Since you really have one-way data (it always flows twitter->core data->user interface) the likelihood of clashes is minimal, so you can easily use NSManagedObjectContextDidSaveNotification and mergeChangesFromContextDidSaveNotification:

Answer 3

The best way to handle behavior like this is to use multiple NSManagedObjectContexts. The "main" context you create like so:

_mainManagedObjectContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSMainQueueConcurrencyType];
_mainManagedObjectContext.persistentStoreCoordinator = [self mainPersistentStoreCoordinator];

You're going to want to do any heavy writes on a different NSManagedObjectContext to avoid blocking your UI thread as you import (which can be quite noticeable on large or frequent operations to your Main context).

To achieve this, you would do something like this:

1. Retrieve your data asynchronously from the network
2. Spin up a temporary (or perhaps a permanent) background NSManagedObjectContext and set the "parent" to the main ManagedObjectContext (so it will merge the data you import when you save)
3. Use the performBlock: or performBlockAndWait: APIs to write to that context on its own private queue (in the background)

Example (uses AFNetworking):

[_apiClient GET:[NSString stringWithFormat:@"/mydata"]
     parameters:nil
        success:^(AFHTTPRequestOperation *operation, id responseObject) {

            NSError* jsonError;
            id jsonResponse = [NSJSONSerialization JSONObjectWithData:operation.responseData options:kNilOptions error:&jsonError];

            if (!jsonError) {
                NSArray* parsedData = (NSArray*)jsonResponse;
                completionBlock(parsedShares, nil);
            } else {
                NSManagedObjectContext *context = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
                context.parentContext = YOUR_MAIN_CONTEXT; // when you save this context, it will merge its changes into your main context!

                // the following code will occur in a background queue for you that CoreData manages
                [context performBlock:^{

                    // THIS IS WHERE YOU IMPORT YOUR DATA INTO CORE DATA
                    // THIS IS WHERE YOU IMPORT YOUR DATA INTO CORE DATA
                    // THIS IS WHERE YOU IMPORT YOUR DATA INTO CORE DATA

                    if (![context save:&saveError]) {
                        NSLog(@"Error saving context: %@", saveError);
                    } else {
                        NSLog(@"Saved data import in background!");
                    }
                }];
            }

        }
        failure:^(AFHTTPRequestOperation *operation, NSError *error) {
            NSLog(@"There was an error: %@", error)
        }];

Docs: https://developer.apple.com/library/mac/documentation/Cocoa/Reference/CoreDataFramework/Classes/NSManagedObjectContext_Class/NSManagedObjectContext.html#//apple_ref/occ/instm/NSManagedObjectContext/performBlockAndWait:

Answer 4

Core Data does indeed fall under that umbrella. Particularly for downloading and saving data, but also possibly for fetching depending on the number of objects in the data store and the predicate to be applied.

Generally, I'd push all object creation and saving which is coming from a server onto a background thread. I'd only update and save objects on the main thread if they're user generated (because it would only be one, updated slowly and infrequently).

Downloading your twitter data is a good example as there will potentially be a good amount of data to process. You should process and save the data on a background thread and save it up to the persistent store there. The persistent store should then merge the changes down to the main thread context for you (assuming you have the contexts configured nicely - use a 3rd party framework for that like MagicalRecord).

Again, for the avatar update, you're already on a background thread so you might as well stay there :-)

You might not need to use multiple threads now. If you only download the 5 most recent tweets then you might not notice the difference. But using a framework can make the multi-threading relatively easy. And using a fetched results controller can make knowing when the UI should be updated on the main thread very easy. So, it's worthwhile taking the time to understand the setup and using it.