Activity and Activity Lifecycle

                                     Topic: Activity and Activity Lifecycle

Introduction to Activity:

Activity represents a single screen with which a user can interact. It is managed as an activity stack. When a new activity is started, it is placed on the top of the stack and becomes the running activity. The previous activity always remains below it in the stack, and will not come to the foreground again until the new activity exits. 

Introduction to Lifecycle:

Lifecycle is a class that holds the information about the lifecycle state (stages that will occur when the activity is running) of a component (like an activity or a fragment) and allows other objects to observe this state. It performs action in response to a change in the lifecycle status.

Lifecycle uses two main enumerations to track the lifecycle status for its associated component:

Event

The lifecycle events that are dispatched from the framework and the Lifecycle class. These events map to the callback events in activities and fragments.

State

The current state of the component tracked by the Lifecycle object.

A good example to illustrate the above 2 components is a Graph where a node is state and edges are events.

                       

Introduction to Activity-Lifecycle:

To navigate transitions between stages of the activity lifecycle, the Activity class provides a core set of six callbacks: onCreate(), onStart(), onResume(), onPause(), onStop(), and onDestroy(). The system invokes each of these callbacks as an activity enters a new state.

Within the lifecycle callback methods, you can declare how your activity behaves when the user leaves and re-enters the activity. For example, if you're building a streaming video player, you might pause the video and terminate the network connection when the user switches to another app. When the user returns, you can reconnect to the network and allow the user to resume the video from the same spot. In other words, each callback allows you to perform specific work that's appropriate to a given change of state.

1)   onCreate() method:-

This callback fires when the system first creates the activity. On activity creation, the activity enters the Created state. In the onCreate() method, you can perform basic application startup logic that should happen only once for the entire life of the activity. It means that it will contain your all main code. For example, if you are preparing an app in which you are storing the name, class and roll numbers of the students then the all code needed to do so will be written in this method.

It shows fundamental setup for the activity, such as declaring the user interface (defined in an XML layout file), defining member variables, and configuring some of the UI.

 Example:-

 TextView textView;

@Override
public void onCreate(Bundle savedInstanceState) {

// call the super class onCreate to complete the creation of activity //like the view hierarchy.
    super.onCreate(savedInstanceState);

// set the user interface layout for this activity the layout file is //defined in the project res/layout/main_activity.xml file.
    setContentView(R.layout.main_activity);

// initialize member TextView so we can manipulate it later
    textView = (TextView) findViewById(R.id.text_view);

// other code

}

 After the onCreate() method finishes execution, the activity enters the Started state, and the system calls the onStart() and onResume() methods in quick succession.

2)   onStart() method:-

The onStart() call makes the activity is becoming visible to the user, as the app prepares for the activity to enter the foreground and become interactive. For example, this method is where the app initializes the code that maintains the UI.

@Override
    public void onStart() {
        super.onStart();

// code
       

    }

 The onStart() method completes very quickly and, as with the Created state, the activity does not stay resident in the Started state. Once this callback finishes, the activity enters the Resumed state, and the system invokes the onResume() method.

3)   onResume() method :-

This is the state in which the app interacts with the user. The app stays in this state until something happens to take focus away from the app. Such an event might be, for instance, receiving a phone call, the user’s navigating to another activity, or the device screen’s turning off.

When an interruptive event occurs, the activity enters the Paused      state, and the system invokes the onPause() callback.If the activity returns to the Resumed state from the Paused state, the system once again calls onResume() method. For this reason, you should implement onResume() to initialize components that you release during onPause(), and perform any other initializations that must occur each time the activity enters the Resumed state.

 Example:

@Override
protected void onResume() {
    // call the superclass method first
    super.onResume();

  // code

   .……..

             }

4)   onPause() method:-

The system calls this method as the first indication that the user is leaving your activity (though it does not always mean the activity is being destroyed); it indicates that the activity is no longer in the foreground (though it may still be visible if the user is in multi-window mode).

 Example:

@Override
protected void onPause () {
    // call the superclass method first
    super.onPause();

//code

……….

}

5) onStop() method:-

When your activity is no longer visible to the user, it has entered the Stopped state, and the system invokes the onStop() callback. This may occur, for example, when a newly launched activity covers the entire screen. The system may also call onStop() when the activity has finished running, and is about to be terminated.

 Example:

@Override
protected void onStop() {
    // call the superclass method first
    super.onStop();

  //code

}

From the Stopped state, the activity either comes back to interact with the user, or the activity is finished running and goes away. If the activity comes back, the system invokes onRestart(). If the Activity is finished running, the system calls onDestroy().

6)    onDestroy():-

When the activity moves to the destroyed state, any lifecycle-aware component tied to the activity's lifecycle will receive the ON_DESTROY event. This is where the lifecycle components can clean up anything it needs to before the Activity is destroyed.

You can distinguish between these two scenarios with the isFinishing() method. 

If the activity is finishing, onDestroy() is the final lifecycle callback the activity receives. If onDestroy() is called as the result of a configuration change, the system immediately creates a new activity instance and then calls onCreate() on that new instance in the new configuration. 

The onDestroy() callback should release all resources that have not yet been released by earlier callbacks such as onStop().

Example:

@override 

protected void onDestory()

{

// call the superclass method first

Super.onDestory();

……….

}

In the next post you will learn about states of activity (that describes the killing prcocess of an activity by the system) and you will also learn an interesting concept that, how you can save the state of the activity from killing by the system.

for any query feel free to comment and contact me.