Google Android

April 1, 2008 – 6:05 pm

Update 4/17:
After reading Alex’s comment I felt really bad. It’s not that I think Android was actually done poorly, I think that somewhere deep inside there exists some really cool ideas trying to break out. The problem I really have is that it’s a lot of new ideas being shoved into the mobile development world and they often don’t have the documentation to make clear what they intended. The following post was written after about two and a half hours of fighting to make something work and breaking down to just hack it because I had to move on to other school work. This post comes off more critical than it should because the Google guys are extremely clever (more so than me) and though I don’t expect perfection of them I was highly disappointed (particularly by the spotty documentation).

Also, they did support mic emulation, I was just an idiot and never saw it as it was only documented (that I could find) as a command line arg to the emulator (which I only ever ran once manually/outside of eclipse)

Original post:

Disclaimer: I don’t like Google, not like a lot of techies do. I don’t want to work at Google, gmail is not a godsend, and I’m terrified at the thought of everything becoming a webapp. They’re a bunch of (very) intilligent people and they have a lot of clever ideas but I don’t assume everything they produce is Always The Right Thing.

Right, so Android. I’m not sure what to say about it except that it’s been an adventure. Even with my less than fanboyish view of the Goog I still expect the products they put out there to be sorta okay… Wow was I surprised.

To start off the documentation is good for the first 45 minutes of developing for Android, after that you start to realize that most of it hasn’t been updated since the initial release. There is documentation for classes and methods that either don’t (or shouldn’t) exist and the code examples they give just plain don’t work a lot of the time. One of my gropmates was copy/pasting a bit of code from the API and the Eclipse auto-assist showed a rather sad message: “DO NOT USE THIS FUNCTION!!! Someone added this, and they shouldn’t have. You do not have direct access to files inside of a content provider. Don’t touch this. Go away.” It was a rather (Monty) Pythonish moment—I was expecting the rest of the auto-assist text to read “The authors of that last bit of comment have been sacked.”

That’s okay though, as long as it’s easy to work with? Right? Sure, I’d agree to that but it doesn’t. Android is fraught with bugs and evidences of poorly thought out interaction mechanisms (particularly the shell, one could argue that the Eclispe plugin should make this better but it’s pretty flaky at times too). I give them credit as it’s fairly bug-free for the amount of work they did… hacking their own kernerl, rewriting java from scratch, creating this crazy-ass architecture for application development. Of course they didn’t really rewrite java completely from scratch, they left parts out. Whether they needed to or not is another question—I’m not really sure they did though it has its benefits (like the ability to optimize the hell out of their bytecode).

Ahh, that reminds me, the crazy-ass architecture… Now, maybe it’s because I’m just not as smart as they are or maybe it’s because their documentation is incomplete, incoherent, and incorrect but it’s really hard to make anything that they didn’t expect you to do work. It’s also really hard to make things they did expect you to do work sometimes as well — like use the microphone (because they don’t support audio input on the emulator!) Our application revolves around audio and, because I’m clever, we can capture audio but I shouldn’t have had to spend 4 days hacking together a mic replacement…

Anyway, all told, I am very dissatisfied[0] with Android compared to JME and I can’t wait until we get the submission finished (just so I don’t have to write anymore code for it).

[0] enough so I almost want to win the $25,000 JUST to tell them where they can shove the second bit of the competition

PS: In an after the fact manner I realized I didn’t even touch on their “XML-driven” interface philosophy but I can’t begin to channel enough anger to do justice to the feelings of the guy on my team that actually has to work with it… so I’ll leave it at, “It’s not so awesome”

  1. 2 Responses to “Google Android”

  2. Aw :-\ Sorry things haven’t been pleasant…

    With specific issues, though — it’d be great if you’d put in some bug reports. They don’t want to put out code that makes people unhappy. Building toolkits is really hard, and feedback is always appreciated.

    http://code.google.com/p/android/issues/list

    By Alex R. on Apr 17, 2008

  3. @Alex:

    I’ve had several discussions with folks about Android and I always end up at the decision that I can’t say it’s good or bad as a concept because the documentation was so lacking.

    In retrospect the post is really a lot more critical than it need be (in part because I _do_ realize that you folks are really clever) and I’ve added an additional disclaimer saying as much.

    As far as being pleasant: this was the best project I’ve ever worked on. My team was highly competent, motivated, and we worked well together. Compared to that the technical issues haven’t bothered me at all =)

    By Richard on Apr 17, 2008

Sorry, comments for this entry are closed at this time.