Pick a problem.
Build the feature.

Fundamentals lesson · original examples

Start with Android Studio Empty Activity, Kotlin, Compose and Material 3. Keep one app module for the timed attempt. Create model/, data/ and ui/ packages, then implement sample data, repository, ViewModel, and screen. Make loading, empty, content and failure observable before adding persistence.

app/src/main/java/dev/dchung/sleepjournal/
  MainActivity.kt
  JournalApplication.kt
  model/
    SleepNight.kt, Note.kt, Journal.kt, SampleNights.kt
  ui/journal/
    JournalRoute.kt, JournalScreen.kt, JournalViewModel.kt
    JournalUiState.kt, JournalEvent.kt, JournalPresentation.kt
    JournalIntent.kt, JournalReducer.kt   // MVI path only
    PhaseLab.kt                           // optional WS13 experiment
  data/
    JournalRepository.kt, RoomJournalRepository.kt
    local/JournalDatabase.kt, JournalDao.kt, JournalEntities.kt
    remote/DemoBackend.kt, JournalDtos.kt
  sync/
    JournalSyncWorker.kt, SyncQueue.kt
  di/
    JournalModule.kt, IoDispatcher.kt

The workshop uses these package boundaries in its actual snippets and reference downloads. Use plain String IDs for nights and notes. Keep ViewModels and UI state beside their screen; database entities and network DTOs stay in data.

Use the current Compose BOM for Compose artifacts. Lifecycle, Room, Hilt and coroutines are versioned separately. Use KSP compatible with the project Kotlin/compiler setup. Sync and run an empty screen first; dependency repair should happen before your timed rehearsal.

30-minute order

• First 3 minutes: restate the behavior, identify the state owner, and show the sample model.
• Next 15 minutes: finish one usable path through repository, ViewModel and Compose.
• Next 7 minutes: handle failure/retry and one meaningful unit test.
• Last 5 minutes: run the feature, explain lifecycle/cancellation, and show a UI test or describe the remaining coverage.
• For the longer follow-up, add Room, WorkManager and Hilt. Ask what libraries the interview project already provides.

Primary references: Android build configuration

Fundamentals lesson · original examples

MVVM assigns screen decisions to a ViewModel and persistence/network behavior to a repository. MVI usually makes intents, state transitions and side effects explicit. The terms overlap: a ViewModel can expose immutable state and process intents with a pure reducer. Neither name requires a framework or a new module.

Use the same folder structure for MVVM and MVI. Put screen state and ViewModel code in ui/journal. MVI adds its intent and reducer beside them. Domain models do not import UI controls; repositories, Room entities and API adapters stay in data. The workshop provides separate implementation paths with the same storage and user-visible behavior.

For the workshop, JournalUiState holds everything Compose renders. UserInput groups the query, favorite filter, selected night and draft. LoadState is an enum with Loading, Ready and Failure; the journal data and error message are fields in UiState. Compose uses if checks to show the matching UI. The JournalRepository interface lets us replace memory storage with Room; a single concrete repository is enough when you do not need that swap.

UI action -> ViewModel or intent handler -> repository write
Room or in-memory state -> Flow -> ViewModel UI state -> Compose
Reducer: previous state + action -> next state
Effect runner: send request -> dispatch result action

Use one screen state with explicit content and operation status. Keep transient input separate from persisted entities. A domain use case is useful when rules are reused; a pass-through use case adds little to a small interview feature.

Choose the state lifetime

• remember: composition-local state. rememberSaveable: small saveable UI values across recreation.
• ViewModel: survives configuration changes while its owner remains; it does not survive process death.
• SavedStateHandle: small draft/query or ID needed to reconstruct a screen after eligible state restoration.
• Room: durable records, favorites, pending operations. DataStore: small preferences.
• Represent important user feedback as state with an acknowledgement ID. A SharedFlow with no replay can lose it while the screen is stopped.

sealed interface InputAction {
    data class Changed(val text: String) : InputAction
    data object Cleared : InputAction
}
data class InputState(val text: String = "")
fun reduce(state: InputState, action: InputAction): InputState =
    when (action) {
        is InputAction.Changed -> state.copy(text = action.text)
        InputAction.Cleared -> state.copy(text = "")
    }

Keep network calls outside the reducer. Serialize result actions if they can race.

Primary references: Android architecture recommendations

Fundamentals lesson · original examples

A coroutine is a cancellable computation, not a thread. A suspending call can release its thread while waiting. Marking a function suspend does not move blocking work off Main. Dispatchers.Main is for UI, IO for blocking I/O, and Default for CPU work. A suspend network library may already be main-safe.

launch returns a Job for work without a result. async returns Deferred for a result obtained with await. withContext changes the context for a block and returns its result. coroutineScope waits for children; a child failure normally cancels its siblings. Keep the parent-child relationship and avoid GlobalScope.

suspend fun loadOverview(api: OverviewApi): Overview = coroutineScope {
    val profile = async { api.profile() }
    val history = async { api.history() }
    Overview(profile.await(), history.await())
}

Design sketch: OverviewApi and Overview are your domain contracts. If the reads depend on each other, call them sequentially.

viewModelScope is appropriate for screen-owned work. For work that must survive leaving the screen, select an explicitly owned longer scope or persistent work. A Job is cancellation/lifetime; a dispatcher is execution context. Dispatchers.IO alone is not a durable lifetime.

Senior distinctions

• Use withContext on an injected dispatcher around blocking file/database adapters or expensive parsing. Room suspend/Flow adapters already manage their work.
• A suspend call does not guarantee cancellation of a blocking SDK call. Use a cancellable adapter or runInterruptible when the API supports thread interruption.
• Do not use runBlocking or Thread.sleep on Main. Prefer delay for asynchronous waits.
• Never launch a fresh disconnected scope inside a suspending repository method merely to return early.

Primary references: Coroutine context and dispatchers · Android coroutine best practices

Fundamentals lesson · original examples

Cancellation is cooperative. Suspending library calls check it; long CPU loops should periodically call ensureActive or yield. Clean up resources in finally. Catch CancellationException only to rethrow it. A broad runCatching also catches cancellation, so inspect the failure before turning it into a user error.

coroutineScope is appropriate when all child results are required. supervisorScope isolates child failures, but each child still needs explicit handling. A SupervisorJob does not make exceptions disappear. CoroutineExceptionHandler handles uncaught failures for applicable launch jobs; it is not a substitute for recovery around an awaited operation.

