Thoughts on the Android

written on Wednesday, 24th March, 2010

Nearly finished with an Android app that some fellow students and myself did for the mobile lab at RWTH University (simple foursquare like thing: maps, contacts, web services...). I am going to collect some of things that I liked about the Android platform and stuff that annoyed me when working with it.

First of all, let’s state that it was fairly easy to get our application up and running. There were simply no Android problems that were too obscure or too complicated to deal with. Compared to the intricate hells of other Java environments, such as J2EE (think class loaders, think various closed source implementations...) I’d say it was an easy ride for the most part.

The good parts

There was some stuff I really liked, plus everything to do with performance, as they obviously really thought about that, compared to say, SUN when they introduced their first JVM.

• generated resource identifiers

  No need to mess around with strings in order to access resources. For each resource (localized string, layout component id, image) you define it in an XML file and an ID (as a public static final int) is generated for you. Yields performance benefits and some compile time safety.

• eclipse integration

  The android SDK does not depend on using eclipse, which is great if you like to learn what’s actually going on and you know your way around with the shell. But today’s developers are usually bred with eclipse support built right in (kiddin’), so the eclipse plugin really helps as it calls the tools for you (e.g. to regenerate resource identifiers) so you don’t forget.

• layout tools

  compared to the Interface Builder for iPhone, the XML based layout definitions need to allow for more flexible layouts, as android apps are not tailored to a specific screen size or orientation. They do a fairly good job of this, and whenever you are not satisfied you can simply define overriding layouts for specific devices or screen dimensions. The layouts do also have an advantage over CSS based layouts (Palm Pre) because you can easily fill horizontally or vertically or align to the bottom of the screen (that is just annoying with CSS).

• The API’s

  Batteries are included: There is JSON support, various UI components, the mature HTTP libraries from apache commons, and everything from the good old JavaSE that is really useful. the awesome webview lets JavaScript running inside the view interact with your Java code really well!

The bad parts

• The API’s: JSON

  Yes, again. Some of the API’s seem to me like they had to freeze them in a hurry. The JSON api is only similar the one you get from json.org (an older, incompatible version). We wanted our serialization layer to live in a separate project from the android client, so I actually had to get the JSON sources from the Android source repository to downgrade our non-Android implementation to use the platform library.
  The platform developers should offer standalone packages of all included 3rd party libraries they include, in the version that got shipped with Android.

• The API’s: Google Maps

  Compared to the awesome JavaScript API that you can use when you embed Google Maps into a webapp (or a Palm Pre app), the Android Maps API is just tiny. We wanted to set draggable markers and to reverse geocode the selected location, and we just used an android WebView and embedded an GMaps from a web site of ours. That is a tiny bit slower, but so much more powerful to just GTD. While doing that I noticed again, how quickly you can get stuff going with just JavaScript and browser refresh compared to Java’s holy "compile, deploy, navigate to screen" trinity of UI development.

• The API’s: HTTP

  Honestly, I could not believe that there was no simple callback based HTTP abstraction layer over apache commons. Have you guys learned nothing from the success of AJAX? I mean, being with Google, they probably should have, but anyway: It is much too painful to access web services. We had to write our own layer for that (and no, I don’t want to go all SOAP or even WSDL, I just want to get some lists or some image from our server...), instantiating thread pools, managing listeners and such. Perhaps I should use a WebView for that too, it can do that, you know...

• Internationalization

  Perhaps I missed something there, but I18N can get really messy because a missing translation will cause no errors before runtime. This would ideally have a spreadsheet based editor or something like that, so you spot missing translations right away. Also, there are still some API’s (ProgressDialog.setMessage) that take strings where numeric identifiers should be used. Not sure about the reason, but this can lead to untranslated UI quickly (and did in our case...).

• The date and time pickers

  This is mainly about the usability. Compared to the iPhone, these simply sucks. The rolling barrels that the iPhone uses are probably patented, but it must be possible to make something that works more quickly than this.

All in all it was interesting to work with android. I must look into JSON serialization some more, as the various automatic available Java libraries (gson, json-simple, XStream, Jackson) that I glanced at when the json.org one annoyed me all seemed to have serious disadvantages, such as requiring change your model, to write lots of glue code, or to work badly with object graphs containing cycles. But that is another topic, for another time.