Every question, in one place

A dispatcher decides which thread(s) a coroutine runs on.

• Dispatchers.Main - the Android UI thread. Use for touching views/Compose state. Main.immediate runs synchronously if you’re already on Main, avoiding an extra re-dispatch.
• Dispatchers.IO - an elastic dispatcher tuned for blocking I/O: legacy network calls, file reads, and blocking database APIs. Its default parallelism limit is at least 64 or the number of CPU cores (whichever is larger), and it shares threads with Default.
• Dispatchers.Default - a pool sized to the number of CPU cores, for CPU-bound work: parsing, sorting, JSON, image processing.
• Dispatchers.Unconfined - starts in the calling thread and resumes in whatever thread the suspending function used. Rarely used in app code; mainly for specific library/testing cases.

suspend fun loadAndProcess(): Result = withContext(Dispatchers.IO) {
    val raw = legacyBlockingApi.download()      // blocking I/O → IO pool
    withContext(Dispatchers.Default) {
        parseAndSort(raw)                       // CPU-heavy → Default
    }
}

Key points interviewers probe:

• IO vs Default is the most-asked distinction: IO for waiting (blocking calls), Default for computing. They actually share threads, but IO permits many more concurrent blocking ops.
• Main-safe suspending APIs such as Retrofit’s suspend support and Room’s suspend queries already keep blocking work off Main; don’t add an IO hop by reflex. Check the API contract.
• withContext(Dispatchers.IO) is preferred over launch(Dispatchers.IO) for “do this blocking thing and give me the result.”
• limitedParallelism(n) carves a bounded view out of a dispatcher to cap concurrency (e.g. one network host).

They all execute a block on an object; they differ in how you reference the object (it vs this) and what they return (the object vs the lambda result).

Function	Receiver	Returns	Typical use
let	it	lambda result	null-checks, transform a value
run	this	lambda result	run a block + return a result
with	this	lambda result	group calls on one object (not an extension)
apply	this	the object	configure/build an object
also	it	the object	side effects (logging, validation)

// let - operate on a nullable, transform
val len = name?.let { it.trim().length } ?: 0

// apply - configure and return the same object
val paint = Paint().apply {
    color = Color.RED
    isAntiAlias = true
}

// also - side effect, pass through
val user = repo.load().also { Log.d("TAG", "loaded $it") }

How to choose (the mental model interviewers like):

• Need the result of the block? → let / run / with.
• Need the object back (chaining/config)? → apply / also.
• Referencing members a lot? → this-receivers (run/with/apply) read cleaner.
• Want an explicit name for clarity? → it-receivers (let/also).

apply for building, also for side effects, let for null-safe transforms are the three you’ll reach for most.

A thread is an OS-level construct with a large fixed stack (~1MB+ on the JVM). Creating thousands is expensive in memory and context-switching. A coroutine is a language-level construct - essentially a resumable computation - that runs on top of threads.

The key differences:

• Cheap. You can launch hundreds of thousands of coroutines; they’re objects, not OS threads. Many coroutines share a small pool of threads.
• Suspend, don’t block. A coroutine waiting on I/O suspends and frees its thread for other coroutines. A blocked thread sits idle holding its stack.
• Structured. Coroutines form parent/child scopes with automatic cancellation and error propagation - threads have none of that.
• Cooperative scheduling at suspension points, vs. preemptive OS thread scheduling.

// 100k coroutines - fine. 100k threads - OutOfMemoryError.
repeat(100_000) {
    launch { delay(1000); print(".") }
}

coroutines don’t replace threads - they multiplex work onto threads efficiently. “Lightweight” means the cost is a small state-machine object plus a continuation, not an OS thread.

Interview clincher: “Suspension releases the underlying thread; blocking holds it. That’s why a handful of Dispatchers.IO threads can serve thousands of concurrent suspended network calls.”

Kotlin encodes nullability in the type system. String can never be null; String? can. The compiler forces you to handle the nullable case before you can dereference it, which eliminates most NullPointerExceptions at compile time.

The main tools:

• Safe call ?. - returns null instead of throwing if the receiver is null: user?.name.
• Elvis ?: - supply a fallback: user?.name ?: "Guest".
• Smart casts - after a != null check, the compiler treats the variable as non-null inside that block.
• !! (not-null assertion) - tells the compiler “trust me, this isn’t null.” If it is, it throws an NPE. It’s an escape hatch that throws away the guarantee you came for.

val length = name?.length ?: 0   // safe
val forcedLength = name!!.length // throws if name is null

Practical guidance: !! is a code smell - reserve it for genuine impossibilities, and prefer ?., ?:, requireNotNull() (which throws a meaningful message), or restructuring so the value can’t be null. Also mention platform types (String!) from Java interop: the compiler can’t verify them, so annotate Java APIs or null-check at the boundary.

The headline difference is eager vs lazy evaluation, but Sequence is not automatically faster.

• On a List, each operation (map, filter, …) is processed fully and creates a new intermediate list before the next operation runs. It’s horizontal: do all the maps, then all the filters.
• On a Sequence, elements flow through the whole chain one at a time, lazily, with no intermediate collections. It’s vertical: each element goes through map → filter → … until a terminal operation pulls it.

// List: builds a full mapped list of a million items, then filters it
val r1 = (1..1_000_000).map { it * 2 }.filter { it % 3 == 0 }.first()

// Sequence: pulls elements until first match - barely any work
val r2 = (1..1_000_000).asSequence().map { it * 2 }.filter { it % 3 == 0 }.first()

Use ordinary collection operations for small inputs or a single transformation: they are simple and often faster because sequences add iterator/lambda overhead. Reach for Sequence when you have a large input, several intermediate operations, or a short-circuiting terminal operation such as first, take, or any. Measure hot paths instead of treating laziness as a universal optimization.

When sequences win: large collections, multiple chained operations, or short-circuiting terminals (first, take, find) - you avoid allocating big intermediate lists and can stop early.

When lists win: small collections or a single operation. Sequences add per-element overhead (an iterator hop per stage), so for small data the simpler List is actually faster.

• var - a mutable (reassignable) variable.
• val - a read-only reference. You can’t reassign it, but the object it points to may still be mutable (val list = mutableListOf(1) lets you list.add(2)).
• const val - a compile-time constant. It’s inlined at the call site and must be a top-level or object/companion object member with a primitive or String value.

const val API_VERSION = "v1"        // compile-time, inlined
val createdAt = System.currentTimeMillis()  // runtime, just read-only
var counter = 0                      // mutable

Important distinction: val is about the reference being immutable, not deep immutability. const is resolved by the compiler, so it can’t hold anything computed at runtime.

Prefer val by default - it makes code easier to reason about and is required for things like smart casts on properties.

An extension function doesn’t actually modify the class. The compiler turns it into a static method that takes the receiver as its first argument. So this:

fun String.shout() = uppercase() + "!"
"hi".shout()

compiles to roughly StringExtKt.shout("hi").

The crucial consequence: extensions are dispatched statically, by the declared type, not the runtime type. There’s no virtual dispatch / polymorphism.

open class A
class B : A()
fun A.name() = "A"
fun B.name() = "B"

val x: A = B()
println(x.name())   // "A"  - uses the static type A, not B

Other things to know:

• A member function always wins over an extension with the same signature.
• Extensions can’t access private/protected members of the receiver - they’re just outside static functions.
• They’re great for keeping APIs focused and adding utilities to types you don’t own (Context, View, Flow), which is why Android codebases lean on them heavily.

Interview trap: the polymorphism question above. If you say it prints “B”, that’s the classic miss.

A higher-order function takes a function as a parameter and/or returns one. Functions are first-class values, with types like (Int) -> String or (T) -> Unit.

fun <T> List<T>.customFilter(predicate: (T) -> Boolean): List<T> {
    val result = mutableListOf<T>()
    for (item in this) if (predicate(item)) result.add(item)
    return result
}

val evens = listOf(1, 2, 3, 4).customFilter { it % 2 == 0 }

Worth knowing:

• Trailing lambda syntax - if the last parameter is a function, you can move the lambda outside the parentheses: customFilter { it > 0 }.
• it is the implicit name for a single-parameter lambda.
• Function references - pass an existing function with ::: list.filter(::isValid).
• A lambda is compiled to a Function object (allocation) unless the function is inline.

This is the backbone of the Kotlin stdlib (map, filter, forEach) and of idiomatic APIs like Compose and coroutine builders.

These are pre-built CoroutineScopes tied to Android lifecycles, so your coroutines are cancelled automatically.

• viewModelScope - an extension on ViewModel. Cancelled in onCleared(), i.e. when the ViewModel is destroyed for good (the screen is finished, not just rotated). Uses Dispatchers.Main.immediate + a SupervisorJob. This is where most app coroutines live, since the ViewModel survives configuration changes.
• lifecycleScope - an extension on a LifecycleOwner (Activity/Fragment). Cancelled when the lifecycle reaches DESTROYED. Use sparingly - for UI-only work that genuinely must follow the view, not the data.

class FeedViewModel : ViewModel() {
    fun refresh() = viewModelScope.launch {     // cancelled in onCleared()
        _state.value = repo.load()
    }
}

Why this matters: before these existed, you manually cancelled jobs in onDestroy/onCleared - easy to forget, causing leaks and callbacks firing on dead screens. Structured concurrency + lifecycle scopes make that automatic.

Gotchas:

• Don’t run data work in lifecycleScope - on rotation the Activity is destroyed and the work is cancelled and restarted. Put it in the ViewModel.
• GlobalScope is not lifecycle-aware - coroutines launched there outlive everything and leak. Avoid it.
• For collecting flows in the UI, pair lifecycleScope with repeatOnLifecycle(STARTED) so collection pauses in the background.

For the properties declared in the primary constructor, the compiler generates:

• equals() / hashCode() - structural equality based on those properties
• toString() - readable, e.g. User(id=1, name=Ada)
• componentN() - enables destructuring (val (id, name) = user)
• copy() - create a modified clone

data class User(val id: Int, val name: String)

val a = User(1, "Ada")
val b = a.copy(name = "Grace")   // User(id=1, name=Grace)
val (id, name) = b               // destructuring

Limitations / gotchas:

• Only primary-constructor properties count toward equals/hashCode/toString. A property declared in the body is ignored by them.
• A data class can’t be abstract, open, sealed, or inner.
• The primary constructor needs at least one parameter, and they must all be val/var.
• copy() does a shallow copy - nested mutable objects are shared.

data class Team(val members: MutableList<String>)
val first = Team(mutableListOf("Ada"))
val second = first.copy()
second.members += "Grace"
println(first.members) // [Ada, Grace]; both copies share the list

Common follow-up: “Two data classes with the same fields - are they equal?” No. equals also checks the runtime type, so different classes are never equal even with identical fields.

Kotlin has no static. A companion object is a single object tied to a class that lets you call members on the class name:

class User private constructor(val id: Int) {
    companion object {
        const val TABLE = "users"
        fun create(id: Int) = User(id)   // factory
    }
}

User.create(1)      // looks static
User.TABLE

But it’s not the same as static - it’s a real object instance (User.Companion). That means it can:

• implement interfaces and extend classes,
• be passed as a value,
• have extension functions.

Implications interviewers probe:

• Members are not truly static on the JVM unless you add @JvmStatic (useful for Java callers) - otherwise Java sees User.Companion.create(...).
• const val and @JvmField do compile to genuine static fields.
• There’s one companion object per class, and it’s initialized when the class is first loaded - so it’s a handy place for factories and constants, but heavy work there delays class loading.

Common follow-up: “How do you make a singleton?” Use a top-level object Foo { }, not a companion - the companion belongs to a class, a top-level object stands alone.

A suspend function is one that can pause without blocking the thread and resume later. The keyword is a contract: it can only be called from another suspend function or a coroutine.

Under the hood - Continuation Passing Style (CPS): the compiler rewrites a suspend function to take an extra hidden parameter, a Continuation (a callback for “what to do when I resume”). The function body is transformed into a state machine: each suspension point is a state, and local variables are saved on the continuation object.

suspend fun loadUser(): User {
    val token = auth()      // suspension point 1
    val user = api(token)   // suspension point 2
    return user
}

Conceptually compiles to something like a switch over a label:

• State 0: call auth(continuation), save label = 1, return COROUTINE_SUSPENDED.
• When auth completes, it invokes the continuation → re-enters at state 1, and so on.

Why this matters:

• Suspension frees the thread to do other work - that’s how thousands of coroutines run on a small pool. A blocked thread sits idle; a suspended coroutine doesn’t hold a thread.
• suspend alone doesn’t move work off the main thread - you still need withContext(Dispatchers.IO) for blocking work. suspend means “can suspend,” not “runs in the background.”
• There’s no magic threading; it’s compiler-generated callbacks that look like sequential code.

Both are coroutine builders, but they differ in what they return and how you use the result.

