Activity Lifecycle Interview Questions
ANDROID › Lifecycle
Walk me through, in your own words, why doing heavy work like a database write in onPause() is considered bad practice, even though it seems like the natural 'about to leave' hook.
What a strong answer covers: onPause is meant to be fast because the incoming activity's onResume() is synchronously blocked waiting for the current one to finish onPause, so a slow onPause causes visible jank in the transition or can even trigger an ANR on the activity coming to the foreground. On modern Android targeting API 28+, onSaveInstanceState is already called before onStop, giving a natural place for cheap state capture, so disk or database writes belong in onStop, or better, off the main thread entirely via a repository call scoped to the ViewModel or a background job.
When would you actually reach for a non-standard launch mode like singleTask or singleInstance instead of the default standard, and what goes wrong if you overuse them?
What a strong answer covers: singleTask and singleInstance solve 'there must be exactly one instance of this screen in the whole task or back stack' situations, like a hub screen other apps deep-link into, or a dedicated system-level UI such as a dialer; they're not for ordinary screens. Overusing them causes surprising back-stack behavior, existing instances receiving onNewIntent instead of a fresh onCreate, activities getting reparented into a different task, expected data being lost, which is hard to reason about and test, so the default standard mode with explicit intent flags per launch is usually the safer choice.
Two senior engineers disagree: one says lifecycle-aware components like ViewModel and LiveData make manual onPause/onStop bookkeeping obsolete, the other says you still need to manage raw callbacks for things like camera or sensor release. Who's right, and where's the line?
What a strong answer covers: Both are partially right. ViewModel, LiveData and Flow remove the need to manually wire most UI-state save and restore and observer subscribe or unsubscribe logic across pause and resume, but the raw lifecycle callbacks are still the correct place for anything tied to a system resource or piece of hardware that Android itself scopes to visibility or foreground state, such as releasing a Camera2 session in onPause, unregistering sensor listeners in onStop, or reacting to onTopResumedActivityChanged in multi-window. Lifecycle-aware components abstract UI state, they don't abstract device resource ownership.