try {
    val completed = withTimeoutOrNull(5_000) {
        repository.refresh()
        true
    }
    if (completed == null) showRefreshTimeout()
} catch (cancelled: CancellationException) {
    throw cancelled
} catch (failed: IOException) {
    showRefreshFailure()
}

Illustrative calls. withTimeoutOrNull returns null for the timeout it owns; cancellation from an outer scope still propagates. A UI timeout does not undo a server-side operation.

For replaceable reads, cancel the previous Job or use flatMapLatest. A cancelled client request may still finish on a server. Protect writes with an idempotency key, and protect displayed responses with a request identity when the adapter cannot cancel reliably. A request ID and a server/device revision describe different orderings.

Rehearse races

• Search for "s" then "sleep": a late "s" result must not overwrite "sleep".
• Tap Send twice before the first coroutine starts: claim the in-flight state synchronously.
• Clear a chat while a delayed reply is pending: cancel its owner or reject the reply using a conversation generation.
• Device slider: latest requested temperature can differ from acknowledged temperature; preserve both.

Primary references: Cancellation and timeouts · Coroutine exception handling

Fundamentals lesson · original examples

Flow is an interface, so seeing Flow<T> alone does not prove a source is cold. MutableStateFlow can change with no collector. A cold flow does no builder work until collection. A shared stream has one producer lifetime, which its owning scope and sharing policy control.

StateFlow compares values with equals. Publish immutable snapshots with copy; mutating a list inside the existing state can leave observers unaware. MutableStateFlow.update is atomic, but its lambda can run more than once. Keep network calls, counters with external effects, and ID generation outside that lambda.

With MutableSharedFlow(replay = 0), values emitted without subscribers are lost. extraBufferCapacity supports slow active subscribers; it does not store an offline backlog for future subscribers. replay = 1 re-delivers the latest item to new subscribers, which can repeat navigation or a snackbar.

var starts = 0
val cold = flow { emit(++starts) }
println(cold.first())
println(cold.first())
val hot = MutableStateFlow(7)
println(hot.first())
println(hot.first())

Run in a coroutine with kotlinx.coroutines.flow imports.

Primary references: Kotlin Flow guide · StateFlow API · SharedFlow API

Fundamentals lesson · original examples

@OptIn(ExperimentalCoroutinesApi::class)
fun searchResults(query: Flow<String>, api: SearchApi): Flow<SearchUiState> =
    query.map { it.trim() }.distinctUntilChanged().flatMapLatest { text ->
        flow<SearchUiState> {
            if (text.isBlank()) {
                emit(SearchUiState.Empty)
            } else {
                emit(SearchUiState.Loading(text))
                delay(300)
                emit(SearchUiState.Content(text, api.search(text)))
            }
        }.catch { error ->
            if (error is IOException) emit(SearchUiState.Error(text))
            else throw error
        }
    }

Design sketch: define SearchApi and the sealed SearchUiState. The delay inside the new inner flow cancels old work before the wait. Loading includes the query so the UI can associate results with their input.

catch handles failures upstream of its position, not exceptions in the terminal collector. Emitting a fallback ends that failing upstream collection; it does not automatically reconnect. Catching inside flatMapLatest lets future queries create new streams. Use bounded retryWhen for recoverable transport failures.

Primary references: Flow API and operator contracts · Kotlin Flow guide

Fundamentals lesson · original examples

stateIn creates shared state; shareIn creates a shared broadcast. Choose the scope first, then the start policy and replay. Eagerly starts immediately. Lazily starts on the first subscriber and continues until the owning scope ends. WhileSubscribed follows subscribers with configurable stop and replay timeouts.

val uiState: StateFlow<HistoryUiState> = repository.observeHistory()
    .map<List<Night>, HistoryUiState> { HistoryUiState.Content(it) }
    .catch { error ->
        if (error is IOException) emit(HistoryUiState.Error)
        else throw error
    }
    .stateIn(
        viewModelScope,
        SharingStarted.WhileSubscribed(stopTimeoutMillis = 5_000),
        HistoryUiState.Loading
    )

Illustrative domain types. Put stateIn in a stable ViewModel property, not in a composable or a getter that creates it on every access.

The 5-second stop timeout delays stopping upstream after the last subscriber leaves. It is not polling, a network timeout, or disk caching. The replay cache is retained by default; replayExpirationMillis = 0 resets stateIn to its initial value after stopping. Collection can restart upstream when a subscriber returns.

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

// Fragment, use the view lifetime
viewLifecycleOwner.lifecycleScope.launch {
    viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
        launch { viewModel.uiState.collect { render(it) } }
        launch { viewModel.connection.collect { renderConnection(it) } }
    }
}

Two infinite flows need two child collectors. Sequential collect calls never reach the second stream.

An upstream failure in stateIn/shareIn terminates the sharing coroutine and goes to its scope, rather than becoming an exception delivered to subscribers. Put expected recovery before sharing. If the resulting flow completes after catch, define how retry will start new upstream work.

Primary references: StateFlow and SharedFlow on Android · WhileSubscribed API · Testing Kotlin flows

Fundamentals lesson · original examples

This small chat example connects immutable messages, a repository contract, draft input and send status. It is a teaching slice, not a completed answer to EP01. Add the ping/pong delay, deletion, image handling and clear-history rules yourself. The in-memory fake is not offline storage.

import androidx.lifecycle.ViewModel
import androidx.lifecycle.viewModelScope
import java.io.IOException
import kotlinx.coroutines.CancellationException
import kotlinx.coroutines.flow.*
import kotlinx.coroutines.launch

data class ChatMessage(val id: String, val text: String)
interface ChatRepository {
    fun observeMessages(): Flow<List<ChatMessage>>
    suspend fun send(text: String)
}
sealed interface SendState {
    data object Idle : SendState
    data object Sending : SendState
    data object Failed : SendState
}
data class ChatUiState(
    val messages: List<ChatMessage> = emptyList(),
    val draft: String = "",
    val send: SendState = SendState.Idle
)
class ChatViewModel(private val repository: ChatRepository) : ViewModel() {
    private val draft = MutableStateFlow("")
    private val sendState = MutableStateFlow<SendState>(SendState.Idle)
    val uiState: StateFlow<ChatUiState> = combine(
        repository.observeMessages(), draft, sendState
    ) { messages, text, status -> ChatUiState(messages, text, status) }
        .stateIn(viewModelScope, SharingStarted.WhileSubscribed(5_000), ChatUiState())

