• Choose a category
• All
• Classic-Fiction

By Root 861 0

automatic document saving, your users will no longer need to be concerned with manually saving their documents. By monitoring the change count (described later), Cocoa will cue your document to archive itself at appropriate times. When the user does manually save the document, a new version will be created. The user can then browse past versions by using an interface similar to Time Machine. Untitled documents (documents not explicitly saved by the user) will even be preserved between runs of your application.

In order to support automatic document saving, your NSDocument subclass must opt in by overriding the class method autosavesInPlace to return YES:

+ (BOOL)autosavesInPlace {

return YES;

}

If your document saves its data quickly, opting in is probably an easy choice. Otherwise, autosaving in place may not be appropriate for your application, as it will cause the interface to block until the save is completed. Refer to Apple’s Mac OS X Application Programming Guide for a more in-depth discussion.

The Cocoa application template in Xcode enables this feature; NSDocument’s implementation of this method returns NO.

For the More Curious: Document-Based Applications without Undo

The NSUndoManager for your application knows when unsaved edits have occurred. Also, the window is automatically marked as edited. But what if you’ve written an application and are not registering your changes with the undo manager?

NSDocument keeps track of how many changes have been made. It has a method for this purpose:

- (void)updateChangeCount:(NSDocumentChangeType)change;

The NSDocumentChangeType can be one of the following: NSChangeDone, NSChangeUndone, or NSChangeCleared. NSChangeDone increments the change count, NSChangeUndone decrements the change count, and NSChangeCleared sets the change count to 0. The window is marked as dirty unless the change count is 0.

Universal Type Identifiers

One of the enduring problems in working with computers is embodied in the question: What does this data represent? On the Mac, this question gets asked in several places: when a file is opened from the Finder, when data is copied off the pasteboard, when a file is indexed by Spotlight, and when a file is viewed through Quicklook. Thus far, there have been several anwers: file extensions, creator codes, MIME types.

Apple has decided that the long-term solution to the problem is universal type identifiers (UTIs). A UTI is a string that identifies the type of data. This data may be in a file or in a memory buffer. UTIs are organized hierarchically. For example, the UTI public.image conforms to public.data.

Your application tells Mac OS X what UTIs your application can read and write, including new, custom UTI, by setting values in its Info.plist. The Info.plist is an XML file that has a dictionary of key-value pairs. Exported UTIs are stored in the key UTExportedTypeDeclarations. The steps you followed earlier to add an exported UTI created this key. The pasteboard, which we will cover in Chapter 21, also uses UTIs to identify data types.

There is a large set of system-defined UTIs. You can find the entire list in Apple’s documentation.

Chapter 11. Basic Core Data

At this point, you’ve implemented an application that keeps track of an array of objects, takes care of undo, and handles saving and loading from a file. As you can imagine, there are an awful lot of applications like the one you just wrote.

Apple decided to make this type of application extremely easy to write:

• NSArrayController will hold on to an array of objects.

• Bindings will eliminate much of the glue code that would be necessary to keep the model objects in sync with the views.

• NSManagedObjectContext will observe the instance variables of your data objects and will take care of undo for you and loading and saving the data.

So, the punchline is: Using Core Data and bindings, the RaiseMan application that you have written can be created with no code at all. In this section, you are going to write a simple