• launch starts a coroutine and returns a Job. Use it for work whose outcome is completion rather than a returned value. It is still owned by its scope. Callers should be able to cancel it or observe failure, so “fire and forget” is a misleading mental model.
• async returns a Deferred<T>, a Job that also carries a result. You call .await() to get the value. Use it for concurrent work you need to combine.

// Run two network calls concurrently, then combine.
suspend fun loadDashboard() = coroutineScope {
    val user = async { api.getUser() }
    val feed = async { api.getFeed() }
    Dashboard(user.await(), feed.await())
}

Interview trap: calling async { ... }.await() immediately, one after another, runs them sequentially - you’ve lost the concurrency. Start all the async blocks first, then await them.

Exception nuance: async stores its failure in the Deferred, so await() rethrows it. But if that async is a regular child, its failure also cancels its parent immediately. Waiting to call await() does not prevent structured-concurrency propagation. A root launch reports an uncaught failure immediately; a root async exposes it through await().

Choose based on how many values arrive and whether producing them may suspend.

API shape	Values	Can suspend between values?	Typical use
suspend fun load(): User	one result	yes	one network/database operation
fun observe(): Flow<User>	zero to many over time	yes	database updates, UI state, events
fun parse(): Sequence<Row>	many, pulled synchronously	no	lazy in-memory or blocking iteration

suspend fun user(id: Long): User = api.fetchUser(id) // one eventual answer

fun observeUser(id: Long): Flow<User> =
    dao.observeUser(id)                              // updates over time

A suspend function does not imply a background thread; it returns one result and may suspend while obtaining it. A cold Flow is also lazy, but collection can receive multiple values and is cancelled with the collecting coroutine. A Sequence is lazy but synchronous. Its iterator cannot call suspending APIs.

Interview trap: do not return Flow merely to wrap one network response. A suspend function is clearer unless the operation genuinely emits progress, retries as values, or later updates.

StateFlow and LiveData are both observable, lifecycle-friendly state holders, but StateFlow is the modern default in a coroutine-first codebase.

	LiveData	StateFlow
Always has a value	No; it may be unset	Yes (requires initial value)
Lifecycle-aware	Built in	Via repeatOnLifecycle / collectAsStateWithLifecycle
Operators	Few (map, switchMap)	Full Flow operator set
Threading	Main-thread bound	Any dispatcher
Pure Kotlin (testable, multiplatform)	No (Android dep)	Yes

Choose StateFlow when you want a single source of truth that’s always set, you need Flow operators (combine, debounce, flatMapLatest), or you’re in a shared/KMP module with no Android dependency. Collect it with lifecycle awareness (repeatOnLifecycle in Views or collectAsStateWithLifecycle in Compose).

private val _state = MutableStateFlow(UiState.Loading)
val state: StateFlow<UiState> = _state.asStateFlow()

The catch: StateFlow isn’t lifecycle-aware on its own. Collect it safely so you don’t waste work while the UI is in the background:

// Compose
val state by viewModel.state.collectAsStateWithLifecycle()

// Views
lifecycleScope.launch {
    repeatOnLifecycle(Lifecycle.State.STARTED) {
        viewModel.state.collect { render(it) }
    }
}

Reach for SharedFlow instead for one-off events (navigation, snackbars) where you don’t want a “current value” replayed on rotation.

Kotlin classes and members are final by default: they cannot be inherited or overridden unless you explicitly allow it. This nudges code toward composition and makes extension points deliberate.

open class Vehicle {
    open fun move() = "moving"
    fun stop() = "stopped" // final; cannot be overridden
}

class Bike : Vehicle() {
    override fun move() = "pedalling"
}

• open class: may be instantiated and subclassed. Only open members may be overridden.
• abstract class: cannot be instantiated; may hold constructor state, implemented methods, and abstract members. Abstract members are implicitly open.
• interface: defines a capability or contract. It can contain default method bodies and properties without backing fields, and a class may implement several interfaces.

Use an abstract class when related implementations need shared state or construction. Use interfaces for roles that unrelated types can implement. Prefer composition when you only want to reuse behavior because inheritance creates tighter coupling.

Common follow-up: an override member is open by default. Mark it final override when subclasses must not replace it again.

The Builder pattern constructs a complex object step by step, avoiding telescoping constructors (many overloads) and making optional parameters readable.

// Java: classic builder
Notification n = new NotificationCompat.Builder(context, channelId)
    .setContentTitle("Hi")
    .setContentText("Body")
    .setSmallIcon(R.drawable.ic)
    .setAutoCancel(true)
    .build();

Where it appears in Android: NotificationCompat.Builder, AlertDialog.Builder, Retrofit.Builder, OkHttpClient.Builder, Room.databaseBuilder, WorkRequest.Builder, Intent (chained putExtra). These predate Kotlin or come from Java APIs.

Is it still needed in Kotlin? Often not - Kotlin’s default and named arguments replace most builders:

data class RequestConfig(
    val url: String,
    val timeout: Long = 30_000,
    val retries: Int = 3,
    val headers: Map<String, String> = emptyMap(),
)
RequestConfig(url = "...", retries = 5)   // no builder needed

For more builder-like ergonomics, Kotlin uses:

• apply { } to configure an object fluently.
• Type-safe DSL builders - a lambda with receiver (buildString { }, Modifier chains, Gradle Kotlin DSL) - the idiomatic Kotlin “builder.”

When a builder still earns its place in Kotlin:

• Java interop - your API is consumed from Java (no default args there).
• Step-by-step validation or enforcing a build order / required-before-optional sequencing.
• Mirroring an established API style for familiarity.

A Facade provides a simple, unified interface over a complex subsystem, hiding its internal parts from callers.

// Facade over several subsystems
class MediaFacade(
    private val downloader: Downloader,
    private val decoder: Decoder,
    private val cache: MediaCache,
) {
    suspend fun play(url: String) {          // one simple call...
        val bytes = cache.get(url) ?: downloader.fetch(url).also { cache.put(url, it) }
        val media = decoder.decode(bytes)    // ...hides downloader + decoder + cache
        player.start(media)
    }
}

The caller uses play(url) and never touches the downloader, decoder, or cache directly.

Why use it:

• Simplifies usage - clients deal with one entry point instead of orchestrating many classes.
• Decouples clients from subsystem internals - you can restructure the subsystem without breaking callers.
• Reduces coupling and centralizes a workflow.

How it relates to the Repository: a Repository is essentially a Facade over data sources - it hides the network client, database, cache, and the coordination logic behind a clean API (observeUser()), so the ViewModel doesn’t know whether data came from Room or Retrofit. Many Android “manager”/“controller” classes are facades too.

Other Android examples: a SessionManager wrapping token storage + refresh + auth headers; an AnalyticsFacade over multiple analytics SDKs; Retrofit itself is a facade over OkHttp + converters + call adapters.

Caution: a facade can grow into a God object if it accumulates too many responsibilities - keep it focused on simplifying access, not doing everything.

The Observer pattern defines a one-to-many dependency: a subject maintains a list of observers and notifies them automatically when its state changes. It decouples the producer of data from its consumers.

// The essence: subscribe, get notified on change
interface Observer<T> { fun onChanged(value: T) }
class Subject<T>(initial: T) {
    private val observers = mutableListOf<Observer<T>>()
    var value: T = initial
        set(v) { field = v; observers.forEach { it.onChanged(v) } }
    fun observe(o: Observer<T>) { observers += o }
}

Where it’s everywhere in Android:

• LiveData - observe and get lifecycle-aware updates.
• Flow / StateFlow / SharedFlow - the coroutine-based reactive streams; collect is observing.
• Compose state - reading a State subscribes the composable; writes notify readers (recomposition).
• RecyclerView.AdapterDataObserver, click listeners, ViewTreeObserver, LifecycleObserver.
• RxJava Observable/Observer - the pattern in its named form.

Why it matters architecturally: it’s the backbone of reactive, UDF apps - the UI observes state from the ViewModel and updates automatically, instead of the ViewModel reaching into the UI. This inverts the dependency (UI depends on data, not vice versa).

Trade-offs to mention:

• Lifecycle leaks - observers not unregistered (or not lifecycle-aware) leak or update dead UI. LiveData/repeatOnLifecycle solve this.
• Notification storms / ordering - too many fine-grained updates can cause churn (hence distinctUntilChanged, conflation, derivedStateOf).

An Intent is a messaging object to request an action from a component (start an Activity/Service, deliver a broadcast).

Explicit intent - names the exact target component. Used within your app.

startActivity(Intent(this, DetailActivity::class.java).putExtra("id", 42))

Implicit intent - describes an action, and the system finds a component (often in another app) that can handle it via intent filters.

startActivity(Intent(Intent.ACTION_VIEW, Uri.parse("https://example.com")))
startActivity(Intent(Intent.ACTION_SEND).apply {
    type = "text/plain"; putExtra(Intent.EXTRA_TEXT, "Hi")
})

Intent filters (in the manifest) declare what implicit intents a component accepts, matched on action, category, and data (scheme/host/mimeType):

<activity android:name=".ShareActivity">
    <intent-filter>
        <action android:name="android.intent.action.SEND"/>
        <category android:name="android.intent.category.DEFAULT"/>
        <data android:mimeType="text/plain"/>
    </intent-filter>
</activity>

What to remember:

• Always verify an implicit intent resolves (resolveActivity / wrap in try-catch) or no app may handle it.
• Modern Android requires <queries> in the manifest (package visibility) to query/launch other apps’ intents on API 30+.
• Deep links / App Links are implicit ACTION_VIEW intents with a <data> URL filter; verified App Links open your app directly without a chooser.
• Extras pass data via putExtra/getXxxExtra; complex objects need Parcelable.

Default arguments let a parameter have a fallback, so callers can omit it. Named arguments let callers pass parameters by name in any order, which makes calls readable and lets you skip optional ones in the middle.

fun showSnackbar(
    message: String,
    duration: Int = LENGTH_SHORT,
    actionLabel: String? = null,
    onAction: (() -> Unit)? = null,
) { /* ... */ }

// Call only what you need, by name:
showSnackbar("Saved")
showSnackbar("Undo delete", actionLabel = "Undo", onAction = { restore() })

Together they replace most builder patterns and telescoping overloads in Kotlin - no Builder class, no five overloaded constructors. One function with defaults covers it.

Interop gotchas:

• Java callers don’t see Kotlin defaults. Add @JvmOverloads to generate overloads for them - essential when writing a custom View whose constructors Java/XML inflation calls.
• Named arguments don’t work when calling Java methods (the parameter names aren’t reliably in the bytecode).

Since Android 6 (Marshmallow), dangerous permissions (location, camera, contacts, microphone) must be requested at runtime, not just declared in the manifest. Normal permissions (internet, vibrate) are granted at install.

The flow with the modern Activity Result API:

val launcher = registerForActivityResult(RequestPermission()) { granted ->
    if (granted) startCamera() else showRationaleOrSettings()
}

when {
    checkSelfPermission(CAMERA) == PERMISSION_GRANTED -> startCamera()
    shouldShowRequestPermissionRationale(CAMERA) -> showRationale { launcher.launch(CAMERA) }
    else -> launcher.launch(CAMERA)
}

Key behaviors & best practices:

• Request in context, just-in-time - ask for the camera permission when the user taps “take photo,” not at app launch. Show rationale if the user previously denied.
• shouldShowRequestPermissionRationale returns true after one denial; if the user selects “Don’t ask again” (or denies twice on Android 11+), the system auto-denies and you must guide them to Settings.
• Location tiers - ACCESS_COARSE/FINE, and background location (ACCESS_BACKGROUND_LOCATION) must be requested separately and is heavily scrutinized.
• One-time & approximate location (Android 10/12+) - users can grant “only this time” or coarse-only; handle partial grants.
• New granular media permissions (Android 13+): READ_MEDIA_IMAGES/VIDEO/AUDIO replace READ_EXTERNAL_STORAGE; Android 14 adds partial photo access (selected photos).
• Don’t over-ask - Play flags apps that request sensitive permissions without justification; use scoped storage, the Photo Picker, and CameraX’s system UI to avoid needing some permissions at all.

vararg lets a function accept a variable number of arguments; inside the function the parameter is an Array.

fun sum(vararg numbers: Int): Int = numbers.sum()
sum(1, 2, 3)        // pass any count
sum()               // or none

To pass an existing array where a vararg is expected, use the spread operator *, which unpacks the array into individual arguments:

val arr = intArrayOf(1, 2, 3)
sum(*arr)                       // spread
sum(0, *arr, 4)                 // can mix with other args

Points to know:

• A function can have only one vararg parameter. If it’s not the last one, later parameters must be passed by name.
• For reference types it’s an Array<out T>; for primitives use the specialized arrays (IntArray) to avoid boxing.
• Spread copies the array’s references into the call, so it’s a shallow pass.