    fun onDraftChanged(text: String) { draft.value = text }

    fun onSend() {
        val original = draft.value
        val text = original.trim()
        if (text.isEmpty() || sendState.value == SendState.Sending) return
        sendState.value = SendState.Sending
        viewModelScope.launch {
            try {
                repository.send(text)
                draft.compareAndSet(original, "")
                sendState.value = SendState.Idle
            } catch (cancelled: CancellationException) {
                throw cancelled
            } catch (failed: IOException) {
                sendState.value = SendState.Failed
            } finally {
                if (sendState.value == SendState.Sending) {
                    sendState.value = SendState.Idle
                }
            }
        }
    }
}

Calls to onDraftChanged/onSend come from Main. The repository contract assumes an observable local store that keeps producing; handle storage failures separately. compareAndSet prevents a completed send from clearing a newer draft.

The in-flight guard changes synchronously before launch. This covers two taps even if uiState has not emitted its new value yet. UI disabling is useful feedback, but the state owner still enforces the rule. The coroutine test in AF13 uses this exact contract and ViewModel.

Primary references: Android architecture recommendations · Android coroutine best practices

Fundamentals lesson · original examples

Keep the route responsible for obtaining the ViewModel and collecting it. Pass plain state and callbacks into a stateless screen. Hoist shared state to its common owner. Use stable item IDs, avoid network calls during composition, and model loading/empty/error explicitly.

import androidx.compose.foundation.layout.*
import androidx.compose.foundation.lazy.LazyColumn
import androidx.compose.foundation.lazy.items
import androidx.compose.material3.*
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.platform.testTag

@Composable
fun ChatScreen(
    state: ChatUiState,
    onDraftChanged: (String) -> Unit,
    onSend: () -> Unit,
    modifier: Modifier = Modifier
) {
    Column(modifier) {
        LazyColumn(Modifier.weight(1f).fillMaxWidth()) {
            items(state.messages, key = { it.id }) { message ->
                Text(message.text, Modifier.testTag("message-${message.id}"))
            }
        }
        if (state.send == SendState.Failed) {
            Text("Send failed. Try again.", Modifier.testTag("send-error"))
        }
        OutlinedTextField(
            value = state.draft,
            onValueChange = onDraftChanged,
            label = { Text("Message") },
            modifier = Modifier.fillMaxWidth().testTag("chat-input")
        )
        Button(
            onClick = onSend,
            enabled = state.draft.isNotBlank() && state.send != SendState.Sending,
            modifier = Modifier.testTag("chat-send")
        ) { Text("Send") }
    }
}

Call this in a size-constrained Scaffold content area and apply its padding. The route imports lifecycle-compose collectAsStateWithLifecycle and delegates state/events.

LaunchedEffect keys control restarting a composition-owned effect. DisposableEffect is for cleanup of a registration/resource. rememberCoroutineScope supports a UI interaction tied to the composition. Do not create a player or start collection on every recomposition.

Small-feature details

• Navigate with an ID rather than a large DTO; reconstruct detail data through the repository. Keep NavController in UI.
• Use rememberSaveable for a simple local toggle or SavedStateHandle for a ViewModel-owned query. They are not replacements for a database.
• For image selection, use the photo picker and a URI. Do not assume it is a filesystem path; plan URI access/copying for persistence.
• Make content descriptions useful and keep touch targets accessible. Assert semantic behavior in UI tests.

Continue with AF17 for recomposition versus layout/redraw and AF18 for remember, derivedStateOf, snapshotFlow, stability and profiling.

Primary references: State in Compose · Navigation with Compose · Photo picker

Fundamentals lesson · original examples

For an offline-first feature, the UI observes persisted local data and refresh writes network results into that store. Keep DTOs and database entities inside the data layer. Room fits messages/history/favorites; DataStore fits preferences. A StateFlow cache disappears with process death.

import androidx.room.*
import kotlinx.coroutines.flow.Flow

@Entity(tableName = "messages")
data class MessageEntity(
    @PrimaryKey val id: String,
    val text: String,
    val createdAtMillis: Long,
    val pending: Boolean
)
@Dao
interface MessageDao {
    @Query("SELECT * FROM messages ORDER BY createdAtMillis, id")
    fun observeAll(): Flow<List<MessageEntity>>

    @Upsert
    suspend fun upsert(messages: List<MessageEntity>)

    @Query("SELECT * FROM messages WHERE pending = 1 ORDER BY createdAtMillis, id")
    suspend fun pending(): List<MessageEntity>
}
@Database(entities = [MessageEntity::class], version = 1, exportSchema = true)
abstract class ChatDatabase : RoomDatabase() {
    abstract fun messages(): MessageDao
}

Teaching schema, not a complete sync implementation. Persist migrations and exported schemas in a production project. Include an account/conversation key before supporting multiple users or conversations.

Offline read exercise

• EP05 or EP11: store favorites by stable destination/venue ID.
• Persist the favorite, restart the app with network disabled, and confirm it stays selected.
• Refresh venue/catalog data while preserving local favorites; keep server data separate from local preference fields.
• Distinguish first-load empty from cached empty, and refresh failure from failure to read the database.
• Use a transaction for related writes that must become visible together. Avoid destructive migration as a default.

Primary references: Room storage · Offline-first data layer

Fundamentals lesson · original examples

Choose write behavior per operation. A favorite or chat draft can update locally first. A payment or device command may require online acknowledgement. Do not label a queued operation as completed. Pending, acknowledged and failed are meaningful states for EP01 and EP09.

Durable outbox design

• Create a stable operation ID once. In one database transaction, write the optimistic local record and an outbox row with payload, account, status and attempt metadata.
• Enqueue persistent sync with WorkManager using appropriate constraints and bounded/backoff retry. It is deferred work, not an immediate real-time channel.
• Worker selects or atomically claims pending work. Send the same idempotency key on each retry; the backend must support deduplication.
• On acknowledgement, transactionally mark the operation complete and merge canonical server IDs/revisions. If the process dies after server success but before local acknowledgement, retry remains safe.
• A unique worker name reduces overlapping work; it cannot by itself prevent duplicate server effects. Recover abandoned claims after crashes.
• Retry transient connectivity/5xx failures. Re-authenticate before retrying authorization failures. Mark permanent validation failures for user correction.

