Android Developer interview questions

Structured concurrency ties coroutine lifetimes to an explicit scope and its job hierarchy.

• A parent does not complete until all of its child coroutines complete.
• Cancelling a scope propagates cancellation to its children, so work does not outlive its owner.
• An unhandled child failure normally cancels the parent and its sibling coroutines.
• Builders such as coroutineScope preserve this structure without blocking the current thread.

A CoroutineScope provides the CoroutineContext used to launch coroutines, while Job represents their lifecycle.

• CoroutineContext is a set of elements such as Job, dispatcher, name, and exception handler.
• A builder inherits its scope's context and adds or replaces elements supplied to that builder.
• The new coroutine usually creates a child Job linked to the Job in the inherited context.
• Cancelling the scope's Job cancels the coroutine tree rooted in that scope.

Use supervision when sibling coroutines should fail independently while remaining owned by the same parent.

• With a regular Job, an unhandled child failure cancels the parent and its other children.
• With SupervisorJob, one child's failure does not automatically cancel its siblings or supervisor.
• Each supervised child must expose or handle its own failure because the supervisor does not absorb it as success.
• supervisorScope gives the same failure isolation for a bounded suspending block.

Choose a dispatcher according to the kind of work rather than creating threads directly.

• Dispatchers.Main runs UI work on Android's main thread and Main.immediate can run inline when already there.
• Dispatchers.IO is designed for blocking I/O and can expand beyond the CPU-oriented pool.
• Dispatchers.Default is sized for CPU-bound work such as parsing or calculations.
• A well-designed suspending function uses withContext internally when it must move blocking or CPU-heavy work.

Coroutine cancellation is cooperative because a coroutine stops only when it observes that its Job is cancelled.

• Standard suspending functions check cancellation and throw CancellationException.
• CPU loops should call ensureActive or yield periodically when they have no suspension points.
• CancellationException should normally be rethrown rather than converted into a domain failure.
• Cleanup that must suspend can run in finally with NonCancellable used only for that bounded cleanup.

launch reports an uncaught exception immediately, while async stores it until the Deferred result is awaited.

• A root launch can deliver its exception to a CoroutineExceptionHandler after normal propagation rules apply.
• await rethrows the exception captured by async to the awaiting caller.
• A failed child still participates in parent cancellation even if its Deferred is never awaited.
• try and catch should surround the suspending call or await point where recovery is meaningful.

A suspending function can pause without occupying its current thread, whereas a blocking function holds the thread until it finishes.

• The suspend modifier enables suspension points but does not automatically move work off the caller's dispatcher.
• A suspending function may still block if it calls a blocking API directly.
• Blocking I/O should be isolated with withContext on an appropriate dispatcher.
• Suspension preserves local control flow through continuations instead of requiring callbacks.

withContext derives a context for a suspending block and resumes the caller in its original context afterward.

• Supplied elements replace matching keys from the current CoroutineContext, such as the dispatcher.
• The call suspends until the block completes and returns its result directly.
• It preserves structured concurrency because the caller waits for the block and its children.
• Cancellation remains linked to the caller unless the Job is deliberately replaced, which is rarely appropriate.

A regular Flow is cold because its producer block starts separately for each collector.

• Creating a Flow does not execute its upstream code.
• Every collection repeats upstream work unless the Flow is shared with stateIn or shareIn.
• Each collector receives values from its own execution of the flow builder.
• Collection suspends until the flow completes or the collecting coroutine is cancelled.

StateFlow models observable state, while SharedFlow is a configurable hot stream for broadcasts.

• StateFlow always has a current value and immediately gives the latest value to a new collector.
• StateFlow suppresses updates that are equal according to equality comparison.
• SharedFlow configures replay, extra buffer capacity, and overflow behavior without requiring an initial value.
• Neither stream completes merely because collectors disappear, so its owning scope controls its lifetime.

flowOn changes the coroutine context of the upstream operators that precede it.

