|
1 <?xml version="1.0" encoding="utf-8"?> |
|
2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. --> |
|
3 <!-- This component and the accompanying materials are made available under the terms of the License |
|
4 "Eclipse Public License v1.0" which accompanies this distribution, |
|
5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". --> |
|
6 <!-- Initial Contributors: |
|
7 Nokia Corporation - initial contribution. |
|
8 Contributors: |
|
9 --> |
|
10 <!DOCTYPE concept |
|
11 PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> |
|
12 <concept id="GUID-49363088-CE0B-558D-8E86-48400E4F7C2F" xml:lang="en"><title>Multiple |
|
13 Alarm Notification Overview</title><prolog><metadata><keywords/></metadata></prolog><conbody> |
|
14 <section id="GUID-EF2183A7-324A-4D62-93D1-FB007A33645C"><title>Purpose and Scope</title> <p>This document provides a description |
|
15 of the multiple alarm notification support in Symbian OS v9.2 and later. The |
|
16 main feature is the ability of multiple alarms to expire simultaneously. UI |
|
17 applications do not have to acknowledge an alarm event before the agenda server |
|
18 generates the next alarm event. This document provides a configuration guide. </p> </section> |
|
19 <section id="GUID-F20C402E-3C40-4EE3-8822-65D066467FF6"><title>Definitions</title> <dl> |
|
20 <dlentry> |
|
21 <dt>Alarm Server </dt> |
|
22 <dd><p>This provides Symbian with alarm-related services. It communicates |
|
23 with Uikon Alert Server to display the expired alarm to users. </p> </dd> |
|
24 </dlentry> |
|
25 <dlentry> |
|
26 <dt>Uikon Alert Server</dt> |
|
27 <dd><p>The Uikon Alert Server provides the interface for Alarm Server to interact |
|
28 with Licensee UI Applications. It consists of a client interface in Alarm |
|
29 Alert, and a server interface in Uikon. </p> </dd> |
|
30 </dlentry> |
|
31 </dl> </section> |
|
32 <section id="GUID-A8950BFC-6458-4E6A-A3FC-A2FC5FC704FD"><title>Description</title> <p>Alarm Server provides all alarm-related |
|
33 services to the system. When an alarm expires, Alarm Server notifies the Alert |
|
34 Server about the expired alarm to display to the user. </p> <p>The state properties |
|
35 are the same for single and multiple alarm notification, but the condition |
|
36 for moving to ‘notifying’ state is different. If multiple alarm notification |
|
37 is supported, more than one alarm can move to ‘notifying’ state provided that |
|
38 Alert Server can accept more than one alarm from Alarm Server. Even if a UI |
|
39 application can accept multiple notifying alarms, it cannot accept an infinite |
|
40 number of notifying alarms. Therefore, at Alarm Server startup, Alarm Server |
|
41 will query Alert Server for the maximum number of notifying alarms allowed. |
|
42 Alarm Server can use that information to determine if multiple alarm notification |
|
43 is supported, and if so, how many alarms can be in ‘notifying’ state at the |
|
44 same time. </p> <p>To support multiple alarm notification, Alarm Server notifies |
|
45 Alert Server about multiple expired alarms without waiting for the first alarm |
|
46 to be cleared or snoozed. </p> <fig id="GUID-4F324FD2-EB30-5910-BD8E-315B67A4FA44"> |
|
47 <title> Alarm state diagram for multiple alarm notification |
|
48 support </title> |
|
49 <image href="GUID-16B42854-F27D-5CB3-BCFE-8F711793EE60_d0e381172_href.png" placement="inline"/> |
|
50 </fig> <p>In the diagram above, a queued alarm can change to the ‘waiting |
|
51 to notify’ state if an alarm has expired but the maximum number of notifying |
|
52 alarms has been reached. The state can also change if Alarm Server is waiting |
|
53 for a reply from Alert Server. This second scenario may occur because even |
|
54 though Alert Server can accept multiple alarms, the Alarm Server needs the |
|
55 previous asynchronous request <xref href="GUID-A323F434-0A44-31E6-B57D-11F4DFC37EEE.dita"><apiname>EASAltOpCodeSetAlarm</apiname></xref> to be |
|
56 completed before sending the next one. As the UI application is implemented |
|
57 by licensee, this scenario may or may not occur depending on how long the |
|
58 UI application takes to register multiple alarms. </p> <p>If the Alert Server |
|
59 can still accept more alarms the ‘waiting to notify’ alarm can change to ‘notifying’ |
|
60 state after the asynchronous request <xref href="GUID-A323F434-0A44-31E6-B57D-11F4DFC37EEE.dita"><apiname>EASAltOpCodeSetAlarm</apiname></xref> is |
|
61 completed. </p> <p>As demonstrated above, a 'notifying' alarm can change to |
|
62 ‘snoozed’ state if: </p> <ol id="GUID-31855E68-7830-5B92-83DB-7BAFBF660B53"> |
|
63 <li id="GUID-EAFA400D-1FCE-5036-9522-13CB1A2C23E0"><p>The user requests ‘snooze’ </p> </li> |
|
64 <li id="GUID-92CA5327-A999-526A-BB0F-36279B98AFEE"><p>Another alarm has expired |
|
65 and the current alarm has sound playing paused. This scenario occurs if the |
|
66 paused alarm is the only notifying alarm </p> </li> |
|
67 <li id="GUID-7224BE4C-AF70-5F05-9BAE-0B95C8FFE483"><p>The sound playing is |
|
68 paused for the current notifying alarm. If this occurs and there are multiple |
|
69 notifying alarms, the currently notifying alarm is snoozed instead of paused. </p> </li> |
|
70 </ol> <p>For single alarm notification, a notifying alarm has sound paused |
|
71 when Alarm Server receives a <xref href="GUID-4BAB46E3-5397-3D40-8ED7-117C5F3DA51E.dita"><apiname>EASAltAlertServerResponsePauseSound</apiname></xref> event |
|
72 from Alert Server. If another alarm has expired while the notifying alarm |
|
73 has sound paused, Alarm Server snoozes the paused alarm automatically and |
|
74 plays the sound of the just expired alarm. In case of multiple alarm notification, |
|
75 the ‘sound paused’ alarm automatically snoozes if other alarms notify at the |
|
76 same time. </p> <p>It is a design decision to make the implementation compatible |
|
77 with the existing implementation. That way if the maximum number of alarms |
|
78 is set to one, the implementation is exactly that same as before. </p> <p>In |
|
79 case of multiple alarm notification, pausing the playing alarm triggers the |
|
80 Alarm Server to play sound for one of the other notifying alarms. This is |
|
81 because the sound pause request only applies to the specified alarm. </p> <p>If |
|
82 the user wants to silence the alarm while keeping the alarm in ‘notifying’ |
|
83 state, the user can respond with ‘silent’ (<xref href="GUID-C9D7979F-3E53-3513-92E9-219DA85D48E1.dita"><apiname>EASAltAlertServerResponseSilence</apiname></xref>), |
|
84 which will silence the alarm until the next alarm play interval re-starts |
|
85 (an existing behaviour in single alarm notification). Alternatively, a global |
|
86 silent command (<xref href="GUID-B3A373AD-3488-3439-8896-2B2B34653020.dita"><apiname>EASAltAlertServerResponseQuietPeriod</apiname></xref>) will |
|
87 pause sound for all alarms for a specified time while all expired alarms will |
|
88 stay in ‘notifying’ state. </p> </section> |
|
89 </conbody></concept> |