For conflicts, define which fields the client owns and which the server owns. Use server revisions or explicit conflict responses rather than trusting device wall-clock ordering. Use tombstones or versioned deletes so a refresh cannot resurrect deleted records. Persist the incremental cursor only after successfully committing its batch.

1. Client persists operation op-123 and a pending message.
2. Server accepts op-123 and creates message server-456.
3. App dies before marking op-123 complete.
4. Worker retries op-123 after restart.
5. Server returns the original result for the same key.
6. Client merges server-456 and clears pending atomically.

Server idempotency and client reconciliation are required. This is an original design exercise.

Connectivity is a scheduling hint, not proof a request will succeed. If UI observes Room, a worker update naturally reaches the screen through Flow. For a device, queued desired state and confirmed hardware state must remain distinct.

Primary references: Offline-first data layer · WorkManager

Fundamentals lesson · original examples

Constructor injection exposes dependencies and makes replacement with fakes straightforward. Hilt generates the Android object graph. Bind an interface to an implementation; provide third-party objects such as a database. Singleton, ActivityRetained and ViewModel scopes describe lifetimes, not where work executes.

import android.app.Application
import dagger.Binds
import dagger.Module
import dagger.Provides
import dagger.hilt.InstallIn
import dagger.hilt.android.HiltAndroidApp
import dagger.hilt.components.SingletonComponent
import javax.inject.Inject
import javax.inject.Qualifier
import javax.inject.Singleton
import kotlinx.coroutines.CoroutineDispatcher
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.flow.*

@HiltAndroidApp
class PracticeApplication : Application()

@Singleton
class InMemoryChatRepository @Inject constructor() : ChatRepository {
    private val messages = MutableStateFlow<List<ChatMessage>>(emptyList())
    override fun observeMessages(): Flow<List<ChatMessage>> = messages.asStateFlow()
    override suspend fun send(text: String) {
        val item = ChatMessage(java.util.UUID.randomUUID().toString(), text)
        messages.update { it + item }
    }
}
@Qualifier
@Retention(AnnotationRetention.BINARY)
annotation class IoDispatcher

@Module
@InstallIn(SingletonComponent::class)
abstract class RepositoryModule {
    @Binds
    abstract fun chat(impl: InMemoryChatRepository): ChatRepository
}
@Module
@InstallIn(SingletonComponent::class)
object DispatcherModule {
    @Provides @IoDispatcher
    fun io(): CoroutineDispatcher = Dispatchers.IO
}

Set android:name to .PracticeApplication in the manifest. Add @AndroidEntryPoint to the Activity. Change the AF08 ViewModel to @HiltViewModel class ChatViewModel @Inject constructor(...), with the matching imports. Use the current Android Hilt ViewModel Compose integration in the route. The in-memory implementation is a warm-up; replace the binding with a Room-backed repository for offline practice.

A main-safe data source can inject @IoDispatcher CoroutineDispatcher to move blocking work with withContext. A local unit test can instantiate ChatViewModel(fake) directly. Use Hilt test replacement only when testing the actual DI integration; AF14 tests the stateless screen without the whole graph.

Primary references: Hilt on Android

Fundamentals lesson · original examples

Use runTest with one shared TestCoroutineScheduler. StandardTestDispatcher queues work until the test yields or runs the scheduler. advanceTimeBy moves virtual time; runCurrent executes tasks at the new boundary. advanceUntilIdle drains finite queued work. Delays on real IO/Default dispatchers are not controlled by virtual time, so inject dispatchers.

Replace Main before constructing a ViewModel and reset it afterward. stateIn with WhileSubscribed needs an active collector. Put never-ending collectors in backgroundScope so runTest cancels them. Assert final StateFlow values when testing state; use an explicitly collected event list or Turbine when emission order itself is the contract.

import java.io.IOException
import org.junit.Assert.*
import org.junit.Rule
import org.junit.Test
import org.junit.rules.TestWatcher
import org.junit.runner.Description
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.ExperimentalCoroutinesApi
import kotlinx.coroutines.delay
import kotlinx.coroutines.flow.*
import kotlinx.coroutines.launch
import kotlinx.coroutines.test.*

@OptIn(ExperimentalCoroutinesApi::class)
class MainDispatcherRule(
    val dispatcher: TestDispatcher = StandardTestDispatcher()
) : TestWatcher() {
    override fun starting(description: Description) { Dispatchers.setMain(dispatcher) }
    override fun finished(description: Description) { Dispatchers.resetMain() }
}
class FakeChatRepository : ChatRepository {
    val messages = MutableStateFlow<List<ChatMessage>>(emptyList())
    var calls = 0
    var fail = false
    override fun observeMessages(): Flow<List<ChatMessage>> = messages
    override suspend fun send(text: String) {
        calls++
        delay(1_000)
        if (fail) throw IOException("Offline")
        val item = ChatMessage("m$calls", text)
        messages.update { it + item }
    }
}
@OptIn(ExperimentalCoroutinesApi::class)
class ChatViewModelTest {
    @get:Rule val main = MainDispatcherRule()

    @Test fun blankInputDoesNotSend() = runTest {
        val repo = FakeChatRepository()
        val vm = ChatViewModel(repo)
        vm.onDraftChanged("   ")
        vm.onSend()
        runCurrent()
        assertEquals(0, repo.calls)
    }

    @Test fun duplicateTapSendsOnceAndPublishesResult() = runTest {
        val repo = FakeChatRepository()
        val vm = ChatViewModel(repo)
        backgroundScope.launch(UnconfinedTestDispatcher(testScheduler)) {
            vm.uiState.collect {}
        }
        vm.onDraftChanged("  ping  ")
        vm.onSend()
        vm.onSend()
        runCurrent()
        assertEquals(1, repo.calls)
        assertEquals(SendState.Sending, vm.uiState.value.send)
        advanceTimeBy(1_000)
        runCurrent()
        assertEquals(listOf(ChatMessage("m1", "ping")), vm.uiState.value.messages)
        assertEquals("", vm.uiState.value.draft)
        assertEquals(SendState.Idle, vm.uiState.value.send)
    }

