Qt Mobility Whitepaper 1.0.0

The Qt Mobility Project presents a collection of related software frameworks and interfaces.The objective being to deliver new Qt APIs for mobile application developers. Using these newAPIs, developers will be able to create cross-platform applications targeting Maemo, Symbianand other platforms. This suite of features also has components that will be desirable to allusers, not just those with mobile devices, so Mobility has advantages even for the desktopuser.

Contents1. Introduction 22. The New APIs 3

2.1. Bearer Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3. Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4. Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4.1. Basic Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4.2. Sorting and Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5. Multimedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.6. Publish and Subscribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.7. Services Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.8. System Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3. Platform Support 183.1. Symbian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2. Maemo Platform Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4. Conclusion 18

Qt Mobility © 2010 Nokia Corporation and/or its subsidiary(-ies)

1. Introduction

The increasingly competitive world of mobile devices is driven by innovation and in-tegration. New devices demonstrate both of these factors cleverly integrating music,maps, mobile telephony, multimedia, sharing of self generated content, email and webinterfaces. The Qt Mobility Project is delivering a collection of APIs that will be the basisfor new applications across a range of mobile and non-mobile devices running Qt.

The Mobility Project presents a set of new APIs to developers.

API / Framework DescriptionBearer ManagementContacts

LocationMessagingMultimediaPublish and Subscribe

Service Frameworks

System Info

Controlling the system’s connectivity stateEnabling clients to request contact data from local andremote backendsReceiving location data using arbitrary data sourcesMessaging services, including SMS and email.Play and record media, and manage a collection of mediacontentRead item values, navigate through and subscribe to changenotificationsDiscover and instantiate arbitrary services.Discover system related information and capabilities.

There are many opportunities here for interesting and exciting applications. The APIs generallyintend to be an enabling technology, allowing developers to create a diverse range of applica-tions plugging into the underlying frameworks supplied by the Mobility Project. Mobility is notabout supplying ready made solutions but delivering the means to create great software withminimal effort, using your own skill and creativity.

The natural impulse is to view these to-be-developed applications as targeting a mobile phoneplatform. That is indeed a likely target, but it is not the only one. The decreasing size of PCs intothe size realm of phones and the increasing processing power and memory of phones meansthat thinking in terms of phone or netbook or even desktop is probably too restrictive. Devel-opers want applications that are portable between various devices and operating systems withminimal porting issues. Qt is known for its portability and good design so the support for mobiledevices is a natural step.

For a current list of the supported platforms , see the current Mobility Project documentation athttp://qt.nokia.com/doc/qtmobility-1.0/index.html#platform-compatability

2

http://qt.nokia.com/doc/qtmobility-1.0/index.html#platform-compatability


2. The New APIs

The Qt Mobility APIs are within the QtMobility namespace. This has been done to support futuremigration of Qt Mobility into Qt.

2.1. Bearer Management

The optimal WLAN or 3G connection for a phone depends on the purpose of the session andthe available access points. If the user is looking at a live video feed then she would want tomake sure that the connection was reliable, whereas if another user is web browsing then itdoesn’t really matter if he experiences a slight delay between the loading of components of theweb page. A user may also be interested in the costs of these different types of connections.The decision as to which connection is “best” depends then on various criteria of the particularservice being used.

The purpose of Bearer Management is to supply seamless, intelligent management and selectionof connections. The device can even bemulti-homed therefore supporting simultaneous sessionssuch as web, email or phone.

There are three classes of interest in Bearer Management. Network configuration for link layerconnections (QNetworkConfiguration), management of the network configurations (QNetwork-ConfigurationManager) and control of the network session (QNetworkSession).QNetworkSession manages both the network interface and the session. These classes can beused to first select a configuration from a list, say of Internet access points, select the preferredone, then use the configuration attributes to establish a connection and therefore a new session.

This snippet of code illustrates the use of each of these classes in a few lines.

