The software development kit for Google's Linux-based Android mobile phone operating system has been out in the wild for a over a month now, plenty of time for developers to form opinions of the platform and assess the capabilities of the API. The verdict from seasoned mobile software programmers is somewhat mixed; some are even expressing serious frustration.
I put Android to the test myself in an attempt to see how bad the situation really is. What I discovered is a highly promising foundation that is plagued by transitional challenges and a development process that needs more work. Android has many bugs, some of which are impeding development. Unfortunately, Google's QA infrastructure for the platform is completely inadequate for a project of Android's scope and magnitude.
There is no public issue-tracking system for Android. Instead, users post information about the bugs they encounter in the Android Developer Google group and hope that one of Google's programmers sees it so that it can be added to Google's private, internal issue-tracking system. Users have no way to track the status of bugs that they have reported, and they never know whether the issue is being addressed at all until after it is resolved, at which point it is mentioned in the release notes for a new SDK release.
"Unfortunately there is currently no externally-accessible issue-tracking system," wrote Google developer Dan Morrill in response to complaints about the bug reporting situation. "We are considering how we might implement such a system, but we don't have an answer yet. The biggest snag is simply keeping our internal issue tracker in sync with an external one. So, it's a process problem, rather than a technical problem."
Companies like Skype, Nokia, and Trolltech all have public issue tracking systems for their software, so one has to wonder why Google, with all of its resources, can't do the same for Android. This is a pretty clear symptom of a dysfunctional development process. In an effort to minimize the frustration of not having centralized issue tracking, users have started to independently catalog known bugs at an unofficial Android wiki.
Another major problem with Android is lack of documentation. The API reference material doesn't provide enough information and one sometimes has to experiment (that is, guess) to figure out what the parameters for various methods actually do. In many cases, I found the developer discussion group to be far more informative than the API documentation. I also grew frustrated with some of the inconsistencies in the API naming conventions, an issue that other developers have complained about as well.
Working with the layout model for the Android user interface can also be frustrating. The code samples mostly emphasize the XML-based user interface description language, so there aren't enough examples that demonstrate programmatic layout techniques.
A recent article in the Wall Street Journal illuminates problems encountered by other developers who are attempting to build applications for Android. "Functionality is not there, is poorly documented or just doesn't work," MergeLab mobile startup founder Adam MacBeth told the WSJ. "It's clearly not ready for prime time."
The strength of an android
Although Android has its share of problems, there are some places where it really shines. The Eclipse plug-in is quite effective and provides excellent integration with the Android emulator. Every time you initiate the debugging process in Eclipse, it will start up your program inside the emulator and connect it to the Eclipse debugger automatically. You don't even have to close the emulator between tests; you can just modify the code and run the debug process again and it will restart your program in the currently running emulator instance. The seamless support for breakpoint debugging is so effective that it feels like developing a regular desktop application.
The setup is also surprisingly easy if you already have Eclipse installed. You just unzip the SDK, install the Eclipse plug-in, tell it where you put the SDK, and you are good to go. Downloading the SDK to compiling my first Hello World program took me less than ten minutes. In that respect, Android provides a much better experience than Maemo, for instance, which is a real pain to set up.
There are a few other places where Android surprised me with goodness. The ScrollView widget appears to support kinetic scrolling right out of the box, which means that developers won't have to implement that at the application level like they do with Maemo. I was also impressed by Android's seamless support for screen rotation and multiple resolutions. The emulator comes with several skins that you can use to test your application at various screen sizes and in different orientations. My applications worked fine in both horizontal and vertical orientations without requiring any custom programming. The user interface changed to accommodate horizontal orientation in much the same way a regular desktop application changes when it is resized.
To test out the API, I wrote a few experimental Android programs, including a Twitter client. The API is moderately conducive to rapid application development, but there are still some gaps. Although the API offers a lot of really nice functionality for animated transitions, alpha transparency, and other similar visual effects, it doesn't make it easy to create applications that have a really polished look and feel. For my Twitter application, for instance, I wanted to put a nice picture in the background and have a transparent, rounded rectangle with a border behind each tweet, but those kinds of embellishments end up being way more trouble than they are worth in Android. By comparison, getting the same effect with XUL only requires a few trivial lines of CSS.
I had a hard enough time getting the basic layout to look right even without thinking about embellishments. Android would benefit greatly from a drag-and-drop design utility that provides an interactive approach to layout and exposes all of the widget attributes in a clear and expressive way.
Despite some of the bugs and limitations in the API, it is definitely a viable and effective platform for application development. My Twitter client was only about 130 lines of code, which is impressive. That said, I could still crank out applications faster with Java FX Script. In general, I think that Java FX Mobile is probably the competing platform that is most analogous to Android.
The inevitable comparisons between Android and the iPhone platform seem a bit misguided now that I've really worked with Android. The iPhone platform seems to be tailored to a very specific kind of user experience that is particular to the hardware. Apple has always been good at leveraging the tight coupling between its hardware and software, and the iPhone is no exception. With the iPhone, Apple has sacrificed the potential for hardware diversity but gained in the process the ability to make innovative technologies like multitouch a ubiquitous part of the user experience. Android, on the other hand, has to be designed from the ground up to support an extremely diverse range of hardware devices with vastly different capabilities.
Android's design seems to be heavily focused on making as few assumptions as possible about the kinds of devices on which the software will run. And seriously, some of those devices are going to be monstrously ugly clunkers compared to the iPhone.
It's important to remember that Android is still in early stages of development and that its present weaknesses aren't indicative of failure. Devices with Android won't even start to hit the market until later next year, so this is like a pre-release aimed at spurring early development so that a healthy ecosystem of third-party software applications is available at launch.
Despite pre-release status, some of Android's weaknesses are indefensible. Google's Android team needs to get its act together and figure out how to interact with a rapidly growing community of professional and enthusiast developers. The "release early and often" strategy is generally a good thing, but it utterly fails when infrastructure isn't in place to facilitate proper handling of user feedback. Google has a habit of embracing the early release philosophy with a little too much enthusiasm, and the current situation with Android is emblematic of that approach.
reader comments