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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
