• Choose a category
• All
• Classic-Fiction

@synthesize fido = _fido;

For the More Curious: Key Paths

Objects are often arranged in a network. For example, a person might have a spouse who has a scooter that has a model name (Figure 7.6).

Figure 7.6. Objects Are a Directed Graph

To get the selected person’s spouse’s scooter’s model name, you can use a key path:

NSString *mn;

mn = [selectedPerson valueForKeyPath:@"spouse.scooter.modelName"];

We’d say that spouse and scooter are relationships of the Person class and that modelName is an attribute of the Scooter class.

There are also operators that you can include in key paths. For example, if you have an array of Person objects, you could get their average expectedRaise by using key paths:

NSNumber *theAverage;

theAverage = [employees valueForKeyPath:@"@avg.expectedRaise"];

Here are some commonly used operators:

@avg

@count

@max

@min

@sum

Now that you know about key paths, we can discuss how to create bindings programmatically. If you had a text field in which you wanted to show the average expected raise of the arranged objects of an array controller, you could create a binding like this:

[textField bind:@"value"

toObject:employeeController

withKeyPath:@"arrangedObjects.@avg.expectedRaise"

options:nil];

Of course, it is usually easier to create a binding in Interface Builder.

Use the unbind: method to remove the binding:

[textField unbind:@"value"];

For the More Curious: Key-Value Observing

How did the text field become an observer of the fido key in the KvcFunAppDelegate object? When it wakes up from being on the NIB, it adds itself as an observer. If you wanted to become an observer of this key, your line of code might look something like this:

[theAppDelegate addObserver:self

forKeyPath:@"fido"

options:NSKeyValueChangeOldKey

context:somePointer];

This method is defined in NSObject. It is how you say, “Hey! Send me a message whenever fido changes.” The options and context determine what extra data is sent along with that message when fido changes. The method that is triggered looks like this:

- (void)observeValueForKeyPath:(NSString *)keyPath

ofObject:(id)object

change:(NSDictionary *)change

context:(void *)context

{

...

}

The keyPath, in this case, would be @"fido"; the object would be the KvcFunAppDelegate; context would be the pointer somePointer that was supplied as the context when you became an observer; change is a dictionary (a collection of key-value pairs) that can hold the old value of fido and/or the new value.

Chapter 8. NSArrayController

In the object-oriented programming community, a very common design pattern is Model-View-Controller. This design pattern says that each class you write should fall into exactly one of the following groups.

1. Model classes describe your data. For example, if you write banking systems, you would probably create a model class called SavingsAccount that would have a list of transactions and a current balance. The best model classes include nothing about the user interface and can be used in several applications.

2. View classes are part of the GUI. For example, NSSlider is a view class. The best views are general-purpose classes and can be used in several applications.

3. Controller classes are usually application-specific and are responsible for controlling the flow of the application. The user needs to see the data, so a controller object reads the model from a file or a database and then displays the model by using view classes. When the user makes changes, the view objects inform the controller, which subsequently updates the model objects. The controller also saves the data to the filesystem or database.

Until Mac OS X 10.3, Cocoa programmers wrote in their controller objects a lot of code that simply moved data from the model objects into the view objects and back again. To make common sorts of controller classes easier