Can Google Android phones compete with the Apple iPhone? A few weeks ago, Google loaned me a Nexus One smartphone for experimentation, and I've spent the time since downloading applications and writing my own code. The good news is that the platform is not only competitive but is often a better choice than the iPhone for many programmers and the enterprises that employ them.
The Android line is now competitive enough that the casual user may look at the two platforms and assume they're twins. Both let you call people and fire up a number of apps by mashing your finger into one of an endless matrix of square icons. Both let you pull up Web pages. To my unsophisticated eye, the iPhone interfaces still look a bit prettier, but for most basic uses, iPhone and Android are as similar as Ford and Mercury or Coke and Pepsi.
The differences become apparent if you want to do more than make a few phone calls and iFart around. The iPhone app marketplace is dramatically larger and deeper, but there's already a palpable difference in the style. While iPhone developers have found that one path to success is playing to our baser instincts (until Apple shuts them down), a number of Android applications are offering practical solutions that unlock the power of a phone that's really a Unix machine you can slip into your pocket.
GScript, for instance, is an Android app that lets you write your own shell scripts and fire them off with a tap. Another useful app, Remote DB, lets you turn any SQL query into a button that searches the database remotely, then displays the results. It's the fastest way to generate a custom app -- the only code you need to know is SQL and the UI helps you with that.
That kind of openness is often rejected by the Apple App Store because Apple seems to fear the possibility that someone might add or modify the functionality of a program. Apple's terms specifically limit interpreters and emulators -- enough to force one Ruby implementation to disable the best parts of the eval function. Some reports suggest that the App Store reviewers are finally coming around to understanding the advantages in the technique taught to many freshman in their first computer science class, but no one really knows.
These kinds of flexible functions aren't just for code jockeys who use shell scripts all day long. Apps like GScript and Remote DB make it simpler for the IT staff to create rough but workable custom tools for all corners of the enterprise. The users can simply push a button and watch their phone do the right thing.
It's a Java world Android's relative absence of barriers was apparent again and again as I played with the Nexus One. At first I was a bit skeptical that anyone would do much with the open source license. Did it really make sense to reprogram the UI or the functionality if you're just going to take a few calls and check email? But some folks are relentless tinkerers, and they're building new Android distros. These are a long way from the Linux LiveCD ecosystem, but I can see this avenue being useful for an enterprise that wants to put a nice custom interface on top of Android hardware.
The open source foundation also makes adopting the platform that much easier for Java programmers. I was about to install a library to suck down a distant Web page when I realized that Eclipse was signaling that the library was already installed. Many classic frameworks like Apache's HttpClient are bundled right into the mix. So many parts of building an Android app will be very comfortable to an old Java hand.
Still it's important to be slightly skeptical about this openness. The code to interface with Google's excellent Map project is in the package com.google.android.maps, a clue that the interface is not open and that you're not welcome to use and distribute them any way you like. Also, many users who take root-level control of their phone are finding that it can be a real hassle to keep up with bug fixes and other changes.
These limits will affect the most capable and most extreme developers, those out to remake the phone from bottom to top. A far greater number of developers and their employers will be happy with the basic freedom to distribute software. While the Android does require the developer to add a digital signature to the JAR file holding an application, the developer can use a self-signed certificate, an option that allows some control without putting Google at the center of all distribution. Keep hold of the key for this self-signed certificate because the phone will only accept upgrades to packages signed with the same key.
After the code is signed, any path between developer and phone is acceptable. A number of third-party programs will grab the APK from the file system and install it. The very fact that I can write "file system" without using felonious words like "jailbreak" is a welcome treat. There's one app, SwiFTP, that lets you upload and download files from your phone over the Internet using a proxy Website. It's quite a nice trick, and not something you'll find in Apple's App Store. When a friend tapped around the demo phone, he thought I'd done something bad, but it was just another app downloaded from the official Android Market.
Hello Android For the programmer, the advantages of the open ecosystem were apparent from the beginning. While it took me several days to get the keys sorted out when I first hooked up an iPod Touch to the Apple Xcode IDE, I actually got the "Hello World" test working on the Nexus One before I fired up the simulator. Eclipse just noticed the Nexus One was hooked up to my PC, then started up the code. I glanced over and my new app was just running.
The pure Java foundation of Android will be one of the biggest attractions for many businesses with Java programmers on the staff. Any Java developer familiar with Eclipse should be able to use Google's Android documentation to turn out a very basic application in just a few hours. Not only that, but all of the code from other Java programs will run on your Android phone -- although it won't look pretty or run as fast as it does on multicore servers.
The biggest challenge for the Java programmer is working through the seemingly endless layers of indirection coded in XML and properties files, all intended to make it easier to create applications for different screen sizes and languages. Apple is just beginning to add these features to support the iPad, but Google anticipated all of this from the beginning. You can set up the simulator to handle different screen sizes. So when is the Google Pad coming? HP and others are already hard at work.
Here is another place where Google's approach is so much saner than Apple's decision to wrap a nasty nondisclosure agreement around its SDK. As Apple would have it, programmers can't talk to other people, such as bosses and investors, about the iPhone and iPad capabilities unless those folks pay the cash and join the developer program. And is it really possible to call something nonpublic if anyone with $99 can get a copy of the SDK? Is this really what the law means by taking reasonable precautions to protect the so-called trade secrets? Go ask Apple's lawyers.
Despite Google's foresight to target screens of different sizes, I found it confusing to work through all of the XML and properties files. There's an old joke that a computer scientist solves problems by adding another layer of indirection. The Google programmers solved plenty of problems in making this new phone and you have to go chasing through multiple layers to figure out how to put the label on a button. This will pay off when your app runs in X different countries with Y different screen sizes, but still it's mind numbing.
While Java programmers will feel right at home with Android on Eclipse, it isn't just for Java programmers; the phone can run any language embedded in Java. Projects like Jython and JRuby are great solutions, and dozens are out there. There are similar options in the iPhone world, but they're crippled by Apple's fear of meta-programming and the evils that can be done with eval.
Through a camera, darkly The SDK is still showing some annoying rough spots. I wrote one app that used the camera, but it would often lock up, and I couldn't figure out why. The code would work in portrait but not landscape mode; one minute it worked and the next minute it crashed. I finally traced the problem to a "helpful" feature of the accelerometer, which would set the camera to portrait or landscape mode depending on the phone's orientation. If I held the phone in landscape mode, my view would crash because it was expecting a parameter that was tall, not wide. But if I turned it back to portrait, it mysteriously worked because the bounding rectangle for the screen was now taller, not wider. That took more than a few minutes to find.
