Re: KVO and Core data
Re: KVO and Core data
- Subject: Re: KVO and Core data
- From: Quincey Morris <email@hidden>
- Date: Mon, 9 Aug 2010 10:53:47 -0700
On Aug 9, 2010, at 10:42, Kyle Sluder wrote:
> On Mon, Aug 9, 2010 at 10:23 AM, Gideon King <email@hidden> wrote:
>> I don't quite get why I should be passing in something for the context when setting up observing. I would have thought that that would be only for cases where either:
>> a) you actually want to use some context data
>> b) you have more than one key path the same and the observation object isn't enough information to give you the necessary context.
>> ...neither of which is the case for my application.
>
> The context is the only unique identifier for your observation. If
> both your implementation and your superclass's implementation register
> for the same keypath on the same object, the context is the only way
> to differentiate.
>
> The only sane thing to do is the technique espoused by Mike Ash
> <http://www.mikeash.com/pyblog/key-value-observing-done-right.html>,
> OFBinding <http://github.com/omnigroup/OmniGroup/blob/master/Frameworks/OmniFoundation/OFBinding.h>,
> and AppKit itself (all the various NS*Binder classes): create helper
> objects for each individual binding, and have them use their self
> pointers as the context arguments.
In many cases, it's sufficient to pass any ol' unique object pointer (or unique non-object value, of course, but getting uniqueness via object pointers is easier). Many people use globally unique strings. I generally use the observer's class object. That's assuming, of course, that there's no real context information that you need to pass in.
To complete the sermon you started:
Given the unique context identifier, the 'observeValueForKeyPath:ofObject:change:context:' *must* limit itself to handling invocations with the correct identifier and *must not* call the super implementation if it's correct. If the context is unrecognized, the method *must* call the super implementation instead. If Gideon didn't do that, then any number of application misbehaviors might result.
_______________________________________________
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