[Development] Architecture of Android/Java bindings for QML and QtQuick

[Fabian Kosmale]

Hi,

I don't think it's necessary to still flag the Android integration as TP 
like it was in 6.7, we already iterated on the API to cover the initial 
use case, and I think that one is covered by now in a way that we don't 
expect to change.
I think there is a discussion to be had about how we can future proof it 
to support non-graphical QML modules - and whether that makes sense in 
the pure Android context. But I think that should be part of the normal 
API review process that triggers after FF. One way forward there would 
be to have a less strict coupling between the QtQmlComponent and the 
QtQuickView via means of an interface; but let's have as a separate 
discussion thread.
Concerns about where the code is currently located are also much less 
pressing as with our C++ modules, given that we don't have to concern 
ourselves with ABI and imports paths.

Kind regards,
Fabian

On 31.05.24 08:44, Ulf Hermann via Development wrote:
> Hi,
> 
> As noted before, we need to have a discussion on the new Android/Java 
> bindings and how they fit in with the QML language and various Qt 
> modules. See for example 
> https://codereview.qt-project.org/c/qt/qtdeclarative/+/563564 and 
> various follow-up changes.
> 
> I suggest we call the Android/Java bindings Tech Preview for now.
> 
> My main gripe is that the way it's written now, the language bindings, 
> the mapping of various model types, and the QtQuick support are all 
> added in one big package in src/quick. This limits what you can do with 
> e.g. the QtQmlComponent wrapper class. Ideally a QtQmlComponent should 
> be a generic building block for creating any QML component, independent 
> of any particular UI toolkit. There should also be a generic wrapper for 
> a QML engine that could instantiate QML components. This way we'd be 
> able to use the same building blocks for other Qt modules that expose 
> QML types, without depending on QtQuick.
> 
> For example: QtScxml has a QML integration that can be used without 
> QtQuick in C++. If you tie the Java-QML language bindings in with 
> QtQuick, you suddenly need to use QtQuick when employing the same 
> QtScxml/QML integration from Java. Such a thing will not sit well with 
> the maintainer of QtScxml.
> 
> I suggest to split the Java bindings into separate packages for each Qt 
> module, so that you can use them independently. The QtQml bindings 
> should provide common QML-related building blocks, such as a wrapper for 
> a QML engine and a wrapper for a QML component, that can be re-used in 
> other modules.
> 
> best regards,
> Ulf

-- 
Fabian Kosmale
Manager R&D

The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin
fabian.kosmale at qt.io
+49 1638686070