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 (Cocoaemail@example.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