how to manage Activity lifecycle in Android

1 onCreate: Initial Setup

This is for one-time construction. Inflate your layout, initialize non-UI components, and set up your ViewModel. Think: "What must exist before anything is visible?"

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)
    
    // ❌ Blocks UI thread
    val data = fetchDataFromNetwork() 
    textView.text = data
}

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)
    
    // Initialize ViewModel or adapter—no blocking operations.
    // Start heavy work in onStart or use background threads.
}

2 onStart: Visible but not Foreground

The Activity is now visible—the user can see it—but it doesn't yet have input focus. A translucent system dialog (like volume control) or a semi-transparent Activity on top puts you here.

3 onResume: Interactive and Foreground

This is the active state. Your Activity is in the foreground and receives all user input. This is where you start things that require the user's full attention: game loops, sensor listeners, camera preview.

// Re-register listeners that were unregistered in onPause()
override fun onResume() {
    super.onResume()
    sensorManager.registerListener(
        sensorListener, 
        sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER), 
        SensorManager.SENSOR_DELAY_NORMAL
    )
    gameView.resumeLoop()
}

override fun onPause() {
    super.onPause()
    // Unregister to avoid battery drain and memory leaks
    sensorManager.unregisterListener(sensorListener)
    gameView.pauseLoop()
}

1 Strict Sequence

The system marches through CREATED → STARTED → RESUMED. Each step unlocks the next. You cannot be interactive (RESUMED) if the window isn't even visible (STARTED).

2 Managing Background Tasks

A background thread that outlives the RESUMED state can crash your app if it tries to update a destroyed UI. Tie your work to the lifecycle.

class MainActivity : AppCompatActivity() {
    private var dataJob: Job? = null

    override fun onResume() {
        super.onResume()
        // Start work when interactive
        dataJob = lifecycleScope.launch {
            fetchDataAndUpdateUi() 
        }
    }

    override fun onPause() {
        super.onPause()
        // CRITICAL: Stop work when focus is lost
        dataJob?.cancel() 
    }
}

1 Misconception: "onPause means Hidden"

You might think onPause() means your Activity is no longer visible. Not necessarily. onPause() fires whenever your Activity loses foreground focus, even if it's still partially visible.

2 Pitfall: Assuming UI is Fully Stopped

If you treat onPause() as "the UI is gone" and release all resources here (like disconnecting a network client or destroying a heavy object), you'll pay a performance cost when onResume() has to rebuild them for a quick return.

3 Reality: Rapid Pause-Resume Cycles

Because onPause() doesn't guarantee onStop(), your app must be ready for rapid pause‑resume cycles. This is common with:

• Transient system dialogs (volume, permissions)
• Multi-window mode (another app briefly covers yours)
• Picture-in-picture transitions

class MainActivity : AppCompatActivity() {
    private var camera: Camera? = null

    override fun onResume() {
        super.onResume()
        // Reacquire only if needed—fast operation
        if (camera == null) {
            camera = openCamera() // Should be quick; use cached instance if possible
        }
        camera?.startPreview()
    }

    override fun onPause() {
        super.onPause()
        // Release immediately—system may kill us after this
        camera?.stopPreview()
        camera?.release()
        camera = null // Allow GC; will re-open on next onResume if needed
    }
}

1 Misconception: The Diagram is Static

Beginners often treat the lifecycle diagram as a rigid sequence. It's not. The system does not guarantee onStop after onPause, nor onDestroy after onStop. Your code must work correctly if any callback is the last one you receive.

2 Practical Impact: Where to Save Data?

Because the system can kill your process at any time after onPause(), you must treat onPause() as your "final chance" for critical saves.

override fun onStop() {
    super.onStop()
    // RISKY: If system kills after onPause(),
    // this never runs. Data is lost.
    saveUserProgressToPrefs()
}

override fun onPause() {
    super.onPause()
    // ✅ Safe: Guaranteed to run before potential kill.
    // Save critical state here.
    saveUserProgressToPrefs()
}

3 Pitfall: Ignoring onDestroy Cleanup