A QNetworkConfigurationManager is created and used to determine the capabilities of theplatform and to access the default configuration for this system.

QNetworkConfigurationManager manager;const bool canStartIAP = (manager.capabilities() &

QNetworkConfigurationManager::BearerManagement);QNetworkConfiguration cfg = manager.defaultConfiguration();

The configuration is verified from the isValid() function and the previous test for capabilities

if (!cfg.isValid() || !canStartIAP)return;

Now, based on the type of connection defined in the configuration there is the possibility of acustom action based on the configuration. In this case the options are empty except for com-ments,

switch(cfg.type()) {

case QNetworkConfiguration::InternetAccessPoint:// no user interaction -> system starts IAP immediatelybreak;

3


case QNetworkConfiguration::ServiceNetwork:// no user interaction -> system determines best IAP in// group and starts itbreak;

case QNetworkConfiguration::UserChoice:// automatic IAP resolution by system or by asking user as// part of QNetworkSession::open() callbreak;

}

If the configuration is valid, the connection type can be opened. The developer can now make aconnection by opening a session,

QNetworkSession *session = new QNetworkSession(cfg);session->open();

4


2.2. Contacts

The Contacts API allows developers to manage contact data in a platform independent way. Italso provides amechanism for creating and using new data fields and defining new relationshipsbetween the data.

The illustration below shows a graphical summary of the Contacts API and how it functions.

Figure 1: Contacts Summary

For any given backend that stores the contact data, developers may implement a new QCon-tactManager class to interface to the new storage environment. Through this class all detaildefinitions and fields can be defined, and since the class is the base class for interfaces to variousplatforms, we get independence of the Contacts functionality from the backend.

A Contact ‘detail’ is a single, cohesive unit of information. It has defined semantics of usageand storage including component fields, data types and possibly associated metadata. To createa contact list the developer has to define the details and fields and restrictions on them, forexample some data may be read-only. Using the default details is easy, and adding a detail isnot difficult as will be shown later.

Here a simple code example creates a contact using the default fields using setters. The functionsaveContact() in QContactManager is then called to save the changes. The variable ’cm’ is apointer to a QContactManager object.The developer can create a contact object and set some of the attributes belonging to the object,using objects that relate to the particular detail that is to be updated. In this case the ContactName and the Phone Number.

5


QContact alice;

Create a contact name object and populate it with data

QContactName aliceName;aliceName.setFirst(”Alice”);aliceName.setLast(”Jones”);aliceName.setCustomLabel(”Ally Jones”);alice.saveDetail(&aliceName);

And now a phone number object setting the required attributes

/* Add a phone number */QContactPhoneNumber number;number.setContexts(QContactDetail::ContextHome);number.setSubTypes(QContactPhoneNumber::SubTypeMobile);number.setNumber(”12345678”);alice.saveDetail(&number);alice.setPreferredDetail(”DialAction”, number);

Finally, save the contact details

cm->saveContact(&alice);

How is a search for a contact done? The developer does not have to search only by name. TheContacts API supplies a set of functions to create filters on any defined detail, generating a list ofmatches.

Here the code looks for a matching contact based on an incoming phone call id. The filter iscreated, and specified by the definition and value ,

QContactDetailFilter phoneFilter;phoneFilter.setDetailDefinitionName(QContactPhoneNumber::DefinitionName,

QcontactPhoneNumber::FieldNumber);

phoneFilter.setValue(incomingCallNbr);phoneFilter.setMatchFlags(QContactFilter::MatchExactly);

A list of matches for the filter condition can now be generated.

QList<QContactLocalId> matchingContacts = cm->contacts(phoneFilter);...QContact match = cm->contact(matchingContacts.at(0));

Notice that with the instantiated QContactDetailFilter object it is necessary to identify the de-tail definition that will be used for the search, that is QContactPhoneNumber. The search tar-get value is then set, and the option for the kind of match is specified, in this case QContactFil-ter::MatchExactly. Any field could have been used and produced amatch list based on a particularsupplied search value. It could have been anniversary dates for today, or birthdays, or a particularcity if searching within the default address detail.

