[Development] QML bindings for native Android controls

[Attila Csipa]

On 4/13/2015 3:00 PM, Nurmi J-P wrote:
> Indeed. UIs have come a long way since the days of Windows 95 and 
> others where it was sufficient to draw buttons and checkboxes a bit 
> differently. These days, UIs are full of little transitions and 
> effects. When those things are missing or slightly off, the UI feels 
> broken. 

Amen to that.

When you not only try to reimplement everything a company on the scale 
of Google/Apple/Msft/etc did, but also try to do it in source compatible 
way, you're in for a lot of trouble. The choice is basically either the 
UI equivalent of death-by-a-thousand-papercuts you outlined or a really 
rough lowest-common-denominator approach (which is really low nowadays 
given all the various interaction patterns the different platforms 
have). Add to this the various multimedia and mobile API implications, 
it quickly becomes a compatibility-matrix lottery.

If one wants a JavaScript-driven declarative UI that works on a "most of 
the time" basis, web/hybrid apps fill the need pretty well, even if 
60fps interfaces are a bigger challenge (let's not mix bad JS code with 
tech limitations here). QtQuick is awesome if you want to make a custom 
UI (one of the reason it's doing so well in embedded space), but on real 
cross-platform (especially mobile) apps it's a bit out of the water, 
despite the progress of QtQuick.Controls, and IMO it will never quite 
"get there" given the constant flow of new OS versions, widgets, design 
patterns, etc. And, as I discovered, #ifdefs are a really poor way of 
handling cross-platform development (they are far better at 
feature-management than platform-management), so the old-school C++ 
approach is really not helping there either.

What is sorely needed is a fast, prototyping-friendly and 
platform-agnostic way of doing UIs while relying on their native 
implementation of widgets, usage patterns, libraries etc. Yes, even if 
it means giving up the single-codebase dream. QML and it's C++ 
integration does this quite well (broken-by-design quirks 
notwithstanding), and that's why wrapper component-sets like this one 
are a giant step in the right direction.

Best regards,
Attila