0

I have a NSObject that listens for ~30 string signals. I want to post any number of strings to this object. But I first want to test to see if it's observing the current string.

The documentation for [NSNotificationCenter][1] doesn't suggest this is possible. There are only add/remove remove observer, and post notification methods.

The documentation for KVO makes me think this may be possible using the [[NSNotificationCenter defaultCenter] observationInfo] method. I don't have a clue how I would use the returned void*. The documentation states the return value:

A pointer that identifies information about all of the observers that are registered with the receiver, the options that were used at registration-time, and so on.

I especially appreciate the "and so on". That was the most helpful part...sigh.

Considering the number of signals the object is handling, I don't want to manually check each string. Is there a graceful way to check whether the object is observing a string (try/catch doesn't qualify) at the NSObject level or KVO level that doesn't use private API?

Thanks.

stephen
  • 1,039
  • 14
  • 31

1 Answers1

1

The pointer used by -observationInfo is opaque (i.e. meaningless) to you; it's just a token. From the header (emphasis mine):

Take or return a pointer that identifies information about all of the observers that are registered with the receiver, the options that were used at registration-time, etc. The default implementation of these methods store observation info in a global dictionary keyed by the receivers' pointers. For improved performance, you can override these methods to store the opaque data pointer in an instance variable. Overrides of these methods must not attempt to send Objective-C messages to the passed-in observation info, including -retain and -release.

Also, KVO observations and NSNotificationCenter observations are two completely separate mechanisms with no relation between them. Neither offers any public API for figuring out who is observing what. The only way I can conceive to track observations would be to override the add/remove methods (either with method overrides for KVO or by swizzling the methods on NSNotificationCenter) and then keeping track of the observation information yourself.

I don't mean to be "that guy" but wanting to know about who's observing what is generally a red flag that something isn't well architected. If you're worried about performance, I wouldn't be. KVO and NSNotificationCenter are fairly fast/low overhead mechanisms. ~30 observations aint nothin' to either. I wouldn't worry about it.

ipmcc
  • 29,581
  • 5
  • 84
  • 147
  • try/catch it is. :) Thanks for the insight! – stephen Jun 21 '13 at 19:52
  • Not sure why try/catch would be involved, honestly. If you call `will/didChangeValueForKey` and no one is listening it's a no-op. Similarly, if you post a notification to an NSNotificationCenter and no one is listening for it, nothing happens. No exceptions should be thrown in either case. – ipmcc Jun 26 '13 at 03:01
  • I have an [App]Socket that specializes and XMLMessageSocket, which specializes a TCPSocket. When the XMLMessageSocket decides it's received a full xml message, it derives the signal name, and sends itself the message. If the [App]Socket doesn't respond to the message, an exception is thrown. – stephen Jun 26 '13 at 19:27