Benefits and Drawbacks of Android Programming

Android is everywhere: Phones, Tablets, TVs and set-top boxes powered by Google TV. Soon, Android will be in cars, in in-flight entertainment system on planes, and even in robots!

However, the general theme of Android devices will be smaller screens and/or no hardware keyboard. And, by the numbers, Android will probably be associated mostly with smartphones for the foreseeable future. For developers, this has both benefits and drawbacks.

On the plus side, Android-style smartphones are sexy. Offering Internet services over mobile devices dates back to the mid-1990s and Handheld Device Markup Language (HDML). However, only in recent years have phones capable of Internet access taken off. Now, thanks to trends like text messaging and products like Apple's iPhone, phones that can serve as Internet-access devices are rapidly gaining popularity. So, working on Android applications gives you experience with an interesting technology (Android) in a fast-moving market segment (Internet-enabled phones), which is always a good thing.

The problem comes when you actually have to program the darn things.

Anyone with experience in programming for PDAs or phones has felt the pain of phones simply being small in all sorts of dimensions:

• Screens are small (you will not get comments like, "Is that a 24-inch LCD in your pocket, or...?").
• Keyboards, if they exist, are small.
• Pointing devices, if they exist, are annoying (as anyone who has lost their stylus will tell you) or inexact (large fingers and "multitouch" LCDs can sometimes be...problematic).
• CPU speed and memory are always behind what's available on desktops and servers.

Moreover, applications running on a phone have to deal with the fact that they're on a phone.

People with mobile phones tend to get very irritated when those phones do not work. Similarly, those same people will get irritated if your program "breaks" their phones by:

• Typing up the CPU such that call can't be received.
• Not quietly fading into the background when a call comes in or needs to be placed, because the program doesn't work properly with the rest of the phone's operating system.
• Crashing the phone's operating system, such as by leaking memory like a sieve.

Hence, developing programs for a phone is a different experience than developing desktop applications, web sites, or back-end server processes. The tools look different, the frameworks behave differently, and you have more limitations on what you can do with your programs.

What Android tries to do is meet you halfway:

• You get a commonly used programming language (Java) with some commonly used libraries (e.g., some Apache Commons APIs), with support for tools you may be used to using (Eclipse).
• You get fairly rigid and uncommon framework in which your programs need to run so they can be "good citizens" on the phone and not interfere with other programs or the operation of the phone itself.