Having found the contact, the application may allow modifications, these are saved by a call tothe saveDetail() for the QContact object.

6


QList< QContactDetail > numbers =match.details(QContactPhoneNumber::DefinitionName);

QContactPhoneNumber phone = numbers.value(0);phone.setNumber(”123-4445”);...match.saveDetail(&phone);

When the change in the contact details has been completed the saveContact() function in QCon-tactManager is used to save all of the detail that has been associatedwith the contact and savedwith the saveDetail() function call.

The implementation of a contacts list is not restricted to the existing detail definitions. Thedevelopermaywish to add fields that she or hemay consider useful. Here is an example of addinga “Label” field to the email address of a contact. cm is a previously created QContactManagerobject.

First the detail definition that is to be modified must be identified,

/* Find the definition that we are modifying */QMap<QString, QContactDetailDefinition> definitions = cm->detailDefinitions();QContactDetailDefinition modified =

definitions.value(QContactEmailAddress::DefinitionName);

Now, a new field can be defined. The name of the field, “Label”, and the data type, QVariant,are used to create a newField object. The field object is inserted into the list of fields, returnedby the fields() function.

QContactDetailDefinitionField newField;newField.setDataType(QVariant::String);QMap<QString, QContactDetailDefinitionField> fields = modified.fields();

fields.insert(”Label”, newField);

Finally, the modified list of fields is used to update the detail definition modified and the mod-ified object is used by the QContactManager function saveDetailDefinition() to update the listof detail definitions.

/* Update the definition with the new field included */modified.setFields(fields);

/* Save the definition back to the manager */cm->saveDetailDefinition(modified);

One other aspect of the Contacts API to consider is the use of asynchronous calls to the datastore.The datastore may be remote or slow, which is best handled by the asynchronous features of theAPI. Access is made by placing asynchronous “requests” and then waiting for the response.

To perform an asynchronous request that does a lookup of a contact, we first create a filter aswe did previously. This time we use the setFilter() function on a QContactFetchRequest objectto prepare for the request and create a connect() call from the progress() signal in QContact-FetchRequest to a handler routine. Finally, invoke the start() function on the QContactFetchRe-quest object. Requests can also be done on a detail definition or on a relationship.

7


2.3. Location

The Location API gives the developer an easy to use interface to access positional information.The API abstracts the source of the information which can be a list of satellites or streamed datafrom other sources.

Figure 2: Location API Architecture

The classes in the API consist of containers for the positional data and classes that manage thesources of the data. Classes such as QGeoPositionInfo and QGeoCoordinate are containers forthe processed data for use by the developer. These are useful and easy to understand. However,the more important classes are those that deal with the source of data for the API: QGeoSatel-liteInfoSource, QGeoPositionInfoSource and QNmeaPositionInfoSource.QGeoSatelliteInfoSource is an abstract base class that allows the implementer to define the de-fault source of location data returned by the function createDefaultSource() for a particular plat-form. Someplatforms are already catered for so that the staticmethodQGeoSatelliteInfoSource::create-Default() can be called directly. If createDefault() fails then a zero value reference is returned.The QGeoPositionInfoSource class is also an abstract class with a static method createDefault-Source() with some platforms pre-defined.

The difference between these two classes is quite simply that QGeoSatelliteInfoSource man-ages satellite feeds of location data, and that QGeoPositionInfoSource manages the distribu-tion of location data whether it is from satellite data or another source.

QNmeaPositionInfoSource allows the developer to take a data source in NMEA format, then tobe used as if the user was using the QGeoPositionInfoSource class from which it is derived.NMEA is a data communications specification for various devices including GPS (Global Position-ing System) that communicates using an ASCII serial protocol. The developer can take the ASCIIstream of data from a device such as a GPS receiver or a data file.

