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.
Read more: androiddevblog
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.
Read more: androiddevblog