The joy and sadness of developing on Qt for Android (and not only)
On Habré every now and then flashed articles about the successful experience of using Qt for development for Android, as well as for iOS and WP. The articles are filled with quite a lot of enthusiasm - it's so great: you write and test the UI on the desktop, and then you simply collect with the help of some simple commands for Android, iOS, WP, fill it in and finish. In the same article, I want to share the experience of “picking a rake” mainly when developing for Android.
I have been using Qt for a long time, starting with version 4.1. Not to say that I use it “professionally”, but the experience was different - and working with widgets and evolution to version 5.6.
Some examples of projects:
')
In addition, the Qt Android application is written 2gis, on which you can check most of the things described here.
I ask you to correct me in advance if something from the description described here has the solutions I did not find (I will be grateful if you specify them). All of the following applies for the most part to Android.
The first and most important thing at the moment: if you need to work a lot with user-entered text, do not choose Qt / Qml!
I do not like exclamation marks at all, but here this sign is in its place: it will be extremely difficult for you to implement the work with input fields familiar to users of the target platform, namely:
The crux of the problem: the bug of working with the text editing element has been hanging since 2014, it is marked as Important and is registered by the user with the Silver subscription, but has not been fixed yet. The bugtracker describes a workaround, but if you want to use not Quick.Controls but pure Quick with TextEdit and TextInput - sorry.
Maybe someone will say that I want too much and TextEdit / TextInput are basic components, but, excuse me, the lack of Copy & Paste in the basic components and the lack of its implementation in Controls will not cause you problems before the first Customer's comment.
TextEdit does not contain pointer signals that are typical for MouseArea, so an attempt to implement the context menu display via a long press (PressAndHold in terms of Qml) will not succeed. In addition, an attempt to wrap the input field in the MouseArea in the forehead is only suitable for a limited number of scenarios, since you will have a long and hard to put the cursor between letters and words.
Therefore, it remains either to go into the sources and customize the input field, or accept it.
The second and most loved by customers of applications containing socialization: Emoji
The essence of the problem: there is no native processing of everyone's favorite emoticons, which is in the input fields, that in the text - develop imagination and realize it yourself.
Wikipedia article will help you to find out what Emoji really is and what a difficult fate is to implement them in various operating systems. In fact, what are the options:
Total: either it looks ugly (option 1), or it’s buggy (option 2), or it requires excellent knowledge of Qt internals (option 3 - and if you have them, it’s not difficult to solve most of the problems).
PS Funny fun - do not put any inputMethodHints in the input field, otherwise the built-in Android keyboard with Emoji (iWinn IME) you just do not seem.
The third and most annoying: Blink and BlackScreens are your best friends.
This will accompany you when loading the application, when you try to set windowSoftInputMode in AdjustResize, black screen pieces will also appear periodically. Therefore, test, test and test again on real devices.
The fourth and most difficult: Fonts
The essence of the problem: on different devices every year the same thing pops up, with symptoms similar to a closed bug . You will not know about it until the happy owner of the android device starts complaining that the font is floating, breaking, invisible, etc. Basically, these are Sino-Korean devices.
There is only one way out - take the Qt source and patch for a specific GPU.
Fifth and most controversial: advanced Qml - Camera controls and their ilk.
The essence of the problem: frequent crashes, lack of functionality and other inconsistencies of the standard user experience of native applications. This is all very easy to treat - feel free to add native components (Activity in the case of Android) to your application. Yes, from this its cross-platform will decrease, and the amount of code will increase, but it's worth it.
First and most important: real cross-platform.
The bottom line: after the guys from SQLite ported their offspring under WP, and the modest author of this work pointed this out to the guys from Qt, LocalStorage was added to the Qt port for WP. This happiness for all fans of Qml.
You can actually create applications from the same source, really under a bunch of platforms, while customizing them in the right places based on the capabilities and needs of the platform. The declarative UI and js are so tight and allow you to write such a concise code that you don’t want to return after it to verbose Java + xml, or the controversial Swift + Storyboard.
Any animations, support for custom fonts, svg - is this not happiness for a mobile developer?
The second and most loved by customers: non-standard.
The bottom line: a phrase from the customer, leading to the desire to kill - "Do as on the iPhone." Now this is not a problem, it will look about the same everywhere. Yes, this is a violation of the guidelines, yes, it is not good and never do that, but the customer wants three ways to persuade you to give it to him or refuse it, choose it yourself.
In addition, with sufficient desire, you can podhachit source code platform, as you need it. So, in several applications, we simply permanently disconnected the keyboard and wrote ours on the basis of the Qt Virtual Keyboard, whereas the built-in applications did not have such capabilities.
The third and most beloved by me: the speed of development.
Essence: in any state, you can design a UI of almost any complexity (excluding features of interaction with the OS, such as input fields, processing input devices, etc.). If you are your own customer, then all roads are open to you.
Starting a new project is, first of all, right for yourself to assess the limits of this project’s development. If there is little work with the native capabilities of the platform and a lot of non-standard, use Qt. If, on the contrary, consider whether you can refine it the way you need it.
Thanks for attention! Share your experience using Qt in mobile app development in the comments.
Thanks to zsilas for a tip to the interesting QtOffscreenViews library from the 2gis team, which solves problems with typing and showing emoji in the input fields.
I have been using Qt for a long time, starting with version 4.1. Not to say that I use it “professionally”, but the experience was different - and working with widgets and evolution to version 5.6.
Some examples of projects:
')
- Remote control karaoke center (Android / iOS)
- Russian-Tatar dictionary with custom keyboard (Android / iOS / WP), then there wasn’t even an API for iOS with custom keyboard
- Social network with different devices for Android (geo, bluetooth, chat, photos, profiles, etc.)
- Application for quick order colors (Android / iOS / WP)
In addition, the Qt Android application is written 2gis, on which you can check most of the things described here.
I ask you to correct me in advance if something from the description described here has the solutions I did not find (I will be grateful if you specify them). All of the following applies for the most part to Android.
Problem number 1
The first and most important thing at the moment: if you need to work a lot with user-entered text, do not choose Qt / Qml!
I do not like exclamation marks at all, but here this sign is in its place: it will be extremely difficult for you to implement the work with input fields familiar to users of the target platform, namely:
- Text selection
- Copy & Paste
The crux of the problem: the bug of working with the text editing element has been hanging since 2014, it is marked as Important and is registered by the user with the Silver subscription, but has not been fixed yet. The bugtracker describes a workaround, but if you want to use not Quick.Controls but pure Quick with TextEdit and TextInput - sorry.
Maybe someone will say that I want too much and TextEdit / TextInput are basic components, but, excuse me, the lack of Copy & Paste in the basic components and the lack of its implementation in Controls will not cause you problems before the first Customer's comment.
TextEdit does not contain pointer signals that are typical for MouseArea, so an attempt to implement the context menu display via a long press (PressAndHold in terms of Qml) will not succeed. In addition, an attempt to wrap the input field in the MouseArea in the forehead is only suitable for a limited number of scenarios, since you will have a long and hard to put the cursor between letters and words.
Therefore, it remains either to go into the sources and customize the input field, or accept it.
Problem number 2
The second and most loved by customers of applications containing socialization: Emoji
The essence of the problem: there is no native processing of everyone's favorite emoticons, which is in the input fields, that in the text - develop imagination and realize it yourself.
Wikipedia article will help you to find out what Emoji really is and what a difficult fate is to implement them in various operating systems. In fact, what are the options:
- Use a font with support for emoji characters. Use FontForge to compile Roboto with Emoji!
- RichText with replacing Emoji characters with colored png's
- Deep customization of the input field (you can look at the source code for the desktop telegram )
Total: either it looks ugly (option 1), or it’s buggy (option 2), or it requires excellent knowledge of Qt internals (option 3 - and if you have them, it’s not difficult to solve most of the problems).
PS Funny fun - do not put any inputMethodHints in the input field, otherwise the built-in Android keyboard with Emoji (iWinn IME) you just do not seem.
Problem number 3
The third and most annoying: Blink and BlackScreens are your best friends.
This will accompany you when loading the application, when you try to set windowSoftInputMode in AdjustResize, black screen pieces will also appear periodically. Therefore, test, test and test again on real devices.
Problem number 4
The fourth and most difficult: Fonts
The essence of the problem: on different devices every year the same thing pops up, with symptoms similar to a closed bug . You will not know about it until the happy owner of the android device starts complaining that the font is floating, breaking, invisible, etc. Basically, these are Sino-Korean devices.
There is only one way out - take the Qt source and patch for a specific GPU.
Problem number 5
Fifth and most controversial: advanced Qml - Camera controls and their ilk.
The essence of the problem: frequent crashes, lack of functionality and other inconsistencies of the standard user experience of native applications. This is all very easy to treat - feel free to add native components (Activity in the case of Android) to your application. Yes, from this its cross-platform will decrease, and the amount of code will increase, but it's worth it.
Bonus number 1
First and most important: real cross-platform.
The bottom line: after the guys from SQLite ported their offspring under WP, and the modest author of this work pointed this out to the guys from Qt, LocalStorage was added to the Qt port for WP. This happiness for all fans of Qml.
You can actually create applications from the same source, really under a bunch of platforms, while customizing them in the right places based on the capabilities and needs of the platform. The declarative UI and js are so tight and allow you to write such a concise code that you don’t want to return after it to verbose Java + xml, or the controversial Swift + Storyboard.
Any animations, support for custom fonts, svg - is this not happiness for a mobile developer?
Bonus number 2
The second and most loved by customers: non-standard.
The bottom line: a phrase from the customer, leading to the desire to kill - "Do as on the iPhone." Now this is not a problem, it will look about the same everywhere. Yes, this is a violation of the guidelines, yes, it is not good and never do that, but the customer wants three ways to persuade you to give it to him or refuse it, choose it yourself.
In addition, with sufficient desire, you can podhachit source code platform, as you need it. So, in several applications, we simply permanently disconnected the keyboard and wrote ours on the basis of the Qt Virtual Keyboard, whereas the built-in applications did not have such capabilities.
Bonus number 3
The third and most beloved by me: the speed of development.
Essence: in any state, you can design a UI of almost any complexity (excluding features of interaction with the OS, such as input fields, processing input devices, etc.). If you are your own customer, then all roads are open to you.
Summary
Starting a new project is, first of all, right for yourself to assess the limits of this project’s development. If there is little work with the native capabilities of the platform and a lot of non-standard, use Qt. If, on the contrary, consider whether you can refine it the way you need it.
Thanks for attention! Share your experience using Qt in mobile app development in the comments.
Upd 03/31/2016 4:53 pm
Thanks to zsilas for a tip to the interesting QtOffscreenViews library from the 2gis team, which solves problems with typing and showing emoji in the input fields.
Source: https://habr.com/ru/post/280528/
All Articles