On Sep 21, 2016, at 7:00 PM, Doug Hill <cocoa...@breaqz.com> wrote:
> As to the context type, I would be interested to know of cases where the 
> observer doesn't have control over the context. My understanding is that the 
> context is something that the observer sets itself when calling addObserver, 
> and it is passed back to itself in the above method call. So the observer 
> should know what kind of entity the context is, and can determine the best 
> way to compare this value.

The main use of the context parameter, I think, is to to keep your 
*de*registrations from clobbering the wrong registration. It's also useful to 
make sure you're looking at the observation you think you are. If a superclass 
or subclass also observes some things, then your -observeValueForKeyPath can be 
called for all sorts of things other than the things you requested. The 
'context' parameter supplies an opaque value that supports comparison but 
nothing else- that's why it's a (void *).

Unlike other context pointers in the API, you don't usually need to pass data 
in to your observation method, because it has access to self.

I usually use either the "address of a static variable" technique that Quincey 
Morris described, or [TheClassThatMyCodeIsIn class]. The latter will, like the 
static variable, be a pointer value that is unique to the set of observations 
you've registered (superclasses and subclasses will have to register using 
their own class, of course), and sometimes it's easier to examine in the 
debugger. I think the static-variable approach is better in general though.


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:

This email sent to arch...@mail-archive.com

Reply via email to