Real use: listOf(vararg elements: T), arrayOf(...), and forwarding args: fun log(vararg args: Any) = print(format(*args)).

@Preview renders a composable in Android Studio without running the app or a device - fast iteration on UI.

@Preview(showBackground = true)
@Preview(name = "Dark", uiMode = Configuration.UI_MODE_NIGHT_YES)
@Preview(name = "Large font", fontScale = 1.5f)
@Composable
private fun ProfileCardPreview() {
    AppTheme {
        ProfileCard(user = User("Ada", "ada@x.com"))
    }
}

Useful features:

• Multiple previews on one function (light/dark, font scales, locales, device sizes) - or a @PreviewParameter provider to render several data states (loading/empty/error/loaded) at once.
• Custom annotation classes (@PreviewLightDark, or your own multi-preview annotation) to apply a standard set everywhere.
• Interactive Preview and Live Edit for clicking through and editing without rebuilds.

What makes a composable preview-friendly (the real point):

• It must be stateless / driven by parameters - a composable that fetches data from a ViewModel or reads a real repository can’t preview cleanly. Hoist state and pass plain data.
• Wrap previews in your theme so colors/typography render correctly.
• Pass fake/sample data rather than real dependencies.

This is a strong argument for the stateless composable + state hoisting pattern: previewability falls out of it for free. A screen split into a stateful “screen” (wires the ViewModel) and a stateless “content” (pure params) lets you preview the content in every state.

Bonus: previews double as screenshot tests (Paparazzi/Roborazzi) to catch visual regressions in CI without a device.

Android picks the best-matching resource for the current device configuration at runtime, using qualified resource directories. You provide alternatives; the system selects.

res/
├── values/strings.xml            # default
├── values-es/strings.xml         # Spanish
├── values-night/colors.xml       # dark mode
├── drawable-hdpi/ic.png          # density buckets
├── drawable-xxhdpi/ic.png
├── layout/activity_main.xml      # default layout
├── layout-sw600dp/activity_main.xml   # tablets (smallest width ≥ 600dp)
└── mipmap-xxhdpi/ic_launcher.png # launcher icons

Common qualifiers (in precedence order): locale (-es, -fr), layout direction (-ldrtl), smallest width (-sw600dp), screen width/orientation (-w820dp, -land), night mode (-night), density (-hdpi/-xxhdpi), and API level (-v29).

Why it matters:

• Localization - translate by adding values-<lang> folders; never hardcode strings (use @string/... and getString()).
• Dark mode - values-night / -night resources are auto-selected; no code branching.
• Density independence - provide density buckets (or a single vector drawable that scales) so images look crisp on all screens; use dp for layout and sp for text.
• Responsive layouts - -sw600dp/-w600dp for tablets and foldables.
• API-specific - -v29 for resources only valid on newer APIs.

What to remember:

• The system falls back to the default (values/) when no qualified match exists.
• Use vector drawables to avoid shipping many density PNGs.
• Access in code via R.string.x, R.drawable.y; the qualifier resolution is automatic.
• A configuration change (rotation, locale, dark mode) re-resolves resources - which is why the Activity recreates.

The headline difference: Kotlin has no checked exceptions. Every exception is unchecked, so you’re never forced to try/catch or declare throws. This removes Java’s boilerplate but means the compiler won’t remind you an API can fail - you have to know.

// No "throws IOException" needed; caller isn't forced to handle it
fun readConfig(): String = File("config").readText()

Other points:

• try is an expression - it returns a value:

  val n = try { input.toInt() } catch (e: NumberFormatException) { 0 }

• @Throws - annotate a function so Java callers see the checked exception (needed for interop, e.g. a function Java code must catch).
• runCatching wraps a block in a Result<T>, turning exceptions into values for functional handling:

  val result = runCatching { api.fetch() }
      .map { it.body }
      .getOrElse { fallback }

• Nothing is the type of throw, which is why it slots into any expression (val x = a ?: throw ...).

Caution interviewers like to hear: don’t catch broad Exception around coroutine code - it can swallow CancellationException and break structured cancellation. Rethrow it, or catch specific types.

MaterialTheme provides three systems down the tree via CompositionLocals: colors, typography, and shapes.

@Composable
fun AppTheme(darkTheme: Boolean = isSystemInDarkTheme(), content: @Composable () -> Unit) {
    val colors = when {
        // Material 3 dynamic color (Android 12+): derive from the wallpaper
        dynamicColorAvailable() && darkTheme -> dynamicDarkColorScheme(LocalContext.current)
        dynamicColorAvailable() -> dynamicLightColorScheme(LocalContext.current)
        darkTheme -> DarkColors
        else -> LightColors
    }
    MaterialTheme(colorScheme = colors, typography = AppTypography, content = content)
}

Reading the theme anywhere inside:

Text("Hi", color = MaterialTheme.colorScheme.primary,
     style = MaterialTheme.typography.titleMedium)

Key points:

• Single source of truth - define colors/type/shapes once; components read from MaterialTheme.*. Don’t hardcode colors in composables.
• Dark mode is just a different ColorScheme. isSystemInDarkTheme() follows the system; toggling is swapping the scheme - the whole tree recomposes with new colors.
• Dynamic color (Material You) derives a scheme from the user’s wallpaper on Android 12+. Provide static fallbacks for older versions.
• Custom design systems - wrap or replace MaterialTheme with your own CompositionLocalProviders (custom spacing, brand colors) and expose them via a Theme object.
• Theme values flow through staticCompositionLocalOf, so reads are cheap but changing the theme recomposes the provided subtree.

Use the androidx.core:core-splashscreen library / the SplashScreen API (standardized in Android 12), not a dedicated splash Activity.

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        val splash = installSplashScreen()    // BEFORE super.onCreate / setContentView
        super.onCreate(savedInstanceState)

        // Keep the splash visible until data is ready
        splash.setKeepOnScreenCondition { viewModel.isLoading.value }
    }
}

Configure the icon/background via a theme:

<style name="Theme.App.Starting" parent="Theme.SplashScreen">
    <item name="windowSplashScreenBackground">@color/brand</item>
    <item name="windowSplashScreenAnimatedIcon">@drawable/logo</item>
    <item name="postSplashScreenTheme">@style/Theme.App</item>
</style>

Why not a splash Activity (the old anti-pattern):

• It adds an extra Activity and transition → slower startup, the opposite of the goal.
• A fake fixed-duration splash (postDelayed) wastes the user’s time.
• The system already shows a launch window; a separate Activity just delays content.

Best practices:

• The splash should cover actual startup work, not an artificial timer. Use setKeepOnScreenCondition to hold it only while genuinely loading critical data.
• Keep it brief - if startup is slow, fix startup (lazy init, Baseline Profiles), don’t pad it with a splash.
• Provide an animated icon + brand background through the theme; it integrates with the system launch animation seamlessly.
• On pre-12 devices the library backports the same behavior.

Column composes and lays out all its children immediately, whether or not they’re on screen - fine for a handful of items, disastrous for a long/unbounded list. LazyColumn only composes the items currently visible (plus a small buffer) and recycles them as you scroll - the Compose equivalent of RecyclerView.

LazyColumn {
    items(users, key = { it.id }) { user ->
        UserRow(user)
    }
}

Why key = { it.id } matters:

• By default, Lazy lists identify items by their position/index. If the list reorders, inserts, or removes items, Compose can mismatch state to the wrong item.
• A stable key ties each item’s identity (and its remembered state, animations, scroll position) to the data, not the index. So when items move, Compose moves the existing composition instead of recomposing everything.
• Without keys, deleting the first item makes every item below shift index, causing unnecessary recomposition and losing per-item state (e.g. an expanded row collapses, a half-typed field clears).

Other LazyColumn tools:

• contentType - hint the type of each item so Compose reuses compositions of the same type more efficiently in heterogeneous lists.
• rememberLazyListState() - observe/control scroll (with derivedStateOf for things like “show scroll-to-top”).
• Don’t nest a vertically-scrolling LazyColumn inside a vertically-scrolling parent without a bounded height - it can crash or measure infinitely.

Both cache a value across recompositions, but they survive different events.

• remember keeps a value across recompositions. It’s lost on configuration change (rotation) or process death, because the composition is recreated.
• rememberSaveable also persists across configuration changes and process death by writing into the saved-instance-state Bundle.

// Survives recomposition only
var query by remember { mutableStateOf("") }

// Also survives rotation / process death
var query by rememberSaveable { mutableStateOf("") }

Use rememberSaveable for UI state the user would be annoyed to lose - text fields, scroll position, expanded/collapsed flags. Use remember for things that are cheap to recreate or derived from other state.

Gotcha: rememberSaveable can only store types that go in a Bundle (primitives, Parcelable, etc.). For a custom type, provide a Saver.

The Elvis operator ?: returns its left side if non-null, otherwise the right side. Its power comes from the right side being able to be any expression - including return and throw (both have type Nothing).

// 1. Default value
val name = user?.name ?: "Guest"

// 2. Early return - "guard clause"
fun process(input: String?) {
    val text = input ?: return            // bail out if null
    println(text.length)                  // text is non-null here
}

// 3. Fail fast with a meaningful message
val config = loadConfig() ?: throw IllegalStateException("config missing")

// 4. Chained fallbacks
val displayName = nickname ?: fullName ?: email ?: "Anonymous"

// 5. Default for a whole expression
val count = map[key]?.size ?: 0

Why interviewers like #2 and #3: after val x = nullable ?: return, the compiler smart-casts x to non-null for the rest of the function - cleaner than nesting everything inside ?.let { } or an if (x != null) block.

Three ways to reference views in the View system, increasingly capable:

findViewById - the original: look up a view by id at runtime.

• Problems: not null-safe (returns a view that might be wrong/absent → crash), not type-safe (casts), and verbose.

View Binding - generates a binding class per layout with typed, non-null references to all id’d views.

val binding = ActivityMainBinding.inflate(layoutInflater)
setContentView(binding.root)
binding.titleText.text = "Hi"     // typed, non-null, no findViewById

• Benefits: null-safe and type-safe, near-zero overhead, minimal setup. The recommended replacement for findViewById.

Data Binding - a superset that also supports binding expressions in XML, linking layouts directly to data/observables.

<TextView android:text="@{viewModel.title}" />
<Button android:onClick="@{() -> viewModel.submit()}" />

• Benefits: two-way binding, observable data in layouts, binding adapters.
• Costs: slower builds (annotation processing), logic-in-XML can be hard to debug, and steeper complexity. Largely superseded by Compose for new code; many teams prefer View Binding + observing state in code over Data Binding.

How to choose:

• New View-based code → View Binding (simple, safe, fast).
• Legacy projects already using Data Binding → keep it, but it’s not recommended for new adoption.
• New UI → Compose sidesteps all three.

Note: View Binding ≠ Data Binding - View Binding only generates references (no XML expressions), which is exactly why it’s faster and simpler.

Think of the Activity lifecycle as three questions: Does the Activity exist? Is it visible? Can the user interact with it? The main callbacks are:

• onCreate - create this Activity instance and set up its UI.
• onStart - activity becomes visible.
• onResume - activity is in the foreground and interactive.
• onPause - losing focus (a dialog, another activity in front). Keep this fast.
• onStop - no longer visible.
• onDestroy - being torn down (finished or recreated).

On rotation, Android normally destroys the current Activity instance and creates a new one. You will usually see a sequence like this:

onPause → onStop → onDestroy
→ onCreate → onStart → onResume

The exact timing of state-saving callbacks can vary, so do not write logic that depends on one precise callback order. The important point is that Activity fields belong to the old instance and are lost.

• ViewModel keeps screen data across configuration changes.
• onSaveInstanceState, SavedStateHandle, or rememberSaveable keep small pieces of restorable UI state, such as a selected tab or search query.

Common follow-up: Process death also removes the ViewModel because the whole app process is gone. Restore the minimum state needed to rebuild the screen and load durable data again from a database or network source.

Two measures of code quality that good architecture optimizes in opposite directions: low coupling, high cohesion.

Coupling - how much one module depends on another. Low (loose) coupling is the goal: modules interact through small, stable interfaces, so a change in one doesn’t ripple into many others.

• Tightly coupled: a ViewModel directly instantiating RetrofitClient and RoomDatabase - changing either breaks the ViewModel.
• Loosely coupled: the ViewModel depends on a Repository interface, injected. Swap the implementation freely.

Cohesion - how focused a module is; how strongly its parts relate to a single purpose. High cohesion is the goal: a class does one well-defined job.

• Low cohesion: a Utils class with networking, date formatting, and bitmap helpers thrown together.
• High cohesion: a DateFormatter that only formats dates; a FeedRepository that only handles feed data.

Why they matter:

