A Look at Android Development

I stumbled across this article on Android development today, and it was a very interesting read. The author gave a very balanced look at the Android platform, saying what he thought was good and bad. It reads like a very honest assessment. I didn't detect any obvious spin.

The one area where I don't agree with the author is his statement on Android's Intent/Activity model. This post claims that Android is "a big step ahead of the current iPhone programming model", but I can't help but to be reminded of OpenDoc and CyberDog. This idea of getting "away from monolithic, isolated applications" is not new; it's been floating around at least since the 1990s. If you look at theoretical, rather than practical implementations, it probably goes back much further than that, even.

Yet, here we are in 2009 still using monolithic applications.

Oh, wait, no we aren't. Not really.

When I write an iPhone application, much of the functionality I'm using wasn't written by me and isn't part of my application. It's part of a framework that's already on the phone. I think time has shown that the content-focused (or, intent-focused, if you will) way of dividing up code is problematic at best. It's great in theory, but problematic in practice.

In the example in the blog posting, how do I know if that barcode application is installed? What do I do if it's not? This approach opens up a huge number of problems with testing, installation, and development that offset any of the gains you get from not having code duplicated. The problems of Intent/activity are even more pronounced on an open platform like Android where the user has a lot of flexibility in terms of how they configure it and what they install on it.

This concept also just doesn't really fit the mobile application model that well. The iPhone isn't a general-purpose computer, and neither is an Android phone. If you look at the general population of consumers using smart phones, the way they use the phone the vast majority of the time really doesn't lend itself to this concept at all. They use and expect small applications to serve a defined, finite purpose.

If you're building megalithic applications for a smart phone, you're (quite simply) doing it wrong, and if you're not, you're not going to get all that much benefit from Intent/Activity, and you are going to pay a price in added complexity in the development process and the install process, not to mention greatly increasing the likelihood of problems for your customers.

That's not to say that the iPhone couldn't use some improvement in the inter-application communication arena. We currently have the ability to register application URLs, but it's a one-way trip. I can launch a barcode application, but I can't tell the barcode program to send me anything back unless I control both applications. In reality, I'm not sure how big of a limitation this really is, however. Most of the time, we're not going to want to rely on another application's functionality to handle an important application task unless the other app is one we wrote and have control over. If that's the case, then we have access to the source code and can included the functionality in the app and make it self-contained, greatly reducing the chance that our customers will have problems and get mad at us.

Posted in: Android,iPhone SDK,Other blogs