Porting Applications from QtMobility Sensors to Qt SensorsOverviewThe initial release of Qt Sensors (5.0) is generally expected to be source compatible with QtMobility Sensors 1.2. This document attempts to explain where things must be changed in order to port applications to Qt Sensors. QMLCompatibility for QML applications is provided by shipping the legacy QtMobility.sensors QML import. QML applications should not require any changes to continue operating. Applications using the legacy QML import may not be able to trivially port over to the new QML import because the new QML import does not provide elements for every sensor like the legacy QML import does.
C++IncludesQtMobility Sensors installed headers into a Qt Sensors directory. This is also the directory that Qt Sensors uses. It is therefore expected that includes that worked with QtMobility Sensors should continue to work. For example: #include <QAccelerometer> #include <qaccelerometer.h> #include <QtSensors/QAccelerometer> #include <QtSensors/qaccelerometer.h> Macros and NamespaceQtMobility Sensors was built in a QtMobility namespace. This was enabled by the use of various macros. Qt Sensors does not normally build into a namespace and the macros from QtMobility no longer exist.
Note that Qt can be configured to build into a namespace. If Qt is built in this way then Qt Sensors is also built into the nominated namespace. However, as this is optional, the macros for this are typically defined to do nothing.
qtimestampqtimestamp was previously defined as an opaque type equivalent to a quint64. It existed as a class due to an implementation detail. In Qt Sensors, the API uses quint64 instead of qtimestamp. qtimestamp still exists as a typedef so that applications that refer to qtimestamp can be compiled. Project FilesQtMobility Sensors applications used this in their project files to enable the Sensors API. CONFIG += mobility MOBILITY += sensors Applications should remove these lines and instead use this to enable the Qt Sensors API. QT += sensors |