Where Android beats the iPhone

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.

Page Break

It's also important to recognize that a wide variety of options need explicit permission, and you must declare this in the AndroidManifest.xml file. On several occasions, my code wouldn't run simply because I forgot to turn on the permission to use the camera. Yet the error messages never said something like, "Go edit the manifest, doofus." This configuration, by the way, is implemented with a precision that programmers will love but might leave end-users a bit befuddled. There's one XML tag that enables the camera, while another enables the autofocus on the camera.

These features are lovingly enumerated for everyone downloading a new app. Presumably there are people who want to install software that uses the camera but not the autofocus, but my eyes glaze over when I get to the screen filled with a long list of permissions I'm about to grant. For all I know, I've clicked on one with the XML tag <uses-feature android:name="android.permission.take.first.born">.

There are deeper issues that suggest how difficult it will be for Google to maintain consistency between the various phones. Some commenters at the Android marketplace have already developed a shorthand for buggy software that crashes: FC for Force Close. Some code that works on the Droid will "FC" on the Nexus One.

I think Google worked hard to future-proof its API, and the company certainly did a better job than Apple of planning for tablets and other bigger screens with different sizes. Still, I think the programmers will be testing their code on a number of devices for a long time. That's just one of the disadvantages to encouraging 50-plus models of phones to sport the operating system.

At times, this Java-based world feels just a bit too hardcore. While most of the comparisons in this review are with the dominant iPhone, it's worth mentioning that the Palm Pre and Palm's Mojo SDK may offer much of the flexibility of Android but in a dramatically simpler package. Most of the coding is done with CSS, JavaScript, and HTML, which are much simpler alternatives to the endless layers of XML and Java needed to build an Android app.

Droid futures The most interesting question to me is how Android's openness will change the entire ecosystem on the phone. On the first day I had the Nexus One, I created an entirely new test Gmail account to avoid any problems when I returned the phone. Yet when I called a friend by typing in his phone number, his face popped up on the screen. Was this a demonstration of the power of Google's endless databases to link together everything?

After some experimentation, I concluded that the photo came from the Facebook app I had installed on the phone. When I logged in to Facebook, the app pulled pictures, phone numbers, and who knows what else into my phone. I think I accepted this feature when the Facebook app's AndroidManifest.xml file was loaded, and I'm not sure if I can ever get rid of it.

This deeper openness is going to be the source of any number of surprises that will be even greater and more useful than the unexpected appearance of my friend's photo on the phone. I think some of the more serious companies will start to release APIs to their apps, allowing the programs themselves to link together and solve problems.

But the openness may also be a source of privacy and security nightmares. Banks and other organizations with sensitive information will want to walk carefully into this world. Many of the worst exploits today result from hackers stringing together two or three seemingly harmless features like the one that links photos to the dialer.

There are other interesting questions about the role of cloud services in our smartphone future. Google is still guarding access to the Maps API and forcing developers to get an API key before deploying. I wouldn't be surprised if Apple, Palm, and others are frantically working on their own mapping, search, mail, and who knows what other cloud services. Right now the phones are little clients that aren't too closely linked to the Websites, but I can see that changing if better performance makes it possible to tilt the playing field. The quality of the cloud may become just as important as the slick GUI, app store, or number of pixels in the screen.

This interaction with the cloud will be a question for the future. Right now, it seems that Apple won over the latte-sipping fashion plates who love the endless stream of cute games. Apple's decision to court the game developers is paying off in some amazing titles, but the Android platform is a real workhorse. Anyone who wants to do more than play games will find a huge range of possibilities in the Android platform.

While Apple is reportedly fixing some of the worst problems with the App Store process, the Android world avoids most of them by giving people the freedom to use the platform as they want. Considering that people have been using this freedom relatively successfully with PCs for decades, it's a welcome opportunity in the world of handhelds.