diff -r 43e37759235e -r 51a74ef9ed63 Symbian3/SDK/Source/GUID-DCA2880E-7DF9-5E60-8F87-241711935389.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-DCA2880E-7DF9-5E60-8F87-241711935389.dita Wed Mar 31 11:11:55 2010 +0100 @@ -0,0 +1,68 @@ + + + + + +FeatMngrExample: +dynamic feature management exampleThis example demonstrates the use of Feature Manager APIs for dynamic +feature management. It also demonstrates how to receive notification about +changes to a feature. +
Download

Click on the following link to download +the example: FeatMngrExample.zip

Click: browse to view the example code.

+
Purpose

The example shows how to use the Feature Manager API. +UI vendors and device manufacturers can use this API to declare features (such +as DRM agents, codecs, vibra) as available or not. The feature set can be +adjusted dynamically as software services are installed and uninstalled or +as platform capabilities are discovered dynamically.

This example +shows how Feature Manager APIs allow applications and system software to establish +which features are present on or absent from a Symbian device.

+
Design and implementation

The example consists +of two processes:

    +
  • featmngrexample.exe: +this is the main process which provides the list of available features. It +also provides the option to add new features or delete/update a feature.

  • +
  • featurechecker.exe: +this process receives notification about new features installed or uninstalled +by the main process.

  • +

FeatMngrExample

This shows the use of the RFeatureControl API +to manage features.

It presents menu options to the user to list the +available features, to add or delete a feature, update an existing feature, +and to enable or disable a feature. It also starts another process, called +featurechecker.exe which receives notifications of events happening in this +process. The list of features includes some whose feature flags are non-modifiable. +Any attempt to modify or delete those features will result in a system error +-21 (KErrAccessDenied). When adding a new feature, it should +be in the range as described in the console because the featurechecker process +subscribes to this range of features for change notification.

FeatureChecker

This +process is started by featmngrexample.exe. It implements +the MFeatureObserver class to handle notification of feature +changes. FeatureChecker also demonstrates the use of the CFeatureNotifier class. +It implements HandleNotifyChange() to handle the changes +made by FeatMngrExample. The type of change is displayed to the user as an +infoprint message (User::InfoPrint()). HandleNotifyChange() is +called to handle changes for those features which are subscribed to for notification +(in the NotifyFeatureL () method).

+
Building and configuring

To build the example:

    +
  • The example builds two +executables called featmngrexample.exe and featurechecker.exe in +the standard locations. The second executable is run by the first.

  • +
  • You can build the example +from your IDE or the command line.

    If you use an IDE, import the bld.inf file +of the example into your IDE, and use the build command of the IDE.

    If +you use the command line, open a command prompt, and set the current directory +to the source code directory of the example. You can then build the example +with the SBSv1 build tools with the following commands:

    bldmake +bldfiles

    abld build

    How to use bldmake and How to use abld describe +how to use the SBSv1 build tools.

  • +
+
Running the example

When running the example, the +user is presented with various menu options that are self-explanatory. Press +any other key to exit.

+
See also:

Feature Management

+
\ No newline at end of file