Android: Qt vs Java. What is better to use?

Question

Java

I have little experience in developing applications for Android in Java. Now looking towards Qt, especially in view of the release of Qt 5.2.0. So what can you say about Qt for Android (IOS) compared to Java? Does it make sense to use it, or at least try it, or does it lose Java in all respects?
Thanks in advance!

Answer 1

I dare to challenge the reasoning of lorus ( Android: Qt vs Java. Which is better to use? ).
We have almost the same result, but as in mathematics - when the course of reasoning is erroneous - even if the answer is correct - then the problem is not solved. Perhaps a lot subjective, but I will speak out as a personal opinion of a person who loves and wrote both on Qt and on Android with its "native" Java too.
I didn’t write on Qt for Android, because at the time the last project started, the technology was raw.
And so: Not an agitation for Qt, but a few words in defense of Qt.
Looking ahead, I’ll say: to the topic starter - if you have little experience in developing for Android, you have not worked with Qt before, and portability of the source code between everything and everything is not important to you - continue to master the Android SDK (Java).
At least for now.
Good knowledge of at least one instrument is better than mediocre knowledge of two. ;)
C Qt for Android then you'll figure it out. Yes, and it will be "more run-in".
It is necessary to distinguish between "just C++" and C++\Qt. First of all, Qt is actually a dialect of the C++ language. For example, additional signal and slots sections appear in the Qt class declaration, and during the build process there is a meta-compilation phase that makes C ++ code for your platform. I won’t be surprised if a mixture of Java and C ++ code is generated for android, which is then fed to the Android NDK.
Secondly, Qt is a _self-contained_ framework. No STL or "whatever you think comes with C++" typical 3rd party developers .
Many of the problems that lead to the complexity of developing "in plain C++" in "C++ \ Qt" simply do not exist "by design".
For example, Qt has a wonderful mechanism to prevent "null-poiunter" - "signal-slots" from snatching. This greatly simplifies and makes it more reliable to work with both the GUI and, for example, objects running in different threads. In Qt, it's much easier to do this than to fence similar standard mechanisms in Java. I'm not saying in the end it will be more efficient - it needs to be clarified and it can be argued - but here is the fact that in Qt many issues of working with threads and inter-thread interaction are thought out better and the mechanisms are more convenient - in my opinion this is a fact.
(Although there is no such cool mechanism like runnable in Qt. But we are waiting for the 11th C ++ standard.)
Thirdly, "C ++ \ Qt" is a well-thought-out framework with almost the best class design, well-thought-out methods , a unified style of problem solving.
As a person who wrote on Qt 4.0-4.6 and has now completed the first commercial project for Android, I can point out many disadvantages to Java (in comparison with Qt4 / Qt5.) Simply because Java - as a commercial technology in the first place, was forced to gain illogicality for the sake of compatibility with previous versions - almost from the first versions of Java. Look at certification questions - a lot of questions that when you start to sort out "why" are rooted in the distant dark past of Java development. And in the end - modern Java is often an illogical, patchwork quilt, where different classes use, if not a different approach and style, then at least different method names to solve the same task. Well, why is this?)))
Yes, Java is described in detail, and we predict it technically - but you need to cram it, stupidly cram all the exceptions and problems of inheritance of the logic of the first versions, and cram where put () is used, and where add () ....
... and Qt-you can _understand_ and not cramming, understand and only occasionally look at the documentation. And as a result, writing on it is easier.
By the way: the design of the classes of Google's classes - although very, very, very peculiar and strange in places, but, IMHO, it is quite "well-built" and in general does not suffer from such a strong patchwork of logic that is available in standard Java classes. At some point, you understand "as they thought in Google" and everything becomes a little easier.
Another word about the myth "it's easier to write in Java than in C++" (if you compare Java under DalvikVM and C++\Qt5):
Don't forget - DalvikVM is not JavaVM for you.
In DalvikVM, you can easily grab the "null-pointer-exception" if you suddenly naively think that if you have a reference to a fragment, activity or view in a local variable, then the machine will not destroy the object "when it wants to", and you have your variable not nullable.
Understanding which desktop writing and app design habits cannot be transferred to the Android SDK frameworks and restructuring your own thinking will take you several months. And you will _start_ to understand this and grab such problems - as soon as you start writing something more than a set of disparate activities and a couple of fragments from training courses.
And in the end - your first serious project on Android - you can fly into good revisions.
For example, including because there is no life cycle for the Application class in the Android SDK v17. There are no mechanisms for saving the state of a singleton environment, etc., etc.
And when you write in Qt, you are guaranteed to support uniform mechanisms for all platforms.
You do not need to reshape the brain, developed solutions and debugged and proven patterns.
As a result - to write on Qt - can become and will be faster. In some cases.
But from Qt - it can be difficult to have access to purely android services such as a data provider.
In general, I'm what. There is no definitive answer here which is better and which is worse.
Each tool is quite powerful and has many pros, cons, and features.
Sorry, but that's also an unsubstantiated claim. See point 1.
Also note:
The Qt toolkit allows you to get the same behavior on all supported platforms. Including the behavior of the GUI, Forms and the same application architecture for all systems. Ideally - with Qt - you can write for Android as if you were writing for the desktop - without changing the architecture and structure of the application.
And when you write for Android in Java, you always write a piece of code that works in the DalvikVM context and must live according to the patterns and scenarios provided by this machine, and many aspects of "how it works" are clearly not spelled out anywhere. And if suddenly you stray from the standard templates of the Dalvik-machine framework, you run the risk of raking incomprehensible, hard-to-find jambs, moreover, _out_ of your control, which you cannot intercept and process correctly. Who does not know - try to destroy the ViewGroup, whose id you used as a container to place a fragment inside it. As soon as you do FragmentTransaction.commit() - you put the machine a task that it will perform "sometime later", out of your control, and will not deign to allow you to correctly handle the exception. Until the situation when a fragment tries to be added to an Activity that has already completed the standard procedures for Activity.finush(). Well, it would have thrown the error code somewhere, and silently ignored it - but this is Java - it will throw an exception. And you can't wrap it in a try...catch - it's not your piece of code. The most you can do is "catch before you die" Thread.UncaughtExceptionHandler. And that's all.
(correct me if I'm wrong, I'm not a Google engineer either)
Why are you intimidating?
The Android NDK (for C++ development) is as native as the Android SDK (for Java development).
And with compatibility, Qt with the Android platform has no more problems than any other application that uses C ++ code inserts and is developed using the standard Android NDK.
--------------------------------------------------
In summary: the author just needs to weigh what for and how it is going to be used.
If the author needs the same behavior on various platforms - including stubborn products, Linux, various Windows RT under-tablets - then the choice is clear - smoke Qt. This is an amazing, clear, well-thought-out and most logical framework that was not afraid to re-create from scratch in order to eliminate the accumulated complexities (remember the transition from Qt3 to Qt4) Personally, I was delighted when I worked with it (2005-2009)
But - in part Android butt: I suspect there may be "technical risks" using any special "mobile pieces" such as "working with calls," working with contacts "," working with mail "or" content providers ", etc.
I moved away from the Qt world when Qt was 4.8 and I didn't look for classes that do it. I think the descendants of the trolls should have created something in 5.2, but it's better to check.
As a last resort, docking with Java objects may be required, in which case you will need to learn the Android NDK, and perhaps even write some Java wrapper code.
If you _need_ to work with the functions described above, and don't care about the portability of the executable code, or if you _already_ have experience developing with the Android SDK, then of course it's better to write in Java.
But in this case, be prepared for the fact that this is not a JavaVM, and no one promises you the safety of references _for_a_number_of_classes, but because Java does not require a destructor - you _will_ have some architectural challenges when building complex applications.
For example, what in a desktop application you would solve with a "simple" "singleton object" with simple functionality like write-read from a file - here you _have_ to decide by building a "content provider" and so on. - which significantly raises the "entry threshold" for those who dive into Android development.
But - you have to give credit to Google's engineers - they _were_ good reasons to do so, and they protected you as much as possible from getting into many problems - if, of course, you use the framework exactly as it is supposed to. And they made many mechanisms quite elegant and pleasant to use. I like the design of Google classes for the most part. In general, do not forget to understand why in the examples it is done exactly the way it is done, and not otherwise.

Answer 2

native technology is always better. It's worth a try though.

Answer 3

what is the advantage of java? - multiplatform.
what does qt generate? - platform-specific code.
why am I? about the various processors on which the android is launched.