Android Application Anatomy

An Android application consists of loosely coupled components, bound using a project manifest that describes each component and how they interact.

A peculiarity of Android is that an application can use elements of another application (provided that application permits it). For this purpose the system must be able to start an

35 application process when any part of it is required. That’s why Android applications don't have a single entry point. Rather, they have essential components that the system can instantiate and run as needed.

There are four types of independently launchable components:

Activities form the presentation layer of an application: an Activity usually coincides with

a single screen. Each activity is implemented as a single class that extends the Activity class, displays a user interface composed of Views and responds to events. Most applications consist of multiple screens. Each of these screens would be implemented as an activity. Moving to another screen is accomplished by starting a new activity. When a new screen opens, the previous screen is paused and put onto a history stack. The user can navigate backward through previously opened screens. Android uses a special class called Intent to move from screen to screen. An intent describes what an application wants to do while an IntentFilter is another class describing what kind of intents an Activity is able to handle. Navigating from screen to screen is accomplished by resolving intents. The process of resolving intents happens at run time. This gives two key benefits: Activities can reuse functionality from other components simply by making a request in the form of an Intent and can be replaced at any time by a new Activity with an equivalent IntentFilter.

Services are the invisible workers of an application used to perform regular processing

that needs to continue even when the Activities aren’t active or visible. A Service is long- lived code without a UI but rather running in the background for an indefinite period of time. However it’s possible to communicate with a service through an appropriate interface.

A typical function generally accomplished by a service is a background music player.

Broadcast Receivers enable the development of event-driven applications. They let

36 that match specific filter criteria (as we will see hereafter). When triggered by an event a Broadcast Receiver will automatically start the application component best matching the related Intent Filter. Broadcast receivers are usually registered in the AndroidManifest.xml file (described afterwards) of the application, which does not have to be running for its broadcast receivers to be called; the system will start the application, if necessary, when a Broadcast Receiver is triggered. Broadcast Receivers do not display a UI, although they may use the Notification Manager to alert the user if something interesting has happened.

Content Providers form shareable data stores. They are the preferred way for sharing

data across application boundaries. This means that it’s possible to configure Content Providers to permit access from other applications and use Content Providers exposed by others to access their stored data. The data can be stored in the file system, in an SQLite database or otherwise. Android devices include some native Content Providers allowing to share useful databases like contact information. A Content Provider can be made synchronizable by setting the proper attribute of the tag provider in the manifest. However a built-in synchronization service seems to be still unavailable at the moment so that one should implement its own synchronization logic to get a Provider actually synchronized.

Not every application needs to have all four, but all Android applications will be written with some combination of these components.

Now we will describe a few more elements which are not, strictly speaking, core components of an Android application but are essential for its working:

Intents are simple message-passing frameworks providing a facility for late run-time

binding between components in the same or different applications. The Intent object itself is a passive data structure holding an abstract description of an operation to be performed or, in the case of broadcasts, a description of something that has happened and is being announced. Intents can be divided into two groups.

37 Explicit intents designate the target component by its name. Since component names would generally not be known to developers of other applications, they are typically used for application-internal messages — such as an activity starting a subordinate service or launching another activity.

Implicit intents do not name a target but broadcast messages system-wide. They are often used to activate components in other applications. In this case the system must find the best component (or components) to handle the intent (a single activity or service to perform the requested action or the set of broadcast receivers to respond to the broadcast announcement) by comparing the contents of the Intent object to Intent Filters, structures associated with components that can potentially receive intents (see below).

Intent Filters advertise the capabilities of a component (activity, service or broadcast

receiver) to handle implicit intents. If a component does not have any intent filters, it can receive only explicit intents. A component with filters can receive both explicit and implicit intents. An explicit intent is always delivered to its target, no matter what it contains; the filter is not consulted. But an implicit intent is delivered to a component only if it can pass through one of the component's filters.

Notifications allow to signal users without interrupting their current Activities. They’re

the preferred technique for getting a user’s attention from within a Service or Broadcast Receiver. For example, when a device receives a text message or an incoming call, it alerts you somehow (by flashing lights, making sounds, displaying icons, or showing dialog messages).