Where Android beats the iPhone

Android's openness, flexibility, and Java foundation make it the best choice for many developers and the businesses that depend on them

1 2 3 4 Page 3
Page 3 of 4

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.

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.

1 2 3 4 Page 3
Page 3 of 4
How to choose a low-code development platform