• Downstream collection continues in the collector's context, preserving context safety.
• When the dispatcher changes, flowOn introduces a coroutine and channel boundary between upstream and downstream.
• Multiple flowOn calls apply to their respective upstream segments rather than the whole pipeline globally.
• emit should not switch context manually inside a flow builder because Flow enforces context preservation.

Choose the operator according to whether new input should cancel, replace, or run alongside earlier work.

• mapLatest cancels the current transformation when a newer upstream value arrives.
• flatMapLatest switches to the newest inner Flow and cancels collection of the previous one.
• flatMapMerge collects multiple inner Flows concurrently up to its concurrency limit.
• Regular map is sufficient when each value maps to one non-Flow result and all transformations must finish.

These operators change how a slow collector interacts with a faster upstream producer.

• buffer lets upstream production and downstream processing overlap through a channel.
• conflate keeps only the most recent pending value while the collector is busy.
• collectLatest cancels the current collector block when a new value arrives.
• Conflation is appropriate only when intermediate values are replaceable rather than required events.

Collect UI Flows only while the relevant Lifecycle is in an active state.

• repeatOnLifecycle launches the collection block at the chosen state and cancels it when the lifecycle falls below that state.
• A new block is launched when the lifecycle re-enters the state, so the upstream must tolerate repeated collection.
• Multiple Flows that need parallel collection should be launched as separate children inside the repeat block.
• In Compose, collectAsStateWithLifecycle provides the corresponding state adapter for lifecycle-aware collection.

Use callbackFlow to adapt a callback-based API into a cold Flow with safe concurrent emission.

• trySend forwards callback values to the Flow's channel without requiring the callback to suspend.
• awaitClose keeps the producer active and unregisters the callback when collection ends.
• Registration failures should close the channel with the cause rather than emit a fake data value.
• The adapter starts once per collector unless the resulting Flow is shared explicitly.

A ViewModel should own screen-level state and presentation logic without depending on a concrete view instance.

• It survives configuration changes while its Activity, Fragment, or navigation entry remains logically alive.
• It exposes immutable observable state and receives user actions through explicit methods or intents.
• It delegates data access and domain rules to repositories or use cases instead of becoming a service locator.
• It must not retain Activity, Fragment, View, or other short-lived Context references.

viewModelScope is a lifecycle-owned CoroutineScope cancelled when the ViewModel is cleared.

• Its SupervisorJob lets sibling coroutines fail independently.
• Its main dispatcher suits launching presentation work, while lower layers remain responsible for main-safe execution.
• Coroutines survive configuration changes because the same ViewModel instance is retained.
• It does not survive process death, so durable or restorable state needs another mechanism.

Prefer StateFlow for coroutine-based state pipelines, while LiveData remains useful for existing lifecycle-centric APIs and codebases.

• StateFlow has an explicit current value and composes with the full Flow operator set.
• LiveData automatically limits observer callbacks according to LifecycleOwner state.
• StateFlow collection needs a lifecycle-aware adapter such as repeatOnLifecycle or collectAsStateWithLifecycle.
• Conversion at the UI boundary is preferable to maintaining the same state independently in both types.

A ViewModel should mutate private state and expose only a read-only StateFlow to consumers.

• MutableStateFlow keeps writes inside the component that owns state transitions.
• asStateFlow prevents callers from assigning arbitrary values while avoiding a second stream.
• Updating with the atomic update function prevents lost changes when transformations can race.
• A single immutable state model makes rendering and state-transition tests deterministic.

Persistent conditions belong in state, while non-repeatable effects need an explicit delivery model.

• StateFlow is suitable for renderable facts such as content, selection, and loading status.
• Replaying a navigation or snackbar event after recreation may repeat an action that already happened.
• A Channel with receiveAsFlow gives single-consumer queued delivery, while a configured SharedFlow supports broadcast semantics.
• If an effect represents an unhandled business fact, model and acknowledge that fact in state instead of hiding it as a transient event.