Activity lifecycle.

An Activity is a screen in your app. But screens come and go. Users navigate, rotate devices, switch apps. Android manages your Activity through a lifecycle. Today we understand that lifecycle and how to work with it.

An Activity represents one screen.

When users open your app, they see an Activity. They interact with its UI. Each screen in your app is typically an Activity.

Activities are independent. One Activity can start another. They can pass data between them.

The system manages Activities. It creates them, destroys them, pauses them. You do not control when this happens. The system does.

Your job is to respond correctly. When the system creates your Activity, set up the UI. When it destroys, clean up.

Android calls specific methods as the Activity moves through states.

onCreate is called when the Activity is created. Initialize your UI here. Only called once per instance.

onStart is called when the Activity becomes visible. Not yet interactive, but visible.

onResume is called when the Activity starts interacting with the user. Fully visible and active.

onPause is called when the Activity loses focus. Another activity is coming. Still visible but not interactive.

onStop is called when the Activity is no longer visible. Another screen covers it completely.

onDestroy is called when the Activity is finishing. Clean up resources.

The lifecycle flows through states.

Launch: onCreate, onStart, onResume. The Activity becomes fully active.

Navigate away: onPause, onStop. The Activity goes to background.

Return: onRestart, onStart, onResume. Back to foreground.

Finish: onPause, onStop, onDestroy. The Activity is done.

Each transition triggers callbacks. Your code runs in response.

Not all transitions are smooth. The system might kill your Activity. You must handle unexpected destruction.

onCreate: set content view, initialize UI components, restore saved state. This is your setup.

onStart: start operations that should run while visible. Register listeners.

onResume: start operations that should run while active. Resume animations, acquire exclusive resources like camera.

onPause: release exclusive resources. Pause animations. Save lightweight state. Keep this fast.

onStop: save persistent state. Release resources not needed when hidden.

onDestroy: release all resources. Unregister all listeners. This is your final cleanup.

When configuration changes, the Activity is destroyed and recreated.

Rotate the device: configuration change. Language change: configuration change. Dark mode switch: configuration change.

The system destroys the Activity, then creates a new one. Your Activity must handle this.

onCreate is called again. Your UI must reinitialize. But you want to keep user state.

This is why state saving matters. The user was filling a form. Rotation should not lose their input.

onSaveInstanceState lets you save state before destruction.

override fun onSaveInstanceState outState Bundle. Put values in the bundle. outState dot putString key value.

The system passes this bundle to onCreate when recreating. savedInstanceState is null on first creation, non-null on recreation.

In onCreate, check if savedInstanceState is not null. If so, restore your state.

Keep saved state small. Only save what is needed to restore user experience. Large data should be in a ViewModel or database.

You can restore state in onCreate or onRestoreInstanceState.

onCreate: if savedInstanceState not null restore values.

onRestoreInstanceState is called after onStart, only when there is state to restore.

Both approaches work. Choose based on your needs. Most developers use onCreate.

For UI components like EditText, the system automatically saves and restores text. You only need to give the view an ID.

For custom state, you save and restore manually.

Modern Android provides lifecycle-aware components.

LifecycleOwner and LifecycleObserver let components respond to lifecycle events automatically.

ViewModels survive configuration changes. They hold UI state across rotations.

LiveData is lifecycle-aware: it only updates active observers. StateFlow is not; collect it with repeatOnLifecycle or collectAsStateWithLifecycle.

These tools reduce manual lifecycle management. Less code in callbacks. Fewer bugs.

We will explore these in later videos.

Let us summarize.

Activities are screens with a managed lifecycle.

Lifecycle callbacks let you respond to state changes: onCreate, onStart, onResume, onPause, onStop, onDestroy.

Configuration changes destroy and recreate the Activity.

Save state in onSaveInstanceState. Restore in onCreate or onRestoreInstanceState.

Use lifecycle-aware components to simplify management.

Respect the lifecycle. Initialize at the right time. Clean up at the right time.