• Maintainability - loosely coupled, highly cohesive code is easier to change: edits stay local, and each class is easy to understand.
• Testability - low coupling lets you inject fakes; high cohesion means small, focused units to test.
• Reusability - focused modules are reusable; tangled ones aren’t.

How Android practices achieve them:

• DI + interfaces → low coupling (depend on abstractions).
• Single Responsibility / layering → high cohesion (each class/layer one job).
• Modularization → enforces boundaries (low coupling between features).
• UDF → the UI depends on state, not on the ViewModel’s internals.

These two are the why behind SOLID, Clean Architecture, and DI - interviewers like seeing you connect the principle to the practice.

Four modifiers, with public as the default:

• public (default) - visible everywhere.
• private - visible only within the file (top-level) or the enclosing class.
• protected - visible in the class and its subclasses (not top-level).
• internal - visible everywhere in the same module.

The interesting one is internal, which Java doesn’t have. A module is a set of files compiled together - a Gradle module/source set, a Maven project, an IntelliJ module. internal is the backbone of modularization: a library module can expose a small public API while keeping implementation classes internal so other modules physically can’t depend on them.

internal class HttpClientImpl   // usable across this module, invisible outside it
class FeatureApi {
    private val client = HttpClientImpl()
}

Notes:

• Kotlin has no package-private; internal (module) is the nearest equivalent and is broader than Java’s package scope.
• internal names are mangled in the bytecode, which is why Java callers shouldn’t rely on them.
• There’s no default “open” - classes/members are final unless marked open.

A Flow is cold - the chain of intermediate operators (map, filter, onEach…) just describes work. Nothing runs until a terminal operator starts collection. Terminal operators are suspend functions (they need a coroutine).

val pipeline = flow { emit(1); emit(2) }.map { it * 10 }
// Nothing has run yet - pipeline is just a recipe.

pipeline.collect { println(it) }   // NOW it runs: 10, 20

Common terminal operators:

• collect { } - the fundamental one; process every value.
• toList() / toSet() - gather into a collection.
• first() / firstOrNull() - take the first value (and cancel upstream).
• single() - expect exactly one value.
• reduce / fold - accumulate to a single result.
• count() - count emissions.
• launchIn(scope) - collect in a given scope without a lambda (usually after onEach).

flow.onEach { render(it) }.launchIn(viewModelScope)   // fire-and-collect

Why this matters: the classic bug is building a flow with onEach/map and wondering why the side effects never fire - there’s no terminal operator, so collection never starts. “Cold flows do nothing until collected” is the point being tested.

Context is the handle to app/system resources and services. The main flavors:

• Application context - tied to the app’s lifetime. Get it via applicationContext / getApplication(). Use for things that must outlive any single screen: singletons, databases, WorkManager, DataStore, app-wide managers.
• Activity context - tied to one Activity’s lifetime. Carries theme/config. Use for UI work: inflating layouts, starting activities, showing dialogs, theming.
• Service / BroadcastReceiver context - scoped to those components.

The golden rule - match the context’s lifetime to the object that holds it:

// ✅ singleton holds app context - same lifetime, no leak
class Analytics(context: Context) {
    private val appContext = context.applicationContext
}

// ❌ singleton (or static/ViewModel) holding an Activity context → leaks the Activity
object Cache { lateinit var ctx: Context }   // if assigned an Activity, it leaks

Why it matters: holding an Activity context in something longer-lived (a static field, singleton, ViewModel, or a long-running thread) prevents the Activity from being garbage-collected after it’s destroyed - a classic memory leak.

Things that need a specific context:

• Dialogs / theming / inflation → need an Activity (or themed) context; the app context lacks the right theme and can crash/misrender.
• Toasts, system services, resources → app context is fine.

The common Flow builders:

// 1. flow { } - the general builder; call emit() inside
val f1 = flow {
    emit(1)
    delay(100)
    emit(2)
}

// 2. flowOf(...) - fixed set of values
val f2 = flowOf("a", "b", "c")

// 3. asFlow() - from a collection, range, or sequence
val f3 = (1..5).asFlow()
val f4 = listOf("x", "y").asFlow()

// 4. channelFlow { } / callbackFlow { } - emit from other contexts/callbacks
val f5 = callbackFlow {
    val l = listener { trySend(it) }
    register(l); awaitClose { unregister(l) }
}

// 5. MutableStateFlow / MutableSharedFlow - hot flows you push into
val state = MutableStateFlow(0)

How to pick:

• flow { } - most cases; sequential emission, context-preserving (use flowOn to switch dispatchers).
• flowOf / asFlow - wrap existing values/collections.
• channelFlow / callbackFlow - when you must emit from a callback or multiple coroutines/threads (a plain flow { } forbids cross-context emission).
• StateFlow / SharedFlow - hot, shared, observable app state/events.

Note: flow { }, flowOf, and asFlow are cold - the block runs per collector, only when collected. StateFlow/SharedFlow are hot.

when is far more capable than Java’s switch. As an expression it returns a value, and it can branch on conditions, not just constants.

// As an expression with ranges, types, and multiple values
val label = when (score) {
    in 90..100 -> "A"
    in 70..89  -> "B"
    50, 51, 52 -> "borderline"
    else       -> "F"
}

// Type checks with smart cast
when (x) {
    is String -> x.length
    is List<*> -> x.size
    else -> 0
}

// No subject: acts like an if/else-if chain
when {
    user == null   -> showLogin()
    user.isAdmin   -> showAdmin()
    else           -> showHome()
}

Key abilities to mention:

• Exhaustiveness - when used as an expression on a sealed type or enum, the compiler requires all cases (no else needed), and errors if you miss one later.
• Smart casts inside is branches.
• Ranges and collections with in.
• Capturing the subject: when (val r = compute()) { ... }.

Interview note: prefer when as an expression returning a value over mutating a variable in branches - it’s more idiomatic and the exhaustiveness check protects you.

val a = StringBuilder("x").apply { append("y") }
val b = StringBuilder("x").let { it.append("y") }
val c = StringBuilder("x").let { it.append("y"); "done" }

println(a)
println(b)
println(c)

Output:

xy
xy
done

Why:

• apply returns the receiver object (the StringBuilder). So a is the builder → "xy".
• let returns the lambda result. For b, the last expression is it.append("y"), and StringBuilder.append returns the same StringBuilder - so b is also the builder → "xy".
• For c, the lambda’s last expression is the string "done", so let returns "done".

The takeaway: apply/also always give you the object back; let/run/with give you whatever the block’s last line evaluates to. Here b only prints "xy" because append happens to return the builder - change the last line and let returns that instead.

runBlocking is a bridge from regular blocking code into the coroutine world. It starts a coroutine and blocks the current thread until that coroutine and all its children complete.

fun main() = runBlocking {   // blocks main until done
    val data = repository.load()
    println(data)
}

Where it’s appropriate:

• main() functions and simple scripts.
• Tests - though runTest is now preferred for coroutine tests (it skips delays and controls virtual time).
• Bridging a suspend function into a legacy blocking API you must implement.

Where it’s dangerous:

• Never on the main/UI thread in an app - it blocks the thread, defeating the entire point of coroutines and risking ANRs. This is the #1 misuse interviewers watch for.
• Inside another coroutine - you’d block a pool thread instead of suspending. Use withContext/coroutineScope instead.

Contrast with coroutineScope: both wait for children, but coroutineScope suspends (releases the thread) while runBlocking blocks (holds the thread). Inside coroutine code you want coroutineScope; only use runBlocking to enter coroutine code from a non-suspending context.

A ViewModel holds and manages UI-related state and survives configuration changes, so data and in-flight work aren’t lost on rotation.

How it survives: the ViewModel is stored in a ViewModelStore owned by the Activity/Fragment/NavBackStackEntry. On a configuration change, the Activity is recreated but its ViewModelStore is retained (via onRetainNonConfigurationInstance internally) and handed to the new instance. So you get the same ViewModel back. It’s cleared (onCleared()) only when the owner is permanently gone (finished, popped) - not on rotation.

class FeedViewModel(private val repo: FeedRepository) : ViewModel() {
    private val _state = MutableStateFlow(FeedUiState())
    val state = _state.asStateFlow()
    // viewModelScope cancelled in onCleared()
}

What a ViewModel must NOT hold:

• Context of an Activity, Views, Fragments, or anything view-bound - these outlive a config change while the ViewModel persists, so holding them leaks the old Activity. If you need a context, use AndroidViewModel’s application context.
• It shouldn’t reach into the UI; it exposes state the UI observes (one-way).

Key points:

• It does not survive process death - pair with SavedStateHandle for state that must.
• viewModelScope ties coroutines to the ViewModel lifecycle (cancelled in onCleared).
• Scope it correctly: viewModels() (Activity/Fragment), activityViewModels() (share across fragments), or hiltViewModel() (per nav destination).
• Construct it with a factory (or Hilt) to inject dependencies.

Declarative means you describe what the UI should look like for a given state, and the framework figures out how to update the screen. You don’t hold view references and mutate them; you re-describe the UI when state changes.

// Declarative (Compose): describe UI as a function of state
@Composable
fun Counter(count: Int, onIncrement: () -> Unit) {
    Button(onClick = onIncrement) { Text("Count: $count") }
}

vs the imperative View system, where you fetch a widget and mutate it:

button.text = "Count: $count"   // you manually keep the view in sync

Key differences:

• No XML / no findViewById - UI is Kotlin functions.
• State-driven - when state changes, Compose recomposes (re-invokes the affected composables) instead of you manually updating views.
• No view hierarchy inflation - composables don’t map 1:1 to View objects; Compose maintains its own tree and renders directly.
• Single source of truth - the UI can’t drift out of sync with state because it’s derived from state.

A useful mental model: UI = f(state). Instead of imperatively poking widgets when data changes, you make the UI a pure function of state and let recomposition handle updates.

Dependency injection (DI) means a class receives its dependencies from outside rather than creating them itself. “Inversion of control” - something else (a framework or the caller) is responsible for constructing and wiring objects.

// ❌ Without DI: class creates and is coupled to concrete dependencies
class UserViewModel {
    private val repo = UserRepository(RetrofitClient.create(), AppDatabase.dao())
}

// ✅ With DI: dependencies injected; class depends on abstractions
class UserViewModel(private val repo: UserRepository)

Why it matters:

• Testability - inject a fake/mock repository in tests instead of hitting the real network/DB. This is the #1 reason.
• Decoupling - a class depends on an interface, not a concrete implementation; swap implementations (debug vs prod, different backends) without changing the class.
• Single responsibility - classes focus on using dependencies, not constructing them (and their dependencies, and their dependencies…).
• Lifecycle & scoping - a DI framework can provide singletons, per-Activity, or per-ViewModel instances correctly.

On Android specifically:

• Manual DI works but becomes painful as the graph grows (constructing a ViewModel might require a repo, which needs an API, a DB, an OkHttp client, …).
• Hilt (built on Dagger) generates this wiring at compile time - type-safe, no reflection - and integrates with Android components (Activity, ViewModel, WorkManager).
• Koin is a lighter, runtime service locator-style alternative (simpler, but resolution errors surface at runtime).

Forms of DI: constructor injection (preferred - explicit, testable), field injection (for framework-created objects like Activities), and method injection.

State hoisting is moving state up out of a composable to its caller, so the composable becomes stateless - it receives the value and a callback to change it, rather than owning the state.

The pattern is value down, events up:

// Stateless: owns no state, fully driven by parameters
@Composable
fun SearchBar(query: String, onQueryChange: (String) -> Unit) {
    TextField(value = query, onValueChange = onQueryChange)
}

// Stateful caller owns the state
@Composable
fun SearchScreen(viewModel: SearchViewModel) {
    val query by viewModel.query.collectAsStateWithLifecycle()
    SearchBar(query = query, onQueryChange = viewModel::onQueryChange)
}

Why hoist:

• Reusable - a stateless composable works anywhere; the caller decides where state lives.
• Testable - you can render it with any value, no internal state to set up.
• Single source of truth - state lives in one place (ViewModel or a parent), avoiding divergent copies.
• Controllable - the parent can intercept, transform, or share the state.

Stateful vs stateless:

• Stateful composables hold their own remember { mutableStateOf(...) } - convenient for self-contained widgets where the caller doesn’t care about the state.
• Stateless ones take state as parameters - preferred for anything shared, tested, or driven by a ViewModel.

A common design is to offer both: a stateful overload (with a default rememberX state) that delegates to a stateless one - exactly how Compose’s own Scaffold/rememberScaffoldState are structured.

The Application object is a singleton created before any Activity/Service, living for the whole process lifetime. It’s the global entry point and the holder of application-wide state.

class MyApp : Application() {
    override fun onCreate() {
        super.onCreate()
        // app-wide, must-happen-early init
    }
}

Register it in the manifest (<application android:name=".MyApp">).

Legitimate uses:

