Skip to content

A Peek to Maemo 6 UI Framework, Part IV – Service Framework

This article of Maemo 6 Service Framework continues the series of “A Peek to Maemo 6 UI Framework” articles. There are older articles parts I, II, and III if you haven’t read them yet. The Maemo 6 UI Framework is quite large (almost 100 000 lines of c++ code) therefore I want to introduce larger modules rather than smaller things like single widgets. I want to make the reader to understand what you can do with the UI framework, how you can design your application (MVC + layouts) and how you can use services that platform provides or introduce your own services.

Because we are dealing a huge UI/Application Framework  which each application in Maemo 6 device should use, there must be some kind of centralized way to make applications provide public interfaces for other applications. This is where Service Framework comes to the picture.

I checked a doxygen documentation of the Maemo 6 UI framework and there is own section for Service Framework. The following bullet list is derived from the Service Framework documentation. The objectives of Service Framework are:

  1. Provide a simple IPC mechanism
  2. Remove run time binary dependancy between the service user and provider
  3. User of an interface doesn’t need to worry about the logic of choosing or connecting to an interface.
  4. Provides an interface for querying a list of providers and choose one of them

They also state in the documentation that Service Framework can be used for example launching another application such as a web browser or showing recent contacts. I guess this means that each application in Maemo 6 platform can provide a specialized interface to other applications that may be interested in such a service.

Service Framework Design

Service Framework is a convenience layer built on top of dbus. Basically what it does is, it introduces an easier way to use a service in client side. This means that client doesn’t need to care anything about dbus session types, paths or interface names. What a client needs to do is to create an instance of the service interface class and call any of the interface methods it provides. Sounds easy and it really is quite simple to use.

I took a look into a code and it seems that there is an application called duiservicemapper which is being ran in the background. The purpose of the duiservicemapper is: to provide information about available services, information if the service is not available or if the service has changed. I guess the service can be changed “on-the-fly” if you update an application and it has changed its service framework implementation (the service file has been changed due the update). The duiservicemapper also monitors service files directory e.g. “/usr/share/dbus-1/services”. So Maemo 6 will extend the dbus a bit and Service Framework needs an “extra binary” in order to work.

In the client side, there is a base class DuiServiceFwBaseIf which provides the common functionality for all the Service Framework client implementations. Actually DuiServiceFwBaseIf is a client for duiservicemapper service. When you create a client,  it inherits the DuiServiceFwBaseIf class and from there it gets the information about all the available services and it does the dbus connection to the correct session and so on.

I think that the best way to understand how Service Framework works is via sequence diagram. After the next chapter there is a one diagram which should help you to get the overall picture.

Service Framework Usage

How do you create a service and start to use it? If you are familiar how you can use dbus in Qt, there is not much difference for that. In Qt, the preferred way  to define interfaces is, that you define them in XML. Then you use a special tool called qdbusxml2cpp to generate the interface (client interface) and the adaptor (service implementation) classes. The client classes you can use almost directly, but you need to provide the actual implementation for the adaptor methods that can be called over dbus. I don’t go very deep to the details here, but there are good examples and documentations that you can check if you’re interested in:

Creating an Adaptor

The adaptor code generation and service implementation is identical to Qt’s way to do it. First you need the XML. Note: For some reason I had too many problems making the XML visible in WP, so check this link in order to see how to define the XML.

Then you need to generate the adaptor code from the XML:

qdbusxml2cpp -c MyAdaptor  -a myadaptor.h:myadaptor.cpp myserviceif.xml

After this you are almost there, but you need to do the following things:

  • Provide the implementation for the adaptor class (MyService).
  • Pass the instance of MyService as a parent to the generated adaptor class (MyAdaptor).
  • Make the dbus connection and of course start Qt’s event loop, but that should be obvious.
 MyService * service = new MyService;
 new MyAdaptor( service );

 QDBusConnection connection = QDBusConnection::sessionBus();

