.webp)
This blog post is the third one in a series in which we will examine an exciting feature, a change that is first coming out as a Technology Preview in 6.7. Previously, there have been blog posts about Qt Quick in Android as a View and Qt Tools for Android Studio. It is so new that even we do not know how to call this novel approach yet 😊 Give us a name proposal in comments! In this blog post let us look at a few things: workflow, tooling, needed Qt modules, and a small glance at the technical mechanism.
The workflow depends on the case, but usually there might be three steps: design, user interface (UI) development and application a.k.a app development. Sometimes, especially on a one-person project, these could all be combined, but in a bigger project there might be dedicated people doing each. The biggest change is in the application development phase of the workflow.
With the existing approach, the application developer working on Android uses Qt framework modules and tools like Qt Creator IDE to develop the application. Some developers install Android Studio IDE, although that is optional. Then, all or at least the majority, of the application code base is written with Qt C++ or QML. On an as-needed basis, if some bits and pieces are not provided by Qt’s cross-platform modules, the application developer may use the Android Java APIs, for example accessing them over the Java Native Interface (JNI), with Qt’s QJniObject class. At build time Qt creates the Android application with androiddeployqt and Gradle tools and packages the Android and Qt libraries into APK (Android Package). During run time Android application loads Qt, but then Qt takes control of the Android application and life cycle management and starts its own thread aside of the Android UI Thread. The best part of this existing approach is that your app works in iOS and, if needed, on desktop or embedded OS with less work effort.
With the novel approach, the application developer develops their application with the Android Studio IDE. They code with Kotlin or Java and may use only those bits and pieces not provided by Android, like fancy 3D capabilities with Qt Quick 3D module or awesome data visualization with Qt Data Visualization module, from Qt with Qt Quick’s QML. No C++ coding or Qt Creator IDE is needed, just QML and the Android Studio IDE with the Qt Tools for Android Studio plugin. User interface developer could use Qt Creator, but should be fine by using only Qt Design Studio as well. At build time the Android creates the Android application with Android Studio and Gradle, except the parts where Qt Tools for Android Studio uses androiddeployqt and just modifies the build.gradle file to package Qt libraries inside the APK. On run time Android application controls the Qt content and handles the life cycle management but Qt handles its thread execution. The best part in this novel approach is that you can add Qt Quick beauty with QML into your existing Android applications written with Java or Kotlin with less work effort.
So how does the Android application written in Java or Kotlin connect to Qt Quick module written in C++ on this novel approach? Qt libraries are loaded in a bit similar way as in existing approach using Qt for Android Android QPA internals with the help of androiddeployqt and XML file that lists the libraries. Foreign QWindow wraps the QtQuickView to represent Android Activity context and adds QQuickView as child window to QWindow and loads the QML files. The connection from Android Java QtQuickView API to Qt C++ QQuickView is basically a bi-directional wrapper that uses JNI. The wrapper works based on a pointer stored on to Java side that is used from C++ when JNI calls are executed and based on QObject base class and with its properties and signals.
QML has QML properties as connection points. Java side listens QML signals with handlers and has variables as connection points. The value of the property could also be gotten in a synchronous way from QML to Java side. Qt 6.7 supports basic property types, from Integer to String. The type conversion from Java to Qt types and vice versa are done with JNI and QJniObject and QJniTypes.
Hooray early birds! Stay tuned for Qt 6.8 Beta’s coming to browser closest to you by following https://www.qt.io/blog/tag/releases – there is plenty of new stuff that makes Qt for Android novel approach better as well! Like strong typing between and support for more complex data exchange between Java and QML.
