The following example implements an asynchronous listener notification that recognizes session log entries and generates notifications from them. To distinguish a session log entry from another type of log entry, the listener parses the entry data in the notification's supports method. The supports method model is flexible enough to permit this approach because the same listener notification object instance that returns true from the supports call is guaranteed to receive the runNotification call.

The example listener notification uses an alternative approach to implementing resource domains that redirects resource domain activities back to the notification (or adapter service) that uses it. This model does a better job of encapsulating the notification functionality into a single class. The model is described in detail in An Alternative Approach to Organizing Resource Domains. If you do not want to use this model, you may implement the resource domain code following the model described in Specifying Adapter Service Signature Resource Domains.

Another new concept used in this example is the "uses" metadata mechanism. This is a shortcut mechanism commonly used to manipulate a metadata signature. You use it to add a column of check boxes to the adapter's interface so that adapter users can select the fields to use for the notification. When they select the check boxes, values will appear in the Signature column. This metadata mechanism is described in The useParam Argument of setResourceDomain, but you do not need to fully understand the constraint of that feature to implement this example.

The tasks for implementing an asynchronous listener notification are as follows: