Files:
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.
Steps 1 and 2 are shown in the example below:
#include <QApplication> #include <QLabel> #include <QSystemInfo> //(1) QTM_USE_NAMESPACE //(2) int main(int argc, char *argv[]) { QApplication app(argc, argv); QSystemInfo s; QLabel *label = new QLabel(QObject::tr("hello ").append(s.currentCountryCode())); label->show(); label->resize(100,30); 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.
Domain | Value |
---|---|
Bearer Management | bearer |
Contacts | contacts |
Location | location |
Multimedia | multimedia |
Messaging | messaging |
Publish And Subscribe | publishsubscribe |
Service Framework | serviceframework |
Sensors | sensors |
System Information | systeminfo |
Versit | versit |
Document Gallery | gallery |
Organizer | organizer |
Tactile Feedback | feedback |
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:
load(mobilityconfig) contains(MOBILITY_VERSION, 1.1.1) { message(Mobility 1.1.1 detected) } contains(MOBILITY_CONFIG, contacts) { message(Contacts API available) CONFIG+=mobility MOBILITY+=contacts } 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:
TARGET.CAPABILITY = CAPABILITY_A CABAPILITY_B
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.
Domain | Symbian Capabilities | Harmattan Tokens (Aegis) |
---|---|---|
Bearer Management | ReadUserData NetworkServices (NetworkControl for QNetworkSession::stop()) | No token requirements known at this stage. |
Connectivity - NFC | LocalServices | No token requirements known at this stage. |
Connectivity - Bluetooth | LocalServices NetworkServices (ReadDeviceData WriteDeviceData for Pairing control) | No token requirements known at this stage. |
Contacts | ReadUserData WriteUserData | TrackerReadAccess TrackerWriteAccess GRP::metadata-users |
Location | Location LocalServices ReadUserData WriteUserData ReadDeviceData WriteDeviceData NetworkServices | Location TrackerReadAccess TrackerWriteAccess |
Multimedia | UserEnvironment ReadUserData WriteUserData ReadDeviceData WriteDeviceData | GRP::video GRP::pulse-access |
Messaging | LocalServices ReadUserData WriteUserData NetworkServices UserEnvironment ReadDeviceData WriteDeviceData | Cellular TrackerReadAccess TrackerWriteAccess |
Publish And Subscribe | Capability depends on P&S value being read/written. API itself doesn't require any capability. | No token requirements known at this stage. |
Service Framework | No capabilities requried by itself, the plugins may have capability requirements. | No token requirements known at this stage. |
Sensor | ReadDeviceData | No token requirements known at this stage. |
System Information | LocalServices ReadUserData WriteUserData NetworkServices UserEnvironment Location ReadDeviceData | mce::TKLockControl mce::DeviceModeControl |
Versit | No additional capabilities required. | No token requirements known at this stage. |
Document Gallery | ReadDeviceData WriteDeviceData | TrackerReadAccess TrackerWriteAccess |
Organizer | ReadUserData WriteUserData | TrackerReadAccess TrackerWriteAccess GRP::calendar GRP::metadata-users |
Tactile Feedback | No 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:
qmake
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:
qmake
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:
qmake
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