    @Test fun failedSendPreservesDraftAndCanBeRetried() = runTest {
        val repo = FakeChatRepository().apply { fail = true }
        val vm = ChatViewModel(repo)
        backgroundScope.launch(UnconfinedTestDispatcher(testScheduler)) {
            vm.uiState.collect {}
        }
        vm.onDraftChanged("hello")
        vm.onSend()
        runCurrent()
        advanceTimeBy(1_000)
        runCurrent()
        assertEquals("hello", vm.uiState.value.draft)
        assertEquals(SendState.Failed, vm.uiState.value.send)
        assertTrue(vm.uiState.value.messages.isEmpty())
        repo.fail = false
        vm.onSend()
        runCurrent()
        advanceTimeBy(1_000)
        runCurrent()
        assertEquals(listOf(ChatMessage("m2", "hello")), vm.uiState.value.messages)
        assertEquals(SendState.Idle, vm.uiState.value.send)
    }

    @Test fun completedSendDoesNotEraseNewDraft() = runTest {
        val repo = FakeChatRepository()
        val vm = ChatViewModel(repo)
        backgroundScope.launch(UnconfinedTestDispatcher(testScheduler)) {
            vm.uiState.collect {}
        }
        vm.onDraftChanged("first")
        vm.onSend()
        runCurrent()
        vm.onDraftChanged("second")
        advanceTimeBy(1_000)
        runCurrent()
        assertEquals("second", vm.uiState.value.draft)
        assertEquals(listOf(ChatMessage("m1", "first")), vm.uiState.value.messages)
    }
}

These are original teaching tests for the AF08 slice. Run them in your Android project; they are not tests added to the existing downloadable apps.

import org.junit.Assert.*
import org.junit.Test
import kotlinx.coroutines.*
import kotlinx.coroutines.flow.*
import kotlinx.coroutines.test.*

@OptIn(ExperimentalCoroutinesApi::class)
class FlowFundamentalsTest {
    @Test fun coldFlowRunsPerCollector() = runTest {
        var starts = 0
        val stream = flow { emit(++starts) }
        assertEquals(1, stream.first())
        assertEquals(2, stream.first())
        assertEquals(2, starts)
    }

    @Test fun hotStateUpdatesWithoutCollectors() = runTest {
        val state = MutableStateFlow(1)
        state.value = 2
        assertEquals(2, state.first())
        assertEquals(2, state.first())
    }

    @Test fun broadcastWithoutReplayLosesUnobservedValue() = runTest {
        val events = MutableSharedFlow<String>(replay = 0)
        events.emit("before")
        val seen = mutableListOf<String>()
        backgroundScope.launch(UnconfinedTestDispatcher(testScheduler)) {
            events.collect { seen += it }
        }
        events.emit("after")
        assertEquals(listOf("after"), seen)
    }

    @Test fun sharedStateStartsOneUpstreamForTwoCollectors() = runTest {
        var starts = 0
        val state = flow {
            starts++
            emit(42)
            awaitCancellation()
        }.stateIn(backgroundScope, SharingStarted.WhileSubscribed(5_000), 0)
        assertEquals(0, state.value)
        assertEquals(0, starts)
        repeat(2) {
            backgroundScope.launch(UnconfinedTestDispatcher(testScheduler)) {
                state.collect {}
            }
        }
        runCurrent()
        assertEquals(42, state.value)
        assertEquals(1, starts)
    }

    @Test fun cancellationRunsCleanupAndPreventsDelayedWork() = runTest {
        var cleanedUp = false
        var replied = false
        val job = launch {
            try {
                delay(1_000)
                replied = true
            } finally {
                cleanedUp = true
            }
        }
        runCurrent()
        job.cancelAndJoin()
        advanceTimeBy(1_000)
        runCurrent()
        assertTrue(cleanedUp)
        assertFalse(replied)
    }
}

Five outcome-based tests for the stream and cancellation contracts. No Android framework dependency is required.

Add the hard cases in your own attempt

• Query race: arrange a slow first result and a faster second result; prove only the current query is shown.
• Cancellation: cancel a screen-owned job and prove it does not emit a user-visible failure.
• Sharing: two collectors must not start two upstream requests after stateIn/shareIn.
• Offline sync: retry the same operation ID after an interrupted acknowledgement and prove one logical server effect.
• Algorithm: test empty input, boundaries, repeated visits and simultaneous times for EP07.

Verified here: all nine published ChatViewModelTest and FlowFundamentalsTest methods compiled and passed on the JVM using the cached AndroidX ViewModel 2.8.7, coroutines 1.9.0 and JUnit 4.13.2 libraries. This is not an APK, device or UI test run.

Primary references: Testing Kotlin coroutines · Testing Kotlin flows

Fundamentals lesson · original examples

Test what a user sees and can do. Render a stateless screen with explicit state and fake callbacks for component coverage. Add a separate route/integration test with a fake repository to prove ViewModel state reaches the UI. Use semantic text, roles and stable tags; avoid coordinate taps and wall-clock sleeps.

import androidx.compose.material3.MaterialTheme
import androidx.compose.ui.test.*
import androidx.compose.ui.test.junit4.createComposeRule
import androidx.test.ext.junit.runners.AndroidJUnit4
import org.junit.Assert.assertEquals
import org.junit.Rule
import org.junit.Test
import org.junit.runner.RunWith

@RunWith(AndroidJUnit4::class)
class ChatScreenTest {
    @get:Rule val compose = createComposeRule()

    @Test fun displaysMessagesAndForwardsInput() {
        var typed = ""
        compose.setContent {
            MaterialTheme {
                ChatScreen(
                    ChatUiState(messages = listOf(ChatMessage("1", "ping"))),
                    onDraftChanged = { typed = it },
                    onSend = {}
                )
            }
        }
        compose.onNodeWithTag("message-1").assertTextEquals("ping")
        compose.onNodeWithTag("chat-send").assertIsNotEnabled()
        compose.onNodeWithTag("chat-input").performTextInput("hello")
        compose.runOnIdle { assertEquals("hello", typed) }
    }

    @Test fun enabledSendForwardsOneClick() {
        var sends = 0
        compose.setContent {
            MaterialTheme {
                ChatScreen(ChatUiState(draft = "hello"), {}, { sends++ })
            }
        }
        compose.onNodeWithTag("chat-send").assertIsEnabled().performClick()
        compose.runOnIdle { assertEquals(1, sends) }
    }

