QtMobility Reference Documentation

Quickstart guide


The following steps outline how to make a simple "hello world" like application that uses Qt Mobility. It is assumed that Qt Mobility has been successfully built and environment variables have been set as per Installation Guide.

One can start using QtMobility with 3 simple steps.

  1. Include the appropriate headers
  2. Use the QTM_USE_NAMESPACE macro (defined in qmobilityglobal.h but implicitly included from any QtMobility header)
  3. Declare the usage of QtMobility and appropriate API(s) in the project(.pro) file

Steps 1 and 2 are shown in the example below:

 #include <QApplication>
 #include <QLabel>

 #include <QSystemInfo> //(1)


 int main(int argc, char *argv[])
     QApplication app(argc, argv);
     QSystemInfo s;
     QLabel *label = new QLabel(QObject::tr("hello ").append(s.currentCountryCode()));
     return app.exec();

This example uses the QSystemInfo headers to print out the system's current country code. All the domain APIs are wrapped within a Qt Mobility namespace and thus developers need to use the QTM_USE_NAMESPACE macro.

In step 3, to specify that our project is using System Information we declare in the project file:

 CONFIG += mobility
 MOBILITY += systeminfo

The project file states that the application uses Qt Mobility and that it requires the System Information API. By adding mobility to CONFIG qmake finds the mobility.prf file in $QTDIR/mkspecs/features and includes it when processing the current project file. mobility.prf is generated when running the QtMobility configure script and points qmake to the relevant include and prefix paths and ensures that deployment and package dependencies are set. The MOBILITY variable itself is part of mobility.prf and is used to determine the QtMobility library the current project should link to (in this example the SystemInfo library).

Each QtMobility API has its corresponding value which has to be added to MOBILITY. The subsequent table lists the APIs and the corresponding values that can be assigned to MOBILITY.

Bearer Managementbearer
Publish And Subscribepublishsubscribe
Service Frameworkserviceframework
System Informationsysteminfo
Document Gallerygallery
Tactile Feedbackfeedback

In addition the Mobility version and installed modules can be checked from within qmake project files. The associated module name for such tests is the same as above:

 contains(MOBILITY_VERSION, 1.1.1) {
     message(Mobility 1.1.1 detected)
 contains(MOBILITY_CONFIG, contacts) {
     message(Contacts API available)
 } else {
     message(Contacts API not available)

When developing on Symbian we will also need to add the required capabilites to the project file in order to satisfy the Symbian security model. This can be achieved with a line such as the following:


CAPABILITY_A and CAPABILITY_B are place holders for the appropriate Symbian capabilities. A complete list of all Symbian capabilities and their availability to application developers can be found in the Forum Nokia Symbian capability documentation.

The subsequent table provides an overview of possibily required security tokens for each QtMobility library. Note that not all tokens are always required when using a particular API. The exact list depends on which parts of an API is utilized by an application.

DomainSymbian CapabilitiesHarmattan Tokens (Aegis)
Bearer ManagementReadUserData NetworkServices (NetworkControl for QNetworkSession::stop())No token requirements known at this stage.
Connectivity - NFCLocalServicesNo token requirements known at this stage.
Connectivity - BluetoothLocalServices NetworkServices (ReadDeviceData WriteDeviceData for Pairing control)No token requirements known at this stage.
ContactsReadUserData WriteUserDataTrackerReadAccess TrackerWriteAccess GRP::metadata-users
LocationLocation LocalServices ReadUserData WriteUserData ReadDeviceData WriteDeviceData NetworkServicesLocation TrackerReadAccess TrackerWriteAccess
MultimediaUserEnvironment ReadUserData WriteUserData ReadDeviceData WriteDeviceDataGRP::video GRP::pulse-access
MessagingLocalServices ReadUserData WriteUserData NetworkServices UserEnvironment ReadDeviceData WriteDeviceDataCellular TrackerReadAccess TrackerWriteAccess
Publish And SubscribeCapability depends on P&S value being read/written. API itself doesn't require any capability.No token requirements known at this stage.
Service FrameworkNo capabilities requried by itself, the plugins may have capability requirements.No token requirements known at this stage.
SensorReadDeviceDataNo token requirements known at this stage.
System InformationLocalServices ReadUserData WriteUserData NetworkServices UserEnvironment Location ReadDeviceDatamce::TKLockControl mce::DeviceModeControl
VersitNo additional capabilities required.No token requirements known at this stage.
Document GalleryReadDeviceData WriteDeviceDataTrackerReadAccess TrackerWriteAccess
OrganizerReadUserData WriteUserDataTrackerReadAccess TrackerWriteAccess GRP::calendar GRP::metadata-users
Tactile FeedbackNo capabilities at this stage.No token requirements known at this stage.

The complete list of all Symbian capabilities and how they can be obtained can be found at Forum Nokia Symbian capability documentation.

And we're done. If you are using the command line simply enter:

 make //or nmake on Windows

to generate the executable which can then be run.

If you are developing for Symbian, to make a debug build for the emulator run:

 make debug-winscw

This assumes that qmake is in your %PATH% and Qt has been built for the emulator already.

To make a release build and SIS package for a device run:

 make release-gcce
 make sis

For further details on how to build applications for Symbian see The Symbian Platform - Introduction to Qt and Qt for Symbian


Thank you for giving your feedback.

Make sure it is related to this specific page. For more general bugs and requests, please use the Qt Bug Tracker.