<?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 &amp;
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_d0e379068_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>