diff -r 4816d766a08a -r f345bda72bc4 Symbian3/PDK/Source/GUID-F7CC81CE-E823-5196-944A-5F7524411A08.dita --- a/Symbian3/PDK/Source/GUID-F7CC81CE-E823-5196-944A-5F7524411A08.dita Tue Mar 30 11:42:04 2010 +0100 +++ b/Symbian3/PDK/Source/GUID-F7CC81CE-E823-5196-944A-5F7524411A08.dita Tue Mar 30 11:56:28 2010 +0100 @@ -1,43 +1,43 @@ - - - - - -Registration -and Discovery -

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.

-

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

- - - -

Clients of a service can discover which applications implement a particular -service by using RApaLsSession. This has a number of APIs -for retrieving an application list, filtered to only include applications -that implement a particular service. RApaLsSession 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.

-

Also see the 'Service list' section in Defining -application icons, captions and properties.

-
See also

Application -Architecture Overview

+ + + + + +Registration +and Discovery +

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.

+

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

+ + + +

Clients of a service can discover which applications implement a particular +service by using RApaLsSession. This has a number of APIs +for retrieving an application list, filtered to only include applications +that implement a particular service. RApaLsSession 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.

+

Also see the 'Service list' section in Defining +application icons, captions and properties.

+
See also

Application +Architecture Overview

\ No newline at end of file