Is it OK to use multiple NSUndoManagers with one Core-Data managedObjectContext?

//Edit: Really, nobo开发者_开发知识库dy has any suggestions or thoughts on this? Have I asked the question wrongly somehow?//

My iPhone app has a single managedObjectContext with a moderately complicated data model. I'm now adding undo functionality, and am not clear on how best to handle nested viewControllers (as each layer might modify the data model).

Apple's docs point out: "Consider an application that displays a list of books, and allows you to navigate to a detail view that in turn allows you to edit individual properties of the book (such as its title, author, and copyright date). You might create a new book from the list screen, navigate between two other screens to edit its properties, then navigate back to the original list. It might seem peculiar if an undo operation in the list view undid a change to the author’s name that was made two screens away rather than deleting the entire book."

So what's the best way to implement this? Currently, I'm thinking to have each viewController keep its own undoManager, which would be active whenever it's on the screen. So my understanding is that this would require the following steps (for each VC):

• Add a property: myUndoManager
• Add an undoManager method returning myManagedObjectContext.undoManager;
• In viewDidAppear: myManagedObjectContext.undoManager = myUndoManager; //create first if nil
• In viewWillDisappear: myManagedObjectContext.undoManager = nil;
• On memory warning: [self.undoManager removeAllActions ];
• On dealloc: self.myUndoManager = nil;
• For each model change: [self.undoManager setActionName:NSLocalizedString(@“XXX”,@“”)];
• CoreData will handle the actual undo/redo postings

In addition, I have to remain firstResponder:

• In viewDidAppear: `[self becomeFirstResponder]'
• Add canBecomeFirstResponder method returning YES
• In viewWillDisappear: [self resignFirstResponder];
• Re-enable firstResponder upon subViews resign (e.g. textFields)

So far, that seems like it works, even across load/unload cycles, and is nicely self-contained, but I have several questions:

• First, is this the best practice for implementing undo across multiple VCs?
• Will I get in trouble with my child VCs not doing their undos prior to my doing my earlier ones?
• If so, does that list capture everything I need to do?
• Will ManagedObjectContext get confused with multiple UndoManagers being active?
• Do I need to call ProcessPendingActions before swapping undoManagers?

I would work very hard to have only one undo manager.
consider the scenario:

model: (chicken)
properties: eggs, color, size;

model: (egg)
properties: chicken, color;

chicken.eggs = one to many relationship to egg, inverse is true of egg.chicken.

you create 2 undo managers one for chickenViewController, and one for eggViewController.
you create chicken0 and its eggs: egg0, egg1.
you create chicken1 and its eggs: egg2, egg3.
you delete egg2.

now you delete chicken1 cascade deleting the eggs.
now you go back to eggViewController and undo... what do you want to happen (exception would happen).
now you undo chickenViewController and chicken1 and it's eggs come back, but are there 2 egg2's?

Edit I am softening my tone on this a little, assuming that you are using a hierarchical view structure, like UINavigationController, and you make a new Undo controller each time that you go to a child view, I don't thing you should have a problem.

Each view controller can have its own undo manager. A controller should only be responsible for the fields that it directly changes. Once you back out of the corresponding view, the controller should be released and the undo manager with it.

Let's say you have 3 levels. Level 1 represents the entire record, level 2 represents a subset of data from level 1, and level 3 represents a subset of data from level 2.

Once you back out of level 3, you've basically said I accept and you shouldn't need to undo any of that data in level 2. This changed data should only show up as read-only data in level 2 if it shows at all. Similarly, once you back out of level 2, you should release its undo manager.

Back in level 1, since it represents the entire record, why not have a Cancel button instead of trying to undo (or in addition to, depending on what your level 1 controller does)?

Then, if you want to cancel the entire operations you can send a message like the following to your managed object context:

[myMOC refreshObject:theEditedObject mergeChanges:NO];

This will effectively roll back the entire record.

If, for whatever reason, you decide to keep level 3's undo manager around while you're in level 2 and you do a rollback at level 2, only the data pertaining to level 2's undo manager would be rolled back. Level 3's undo manager is separate and Core Data does not see the undo managers as nested.

A managed object context can't get confused due to multiple undo managers because it can only keep track of one at a time via its setUndoManager: method.

You probably won't need to use processPendingChanges unless somehow a rollback is taking place before the completion of the event loop after a change has been made. I wouldn't worry about this unless your undo only restores some of the data that is supposed to be recorded with the undo manager up to that point.

It sounds like you want to take a bunch of undos into one lump so they can be all undone as a group. This is accomplished with beginUndoGrouping and endUndoGrouping. Is there some reason that you can't use that? I'm not sure if you can undo one step in the middle of a group, so that would be a problem.