<?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-12A32F8E-0C53-5311-9B2B-8E0EA373ED08" xml:lang="en"><title>Types
of Alarm</title><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>This section explains the various types of alarms that are handled by the
Alarm Server. </p>
<p>Session alarms and Non-Session alarms are handled by the Alarm Server after
creating a session using <xref href="GUID-3598EAEE-0EF4-35A2-89E5-F3B2555B1AB4.dita"><apiname>RASCliSession</apiname></xref> function. </p>
<section><title>Session Alarms </title> <p>The alarms that are removed from
the alarm queue when the session disconnects are referred as Session Alarms.
Session alarms can either be synchronous or asynchronous. </p> <p>The session-based
alarms are defined by setting an alarm’s characteristics flag as <xref href="GUID-20A42BF7-A0F5-3177-9592-E3AE097B4CF2.dita#GUID-20A42BF7-A0F5-3177-9592-E3AE097B4CF2/GUID-EFA80EA7-423D-3B8E-A4CF-CD34325506E6"><apiname>TAlarmCharacteristics::EAlarmCharacteristicsSessionSpecific</apiname></xref>. </p> <p>Session Alarms are handled on behalf of a session with the Alarm Server.
Each session is allowed to set only one Session Alarm. The server informs
the session when to set the next alarm. If the session disconnects, the Session
Alarm is cancelled. </p> <p>The Session Alarm is completed when the alarm
expires, is cancelled, or a timing error occurs. </p> <p> <b>NOTE</b>: If
the client session is closed before the alarm has expired, the Alarm Server
automatically dequeues the alarm. </p> <p><b>Synchronous Session Alarms</b> </p> <p>To
add a session alarm to the queue synchronously, use <xref href="GUID-3598EAEE-0EF4-35A2-89E5-F3B2555B1AB4.dita#GUID-3598EAEE-0EF4-35A2-89E5-F3B2555B1AB4/GUID-45B0A300-B65E-3503-92AF-441DB44CD5CD"><apiname>RASCliSession::AlarmAdd()</apiname></xref>. </p> <p><b>Asynchronous
Session Alarms</b> </p> <p>To add a session alarm to the queue asynchronously,
use <xref href="GUID-3598EAEE-0EF4-35A2-89E5-F3B2555B1AB4.dita#GUID-3598EAEE-0EF4-35A2-89E5-F3B2555B1AB4/GUID-D9A2FDAA-D303-349D-B099-A770021720CC"><apiname>RASCliSession::AlarmAddWithNotification()</apiname></xref>. If a client
decides to cancel a Session Alarm, it must use <xref href="GUID-3598EAEE-0EF4-35A2-89E5-F3B2555B1AB4.dita#GUID-3598EAEE-0EF4-35A2-89E5-F3B2555B1AB4/GUID-C8FAE669-D389-3921-8FBF-2D04F90B6CA6"><apiname>RASCliSession::AlarmNotificationCancelAndDequeue()</apiname></xref>.
This requires that the ID of the alarm object be passed to the Alarm Server,
so that it can correctly identify the Session Alarm to be removed. </p> </section>
<section><title>Non-Session Alarms</title> <p>The alarms that continue to
persist in the alarm queue, even after their session owner which added these
alarms disconnect, are referred as Non-Session alarms. They are independent
of the client that set them. </p> <p>Non-Session alarms are also referred
as Orphaned Session alarms because these alarms are orphaned with no session
owners. </p> </section>
<section><title>Wake-Up Alarms</title> <p>An alarm that wakes-up the device,
if the device is switched OFF when the alarm expires, is referred to as Wake-Up
alarm. If the device is in the normal state, then it works as a clock alarm. </p> <p>It
is set using <xref href="GUID-3598EAEE-0EF4-35A2-89E5-F3B2555B1AB4.dita#GUID-3598EAEE-0EF4-35A2-89E5-F3B2555B1AB4/GUID-92A40392-98CC-3BEA-AD92-0566C88905D9"><apiname>RASCliSession::SetWakeup</apiname></xref>, by passing the unique
identifier of the alarm. </p> <p>A wake-up alarm that has been set and not
started alerting the device user is referred as an active Wake-Up alarm. Alarm
Server sets <codeph>EActiveWakeupAlarmSet</codeph> value if there are active
wake-up alarm(s) else, it sets <codeph>EActiveNoWakeupAlarmsSet</codeph> value. </p> <p> <codeph>KWakeupAlarmPubSubKey</codeph> can
be used to subscribe for wake-up alarm set and unset notifications. It belongs
to the <codeph>KAlarmServerPubSubCategory</codeph> alarm Publish and Subscribe
category. <codeph>EActiveWakeupAlarmUninitialized</codeph> is used to notify
the listeners of <codeph>KWakeupAlarmPubSubKey</codeph> key that the Alarm
Server has started at the device startup, and requires internalizing alarm
queue and checking for the presence of active wake-up alarm. </p> </section>
<section><title>Skipped Calendar Alarms</title> <p>An alarm that does not
expire normally because of an environment change but the alarm’s expiry time
is put in the past, is referred as Skipped Calendar alarms. An environment
change can be due to system time and other local changes (UTC and workday
changes). For more information, refer to <xref href="GUID-ED2B2DCC-D3C1-42FA-9CF3-0E149424C11D.dita">Working
with Skipped Alarms</xref>.</p><p>The Publish and Subscribe framework enables
a client to receive notification from the Alarm Server about the skipped alarm. <codeph>KMissingAlarmPubSubKey</codeph> P&amp;S
key contains data about environmental changes and whether or not they have
resulted in a skipped alarm. <codeph>KSkippedAlarmInstancesPubSubKey</codeph> P&amp;S
key supplies additional information that is required to search the Calendar
store for instances with skipped alarms. </p></section>
</conbody></concept>