Some of the more common questions that I see posted to various Android development forums are from developers curious about, or new to the platform, and looking for a good, light introduction to it all. This is my best attempt at a thorough, simple summary.

An Android application should be thought of as a package comprised of separate, loosely-coupled components connected at runtime, not as a single executable. These components work together by responding to events, or Intents , that are broadcast by other components included in an application, or by the Android system. Each Android app has a “manifest” file, AndroidManifest.xml , that lists each component that an app includes, and which Intents , if any, will trigger these components to do work.

Intents

In its simplest form, an Intent contains an “action” string, which is usually represented as a Java package name prefixed to something like “action.COMMAND_NAME.” An Intent action might be “com.example.action.DOWNLOAD_LATEST_WEATHER,” for example. Many framework components are capable of broadcasting an Intent , and likewise many framework components are capable of registering to receive these broadcasts. To be notified when a particular Intent is broadcast, an application can create a BroadcastReceiver that listens for the broadcast of a specific Intent action. Intents are really just a way of connecting callbacks.

An Intent can also contain a Map of key-value pairs that is sent along as “extras” when the Intent is broadcast. Like the value 32601 for the extra “userZipcode.”

Services and BroadcastReceivers

These separate framework components work together to support Android’s multitasking model because – among other things – they allow parts of an application to do work even when the user is doing other things, like checking his email or browsing a web page.

To give an example, BroadcastReceivers allow apps to be notified when the phone’s SD card is mounted, or when a text message is received, even when the app, or package, to which the component belongs is not in the foreground. Likewise, Services allow an app to perform long-running tasks in the background, like playing music. Services and BroadcastReceivers can be combined to create an application that performs a task triggered by a system event, like downloading the latest weather report when the phone’s location changes.

Note that Services allow applications to do work in the background only in the sense that an application is doing work without any of its Activities being open and visible to the the user in the foreground, though this work is still being done on the app’s main, or UI, thread. It’s important to understand that all framework components, and almost all SDK-provided framework component instances, run on the main thread. One exception that I’m aware of is IntentService , which is useful if you want to perform a task in the background, on a background thread.

Activities

As alluded to, Activities are the parts of an app that users can see and with which they may interact. An Activity has a view which is built from xml that you create, and it can contain widgets like buttons, text input fields, date pickers, and other common user-interface components. It also contains these views’ click-listeners and any other supporting code. Activities allow an application to show AlertDialogs , ProgressDialogs , Toast notifications, and other things that can be used to grab a user’s attention or prompt him for input. Using callbacks that you may override, Activities can have menus that are activated by the phone’s “menu” hard-key, and list items can have long-press, or context, menus.

ContentProviders

ContentProviders are used to make an application’s data available to other apps on a user’s phone. A scheduling app might make its appointments available to be read by other applications, using a ContentProvider .

Putting it together

You can use as many of these components in your application, or package, as you like: there’s nothing in the framework that restricts you to using one single Activity , or even one single Service , and there’s nothing in the framework that requires you to use any components that you don’t need. For example, the Grooveshark app has 31 Activities , 3 Services , many BroadcastReceivers , but no ContentProviders .

As a person uses an Android app, they navigate from Activity to Activity , just as they might browse a series of pages on a web site. And just like URL arguments or forms are used to send information from page-to-page, Android apps use Intent extras to send things between Activities . Just as a person might leave a web site at any time, a user of an Android app might leave, or pause, the app at any time by pressing the phone’s “home” hard key. The framework provides callbacks that you may override in your Activity instances, letting you save and resume state when this happens.

Undoubtedly, parts of the Android framework documentation can be overwhelming and confusing, but the basics don’t have to be. The SDK documentation has improved immensely over the past year, and I’ve no doubt that it will continue to get better going forward.

For a more in-depth discussion of framework components and their usage, the SDK Application Fundamentals doc is an absolutely fantastic resource, which you can read at http://developer.android.com/guide/topics/fundamentals.html. If you’re still curious about Android development, read through this a few times and really be sure that you’ve got a good understanding of the basics before you move on to any advanced concepts.

Good luck writing apps!