[Android-development] On False Promises ...

[Eskil Abrahamsen Blomfeldt]

On 01/06/2014 01:29 PM, Rubi Mazaki wrote:
>
> Finally! I managed to deploy the QML app to the Android device. It 
> even run after showing me weird errors about QML debug info that is 
> missing from my application. Whatever I said. This will not stop me. 
> QML can be debugged on the computer, and C++ is better anyway 
> (considering that Native UI components are out of the scope anyway?)
>

Hi!

We should be able to get the same level of support for native UI 
components in Qt Quick Components as in Qt Widgets, but it requires some 
work. It is definitely not regarded as "out of scope", but the focus of 
Qt Quick Components so far has been the desktop platforms.

> These are small things. But they put Qt in a very bad light.
>
> My Proposal:
> 1. Downloads can be put to torrents. Even with open source resources 
> -- Let some people be the "torrent keepers" (I volunteer my home 
> connection at day time..) use uTorrent and leave the downloads open.
>

This seems like a general suggestion for the Qt Project. Try asking on 
the main mailing list. There might be interest in joining you on 
creating torrent-based distribution. Currently there is a network of 
mirrors serving the downloads in the Qt Project, and I haven't 
experienced any slow downloads there myself. Could this be bad timing 
for your download, or have you experienced this several times? Note that 
we did distribute Qt over torrent back when Qt 4 was released in 2005, 
but it never really caught on as far as I remember.

> 2. Add Android installations (sdk/ndk) into the Android installer. 
> Make it setup the paths right to the environment.
>

In order to install Google's NDK and SDK, the user has to accept the 
licenses on Google's download page, so it can unfortunately not be 
distributed with the Qt SDK (non-redistributability is actually part of 
the license as far as I've understood). So this is not a trivial issue, 
legally. We have discussed the possibility of making these available 
through Qt's online installer, somehow displaying the correct license 
for the downloads there, but so far we haven't committed to any solution 
but chosen rather to document the process, since there are a number of 
unknowns. If the documentation for getting started with Qt for Android 
is unclear, we would very much like to hear about your specific 
complaints, since this is something we continually improve. Personally, 
I think that with proper documentation, users will be able to download 
these two external packages and set the paths themselves, so our first 
priority should be to make the documentation complete.

I'm not entirely sure what path hell you were referring to earlier in 
your mail. As long as you use the Qt binary package and set the four 
paths asked of you in the Android settings, then you should be set to 
go. If you have not done this, then a link to the settings should appear 
when configuring the kit for your project. We've attempted to make the 
steps clear in the UI without pushing modal dialogs in your face, 
striving for a less noisy UI design.

> 3. Remove all samples from the directory and enter them back, one by 
> one, once they are adapted for mobile development! It is better if 
> there are no samples at all at first !!!
>

I'm picturing a general installation of Qt as having both desktop and 
mobile versions side by side (this is also the case in the binary 
installation). In this case, you would likely want to see the examples 
that work better on desktop even if you have an Android-based kit among 
your other Qt versions. What we could do here would be to distribute a 
set of appropriate examples with the Android kit so that you can see 
them by selecting the correct Qt version in the example page in Creator. 
However, this will probably still confuse novice users, since they'll 
never know to change the default in there. I agree that the current 
setup is not ideal, but right now I don't know exactly how it should 
ideally look.

As for the non-working examples: Most of the examples I've tried have 
worked for me. Some of the Qt Widgets examples will look bad because 
they have not been written to work below their minimum sizes (basically 
they're specifically written to run well on a desktop system), but they 
will still work as designed. As you mentioned, Qt WebKit has not been 
ported to Android, so those examples will not work, but you should have 
got an error message about this when trying to compile these examples. 
Same for examples that depend on desktop GL, DBUS, etc.

> 4. armv5/7 ?? what are these? we don't know... You need to let the 
> developer know what to choose.. when to use arm5 and when arm7. Best 
> if this is available in the GUI of QtCreator.
>

Having some extra descriptions in the UI would be a good idea, yes. The 
different ABIs supported by Android are mentioned in several locations 
in the Android documentation and when uploading to the Play store. I 
think that the architecture fragmentation is something you will have to 
deal with in order to do native development on Android, but this might 
not be completely familiar to someone coming from a background of 
developing on other platforms, so we could help them out by adding a 
tooltip for instance. Creator should currently be helpful at least in 
the respect that if you select an ABI which is incompatible with the 
device you have connected, you will be informed of this when trying to 
run it. Switching to a new kit should then be quite quick and easy.

> 5. If QML debugging is not supported on a real phone, don't even let 
> me start the deployment. It is much more constructive for the 
> developer to know what he/she can't do at development time, and not 
> after the deployment...
>

QML debugging should be supported, so this sounds like a bug to me.

> Hope my "recommendations" will fall hard on good ears :)
>
>

Thank you very much for your suggestions and feedback. I hope you can 
also take the time to report them in the bug report system:

     http://bugreports.qt-project.org

Having them in the bug report system will ensure that they're 
prioritized properly and will prevent them from being forgotten :)


-- Eskil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/android-development/attachments/20140106/9aed5f7f/attachment.html>