Component - 1. Activity

Components - Activity 

1. Activities are like stand-alone systems on desktops
2. An activity is usually a single screen 

• Implemented by extending “Activity” class
•  Displays user interface controls (views)
• Reacts on user input/events 

    3 An application typically consists of several screens

• Each screen is implemented by one activity
• Moving to the next screen means starting a new activity
• An activity may return a result to a previous activity 

---> An application usually consists of multiple activities that are loosely bound to each other. Typically, one activity in an application is specified as the "main" activity, which is presented to the user when launching the application for the first time. Each activity can then start another activity in order to perform different actions. Each time a new activity starts, the previous activity is stopped, but the system preserves the activity in a stack (the "back stack"). When a new activity starts, it is pushed onto the back stack and takes user focus. The back stack abides to the basic "last in, first out" queue mechanism, so, when the user is done with the current activity and presses the BACK key, it is popped from the stack (and destroyed) and the previous activity resumes.
Creating an Activity

• Create a new Activity by extending the Activity class.
• Override the onCreate() method to set the view for the activity
• Set the user interface to an Activity using the setContentView method in the onCreate method of the Activity.
• Use the findViewById(int) method to retrieve the reference of the widgets in UI.

 The basic skeleton code for a new activity is shown below :
                         public class MyActivity extends Activity {
                                 public void onCreate(Bundle icicle) {
                                super.onCreate(icicle);
                                setContentView(R.layout.main);
                              }
                         }


Activity Lifecycle

• Activities in the system are managed as an activity stack.
• The Android memory manager uses this stack to determine the priority of applications based on their Activities when deciding which application to terminate to free resources.
• An activity has essentially four states:

1. Active : An activity in the foreground of the screen.
2. Paused : An activity has lost focus but is still visible.
3. Stopped : An activity is completely obscured by another activity.
4. Inactive : After an Activity has been killed or before it has been launched.

State paths of an Activity:

Figure 1. The activity lifecycle.

The same lifecycle callback methods are listed in table 1, which describes each of the callback methods in more detail and locates each one within the activity's overall lifecycle, including whether the system can kill the activity after the callback method completes.

Table 1. A summary of the activity lifecycle's callback methods.

Method			Description	Killable after?	Next
onCreate()			Called when the activity is first created. This is where you should do all of your normal static set up — create views, bind data to lists, and so on. This method is passed a Bundle object containing the activity's previous state, if that state was captured (see Saving Activity State, later). Always followed by onStart().	No	onStart()
	onRestart()		Called after the activity has been stopped, just prior to it being started again. Always followed by onStart()	No	onStart()
	onStart()		Called just before the activity becomes visible to the user. Followed by onResume() if the activity comes to the foreground, or onStop() if it becomes hidden.	No	onResume() or onStop()
		onResume()	Called just before the activity starts interacting with the user. At this point the activity is at the top of the activity stack, with user input going to it. Always followed by onPause().	No	onPause()
		onPause()	Called when the system is about to start resuming another activity. This method is typically used to commit unsaved changes to persistent data, stop animations and other things that may be consuming CPU, and so on. It should do whatever it does very quickly, because the next activity will not be resumed until it returns. Followed either by onResume() if the activity returns back to the front, or by onStop() if it becomes invisible to the user.	Yes	onResume() or onStop()
	onStop()		Called when the activity is no longer visible to the user. This may happen because it is being destroyed, or because another activity (either an existing one or a new one) has been resumed and is covering it. Followed either by onRestart() if the activity is coming back to interact with the user, or by onDestroy() if this activity is going away.	Yes	onRestart() or onDestroy()
onDestroy()			Called before the activity is destroyed. This is the final call that the activity will receive. It could be called either because the activity is finishing (someone called finish() on it), or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method.	Yes	nothing