Some functionality in cocoa is taken for granted. It's sooo easy to create something that works - drag here, drop there, bind, bind, presto! Some time during your adventure with cocoa you might start wondering how some of these mechanisms work. I did :) When that moment comes, don't back down. Instead, try pursuing the idea. It's a great time to delve deeper into cocoa and objective-c and see how apple engineers solved issues you might have been implementing wierd workarounds for.
I like the way some people write about cocoa's bindings - "It's magic". It sure does seem so for some one who knows nothing about them (or knows a whole bunch and doesn't feel like explaining). The truth is bindings are nothing more than an automated form of KVO (Key-Value Observing). Binding an object to another object results in those objects being in sync. We can do the exact same thing by observing those objects and manually updating their values, but in such a case we would end up writing a lot of our own glue code.
Recently I've created a custom NSView that essentially mimicked the way NSTableView worked. I didn't want to subclass NSTableView mainly because it seems to have been designed to work well when inside an NSScrollView, not as an independent view. Seeing as how NSTableView had a content property you could bind to I created an NSMutableArray object called content in my class and made it KVO compliant. This is where the problems started. Simply binding content to my NSArrayControllers arrangedObjects array wasn't going to inform my custom view about the changes that were being made to arrangedObjects. I figured I could overcome this by observing arrangedObjects. Unfortunately, it turns out that key-value observing for collections isn't fully functional. Apples documentation for:
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context;
states that:
NSKeyValueChangeKindKey
An NSNumber object that contains a value corresponding to one of the NSKeyValueChangeKindKey enumerations, indicating what sort of change has occurred.
A value of NSKeyValueChangeSetting indicates that the observed object has received a setValue:forKey: message, or that the key-value-coding-compliant set method for the key has been invoked, or that willChangeValueForKey:/didChangeValueForKey: has otherwise been invoked.
A value of NSKeyValueChangeInsertion, NSKeyValueChangeRemoval, or NSKeyValueChangeReplacement indicates that mutating messages have been sent to the array returned by amutableArrayValueForKey: message sent to the object, or that one of the key-value-coding-compliant array mutation methods for the key has been invoked, or thatwillChange:valuesAtIndexes:forKey:/didChange:valuesAtIndexes:forKey: has otherwise been invoked.
You can use NSNumber's intValue method to retrieve the integer value of the change kind.
Available in Mac OS X v10.3 and later.
Declared in NSKeyValueObserving.h.
NSKeyValueChangeNewKey
If the value of the NSKeyValueChangeKindKey entry is NSKeyValueChangeSetting, and NSKeyValueObservingOptionNew was specified when the observer was registered, the value of this key is the new value for the attribute.
For NSKeyValueChangeInsertion or NSKeyValueChangeReplacement, if NSKeyValueObservingOptionNew was specified when the observer was registered, the value for this key is an NSArray instance that contains the objects that have been inserted or replaced other objects, respectively.
Available in Mac OS X v10.3 and later.
Declared in NSKeyValueObserving.h.
If this were true, I wouldn't be writing this post :) If the value of NSKeyValueChangeKindKey for the change dictionary contains NSKeyValueChangeInsertion, NSKeyValueChangeRemoval or NSKeyValueChangeReplacement the value for NSKeyValueChangeNewKey will always be [NSNull null]. From what I've read, this is something Apple is aware of, but hasn't established a date for when it will be fixed (this could mean that it will never get fixed).
What this implied for my custom view is the fact that I needed to establish what the changes were myself. However, if I bind content to arrangedObjects and observe arrangedObjects the value of both will always be the same once my code in the observing method is reached. This in turn implies that I will not be able to get the changes and that bindings will not be a feasible solution for this problem. I started wondering how Apple solved this issue. What I came up with is a solution that perfectly mimics NSTableViews behaviour.
I came to terms with the fact that I won't be able to use bindings, but I really wanted the illusion of bindings to stay. I decided to overwrite the method used for binding like so:
- (void)bind:(NSString *)binding toObject:(id)observableController withKeyPath:(NSString *)keyPath options:(NSDictionary *)options
{
if([binding isEqualToString:@"content"] && [keyPath isEqualToString:@"arrangedObjects"] && [observableController isKindOfClass:[NSArrayController class]])
{
[observableController addObserver:self forKeyPath:keyPath options:(NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld) context:nil];
_contentArrayController = observableController;
[self setContent: [_contentArrayController arrangedObjects]];
}
else
[super bind:binding toObject:observableController withKeyPath:keyPath options:options];
}
From the outside this still looks like the normal binding procedure is taking place, when in reality it's only observing. I also assigned my NSArrayController to a class variable in my custom view called _contentArrayController. This becomes useful in the unbind method:
- (void)unbind:(NSString*)keyPath
{
if([keyPath isEqualToString:@"content"])
{
if(_contentArrayController != nil)
{
[_contentArrayController removeObserver:self forKeyPath:@"arrangedObjects"];
_contentArrayController = nil;
}
}
[super unbind:keyPath];
}
Once all that is done you can try to observe changes in the observeValueForKeyPath method. What you will notice is that there is another issue - the only value the change dictionary will return for the NSKeyValueChangeKindKey is NSKeyValueChangeSetting. This is due to the way the arrangedObjects array is set in NSArrayController. So what we are left with is determining changes ourselves. If you need a custom view that displays a small amount of data then you might as well just set the new value for your views content based on what arrangedObjects contains. If you NEED to know what changed then I guess the reasonable way to go about it would be to compare your views current content array with the new arrangedObjects array like so:
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context
{
if([keyPath isEqualToString:@"arrangedObjects"] && _contentArrayController != nil)
{
NSMutableArray *array = [_contentArrayController arrangedObjects];
if(array != nil)
{
if([array count] > [content count])
{
NSLog(@"items added");
}
else if([array count] < [content count]) { NSLog(@"items removed"); } else if([array count] == [content count]) { NSLog(@"items replaces"); } } //don't forget to set the content array!!! [self setContent:array]; [self setNeedsDisplay:YES]; } }
The problem with this is that if you assign a completely new array to NSArrayControllers content the above code won't be worth a damn. You could ofcourse go through every object in the array every time arrangedObject changes, but for large amounts of data that seems like a bad use of resources.
Anyhow, I encourage readers to look for interesting solutions to fun problems.
