Title Unit -4 Android Activity.pdf ✅

1 Unit -4 Android Activity [4 Hrs] The Activity Life Cycle Every instance of Activity has a lifecycle. During this lifecycle, an activity transitions between three possible states: running, paused, and stopped. For each transition, there is an Activity method that notifies the activity of the change in its state. As a user navigates through, out of, and back to your app, the Activity instances in your app transition through different states in their lifecycle. The Activity class provides a number of callbacks that allow the activity to know that a state has changed: that the system is creating, stopping, or resuming an activity, or destroying the process in which the activity resides. 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. Doing the right work at the right time and handling transitions properly make your app more robust and performant. For example, good implementation of the lifecycle callbacks can help ensure that your app avoids: • Crashing if the user receives a phone call or switches to another app while using your app. • Consuming valuable system resources when the user is not actively using it. • Losing the user's progress if they leave your app and return to it at a later time. • Crashing or losing the user's progress when the screen rotates between landscape and portrait orientation. 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. Figure 4-1 shows the activity lifecycle, states, and methods.
2 Figure 4-1. A simplified illustration of the activity lifecycle onCreate() You must implement this callback, which fires when the system first creates the activity. On activity creation, the activity enters the Created state. In the onCreate() method, you perform basic application startup logic that should happen only once for the entire life of the activity. @Override protected void onCreate(Bundle b) { super.onCreate(b); //your stuffs }
3 onStart() When the activity enters the Started state, the system invokes this callback. The onStart() call makes the activity 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. 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. @Override protected void onStart() { super.onStart(); //your stuffs } onResume() When the activity enters the Resumed state, it comes to the foreground, and then the system invokes the onResume() callback. 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. @Override protected void onResume() { super.onResume(); //your stuffs } onPause() 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). Use the onPause() method to pause or adjust operations that should not continue (or should continue in moderation) while the Activity is in the Paused state, and that you expect to resume shortly. There are several reasons why an activity may enter this state. For example: • Some event interrupts app execution, as described in the onResume() section. This is the most common case. • In Android 7.0 (API level 24) or higher, multiple apps run in multi-window mode. Because only one of the apps (windows) has focus at any time, the system pauses all of the other apps. • A new, semi-transparent activity (such as a dialog) opens. As long as the activity is still partially visible but not in focus, it remains paused.
4 @Override protected void onPause() { super.onPause(); //your stuffs } onStop() 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. You should also use onStop() to perform relatively CPU-intensive shutdown operations. For example, if you can't find a more opportune time to save information to a database, you might do so during onStop(). @Override protected void onStop() { super.onStop(); //your stuffs } onDestroy() onDestroy() is called before the activity is destroyed. The system invokes this callback either because: • the activity is finishing (due to the user completely dismissing the activity or due to finish() being called on the activity), or • the system is temporarily destroying the activity due to a configuration change (such as device rotation or multi-window mode) 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(). @Override protected void onDestroy() { super.onDestroy(); //your stuffs } Following example will demonstrate lifecycle of android: