1

I want to use a cpp function as observer callback. Out of CFNotificationCenterGetDarwinNotify/Distributed/LocalCenter, CFNotificationCenterGetLocalCenter seems closest to [NSNotificationCenter defaultCenter].

Is CFNotificationCenterGetLocalCenter equivalent to [NSNotificationCenter defaultCenter]?

EDIT:I am in doubt because An answer here says - You cannot add observer throuh C++ class But the one here says - You can add observer in C++ class through CF functions.

Community
  • 1
  • 1
Nitesh
  • 2,681
  • 4
  • 27
  • 45

2 Answers2

1

The best way to use a C++ callback for a notification might be to use -[NSNotificationCenter addObserverForName:object:queue:usingBlock:] with a small glue block to your C++ code.

microtherion
  • 3,938
  • 1
  • 15
  • 18
  • That really seems the best way. Do I need to retain the observer returned by addObserverForName and release after removing observer? I am adding observer in C++ class ctor and removing observer in dtor. – Nitesh Jun 15 '13 at 13:14
  • You don't need to retain it (headers say "The return value is retained by the system"), but you do need to keep a (unretained) reference to it in your C++ object so that you can pass it back to `removeObserver:` in your dtor. – ipmcc Jun 15 '13 at 13:35
0

NSNotificationCenter and CFNotificationCenter are not toll-free bridged (see: definitive list of toll-free bridged types), so if you are trying to receive notifications posted by AppKit on the specific NSNotificationCenter instance returned by +[NSNotificationCenter defaultCenter] it would seem safest to use Objective-C, at the very least to interact with that instance of NSNotificationCenter. Your Objective-C class can be quite thin, and simply call through to your C++ class, but there's no avoiding Objective-C if those are the specific notifications you wish to receive.

EDIT: Empirically, yes, posting a notification to one appears to cause the notification to be received by the other, per the comment you copied and pasted. That said, I see no mention whatsoever of this behavior on either the CFNotificationCenter reference page nor the NSNotificationCenter reference page, nor does it appear to mentioned in the Notification Programming Guide so to rely on such an un-documented implementation detail seems risky.

ipmcc
  • 29,581
  • 5
  • 84
  • 147
  • The answer in 2nd linked question has a comment: "No, CFNotificationCenter is not toll-free bridged with NSNotificationCenter. So a custom instance of either will not be usable in the other API. However, if you use a standard center in either (e.g. CFNotificationCenterGetLocalCenter() or [NSNotificationCenter defaultCenter]) and post a notification to it, the notification is posted to both sets of listeners (i.e. the interfaces are distinct, but the underlying system is the same.)" This makes me believe I can listen to default center notification in cpp – Nitesh Jun 15 '13 at 11:41
  • And yes there is always an option to have mediator or glue classes but why go with it if system provides some other means? I just want to receive notification by name – Nitesh Jun 15 '13 at 11:43
  • Edited with caveat. Honestly, if you're trying to receive AppKit notifications, not working in the AppKit idiom (i.e. Objective-C) seems like it's making unnecessary work for yourself, but I get that some people have strong feelings about programming languages. – ipmcc Jun 15 '13 at 11:48
  • Undocumented implementation detail - That's exactly what I thought about it and hence posted the question so that if someone who knows that its a defined behavior, can post a link. – Nitesh Jun 15 '13 at 12:41
  • I'm pretty confident that if this were public, documented behavior, that some mention of it would appear in one of the pages I linked to, but I also don't claim exhaustive up-to-date knowledge of all Apple documentation. Either way you go will probably be fine. On the one hand, a ~10 line glue class seems like a small price to pay, but on the other hand, I can't imagine this is behavior that changes very often. Another thought might be to track down a system running 10.5 and see if the behavior is the same there. If it hasn't changed since 10.5, it seems unlikely to change any time soon. – ipmcc Jun 15 '13 at 12:48