Android App Development Hard to Beat

I gotta say, Google Android is going to blow the iPhone and iOS away.

Now, I don't say this because I think Android phones or the Android user experience are necessarily better. In fact, with respect to the user experience, I think quite the opposite.  I switched from an iPhone to a Samsung Captivate (Android 2.1) and I'd have to say that the user experience was hands-down better on the iPhone. The ease of use and slickness in terms of the way applications were integrated on the iPhone was far superior. Now, a techie like me can tweak Android out to make it pretty nice too, but someone like my wife - forget it! She got my iPhone 3G as a hand-me-down, and it will be more phone that she needs.

Still, I think Android will dominate the market space. A big reason I believe this is the Android SDK - and I'll explain why in a couple of paragraphs - but first, some background:

If you know me well, you're probably aware that I go all-out with the lights at Christmas, including wearing a Light Suit to events like the Trail of Lights fun run and the Capitol Tree lighting. My home lights are already synchronized to sound an music, but this year, I wanted synchronized lights on my light suit too. You can follow my endeavors in more detail on my other blog, AustinLightGuy.wordpress.com. I had already written a custom light sequence application for my home lights, in which I can compose and run complex sequences in time with music, but those take a lot of time to compose. I wanted a more diverse play list for the light suit, so I also wrote a visualization plugin for Windows Media Player which uses the WMP-supplied frequency info to drive light channels more or less to the beat. The plugin results are not as impressive in terms of patterns timed perfectly to the music, but I don't have to spend time composing sequences. Both can run on a small laptop in a backpack or whatever.

I sort of want the best of both worlds when I go out with this contraption - I want to be able to play lots of songs through WMP, but I also want to be able to play the well-choreographed sequences for maximum impact from time to time. I had already developed the Sequencer, which I wrote in C#, to incorporate the ability to launch sequences from external apps via remoting. That made it really easy for me to throw together another little Windows app that has an embedded Windows Media Player ActiveX control which can play a playlist and also supports the visualization. The app can also submit sequences to the sequencer via remoting. I incorporated some simple RESTful services using System.Net.HttpListener (kudos to Microsoft for making that really easy too, by the way) and Presto! - a RESTful HTTP service that can play MP3's or sequencer sequences. I was basically done - I can network my phone to the laptop via AdHoc wifi, hit a simple control page, and play either way...but...  My buddy Richard was telling me how easy it was to write Android apps, so I thought I'd take a quick stab at writing a simple native app that hits the same RESTful services.

So here at last is my point.  It is really easy for a Java developer to write Android apps.  Google's developer docs are quite thorough and the SDK includes plenty of samples. The SDK is available for the PC, Mac and Linux. You want to develop an iPhone app? You'd better have a Mac. It also includes an emulator, a plugin for Eclipse (which can debug code running in the emulator), and you can sign and deploy apps right to your phone.  But more importantly, you write your app in Java. UI layout is nicely separated in XML layout files and you interact with it using a pretty basic object model and a simple GUI event mechanism. Everything else is just basic Java and, of course, it's open - no going through iTunes, no waiting on approval from Apple, no OS secrets - just write and deploy.

Code Sample

To talk to my RESTful services, I just use standard Java coding incorporating standard JDK functionality in the java.net package. If you've done any Development using Google's GWT UI toolkit, you'll find the event model quite familiar...probably not too different from Swing development either, although I've really only barely dabbled in that.

Screen Shot of Sequence Control App

So my point is this; there are millions of Java developers out here.  Seriously - about 10 million. By making the barrier to entry for this huge population of developers to write apps for Android very low, Google has, in my opinion, ensured that Android will be the first choice for developers wanting to target a mobile platform. Sure, if they want saturation, they'll do both, but they'll still develop for Android first (a lot of them may just stop there or run out of venture funds :-). And some percentage of those 10 million who, like me, just want to write a cool mobile app won't bother with the iPhone.  By making it super easy for a huge developer community to write apps for Android, Google has effectively ensured that more apps will be written for Android.

Six months ago, I heard in the news that Android phones have passed iPhone in market share. It was just about three years ago today that Google announced Android - several months and a couple of years of R&D behind Apple - and yet the platform is already winning. This seems phenomenal to me, but is no longer surprising.  Sure, it has a lot to do with the fact that a lot of vendors are producing smart phones that compete with the iPhone, but that's kind of the point. These vendors have chosen Android. They've chosen it because it's a robust smartphone OS. There are various hardware discriminators; slide-out keyboards, bigger screens  (I like the big, bright AMOLED screen on the Captivate).  But those features are really kind of a wash. Vendors will be leapfrogging each other hardware-wise from now to eternity. But the big discriminator is Apps. More apps = more users = more phones and Google has guaranteed there will be more Android apps. Just you watch!