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 laurent.daude...@gmail.com Photo Gallery Store: http://laurentdaudelin.shutterbugstorefront.com/g/galleries _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
