4 ms·

All apps on Android require Java to run currently in some way or another unless you want to have a purely browser based game. At the same time, Google sits on t

All apps on Android require Java to run currently in some way or another unless you want to have a purely browser based game. At the same time, Google sits on the fastest javascript interpreter out there. It would be great if Android could expose native permissions to Javascript and have web apps like Mozilla's Firefox OS. I know they've made a push for holo themes and I would be willing to write in a different markup language to avoid writing in Java

georgemcbay 14y ago
I don't think JavaScript is what activepeanut had in mind when he(?) was talking about "native" development. HTML5 is a wasteland for most types of games as well. Allow Android games to be fully written in C/C++/Go with a fat binary format to support ARM/x86 and now we're talking. You can kind-of-sort-of do native development in Android using the NDK but it is much more of a pain in the ass than it should be because Android's userland was designed so tightly around Dalvik and Google has always treated the NDK as a bit of a red-headed stepchild (eg. it was never officially supported on the x86 Google TV boxes).
- chii 14y ago
  i dont understand why having C/C++ would stop the "wasteland" - i don't believe java to be an inferior language, and as you have claimed, the debugging/IDE support for java is much better than NDK. The only possible reason having better support for C/C++ development is so that ports are easier (assuming the original is written in C++).
  - yusefnapora 14y ago
    > the debugging/IDE support for java is much better than NDK. That's kind of the point; the tooling for native development is crap compared to working in Java, which, while a fine language for lots of purposes, brings a few performance penalties that can inhibit game development. Apart from the overhead of a VM, games often require precise timings that are difficult to achieve when a garbage collector can be running at unpredictable times. And I think you're dismissing the porting angle a bit quickly. When faced with the choice between converting your entire codebase to a different language, using difficult tools with poor debugging support, or starting a new project on a platform you're already successful on, which would you choose?
  - Lerc 14y ago
    The reason for having better support for C/C++ is that you shouldn't force developers to use tools that they would rather not. If you want more people to develop for your platform let them develop for your platform the way they are comfortable. Support C, Ruby, Pascal, Lua, Lisp, BASIC and even Logo. Not perl though, That'd just be sadistic.

georgemcbay 14y ago

I don't think JavaScript is what activepeanut had in mind when he(?) was talking about "native" development. HTML5 is a wasteland for most types of games as well. Allow Android games to be fully written in C/C++/Go with a fat binary format to support ARM/x86 and now we're talking. You can kind-of-sort-of do native development in Android using the NDK but it is much more of a pain in the ass than it should be because Android's userland was designed so tightly around Dalvik and Google has always treated the NDK as a bit of a red-headed stepchild (eg. it was never officially supported on the x86 Google TV boxes).

chii 14y ago
i dont understand why having C/C++ would stop the "wasteland" - i don't believe java to be an inferior language, and as you have claimed, the debugging/IDE support for java is much better than NDK. The only possible reason having better support for C/C++ development is so that ports are easier (assuming the original is written in C++).
- yusefnapora 14y ago
  > the debugging/IDE support for java is much better than NDK. That's kind of the point; the tooling for native development is crap compared to working in Java, which, while a fine language for lots of purposes, brings a few performance penalties that can inhibit game development. Apart from the overhead of a VM, games often require precise timings that are difficult to achieve when a garbage collector can be running at unpredictable times. And I think you're dismissing the porting angle a bit quickly. When faced with the choice between converting your entire codebase to a different language, using difficult tools with poor debugging support, or starting a new project on a platform you're already successful on, which would you choose?
- Lerc 14y ago
  The reason for having better support for C/C++ is that you shouldn't force developers to use tools that they would rather not. If you want more people to develop for your platform let them develop for your platform the way they are comfortable. Support C, Ruby, Pascal, Lua, Lisp, BASIC and even Logo. Not perl though, That'd just be sadistic.