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.

- Alarm state diagram for multiple alarm notification - support - -

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.

+ + + + + +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.

+ Alarm state diagram for multiple alarm notification + support + +

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.

\ No newline at end of file