Since Objective-C 2.0, we\'ve had @properties
and autogenerated accessor methods. So today, what is the point of key-value coding? Under what circumstances is it
KVC can be useful if you are using Key Value Observers to detect value changes on an object. If you wanted to use KVO and @properties
you would have to wrap every mutator method with:
[self willChangeValueForKey:@"bar"];
bar = foo;
[self didChangeValueForKey:@"bar"];
It's almost never preferable to write out [myObject setValue:foo forKey:@"bar"]
by hand, with a literal @"bar"
. We usually use KVC to access a property when we don't know which property we want to access until runtime.
One example is an outlet in a xib. When you connect a text field's delegate outlet to the File's Owner in the xib, the xib records the connection as an object with three fields:
@"delegate"
At runtime, the xib loader (part of the UIKit framework) deserializes the text field. Then it deserializes the connection object and uses it to establish the connection that you wired up in the xib. The xib loader has to set a property of the text field (the delegate
property), but it doesn't know which property until it loads the xib at runtime, long after both your app and the UIKit framework were compiled.
Another example of not knowing which property to access until runtime is the (little-known) ability of Core Animation to animate a custom property of your CALayer
subclass. Say you create a subclass of CALayer
called PolygonLayer
, with a property named sides
. You can animate the sides
property using a standard CABasicAnimation
:
CABasicAnimation *animation = [CABasicAnimation animationWithKeyPath:@"sides"];
animation.fromValue = @3;
animation.toValue = @9;
animation.autoreverses = YES;
animation.duration = 1;
[myPolygonLayer addAnimation:animation forKey:@"sides"];
Presto, Core Animation will animate your layer's sides
property from 3 to 9 and back. Yet the source code of Core Animation doesn't know anything about your sides
property. (Check out this question for more details.)
There are times we use KVC even though we know the property at compile-time. One example is when we want to take advantage of extra work KVC will do for us. For example, if you have an NSArray
full of Person
objects, and you want to get an array of every person's first name, you could write this:
NSMutableArray *firstNames = [NSMutableArray array];
for (Person *person in people) {
[firstNames addObject:person.firstName];
}
But this is a case where KVC has a feature that makes it simpler. If you access a property of an array using KVC, KVC will actually access that property of every element in the array for you:
NSArray *firstNames = [people valueForKey:@"firstName"];
Another example where we might use KVC even though we know the property at compile-time is when the property is not statically declared as part of the class. For example, each NSManagedObject (part of Core Data) dynamically gives itself properties based on whatever entity that instance of NSManagedObject
is representing. You can access those properties using KVC, although generally we prefer to declare them in a subclass of NSManagedObject or in a category of NSManagedObject.
Sometimes you don't know what property you want to set/get until run-time.
In this case you can use KVC by constructing the property key path as a string.
For example i have an object with multiple NSArray properties and i want to keep the last NSDate they were updated.
Let's say i have an array property called: comments and an array property called likes.
I define a properties: commentsLastModified and likesLastModified. when an array is updated (i have the property name as string), i use:
[object setValue:[NSDate date] forKey:[NSString stringWithFormat:@"%@%@", arrayString, @"LastModified"];