Android interview questions

By default the Activity is destroyed and recreated with the new configuration. I keep screen data in a ViewModel, which survives the change, and use saved state for small values that must survive process death too. I avoid blocking rotation in the manifest, because that only hides the problem.

onStart means the Activity is visible, and onResume means it is in the foreground and receiving input. A dialog-style Activity on top can pause yours while it stays visible. I start camera previews or sensors in onResume and release them in onPause.

The ViewModel lives longer than the Activity, for example across a rotation. Holding the old Activity keeps it and its whole view tree in memory, which is a leak. If I need a Context for something long-lived, I use the application context.

I use Kotlin coroutines, launching from viewModelScope and switching to Dispatchers.IO for network or disk work, or using suspend functions that already do it, like Room's. The main thread only updates the UI. This avoids frozen screens and app-not-responding errors.

It creates only the rows needed to fill the screen and recycles them as the user scrolls, using ViewHolders to keep view references. I keep onBindViewHolder light, load images asynchronously and use ListAdapter with DiffUtil so only changed rows are updated.

Composables are functions that redraw when the state they read changes. I hold state with remember and mutableStateOf for UI details, and in a ViewModel for screen data, then pass values down and events up. A plain variable inside a composable does not trigger a redraw, which is a common bug.