Learn Objective-C on the Mac - Mark Dalrymple [44]
Of course in our contrived example, we could choose to follow the “simpler” route. We could just take the NSArray creation code and plop that into our code wherever we need to see the list of motivations! However, in the long run, doing things the “simple” way often backfires, and ends up not being simple at all. Remember that the systems we build may grow and be extended in the future, in ways we can’t always anticipate today. Doing things the “right” way is a good way to future-proof your code, so that someone looking through the code later on (for example, trying to find where to add to the list of motivations) can figure out what’s happening and find the one spot they need to change, instead of doing a manual search and replace to find every spot where an identical array is being created.
With our motivations method in place, we’ll now be able to harvest from it an index number to identify the tag of the cell we want to select in the GUI. Here’s one way to do this, ready to be added to the end of updateDetailViews:
Okay, we realize that looks like a bit of a mess if you’re not used to it, and may give some of you flashbacks to the Lisp or Scheme you had to learn in your computer science education and have spent years trying to forget (These feelings are normal, and will subside over time). For the sake of clarity, we’re going to unpack this a bit and show you an alternate version of the above, where some intermediate values are assigned to variables.
Pretty straightforward, so you may wonder why we showed you the first version, where everything is all packed together. Basically, the first version is a kind of Objective-C code that you’re likely to encounter in the wild at some point, so it’s good to be able to try to eyeball it a little. Not because it’s technically superior in some way (it’s not), but simply because some people consider the highly nested version to be more readable in some ways, and just prefer to write their code that way. The position of the brackets, combined with features of Xcode’s text editor, lets you easily do some things with the former version that take a bit more time with the latter. For example, double-clicking on a bracket in Xcode selects the entire bracketed expression, including the brackets themselves, which means you can easily select an entire method invocation, including the receiver, the method name, and all arguments, in a single double-click. This can be a huge help both when editing code and also browsing/reading code.
On the other hand, the second form we showed you can be helpful when debugging your application. Just set a breakpoint, and you’ve got a full complement of intermediate variables ready to divulge their contents to you. Ultimately, which style you lean toward is a matter of personal taste and practicality. Use whatever works best for you in the situation at hand. Until you’ve gotten a bit more Cocoa experience under your belt, you’re probably better off sticking with the latter style, which shows more clearly the sequence of execution. For now, either of the alternatives shown above should work at the end of the updateDetailViews method. Compile and run, and verify that the correct primary motivation, “Revenge,” is shown in the GUI.
Finally, it’s time to display the powers attribute. Like the primaryMotivation, the villain’s powers are shown in a matrix of button cells. This time, however, the button cells are checkboxes, and any number of them can be selected (or “checked”). Instead of a single string, the powers attribute is an NSArray containing all the relevant strings for the villain we’re looking at.
We’ll start off with something very similar to what we added for the primaryMotivation attribute: a new class method called powers:
Like the motivations method, this method creates an array of strings whose indexes in the array correspond to the tags defined in a matrix in the nib file. Now we just have to add a bit of code to selectively “check” all the appropriate checkboxes. Add this code to the end