First of all, sorry for the too long question.
I know that there are few questions here that discuss similar issues but none of these talks about NSFetchedResultsControl
Two separate questions here. First, if you are getting mutating errors that means you are mutating a set or array (or relationship) while iterating over that set/array/relationship. Find where you are doing that and stop doing it. That is the only solution.
As for your updates. Your background NSManagedObjectContext
should be saving periodically. Your main thread should be listening for NSManagedObjectContextDidSaveNotification
and when it receives one it calls the main NSManagedObjectContext
on the main thread (as the notification will most likely come in on the background thread) via -mergeChangesFromContextDidSaveNotification:
which takes the NSNotification
as a parameter. This will cause all of your NSFetchedResultController
instances to fire their delegate methods.
Simple as that.
ank you for your reply. The exception is thrown on updating the NSManagedObjectContext in the background thread. I use the same NSManagedObjectContext in both threads. The app should be as close as possible to real time app - the updates constantly and the tables should be updated immediately. I don't save at all - I only update the NSManagedObjectContext. I have seen in one of the questions mentioned that someone used to separate instances of NSManagedObjectContext but he still receive the same exceptions once he merges the changes. So, you suggest using 2 separate NSManagedObjectContext's?
First, read up on multi-threading in Core Data from Apple's documentation (or my book :).
Second, yes you should have one context per thread, that is one of the golden rules of Core Data and multi-threading (the other is don't pass NSManagedObject
instances across threads). That is probably the source of your crash and if it isn't it is going to be the source of a crash in the future.
I have tons of data and I update only the modified/new/deleted items in the table. If I will start saving then will it harm the performance?
No, only the updates will be propagated across the threads. The entire data store will not be re-read so it will actually improve performance when you break up the saves into smaller chunks because you will be on the main thread, updating the UI, in smaller chunks so the UI will appear to perform better.
However, worrying about performance before the app is completed is a pre-optimization that should be avoided. Guessing at what is going to perform well and what won't is generally a bad idea.