Types of Alarm

This section explains the various types of alarms that are handled by the Alarm Server.

Session alarms and Non-Session alarms are handled by the Alarm Server after creating a session using RASCliSession function.

Session Alarms

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.

The session-based alarms are defined by setting an alarm’s characteristics flag as TAlarmCharacteristics::EAlarmCharacteristicsSessionSpecific.

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.

The Session Alarm is completed when the alarm expires, is cancelled, or a timing error occurs.

NOTE: If the client session is closed before the alarm has expired, the Alarm Server automatically dequeues the alarm.

Synchronous Session Alarms

To add a session alarm to the queue synchronously, use RASCliSession::AlarmAdd().

Asynchronous Session Alarms

To add a session alarm to the queue asynchronously, use RASCliSession::AlarmAddWithNotification(). If a client decides to cancel a Session Alarm, it must use RASCliSession::AlarmNotificationCancelAndDequeue(). 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.

Non-Session Alarms

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.

Non-Session alarms are also referred as Orphaned Session alarms because these alarms are orphaned with no session owners.

Wake-Up Alarms

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.

It is set using RASCliSession::SetWakeup, by passing the unique identifier of the alarm.

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 EActiveWakeupAlarmSet value if there are active wake-up alarm(s) else, it sets EActiveNoWakeupAlarmsSet value.

KWakeupAlarmPubSubKey can be used to subscribe for wake-up alarm set and unset notifications. It belongs to the KAlarmServerPubSubCategory alarm Publish and Subscribe category. EActiveWakeupAlarmUninitialized is used to notify the listeners of KWakeupAlarmPubSubKey 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.

Skipped Calendar Alarms

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 Working with Skipped Alarms.

The Publish and Subscribe framework enables a client to receive notification from the Alarm Server about the skipped alarm. KMissingAlarmPubSubKey P&S key contains data about environmental changes and whether or not they have resulted in a skipped alarm. KSkippedAlarmInstancesPubSubKey P&S key supplies additional information that is required to search the Calendar store for instances with skipped alarms.