The Undo Interface
We must now decide how to let the user request Undo and Redo. In developing the code from the preceding section, I used two buttons: an Undo button that sent undo to the NSUndoManager, and a Redo button that sent redo to the NSUndoManager. This can be a perfectly reasonable interface, but let’s talk about some others.
By default, your application supports shake-to-edit. This means the user can shake the device to bring up an undo/redo interface. We discussed this briefly in Chapter 35. If you don’t turn off this feature by setting the shared UIApplication’s applicationSupportsShakeToEdit property to NO, then when the user shakes the device, the framework walks up the responder chain, starting with the first responder, looking for a responder whose inherited undoManager property returns an actual NSUndoManager instance. If it finds one, it puts up the undo/redo interface, allowing the user to communicate with that NSUndoManager.
You will recall what it takes for a UIResponder to be first responder in this sense: it must return YES from canBecomeFirstResponder, and it must actually be made first responder through a call to becomeFirstResponder. Let’s make MyView satisfy these requirements. For example, we might call becomeFirstResponder at the end of dragging:, like this:
- (BOOL) canBecomeFirstResponder { return YES; } - (void) dragging: (UIPanGestureRecognizer*) p { // ... the rest as before ... if (p.state == UIGestureRecognizerStateEnded || p.state == UIGestureRecognizerStateCancelled) ...Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access