Alarm Server Overview

Alarm Server is a system server, which starts during device start-up. It is responsible for maintaining a queue of all system-wide alarms.

It allows clients to query the status of alarms, set alarms, remove alarms and perform other utility functions. The Alarm client API allows other components to interact with the Alarm Server. The Alarm Server sends notification of alarm expiry to the Alert Server, which then notifies the Alarm UI to display dialogs and play sound.

The typical clients of Alarm Server include Clock and Calendar applications.

Purpose

The Alarm Server manages the alarms in the system and provides the following functionality:

  • adding, updating and deleting alarms.

  • getting and setting client-specific data associated with the alarm.

  • performing alarm category-based operations such as retrieval and deletion. Retrieving alarm information includes alarm count, unique identifiers based on alarm states.

  • getting and setting Alarm Server’s global sound state and play intervals.

  • notifying the client when alarm settings change and when the alarm expires.

Key concepts and terms

Duration

It is the time period, in seconds, for which the alarm sound is played.

Offset

It is the time (in minutes) duration of alarm sound played after the alarm expiry.

Alarm play interval

Alarm play interval consists of duration and an offset. At each offset, the Alarm Server makes a request to the Alarm Alert Server to display the alarm dialog and play the alarm sound.

Universal Time Coordinated (UTC)

It is the international time standard. It is the current term for what was commonly referred as Greenwich Meridian Time (GMT) . Zero hours UTC is midnight in Greenwich England, which lies on the zero longitudinal meridian. Universal time is based on a 24-hour clock. Therefore, afternoon hours such as 4 PM are expressed as 16:00 UTC.

Daylight Saving Time (DST)

Daylight Saving Time or Summer Time, is a way of utilizing more daylight by advancing the local time by one hour during the summer.

Session alarms

The alarms that are removed from the alarm queue when their session owners disconnect are referred as Session Alarms.

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. These alarms are also referred to as Orphaned Session alarms.

Wake-Up alarms

An alarm that wakes-up the device if the device is switched OFF when the alarm occurs, is referred to as Wake-Up alarm.

Skipped/Missed Calendar alarms

An alarm which 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.

Architecture

Alarm Server is implemented using the Symbian platform IPC client-server architecture. It has an interface to the Alarm Alert server, which is delivered as part of the Application Framework (UIKON component). Alarm Alert Server is responsible for displaying the alarm dialog when an alarm expires. The Alarm Server implements the Alarm Alert server’s client side DLL to send and receive notifications to and from the Alarm UI. Alarm Alert Server is a part of the UIKON server (Eiksrv.exe). The Alarm Server itself implements the client-side APIs since it is the only client for the Alarm Alert server. The following diagram illustrates the Alarm Server architecture:

Figure 1. Alarm Server Architecture

Alarm Client and Alarm Shared

They are the static interface DLLs. Alarm client is the client side of the Alarm Server, which allows other components to interact with the Alarm Server.

The Alarm Shared facilitates a common format shared across server and its clients for providing definition for an alarm. It consists of shared objects such as alarm class, IPC messages, repeat definitions, alarm states.

Alarm Server

Alarm Server manages all alarms on the device and enables client UI applications to use the services provided by the Alarm Server. It relies on the Alarm UI to notify, which includes displaying and playing sounds.

It uses a resource file to configure the sound intervals required for the alarm to repeat. The compiled resource file resides in the private directory of the Alarm Server. The resource file is used only for initial configuration.

Alarm Server configurations are stored in AlarmServer.ini file and Backup_Registration.xml file performs a passive backup of this .ini file to the PC-side at runtime. For secure backup of this .ini file, backuprestorenotification.lib is used. For more information on the resource file and backup, refer to the Alarm Sound Play Control.

It provides Publish and Subscribe keys to enable the client to receive notifications of the changes to the Alarm Server. The P&S key are:

  • KMissingAlarmPubSubKey - provides information about missed calendar alarms, which were missed due to the device being in the shutdown state.

  • KSkippedAlarmInstancesPubSubKey - provides information about skipped calendar alarms instances which can used for searching the required data in the calendar store.

  • KWakeupAlarmPubSubKey - provides information about an active wake-up alarm which is set or unset.

For more information on Skipped Calendar Alarms and Wake-up Alarms, refer to Types of Alarm section.

It listens to the following events:

  • DST rollover - Using KDSTChangePropertyKey P&S key, Alarm Server listens to DST rollover information from Time Zone Server resulting in the change of wall clock/local time clock.

  • System state changes - Using System State Manager (SSM), Alarm Server listens to the system state changes (normal and shutdown states) to synchronize the backup of the alarm server queue to the AlarmServer.ini backup file.

  • Environment change - Using Environment Change Notifier (bafl.dll), Alarm Server listens to the changes in the environment, such as system time/date change, workdays change or UTC offset change.

UIKON Server

UIKON server is responsible for starting the Alarm Server at the device boot-up, by loading the polymorphic DLL, EIKSRVUI provided by the device creator.

It is also responsible for playing sounds, flashing lights and displaying the message. Through the UIKON server, alarms can be cleared, snoozed or silenced. Alarm server implements and uses the client side interface. Alarm UI implements the server side of the UIKON server.

APIs

The Alarm Server provides the following client API:

API Description

RASCliSession

Client interface to the Alarm session.

Typical uses

The following are the typical use cases of Alarm Server:

  • Using Alarm Server to add, update and delete alarms, set alarm status and so on.

  • Playing an alarm continuously.

  • Activating an alarm on specified days.

Related reference
Alarm Server Reference