Choosing a Notification Technology

For the most part, the notification technology you choose should be appropriate for the type of programming you are doing. Command-line tools and daemons should generally use Darwin notifications. High-level applications should generally use either Core Foundation or Cocoa notifications.

This is not always true, however. In some cases, it may be more appropriate to choose a low-level notification scheme even in a high-level application. This chapter describes some environments in which you should choose a different technology than the most obvious choice.

Applications Communicating with Daemons

When applications and daemons must communicate with notifications, the best choice is not always obvious.

Of course, you do not have to use the same API in your application as in the daemon. As long as you limit your use of the Core Foundation or Cocoa notification APIs to empty messages (that is, messages with only a name), you can use those APIs in your application and still use the Darwin notification API in your daemon.

Mixed Carbon and Cocoa Applications

Cocoa notifications (NSNotificationCenter) and Core Foundation notifications (CFNotificationCenterRef) can communicate with each other, making it easy to provide notifications between Carbon and Cocoa applications. However, because these types are not toll-free bridged, you cannot cast between them.

For the most part, this is not a problem. However, if you need to post notifications from portions of your application written in Carbon, it may be easier to use Core Foundation notifications throughout. This will make it easier to share data structures between C and Objective-C portions of your code without introducing redundancy.

Similarly, if you are adding notifications to Carbon and Cocoa applications simultaneously and need to write any glue code that is common to both your Carbon and Cocoa applications, you may find it more convenient to write a single notification module based on Core Foundation notifications in order to avoid maintaining multiple versions of your glue code.

System-Provided Notifications

Many parts of OS X provide notifications in other ways. Examples include the I/O Kit, Disk Arbitration, System Configuration (configd), and kernel queues. To lean how to receive these notifications, you should read Appleā€™s documentation about those technologies.

Kernel queues and kernel event notifications are a much better alternative to polling for file changes. Kernel event notifications also provide a way to find out about a number of other kernel-related events. The kernel queues mechanism is described in File System Events Programming Guide and in the manual pages for kevent(2) and kqueue(2).

The I/O Kit notification mechanism is based around the IOService class. Registering for and posting notifications is described in IOKit Fundamentals.

System Configuration notifications are provided through the System Configuration framework. You can learn more about this framework by reading System Configuration Programming Guidelines and System Configuration Framework Reference.

Disk Arbitration notifications can tell you when a volume is mounted or unmounted. (You can also learn when volumes are mounted or unmounted using the File System Events API in OS X v10.5 and later.) You can learn more about Disk Arbitration notifications in Disk Arbitration Framework Reference.