|Home · All Classes · Main Classes · Deprecated|
The service framework is an IPC mechanism that allows applications to simply either use or serve an interface. For the purposes of this documentation, the interface user process is referred to as 'user' and the interface provider process is referred to as the 'provider'.
The objectives of the service framework are :
The basic service framework mechanism.
The above diagram shows what happens behind the scenes when a Service User (SU) uses an Interface (IF).
The service mapper will send signals to the corresponding SU interfaces to inform them when there is a new SP for the IF, or if there are no more SPs for the IF. The application should connect to the signals in the IF in order to tell when these events occur and to take appropriate action. For example, a gallery application may wish to allow a user to send a photo via email and it might listen to the 'no more SP for IF' signal in order to tell when to disable the option.
Service Framework should not be used for generic IPC communication purposes or, for example, communication between applets. This should be done using other means like using a data backend that provides notifications of changes to values like MValueSpace.
Two things are required of the developer of an SP :
Create an XML file that defines the interface.
If you wish a method to be chained to the current application, you can add a 'chainTask="true"' attribute to the method tag. If you wish a method to be asynchronous, you can add an 'asyncTask="true"' attribute to the method tag. Note that such methods must not have any 'out' parameters.
<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd"> <node> <interface name="com.nokia.TextProcessorInterface"> <method name="reverse" chainTask="true"> <arg name="message" type="s" direction="in"/> <arg name="" type="s" direction="out"/> </method> <method name="blinkScreen" asyncTask="true"> <arg name="message" type="s" direction="in"/> </method> </interface> </node>
Run the m-servicefwgen tool to generate the adaptor h and cpp files, for example :
m-servicefwgen -a com.nokia.TextProcessorInterface
Change your code.
There are three steps that are illustrated in the following code snippet :
// 1. Make an instance of the class that has methods that implement the interface functionality MyService myService; // 2. Make an adaptor to link the dbus methods with the methods in myService // According to QDBusAbstractAdaptor(), this must be on the heap, // and memory is owned by QDBusAbstractAdaptor, so no need to keep pointer new MyServiceIfAdaptor( &myService ); // 3. Connect to session bus and register this service QDBusConnection connection = QDBusConnection::sessionBus(); bool ret = connection.registerService("com.nokia.TextProcessor"); // continue with rest of app return app.exec();
There are three steps to defining an interface.
Run the m-servicefwgen tool to generate the proxy header and cpp files, and the wrapper header file. For example :
m-servicefwgen -p com.nokia.TextProcessorInterface
The above files should be made part of the maemo-interfaces package. The library should be in maemo-interfaces, and the header and xml files should be in maemo-interfaces-dev.
Documentation for an interface and its methods can be added between '<doc>' and '</doc>' tags, as follows :
<interface name="com.nokia.someserviceinterface"> <doc> <arg tag="brief">brief documentation for the interface</arg> <arg tag="details">detailed documentation for the interface</arg> </doc> <method name="showPage"> <doc> <arg tag="brief">brief documentation for showPage() method</arg> <arg tag="details">detailed documentation for showPage() method</arg> </doc> <arg name="targetPage" type="s" direction="in" /> <arg name="previousPage" type="s" direction="in" /> <arg name="" type="b" direction="out"/> </method> ....etc
In libmeegotouch/demos/servicefw/ there is example code showing three service providers and a service user. The com.nokia.textprocessor and org.maemo.textprocessor services both implement the same interface - com.nokia.TextProcessorInterface. There are two services so that we are able to remove services and see that the service user is switched from one service to another/etc. There is one script tools/m-servicefwgen, which is used to generate the source files that are used to define the interface to the service user. To run this demo :
In this demo, you can remove the various service files from /usr/share/dbus-1/services to simulate the service being removed (and added again) and see that the service user application 'does the right thing'.
|Copyright © 2010 Nokia Corporation||Generated on Thu Nov 4 2010 18:14:23 (PDT)