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

[Ulf Hermann]

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