Part I

Core Concept

Chapter 1

The Big Picture

Android is everywhere. Phones. Tablets. TVs and set-top boxes powered by Google TV. Soon, Android will be in cars, in in-flight entertainment systems 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, as described next. This chapter also describes the main components in an Android application and the Android features that you can exploit when developing your applications.

Benefits and Drawbacks of Smartphone Programming

On the plus side, 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 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

• Tying up the CPU such that calls 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 a 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.

As you might 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.

What Androids Are Made Of

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 application programming interface (API), such as Java Database Connectivity (JDBC), or frameworks atop it, to communicate with MySQL or another database.

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

• Activities: The building block of the user interface is the activity. You can think of an activity as being the Android analogue for the window or dialog box in a desktop application or the page in a classic web application. Android is designed to support lots of cheap activities, so you can allow users to keep tapping to open new activities and tapping the Back button to back up, just like they do in a web browser.
• Services: Activities are short-lived and can be shut down at any time. Services, on the other hand, are designed to keep running, if needed, independent of any activity, akin to the notion of services or daemons on other operating systems. You might use a service to check for updates to an RSS feed or to play back music even if the controlling activity is no longer operating. You will also use services for scheduled tasks (“cron jobs”) and for exposing custom APIs to other applications on the device, though those are relatively advanced capabilities.
• Content providers: Content providers provide a level of abstraction for any data stored on the device that is accessible by multiple applications. The Android development model encourages you to make your own data available to other applications, as well as your own applications. Building a content provider lets you do that, while maintaining complete control over how your data gets accessed. Content providers can be anything from web feeds, to local SQLite databases, and beyond.
• Intents: Intents are system messages that run around the inside of the device and notify applications of various events, from hardware state changes (e.g., an SD card was inserted), to incoming data (e.g., a Short Message Service [SMS] message arrived), to application events (e.g., your activity was launched from the device's main menu). Intents are much like messages or events on other operating systems. Not only can you respond to an Intent, but you can create your own to launch other activities or to let you know when specific situations arise (e.g., raise such-and-so Intent when the user gets within 100 meters of this-and-such location).

Stuff at Your Disposal

• Storage: You can package data files with your application for things that do not change, such as icons or help files. You also can carve out a small bit of space on the device itself, for databases or files containing user-entered or retrieved data needed by your application. And, if the user supplies bulk storage, like an SD card, you can read and write files on there as needed.
• Network: Android devices generally are Internet-ready, through one communications medium or another. You can take advantage of the Internet access at any level you wish, from raw Java sockets all the way up to a built-in WebKit-based web browser widget you can embed in your application.
• Multimedia: Android devices have the ability to play back and record audio and video. While the specifics may vary from device to device, you can query the device to learn its capabilities and then take advantage of the multimedia capabilities as you see fit, whether that is to play back music, take pictures with the camera, or use the microphone for audio note-taking.
• Location services: Android devices frequently have access to location providers, such as GPS and cell triangulation, which can tell your applications where the device is on the face of the Earth. In turn, you can display maps or otherwise take advantage of the location data, such as to track a device's movements if the device has been stolen.
• Phone services: Because Android devices are typically phones, your software can initiate calls, send and receive SMS messages, and do everything else you expect from a modern bit of telephony technology.

The Big Picture...of This Book

Now that you have the Android big picture, here is what's coming in the rest of this book:

• The next two chapters are designed to get you going quickly with the Android environment, through a series of step-by-step, tutorial-style instructions for setting up the tools you need, creating your first project, and getting that first project running on the Android emulator.
• The three chapters that follow explain a bit more about what just happened in Chapters 2 and 3. We examine the Android project that we created, talk a bit more about Eclipse, and discuss some things we could add to the project to help it run on more devices and enhance its capabilities.
• The bulk of the book explores the various capabilities of the Android APIs—how to create components like activities, how to access the Internet and local databases, how to get your location and show it on a map, and so forth.