--- a/Symbian3/SDK/Source/GUID-49363088-CE0B-558D-8E86-48400E4F7C2F.dita Wed Mar 31 11:11:55 2010 +0100
+++ b/Symbian3/SDK/Source/GUID-49363088-CE0B-558D-8E86-48400E4F7C2F.dita Fri Jun 11 12:39:03 2010 +0100
@@ -1,89 +1,89 @@
-<?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_d0e381172_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>
+<?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>
</conbody></concept>
\ No newline at end of file