    @Test fun pendingSendIsDisabled() {
        compose.setContent {
            MaterialTheme {
                ChatScreen(ChatUiState(draft = "hello", send = SendState.Sending), {}, {})
            }
        }
        compose.onNodeWithTag("chat-send").assertIsNotEnabled()
    }

    @Test fun errorIsVisibleAndRetryIsAvailable() {
        compose.setContent {
            MaterialTheme {
                ChatScreen(ChatUiState(draft = "hello", send = SendState.Failed), {}, {})
            }
        }
        compose.onNodeWithTag("send-error").assertTextEquals("Send failed. Try again.")
        compose.onNodeWithTag("chat-send").assertIsEnabled()
    }
}

These tests intentionally supply fixed state; callback assertions do not prove the whole app updates. Add a route-level test with a fake repository for input -> send -> displayed reply.

Deterministic UI checks

• Compose synchronizes its own work. For external asynchronous work use a controlled fake and waitUntil for an observable condition.
• mainClock controls Compose frames/animations. It is separate from the kotlinx-coroutines-test scheduler. Do not advance one and assume the other advances.
• Verify loading, empty, retry, selection/detail/back, disabled actions, and accessibility semantics.
• Use an in-memory Room database for repository integration tests and persistent storage/relaunch coverage for offline requirements.
• Run ./gradlew :app:testDebugUnitTest, then ./gradlew :app:connectedDebugAndroidTest with an emulator/device. Adapt the task prefix for build flavors.

The four Compose UI tests are supplied for your practice project. They have not been executed on an emulator in this environment.

Primary references: Compose testing · Compose test APIs and semantics

Fundamentals lesson · original examples

fun positions(source: PositionSource): Flow<Position> = callbackFlow {
    val listener = object : PositionListener {
        override fun onPosition(value: Position) {
            // Position is replaceable snapshot data.
            trySend(value)
        }
        override fun onFailure(error: Throwable) { close(error) }
    }
    source.register(listener)
    awaitClose { source.unregister(listener) }
}.buffer(Channel.CONFLATED)

Design sketch with domain-specific PositionSource, PositionListener and Position. Import kotlinx.coroutines.channels.awaitClose and Channel plus flow APIs. Registration/unregistration must obey the SDK thread and concurrency contract. Conflation is deliberate for positions; use an explicit overflow/recovery policy for non-droppable messages.

callbackFlow is cold, so each collector registers its own listener unless you share the stream. awaitClose ties cleanup to cancellation. Handle trySend failure according to the data contract. For reliable messages, persist stable IDs and detect gaps; reconnect with a cursor and bounded backoff instead of assuming the socket delivered everything.

Problem-specific adapters

• EP10 video: one active player policy, release/stop at the owner lifecycle, track visible item by stable ID, pause offscreen media. Media3 is a useful implementation option.
• EP11 venues: request only the needed location permission, handle denied/approximate location, adapt the location source to Flow, cancel old venue queries. Do not prompt from recomposition.
• EP06 files: use URI/storage access contracts, map loading and permission failure, keep debug/release or flavor configuration explicit.
• EP01 images: use the picker contract, keep URI ownership clear, and store accessible image data when the feature must survive restart.
• EP09 hardware: separate desired, sent and acknowledged values. Sequence commands and reject stale replies according to the device revision contract.

Primary references: callbackFlow API · Media3 ExoPlayer · Location permissions

Fundamentals lesson · original examples

The goal is to finish a small feature and explain its failure behavior. Use this guide for the shared building blocks, then read the specific brief for algorithm, media, location or device rules. These lessons are a preparation plan, not a guarantee of the actual interview content.

Before calling an attempt complete

• State: one clear owner, immutable snapshots, explicit loading/empty/error/pending behavior.
• Concurrency: child lifetime, injected dispatchers where needed, cooperative cancellation, latest-read policy, write idempotency.
• Flow: cold/hot reasoning, sharing scope, replay/loss policy, lifecycle collection, upstream failure recovery.
• Storage: offline reads work after restart; pending writes are durable when required; local/server IDs reconcile.
• UI: stable IDs, useful semantics, back/navigation, no work launched from ordinary composition.
• Tests: one outcome-changing unit test and one visible UI behavior; extend to race/offline tests in the longer attempt.
• Delivery: run the feature and explain what is intentionally unfinished under the timebox.

Senior questions to answer aloud

• Why Flow instead of a suspend function here? When would you use each?
• What changes if two screens collect the same stream?
• What happens if the screen stops halfway through a send?
• How does stateIn handle a thrown exception and a later retry?
• Why does a StateFlow update fail to render when you mutated its list?
• Which values are safe to conflate? What cannot be dropped?
• How do you keep an old search result from replacing a new one?
• What survives process death, and how do you resume a pending write?
• How do you test WhileSubscribed state without a real delay?
• Where are Hilt dependencies scoped, and what changes in a fake-based test?
• Can a redraw happen without recomposition? Where did the state read occur?
• When does derivedStateOf help, and when is remember with input keys enough?
• What does strong skipping change about unstable parameters?

Primary references: Android architecture recommendations

Fundamentals lesson · original examples

Recomposition reruns affected composable code to update the UI description. Layout measures and places nodes. Drawing renders their content. A state change can invalidate just one phase. Recomposition does not mean the whole screen was measured or redrawn, and a redraw can happen without recomposition.

The point where value is read matters. Passing a State<T> or a provider lambda to a child can defer the read. Evaluating value in the parent first still subscribes that parent scope. A lambda only helps when the API invokes it in the later phase you intend.

import androidx.compose.foundation.background
import androidx.compose.foundation.layout.Box
import androidx.compose.foundation.layout.offset
import androidx.compose.foundation.layout.size
import androidx.compose.runtime.Composable
import androidx.compose.runtime.State
import androidx.compose.ui.Modifier
import androidx.compose.ui.draw.drawBehind
import androidx.compose.ui.graphics.Color
import androidx.compose.ui.unit.IntOffset
import androidx.compose.ui.unit.dp
import kotlin.math.roundToInt

@Composable
fun MovingMarker(positionPx: State<Float>, modifier: Modifier = Modifier) {
    Box(modifier.offset {
        IntOffset(positionPx.value.roundToInt(), 0)
    }.size(24.dp).background(Color.Green))
}

@Composable
fun TintMarker(tint: State<Color>, modifier: Modifier = Modifier) {
    Box(modifier.size(40.dp).drawBehind {
        drawRect(tint.value)
    })
}

