QtLocation reloaded

Once upon a time, back in the Qt 4 and QtMobility days, there used to be a Location API. Unfortunately, during the transition to Qt 5, this API never managed to get a complete port. Qt Mobility location code was tightly bound to QML1, while Qt 5 introduced QML 2. However if you looked carefully, you may have detected that some QML 2 work had already been done for Qt 5.0. More attention and love was required though. With Qt 5.2 Qt Positioning was released, which was a subset of the Qt 4 Location API offering. It focused on providing the means to determine the geographic position.

Now, with Qt 5.5 the remaining Location APIs are back as a Technology Preview. The main differences between the initial Qt 5.0 work and the current state are the removal of the Qt3D dependencies, updating the map rendering logic and fixing the mouse/touch handling.

The heart of every location offering is accessing and presenting map data. Qt Location builds on top of the Qt Positioning offering and uses Mercator projections for tile -maps. They are rendered using Qt Quick Scene Graph with tiles being simple texture nodes. Users can interact with maps using gestures, insert markers or draw simple geometric objects like rectangles & circles. There are currently three plug-ins providing map data:

HERE

OpenStreetMap

Mapbox

In addition, Qt Location provides utilities to find a geographic coordinate based on a street address (geocoding) and navigation routes between two locations. It includes simple driving and walking directions. Everything is exposed with nice and familiar model types in QML, for example GeocodeModel and RouteModel. The obtained navigation data can be presented on the map using the Route type and follows the model-view-delegate pattern. The route instructions can be extracted via the RouteManeuver type. Currently, the HERE and OpenStreetMap plug-in provide support for geocoding and navigation.

Last but not least, there is the Places sub module. It not only provides the means to discover categorized places of interests (POIs) but also presents place details like reviews and associated images. The Places API centers around several QML models with the main two being CategoryModel and PleaseSearchModel. Other features such as search suggestions and reviews are implemented in similar ways. Currently POI functionality is provided by the OpenStreetMap and HERE plug-in.

In summary, QtLocation is back in Qt 5.5. Please checkout our documentation and we are looking forward to your feedback !

The post QtLocation reloaded appeared first on Qt Blog.

Source :- Qt Blog http://ift.tt/1HQN6Yz

Qt Bluetooth and its state of the union

Even though a lot of Qt use cases are about creating user interfaces, Qt provides a diverse set of middle-layer APIs for non-GUI functionality. One of the younger middle-layer APIs in Qt is Qt Bluetooth. From its first release in Qt 5.2 onwards, it has grown and improved in every Qt release.

In light of the forthcoming Qt 5.5 release, I’d like to tell you a bit more about the current status of Qt Bluetooth. It started out as a solution to interact with Bluetooth devices on Linux using Bluez 4.x. At the time, the supported feature set focused on classic Bluetooth development. It targeted the type of profiles and capabilities most commonly encountered by applications:

• Local Device Control
• Device & Service Discovery
• OBEX Push
• Serial Port Profile for Server & Client

Over time, the number of supported platforms was significantly expanded to cover Android (Qt 5.3), Bluez 5 (Qt 5.4) & OS X (Qt 5.5). Unfortunately, there are no API’s which would permit the implementation of the above features on iOS too.

One of the more recent feature additions is related to Bluetooth Low Energy and Internet of Things. What started as a Technology Preview in Qt 5.4 for Linux quickly became a very important subset of the Qt Bluetooth APIs. The recent explosion of available wearables, health and environment sensors requires Qt to be able to interact with such Bluetooth Smart enabled devices. Qt 5.5 takes this development into account and provides Bluetooth Low Energy support on all existing Qt Bluetooth platforms. In addition, Bluetooth Low Energy on iOS was added too.

Well, what’s missing? I guess my personal list is rather long and some of those items are less visible. Hopefully, we can close the gap towards the last major platform which is not yet supported. A WinRT port is being planned for Qt 5.6. On the Low Energy side of things, Qt Bluetooth should be able to run on Bluetooth Low Energy devices which offer their services to other devices (server role). Better scanning and advertising features, to interact for example with devices adhering to the iBeacon standard, are desirable too.

For the interested mind, the semi-official roadmap for the missing features is QTBUG-31674. I am interested in your feedback. Either drop a comment here or directly in Jira.

The post Qt Bluetooth and its state of the union appeared first on Qt Blog.

Source :- Qt Blog http://ift.tt/1CDWCMk