• Critical, early initialization - crash reporting, DI graph (Hilt generates Application integration), logging.
• A safe source of application context for app-lifetime objects.
• ProcessLifecycleOwner / registerActivityLifecycleCallbacks for app-wide foreground/background awareness.

What NOT to do (the important part - onCreate runs on every cold start and blocks the first frame):

• No heavy/synchronous work - network, disk, big SDK init on the main thread here directly slows cold start and risks ANR. Lazy-init non-critical SDKs (or use the App Startup library) instead.
• Don’t store mutable global state as a substitute for proper architecture - it’s not a dumping ground for “global variables.”
• Don’t assume it survives process death with in-memory state - the process can be recreated; persist what must survive.

What to remember:

• It’s a singleton tied to the process - and there can be multiple processes (android:process), each with its own Application instance.
• Keep onCreate lean; defer everything you can - startup time is a real metric (Android vitals).
• Prefer Hilt/DI and the App Startup library over manual init soup.

Local tests run on the JVM on your development machine. They are fast and work well for business logic, mappers, reducers, and ViewModels whose Android dependencies have been kept behind interfaces.

Instrumented tests run on an Android device or emulator. Use them when the behavior depends on the framework, such as navigation, permissions, resources, Room integration, or a complete UI flow. They provide more realism but are slower and need more setup.

Robolectric sits between the two: it runs Android-like behavior on the JVM. It can be useful, but it is not a replacement for every device test.

A good default is to keep most tests local, add integration tests at important boundaries, and reserve device tests for behavior that genuinely requires Android.

A Repository mediates between the rest of the app and the data sources (network, database, cache, DataStore). It exposes a clean, domain-oriented API and hides where the data comes from.

class UserRepository(
    private val api: UserApi,
    private val dao: UserDao,
) {
    // The caller doesn't know or care this comes from cache + network
    fun observeUser(id: String): Flow<User> = dao.observe(id)
        .onStart { refreshFromNetwork(id) }

    private suspend fun refreshFromNetwork(id: String) {
        runCatching { api.fetch(id) }.onSuccess { dao.upsert(it.toEntity()) }
    }
}

What it solves:

• Single source of truth - the repository decides the caching/refresh policy (e.g. DB as source of truth, network refreshes it). Callers just observe.
• Abstraction - ViewModels depend on the repository, not on Retrofit or Room. Swapping the network library or adding a cache doesn’t ripple into the UI.
• Testability - fake the repository (or its data sources) in ViewModel tests.
• Centralized logic - retry, mapping DTO→domain, combining sources, and offline behavior live in one place, not scattered across ViewModels.

Design choices:

• Repositories typically expose domain models, mapping from DTOs (network) and entities (DB) at the boundary.
• Define the repository as an interface in the domain layer; implement it in the data layer (dependency inversion) so the domain doesn’t depend on data details.
• One repository per data type/feature (UserRepository, FeedRepository), not one giant “DataRepository.”
• Keep business logic out of the repository - it does data orchestration; complex rules belong in use cases.

The test pyramid guides where to invest: many fast tests at the bottom, few slow ones at the top.

        /\        UI / E2E tests  (few - slow, brittle, on-device)
       /  \       Espresso / Compose UI tests, full flows
      /----\      Integration tests (some)
     /      \     Room DAO, repository + fakes, navigation
    /--------\    Unit tests (many - fast, JVM)
   /__________\   ViewModels, use cases, mappers, pure logic

Unit tests (the base, most of your tests):

• Run on the JVM (no device) → fast, run on every change.
• Target pure logic: ViewModels, use cases, mappers, formatters, repositories (with fake data sources).
• Use runTest for coroutines, inject dispatchers, Turbine for flows.

Integration tests (middle):

• Verify components together: Room DAOs against an in-memory DB, a repository with real DB + fake network, navigation graphs.
• Some run on JVM (Robolectric) or instrumented.

UI / End-to-end (top, few):

• Espresso (Views) / Compose UI tests / UI Automator drive real screens and flows.
• Slow and flakier, so cover critical user journeys (login, checkout), not every screen.

What makes the app testable (the real point):

• Architecture enables testing - DI + interfaces let you inject fakes; UDF makes ViewModels pure functions of input you can assert on; separating layers keeps logic Android-free.
• Inject dispatchers and clocks so time/threading is controllable.
• Prefer fakes over heavy mocking, and test behavior, not implementation.

Other tools: screenshot tests (Paparazzi/Roborazzi) for visual regression, Macrobenchmark for performance, and Play Pre-launch reports for device coverage.

• APK - the installable package that lands on a device. It contains all code and resources for every density, ABI, and language.
• AAB (Android App Bundle) - a publishing format (.aab) you upload to Play. It’s not installed directly; Play uses it to generate and serve optimized APKs per device via Play Feature/Dynamic Delivery.

The win - smaller downloads. With an AAB, Play’s split APKs ship only what a given device needs:

• Density splits - only that device’s drawable density.
• ABI splits - only that device’s CPU architecture (arm64 vs x86).
• Language splits - only the user’s languages.

So a user doesn’t download xxhdpi assets, French strings, and x86 libraries they’ll never use. AAB is required for new apps on Google Play (since Aug 2021).

Related capabilities AAB enables:

• Dynamic feature modules - download features on demand (Play Feature Delivery), shrinking the base install.
• Play Asset Delivery - stream large game assets.
• Play App Signing - Google holds the signing key and re-signs the generated APKs (a consequence to understand: you upload with an upload key, Play signs with the app key).

What to remember:

• AAB ≠ APK: AAB is for upload/distribution; APK is for install.
• You can still build a universal APK from a bundle (bundletool) for sideloading/testing.
• It reduces app size without code changes - the splits are automatic.

The *Latest variants cancel the in-progress work when a new value arrives.

collect processes every emission to completion, sequentially. If processing is slow, emissions queue up.

collectLatest starts processing each value, but if a new value arrives before the current block finishes, it cancels the current block and restarts with the new value.

flow {
    emit("A"); delay(10); emit("B")
}.collectLatest { value ->
    println("start $value")
    delay(100)                 // slow work
    println("done $value")     // only reached for the LAST value
}
// Output: start A, start B, done B   (A's work was cancelled by B)

flatMapLatest / mapLatest apply the same idea to transformations - cancel the previous inner flow/computation when upstream emits again. This is the common search-as-you-type pattern:

queryFlow
    .debounce(300)
    .distinctUntilChanged()
    .flatMapLatest { q -> repo.search(q) }   // cancels the stale search
    .collect { render(it) }

When to use which:

• Only the latest value matters (UI state, search results) → collectLatest / flatMapLatest.
• Every value must be processed (analytics events, a write queue) → plain collect (with buffer if needed).

Gotcha: with collectLatest, cancellation means the slow block’s later lines may never run - don’t rely on it for must-complete side effects.

Start with a practical rule: if a generic type only produces values, mark it out. If it only consumes values, mark it in.

These rules are called variance. Without in or out, a generic type is invariant: Box<String> cannot be used as Box<Any>, even though String is a subtype of Any.

out means producer. The type is returned, not accepted as input. This is why Kotlin’s read-only List is List<out T>.

interface Producer<out T> { fun produce(): T }
val p: Producer<Any> = object : Producer<String> { ... }  // OK

Kotlin’s read-only List<out E> is covariant - that’s why List<String> is usable as List<Any>.

in means consumer. The type is accepted as input, not returned. A Comparator<Any> can compare strings, so it can be used where a Comparator<String> is required.

interface Consumer<in T> { fun consume(item: T) }
val c: Consumer<String> = object : Consumer<Any> { ... }  // OK

Mnemonic: PECS / “in–consumer, out–producer.”

Star projection <*> - used when you don’t know or care about the argument: a Box<*> is a Box of some type. You can read values as the upper bound (Any?) but can’t safely write (except null), because the real type is unknown.

fun printAll(box: Box<*>) { println(box.get()) }  // get is fine, set isn't

in/out at the declaration site is declaration-site variance; specifying it at a usage point (Array<out T>) is use-site variance (Kotlin’s equivalent of Java wildcards).

Structured concurrency means every coroutine runs inside a scope, and a scope doesn’t finish until all the coroutines it launched have finished. Coroutines form a parent–child tree.

This gives you three guarantees:

1. No leaks. A coroutine can’t outlive its scope. When the scope is cancelled, all children are cancelled.
2. Cancellation propagates. Cancelling a parent cancels its children; a failing child (by default) cancels its siblings and parent.
3. Errors aren’t lost. Exceptions surface to the scope rather than vanishing on some detached thread.

Why it matters on Android: viewModelScope is cancelled in onCleared(), and lifecycleScope follows the lifecycle. Tie your coroutines to these and work is automatically cancelled when the user leaves - no manual teardown, no callbacks firing on a dead screen.

class FeedViewModel : ViewModel() {
    fun refresh() = viewModelScope.launch {
        val items = repo.loadFeed()   // cancelled automatically if the
        _state.value = State.Loaded(items) // ViewModel is cleared mid-flight
    }
}

Follow-up to be ready for: use supervisorScope (or a SupervisorJob) when you don’t want one child’s failure to cancel its siblings - e.g. loading several independent widgets where one failing shouldn’t blank the rest.

The behavior depends on the builder.

launch - an uncaught exception propagates immediately up the Job hierarchy. A root launch reports it to a CoroutineExceptionHandler (or the thread’s uncaught-exception handler). A child delegates handling to its parent.

async - stores the exception and rethrows it from await(). A CoroutineExceptionHandler does not consume a root async failure because the caller is expected to observe the Deferred.

val handler = CoroutineExceptionHandler { _, e -> Log.e("TAG", "caught $e") }

// Root launch → handler reports it
scope.launch(handler) { throw IOException() }

// async → must catch at await()
val deferred = scope.async { throw IOException() }
try { deferred.await() } catch (e: IOException) { /* handle */ }

The interview-grade nuance: in a normal coroutineScope, a child created with async still cancels its parent as soon as it fails. Catching only await() from inside that already-cancelled scope is often too late. Use supervisorScope when children should fail independently, and then handle each await() result.

Things that trip people up:

• try/catch around launch { } doesn’t work - the builder returns immediately; the exception happens later, inside the coroutine. Put the try/catch inside the coroutine, or use a handler.
• A CoroutineExceptionHandler is a last-resort reporter for an uncaught root failure, not a recovery mechanism. It cannot make the failed coroutine continue.
• CancellationException is special - it’s not treated as a failure and doesn’t trigger the handler.
• With a regular Job, one child’s exception cancels siblings; with SupervisorJob/supervisorScope, children fail independently and each needs its own handling.

Cancellation is cooperative: cancelling a coroutine sets its Job to a cancelling state, but the coroutine only actually stops when it checks for cancellation. If your code never checks, it keeps running.

Suspending functions from kotlinx.coroutines (delay, withContext, yield, etc.) check automatically and throw CancellationException when cancelled. But a tight CPU loop won’t:

// ❌ Ignores cancellation - runs to completion even after cancel()
launch {
    while (i < 1_000_000) { heavyStep(i++) }
}

// ✅ Cooperates
launch {
    while (i < 1_000_000) {
        ensureActive()        // throws if cancelled
        heavyStep(i++)
    }
}

Ways to cooperate:

• ensureActive() - throws CancellationException if cancelled.
• isActive - check the flag yourself (while (isActive) { }).
• yield() - checks for cancellation and lets other coroutines run.
• Call any cancellable suspend function (delay, etc.).

Critical rules:

• CancellationException is normal - don’t swallow it. A blanket try { } catch (e: Exception) { } will eat it and break cancellation. Catch specific exceptions, or rethrow CancellationException.
• To run cleanup that itself suspends (closing a resource), use withContext(NonCancellable) { } - the coroutine is already cancelling, so normal suspension would immediately throw.
• finally blocks run on cancellation, so they’re the place for non-suspending cleanup.

The difference is how a child’s failure affects its siblings and parent.

Regular Job - failure propagates both ways: a failing child cancels its parent, which cancels all the other children. One failure tears down the whole scope.

SupervisorJob - failure propagates downward only: a child failing does not cancel its siblings or the parent. Each child fails independently.

// Regular: if one fails, both are cancelled
coroutineScope {
    launch { loadProfile() }   // if this throws...
    launch { loadFeed() }      // ...this gets cancelled too
}

// Supervisor: independent children
supervisorScope {
    launch { loadProfile() }   // can fail alone
    launch { loadFeed() }      // keeps running regardless
}

coroutineScope { } uses a regular Job; supervisorScope { } uses a SupervisorJob. Same relationship as CoroutineScope(Job()) vs CoroutineScope(SupervisorJob()).

When to use supervision: a screen loading several independent widgets where one failing shouldn’t blank the others; a viewModelScope-style scope where one failed operation shouldn’t kill all future ones.

Two gotchas interviewers love:

