Why Android went with Java?
-
They probably will, now that Open Governance is in place. But they must mature first, so that the whole official Qt package remains top-quality stuff.
They are even working on NaCL port! Pure beauty!
-
See the "Qt Project":http://labs.qt.nokia.com/2011/09/12/qt-project/.
-
[quote author="mk12345" date="1383736748"]what is the difference between throws and throw. i have read from internet but point is not clear to me.[/quote]
The "s" at the end of the word. What are you really asking about, and why in this thread?
-
[quote author="mk12345" date="1383736748"]what is the difference between throws and throw. i have read from internet but point is not clear to me.[/quote]
throws specifies that the class may throw an exception which needs to be handled somewhere in the call stack when using this class/method.And throw actually raises the exception upwards the call-stack, which needs to be handled anywhere and if not the application crashes.
But as sierdzio said, this is not the place to ask this here.
-
It's two year's since I opened this thread and much has changed. I see that the last version of Qt Creator is Android compatible (I suppose that Necessitas is inside it). I didn't test it, are the results looking good? Is it buggy?
In the time being, I have learnt Java and the Android SDK package. A piece of cake coming from C/C++. The conclusion from the experience was: better stick to C/C++.
-
"because java has strong GUI system than C/C++."
I hope this was posted in jest...but it is typical of the misunderstanding of what is being discussed here, by MOST Java adherents.
C/C++ vs Java is NOT a war or a comparison of "who has the better GUI system"--THAT is irrelevant and a non-sequitur, as I'm sure most on this forum already realize. Language features and drawbacks have very little to do with the GUI that serves as a presentation layer.
The original idea behind Java, to obscure the HW and provide a VM orchestrated sandbox comes with so many penalties (in speed, obfuscation, control, etc, etc), we as programmers and engineers are always trying to play catchup...
In terms of Android, it's amazing that this Linux/JVM/User code scheme is workable AT ALL. There is so much layering and object instantiation that, indeed, a 1/2/4 core 1+Ghz platform still seems sluggish! And to top it off, we have to dance around a blocking GC in the VM!
There is a reason why C++ is NOT favored in OS and limited resource scenarios--and the same can be said for Java, in terms of the penalties one incurs with OO in general.
Even Google realizes this, but instead of changing gears, back to native code, they come out with yet another VM (ART) to patch up the scheme, and try to make all this gobbledegook a little faster....amazing!!!
