Sonali Gadave
A21 MSc CS
Mobile technologies
Blog link : [Link]
the-android-activity-lifecycle-the-blueprint-of-your-app-
understanding-the-android-1a512253f477
Understanding the Android Activity Lifecycle:
The Blueprint of Your App
Understanding the Android Activity Lifecycle is the absolute cornerstone of Android
development. Whether you are building a simple calculator or a complex social media app,
managing how your "screens" appear, disappear, and persist is what separates a buggy app from
a seamless user experience.
What is an Activity?
In the Android ecosystem, an Activity is a single, focused thing that the user can do. It's
essentially one "screen" of your application. Almost all activities interact with the user, so the
Activity class takes care of creating a window in which you can place your user interface (UI).
While a desktop app might have a "main" function that runs everything, Android initiates code in
an Activity instance by calling specific callback methods that correspond to specific stages of
its lifecycle. These callbacks allow you to tell your activity exactly how to behave when the user
enters, leaves, or returns to it.
The Lifecycle Pyramid
Think of the Activity Lifecycle as a stepped pyramid. At the top, the activity is in the foreground,
fully created and interacting with the user. At the bottom, it is completely destroyed and removed
from memory. The transitions between these states are managed by seven primary callback
methods.
Here is a visual representation of the overall flow:
1. onCreate()
This is the first callback and the only one you must implement. This is where you perform basic
application startup logic that should happen only once for the entire life of the activity (e.g.,
calling setContentView() to define the UI layout, initializing views, or binding data to lists).
2. onStart()
The activity enters the "Started" state. The UI becomes visible to the user, but they cannot
interact with it yet. This is where the app prepares to come to the foreground.
3. onResume()
This is the state in which the app begins interacting with the user. This is the Active state. The
activity stays in this state until something happens to take focus away from the app (like
receiving a phone call or navigating to another activity).
4. onPause()
The system calls this method as the first indication that the user is leaving your activity. The
activity is no longer in the foreground but might still be partially visible (for example, if a semi-
transparent dialog or a permission request appears over it).
Here is a simple visualization of the difference between an activity being Paused versus being
fully Stopped:
You should use onPause() to pause ongoing actions like video playback or GPS updates that
consume battery while the user isn't actively engaged. This callback should be very fast.
5. onStop()
The activity is no longer visible to the user. This might happen because a new activity is
covering the entire screen. Here, you should release heavy resources that are not needed while
the user isn't seeing the app (e.g., stopping animations, closing database connections, or saving
persistent data).
6. onDestroy()
The final call before the activity is destroyed and removed from memory. This happens either
because:
1. The user explicitly finishes the activity (by hitting "Back").
2. The system is temporarily destroying the activity due to a
configuration change (like rotating the screen from portrait to
landscape).
If the destruction is due to a configuration change, the system will immediately start a new
lifecycle, calling onCreate() again for the new configuration.
Here is how the main states flow into each other:
Common Scenarios & Transitions
Scenario Lifecycle Transitions
App Launch (First time) onCreate() → onStart() →
onResume()
Home Button Pressed onPause() → onStop()
Return to App (from onRestart() → onStart()
Background) → onResume()
Back Button Pressed onPause() → onStop() →
onDestroy()
Screen Rotation onPause() → onStop() →
onDestroy() →
onCreate() → onStart() →
onResume()
Dialog Appearance onPause()
Closing a Dialog onResume()
onResume
Key Takeaway on State Management
One of the most crucial concepts is handling the “Stopped” and “Destroyed”
states properly. Consider an app where the user has filled out half of a long
form.
If the user temporarily leaves the app (causing it to be “Stopped”) or rotates
the screen (causing it to be “Destroyed”), and you haven’t implemented
state saving, all that user data will be lost when they return.
[Image illustrating UI state preservation in Android. This diagram shows two
paths for an activity: one on configuration change (like rotation) and one
when process is killed due to memory pressure. It visually contrasts how
ViewModel and onSaveInstanceState handle data retention in these
scenarios.]
To prevent this data loss, developers must use architectural components like
ViewModel (for configuration changes) or implement onSaveInstanceState()
(for system-initiated process death) to preserve critical UI data.
Code Example: Seeing It In Action
The best way to truly learn this is by doing. Here is a simple Android Activity
where we implement logs for every callback. When you run this app, you can
watch the Logcat in Android Studio to see these states trigger in real-time as
you interact with your phone.
Package [Link];
Import [Link];
Import [Link];
Import [Link];
Public class MainActivity extends AppCompatActivity {
Private static final String TAG = “LifecycleDemo”;
// 1. MUST Implement: Activity is first created
@Override
Protected void onCreate(Bundle savedInstanceState) {
[Link](savedInstanceState);
setContentView([Link].activity_main);
Log.d(TAG, “onCreate() called: Activity created.”);
// 2. Activity becomes visible to the user
@Override
Protected void onStart() {
[Link]();
Log.d(TAG, “onStart() called: Activity visible.”);
// 3. Activity enters foreground & user interaction starts
@Override
Protected void onResume() {
[Link]();
Log.d(TAG, “onResume() called: Activity active.”);
// --- User Leaves ---
// 4. First indicator user is leaving (partially visible, loses focus)
@Override
Protected void onPause() {
[Link]();
Log.d(TAG, “onPause() called: Pausing ongoing actions.”);
// 5. Activity is no longer visible
@Override
Protected void onStop() {
[Link]();
Log.d(TAG, “onStop() called: Releasing heavy resources.”);
// 6. User is returning to a previously stopped activity
@Override
Protected void onRestart() {
[Link]();
Log.d(TAG, “onRestart() called: Activity restarting.”);
// 7. Activity is being destroyed and removed from memory
@Override
Protected void onDestroy() {
[Link]();
Log.d(TAG, “onDestroy() called: Activity destroyed.”);
}
Best Practices
Save UI State: Because activities are frequently destroyed (on rotation), use
ViewModel or onSaveInstanceState() to ensure the user doesn’t lose their
data (like text typed into an input field or their scroll position).
Don’t Over-initialize in onCreate: Keep your startup logic lean to ensure the
app opens quickly. Avoid loading massive databases or performing heavy
network calls on the main thread in onCreate().
Clean Up Resources Properly: Always pair your “Start” and “Stop” logic. If
you start a sensor or animation in onStart(), make sure to stop it
symmetrically in onStop(). If you allocate something heavy in onCreate(),
clean it up in onDestroy().
Mastering these callbacks ensures that your app handles interruptions
gracefully and manages system resources efficiently. Happy coding!