Re: Bindings and Observing
Re: Bindings and Observing
- Subject: Re: Bindings and Observing
- From: Laurent Daudelin <email@hidden>
- Date: Thu, 25 Mar 2010 11:25:46 -0700
On Mar 25, 2010, at 00:32, Quincey Morris wrote:
> On Mar 24, 2010, at 23:42, Laurent Daudelin wrote:
>
>> In the Preferences.nib file, the checkbox and the textfield are bound to the defaults controller. So far, so good. In the application delegate's applicationWillFinishLaunching:, they have those 2 lines:
>>
>> [self bind:SKTAppAutosavesPreferenceKey toObject:userDefaultsController withKeyPath:[@"values." stringByAppendingString:SKTAppAutosavesPreferenceKey] options:nil];
>> [self bind:SKTAppAutosavingDelayPreferenceKey toObject:userDefaultsController withKeyPath:[@"values." stringByAppendingString:SKTAppAutosavingDelayPreferenceKey] options:nil];
>>
>> The app delegate, by binding these properties to the user defaults controller, then has its setAutosaves: and setAutosaveDelay: methods called each time the checkbox is toggled or the text field value is changed. How does that work behind the scene? The user defaults controller of course has the keys saved in the user preferences set in IB. Maybe it's late but I fail to understand this.
>
> The [NSObject bind:] method implements functionality that's useful as *part* of a custom bindings implementation. As it happens, the method is also usable in isolation as a sort of observation convenience method. (People sometimes call this usage a "binding" or a "one-way binding" though by itself it doesn't meet the requirements of a bindings implementation. But that's a different soapbox.)
>
> Let's call the 1st parameter the "receiver key", the 2nd parameter the "target" object, and the 3rd parameter the "target key path".
>
> What the method does, in essence, is to establish the receiver as a KVO-observer of the target object for the target key path. In addition, when a KVO notification arrives, if the receiver key is actually a KVC property of the receiver, it sets that property to the value that changed at the target object's target key path.
>
> In other words, the receiver's property is made to track changes in the target property. In the above example, this makes the app delegate's property values follow the user defaults values.
>
> It works just fine, but I think this use of the 'bind:' method is an abuse of the API, especially as there are at least 2 other simple ways of getting the same effect:
>
> You could do the same thing yourself, by calling [userDefaultsController addObserver: self forKeyPath: ...] and providing an 'observeValueForKeyPath:...' method to transfer the changed value to the observer's property.
>
> You could also make the app delegate's properties be derived properties, having the app delegate getter retrieve the user interface controller values directly, and using the keyPathsForValuesAffecting<Key> mechanism to provide KVO compliance.
I see. I thought about observing those properties managed by the user defaults controller but after I read the document "Controller Key-Value Observing Compliance", I saw that NSUserDefaultsController is a key-value-observing only for a limited set of its own properties. That left me thinking that I would not be able to observe the user defaults properties managed by the controller but maybe I'm not ready this correctly?
-Laurent.
--
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin http://nemesys.dyndns.org
Logiciels Nemesys Software email@hidden
Photo Gallery Store: http://laurentdaudelin.shutterbugstorefront.com/g/galleries
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden