Test Center preview: Inside Google's mobile future
The Open Handset Alliance's Android SDK for creating mobile applications throws a few semantic curves at Java developers, but for the most part, they will feel at home; just be prepared for some rough terrain, and be sure to bring plenty of hardware
Unfortunately, Android introduces a whole new lingo for developers to memorize. Roughly speaking, an application is an Activity. (The current documentation is only marginally helpful on this point, describing an Activity as "a single focused thing that a user can do.") Within an activity, you define one or more views. A view -- realized via the View class -- corresponds to an area on the screen, and manages the drawing and event trapping of its associated area. (So, for Java developers, a View is roughly equivalent to a Canvas.) Event handling is governed by the Intent class, which models an activity's intention to handle events of a given kind.
In short, be prepared to spend some time in the documentation matching what you already understand about GUI application development with the corresponding elements as Android calls them. The documentation is reasonably good on this matter. Nevertheless, as is typical, I found the provided example code to be far more useful.
Just before I began testing the Android SDK in mid-February, a new SDK was released (m5-rc14, to be exact). I installed that SDK (and Eclipse plug-in) on a 1GHz, 1GB Windows XP system. Though installation went smoothly, the emulator took on the order of 30 minutes to complete its boot process when an Activity was launched from within Eclipse. Other users on the Android message boards reported similar behavior, though the problem was by no means universal. The solution appeared to be faster hardware. Luckily, I had a more powerful machine on hand: a 3GHz processor with 2GB of RAM (running Windows 2000). I reinstalled Eclipse and the Android SDK on this faster system, and -- sure enough -- the emulator was up and running my trial application in about 30 seconds after the launch from Eclipse.
Now, 30 seconds -- though worlds better than 30 minutes -- is by no means a comfortable launch latency, particularly if you're stuck in a heavy execute-crash-debug-fix-execute cycle. And I'm not certain that delay can be reduced appreciably. Remember, when you start the emulator, you're starting the QEMU environment, followed by a booting of the Linux kernel, which has to fire up all the framework services. In other words, a lot has to happen just to get to the first bytecode of your target application.
Android on the march
Android is definitely a work in progress. If you want to try your hand at creating a significant Android application with the existing toolkit, I salute you. But be prepared for a challenge.
My biggest concern with Android is that I find nothing compelling in it that sets it apart from other handheld OSes. Though one might be tempted to point to the inclusion of the SQLite database engine as significant, I am unconvinced that an SQL-speaking relational database is the "killer feature" that will help Android succeed where other, similar handheld OSes have simply fizzled.
Nevertheless, Android has the weight of Google behind it. Whether that weight is sufficient to propel Android where other handheld OSes have not gone before is uncertain. For now, I'll simply say that Google has a lot of propelling to do.