--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Symbian3/SDK/Source/GUID-49363088-CE0B-558D-8E86-48400E4F7C2F.dita	Thu Jan 21 18:18:20 2010 +0000
@@ -0,0 +1,15 @@
+<?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 xml:lang="en" id="GUID-49363088-CE0B-558D-8E86-48400E4F7C2F"><title>Multiple Alarm Notification Overview</title><prolog><metadata><keywords/></metadata></prolog><conbody><section><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><title>Definitions</title> <dl><dlentry><dt>Alarm Server </dt> <dd><p>This provides Symbian OS 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><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_d0e354652_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>
\ No newline at end of file