When a data source is going to be used it will be necessary to call the startUpdates() function.

8


This maymean that an update period needs to be specified, depending on the class. QGeoSatel-liteInfoSource uses a timeout to indicate an error in receiving satellite updates. QGeoPosi-tionInfoSource and QNmeaPositionInfoSource allows the setting of the update interval usingsetUpdateInterval(), the signal positionUpdated() is emittedwith a reference to aQGeoPosition-Info object. Updates can be stopped with the stopUpdates() function.

This sample shows two of the classes being instantiated, started and stopped.

QGeoPositionInfoSource *m_location;

m_location = QGeoPositionInfoSource::createDefaultSource(this);

if (!m_location) {// Notify of error and exit from here...return;

}

QGeoSatelliteInfoSource *m_satellite =QGeoSatelliteInfoSource::createDefaultSource(this);

if (m_satellite) {...m_location->startUpdates();m_satellite->startUpdates();...m_location->stopUpdates();m_satellite->stopUpdates();

}

If the positionUpdated() signal is connected to a slot myPositionUpdated() then the followingcode could extract the data. This code is taken from the Qt Mobility Project example called“weatherinfo”. The slot receives a QGeoPositionInfo reference containing the data, the coor-dinate object is copied to m coordinate and the coordinate is given a sanity check.

