Learn Objective-C on the Mac - Mark Dalrymple [148]
Here, the fileAttributes accessor returns a dictionary, which it gets from fileWrapper. This dictionary contains a dozen or more filesystem attributes, and will be displayed in a table view in the GUI by using an NSDictionaryController.
Now we get into the somewhat hairier issue of string encodings. As we’ve mentioned earlier, NSString provides functionality for reading a string from a file and making a guess at which string encoding it should use. This may be right most of the time, but sometimes it can be useful to see the contents of a string through a different set of goggles, so to speak. It may be enlightening, for instance, to see how a modern UTF8 document may appear if viewed in an archaic application on some other platform that doesn’t have any concept of string encodings, and always uses the one and only string encoding available to it.
We start off by defining the encodingNames method. This method will provide a list of encoding names to the popup button in our GUI, and will also serve as an internal lookup mechanism for mapping between encoding names and their code-level representation, the NSStringEncoding type. For keys, this dictionary uses the numeric value of each encoding wrapped in an NSString. You might think that it would make more sense, given the numeric nature of these values, to wrap them in NSNumber objects instead, and you’d be right except for one small catch: if you’re using an NSDictionary in a key-value observer context, such as Cocoa Bindings, you have to use strings as keys! Because we’re using this dictionary to populate an object via Cocoa Bindings, that’s what we’re doing.
Continuing our efforts with string encodings, we’ll now define accessors for stringEncodingName, this time adding a setter into the mix (because this value will be settable from the popup button). As before, we implement keyPathsForValuesAffectingStringEncodingName, this time adding chosenEncoding as one of the keys to watch for.
The stringEncodingName method has two main execution paths. If chosenEncoding has been set (say, the user has picked an encoding from the popup list), we simply look up the name of the chosen encoding in the dictionary we defined earlier. Otherwise, we actually read the file’s contents with stringWithContentsOfFile:usedEncoding:error: and use the resulting encoding to look up the name of the discovered encoding (or return a brief problem description if no encoding could be discovered).
The setStringEncodingName: method is quite simple. We do a reverse lookup in the dictionary to find the key (a string containing the integer value of the encoding) corresponding to the chosen encoding. This method is called when the user selects an encoding name in the popup.
Finally, fileStringValue and its matching keyPathsForValuesAffectingFileStringValue method. Here we also have a couple of primary code paths. In the first case, where chosenEncoding has been set, we attempt to read a string value from the chosen file, using the chosen encoding. In the other case, where the no encoding has been chosen, we attempt to read a string value but let the system try to figure out which encoding to use. In either case, we do a bit of error checking, and show an alert panel if a particular string encoding error is encountered.
What About That File: The GUI
That’s all, as far as the code is concerned. Now let’s set up the GUI. Open up MainMenu.xib in Interface