• Choose a category
• All
• Classic-Fiction

By Root 978 0

view will show its values in the relevant text field. Unlike Chapter 5, where we showed you how to handle the table view in your own code, here we’re going to show you how to use the NSArrayController class, a generic controller class included with Cocoa, to manage the display of these table views with no custom code of your own, thanks to Cocoa Bindings. We’ll need to add a few outlets and other instance variables to our DungeonThingAppDelegate class, for three instances of NSArrayController and three arrays (one for each type of game object). We’ll also remove the NSTextField outlets, because those will also be configured with bindings to display their contents. Finally, we’ll change the action methods just slightly, to insert each created object into the relevant array. When we’re done, the source code will be almost identical in size, because all configuration of the table views is done right in the nib file.

Make the Code Bindings-Ready

Let’s start by making the necessary changes in the header file. In order to maintain lists of generated objects, our DungeonThingAppDelegate needs three new NSMutableArray instance variables, one for each kind of game object. Each array will be managed by an NSArrayController in the nib file, so we’ll also add three outlets to connect to those. We’ll also change the labels in the window, so that they access their content through the NSArrayControllers as well. This means that we can remove the three existing outlets to NSTextFields, because we never need to deal with them from the code now. Finally, we declare the three NSMutableArrays as properties, so that they are readily available for the NSArrayControllers to access them. The changes you need to make in DungeonThingAppDelegate.h are shown below. Note that in addition to adding the lines shown in bold, you should delete the old outlet declarations pointing at NSTextFields.

THE CANONICAL INIT METHOD

The preceding code snippet shows an example of an init method that creates values for our class’s instance variables. The form of this init method is fairly standard, and you’re likely to see something similar in most Objective-C classes you see, but it does some things that seem strange at first glance, and is worth explaining a bit. The method starts off with this peculiar if statement:

That if-statement is really killing two (or more) birds with one stone. First, it’s calling the superclass’s implementation of init, and assigning its return value to the special variable self. Then it checks the value of the assignment itself (that is, the value of self after it’s been assigned), and only executes the following block of code if it’s not something that evaluates as false, e.g. a nil pointer value.

This usage of self, assigning a value to it, is really unusual. In fact, the only time you’re ever likely to see code assigning a value to self is within an init method such as this. The reason for doing it this way is to allow for the possibility, however slight, that the superclass’s init method will return a different value than what was pointed at by self from the outset. On the one hand, the superclass may find that it fails to initialize itself properly for some reason, and signal this by returning nil from the init method, which is the “standard” way of dealing with an object initialization failure (rather than, say, raising an exception). In this case, the class will notice the nil value, and skip the block following the if statement, dropping down to the end where it returns the value pointed at by self, which is now nil.

The other possible alternate return value for the superclass’s init method is a different instance altogether. The idea is that the superclass might have a smart scheme for recycling objects in a private pool instead of constantly deallocating and creating new ones, and a part of that scheme would be that the init method would sometimes return an old, second-hand object instead of the shiny new one you just tried to create. The question of whether or not this situation is a realistic one is