### Implement a Notification

When an event requiring notification occurs, the notifier constructs an INotificationEvent object defining the type of event and sends it to any observers registered for that type of event. Each observer is responsible for handling the event as appropriate.

To implement your own notification mechanism your code must follow a basic order, or sequence, of calls:

1. Create a notifier.
2. Create an observer.
   1. Connect the observer to the notifier.
   2. Register with the notifier with an interest for a change or event.
3. Use your notifier from the application object managing the data or event.

### Asynchronous or Synchronous Notification

You can send notifications synchronously or asynchronously, depending on the requirements of both the notifier and the observer. Some notifiers require that notifications be handled synchronously so that all notification processing is complete before returning to the notifier. A system shutdown service is an example of this.

Other notifiers, such as a file server, might require that notifications be delivered asynchronously so that they are not blocked for long periods of time, waiting for observers to complete notification handling.

The Notification Framework provides two INotifier methods that you can use depending on your needs. INotify::notifyObservers() provides a synchronous implementation and INotify:notifyObserversAsync() provides one that is asynchronous.

When you call INotifier::notifyObservers(), the notifier calls the notify member function of all the connections interested in that notification in the same thread in which INotifier::notifyObservers() was called. When the call completes, the notifier is assured that all observers interested in the notification have received it.

However, this means that an observer can tie up the notifier by taking a long time to process a notification.

When you call INotify::notifyObserversAsync(), a request to perform the notification is passed to a request processor. The notifier can then immediately continue to perform other work. When the request processor eventually delivers the notification, receivers cannot make any assumptions about the state of the notifier (even that it still exists).

### Multi-threaded Notification

To register an observer, an observer's handleNotificationFor() function is called. It, in turn, chains into the notifier's addObserver() function which can then record the threadID associated with the observer.

When an event for which the observer is registered occurs, in the case of synchronous multi-threaded notification, the notifier's notifyObservers() function is called.

The notification is dispatched on the same thread on which the observer was created. This is basically the same behavior as if notifyObserversAsync() were invoked instead of notifyObservers().

For asynchronous multi-threaded notification, when the notifier's notifyObserversAsync() function is called, it determines whether it needs to send a notification to an observer in another thread. If so, it posts to the request queue associated with the observer's thread.

When using asynchronous notification, it is important to start the notification dispatcher properly:

- For a GUI thread, one that uses IThread::current().processMsgs(), your main function should have a processMsgs() loop to handle the GUI events for the thread.
- If you create observers in a non-GUI thread, one that does not use IThread::current().processMsgs(), and you want the observers to receive asynchronous notifications, then you should use ICrossThreadNotificationLoop() in the non-GUI thread to dispatch to asynchronous notification-aware observers. You would include code similar to the following:

> ICrossThreadNotificationLoop
> theLoop(anObserver);
> theLoop.run();