Mark Murphy - Beginning Android

MARK MURPHY is the founder of CommonsWare and the author of the Busy Coders Guide to Android Development. A three-time entrepreneur, his experience ranges from consulting on open source and collaborative development for the Fortune 500 to application development on just about anything smaller than a mainframe. He has been a software developer for over 25 years, from the TRS-80 to the latest crop of mobile devices. A polished speaker, Mr. Murphy has delivered conference presentations and training sessions on a wide array of topics internationally.

Mr. Murphy writes the Building Droids column for AndroidGuys and the Android Angle column for NetworkWorld.

Outside of CommonsWare, Mr. Murphy has an avid interest in how the Internet will play a role in citizen involvement with politics and government. He is also a contributor to the Rebooting America essay collection.

I would like to thank the Android team, not only for putting out a good product, but for invaluable assistance on the Android Google Groups. In particular, I would like to thank Romain Guy, Justin Mattson, Dianne Hackborn, Jean-Baptiste Queru, Jeff Sharkey, and Xavier Ducrohet.

Icons used in the sample code were provided by the Nuvola icon set.

Thanks for your interest in developing applications for Android! Increasingly, people will access Internet-based services using so-called non-traditional means, such as mobile devices. The more we do in that space now, the more that people will help invest in that space to make it easier to build more powerful mobile applications in the future. Android is new Android-powered devices appeared on the scene first in late 2008 but it likely will rapidly grow in importance due to the size and scope of the Open Handset Alliance.

Most of all, thanks for your interest in this book! I sincerely hope you find it useful and at least occasionally entertaining.

If you are interested in programming for Android, you will need at least basic understanding of how to program in Java. Android programming is done using Java syntax, plus a class library that resembles a subset of the Java SE library (plus Android-specific extensions). If you have not programmed in Java before, you probably should learn how that works before attempting to dive into programming for Android.

The book does not cover in any detail how to download or install the Android development tools, either the Eclipse IDE flavor or the standalone flavor. The Android Web site covers this quite nicely. The material in the book should be relevant whether you use the IDE or not. You should download, install, and test out the Android development tools from the Android Web site before trying any of the examples listed in this book.

This book is being produced via a partnership between Apress and CommonsWare. You are reading the Apress edition, which is available in print and in digital form from various digital book services.

CommonsWare continually updates the original material and makes it available to members of its Warescription program, under the title The Busy Coders Guide to Android Development.

CommonsWare maintains a FAQ about this partnership at http://commonsware.com/apress.

The source code samples shown in this book are available for download from the Apress Web site., in case you have the desire to reuse any of it.

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 Apples 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 wont 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 phones silicon.

And, so on

Moreover, applications running on a phone have to deal with the fact that theyre on a phone.

People with mobile phones tend to get very irritated when their phones dont 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 cant be received

not working properly with the rest of the phones OS, such that your application doesnt quietly fade to the background when a call comes in or needs to be placed

crashing the phones 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 youre 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.

When you write a desktop application, you are master of your own domain. You launch your main window and any child windows like dialog boxes that are needed. From your standpoint, you are your own world, leveraging features supported by the operating system, but largely ignorant of any other program that may be running on the computer at the same time. If you do interact with other programs, it is typically through an API, such as using JDBC (or frameworks atop it) to communicate with MySQL or another database.

Android has similar concepts, but packaged differently, and structured to make phones more crash-resistant.

The building block of the user interface is the