Technology Comparison


This section provides a high-level comparison of the architecture of mobile applications developed for Android with applications created with Qt for Nokia platforms. The goal of this section is to help developers that are familiar with Android application development get a clear understanding of the architecture of Qt applications.

The following is covered:

  • Android Activities and Layouts and how those are translated into Qt concepts.
  • Services.
  • Content Providers.
  • Broadcast Receivers.

Where a strict one-to-one mapping between an Android and a Qt concept does not exist, an alternative implementation strategy will be discussed.

After reading this section Android developers should find it easy to map any Android application 's architecture to the corresponding Qt application architecture.

Activities and Layouts

Activities are the basic visual building blocks of Android apps. The Android runtime does not strictly limit or govern relationships between Activities and views. The best practice, however, is to have one Activity for every view.

Qt does not have a real counterpart for Activities, instead the responsibilities of the Activity class are split between several different components:

  • Simple domain classes or Qt State Machines for keeping track of application or component state.
  • A QmlApplicationViewer for displaying the UI (an automatically generated class created by Qt Creator).
Android Layouts correspond to QML components, essentially separate QML files.

Changing views within an application

In Android, an application's views generally correspond to its Activities, and the mechanism for changing Activities is the Intent. Intents can be used within an app, or (if permitted) to launch an Activity in another app. The following diagram demonstrates the use of Intents within an app, and outlines the part that is most relevant for the following discussion.

Figure 1. Starting an Activity with an Intent

In Qt Quick apps, the same thing can be achieved in different ways. If you are using Qt Quick components, you can use the PageStack element to easily implement in-app navigation between different views or pages. Page transitions are animated and you get a logical flowing user experience where new views get pushed to the stack and the back button brings the user back to the previous view. The outlined part corresponds to the outlined part in the Android diagram.

Figure 2. Moving between views in a a Qt Quick components app

For custom UIs there are a couple of options. QML can directly load other QML using the Loader element. Another option is to make C++ application logic class instances accessible to the UI as Context Properties. Signals and slots can then be used to communicate important UI events to them. The following diagram shows a similar scenario as the diagrams above but from the perspective of a Qt Quick app with a custom QML UI.

Figure 3. Moving between views in a Qt Quick app

An good example where the Loader element might instead be used is when a part of the view is shared, such as a toolbar of common controls. In this case the root view can have a Loader element where the "pages" of the app are displayed. Then, instead of calling setMainQmlFile to replace the whole layout, the application logic can set the source property on the Loader to switch to a different view.

Launching other applications

If an Android app is granted the relevant permission, it can use an Intent to start an Activity in another application. The same can be achieved in a Qt applications by using:

For most apps, the first case is the more relevant one. In this case another developers app provides a view to some stored content. In your app, you want to provide users with the ability to view this content without having to implement the viewing functionality yourself. Here you can use the QDesktopServices class, from the QtGui module, that has a method called openUri. This method implements the functionality in a platform-agnostic manner, so it will work on desktop PC as well as a mobile phone. The method takes a QUrl argument that points to the file to be opened, and launches the correct handling application on any platform. The sequence diagram below illustrates how to use this method to launch another application.

Figure 4. Launching another application from a Qt Quick application


Servies in Android and Qt work differently. Android Services enable apps to start background tasks that continue working even when the user switches to another app, while Qt apps have no explicit restrictions related to multitasking (except that they are terminated when system resources are exhausted). Qt apps do not therefore need services for background work. That is not to say Services are not useful for this purpose: for the sake of design and ease of maintenance it could be useful to implement for example a media player application as separate front-end app and player service components.

For implementing services and the clients that consume them, refer to the documentation for the Qt Service Framework. Example code can be found in the Qt Mobility Git repository. A good starting point is the echo service, in that it demonstrates both service and client implementations: http://qt.gitorious.org/qt-mobility/qt-mobility/trees/master/examples/sfwecho.

Content Providers

Content providers are Android's way of providing apps access to common data such as media and contacts, while at the same time preventing unauthorized access. In Qt, this functionality is provided by a group of APIs in Qt Mobility, and it is used by apps and services just like any other API, without the need for special architectural considerations:

Broadcast Receivers

Android's Broadcast Receivers are special application components that receive system-wide notifications like "battery low" or "incoming call". Some of this information is available to Qt apps via the Qt Mobility System Information API.

Last updated 17 November 2011

Back to top