1. With SupervisorJob, each child needs its own exception handling - a CoroutineExceptionHandler must be installed on the child launch, not just the scope, because the failure doesn’t propagate up to the scope’s handler in the same way.
2. Putting SupervisorJob() inside a child launch(SupervisorJob()) does not make its children supervised - supervision comes from the scope’s Job, and passing a Job to a builder breaks the parent link. Use supervisorScope { } instead.

Both defer initialization, but they’re for different situations.

lateinit var

• A var you promise to set before first use. No initial value.
• Only for non-null, non-primitive types (var x: Int won’t work).
• Accessing it before assignment throws UninitializedPropertyException.
• You can reassign it and check ::x.isInitialized.
• Use when something injects/sets the value later - Dagger fields, onCreate views/binding, test setup.

private lateinit var binding: ActivityMainBinding
override fun onCreate(savedInstanceState: Bundle?) {
    binding = ActivityMainBinding.inflate(layoutInflater)
}

by lazy

• A val computed once, on first access, then cached.
• Thread-safe by default (LazyThreadSafetyMode.SYNCHRONIZED); you can relax it.
• Use for expensive, read-only values you might not even need.

val database by lazy { Room.databaseBuilder(...).build() }

Quick decision: mutable + set-externally-later → lateinit; read-only + compute-on-demand → lazy. And remember lateinit can’t be used with primitives or nullable types, while lazy can hold anything.

All three model a restricted set of types, but at different levels.

• enum - a fixed set of singleton instances, each the same type. Use it for a closed set of constants (Direction.NORTH). Every entry is one object; they can’t carry per-instance varying state across many instances.
• sealed class / sealed interface - a restricted hierarchy of subclasses known at compile time, but each subtype can have its own properties and multiple instances. Perfect for modeling UI state or results.
• abstract class - an open hierarchy; subclasses can be defined anywhere, including other modules. Use when you don’t need exhaustiveness and want open extension.

sealed interface UiState {
    data object Loading : UiState
    data class Success(val items: List<Item>) : UiState
    data class Error(val message: String) : UiState
}

The big win for sealed is exhaustive when - the compiler knows all subtypes, so you don’t need an else and it errors if you add a case and forget to handle it:

when (state) {
    UiState.Loading    -> showSpinner()
    is UiState.Success -> render(state.items)
    is UiState.Error   -> showError(state.message)
}  // no else needed

Rule of thumb: closed set of plain constants → enum; closed set of variants that carry different data → sealed; open extension → abstract.

Use StateFlow for state and SharedFlow for broadcasts or events.

StateFlow always has a current value. A new collector immediately receives that value, which makes it a natural fit for a screen’s loading, content, and error state.

private val _state = MutableStateFlow(UiState.Loading)
val state: StateFlow<UiState> = _state.asStateFlow()
_state.value = UiState.Loaded(items)   // synchronous, has a current value

SharedFlow does not need to hold one current value. You can configure whether it replays old values and how it buffers new ones. That makes it useful when several collectors need the same stream of events.

private val _events = MutableSharedFlow<Event>()   // replay = 0 by default
val events: SharedFlow<Event> = _events.asSharedFlow()
suspend fun navigate() = _events.emit(Event.GoToDetail)

Choosing:

• State that the screen renders (loading/content/error) → StateFlow.
• Transient broadcasts for active collectors (analytics ticks, refresh signals, a snackbar that may be dropped while the UI is absent) → SharedFlow with replay = 0.

Why not put consumable events directly in StateFlow? It retains the last value and replays it, so a naïve snackbar or navigation value may run again after recreation. SharedFlow(replay = 0) avoids replay, but it can drop an event when there is no collector. If delivery must survive the UI stopping, model the outcome as durable UI state (often the best option) or use an explicit queued-event design. State vs event is a delivery-semantics decision, not just a type choice.

Optional details:

• MutableStateFlow.value updates are conflated - fast intermediate values can be skipped; a rapidly emitting StateFlow won’t deliver every value, only the latest.
• Equality matters: StateFlow skips emissions that are equals to the current - using a data class for state means copy()-ing is what makes it emit.
• SharedFlow.emit suspends if the buffer is full; tryEmit doesn’t.

inline tells the compiler to copy the function body - and its lambda arguments - into the call site instead of creating a function object for each lambda. For higher-order functions this removes the per-call lambda allocation and the extra invoke() call.

inline fun measure(block: () -> Unit) {
    val start = System.nanoTime()
    block()                       // body inlined, no Function object created
    Log.d("perf", "${System.nanoTime() - start}ns")
}

Two extra benefits unlocked by inlining:

• Non-local returns - a return inside the lambda can return from the enclosing function.
• reified type parameters - the real type is available at runtime (covered separately).

The modifiers:

• noinline - opt a specific lambda out of inlining (e.g. you need to store it in a variable or pass it on as an object).
• crossinline - keep the lambda inlined but forbid non-local returns, needed when the lambda is called from another execution context (like inside a Runnable/another lambda).

inline fun run(crossinline body: () -> Unit) {
    val r = Runnable { body() }   // crossinline required here
    r.run()
}

When NOT to inline: large function bodies (inlining bloats bytecode at every call site) or functions with no lambda parameters (little benefit). Use it for small higher-order utilities.

object creates a class and its single instance at once. It has three uses:

1. Singleton (object declaration)

object Analytics {
    fun track(event: String) { /* ... */ }
}
Analytics.track("open")   // thread-safe, lazily created on first access

2. Companion object - a singleton tied to a class, called via the class name (factories, constants).

3. Object expression (anonymous object) - Kotlin’s answer to anonymous classes:

view.setOnClickListener(object : View.OnClickListener {
    override fun onClick(v: View?) { /* ... */ }
})

// or an ad-hoc object holding state
val point = object {
    val x = 1
    val y = 2
}

Things to know:

• An object declaration is initialized lazily and thread-safely on first use.
• Unlike a class, you can’t have a constructor (it takes no parameters).
• An anonymous object’s type is only visible locally - if returned from a public function it’s seen as its supertype.

Android note: an object singleton holding a Context is a classic memory leak - store applicationContext, never an Activity.

On the JVM generics are erased - at runtime List<String> and List<Int> are both just List, and a normal generic function can’t ask T::class or do is T. A reified type parameter keeps the concrete type available at runtime.

It only works with inline functions: because the function is inlined at the call site, the compiler substitutes the real type there, so the type information survives.

inline fun <reified T> Gson.fromJson(json: String): T =
    fromJson(json, T::class.java)

inline fun <reified T> List<*>.filterIsType(): List<T> =
    filterIsInstance<T>()        // uses `is T` under the hood

// Android: a clean startActivity helper
inline fun <reified T : Activity> Context.start() =
    startActivity(Intent(this, T::class.java))

context.start<DetailActivity>()

Why it matters: it removes the need to pass Class<T> parameters around (fromJson(json, Foo::class.java) becomes fromJson<Foo>(json)), which is why Gson/Moshi extensions, DI lookups, and intent builders use it everywhere.

Limitation to mention: because it relies on inlining, a reified type can’t be used from Java, and you can’t call it where T is itself a non-reified generic.

Cold flow (flow { }, flowOf, Room/Retrofit flows): the producer block runs per collector, starting only when collected. Two collectors get two independent executions from the start. No collector = no work.

val numbers = flow {
    println("start")        // runs each time someone collects
    emit(1); emit(2)
}

Hot flow (StateFlow, SharedFlow): emits regardless of collectors, and all collectors share the same stream. Late collectors miss past emissions (except replay/the current value).

	Cold (Flow)	Hot (StateFlow / SharedFlow)
Starts when	collected	exists independently
Per-collector execution	yes	shared
Has a current value	no	StateFlow: yes / SharedFlow: optional replay
Use for	one-shot data, transformations	observable app state, events

StateFlow = hot, always has one current value, conflated, deduplicated (distinctUntilChanged built in). Great for UI state.

SharedFlow = hot, configurable replay and buffer, no “current value” requirement. Great for one-off events (navigation, snackbars) where you don’t want replay on rotation.

Bridging them: convert a cold flow to hot with stateIn / shareIn, so an upstream (e.g. a DB query) runs once and is shared across collectors instead of re-running per subscriber.

val a: Int? = 127
val b: Int? = 127
val c: Int? = 128
val d: Int? = 128

println(a == b)    // ?
println(a === b)   // ?
println(c == d)    // ?
println(c === d)   // ?

Output:

true
true
true
false

Why:

• == calls equals() → structural equality. All four comparisons by value are true.
• === is referential equality (same object).
• The Int? types are boxed (Integer). The JVM caches boxed integers in the range −128..127, so a and b point to the same cached object → a === b is true. 128 is outside the cache, so c and d are different boxed objects → c === d is false.

never use === to compare values - it’s an implementation detail of boxing. Use == for value equality. (With non-nullable Int, there’s no boxing and this trap disappears - it only shows up because the types are nullable, forcing boxing.)

These are bread-and-butter and come up constantly:

val nums = listOf(1, 2, 3, 4, 5)

nums.map { it * 2 }              // [2,4,6,8,10] - transform each
nums.filter { it % 2 == 0 }     // [2,4]        - keep matching
nums.reduce { acc, n -> acc + n } // 15         - combine, seed = first element
nums.fold(100) { acc, n -> acc + n } // 115     - combine with explicit seed

val words = listOf("apple", "avocado", "banana")
words.groupBy { it.first() }    // {a=[apple, avocado], b=[banana]}
words.associate { it to it.length } // {apple=5, avocado=7, banana=6}
words.associateBy { it.first() } // {a=avocado, b=banana} (last wins per key)
words.partition { it.length > 5 } // Pair([avocado, banana], [apple])

listOf(listOf(1,2), listOf(3)).flatMap { it } // [1,2,3] - map then flatten

Distinctions interviewers probe:

• fold vs reduce - reduce starts from the first element and throws on an empty list; fold takes an explicit initial accumulator (and can change the result type).
• associate vs associateBy vs groupBy - associate builds key→value pairs you specify; associateBy keys by a selector (one value per key, last wins); groupBy keys to a list of all matching values.
• map vs flatMap - flatMap is for when each element produces a collection you want flattened into one.
• mapNotNull / filterNotNull - transform-and-drop-nulls in one pass.

For big chains, prepend .asSequence() to avoid intermediate lists.

The problem: a plain lifecycleScope.launch { flow.collect { } } keeps collecting even when the app is in the background. The UI isn’t visible, but the flow still does work and holds references - wasted CPU/battery and a potential crash if you touch views.

repeatOnLifecycle(STATE) suspends, and runs its block only while the lifecycle is at least in that state, cancelling it when the lifecycle drops below and restarting it when it comes back.

class MyFragment : Fragment() {
    override fun onViewCreated(view: View, b: Bundle?) {
        viewLifecycleOwner.lifecycleScope.launch {
            viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
                viewModel.uiState.collect { render(it) }   // collected only while STARTED
            }
        }
    }
}

What happens: when the app goes to the background (below STARTED), the collection coroutine is cancelled (unsubscribing from the flow); when it returns to the foreground, the block restarts and re-collects. For a StateFlow, you immediately get the current value back.

Equivalents / related:

• flowWithLifecycle(lifecycle, STARTED) - operator form for a single flow.
• Compose: collectAsStateWithLifecycle() does the same lifecycle-aware collection automatically - prefer it over collectAsState().

Common bug it prevents: using LATEST/launchWhenStarted (deprecated) only paused the coroutine but kept the flow subscription alive upstream - repeatOnLifecycle actually cancels it, which (combined with WhileSubscribed upstream) lets the producer stop too.

GlobalScope launches coroutines that live for the entire application lifetime and belong to no parent. That breaks structured concurrency and causes real problems:

• Leaks - the coroutine isn’t tied to any lifecycle, so it keeps running after the screen (and the objects it references) is gone. A GlobalScope.launch capturing a ViewModel or Context leaks it.
• No cancellation - nothing cancels it. You can’t stop it when the user navigates away; it runs to completion regardless.
• Orphaned errors - exceptions don’t propagate to any parent scope, so failures can vanish or crash unexpectedly.
• Hard to test - there’s no scope to control or wait on in tests.

// ❌ leaks, never cancelled, error goes nowhere useful
GlobalScope.launch { repo.sync() }

// ✅ tied to the ViewModel lifecycle
viewModelScope.launch { repo.sync() }

Use a lifecycle-bound scope instead: viewModelScope, lifecycleScope, or an application-scoped CoroutineScope you create and inject (with a SupervisorJob) for genuinely app-lifetime work (e.g. a sync that must outlive a screen).

@Singleton
class AppScope @Inject constructor() :
    CoroutineScope by CoroutineScope(SupervisorJob() + Dispatchers.Default)

The rare legit case: truly application-lifetime, fire-and-forget work with no lifecycle - but even then, an injected app scope is preferable because it’s testable and controllable. GlobalScope is marked @DelicateApi for exactly these reasons.

