A central feature of Android is that one application can make use of elements of other applications (provided those applications permit it).
Android applications don’t have a single entry point for everything in the application (no main() function, for example). Rather, they have essential components that the system can instantiate and run as needed.
There are four types of components:
An activity presents a visual user interface for one focused endeavor the user can undertake. For example, an activity might present a list of menu items users can choose from or it might display photographs along with their captions. A text messaging application might have one activity that shows a list of contacts to send messages to, a second activity to write the message to the chosen contact, and other activities to review old messages or change settings. Though they work together to form a cohesive user interface, each activity is independent of the others. Each one is implemented as a subclass of the Activity base class.
What the activities are, and how many there are depends, of course, on the application and its design. Typically, one of the activities is marked as the first one that should be presented to the user when the application is launched.
Parent views contain and organize the layout of their children.
Leaf views (those at the bottom of the hierarchy) draw in the rectangles they control and respond to user actions directed at that space.
The content view is the View object at the root of the hierarchy.
Thus, views are where the activity’s interaction with the user takes place.
A view hierarchy is placed within an activity’s window by the Activity.setContentView() method.
A service doesn’t have a visual user interface, but rather runs in the background for an indefinite period of time. For example, a service might play background music as the user attends to other matters, or it might fetch data over the network or calculate something and provide the result to activities that need it. Each service extends the Service base class.
A broadcast receiver is a component that does nothing but receive and react to broadcast announcements. Many broadcasts originate in system code — for example, announcements that the timezone has changed, that the battery is low, that a picture has been taken, or that the user changed a language preference.
An application can have any number of broadcast receivers to respond to any announcements it considers important. All receivers extend the BroadcastReceiver base class.
Broadcast receivers do not display a user interface. However, they may start an activity in response to the information they receive, or they may use the NotificationManager to alert the user.
A content provider makes a specific set of the application’s data available to other applications. The data can be stored in the file system, in an SQLite database, or in any other manner that makes sense. The content provider extends the ContentProvider base class to implement a standard set of methods that enable other applications to retrieve and store data of the type it controls.