onDestroy is not guaranteed (the system can simply kill the process). You must not rely on it for releasing resources or saving data.

override fun onStop() {
    super.onStop()
    // Optional: Release expensive resources (images, listeners)
    // that don't need to persist if the app is killed.
}

override fun onDestroy() {
    super.onDestroy()
    // Rarely needed. Only for static cleanup or
    // things the OS won't clean up automatically.
}

1 The "Sticky Note" Strategy: onSaveInstanceState

onSaveInstanceState() is like a sticky note you leave on the door before you leave a room. It's useful for small, temporary UI state (like the text in a text field or the scroll position).

override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    // ❌ Risky: If user presses Back, this might not run.
    // ❌ Limit: Cannot save large data here.
    outState.putString("draft", editText.text.toString())
}

// ✅ Save immediately as user types
editText.doAfterTextChanged { text ->
    // Save to persistent storage (DB, SharedPreferences)
    preferenceManager.saveDraft(text.toString())
}

// Use Bundle only for tiny UI restoration
override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putInt("scrollPos", recyclerView.scrollPos)
}

2 The "Safe House": ViewModel

A ViewModel is a special container that survives configuration changes (like rotation). It lives in a separate memory store that the Activity doesn't own. When the Activity is destroyed and recreated, the ViewModel is passed the exact same instance.

class MyViewModel : ViewModel() {
    // LiveData survives rotation
    private val _items = MutableLiveData>()
    val items: LiveData> = _items

    fun loadItems() {
        // This runs ONCE. If rotated, this is skipped because data exists.
        viewModelScope.launch {
            _items.value = repository.getItems()
        }
    }
}

class MyActivity : AppCompatActivity() {
    private val viewModel: MyViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // Check if data is missing (Process Death) before loading
        if (viewModel.items.value == null) {
            viewModel.loadItems()
        }
    }
}

3 Resource Management: When to Clean Up?

Because ViewModel survives rotation but Activity doesn't, you must be careful about where you register listeners (like sensors or network callbacks). If you register them in the ViewModel, they might keep running even when the screen is off or the Activity is in the background.

class MyViewModel : ViewModel() {
    // ❌ Bad: Sensor keeps running even if Activity is destroyed
    init {
        sensorManager.registerListener(listener, ...)
    }
}

class MyActivity : AppCompatActivity() {
    // ✅ Good: Register in onStart, Unregister in onStop
    override fun onStart() {
        super.onStart()
        sensorManager.registerListener(listener, ...)
    }

    override fun onStop() {
        super.onStop()
        sensorManager.unregisterListener(listener)
    }
}

1 Design for State, Not Events

Beginners often try to handle every possible sequence by putting logic in multiple callbacks. This leads to tangled, error-prone code. The reality: the state (what the Activity can currently do) is more important than the event (which method was just called).

// ❌ Tangled logic across multiple callbacks
override fun onStart() {
    super.onStart()
    // Risk: Runs even if dialog is blocking input
    startCamera() 
}
override fun onResume() {
    super.onResume()
    // Redundant: Camera already running
    startCamera() 
}

// ✅ Clean state-based logic
override fun onResume() {
    super.onResume()
    startCamera() // Only runs when interactive
}
override fun onPause() {
    super.onPause()
    stopCamera()  // Pauses immediately
}

2 Pitfall: Over-using onCreate

onCreate() is for one-time initialization of the structure—inflating layout, creating ViewModels, setting up adapters. It is not for loading data that might change or be needed only while visible. Heavy work here blocks the first frame, causing jank.

3 Use Lifecycle-Aware Components

Android provides components that automatically respond to state changes when you tie them to a LifecycleOwner (like an Activity). This removes the need for you to manually start/stop things in every callback.

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)

    // ✅ RIGHT: Runs only while RESUMED, pauses automatically
    lifecycleScope.launch {
        repeatOnLifecycle(Lifecycle.State.RESUMED) {
            // This block suspends when Activity leaves RESUMED state
            val data = repository.loadHeavyData()
            updateUi(data) // Safe: only called when UI is interactive
        }
    }
}