They all run code in a coroutine, but serve different purposes.

• withContext(ctx) { } - a suspend function that runs a block in a different context (usually a different dispatcher) and returns its result. It does not start a concurrent coroutine - it suspends the current one until the block finishes. Use it to switch threads for a piece of work.
• launch { } - starts a new concurrent coroutine, returns a Job, no result. Fire-and-forget.
• async { } - starts a new concurrent coroutine, returns a Deferred<T> you await(). Use for concurrent work you’ll combine.

// withContext: switch to IO, get the result back, sequential
suspend fun load() = withContext(Dispatchers.IO) { api.fetch() }

// async: two things at once
suspend fun loadBoth() = coroutineScope {
    val a = async { api.fetchA() }
    val b = async { api.fetchB() }
    a.await() to b.await()
}

The common mistake: using async { }.await() immediately to switch threads:

val data = async(Dispatchers.IO) { fetch() }.await()  // ❌ pointless
val data = withContext(Dispatchers.IO) { fetch() }    // ✅ clearer, cheaper

If you’re going to await right away, you want withContext - async is only worth it when you start multiple and await them later.

Rule of thumb: one result, switch context → withContext; concurrent work to combine → async; side-effect with no result → launch.

Both merge multiple flows, but emit on different triggers.

zip pairs emissions one-to-one, in lockstep. It waits until both flows have a new value, then emits a pair. It completes when either flow completes. Use it to pair up corresponding items.

combine emits whenever any flow emits, using that flow’s newest value plus the latest value of the others. It needs every flow to have emitted at least once before the first emission.

val a = flowOf(1, 2, 3)
val b = flowOf("x", "y")

a.zip(b) { n, s -> "$n$s" }       // [1x, 2y]  - pairs, stops at shorter
a.combine(b) { n, s -> "$n$s" }   // e.g. [3x, 3y] or [1x,2x,3x,3y]… - latest of each

When to use which:

• combine - building UI state from several independent sources: combine(user, settings, network) { ... }. Any source changing should recompute the result with the latest of the others. This is the common one in apps.
• zip - genuinely paired streams where item N of one corresponds to item N of the other (e.g. requests with their responses).

Gotchas:

• combine’s output count is non-deterministic - it depends on timing. Don’t assume a fixed number of emissions.
• combine won’t emit until every input has emitted once, so give each source an initial value (a StateFlow always has one, which is why it pairs well with combine).

Pagination loads a large list in chunks. The main strategies:

Offset/limit (page-based) - ?offset=40&limit=20 (or ?page=3).

• ✅ Simple, can jump to arbitrary pages, shows total count.
• ❌ Breaks on inserts/deletes - if items are added at the top while you scroll, offset 40 now points at a shifted position → duplicates or skipped items.
• ❌ Slow on large datasets (DB OFFSET scans rows).

Cursor/keyset-based - ?after=<cursor>&limit=20, where the cursor encodes the last item’s stable position (e.g. createdAt + id).

• ✅ Stable under inserts/deletes - you ask for “items after this specific item,” so shifting doesn’t cause dupes/gaps.
• ✅ Efficient (WHERE id < cursor LIMIT n uses an index, no offset scan).
• ❌ No random page access, harder to show a total count or “page 5.”

Why cursor wins for feeds: social/chat/activity feeds change constantly at the head. Cursor pagination is the standard because it’s consistent during live updates - exactly the mobile reality.

Mobile client implementation (Paging 3):

• PagingSource loads pages by cursor; RemoteMediator writes pages into Room for offline-first paging.
• Prefetch distance - load the next page before the user hits the end (smooth scroll).
• Placeholders for not-yet-loaded items; dedup by stable id; expose load states (loading/error/retry).
• cachedIn(scope) to survive config changes.

Other approaches: keyset with timestamp for chat history (before=<seq>), bidirectional paging (load older and newer), and infinite scroll vs explicit “load more” as UX choices.

Trade-offs to name: cursor’s consistency vs loss of random-access/total-count; prefetch distance (smoothness vs memory/data); page size (fewer requests vs larger payloads).

A side effect is anything that escapes the scope of a composable (network call, listener registration, logging). Composition can run often and unpredictably, so you must contain side effects in the right API:

LaunchedEffect(keys) - run a suspend block scoped to composition; cancelled on leave, restarted on key change. For coroutine work driven by the composition.

DisposableEffect(keys) - for effects that need cleanup. Register in the block, clean up in onDispose. Re-runs (dispose + re-setup) on key change.

DisposableEffect(lifecycleOwner) {
    val observer = LifecycleEventObserver { _, e -> /* ... */ }
    lifecycleOwner.lifecycle.addObserver(observer)
    onDispose { lifecycleOwner.lifecycle.removeObserver(observer) }
}

SideEffect { } - runs after every successful recomposition. Use to publish Compose state to a non-Compose object (e.g. update an analytics property or a third-party controller).

rememberCoroutineScope() - returns a CoroutineScope tied to the composition that you launch from event callbacks (not during composition):

val scope = rememberCoroutineScope()
Button(onClick = { scope.launch { snackbarHost.showSnackbar("Hi") } }) { ... }

How to choose:

• Suspend work when entering / on key change → LaunchedEffect.
• Need teardown (listeners, callbacks) → DisposableEffect.
• Launch a coroutine in response to a user event → rememberCoroutineScope.
• Sync Compose state to a non-Compose API every recomposition → SideEffect.

The rule: never call viewModel.load() or launch coroutines directly in a composable body - it’d fire on every recomposition. Use these APIs to scope effects correctly.

SharedPreferences is the old key-value store; DataStore (Jetpack) is its modern replacement, designed to fix SharedPreferences’ flaws.

SharedPreferences problems:

• apply() is async but commit() does synchronous disk I/O on the calling thread - easy to block the main thread (and a known ANR source).
• Loads the entire file into memory on first access, synchronously - can cause jank at startup.
• No error signaling, no transactional safety, no first-class async API.
• getString etc. can return on the main thread after blocking.

DataStore advantages:

• Fully async and safe - built on coroutines and Flow. Reads are a Flow; writes are suspend. No main-thread I/O.
• Transactional writes with strong consistency, and it surfaces errors (e.g. IOException) through the Flow.
• Two flavors:
  • Preferences DataStore - untyped key-value (drop-in for SharedPreferences use cases).
  • Proto DataStore - typed schema via protobuf, with type safety.

val EXAMPLE_KEY = booleanPreferencesKey("dark_mode")

val darkMode: Flow<Boolean> = context.dataStore.data
    .map { it[EXAMPLE_KEY] ?: false }

suspend fun setDarkMode(on: Boolean) {
    context.dataStore.edit { it[EXAMPLE_KEY] = on }
}

When to use which:

• DataStore for new code - settings, flags, small typed config.
• SharedPreferences only for legacy code or trivial cases; DataStore even provides a migration (SharedPreferencesMigration).
• For structured/relational data, neither - use Room.

Google’s official guidance defines two-to-three layers with UDF between them and a few firm principles.

Layers:

• UI layer - ViewModel + UI (Compose/Views). The ViewModel holds UiState and exposes it as an observable stream; the UI renders it and sends events up.
• Domain layer (optional) - use cases for reusable/complex business logic, sitting between UI and data.
• Data layer - repositories (the public API of the layer) over data sources (network, DB, DataStore). Repositories own the single source of truth and the data policy.

UI (ViewModel + Compose)  ──▶  Domain (UseCases)  ──▶  Data (Repository → sources)
        ▲────────────────── state flows back ──────────────────┘

The core principles Google emphasizes:

1. Separation of concerns - UI is thin; logic lives in ViewModel/domain/data, not Activities/Fragments.
2. Drive UI from data models - ideally immutable, observable state; UDF (state down, events up).
3. Single source of truth - each data type has one owner (usually the repository/DB) that others read; mutations go through it.
4. Unidirectional data flow - events flow up, state flows down.

Practical specifics:

• ViewModel exposes StateFlow<UiState>, often via stateIn(WhileSubscribed(5000)).
• Repository exposes Flows; DB (Room) is the source of truth for offline-first.
• Dependencies injected (Hilt); each layer testable in isolation.
• Scale up with modularization (feature + core modules) as in Now in Android.

Pragmatism: the domain layer is optional - add it when logic is shared or complex; ViewModel → Repository is fine otherwise. Don’t over-engineer simple screens.

Start with the user experience: messages should appear immediately, work through brief network loss, stay in the right order, and show whether they were sent or read. Then design the client one concern at a time.

Requirements: 1:1 (and group) messaging, real-time delivery, sent/delivered/read receipts, offline send & receive, message history, media.

Real-time transport: use a WebSocket, a connection that lets the client and server send messages at any time, while the app is in the foreground. Use FCM push notifications when it is backgrounded. If the connection drops, reconnect gradually instead of retrying in a tight loop.

Local data: let the UI observe messages from Room. Network responses update Room, and the UI updates from the database. This keeps one place responsible for the visible message history and makes offline reading straightforward.

messages(id, chatId, senderId, body, status, createdAt, serverSeq)
status: SENDING | SENT | DELIVERED | READ | FAILED

Sending a message (optimistic):

1. Insert into Room with a client-generated UUID and status = SENDING → UI shows it instantly.
2. Send over the socket (or queue if offline).
3. When the server acknowledges the message, change it to SENT and store the server ID. An acknowledgement simply means the server confirmed receipt.

• A WorkManager job (or outbox) drains queued messages when connectivity returns.

Receiving & ordering:

• The server assigns a monotonic sequence per chat (serverSeq); the client orders by it, not by device time (clocks drift).
• Reusing the client UUID makes a retry safe: the server can recognize the same message instead of creating a duplicate. This is called idempotency.
• Gap detection - if you receive seq 5 then 8, fetch the missing 6–7 (sync by “last seen seq”).

Receipts: delivered = stored on device; read = user opened the chat. Send these back over the socket; update local status.

Media: upload to blob storage, send a reference/URL in the message (not the bytes); thumbnails first, lazy full download; resumable chunked upload for large files.

Other concerns: pagination of history (cursor by serverSeq, load older on scroll up), E2E encryption (keys in Keystore) if required, typing/presence via lightweight socket events, notification dedup between FCM and socket.

Trade-offs to name: WebSocket battery cost vs real-timeness (drop socket in background, use FCM), optimistic UI vs consistency, ordering by server sequence vs device time.

Requirements: browse a feed of articles, read full content, read offline, sync read/bookmark state, images, periodic refresh.

Offline-first data layer (the centerpiece):

• Room is the single source of truth. The UI observes Room Flows, so the feed and saved articles render instantly and work offline.
• Schema: articles(id, title, summary, body, imageUrl, publishedAt, isRead, isBookmarked, cachedAt).
• Network fetches write into Room; the UI never reads the network directly.

Sync strategy:

• Cache-then-network - show cached feed immediately, refresh in background, update.
• Background refresh - WorkManager periodic job (constraints: unmetered + maybe charging) pulls latest headlines so content is fresh when the user opens the app, even offline.
• Delta sync with a timestamp/cursor to fetch only new articles.
• Prefetch full article bodies + images for the top N feed items (and bookmarked ones) so they’re readable offline - on Wi-Fi to save data.

Read & bookmark state:

• Stored locally (instant), synced to the server (delta). Optimistic updates; reconcile on sync.

Pagination: cursor-based, load older on scroll, RemoteMediator to page from Room.

Images: Coil with disk cache; prefetch thumbnails with the feed and the hero image for prefetched articles; downsample to view size.

UX: “saved for offline” indicator, last-updated time, pull-to-refresh, graceful offline banner.

Other concerns: cache eviction (cap stored articles / TTL cleanup of old cached bodies to bound storage), content formatting (sanitized HTML/markdown rendering), analytics (reads, dwell time, batched).

Trade-offs to name: how much to prefetch for offline (readability vs storage/data), refresh frequency (freshness vs battery/data), cache retention (offline availability vs storage), eager body prefetch vs on-demand.

Requirements: suggestions as the user types, fast, tolerant of slow networks, no wasted requests, no stale results.

The client pipeline (this is also a coroutines/Flow question):

queryFlow
    .debounce(300)                 // wait for a typing pause
    .filter { it.length >= 2 }     // skip tiny queries
    .distinctUntilChanged()        // skip duplicate queries
    .flatMapLatest { q ->          // cancel the previous in-flight search
        searchRepository.search(q)
            .onStart { emit(Loading) }
            .catch { emit(Error) }
    }
    .collect { render(it) }

Why each operator:

• debounce - don’t fire on every keystroke; one request per typing pause. Saves network/battery.
• distinctUntilChanged - type then backspace to the same text → no repeat search.
• flatMapLatest - cancel the stale search when a newer query arrives. Fixes the classic race: a slow response for “ja” must not overwrite results for “java”.

Caching & performance:

