Intertask Communications

Notification Manager

Notification Manager provides a mechanism for sending programmatic notifications of unsolicited system events to applications. Applications can register to receive particular types of notifications that they are interested in. The Notification Manager can deliver notifications not only to currently running applications, but also to applications that are registered to receive them but are not currently running.

Notifications are general system level or user application level events like application installed/uninstalled, card inserted/removed, VFS mounted/unmount, incoming call, clam shell opened/closed, time changed, locale changed, low power, or device going to sleep/waking up. The Notification Manager has a client/server architecture.

Notification Manager server. The Notification Manager server is a persistent thread in a separate system process which keeps track of all registered notifications and broadcasts notifications to registered clients. The Notification Manager server also communicates with the Package Manager and Application Server.

Notification Manager client library. Client processes call APIs in the Notification Manager client library to (1) register to receive notifications, (2) unregistered previously registered notifications, (3) signal the completion of a notification, and (4) broadcast notifications. The Notification Manger client library uses the ALP IPC framework to communicate to the Notification Manager server.

What the Notification Manager is not. (1) The Notification Manager should not be used for application specific or directed notifications like alarms or find. (2) The Notification Manager facilitates the sending and receiving of notifications but it does not itself broadcast notifications (individual component owners are responsible for broadcasting their own notifications).

Detailed information on Notification Manager can be found here.

Alarm Manager

The Alarm Manager provides a mechanism to notify applications of real time alarm (i.e. time based) events. Both currently running and non-running applications can receive events from the Alarm Manager. The Alarm Manager does not control presentation to the user – the action taken by an application in response to an alarm is defined by the application.

The Alarm Manager:

Works closely with the Power Manager to register the first timer.
Calls alp_app_launch() to launch the applications the alarm is due.
Supports more than one alarm per application.
Stores alarm database in SQLite for persistence.

The Alarm Manager doesn't have any UI of its own; applications that need to bring an alarm to the user's attention must do this through the Attention Manager. The Alarm Manager doesn't provide reminder dialog boxes, and it doesn't play the alarm sound. Applications should use the Attention Manager to interact with the user.

Alarm Manager Architecture

The following is the overview of the Alarm Manager architecture:

The detail diagram for the Alarm Manager Daemon is the following:

Detailed information on the Alarm Manager can be found here.

Attention Manager

The Attention Manager manages system events that need to be presented to the user, such as a low battery condition or an incoming call (rather than programmatic events delivered to other applications like the service provided by the Notification Manager). The Attention Manager uses a priority scheme to manage presentation of items needing attention to the user. The infrastructure used by applications and system services to ask for attentions and the storage of the currently pending list of events requiring the user’s attention is separate from the actual presentation of the events to the user.
The Attention Manager is a standard facility by which applications can tell the user that something of significance has occurred. The Attention Manager is responsible only for being a nexus for such events and interacting with the user in regards to these events; it is not responsible for generating the events.
The Attention Manager provides both a single alert dialog and maintains a list of all "alert-like" events. Together these improve the user experience by first getting the user's attention when needed, then allowing the user to deal with the attention or dismiss for review later. By handling it this way, it is no longer necessary to click through a series of old alert dialogs. Often the user doesn't care about most of the missed appointments or phone calls - although he might care about a few of them. Without the Attention Manager, the user cannot selectively dismiss or follow up on the alert events but would instead have to deal with each alert dialog in turn.
Applications have complete control over the types and level of attention they can ask for.
Typical flow of an attention event:

An application (maybe the calendar app) requests the Alarm manager to wake at some time in the future.
The Alarm Manager simply sends an event to an application when that future point in time is reached. The application can then post an event to the attention manager with the appropriate priority.
The Attention Manager will present the appropriate alert dialog based on the event type and priority.
The Attention Manager is designed solely to interact with the user when an event must be brought to the user's attention

When the Attention Manager isn't appropriate

The Attention Manager is only designed for attempts to get attentions that can be effectively handled or suspended. The Attention Manager also doesn't attempt to replace error messages. Applications most use Modal dialogs and other existing OS facilities to handle these cases.

The Attention Manager is also not intended to replace the ToDo (Tasks) application, or act as a universal inbox. Applications must make it clear that an item appearing in the attention manager is simply a reminder, and that dismissing it does not delete or cancel the item itself. That is, saying "OK" to an attention message does not delete the appointment, and dismissing an SMS reminder does not delete the SMS message from the SMS inbox. (well clearly some apps could work a little harder on this concept) (Although dismissing the event does clear the event message from the attention manager).

The Attention Manager is also not an event logger or event history mechanism. It contains only the state of active attention events.

Architecture

This is one of several different ways the components of the Attention Manager could be organized in order to meet the design goals, which are:

separate UI from attention event logging mechanisms
provide sufficient configurability so that a licensee may alter both the appearance and behavior of the posted events.
persistent store of events that will survive a soft reset
be responsive (need to be quick from alert to UI - prime example is incoming call)
minimize memory usage (i.e. try to get as small a memory foot print as possible)

The server model shown here relies on an init script to start a small daemon. The daemon will accept IPC requests to post, update, query or delete events and maintain such event state in a database to provide persistent storage for the events. The daemon will launch the attention UI application which will display the appropriate alert dialog. If the snooze action is chosen for an event (provided that a snooze action is associated with the event), the Attention UI application will call the Alarm manager to schedule a wakeup. The wakeup will be in the form of a launch or relaunch from the Application server. In this model, the attention status gadget is assumed to be polling the attention manager daemon for active event state and using that information in displaying status. If the attention status gadget is "clicked" on, it is expected to start the Attention UI through the Application Server.

Since the Attention Manage is made up of several components, it will be possible to try several of the models and evaluate which is the better for memory and performance. Also, the final result may have some components residing in other system components - for example, the Attention Manager daemon may be integrated within the Application Server. This won't be determined until the implement is working and performance can be further measured and compared.

Features

The Attention Manager consists of the following major components:

attention events
an API library for posting, updating, deleting and querying events
a server through which events are posted, retrieved and managed.
an UI application that displays the alert dialogs
an event database and associated DML API
a status gadget for the status bar

Detailed information on the Attention Manager can be found here.

Back to "About Hiker... "