Android Fundamentals: Activities & Lifecycle

Reviewed & published by Brayan K

Behind every Compose screen sits an Activity with a well-defined lifecycle. Understanding when the system creates, pauses, and destroys your screen is essential to avoid bugs and leaks.

Part of the free Kotlin course at LearnCodingFast — hands-on lessons with worked examples and the output they print, plus practice exercises and a quick quiz.

By the end you'll trace the lifecycle callbacks, see why a ViewModel survives rotation, and launch coroutines safely with viewModelScope.

What You'll Learn in This Lesson

• What an Activity is
• The lifecycle callback order
• onCreate / onStart / onResume
• onPause / onStop / onDestroy
• Why ViewModels survive rotation
• Launching coroutines in viewModelScope

1️⃣ The Activity Lifecycle

An Activity is a single screen. The OS calls lifecycle methods in a predictable order: onCreate then onStart then onResume on the way up, and onPause then onStop then onDestroy on the way down.

import android.os.Bundle
import android.util.Log
import androidx.activity.ComponentActivity

class MainActivity : ComponentActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        Log.d("LC", "onCreate")   // one-time setup goes here
    }

    override fun onStart() {
        super.onStart()
        Log.d("LC", "onStart")    // becoming visible
    }

    override fun onResume() {
        super.onResume()
        Log.d("LC", "onResume")   // foreground & interactive
    }

    override fun onPause() {
        super.onPause()
        Log.d("LC", "onPause")    // losing focus
    }

    override fun onDestroy() {
        super.onDestroy()
        Log.d("LC", "onDestroy")  // final cleanup
    }
}

Use each callback for the right job: one-time setup in onCreate, acquiring resources in onStart/onResume, releasing them in onPause/onStop.

2️⃣ ViewModel and viewModelScope

A ViewModel holds UI state that survives configuration changes like rotation. Launch asynchronous work in viewModelScope so it's cancelled automatically when the ViewModel is cleared.

import androidx.lifecycle.ViewModel
import androidx.lifecycle.viewModelScope
import kotlinx.coroutines.delay
import kotlinx.coroutines.flow.MutableStateFlow
import kotlinx.coroutines.flow.asStateFlow
import kotlinx.coroutines.launch

class CounterViewModel : ViewModel() {
    // UI state that survives configuration changes (rotation).
    private val _count = MutableStateFlow(0)
    val count = _count.asStateFlow()

    fun increment() {
        _count.value += 1
    }

    fun loadAfterDelay() {
        // viewModelScope cancels this coroutine when the ViewModel is cleared.
        viewModelScope.launch {
            delay(1000)
            _count.value = 100
        }
    }
}

Your turn. Replace the TODO, then run and read Logcat.

// 🎯 YOUR TURN — replace the TODO then reason about the logs.

import android.os.Bundle
import android.util.Log
import androidx.activity.ComponentActivity

class ProfileActivity : ComponentActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // 1) Log the FIRST lifecycle stage.
        //    👉 replace TODO with: Log.d("LC", "onCreate")
        TODO
    }

    override fun onResume() {
        super.onResume()
        Log.d("LC", "onResume")
    }
}

Mini-Challenge: A Name ViewModel

Build a ViewModel that holds a name in state and explain why it survives rotation.

// 🎯 MINI-CHALLENGE: a name ViewModel.
//
// 1. Create class NameViewModel : ViewModel().
// 2. Hold a MutableStateFlow<String> starting at "" exposed as a StateFlow.
// 3. Add fun setName(value: String) that updates the state.
// 4. Explain (in a comment) why the name survives screen rotation.
//
// ✅ setName("Ada") -> the exposed state emits "Ada",
//    and it is retained across configuration changes.

class NameViewModel /* : ViewModel() */ {
    // your code here
}

Common Errors (and the fix)

• State in the Activity — It's lost on rotation. Move UI state into a ViewModel.
• Forgetting super calls — Each lifecycle override must call super.onCreate(...) etc.
• Launching on the wrong scope — Use viewModelScope so coroutines are cancelled with the ViewModel.
• Heavy work in onCreate — Keep it light; do async work in a coroutine, not on the main thread.

Pro Tips

• 💡 One Activity, many composables: in modern apps a single Activity hosts Compose navigation.
• 💡 Expose immutable state: keep a private MutableStateFlow and expose a read-only StateFlow.
• 💡 Pair acquire/release: resources gained in onStart should be released in onStop.

📋 Quick Reference — Lifecycle

🎉 Lesson Complete!

• ✅ An Activity is one screen with a defined lifecycle
• ✅ Up: onCreate → onStart → onResume
• ✅ Down: onPause → onStop → onDestroy
• ✅ ViewModel retains UI state across rotation
• ✅ viewModelScope cancels coroutines on clear

Practice quiz

Continue this course

• Previous: Navigation in Compose
• Next: Serialization with kotlinx.serialization — @Serializable, Json.encodeToString/decodeFromString and @SerialName
• Quick reference: Kotlin cheat sheet

Frequently asked questions

What is an Activity and how does it relate to Compose?

An Activity is a single screen and an entry point into your app — the OS launches it and delivers lifecycle callbacks. With Compose, you typically have one (or few) Activity that calls setContent { } in onCreate to host your composables, and you navigate between screens using Navigation-Compose rather than launching a new Activity per screen.

What's the order of the main lifecycle callbacks?

Starting up: onCreate (one-time setup) then onStart (becoming visible) then onResume (foreground and interactive). Going away: onPause (losing focus) then onStop (no longer visible) then onDestroy (final cleanup). Returning from stopped uses onRestart then onStart then onResume. Knowing this order tells you where to acquire and release resources.

Why use a ViewModel instead of keeping state in the Activity?

An Activity instance is destroyed and recreated on configuration changes such as rotation, so state stored in it is lost. A ViewModel is retained across those changes, so UI state survives. It also separates UI logic from the screen, making code testable. The Activity (or composable) observes the ViewModel's state and just renders it.

What is viewModelScope and why does it matter?

viewModelScope is a CoroutineScope tied to the ViewModel's lifecycle. Coroutines you launch in it — for network calls, database reads, timers — are automatically cancelled when the ViewModel is cleared (onCleared). That prevents leaks and 'zombie' work after the screen is gone. It's the idiomatic place to start asynchronous work that backs the UI.