• Cache recent query results (LRU) so re-typing a query is instant and offline-tolerant.
• Local index for some sources - recent searches, contacts, on-device data via a Room FTS table → instant local suggestions merged with remote.
• Prefetch / warm popular queries.

Ranking & UX:

• Merge local (recent/history) + remote suggestions; rank by relevance/recency.
• Highlight the matched substring; show recent searches when the box is empty.
• Debounce-tuned for feel (200–400ms); show a subtle loading state, not a blocking spinner.

Backend-ish considerations (mention briefly): server-side prefix index (trie/Elasticsearch) - but the client focus is debounce, cancellation, caching, and merging local+remote.

Trade-offs to name: debounce delay (responsiveness vs request count), min query length, local vs remote suggestions (instant/offline vs coverage), cache size, prefetch popular queries (instant vs wasted work).

The model: OAuth2/OIDC issues a short-lived access token (minutes–hours) and a long-lived refresh token (days–months). The access token authorizes API calls; the refresh token gets a new access token when it expires.

Login flow:

• OAuth2 with PKCE (Authorization Code + PKCE) for first-party and social login - avoids embedding secrets in the app.
• Store tokens securely - encrypted via Android Keystore (EncryptedSharedPreferences / encrypted DataStore). Never plain prefs.

Transparent refresh (the key client design):

• Use OkHttp’s Authenticator, which fires automatically on a 401: refresh the token and retry the original request - invisible to the rest of the app.

class TokenAuthenticator(private val store: TokenStore, private val api: AuthApi) : Authenticator {
    override fun authenticate(route: Route?, response: Response): Request? {
        val newToken = runBlocking { refreshOnce() } ?: return null  // give up → log out
        return response.request.newBuilder()
            .header("Authorization", "Bearer $newToken").build()
    }
}

• Serialize concurrent refreshes - if 5 requests 401 at once, only one refresh should run (a Mutex); the others wait and reuse the new token. Otherwise you fire 5 refreshes and may invalidate each other.
• An Interceptor attaches the current access token to every request.

Edge cases to handle:

• Refresh token expired/revoked → force logout, clear tokens, send to login.
• Refresh token rotation - many servers issue a new refresh token each refresh; store the latest, handle reuse-detection (a replayed old token = possible theft → invalidate session).
• Clock skew - refresh slightly before expiry (proactive) or rely on 401 (reactive); proactive avoids a failed request.
• Logout - revoke server-side, clear local tokens, clear caches, cancel the device push token.
• Multiple accounts - token store keyed by account.

Security: Keystore-backed storage, HTTPS + cert pinning, biometric gate for sensitive apps, no tokens in logs.

Trade-offs to name: access-token lifetime (security vs refresh frequency), proactive vs reactive refresh (extra check vs a failed request), refresh-token rotation (security vs complexity).

Flow overview: App registers with FCM → gets a device token → sends it to your backend → backend sends messages to FCM addressed by token → FCM delivers to the device → your app shows a notification or syncs.

Client responsibilities:

1. Token management

• On onNewToken, upload the token to your backend (associated with the user/device). Tokens rotate (reinstall, restore, refresh) - always sync the latest.
• Remove/invalidate tokens on logout so the next user doesn’t get the previous user’s pushes.

2. Message types (the key design choice):

• Notification messages - FCM displays them automatically when backgrounded; limited control.
• Data messages - delivered to your onMessageReceived (foreground; background with caveats), giving you full control to build the notification or trigger a sync.
• Best practice: use data messages so you control rendering and can act (sync), and treat the push as a signal - for important data, fetch the source of truth rather than trusting the payload (which is size-limited and not guaranteed ordered).

3. Displaying & handling

• Build with NotificationCompat on the right channel (user-controlled importance); attach an immutable PendingIntent with a deep link to the relevant screen.
• Request POST_NOTIFICATIONS runtime permission (Android 13+).
• Deduplicate with the socket/in-app path (don’t double-notify), and collapse related notifications (group + summary, or collapseKey).

4. Reliability & priority

• High-priority messages can wake the app from Doze for time-sensitive pushes (use sparingly - abuse gets throttled).
• FCM delivery is best-effort, not guaranteed/instant/ordered - design for missed/late pushes (sync on next open).
• WorkManager to do any heavy work the push triggers (don’t do it in onMessageReceived, which has a ~10s budget).

Trade-offs to name: data vs notification messages (control vs simplicity), high-priority (timeliness vs battery/throttling), push-as-signal vs push-as-payload (reliability vs latency).

Launch modes control how an Activity instance relates to the task back stack. Set them in the manifest (android:launchMode) or via intent flags.

• standard (default) - a new instance every time it’s launched, even if one already exists. Can have multiple copies in the stack.
• singleTop - if an instance is already at the top of the stack, reuse it and deliver the intent to onNewIntent() instead of creating a new one. If it’s not on top, a new instance is created.
• singleTask - at most one instance in the task. If it exists, it’s brought to the front and everything above it is cleared (onNewIntent is called). Common for an app’s entry/root activity.
• singleInstance - like singleTask, but the activity is the only one in its task - nothing else can be added to that task. Rare (e.g. a launcher or a separate-window screen).

Equivalent intent flags (set at launch time, no manifest change):

• FLAG_ACTIVITY_NEW_TASK - start in a new/ existing task.
• FLAG_ACTIVITY_SINGLE_TOP - like singleTop for this launch.
• FLAG_ACTIVITY_CLEAR_TOP - if the activity exists in the stack, clear everything above it.
• FLAG_ACTIVITY_CLEAR_TASK (with NEW_TASK) - wipe the task and start fresh (e.g. after logout).

onNewIntent() is the callback you must handle when an existing instance is reused - the new Intent arrives there, not in onCreate. Forgetting it means you process the old intent’s data.

Practical uses: singleTask/CLEAR_TOP for “go home” buttons and notification taps that shouldn’t stack duplicates; singleTop for a search activity re-launched with a new query; CLEAR_TASK + NEW_TASK to reset the stack on logout.

Three related concepts let you produce multiple versions of an app from one codebase:

• Build types - how the app is built. Default debug and release; differ in signing, minifyEnabled, debuggable, applicationIdSuffix, etc. You can add custom ones (e.g. staging).
• Product flavors - what the app is. Different variants like free/paid, or dev/prod (different API endpoints, app names, feature sets). Grouped by flavor dimensions.
• Build variant = build type × flavor. With flavors free/paid and types debug/release you get four: freeDebug, freeRelease, paidDebug, paidRelease.

android {
    flavorDimensions += "tier"
    productFlavors {
        create("free")  { dimension = "tier"; applicationIdSuffix = ".free" }
        create("paid")  { dimension = "tier" }
    }
    buildTypes {
        getByName("release") { isMinifyEnabled = true; signingConfig = ... }
        create("staging")    { initWith(getByName("debug")); applicationIdSuffix = ".staging" }
    }
}

What you control per variant:

• applicationId/suffix - so debug/staging/free can install alongside release (different package names).
• buildConfigField and resValue - inject constants (API base URL, feature flags) and resources per variant.
• Source sets - src/free/, src/debug/ directories override/add code and resources for that variant.
• Signing configs, ProGuard rules, manifest placeholders.

Common real-world use: dev/prod flavors pointing at different backends, a staging build type for QA, and applicationIdSuffix so testers keep prod + staging installed simultaneously.

Clean Architecture separates code by responsibility. The useful part is not the diagram or the number of layers. It is keeping business rules independent from Android UI and storage details.

On Android this typically maps to three layers (Google’s recommended architecture):

• Data layer - repositories and their data sources (network, database, cache). Owns how data is fetched/stored. Exposes data to the domain/UI.
• Domain layer (optional) - pure business logic: use cases and domain models. No Android dependencies - plain Kotlin, fully testable. Defines repository interfaces.
• UI (presentation) layer - ViewModels + Compose/Views. Holds UI state, reacts to user input, observes data.

UI  ──depends on──▶  Domain  ◀──depends on──  Data
(ViewModel)          (UseCase,                (Repository impl,
                      interfaces)              network, db)

The dependency rule in practice: a domain layer can define a UserRepository interface and the data layer can implement it. Business logic then knows it can load a user, but does not know whether the data came from Room, Retrofit, or a fake used in a test.

Why teams use it:

• Testability - domain logic is pure Kotlin, tested without Android.
• Replaceability - change a data source without rewriting the UI.
• Separation of concerns - each layer has one reason to change.

Keep it practical:

• The domain layer is optional - for simple screens, ViewModel → Repository is fine; add use cases when business logic is reused across ViewModels or gets complex.
• Don’t over-engineer: mapping models across three layers and a use case per call can be overkill for a CRUD app. Match the architecture to the app’s complexity.
• Separate models can protect layers from each other’s changes, but mapping every small object through four representations is not automatically better.

This trio is the message-passing machinery behind Android’s main thread.

• MessageQueue - a queue of Message/Runnable tasks to be processed, ordered by time.
• Looper - an infinite loop bound to a thread that pulls messages off the queue and dispatches them, one at a time. One Looper per thread (Looper.prepare() + Looper.loop()).
• Handler - the interface to post messages/runnables onto a Looper’s queue and to handle them when they’re dispatched. A Handler is bound to the Looper of the thread that created it (or one you pass).

val mainHandler = Handler(Looper.getMainLooper())
mainHandler.post { textView.text = "Done" }        // run on main thread
mainHandler.postDelayed({ /* ... */ }, 1000)        // schedule for later

The main (UI) thread is a thread running a Looper. The framework calls Looper.loop() for you; every lifecycle callback, touch event, and View.invalidate is a message dispatched through the main MessageQueue. That’s why:

• All UI updates must happen on the main thread - it’s the single thread draining that queue.
• Blocking the main thread (heavy work in a message) stalls the queue → no frames drawn → ANR.
• You “go back to the UI thread” by posting to the main Handler (or, in coroutines, Dispatchers.Main).

Where it still matters today: even though you use coroutines now, Dispatchers.Main is built on the main Looper, and HandlerThread (a thread with its own Looper) backs some libraries (e.g. camera/sensor callbacks). Understanding it explains why runOnUiThread, View.post, and Dispatchers.Main exist.

LaunchedEffect runs a suspend block tied to the composition. It launches a coroutine when the composable enters the composition and cancels it when the composable leaves - perfect for one-off or ongoing async work driven by Compose.

LaunchedEffect(Unit) {
    viewModel.loadData()          // runs once when entering composition
}

The keys are the crucial part. LaunchedEffect(key1, key2, …) restarts the coroutine (cancels the old, starts a new) whenever any key changes. If keys don’t change across recompositions, the same coroutine keeps running.

LaunchedEffect(userId) {
    user = repository.loadUser(userId)   // reloads whenever userId changes
}

• LaunchedEffect(Unit) or LaunchedEffect(true) - run once for the composable’s lifetime (key never changes). Good for “fire on first appearance.”
• LaunchedEffect(key) - re-run when key changes. The classic bug is using Unit when you need it to re-run on a parameter change (stale data), or capturing a value that’s stale because it isn’t a key.

Output-based trap:

LaunchedEffect(Unit) {
    delay(2000)
    println(count)     // captures count at first composition - may be STALE
}

If count should be current, either add it as a key, or wrap it in rememberUpdatedState.

Two structural patterns that are easy to confuse.

Adapter - converts one interface into another the client expects. It wraps an incompatible type to make it usable.

// Adapt a domain list to what RecyclerView expects
class UserAdapter(val users: List<User>) : RecyclerView.Adapter<UserVH>() { ... }

Android examples: RecyclerView.Adapter (the name says it - adapts data to view-holders), PagerAdapter, wrapping a third-party SDK’s interface behind your own (AnalyticsClient interface adapting Firebase/Amplitude), or a Retrofit CallAdapter. Use it to make incompatible interfaces work together, especially to wrap libraries you don’t control behind your own abstraction (an anti-corruption layer).

Decorator - adds behavior to an object dynamically by wrapping it in another object with the same interface, without changing the original.

interface DataSource { suspend fun load(key: String): String }

class CachingDataSource(private val wrapped: DataSource) : DataSource {
    private val cache = mutableMapOf<String, String>()
    override suspend fun load(key: String) =
        cache.getOrPut(key) { wrapped.load(key) }   // adds caching, same interface
}

class LoggingDataSource(private val wrapped: DataSource) : DataSource {
    override suspend fun load(key: String): String {
        Log.d("DS", "load $key"); return wrapped.load(key)
    }
}

Android examples: OkHttp Interceptors (each wraps the chain, adding logging/auth/caching), ContextWrapper (and ContextThemeWrapper), input stream wrappers (BufferedInputStream). You can stack decorators (Logging(Caching(real))) to compose behavior.

The distinction:

• Adapter = change the interface (make B usable as A).
• Decorator = same interface, add responsibilities (wrap to enhance).