4 ms·

Every time I think about what Android could have been, my frustration mounts. Google chose to use Java for the top layer on top of their native code libraries

by jnbiche 13y ago

Every time I think about what Android could have been, my frustration mounts. Google chose to use Java for the top layer on top of their native code libraries (as in on top of C libraries like surface manager, opengles, openvg, sgl, etc.). Why they chose Java instead of a language that integrates well with C, I just don't understand. It would have made the ecosystem much more open. I wish they had considered just making the top layer in Luajit, as well as exposing a C API. Luajit would have been just as efficient battery-wise as Dalvik, and perhaps even better-performing. Best of all, people then could have much more easily built libraries for Python, Ruby, and any other language with good C interop. Instead, we're left with Java. It's not a bad language, but it is very bad at integrating with other languages and platforms. I prefer Android to iOS, but the iOS architecture is definitely more open to third-party platforms. Unfortunately, Apple is not so welcoming and puts up roadblocks.

zbowling 13y ago
We agree on with native and opening up the platform at Apportable. It's why we built Apportable. It provides everything you expect from iOS on top of Android and makes it just as open for mixing code. We try to fill in the gaps that people with the native experience on Android.
- jeopard 13y ago
  Apportable doesn't let you build libraries. You can only translate whole iOS apps to Android.
  - zbowling 13y ago
    It actually does let you build libraries, but those libraries also depend on Apportable's improved libc and libc++ environment and other libs you link. Admittedly the documentation is lacking how to do that exactly. That will improve soon.
- mojuba 13y ago
  Apportable's promise is huge. The prospect of being able to compile the same project for both iOS and Android makes me want to jump. But the platform is not quite there yet, as far as I know.
  - zbowling 13y ago
    Without divulging anything, I can safely say it's responsible for at least 32 apps that made it in the Google Play Top 100 games last year, so it's doing pretty good. For anyone else that wants to focus on iOS where they will make the most money but not compromise on Android and provide it with the same experience without having to rewrite everything, it's working great. I will say that if you are building a game it works out of the box today better but we have a lot of people using in ways we could never imagined. The newly rewritten UIKit support is coming soon which will make it a viable solution for anyone that wants a single push button solution for all kinds of apps. For a few users, they choose to use the native UI on Android and bind that to their Objective-C/C++ backends with Apportable. There are a lot of options with Apportable.
rdtsc 13y ago
Yeah I think Python would have been a good choice. Something that looks like kivy perhaps. http://kivy.org/#home http://kivy.org/#home Java is just too popular and too average. Has enough people knowing it, works well with an IDE, compiles (and thus hides the source better). The apps I wrote for example, was more about the API and editing XML files. I've used Java before but in this case it felt different, I would say easier. Not a lot of FactoryFactoryManager type mess many stereotypically associate with Enterprise Java back-ends. So it wasn't too bad. Another interesting point. At one of the PyCons someone asked Guido publicly (he was still at Google back then), why doesn't Android use Python more? And Guido replied it was a "political decision". Moreover the tone he replied it was betraying that he was a bit upset or annoyed at it. So I imagine there was some internal discussion, perhaps more than one and more than once, and one camp one and one lost.
- bch 13y ago
  I would love it if Tcl were a first class option. W/o getting into Tcl vs. Lua vs. Python vs. Ruby vs. Perl vs. Chicken Scheme vs... if the underlying platform really were C, all these things would be viable options. C would have let all these flourish.
- jnbiche 13y ago
  I would really love a Python API on Android. Unfortunately, Python as it exists now is way too inefficient to use on a mobile phone. Have you tried running a Kivy app for more than a few minutes and watched your battery run down? Don't get me wrong -- that's not Kivy's fault really. It's the Python interpreter that's eating up the battery, not Kivy per se. And I'd like to say that there's hope in Pypy, but for the fact that PyPy uses up to twice the memory of regular Python. Now, there's no reason why Python couldn't efficiently run on mobile, but it'd have to be with an entirely different interpreter, or at least a significantly modified CPython. One that uses a register-based VM instead of a stack-based one, and makes a number of other bytecode and VM changes toward greater efficiency.