positionPx is pixels. These examples deliberately avoid reading either value in composition. Supply remembered snapshot state and put the marker in a visible, size-constrained parent. They illustrate phase invalidation; device rendering has not been measured here.

Primary references: Compose rendering phases · Compose performance best practices

Fundamentals lesson · original examples

val visible = remember(nights, query) {
    nights.filter { it.date.contains(query, ignoreCase = true) }
}

This caches a pure calculation for these inputs. For a large list, do filtering in the ViewModel on the appropriate dispatcher. It does not move work to another thread.

val listState = rememberLazyListState()
val showJumpButton by remember(listState) {
    derivedStateOf { listState.firstVisibleItemIndex >= 3 }
}

Requires Compose runtime getValue/remember/derivedStateOf and foundation lazy rememberLazyListState imports. Use listState on the actual LazyColumn. The boolean changes less often than the underlying position.

val latestOnPastIntro by rememberUpdatedState(onPastIntro)
LaunchedEffect(listState) {
    snapshotFlow { listState.firstVisibleItemIndex >= 3 }
        .filter { it }
        .collect { latestOnPastIntro() }
}

Imports Compose runtime snapshotFlow, LaunchedEffect and rememberUpdatedState plus Flow filter/collect. onPastIntro is your callback. This reports each transition into the threshold while the effect is alive; it is not durable analytics. Use take(1) for a once-per-effect rule.

Stability affects whether unchanged parameters can allow skipping. Strong skipping is enabled by default with Kotlin 2.0.20 and later. Restartable composables can then be skipped even with unstable parameters. Stable parameters use equals; unstable ones use identity comparison. State invalidation can still require a rerun.

A val List<T> is read-only through that reference, not necessarily an immutable object. In-place mutation may be invisible to state observation. Publish new snapshots or use observable snapshot collections appropriately. @Stable and @Immutable promise contracts to the compiler; adding them does not repair mutable data. Verify your compiler configuration instead of applying old rules about lambdas or unstable inputs blindly.

Lazy lists and effect identity

• Use a stable unique key so remembered item state follows its item when rows move. contentType can help lazy-layout reuse for different row shapes; it serves a different purpose from identity.
• Store derived values with the right keys. A remembered sort with no items key can retain old data.
• Use LaunchedEffect(itemId) when selecting a new item should restart its work. Use DisposableEffect for listener or player cleanup.
• Keep expensive work and state writes out of ordinary composition. Composition can be repeated or abandoned; a println counter in the body is not a reliable frame metric.

Diagnose before optimizing

• Use Layout Inspector recomposition/skip counters to locate active areas. It shows composition activity, not a complete count of drawing or GPU work.
• Inspect Compose compiler stability/skippability reports when parameter behavior is unclear.
• Reproduce the actual interaction and use system tracing or profiler tools to identify main-thread, layout, drawing, allocation or media work.
• Assess performance on a representative device with a release or appropriate benchmark configuration; debug overhead can mislead.
• Change one suspected cause, then repeat the same interaction. A lower recomposition count alone does not prove a smoother app.

Hands-on Compose experiment

• Add a marker beside your sleep list. Use snapshot state to change its text, position and tint separately.
• First read the position in the composable body, then move the read into Modifier.offset { ... }. Observe which composition scopes restart.
• Move the tint read into drawBehind and compare the observed phase work.
• Type in search while inspecting list rows. Confirm stable item keys preserve per-row state during filtering/reordering.
• Explain the result using a state-read location and actual trace evidence, without promising a fixed recomposition count.

Primary references: Compose side effects and state tools · Strong skipping and parameter equality · Fix stability issues · Debug Compose with Layout Inspector · Diagnose stability with compiler reports · Compose performance measurement

Quora · 30-minute core; attachments and menus are extensions

Reconstructed from saved code. Saved Quora Android implementation. The original written prompt was not recovered.

Start with an empty conversation.
User: ping
After one second, bot: pong
User: hi
Bot: Hello!

Follow-ups after the core

• Delete one message through a long-press menu.
• Add image selection and render an attached image.
• Send ping twice consecutively. Explain whether each send creates a separate reply.
• Clear while a reply is pending. Define whether that reply can appear afterward.

Robinhood · 30-minute core

Adapted from interview guides. The saved 2024 Robinhood guides require UI, networking, parsing, and navigation. They do not specify this catalog.

Retrofit version of the template: 30-minute template, Part 2

Follow-up practice: Add and edit products

List: GET https://dummyjson.com/products?limit=20
Detail, if needed: GET https://dummyjson.com/products/{id}
Required fields: id, title, description, price.

If the service is unavailable, parse this sample locally and continue:
{
  "products": [
    {
      "id": 101,
      "title": "Demo lamp",
      "description": "A sample desk lamp.",
      "price": 24.5
    },
    {
      "id": 102,
      "title": "Demo blanket",
      "description": "A sample blanket.",
      "price": 39.0
    }
  ]
}

Follow-ups after the core

• Retain the selected product and list position after rotation.
• Add search without letting stale responses overwrite a newer query.

Original public resource: DummyJSON product API

Lyft · 30-minute core; longer app practice can take 60 to 90 minutes

Adapted from the Android guide. The saved 2022 Lyft guide describes a mini app followed by feature additions. This ride board is an original practice specification.

{
  "rides": [
    {
      "id": "R1",
      "passenger": "Alex",
      "pickup": "Union Station",
      "destination": "North Park",
      "etaMinutes": 4,
      "status": "requested"
    },
    {
      "id": "R2",
      "passenger": "Jamie",
      "pickup": "City Hall",
      "destination": "East Market",
      "etaMinutes": 2,
      "status": "requested"
    },
    {
      "id": "R3",
      "passenger": "Sam",
      "pickup": "West Library",
      "destination": "Union Station",
      "etaMinutes": 7,
      "status": "accepted"
    }
  ]
}

Follow-ups after the core

• Add search and sorting as EP04.
• Explain which client state would be provisional if a real server handled acceptance.

Lyft · 30-minute core

Adapted feature-addition practice. Original extension based on the feature-addition format in the saved Lyft guide.

