Introduction: Qt is a powerful set of C++ libraries which can be used to build networking software all the way up to user interfaces, and is used by several companies (e.g. Siemens, Thales, ABB, Panasonic, etc) nowadays, most notably in Desktop environments.
Objective: My goal visiting the roadshow in Berlin (on March 13th 2014) was to get acquainted with the latest developments of Qt, specially with it’s focus on mobile devices, in order to see what portions of the library could be useful for our current and future projects, with the promise of providing software reuse and quick development of custom UI components across different mobile platforms.
- Quick Qt/QML recap
- Getting started
- Mobile Optimised UI’s
- Mobile Specific API’s
- Qt on Android and iOS
- Platform-dependent code
- Development tools
- Qt Android Extras
- In-App Purchasing
- Deployment and Publishing
- Qt Could Services
Conclusion: The library is evolving in a fast pace in all major mobile platforms, and can already be used to build applications with custom UI elements. The presentation provided a good overview of the current state of Qt technologies and what is coming in the future. For our current Flowtrol project, the UI elements unfortunately can’t be directly used without a big amount of rework. The main issue is that either one makes a “Qt-only” application or not. In other words, it is yet not possible to mix native UI components with those of Qt (in the current form that the libraries are provided), and re-writing all our iOS UI in Qt would not be viable.
After a quick source code analysis on the Qt iOS plugins that wraps to the QPA (Qt Platform Abstraction) , it seems to me that it *is* technically possible to mix native and Qt components, by changing the Qt components that encapsulate system events and providing the openGL context as a view for the app developer, instead of Qt handling the whole application life-cycle in the main function (i.e in iOS, exposing those in a UIView).
I believe this hasn’t been done simply because it wasn’t the project focus and not due technical limitations – the goal was instead to provide a complete development environment directly under Qt. However, for us that already have a lot of written native code, exposing Qt e.g. in a UIView would be extremely useful, allowing us to take advantage of both worlds.
Hopefully the library will become even more flexible in the future, allowing such mixing of components (native vs Qt). However, where a custom-only UI is desired and no native components are required, one can already largely benefit from the Qt mobile libraries in its current state.