<?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_d0e355905_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>
</conbody></concept>