UIManagedDocument parent context object insertion on a background priority queue not updating in UI using child context

Question

I'm trying to implement some basic UIManagedDocument import/export functionality into my app, mainly for dev so that I can easily inspect the document contents and more crucially preserve a set of test data when I start trying to iterate on my CoreData models.

All I am trying to do is load some JSON data from a local file and inject it into my apps UIManagedDocument. The UIManagedDocument's ManagedObjectContext contents are visualised in my app using some Core Data Table View Controllers from the Stanford iOS courses.

I thought I'd try to write this with some threading to keep the UI responsive and to learn how to do it. So I've done something like this

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0), ^{
  // read JSON data file
  // parse JSON into dictionaries etc
  // iterate over dictionaries
  // try to create a new core data entity with my document's ManagedObjectContext
} );

At first I thought this was working. No errors, asserts, crashes triggered and upon looking at my CoreData TableViews I could see the newly added objects in my UI. Unfortunately the newly added objects were seemingly never saved back to the store. I even hooked up to listen to the NSManagedObjectContextDidSaveNotification from my UIDocument's managedObjectContext and saw it wasn't triggering on pressing the home button, like it usually does if it has some changes performed in the app with my UI pending. Infact even doing these operations in the UI wouldn't cause the notification and saving to occur so it was clearly not happy.

I unrolled the code from within the background queue and ran it on the main thread synchronously and everything worked ok, the new data was saved correctly.

I started reading about the complexities of threading and coredata, the documentation seemed to suggest using the UIDocument's ManagedObjectContext's parent ManagedObjectContext to perform operations on in the background so I tried doing the same code again using this parent context, so as follows

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0), ^{
  // read JSON data file
  // parse JSON into dictionaries etc
  // iterate over dictionaries
  // try to create a new core data entity with my document's ManagedObjectContext parent ManagedObjectContext
} );

This time for some reason the CoreData TableView controllers no longer updated to show the newly injected objects. Even after explicitly calling save on the parent context, nothing appeared. However on quitting the app and reloading the app the newly injected objects did seem to be added correctly. Interestingly at this point i'd left a fetchrequest with a cachename specified and that threw up an error on this first run of the app after injecting the objects this way. I guess somehow the way the object had come from the parent context directly perhaps invalidated the cache somehow, that's still something I don't fully understand. Even changing the cache to nil didn't fix the issue of the table views not updated the same session as when the objects were injected into the parent context.

Looking elsewhere I've seen some uses of the managedObjectContext performBlock suggested. Another case where someone has said you must call

[document updateChangeCount:UIDocumentChangeDone]

after all changes to ensure the saving is performed, or perhaps using

- (void)autosaveWithCompletionHandler:(void (^)(BOOL success))completionHandler

instead. Though elsewhere I've seen mentioned that saving should be enough to push context contents through the hierarchy. Does saving only work from child -> parent and not from parent -> child.

Or am I just doing it wrong?

Anyone's time and help is really appreciated! Cheers.

score 0 · Answer 1 · answered Jun 19 '14 at 12:38

please look at the 'Parent/Child Contexts' section in the Multi-Context CoreData.

Whenever a child MOC saves the parent learns about these changes and this causes the fetched results controllers to be informed about these changes as well. This does not yet persist the data however, since the background MOCs don’t know about the PSC. To get the data to disk you need an additional saveContext: on the main queue MOC.

I do saving to the PSC n following way:

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0), ^{
{
    // read JSON data file
    // parse JSON into dictionaries etc
    // iterate over dictionaries

    NSError* error;
    if (self.managedObjectContext.hasChanges)
    {
        [self.managedObjectContext save: &error];
    }

    // Save main context
    dispatch_sync(dispatch_get_main_queue(), ^
    {
        [[AXContextHelper sharedInstance] saveMainContext];
    });
}

Thanks for your answer. I've just skimmed over it as I'm at work, the only thing I wonder about is it seems to be all about MOCs that aren't associated with UIManagedDocuments (which mine are). I found another question here - http://stackoverflow.com/questions/11350670/uimanageddocument-with-nsfetchedresultscontroller-and-background-context with a comment "Apple does not support context -save: when using a managed document. Perhaps after obtaining the permanent ids you should call [document updateChangeCount:UIDocumentChangeDone]" Maybe UIManagedDocuments complicate things further? — jimbobuk, Jun 19 '14 at 14:09

score 0 · Accepted Answer · answered Jun 20 '14 at 08:30

After looking into all the suggestions I could find for similar problems, none of them seemed to help.

The scenario i was describing in the end had the store stuff to file handled ok, but the UI not updating. At the time when I do this import/export I'm in a view ontop of the core data table view controller that doesn't update when I inject all these JSON objects, so in the end all I did was force that controller to re-fetch it's data. I believe the NSFetchedResultsController is meant to monitor the managedObjectContext and update the fetch request as required. For whatever reason, this wasn't working.

With the force re-fetch called, everything seems to work ok. The newly injected entities appear in my tables, and are saved to the store files.

Either there are some bugs in these objects, or I'm still using it wrong but I see other problems... my import/export data both work now on background threads with the parent context. What I've noticed today is that I can use the UI to properly insert and edit some objects using the child context on the main thread. I don't deliberately call anything at the moment after making these edits so i guess the edits are are still pending till core data decides to save. If i then go to my export feature and use it using the parent context then i find the newly edited or inserted objects aren't there.

Clearly there's no messaging happening in time from child -> parent, and messaging from background thread edits on the the parent itself just doesn't seem to work.. I never get any notifications for the edits i perform in a thread on the parent context, even though they seem to work. If I force the save to happen via the documents then the passed in dictionaries show no edits being made, even though the edits are saved correctly to store files somehow.

I guess i now need to force my document to save after every operation, or at least before every operation i'm about to do on another thread to ensure the parent/child are both in sync.

Still the problem I originally described I've managed to get around, but I'm still left wondering quite how I should be using the parent and child context of a UIManagedDocument to avoid encountering these issues.

UIManagedDocument parent context object insertion on a background priority queue not updating in UI using child context

2 Answers2