void myPositionUpdated(QGeoPositionInfo gpsPos){

...m_coordinate = gpsPos.coordinate();if (m_coordinate.isValid()) {

The latitude and longitude are extracted

QString longitude;longitude.setNum(m_coordinate.longitude());QString latitude;latitude.setNum(m_coordinate.latitude());

Then the data is used and the updates are stopped.

requestTownName(longitude, latitude);m_gpsWeather = false;

9


m_location->stopUpdates();

One other class in the Location API is QGeoAreaMonitor. This class enables the developer todefine a region around a coordinate and then emit a signal when the current position indicatesthat the device is entering or leaving the region.

2.4. Messaging

2.4.1. Basic Messaging

The Messaging API enables a wide range of messaging types including email, SMS and MMS (Mul-timedia Messaging Service). The API supports storage functions for the messages, and notifica-tions of various actions on the stored messages can be enabled.

To demonstrate the API here is an example that shows how a message can be sent.

The developer creates a QMessage object and then sets the necessary message details. First setthemessage type, the default account formessages of the specified typewill be used for sending:

QMessage message;message.setType(QMessageAddress::Email);

Now a recipient is set

QString recipient(”[email protected]>”);message.setTo(QMessageAddress(QMessageAddress::Email, recipient));

For email a subject and a body are set, and any relevant attachments added

message.setSubject(”Example subject”);message.setBody(”Example body text”);

QStringList attachmentPaths;attachmentPaths << ”images/landscape.png”;

message.appendAttachments(attachmentPaths);

The message is ready to send. Next, create a service object and call the send() function

QMessageService *m_service = new QMessageService();

if (!m_service->send(message))QMessageBox::warning(0, tr(”Failed”), tr(”Unable to send message”));

2.4.2. Sorting and Filtering

Searching for messages is done by constructing a filter to perform amatch against the datastore.The filter is built by specifying a search condition, the property that is being matched, the value

10


of the property and the relation between the property and the value.

Since the filter condition could return a list of matching messages then sorting of the list maybe desirable. Sorting is performed with the Ordering functions. The QMessageManager classqueriesmessages for accounts, folders andmessages: queryAccounts(), queryFolders() and query-Messages(). These functions are used to search by a defined filter and/or to sort the list by a givenordering function.

To demonstrate this, consider a request to search for messages that are inbound. They can beidentified by using a QMessageFilter object

QMessageFilter filter(QMessageFilter::byStatus(QMessage::Incoming));

This resulting list would be more useful if it was in descending received date order, using aQMessageSortOrder

QMessageSortOrder sortOrder(QMessageSortOrder::byReceptionTimeStamp(Qt::DescendingOrder));

The filter specifies that the status is Incoming. The Ordering is by reception time stamp in de-scending order. It is now possible to get the list of results by calling the queryMessages() functionof the class QMessageManager, passing in the filter, the sortOrder and an integer specifying themaximum number of results to be returned, in this case 100.

const QMessageIdList matchingIds(manager.queryMessages(filter, sortOrder, 100));

Another interesting part of the Messaging API is the class QMessageService, which gives thedeveloper a common interface for various messaging services including native applications. Forexample, the compose() function can be implemented to invoke a native editor for messageconstruction.

11


2.5. Multimedia

The Multimedia API supplies ready to use calls for playing media, and functions that can be thebasis of more sophisticated applications.

The following example will show the fundamental features of this API with code fragments froma simple application that can record audio and play media.

The first step is to demonstrate recording audio to a file. When recording from an audio sourcethere are a number of things that the developer may want to control beyond the essential userinterface. He or she may want a particular encoding of the file, MP3 or Ogg Vorbis for instance,or select a different input source. The user may modify the bitrate, number of channels, qualityand sample rate. Here the example will only modify the codec and the source device, since theyare essential.

To begin, the developer sets up a source and a recorder object. A QAudioCaptureSource objectis created and used to initialize a QMediaRecorder object. The output file name is then set forthe QMediaRecorder object.

audiosource = new QAudioCaptureSource;capture = new QMediaRecorder(audiosource);

capture->setOutputLocation(QUrl(”test.raw”));

A list of devices is needed so that an input can be selected in the user interface

for(int i = 0; i < audiosource->deviceCount(); i++)deviceBox->addItem(audiosource->name(i));

and a list of the supported codecs for the user to select a codec,

QStringList codecs = capture->supportedAudioCodecs();for(int i = 0; i < codecs.count(); i++)

codecsBox->addItem(codecs.at(i));

To set the selected device or codec just use the index of the device or codec by calling the setterin audiosource or capture as appropriate, for example,

audiosource->setSelectedDevice(i);...capture->setAudioCodec(codecIdx);

Now start recording by using the record() function from the new QMediaRecorder objectcapture->record();

And stop recording by calling the matching function stop() in QMediaRecorder.capture->stop();

How then would this audio file be played? The QMediaPlayer class will be used as a genericplayer. Since the player can play both video and audio files the interface will be more complex,but for now the example will concentrate on the audio aspect.

12


Playing the file is simple: create a player object, pass in the filename, set the volume or otherparameters, then play. Not forgetting that the code will need to be hooked up to the user inter-face.

QMediaPlayer *player = new QMediaPlayer;...player->setMedia(QUrl::fromLocalFile(”test.raw”));player->setVolume(50);player->play();

The filename does not have to be a local file. It could be a URL to a remote resource. Also byusing the QMediaPlaylist class from this API the user can play a list of local or remote files. TheQMediaPlaylist class supports constructing, managing and playing playlists.

player = new QMediaPlayer;

playlist = new QMediaPlaylist(player);playlist->append(QUrl(”http://example.com/myfile1.mp3”));playlist->append(QUrl(”http://example.com/myfile2.mp3”));...playlist->setCurrentPosition(1);player->play();

To manipulate the playlist there are the usual management functions (which are in fact slots):previous, next, setCurrentPosition and shuffle. Playlists can be built, saved and loaded using theAPI.

Moving from audio to video requires few changes in the sample code. To play a video playlist theabove code can be changed to include another new Mobility Project class: QVideoWidget. Thisclass enables control of a video resource with signals and slots relating to control of brightness,contrast, hue, saturation and full screen mode.

player = new QMediaPlayer;

playlist = new QMediaPlaylist(player);playlist->append(QUrl(”http://example.com/myclip1.mp4”));playlist->append(QUrl(”http://example.com/myclip2.mp4”));...widget = new QVideoWidget(player);widget->show();

playlist->setCurrentPosition(1);player->play();

So with the addition of a few extra lines the playing of a video playlist is now possible.

13


2.6. Publish and Subscribe

The Publish and Subscribe API serves primarily as a means of easy inter-process communicationwith the capacity for notifications.

Often an implementer will need to communicate an event to interested parties in another pro-cess. For example, a received email producing a notification that is displayed on a desktop userinterface or a phone’s top level display. A publish and subscribe strategy provides the ability tonotify an arbitrary number of subscribers which register themselves with the publishing appli-cation.

To create a publisher, for a published value, an instance of QValueSpacePublisher is created andinitialized with a path. The path defines a “value space” that resembles a filesystem, with thepath specifying a “directory” that can be used to insert key / value pairs. The “key” is the pathto a “file” from the directory and the “value” could be the contents of the “file”. For example,if a publisher is created with a value space of ”/Device” then any keys inserted would start fromthat directory,

QValueSpacePublisher publisher(”/Device”);publisher.setValue(”State”, ”Starting”);publisher.setValue(”Memory”, ”1000”);publisher.sync(); /* Not usually required */

The code above defines two keys: /Device/State and /Device/Memory.

There are layer options that could have been used during the creation of the publisher object.The layers restrict listening subscribers and notifications to a special set of value spaces, such asa read-only layer.

The setValue() function takes a QString for the value name and a QVariant for the value itself.The sync() function then forces a synchronization of all of the value space using the same layeras this publisher, however this is usually not needed and the sync() call is shown here only forcompleteness.

At the Subscriber end of this relationship a QValueSpaceSubscriber object is created with thesame value space path that was used to create the publisher, and then the contentsChanged()signal is connected to a slot to process the changed data.

QValueSpaceSubscriber *subscriber = new QValueSpaceSubscriber(”/Device”);QObject::connect(subscriber, SIGNAL(contentsChanged()),

this, SLOT(infoChanged()));

The subscriber can then extract the changed data by getting the value on the known paths forthe attribute using the value() function. This function assumes, as a starting point, the path usedto create the “subscriber”, so there is no need to put the full path in the call

QVariant state = subscriber->value(”State”);QVariant memory = subscriber->value(”Memory”);

The subPaths() function could also be used to get all the paths directly under the current path(”/Device”).

14


2.7. Services Framework

The Services Framework could be considered a kind of glue that allows functionality to be sharedbetween many applications by means of the services they represent or are trying to use. Theframework gives the developer a device independent method of finding appropriate services,using the services and even implementing those services. The diagram below shows the rela-tionship of the Services Framework to the services provider and the rest of the Mobility API.

Figure 3: The Services Framework Architecture

What is a Service? A service is an independent component that permits a client to perform a welldefined operation. The definition seems abstract because a service can be many things.

A client can search for a service using the service name, version and the interface that the ser-vice object supplies. If the service has been found then the QServiceManager class functionloadInterface() can be used to create an instance of the interface.

Take, as an example, a File Manager service named ”FileManager”. First setup the filter for thesearch,

QServiceManager manager;QServiceFilter filter(”com.nokia.qt.examples.FileStorage”);filter.setServiceName(”FileManager”);

Next, locate the matching services

15


QList<QServiceInterfaceDescriptor> foundServices;foundServices = manager.findInterfaces(filter);

Now create an interface to the service, the fileStorage object is ready to be used.

QObject *fileStorage;fileStorage = manager.loadInterface(foundServices.at(0));

QMetaObject::invokeMethod(fileStorage, ”deleteFiles”);

The example now has a pointer to a generic object. The developer can then use Qt’s meta objectsystem to discover the FileManager interface without the need for prior knowledge about it. Theclient also does not have to link against specific libraries because the interface is discoverable.

Service interfaces can be implemented as plug-ins, derived from the QServicePluginInterfaceclass. A simple example is the Bluetooth transfer plugin described in the Services Frameworkdocumentation. The BluetoothTransferPlugin class is derived from QObject and QServicePlug-inInterface but implements only one function, createInstance(), which returns a new instanceof the object that implements the service.

QObject *BluetoothTransferPlugin::createInstance(const QServiceInterfaceDescriptor &descriptor,QServiceContext *context,QAbstractSecuritySession *session)

{return new BluetoothTransfer(this);

}

Note that future plans will mean there will be no need for a plug-in implementation because anIPC service solution will be available.

How are new services installed? The service metadata is described by an XML file which links theservice code to the metadata description. The same description is used for locating the service.A graphical tool, servicexmlgen, assists in the process of creating and editing the metadata tosimplify the process. A command line tool, servicefw, is provided as well to browse, search, addand remove services. Installing the service requires the developer to call the QServiceManagerfunction addService(), passing it the path to the XML file describing the service.

16


2.8. System Information

The System Information API provides a simple interface for accessing important informationabout the system. The returned information may be from any number of on-board or attacheddevices. It could be display information, screensaver settings, the battery power level, the stateof the network connection hardware or available languages amongst other possibilities. Thenames of the classes in this API clearly show the different types of information available: QSys-temDeviceInfo, QSystemDisplayInfo, QSystemInfo, QSystemNetworkInfo, QSystemScreen-Saver and QSystemStorageInfo.Using these classes is generally as simple as creating the object and calling the functionwewant.

// Battery level (range 1 - 100)QSystemDeviceInfo di;di.batteryLevel();

Some return values will have to be compared against enums specific to that class,

// Battery status (or using the batteryStatusChanged(int) signal)QSystemDeviceInfo::BatteryStatus status = di.batteryStatus();

switch (status) {case QSystemDeviceInfo::BatteryCritical:...

17


3. Platform Support

3.1. Symbian

The porting of Qt to the Symbian platform means that compatible Symbian devices will be ableto use the Qt Mobility Project APIs. However, because of the significant differences between adesktop system, with operating system support, and a Symbian device then some functionalitymay be unavailable.

3.2. Maemo Platform Support

Maemo devices are a high priority for Qt Mobility development with improved support with eachrelease. Qt Mobility supports Maemo 5 and 6 for many APIs. Check the compatibility table in theQt Mobility Documentation for the details of the current state of support.

4. Conclusion

The QtMobility Projectwill enable a newgeneration of Qt-style applications and services support-ing mobile and desktop devices. The APIs are well designed, easy to use, portable across manyplatforms and well tested. The applications developed using these APIs will therefore have thesame advantages as other Qt APIs that developers have come to know and use.

18

Nokia, the Nokia logo, Qt, and the Qt logo are trademarks of Nokia Corporation and/or its subsidiary(-ies)in Finland and other countries. Additional company and product names are the property of their respectiveowners andmay be trademarks or registered trademarks of the individual companies and are respectfullyacknowledged. For its Qt products, Nokia operates a policy of continuous development. Therefore, wereserve the right to make changes and improvements to any of the products described herein withoutprior notice. All information contained herein is based upon the best information available at the time ofpublication. Nowarranty, express or implied, ismade about the accuracy and/or quality of the informationprovided herein. Under no circumstances shall Nokia Corporation be responsible for any loss of data orincome or any direct, special, incidental, consequential or indirect damages whatsoever.

Copyright © 2010 Nokia Corporation and/or its subsidiary(-ies).

This document is licensed under the Creative Commons Attribution-Share Alike 2.5 license.For more information, see http://creativecommons.org/licenses/by-sa/2.5/legalcode for the full termsof the license.

http://creativecommons.org/licenses/by-sa/2.5/

http://creativecommons.org/licenses/by-sa/2.5/legalcode

Documents

Qt Mobility Whitepaper 1.0.0