Symbian3/PDK/Source/GUID-B01EDE29-0861-52B0-97BE-8B41E580817F.dita
author Dominic Pinkman <Dominic.Pinkman@Nokia.com>
Tue, 30 Mar 2010 11:56:28 +0100
changeset 5 f345bda72bc4
parent 3 46218c8b8afa
child 14 578be2adaf3e
permissions -rw-r--r--
Week 12 contribution of PDK documentation_content. See release notes for details. Fixes Bug 2054, Bug 1583, Bug 381, Bug 390, Bug 463, Bug 1897, Bug 344, Bug 1319, Bug 394, Bug 1520, Bug 1522, Bug 1892"

<?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-B01EDE29-0861-52B0-97BE-8B41E580817F" xml:lang="en"><title>Identifying
Optional Features</title><shortdesc>This document details how to identify optional features for querying
with the Feature Registry. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
<section id="GUID-EA8C9852-C613-51DC-8027-866FEE91EB39"><title>Feature UIDs</title> <p>Each
optional or managed feature on Symbian platform is given a 32-bit unique identifier
and represented by a <xref href="GUID-530281E6-29FC-33F2-BC9B-610FBA389444.dita"><apiname>TUid</apiname></xref>. The names of Symbian platform
features and their UID assignments are defined in the <filepath>featureUIDs.h</filepath> header
file. </p> <p>These names or UIDs are the argument values for the Feature
Registry query functions. The <i>granularity</i> of features is generally
quite coarse. Seldom will a feature correspond to a single API method or aspect
of its behaviour. Other approaches (beyond what is provided by the Feature
Registry) are generally required to detect these minor variations. Strong
guarantees of backward compatibility mean that existing functionality associated
with a feature or identifier may not change or be removed, though it may grow
in later releases. Functionality is only removed when the entire feature is
removed. </p> </section>
<example id="GUID-970828DC-81E0-506F-B96B-74DE79B38F1B"><title>Feature UIDs
example</title> <p>This code is an example of UIDs assigned to features to
be queried using the Feature Registry. </p> <codeblock id="GUID-71DAFE3B-381D-5F97-9449-CFF04DA91FCB" xml:space="preserve">namespace NFeature
    {
    const TUid KFax = {0x10279806};         // Sample only! Refer to true
    const TUid KPrint = {0x10279807};       // featureUIDs.h header file for
    const TUid KBluetooth = {0x10279808};   // actual names and UIDs (plus
    const TUid KInfrared = {0x10279809};    // proper in-code documentation
    const TUid KMmc = {0x1027980a};         // about each feature).
    const TUid KUsb = {0x1027980b};
    // . . .
    }</codeblock> </example>
</conbody><related-links>
<link href="GUID-747869DD-ECD1-5515-B876-0D7D753B1CD9.dita"><linktext>Optional
Features Query                 API</linktext></link>
<link href="GUID-9F9D6764-D86E-5665-B51A-04A4D3949FB4.dita"><linktext>Optional
Features                 Notification API</linktext></link>
<link href="GUID-F55EAA3A-5D30-5983-9053-7C3935D99802.dita"><linktext>Feature Registry
                Overview</linktext></link>
</related-links></concept>