{
  "rides": [
    {
      "id": "R1",
      "passenger": "Alex",
      "pickup": "Union Station",
      "destination": "North Park",
      "etaMinutes": 4,
      "status": "requested"
    },
    {
      "id": "R2",
      "passenger": "Jamie",
      "pickup": "City Hall",
      "destination": "East Market",
      "etaMinutes": 2,
      "status": "requested"
    },
    {
      "id": "R3",
      "passenger": "Sam",
      "pickup": "West Library",
      "destination": "Union Station",
      "etaMinutes": 7,
      "status": "accepted"
    }
  ]
}

Follow-ups after the core

• Debounce a remote search and prevent stale completions from replacing the latest results.
• Discuss local filtering versus backend filtering when the list becomes large.

Lyft · 30-minute core

Adapted feature-addition practice. Original persistence exercise based on the saved Lyft guide. This is not a recovered original task.

{
  "destinations": [
    {
      "id": "D1",
      "name": "Home",
      "address": "10 Sample Road"
    },
    {
      "id": "D2",
      "name": "Work",
      "address": "20 Sample Street"
    },
    {
      "id": "D3",
      "name": "Gym",
      "address": "30 Sample Avenue"
    }
  ]
}

Follow-ups after the core

• Add and delete custom destinations.
• Explain how local choices would merge with a remote account.

Dropbox · 30-minute app; 60-minute app and build-variants round

Adapted from screening questions. The saved Dropbox document has eight build-tool screening questions. Its debugging preparation project omits the actual task source.

{
  "files": [
    {
      "id": "F1",
      "name": "Sleep notes.txt",
      "type": "text",
      "sizeBytes": 2048
    },
    {
      "id": "F2",
      "name": "Room photo.jpg",
      "type": "image",
      "sizeBytes": 512000
    }
  ]
}

Follow-ups after the core

• Add a build-only CI workflow that assembles the app and runs lint.
• Explain how you would upgrade Gradle and plugins without interrupting other developers.
• Explain which build logic you would share across modules.

Company unconfirmed · 30-minute algorithm and minimal UI

Recovered algorithm prompt. Saved infection-simulator question handout. The company association is unconfirmed. Add the Android UI yourself.

{
  "visits": [
    [
      0,
      0,
      1,
      3
    ],
    [
      0,
      1,
      4,
      5
    ],
    [
      0,
      2,
      8,
      9
    ],
    [
      1,
      1,
      4,
      6
    ],
    [
      2,
      2,
      7,
      9
    ],
    [
      3,
      2,
      6,
      8
    ]
  ],
  "initiallyInfected": [
    1
  ],
  "expectedTotal": 3
}
User 1 infects user 0. User 0 later infects user 2. User 3 leaves before contact.

Follow-ups after the core

• Add an incubation period of K time units.
• Add recovery after X time units.
• Handle visit events as a stream instead of receiving the entire list.

Eight Sleep preparation · 30-minute core

Original role-focused practice. Original exercise for this interview preparation. The actual Eight Sleep task is unknown.

Short version to drill: 30-minute template, Part 1

{
  "nights": [
    {
      "id": "N1",
      "date": "2026-10-07",
      "durationMinutes": 435
    },
    {
      "id": "N2",
      "date": "2026-10-06",
      "durationMinutes": 400
    },
    {
      "id": "N3",
      "date": "2026-10-05",
      "durationMinutes": 480
    }
  ]
}
Support local response modes DATA, ERROR, and EMPTY. After an ERROR result, the next load returns DATA.

Follow-ups after the core

• Add refresh while retaining old content.
• Define which result wins if overlapping refreshes are allowed.

Eight Sleep preparation · 30-minute basic flow; 60-minute full race and reconnect behavior

Original role-focused practice. Original simulator exercise. Levels and revisions are teaching contracts, not Pod specifications.

Initial: desired=5, confirmed=5, revision=0, connected=true.
A request has id and level. A completion has id, level, and deviceRevision.
You control the demo delays, connection, and failure mode.
An old request can report newer device truth. Request ID and device revision have different roles.

Follow-ups after the core

• Explain cancellation when a physical command may already have been applied.
• Save only the draft through process recreation and reconcile device truth after reconnect.

Streamlabs · Published assignment suggests 2 to 3 hours; use 30 minutes for a first slice

Published hiring exercise. Published Streamlabs assignment. Start an empty project and use only the supplied data and assets.

Get videos.json, user.json, and the image assets from the linked Streamlabs repository. Import the data into your own project.

Follow-ups after the core

• For a 30-minute warm-up, finish one playable video and a basic profile first.
• Explain when inactive video playback stops and player resources are released.

Original public resource: Streamlabs original assignment and data

Wolt · 30-minute first slice; complete the full task in a longer practice session

Published hiring exercise. Published Wolt 2025 Android internship assignment. Its historical service availability is unconfirmed.

Use the API, coordinates, response fields, and assets in the linked Wolt README. If the historical API is unavailable, create two local venue responses in your own project and alternate them. Keep the same IDs for shared venues.

Follow-ups after the core

• Use 30 minutes to finish the list and favorite action, then add timed updates.
• Explain cancellation and stale results when location requests overlap.

Original public resource: Wolt original assignment, API, and coordinates

Architecture · original practice question

Answer aloud first, then show the script to compare.

State · original practice question

Answer aloud first, then show the script to compare.

Flow · original practice question

Answer aloud first, then show the script to compare.

Coroutines · original practice question

Answer aloud first, then show the script to compare.

Coroutines · original practice question

Answer aloud first, then show the script to compare.

Lifecycle · original practice question

Answer aloud first, then show the script to compare.

Compose · original practice question

Answer aloud first, then show the script to compare.

Compose · original practice question

Answer aloud first, then show the script to compare.

Compose · original practice question

Answer aloud first, then show the script to compare.

Lifecycle · original practice question

Answer aloud first, then show the script to compare.

Networking · original practice question

Answer aloud first, then show the script to compare.

Networking · original practice question

Answer aloud first, then show the script to compare.

Device · original practice question

Answer aloud first, then show the script to compare.

Device · original practice question

Answer aloud first, then show the script to compare.

Device · original practice question

Answer aloud first, then show the script to compare.

Offline · original practice question

Answer aloud first, then show the script to compare.

Testing · original practice question

Answer aloud first, then show the script to compare.

Testing · original practice question

Answer aloud first, then show the script to compare.

Performance · original practice question

Answer aloud first, then show the script to compare.

Product · original practice question

Answer aloud first, then show the script to compare.