Beginning Android

Android devices, by and large, will be mobile phones. While the Android technology is being discussed for use in other areas (e.g., car dashboard “PCs”), for the most part, you can think of Android as being used on phones.

For developers, this has benefits and drawbacks.

On the plus side, circa 2009, Android‑style smartphones are sexy. Offering Internet services over mobile devices dates back to the mid‑1990s and the 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 to 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 won’t 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 “multi‑touch” LCDs are not a good mix).

• CPU speed and memory are tight compared to desktops and servers you may be used to.

• You can have any programming language and development framework you want, so long as it was what the device manufacturer chose and burned into the phone’s silicon.

• And, so on …

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 their phones don’t work, which is why the “Can you hear me now?” ad campaign from Verizon Wireless has been popular for the past few years. Similarly, those same people will get irritated at you if your program “breaks” their phone by

• tying up the CPU so that calls can’t be received

• not working properly with the rest of the phone’s OS, such that your application doesn’t quietly fade to the background when a call comes in or needs to be placed

• 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. You wind up with different‑looking tools, different‑behaving frameworks, and “different than you’re used to” limitations on what you can do with your program.

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) along with support for tools you may be used to (Eclipse).

• You get a fairly rigid and separate 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.

As you may expect, much of this book deals with that framework and how you write programs that work within its confines and take advantage of its capabilities.