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.

+ + + + + +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.

\ No newline at end of file