<?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-316ED912-04F7-5613-942E-516C3AB01C49" xml:lang="en"><title>Domain</title><shortdesc>A domain is associated with one or more applications, typically

the applications that take part in, or are associated with those activities. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

<p>Domains classify applications by their power requirements and dependencies.

A domain is defined as a type of activity, or a class of system services,

for example, telephony, networking, or camera. The exact definition depends

on the device. </p>

<p>A domain is associated with one or more applications, typically the applications

that take part in, or are associated with those activities. Applications register

with a domain, and are then said to belong to that domain. Domain population

by applications is a dynamic process, as applications can also leave a domain. </p>

<p>A domain has a power state, i.e. <i>Active</i>, <i>Standby</i> or <i>Off</i>.

The power state is updated by the domain manager through the publish &

subscribe mechanism. After registration with a domain, applications typically

maintain an outstanding request to be notified of changes to the domain's

power state. </p>

<p>Domains form a tree structure, with parent-child relationships. The architecture

permits power transitions to apply to specified domains either as a result

of user action, or by individual application request, or by the device's power

management policy. The domain tree defines the order in which power transitions

occur. </p>

<p>For transitions to the <i>Off</i> or <i>Standby</i> state, all applications

within a domain are notified of the transition; the transition is considered

complete for a domain when all of its applications have acknowledged the transition

(and completed whatever action they deem necessary to save their state). Notification

proceeds from child domains up to the parent domain. A domain transition can

only start when all of its child domains have successfully completed their

power state transition. </p>

<p>For transitions to the <i>Active</i> state, notification happens in the

reverse order, starting with the parent domains and proceeding down the tree

to the child domains. </p>

<fig id="GUID-90A60E81-1461-5CF7-9BA5-94AFAE96635D">

<image href="GUID-4710494E-835F-50B8-B0B5-0482147C02D2_d0e384645_href.png" placement="inline"/>

</fig>

<p>Domains are identified by a domain Id. This is an 8-bit wide number and

is defined as being of type <xref href="GUID-4F284AB0-85A5-3871-B973-8BCAB4AA91BC.dita"><apiname>TDmDomainId</apiname></xref>. The Symbian platform

defines two generic domain Ids: <xref href="GUID-766E2EA6-AB0C-3631-AC82-AA0B98E5D4BE.dita"><apiname>KDmIdApps</apiname></xref> and <xref href="GUID-1D54EF94-5744-350D-87B6-5EE87BDD17E5.dita"><apiname>KDmIdUiApps</apiname></xref> in <filepath>domaindefs.h</filepath>.

However, the <xref href="GUID-1197F032-1B73-58E1-8B45-E5D58B9DF788.dita">Domain

Management Policy DLL</xref> can define additional policy-specific domain

identifiers. </p>

</conbody></concept>