• Choose a category
• All
• Classic-Fiction

Rinse, Repeat, Rinse, Repeat

Now that we’re dealing with characters entirely with bindings, we can go back and do the same things for monsters and dungeons. Create a new NSArrayController by duplicating the “characters” array controller (thereby keeping its existing configuration, including the key names we already entered), name it “monsters,” connect DungeonThingAppDelegate’s monsterArrayController outlet to it, configure its Content Array binding to connect to the “monsters” attribute in DungeonThingAppDelegate, and configure the two relevant GUI objects (the table column and the text field) through the “monsters” array controller, all as described previously. Build and run the app and make sure it’s all working, then repeat all this once more for dungeons.

Okay, But How Did That Work?

Now that you’ve gotten your feet wet with Cocoa Bindings, you may have the distinct feeling that you’ve just witnessed some sort of magic show, and find yourself wondering how the tricks actually work! That’s a completely understandable feeling. We programmers are accustomed to being required to spell out every movement of a chunk of data and every update to the screen in excruciating detail, and suddenly we find that simply setting a value somewhere causes some unseen forces to propagate the value to other views on the screen. This section will attempt to clarify the process for you, by explaining the Cocoa concepts of Key-Value Coding and Key-Value Observing, and how Cocoa Bindings uses these to do its magic.

Key-Value Coding

First let’s talk about Key-Value Coding. The idea behind KVC is to allow us to refer to an object’s attributes by using strings that match attribute names, or that match the names of some getter and setter methods. Say, for instance, that you have a class called Person, which has the concept of a firstName, either in the form of an instance variable called firstName, or a pair of methods called firstName and setFirstName:. Using KVC, you can access a person’s firstName attribute using the following incantation:

Given the key name firstName, this method call first checks to see whether the object has a method called setFirstName:, and if so, invokes it to set the value. If that doesn’t work, it checks to see if there’s an instance variable called firstName, and tries to set it directly.

You can also retrieve a value in a similar manner:

A similar sequence occurs in this case. It first looks for a method called firstName, and if there isn’t one, it tries to find an instance variable with the same name.

The result of all this is that KVC gives us a way to talk about an object’s attributes in an extremely generic fashion. Not only is the object’s storage of its attributes transparent to us, even the way to access an attribute from the outside is something that we don’t need to worry about. It could change, perhaps even inside a running a program, and we wouldn’t notice the difference.

The setValue: forKey: and valueForKey: methods are defined in NSObject (with some additional extensions for collection classes like NSArray and NSSet) to try to determine, on the fly, the best way to access the value, based on the name of the key. This means that they are ready to use on every class in Cocoa.

One additional point to make about KVC is that the strings used as keys can actually be used as a sort of path, to traverse relationships between objects. For example, let’s imagine that our Person class also contains a property called mother, which is a pointer to another Person. If you want to set the firstName of myPerson’s mother, in normal code you would likely do it one of these ways:

The KVC methods are smart enough to look at the key string, split it apart by paths, and traverse any object relationships mentioned in the path, so the previous line ends up calling something like this:

While neither of the KVC options are really appealing for regular use in your own code (because the “normal” versions all read a bit more nicely), it can be used to great