Native Android devlopment (i.e. C/C++) is a major PITA. Biggest reason: there still is no debugger for C/C++ code; you have to do all debugging with printf. In 2012. I'm not kidding. Android NDK didn't even support the C++ Standard Library until recently.
Another reason why Android is losing on the developer front is that development environment setup and usage, even for Java, is worse than Apple's. It's usage of Eclipse is like duct tape and glue.
There is support for debugging native code with gdb, and in the latest Android tools releases this is integrated into Eclipse via the CDT. However, it can still be difficult to set up - if it doesn't work the easy way it's very difficult to figure out how to fix it.
And although there are quirks (mainly performance related) in the ADT/Eclipse combo your description is far from my experience. The overall experience is better, IMO, than Xcode. The latter is the buggiest IDE I've ever used.
Frankly AppCode/IntelliJ beat both in many respects, but frustratingly don't quite cover the full range of functionality. It's difficult to make the leap when you need to go back to Xcode/Eclipse to accomplish some of your work each day.
You really need a lot of nerve to talk about how ADT is better than xcode.
I used xcode for more than three years now, wrote a lot of object c/c/c++ and even assembler, and yet to find any major bug. This year I tried to port one of my app to Android, and the biggest challenge happens to be debugging native code. Basically you can't, there are some tutorials to set up gdb, but it shouldn't be that hard, and I don't bother. I ended up with printf, of course it is a nightmare.
If Google can deliver a xcode quality IDE, it'd already ruled the world.
You're being unnecessarily hostile. Obviously our experiences have been different having used the same tools on different projects. I find plenty of problems with both IDEs, but for me Xcode has been the more painful because of bugs.
Really? There is support for native code debugging if and only if you go through a boatload of non-obvious, unofficially documented steps. On Xcode I can fire it up and instantly set breakpoints - without settings tons of non-default settings, recompiling magic gdb.setup files, and hacking the built-in build scripts.
Then when you get to single stepping its ridiculously slow. Anyone that has used or attempted to use the NDK debugger cannot say with a straight face that it is up to par with modern tools.
Oh...then there is the issue of ridiculously uninformative stack traces.
Its generally easier to build your code in an x-plat fashion in C++ and then work out as many bugs on iOS as you can and then - as the parent said - leave printf turds everywhere.
I recently ported a PC game written in C++ to Android. I basically used the command-line gdb to debug the program when I needed to. It was a PITA at times, especially when it would sometimes lose track of the program when stepping through. It definitely felt a bit half-baked. I definitely can't say the experience was easier than using Xcode.
I agree ... still I have the problem that the Android development chain on my Mac breaks from time to time.
Disclaimer: I'm developing for iOS and I'm quite new to Android (playing with some code from time to time).
Yet, debugging with a galaxy nexus on usb is buggy for me (sometimes it works sometimes it won't). reboot might help ...
I just love instruments in xcode.
As code editor I use MacVim (faster and a much cleaner look for me compared to IntelliJ as it's a coca citizen and not a Java GUI app ... ).
I can't imagine giving up all the code editing features of IntelliJ for any generic text editor though. All that java and XML without code completion and refactoring is just too horrible to contemplate. If you're determined to go that route then why not just ditch the IDE entirely and do everything from the command line?
MacVim has good code-completing and most of the advanced features out of the box, if you use YADR or similar ( https://github.com/skwp/dotfiles ). I like to have the same environment regardless which language I'm using ( objective-c, python, java ... latex, html).
I usually use Xcode/IntelliJ for refactoring and some more advanced functionality.
I think this is one of the reasons I always shied away from Vim. I can use my basic Emacs muscle memory in almost any text editing environment. But I'm sure you can brew up a pretty powerful Vim environment too with a little legwork.
"Another reason why Android is losing on the developer front is that development environment setup and usage, even for Java, is worse than Apple's. It's usage of Eclipse is like duct tape and glue."
I think this is mere perception vs reality. Android development environment is far superior to XCode. Using IntelliJ for Android Development is a true pleasure working with Android. I have no problems debugging over USB on my Mac ever.
The game industry is incredibly rigid to any change. Once they've found their horse they will not walk away from it, and show little interest in changing how they approach development ever. This isn't the first time we've seen some long article with game studios wringing their hands over any change.
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
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).
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++).
> 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?
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.
