HomebaseWorks
Lesson 1 of 4

Activity lifecycle, intents and ViewModel

Know what the system does to your screens, how screens open each other, and where to keep data so it survives.

EWritten by the HomebaseWorks editorial team · reviewed 26 Oct 2026

Android can pause, stop or destroy your screens at any time: when the user rotates the phone, opens another app, or the system needs memory. Good apps expect this, and screening questions check that you do too.

Advertisement

The Activity lifecycle

Opening a screen calls onCreate(), onStart() (visible) and onResume() (interactive). Leaving it calls onPause(), then onStop() when it is no longer visible, and onDestroy() if it is finished. A rotation, by default, runs the full teardown and then creates a new Activity. So anything held only in Activity fields, such as a loaded list, is lost. Fragments have a similar lifecycle tied to their host, plus a separate view lifecycle; touch views only between onViewCreated() and onDestroyView().

ViewModel and LiveData

A ViewModel holds screen state and survives configuration changes:

class ProfileViewModel(private val repo: UserRepo) : ViewModel() {
    private val _user = MutableLiveData<User>()
    val user: LiveData<User> = _user

    fun load(id: Long) = viewModelScope.launch {
        _user.value = repo.getUser(id)
    }
}

The Activity observes user. LiveData only delivers updates while the screen is at least started, and drops the observer when it is destroyed. Never keep a reference to an Activity or View inside a ViewModel, because the ViewModel outlives them and causes leaks. For very small state that must also survive process death, use saved state.

Intents

  • Explicit: names the target, such as Intent(this, DetailActivity::class.java). Used inside your app.
  • Implicit: describes an action, such as Intent(Intent.ACTION_VIEW, Uri.parse(url)), and lets the system choose an app.
  • Pass small values with putExtra; pass an id rather than a large object.

Runtime permissions

Dangerous permissions such as camera, location and microphone must be declared in the manifest and requested while the app runs. Ask at the moment the feature is used, explain why, and keep the app usable if the user refuses.

Habit: after building a screen, rotate it, send the app to the background and return. If anything resets or crashes, the state is in the wrong place.

Advertisement
Continue with Android4 lessons · 1 interview set · 1 test · 1 certificate
Not tested

More in Web and app