Symbian3/PDK/Source/GUID-F7CC81CE-E823-5196-944A-5F7524411A08.dita
author Dominic Pinkman <Dominic.Pinkman@Nokia.com>
Tue, 30 Mar 2010 11:56:28 +0100
changeset 5 f345bda72bc4
parent 3 46218c8b8afa
child 9 59758314f811
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-F7CC81CE-E823-5196-944A-5F7524411A08" xml:lang="en"><title>Registration
and Discovery</title><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>Server applications need to advertise what services they provide and clients
of server application services need to know what implementations of the services
exist. This happens through Apparc's application registration file system. </p>
<p>Application registration files have a table in which applications can list
the service UIDs that they implement. For each service UID listed, there is
an associated opaque (i.e. not interpreted by the framework) data field which
indicates how the service is implemented by that application. The opaque data
field is accessed through an <codeph>LLINK</codeph> into a resource elsewhere
in the application registration file group. The meaning of this opaque data
field is not known to the framework, it will vary according to the service.
For some services the opaque data field may be a name intended for user display,
for others it may be structured data that the service's client-side code can
interpret. </p>
<fig id="GUID-84072240-5DC6-5900-B767-FD13666A6639">
<image href="GUID-7F7A449F-CC19-570C-A6C1-BC470256AA8C_d0e172642_href.png" placement="inline"/>
</fig>
<p>Clients of a service can discover which applications implement a particular
service by using <xref href="GUID-5EEE8745-F483-33C0-A5B1-AEB5544DE2BA.dita"><apiname>RApaLsSession</apiname></xref>. This has a number of APIs
for retrieving an application list, filtered to only include applications
that implement a particular service. <codeph>RApaLsSession</codeph> can also
return other information about server applications, including how the services
are implemented as described by the opaque data field. If a service uses the
opaque data field to store localised strings to describe implementations,
these can be shown to the user. If a service uses structured data, a resource
reader can be created over the opaque data field to extract the data. </p>
<p>Also see the 'Service list' section in <xref href="GUID-A6116E8B-9C4A-5B9E-AA8A-BE031408AA2F.dita">Defining
application icons, captions and properties</xref>. </p>
<section><title>See also</title><p><xref href="GUID-940F3F6E-BA9C-5E19-9AC5-D848B5E175FB.dita">Application
Architecture Overview</xref></p></section>
</conbody></concept>