pjmlp 13y ago
Worse, for the Java fans like myself, they really forked Java. So now Java 8 is around the corner and Android is still playing catchup with Java 7, which is only fully supported on KitKat. So I end up going with C++, since what I care about is covered by libraries like SDL and openframeworks. They had a talk about ART planned for FOSDEM and it was: - cancelled at last minute - Google was also not letting anyone film the talks on the Java room. http://neugens.wordpress.com/2014/02/09/fosdem-2014/#comment-49 http://neugens.wordpress.com/2014/02/09/fosdem-2014/#comment...

by jnbiche 13y ago

zbowling 13y ago

We agree on with native and opening up the platform at Apportable. It's why we built Apportable. It provides everything you expect from iOS on top of Android and makes it just as open for mixing code. We try to fill in the gaps that people with the native experience on Android.

jeopard 13y ago
Apportable doesn't let you build libraries. You can only translate whole iOS apps to Android.
- zbowling 13y ago
  It actually does let you build libraries, but those libraries also depend on Apportable's improved libc and libc++ environment and other libs you link. Admittedly the documentation is lacking how to do that exactly. That will improve soon.
mojuba 13y ago
Apportable's promise is huge. The prospect of being able to compile the same project for both iOS and Android makes me want to jump. But the platform is not quite there yet, as far as I know.
- zbowling 13y ago
  Without divulging anything, I can safely say it's responsible for at least 32 apps that made it in the Google Play Top 100 games last year, so it's doing pretty good. For anyone else that wants to focus on iOS where they will make the most money but not compromise on Android and provide it with the same experience without having to rewrite everything, it's working great. I will say that if you are building a game it works out of the box today better but we have a lot of people using in ways we could never imagined. The newly rewritten UIKit support is coming soon which will make it a viable solution for anyone that wants a single push button solution for all kinds of apps. For a few users, they choose to use the native UI on Android and bind that to their Objective-C/C++ backends with Apportable. There are a lot of options with Apportable.

rdtsc 13y ago

Yeah I think Python would have been a good choice. Something that looks like kivy perhaps. http://kivy.org/#home http://kivy.org/#home Java is just too popular and too average. Has enough people knowing it, works well with an IDE, compiles (and thus hides the source better). The apps I wrote for example, was more about the API and editing XML files. I've used Java before but in this case it felt different, I would say easier. Not a lot of FactoryFactoryManager type mess many stereotypically associate with Enterprise Java back-ends. So it wasn't too bad. Another interesting point. At one of the PyCons someone asked Guido publicly (he was still at Google back then), why doesn't Android use Python more? And Guido replied it was a "political decision". Moreover the tone he replied it was betraying that he was a bit upset or annoyed at it. So I imagine there was some internal discussion, perhaps more than one and more than once, and one camp one and one lost.

bch 13y ago
I would love it if Tcl were a first class option. W/o getting into Tcl vs. Lua vs. Python vs. Ruby vs. Perl vs. Chicken Scheme vs... if the underlying platform really were C, all these things would be viable options. C would have let all these flourish.
jnbiche 13y ago
I would really love a Python API on Android. Unfortunately, Python as it exists now is way too inefficient to use on a mobile phone. Have you tried running a Kivy app for more than a few minutes and watched your battery run down? Don't get me wrong -- that's not Kivy's fault really. It's the Python interpreter that's eating up the battery, not Kivy per se. And I'd like to say that there's hope in Pypy, but for the fact that PyPy uses up to twice the memory of regular Python. Now, there's no reason why Python couldn't efficiently run on mobile, but it'd have to be with an entirely different interpreter, or at least a significantly modified CPython. One that uses a register-based VM instead of a stack-based one, and makes a number of other bytecode and VM changes toward greater efficiency.

pjmlp 13y ago

Worse, for the Java fans like myself, they really forked Java. So now Java 8 is around the corner and Android is still playing catchup with Java 7, which is only fully supported on KitKat. So I end up going with C++, since what I care about is covered by libraries like SDL and openframeworks. They had a talk about ART planned for FOSDEM and it was: - cancelled at last minute - Google was also not letting anyone film the talks on the Java room. http://neugens.wordpress.com/2014/02/09/fosdem-2014/#comment-49 http://neugens.wordpress.com/2014/02/09/fosdem-2014/#comment...