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

Question

//Edit: Really, nobody 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?

Answer 1

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.