Multiple Alarm Notification Overview
Purpose and Scope
This document provides a description of the multiple alarm notification support in Symbian OS v9.2 and later. The main feature is the ability of multiple alarms to expire simultaneously. UI applications do not have to acknowledge an alarm event before the agenda server generates the next alarm event. This document provides a configuration guide.
Definitions
- Alarm Server
This provides Symbian with alarm-related services. It communicates with Uikon Alert Server to display the expired alarm to users.
- Uikon Alert Server
The Uikon Alert Server provides the interface for Alarm Server to interact with Licensee UI Applications. It consists of a client interface in Alarm Alert, and a server interface in Uikon.
Description
Alarm Server provides all alarm-related services to the system. When an alarm expires, Alarm Server notifies the Alert Server about the expired alarm to display to the user.
The state properties are the same for single and multiple alarm notification, but the condition for moving to ‘notifying’ state is different. If multiple alarm notification is supported, more than one alarm can move to ‘notifying’ state provided that Alert Server can accept more than one alarm from Alarm Server. Even if a UI application can accept multiple notifying alarms, it cannot accept an infinite number of notifying alarms. Therefore, at Alarm Server startup, Alarm Server will query Alert Server for the maximum number of notifying alarms allowed. Alarm Server can use that information to determine if multiple alarm notification is supported, and if so, how many alarms can be in ‘notifying’ state at the same time.
To support multiple alarm notification, Alarm Server notifies Alert Server about multiple expired alarms without waiting for the first alarm to be cleared or snoozed.
In the diagram above, a queued alarm can change to the ‘waiting to notify’ state if an alarm has expired but the maximum number of notifying alarms has been reached. The state can also change if Alarm Server is waiting for a reply from Alert Server. This second scenario may occur because even though Alert Server can accept multiple alarms, the Alarm Server needs the previous asynchronous request EASAltOpCodeSetAlarm to be completed before sending the next one. As the UI application is implemented by licensee, this scenario may or may not occur depending on how long the UI application takes to register multiple alarms.
If the Alert Server can still accept more alarms the ‘waiting to notify’ alarm can change to ‘notifying’ state after the asynchronous request EASAltOpCodeSetAlarm is completed.
As demonstrated above, a 'notifying' alarm can change to ‘snoozed’ state if:
The user requests ‘snooze’
Another alarm has expired and the current alarm has sound playing paused. This scenario occurs if the paused alarm is the only notifying alarm
The sound playing is paused for the current notifying alarm. If this occurs and there are multiple notifying alarms, the currently notifying alarm is snoozed instead of paused.
For single alarm notification, a notifying alarm has sound paused when Alarm Server receives a EASAltAlertServerResponsePauseSound event from Alert Server. If another alarm has expired while the notifying alarm has sound paused, Alarm Server snoozes the paused alarm automatically and plays the sound of the just expired alarm. In case of multiple alarm notification, the ‘sound paused’ alarm automatically snoozes if other alarms notify at the same time.
It is a design decision to make the implementation compatible with the existing implementation. That way if the maximum number of alarms is set to one, the implementation is exactly that same as before.
In case of multiple alarm notification, pausing the playing alarm triggers the Alarm Server to play sound for one of the other notifying alarms. This is because the sound pause request only applies to the specified alarm.
If the user wants to silence the alarm while keeping the alarm in ‘notifying’ state, the user can respond with ‘silent’ (EASAltAlertServerResponseSilence), which will silence the alarm until the next alarm play interval re-starts (an existing behaviour in single alarm notification). Alternatively, a global silent command (EASAltAlertServerResponseQuietPeriod) will pause sound for all alarms for a specified time while all expired alarms will stay in ‘notifying’ state.