Anatomy Of An Android Application

 There are four building blocks to an Android application:

• Activity
• Intent Receiver   
• Service   
• Content Provider

Not every application needs to have all four, but your application will be written with some combination of these. Once you have decided what components you need for your application, you should list them in a file called AndroidManifest.xml. This is an XML file where you declare the components of your application and what their capabilities and requirements are.I will post soon,what the AndroidManifest.xml is responsible for.

Activity :

Activities are the most common of the four Android building blocks. An activity is usually a single screen  in  your application. Each activity is implemented as a single class that extends the Activity base class. Your

class will display a user interface composed of Views and respond to events. Most applications consist of

multiple screens. For example, a text messaging application might have one screen that shows a list of contacts to send messages to, a second screen to write the message to the chosen contact, and other screens to review old messages or change settings. Each of these screens would be implemented as an  activity.

Moving to another screen is accomplished by a starting a new activity. Insome cases an Activity may return a value to the previous activity – for example an activity that lets the user pick a photo would return the chosen photo to the caller.

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 in the history. Screens can also choose to be removed from the history stack when it would be inappropriate for them to remain. Android retains history stacks for each application launched from the home screen.

Intent and Intent Filters :

Android uses a special class called Intent to move from screen to screen. Intent describe  what   an   application wants done. The two most important parts of the intent data structure are the action and the data

to   act   upon. Typical values for action are MAIN (the  front door of the application),VIEW,PICK, EDIT,   etc.The data is expressed as a Uniform Resource Indicator (URI). For example, to view a website in the browser, you would create an  Intent with the VIEW action and the data set to a Website-URI.

new Intent(android.content.Intent.VIEW_ACTION,

        ContentURI.create ("http://anddev.org"));

There is a related class called an Intent Filter.While an intent is effectively a request to do something, an intent filter is a description of what intents an activity (or  intent receiver, see below)is capable of handling. An activity that is able to display contact information for a person would publish an IntentFilter that said that  it knows how to handle the action VIEW when applied to data representing a person. Activities publish their IntentFilters in the AndroidManifest.xml file.

Navigating from screen to screen is accomplished by resolving intents. To navigate forward, an activity calls startActivity(myIntent). The system  then looks at the intent filters for all installed applications and picks the activity whose intent filters best matches myIntent. The new activity is informed of  the intent, which causes   it to be launched. The process of resolving  intents happens at run time when startActivity is called, which offers two key benefits:

1) Activities can reuse functionality from other components simply

     by making a request in the form of an Intent

2) Activities can be replaced at any time by a new Activity with an

    equivalent IntentFilter

Intent Receiver :

You can use an IntentReceiver when you  want code in your application to execute in reaction to an   external event, for example,when the phone rings,or when the data network is available,or when it's midnight. Intent receivers do not display a UI, although they may display Notifications to alert the user if  something interesting has happened. Intent receiver are also registered in AndroidManifest.xml, but you can   also register them from code using Context.registerReceiver(). Your application does not have to be   running for its intent  receivers to be called; the system will start your application, if necessary, when an intent receiver is triggered. Applications can also send their own intent broadcasts to others with Context.broadcastIntent().

Service :

A Service is code that is long-lived and runs without a UI. A good example of this is a media player playing songs  from a play list. In a media player application, there would probably be one or more activities that allow the user to choose songs and start playing them. However, the music playback itself should not be  handled  by an activity because the user will expect the music to keep playing even after navigating to a new screen. In this case, the media player activity could start a service using Context.startService() to run in the   background to keep the music going. The system will then keep the music playback service running until it has finished. (You can learn more about the priority given to services in the system by reading Life Cycle of an Android Application.) Note that you can connect to a service (and start it if it's not already running) with the Context.bindService() method. Whenconnected to a service, you can communicate with it through an interface exposed by the service. For the music service, this might allow you to pause, rewind, etc.

Content Provider :

Applications can store their data in files, a SQLite database, preferences or any other mechanism that makes sense. A content provider, however, is useful if you want your application's data to be shared with other applications. A content provider is a class that implements a standard set of methods to let other applications store and retrieve the type of data that is handled by that content provider.