Learn Objective-C on the Mac - Mark Dalrymple [79]
This code is pretty straightforward, and is probably nothing you’ll ever pay much attention to, except perhaps to customize the error reporting.
An NSWindow Delegate Method
Next up is an NSWindow delegate method called windowWillReturnUndoManager:
This method lets us specify the object that handles undo/redo actions for the window containing our GUI. We’ll discuss the undo/redo system in Chapter 11, but for now all you need to know is that this method tells the system to use Core Data’s undo manager, which is accessed through the managed object context.
The saveAction: Action Method
Next up, the saveAction: method, which is called when the user clicks the relevant menu item. As before, the note about different versions of code generated by different versions of Mac OS X and Xcode applies here as well. This is the Snow Leopard version; the Leopard version may be slightly different.
This method is pretty straightforward. It first tells the context to ensure that any pending edits are committed to the underlying model objects, and prints a warning in case the commit fails. Whether the commit succeeds or fails, it then proceeds to tell the context to save all model objects to storage. If that fails, it shows the user an error.
An NSApplication Delegate Method
Now we come to this class’s longest method, the NSApplication delegate method applicationShouldTerminate:. This method is called by the application when the user selects Quit from the menu, and gives the delegate a chance to save changes, inspect its state, ask the user if they really want to quit, and so on. The value returned by this method determines whether the application will really terminate or not. Here’s the code:
First it checks to see whether there really is a managedObjectContext to worry about. If not, it just returns NSTerminateNow immediately, and the application terminates. Then, it tells the context to commit any pending changes. If that fails, it logs an error message and returns NSTerminateCancel, which makes the application abort the current termination procedure and just continue about its business. Then, it checks to see whether the managedObjectContext actually has any pending changes, and if it doesn’t, it returns NSTerminateNow.
Finally, it does the big step of telling the context to save its changes. If the save fails, then the final big conditional block is triggered. That block constructs an NSAlert, a special type of window that appears in front of all other application windows and forces you to make a choice by clicking a button (you’ll learn more about NSAlert and other windows in Chapter 10). In this case, it’s telling the user that their changes were not saved, and asking them to choose whether to quit the app anyway, or cancel the termination and go back to normal. Depending on the return value from this request, it either returns NSTerminateCancel, or “falls through” and returns NSTerminateNow.
Time to point out a small bug in this method: near the end, when the method checks to see if the Cancel button was pressed, it’s actually comparing answer to the wrong value. It should be NSAlertSecondButtonReturn instead of NSAlertAlternateReturn. Not such a big deal perhaps, but this error in the logic makes it impossible to avoid quitting when the app is in a particular invalidate state. Oops!
One interesting thing to note is the use of NSLocalizedString in this method. NSLocalizedString is a simple way to let your code use localized resources if present. It’s a C function that takes two arguments: a default string and a key used for looking up a localized string. For instance, in a call like NSLocalizedString(@“Cancel”, @“Cancel button title”), NSLocalizedString will first check to see which language the user prefers, then check to see if there exists a localized string for that language, keyed off @“Cancel button