Re: Core Data - Importing using NSOperation - Problems on main thread
Re: Core Data - Importing using NSOperation - Problems on main thread
- Subject: Re: Core Data - Importing using NSOperation - Problems on main thread
- From: Nick Banks <email@hidden>
- Date: Sun, 20 Dec 2009 18:16:00 +0100
Thanks Greg,
Yes I did use the [managedObjectContext save:&error], in the same fashion as in some of the examples provided by Apple. Interestingly, I am using the same mechanism in a completely unrelated project with no problems, and have studied the Core Data documentation for some time.
If I delete an object in the import moc (moc2) will that immediately cause the object in moc1 to be deleted also (thus causing problems when referenced by the UI i.e. it will no longer exist) or will this only happen when I call [managedObjectContext save:&error]?
Regards,
Nick
On 20 Dec 2009, at 17:01, Greg Reichow wrote:
>
>> Hi,
>>
>> I have an application that persists its data using core data.
>>
>> It uses an NSOperation to download new versions of the data asynchronously. This NSOperation uses its own MOC (moc2) (as opposed to the MOC (moc1) used in the main thread, which is used by the UI). Both MOCs share the same persistent store which, as I understand it, this is the paradigm recommended by Apple (for using Core with multiple threads).
>>
>> My problem occurs when the NSOperation is almost complete and deletes all the old Managed Objects (that have been replaced by the new data) performs a [managedObjectContext save:&error] with the intent of making the new data available in the other MOC (moc1).
>>
>> The old data is deleted using [managedObjectContext deleteObject:objectToDelete] after the new data has been added.
>>
>> At the same point in time as the update is taking place, the user may be scrolling through the data in a UITableView (using custom cells populated with data from managed objects in the main thread MOC moc1)). The heavy lifting is performed by a NSFetchedResultsController - using code similar to that in the Apple CoreDataBooks example
>>
>> There are a number of problems with this approach If the user happens to select the view causing the fetched results controller to be initialised
>>
>> i.e. [self.fetchedResultsController performFetch: &error]
>>
>> whilst the NSOperation is deleting the old Managed Objects, and attempts to scroll an exception is thrown in cellForRowAtIndexPath (as the object that it is referring to has just been deleted)
>>
>> Problems also occur in the fetched results controller delegate methods, where the didChangeObject methods gets called with NSFetchedResultsChangeUpdate instead of NSFetchedResultsChangeDelete if the user is scrolling up and down the list at the same time (though everything works if the user is not scrolling).
>>
>> Any ideas on how I can avoid these problems, or come up with a more elegant solution?
>>
>
> Are you using the contextDidSaveNotification to pass the updates to the main thread MOC? This has worked for me in the exact same case you describe above.
>
> In your NSOperation, you register for the contextDidSaveNotification (for your moc2), which calls a method in the NSOperation when it is received that then passes back the notification data to a method on the main thread (using performSelectorOnMainThread). This keeps both MOC's in sync. I think this is documented in the Core Data docs.
>
> Greg
Nick Banks
Managing Director
Synchromation Ltd.
www.synchromation.com
Office: +33 9 62 60 47 88 (FR)
SkypeIn: +44 20 7193 6114 (UK)
iPhone: +33 6 45 44 54 93 (FR)
iPhone: +44 7763 839 430 (UK)
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden