An Android developer at Grooveshark

A simple introduction to the Android framework

with 7 comments

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.


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.


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 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 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!


Written by Skyler Slade

March 4, 2011 at 1:18 am

Posted in Uncategorized

7 Responses

Subscribe to comments with RSS.

  1. I’ve been following the tutorials on the android developer’s page and an it’s seriously in need of an overview like this, thanks for posting!


    March 4, 2011 at 1:14 pm

  2. Nicely concise and clear intro, thanks!


    March 4, 2011 at 2:10 pm

  3. I have just started my journey in Android development and this article gave me a very good grasp of the basic that I needed. Thanks!


    November 7, 2011 at 1:16 am

  4. I have just started top learn and develop android apps. The above introduction gave me an clear skeleton how android app works. Thanks for the information


    November 25, 2011 at 10:05 am

  5. Great article. I’ve been programming Android apps for a bit now but it’s still refreshing to read such a take on the structure of an app. Your writing style is nice and gives the article clarity. Thanks!


    May 2, 2012 at 3:39 am

  6. Great work ! Informative to all beginners like me. Thanks.


    March 18, 2013 at 4:56 am

  7. Nice and clear explanation.


    June 27, 2013 at 6:58 am

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: