What's the standard way to handle canceling an edit while on an item detail display screen?

Question

I'm currently working on an application which keeps tracks of cats and their associated cheeseburgers. I'm backing the application with Core Data. There is a one-to-many relationship between a cat and its cheeseburgers (a cat is allowed to have zero or more cheeseburgers).

I have a UITableViewController which displays all of the cats by name (last name, first name). When you click on a row in the table, a new UITableViewController is pushed onto the navigation controller which displays all of the information about the cat. For what its worth, the table view is grouped with the first second containing information about the cat (first/last name, color, etc). Then in a second section, all the cheese burgers the cat has are described.

The right navigation item is the edit button. When the user is in edit mode, I'm hiding the navigation bar's back button, replacing it with a cancel button.

My question is this: Is there a standard / common practice / etc on how to handle managing the data in the edit screen? I see it happening one of two ways:

1. Keep track of all the things the user changes and then when they hit the done button, copy those changes to the Cat NSManagedObject.
2. Use an NSUndoManager associated with the NSManagedObjectContext and when the user begins editing, create a new undo grouping. When they tap the cancel button, just end the grouping and then perform an undo on the NSUndoManager.

I feel like option 2 seems most practical, but I have mixed feelings about it. For the iPhone, the NSManagedObjectContext does not by default have an NSUndoManager associated with it - I've read that it does for OSX applications. I also don't see much discussion about using the NSManagedObjectContext in relation to iPhone programming while doing reading on the net. This makes me feel that people may be using another method I haven't thought of.

Answer 1

A more common iPhone app workflow is to not have a 'Cancel' button at all. Most apps just morph the Edit button into a Done button. Only consider Cancel when the information potentially lost is hard to reproduce.

However, if you want a Cancel button, the first option seems more streamlined. Apply changed on Done. In any other case, just discard the transitory changes data. Do the latter not only on Cancel, but also if the app has to terminate. Only accept the changes with explicit Done.