Re: Undo in conjunction with core data
Re: Undo in conjunction with core data
- Subject: Re: Undo in conjunction with core data
- From: Dave Fernandes <email@hidden>
- Date: Sat, 22 Jan 2011 21:45:34 -0500
On 2011-01-22, at 8:34 PM, Kenneth Baxter wrote:
> Thanks Dave. I am now trying to use an array controller. I have set up the array controller and an observer on arrangedObjects, and that gets called during my addition and removal of children, but the change kind is always 1, and there is never anything in the old or new value arrays, so nothing beyond this knows whether it was an insertion or a deletion. I'm not sure exactly how much use that is in managing my other objects.
Looking back at my code, I see that I just use the KVO message to know that something changed. I then re-traverse the data model to update the view. (Not the most scalable technique.)
> The other things that need to remain in sync during undo and redo are not other nodes - they are some things that are managed at the view and controller layers of the application. I have some background threads that are processing data and need to know when a node is removed, and I have a mapping between the data and a number of front end objects and views, some of which may be animating at the time, as well as an intermediate model layer, and if any of those objects try to access the core data objects when they have been deleted, then all hell breaks loose. Therefore I have been sending notifications before the nodes are removed so that the processing thread can pick up on that and remove the node from the ones it is working on, and the animations can have their connections to the back end and other related objects cleaned up nicely. I don't know how else to accomplish a nice tidy up, since the animations and processing are using other threads, and may try to access the deleted node.
If your background thread can copy the necessary data, then it doesn't have to worry about it disappearing. My understanding is that accessing a potentially changing MOC from another thread is problematic at best. See Ben Trumbull's posts on this topic. Ex. March 16, 2007
Re: Core Data & threads [re: Ping: Look for hints for "nested transaction" problem with Core Data]
The usual pattern seems to be to have a separate MOC for the background thread and echo changes to it when the MOC in the main thread changes (NSManagedObjectContextObjectsDidChangeNotification).
_______________________________________________
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