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

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:

+ 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 +listens to the following events:

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.

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 Alarm session on Symbian Platform.

+ + + +

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.