Creating a Client Interface

I don’t have a working Maemo 6 UI Framework running so I couldn’t give a try how this really works and most of the text in this article is based on the doxygen documentation of the Maemo 6 UI Framework. However there is demo app available in the git repository so I have made my conclusions based on that. You can check the demo code from here.

The client side creation is the part where things go differently if comparing to QtDbus. Maemo 6 UI Framework introduces a new tool called duiservicefw-gen which creates classes needed for the client side usage.

duiservicefw-gen myserviceif.xml

What this does is, that it creates two classes: MyServiceIf  and MyServiceIfProxy. The MyServiceIf inherits the DuiServiceFwBaseIf i.e. it gets the duiservicemapper functionality discussed earlier and the MyServiceIfProxy class inherits QDbusAbstractInterface class. MySerfviceIfProxy sort of “hard codes” the interface name and provides the concrete interface methods that are defined in XML. In the constructor of MyServiceIf, it “asks” from the duiservicemapper if the service is available. MyServiceIf also provides the callable interfaces for the service, but it calls the “real” interfaces from the MyServiceIfProxy class. To make things more clear, check the following list or check the sequence diagram below:

  • MyServiceIfProxy is the actual interface and it provides the methods that call the adaptor side implementation.
  • User of the service creates the instance from MyServiceIf.
  • MyServiceIf connects to the duiservicemapper to check if the service is available and it creates the instance of MyServiceIfProxy.
  • Interface that MyServiceIf provides, calls the interface of MyServiceIfProxy

The Interaction

I’m not gonna draw any class diagrams here because Service Framework implementation contains only couple of classes and the rest of the classes are either generated or then the app developer must implement them. Instead I’d like to show you how the classes interact with each others. I believe that best way to do it is to draw a sequence diagram.


Thoughts about Service Framework

If you have read my previous posts about Maemo 6 UI Framework there have always been sort of “review part” at the end of the post. This post is not an exception:) Btw, this time I don’t go through the code in this review part, because of lack of time. So here are my thoughts about Service Framework.


  • From the service user’s point of view, this mechanism seems to be quite easy to use
  • Using XML for service definition makes the code to easier to maintain
  • You can always “skip” the Service Framework part and use the plain dbus. In Qt this is really easy. (This is on purpose in both pros/cons sections)


  • I understand that Nokia has used to of using dbus in Maemo devices, but I think there are quite many problems when using dbus. Btw, I believe that someone in Nokia has already thought of these issues, but I will put them here in anyway
  • Dbus is is public – with this I mean that everyone can see what is send via dbus e.g. with dbus-monitor that is quite easy to do. What if you have to send some private data via dbus? I know you can always encrypt things but still it’s all visible.
  • You can always “skip” the Service Framework part and use the plain dbus. In Qt this is really easy. (This is on purpose in both pros/cons sections)
  • With this approach it is quite easy to create fake services and replace the original one because the adaptor side doesn’t provide any mechanism to make sure that client is calling the exact service that it should.

Questions / Comments

  • There is Qt Mobility project and it contains another Service Framework. I’m not so familiar with that project, but it should be available for maemo 6 also at some point. I also gave a quick look to Qt Mobility’s Service Framework code and it looks like it has some kind of security  management also. So the question here is that how these two different Service Framework implementations will fit together and what are roles will they play? Both of them seem to have targeted to Maemo 6?
  • Addition: I found an “old” blog entry about Qt’s Service Framework. See it here.
Marko Mattila on sabtwitterMarko Mattila on sabinstagramMarko Mattila on sabgoogleMarko Mattila on sabflickr
Marko Mattila
Marko Mattila is a nerd, father, husband, snowboarder, photographer, mountain biker, runner and I love open source.

This is a blog, where I share my thoughts about technology or sometimes about life in general.
Published inMaemoProgrammingQt


Leave a Reply

Your email address will not be published. Required fields are marked *