Learn Objective-C on the Mac - Mark Dalrymple [147]
Each of the classes mentioned here also contains a method called writeToFile:atomically: whose second parameter is a BOOL specifying whether the data should first be written to an auxiliary file, which then replaces the original after all data is written. The NSString version of this method is actually deprecated, and you’re encouraged to use writeToFile:atomically:encoding:error: instead, which forces you to specify which text encoding to use, and gives you the chance to inspect any errors that may occur. NSData provides the similar writeToFile:options:error:, which also gives you a chance to see any errors that occur when writing to a file.
High-level File Operations
Besides the basics of reading and writing files, Cocoa provides a number of classes that let you deal with files in ways similar to how the Finder deals with files. You can get access to file-system attributes, get the file’s icon, see which application will open this file by default, and more. The rest of this chapter will explore some of these capabilities in the context of a new application called “What About That File?” (see Figure 15-1).
This application lets the user choose a file, at which point some information about the file is shown, as well as the file’s contents in the form of a string. If the file contains data that can’t be represented as a character string, it will tell the user so. Otherwise, the user can use an included popup list to change the text encoding that is used when reading the file from disk, and show the resulting string.
Figure 15-1. The completed “What About That File?” application
What About That File: The Code
Start in Xcode. Make a new Cocoa application (no Document support or Core Data this time) named WhatAboutThatFile, and do the usual steps of enabling garbage collection and creating a WhatAboutThatFileAppDelegate class if Xcode didn’t create one for you. In previous chapters, we’ve assembled applications one step at a time, but now that we’re this far along, we think you’re ready to take on bigger chunks of application code. So this time, what we’re going to do to is present the complete code of the application, with some commentary interspersed, and then describe how to wire up everything in Interface Builder using Cocoa Bindings. For starters, here’s the header file of our app delegate, which declares a few instance variables and a larger number of properties, used for accessing values through Cocoa Bindings:
Now let’s move on to the .m file:
The chooseFile: method uses the NSOpenPanel class to ask the user to choose a file to inspect. If the user actually picks a file, we set all of our instance variables based on the selection. chosenEncoding, a variable of type NSStringEncoding (which is at heart simply an unsigned integer) is set to 0, which is not a valid string encoding type, so that at a later stage we can let the system try to deduce the string encoding type for us. After that, we set filePath based on the selection in the open panel, and finally set fileWrapper, which is an instance of the NSFileWrapper class, which simply wraps a file and lets us get some metadata about it, based on the value of filePath.
Next, we have the filename and fileIcon methods, which will be read by the uppermost GUI objects in our window. Note that this reading occurs via Cocoa Bindings, so we use the convention of providing class methods named keyPathsForValuesAffectingFilename and keyPathsForValuesAffectingFileIcon, in order to ensure that changes made to one bindings-friendly value cause another value to be re-fetched. We last used this in the context of a Core Data model class, but it works equally well here, ensuring that any time the filePath or fileWrapper values are changed, any views binding their content to filename or fileIcon will automatically reload their content. Both the filename and fileIcon methods use the previously-created fileWrapper to access the values for display.
We provide similar functionality in order to display info about the application that will