<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept id="GUID-49363088-CE0B-558D-8E86-48400E4F7C2F" xml:lang="en"><title>Multiple

Alarm Notification Overview</title><prolog><metadata><keywords/></metadata></prolog><conbody>

<section id="GUID-EF2183A7-324A-4D62-93D1-FB007A33645C"><title>Purpose and Scope</title> <p>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. </p> </section>

<section id="GUID-F20C402E-3C40-4EE3-8822-65D066467FF6"><title>Definitions</title> <dl>

<dlentry>

<dt>Alarm Server </dt>

<dd><p>This provides Symbian with alarm-related services. It communicates

with Uikon Alert Server to display the expired alarm to users. </p> </dd>

</dlentry>

<dlentry>

<dt>Uikon Alert Server</dt>

<dd><p>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. </p> </dd>

</dlentry>

</dl> </section>

<section id="GUID-A8950BFC-6458-4E6A-A3FC-A2FC5FC704FD"><title>Description</title> <p>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. </p> <p>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. </p> <p>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. </p> <fig id="GUID-4F324FD2-EB30-5910-BD8E-315B67A4FA44">

<title>              Alarm state diagram for multiple alarm notification 

            support            </title>

<image href="GUID-16B42854-F27D-5CB3-BCFE-8F711793EE60_d0e375093_href.png" placement="inline"/>

</fig> <p>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 <xref href="GUID-A323F434-0A44-31E6-B57D-11F4DFC37EEE.dita"><apiname>EASAltOpCodeSetAlarm</apiname></xref> 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. </p> <p>If the Alert Server

can still accept more alarms the ‘waiting to notify’ alarm can change to ‘notifying’

state after the asynchronous request <xref href="GUID-A323F434-0A44-31E6-B57D-11F4DFC37EEE.dita"><apiname>EASAltOpCodeSetAlarm</apiname></xref> is

completed. </p> <p>As demonstrated above, a 'notifying' alarm can change to

‘snoozed’ state if: </p> <ol id="GUID-31855E68-7830-5B92-83DB-7BAFBF660B53">

<li id="GUID-EAFA400D-1FCE-5036-9522-13CB1A2C23E0"><p>The user requests ‘snooze’ </p> </li>

<li id="GUID-92CA5327-A999-526A-BB0F-36279B98AFEE"><p>Another alarm has expired

and the current alarm has sound playing paused. This scenario occurs if the

paused alarm is the only notifying alarm </p> </li>

<li id="GUID-7224BE4C-AF70-5F05-9BAE-0B95C8FFE483"><p>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. </p> </li>

</ol> <p>For single alarm notification, a notifying alarm has sound paused

when Alarm Server receives a <xref href="GUID-4BAB46E3-5397-3D40-8ED7-117C5F3DA51E.dita"><apiname>EASAltAlertServerResponsePauseSound</apiname></xref> 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. </p> <p>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. </p> <p>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. </p> <p>If

the user wants to silence the alarm while keeping the alarm in ‘notifying’

state, the user can respond with ‘silent’ (<xref href="GUID-C9D7979F-3E53-3513-92E9-219DA85D48E1.dita"><apiname>EASAltAlertServerResponseSilence</apiname></xref>),

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 (<xref href="GUID-B3A373AD-3488-3439-8896-2B2B34653020.dita"><apiname>EASAltAlertServerResponseQuietPeriod</apiname></xref>) will

pause sound for all alarms for a specified time while all expired alarms will

stay in ‘notifying’ state. </p> </section>