Design a notifications screen in Jetpack Compose (Android)

Build it. The Kotlin code, the JSON, the tests and the strings are on a separate page: Build it: a notifications screen in Jetpack Compose.

How to read this. This page is the 45 minutes, in the order I would talk in an interview: ask, state assumptions, model the data, design the screen, go deep on the countdown, handle state and the server, then failures, tests and trade-offs. It is Android and Jetpack Compose only. It uses a travel app as the example. It builds on the news feed case. The follow-up questions are my reconstruction from public prep material, not transcripts of real rounds.

By the end you can:

• Split what you can see on a screen from what you must ask.
• Choose a data model for rows that look different, and say why.
• Explain why a countdown needs a clock and not a counter, and which clock.
• Say exactly which Compose code runs on every tick, and how to keep that small.
• Handle Accept and Decline when the server is slow, wrong, or gone.

Read section 4 twice. Most answers stop at a timer in a LaunchedEffect.

TL;DR. My answer in four lines:

• Data. A sealed type with three row types in one LazyColumn, with stable keys and a content type. The server sends facts and times. The phone writes the words.
• Time. The deadline is data. Time comes from a clock object: the server time of the last response plus elapsedRealtime(). A Flow wakes when the shown second changes, and runs only while the screen is started.
• Compose. The tick is read in two small leaves: the text, and a draw lambda for a bar. The card reads only a derived "expired" flag.
• Actions. Accept and Decline are optimistic, with an overlay in the ViewModel, one request per row, and a rollback with a message.

Patterns in this round.

• State machine (a friend request moves through a short list of states)
• Repository (parsing, clock sync and the order of calls in one place)
• Idempotency key (when an action creates something, the key survives a restart)

More in design patterns in mobile rounds.

1. Scope and constraints (minutes 0 to 5)

In short: A list with three kinds of rows. One row has a clock in it, and one row has buttons. I read the screen first, then I ask.

A prompt I would expect: "Here is a screenshot of a notifications screen in a travel app. Design how you would build it." There is no spec. So I split what I can see from what I must guess.

Now the requirements, in the five groups the prompt asks for. The last column says where each one comes from.

Unknown things I would ask about, each with the default I take if the interviewer says "your call":

Your decision. The interviewer asks: "Should the list work offline? Put it in Room." Room is the Android library for a local database. Do you say yes?

First idea, and why it fails. Yes, every list gets a database. But this list is made of things that go stale in minutes: an offer that ends, a friend request that can be withdrawn. A cached copy shows exactly the wrong thing. It also adds migrations and a second source of truth.

What I would say. Memory only for now. The list reloads when the screen opens and on pull to refresh. If the interviewer wants offline reading, I add Room as the source of truth and mark old offers and requests as unconfirmed.

Say this. "Three row types, one list, in the order the server sends. I will treat the countdown as a clock problem. The server decides when the offer ends, and the phone only shows it. I assume Android and Compose, no offline database, and I will tell you when an assumption matters."

The follow-up question I expect: "Why not just ask the server for the text, like the "12 minutes ago"?"

Because that text is wrong one minute later. The server sends a time. The phone makes the words. The same is true for "2 days, 2 hours" on the offer.

2. Data and contracts (minutes 5 to 13)

In short: One sealed type with three subtypes. Times are numbers, never text. "Expired" is computed from the time, never stored.

2.1 One type or many (minutes 5 to 9)

The three rows share an ID and a time. Everything else differs. These are the options I weigh:

Two layers use this. The wire format is a DTO (data transfer object: the class that matches the JSON). It must survive a new type from a newer server: an unknown type becomes an Unknown item and is skipped, so the screen does not crash. The app model is the sealed type above. Mapping happens once, in the repository.

2.2 The fields (minutes 9 to 12)

Stable identity and time:

• id is a string and unique across all types, for example pa_881, offer_12, fr_40. If the server only makes IDs unique per type, the key is type:id. I ask.
• If the server groups people ("Ana and 2 others"), the group ID must stay the same when a third person joins. If it changes, the row looks new: it fades out and a new one fades in.
• Times are epoch milliseconds in UTC. Never text like "12 minutes ago". The words are made on the phone from now - createdAtMs. If the result is negative, I show "Just now".
• The phone never sorts by time. The offer has no natural place in time order, so the server order is the order.

Your decision. The offer might come from its own endpoint. The client could put it at position 2. Is that fine?

First idea, and why it fails. Hard-code the position. Quick, but placement, experiments and frequency limits are server rules. A fixed index copies those rules into the app and drifts. With paging it also breaks: what is "position 2" on page 3?

What I would say. I assume one endpoint, in display order. If the interviewer says the offer is separate, the repository merges it with one pure function merge(feed, offer) and the rule lives in one place. The UI model does not change.

2.3 The calls (minutes 12 to 13)

JSON, DTOs and the unknown-type fallback are in the build guide.

3. Client structure (minutes 13 to 21)

In short: One LazyColumn. A stateless screen, a ViewModel for the state, a repository for the server. A clock object that has no UI.

3.1 Who owns what (minutes 13 to 17)

What I do not add, and why:

• Use cases. Each would be one line that calls the repository.
• A database. Section 1 says why.
• Paging 3. One page of 30 rows. It enters if the list grows (section 6).
• A separate UI model. The sealed domain type is what the rows need. I copy it only for the in-flight overlay, in one place, in the ViewModel.

3.2 The list (minutes 17 to 21)

The list code is short. Two arguments matter:

LazyColumn(state = listState, contentPadding = PaddingValues(16.dp),
    verticalArrangement = Arrangement.spacedBy(12.dp)) {
    items(items = items, key = { it.id }, contentType = { it::class }) { item ->
        when (item) {
            is PhotoActivity -> PhotoActivityRow(item, minuteNow, { onAlbumClick(item.albumId) }, Modifier.animateItem())
            is AlbumOffer    -> OfferCard(item, clock, { onOfferClick(item.id) }, Modifier.animateItem())
            is FriendRequest -> FriendRequestRow(item, minuteNow, onAccept, onDecline, Modifier.animateItem())
        }
    }
}

• key = { it.id } gives each row an identity (a stable key). The state of a row, and the scroll position, follow the ID when rows move or arrive. The Android docs say a stable key keeps item state the same across data changes.
• contentType lets Compose reuse the composition of a row only for rows of the same type. The docs say reuse works between items of the same type. The offer card is very different from an avatar row, so this matters.
• animateItem() animates arrival, removal and moves. It exists from Compose Foundation 1.7.
• Row models are @Immutable. A List<Actor> inside a class makes the Compose compiler treat it as unstable unless you say otherwise. With strong skipping (the default since Kotlin 2.0.20) unstable parameters are compared by instance, stable ones with equals. I want equals, so a refresh that returns equal rows does not redraw them.
• Images: avatars at the size on screen (40 dp), not the original file. Use the image library the app already has.

3.3 When the list changes

I checked the first row in a test on Compose 1.7 (desktop). A list scrolled to the very top kept the old first row on screen when I put a row above it. The official pages I read do not say this, so I test it in the app before I rely on it.

4. Make the hard part work (minutes 21 to 38)

In short: A deadline is a clock problem. A counter counts ticks and a clock tells the time, so the value always comes from a clock. Then I read that value in the smallest place that needs it.

4.1 What is unknown (minutes 21 to 23)

4.2 Pick the time source and the ticker (minutes 23 to 28)

Five ways to drive a countdown:

Your decision. The deadline is 2 days away. What do you do each second?

First idea, and why it fails. Subtract one second from a number in the ViewModel. After the app is stopped for a minute the number is a minute late, and nothing can repair it.

What I would say. I store the deadline once. Each wake-up I read a clock and subtract. If a wake-up is late, the next reading is still right. The timer only says "wake me about then".

Which clock? The Android reference for SystemClock says System.currentTimeMillis() is the wall clock, which "can be set by the user or the phone network" and can jump. elapsedRealtime() counts time since boot, including sleep, so it works as a monotonic clock here. So:

• Server time estimate = the server time of the last response + the time since then, measured with elapsedRealtime().
• The user can move the wall clock by hours and this number does not move.
• The estimate runs behind by about one trip from the server to the phone, because the server stamped the time before the response travelled. So the card shows a little more time than there is. A careful version adds half of the round trip. The server checks again at order time, so I accept this error. I only use fresh responses, not cached ones, and a new response can move the display by the jitter between two trips.
• On this screen an offer is only drawn after a response, so the anchor already exists. The wall clock fallback matters only if you show cached rows before the first response. Then the number may jump once.
• After a process restart the anchor is gone. The first response sets it again.

class AnchoredServerClock(
    private val elapsedRealtimeMs: () -> Long,  // { SystemClock.elapsedRealtime() }
    private val wallClockMs: () -> Long = { System.currentTimeMillis() },
) : ServerClock {
    private class Anchor(val serverMs: Long, val elapsedMs: Long)
    @Volatile private var anchor: Anchor? = null

    fun sync(serverNowMs: Long) { anchor = Anchor(serverNowMs, elapsedRealtimeMs()) }

    override fun nowMs(): Long {
        val a = anchor ?: return wallClockMs()
        return a.serverMs + (elapsedRealtimeMs() - a.elapsedMs)
    }
}

The ticker wakes when the shown second changes, not every 1000 ms. The displayed value rounds up, so it reaches zero when the offer ends:

fun ServerClock.countdownTicks(deadlineMs: Long): Flow<Long> = flow {
    while (true) {
        val now = nowMs()
        emit(now)
        val remaining = deadlineMs - now
        if (remaining <= 0) return@flow            // expired: one last value, then stop
        val toNextSecond = remaining % 1_000L
        delay(if (toNextSecond == 0L) 1_000L else toNextSecond)
    }
}

From my test, a deadline 3400 ms away with a fake clock. The delay is not a constant, and the flow ends by itself:

• Missed ticks. I jumped the fake clock 30 s forward in a test. The next reading showed the right value at once. Nothing is counted, so nothing is lost.
• Lifecycle. collectAsStateWithLifecycle collects only while the lifecycle is at least STARTED, and starts the Flow again when it returns. The first value of the new Flow is a fresh reading. In a test, a stopped lifecycle made no clock reads at all.
• Scrolled off screen. A lazy row that is scrolled far away leaves the composition, so its collector stops. A test with 60 rows showed no clock reads while the card was away, and reads again when it came back.
• Expired. The Flow ends after the deadline. Another test shows no clock reads after expiry.
• Device clock changed. Not visible to the countdown. A test moves the wall clock back one hour and the server time does not move.
• New deadline. If the server extends the offer, the deadline in the model changes. The Flow is remembered with the deadline as a key, so a new Flow starts.

4.3 Where each piece lives (minutes 28 to 30)

4.4 What recomposes on each tick (minutes 30 to 34)

Compose has three phases: composition (run the composable code), layout (measure and place) and draw. Reading a State in a phase subscribes that phase to it, and a change makes that phase run again. Running composition again is called recomposition. The performance docs call this deferring reads: a read inside a layout or draw lambda lets Compose skip composition, and a read in a draw lambda lets it skip layout too.

@Composable
fun OfferCard(offer: AlbumOffer, clock: ServerClock, onOrderClick: () -> Unit, modifier: Modifier = Modifier) {
    val now = rememberCountdownNow(clock, offer.expiresAtMs)            // a State<Long>, NOT read here
    val expired by remember(offer.expiresAtMs) { derivedStateOf { now.value >= offer.expiresAtMs } }
    Card(modifier.fillMaxWidth()) {
        Column(Modifier.padding(16.dp), verticalArrangement = Arrangement.spacedBy(8.dp)) {
            // image, title and body
            if (expired) Text(stringResource(R.string.offer_ended))
            else { CountdownText(offer.expiresAtMs, now); Button(onClick = onOrderClick) { Text(offer.ctaLabel) } }
        }
    }
}

What I measured in tests (Compose 1.7.3 on the desktop JVM, a stand-in image composable that counts how often it runs, a fake clock):

• Three ticks: the card image was composed the same number of times before and after. The photo row next to it did not change either. The text did.
• The same card with the read moved into the card body: one more composition per tick.
• A bar that reads the tick in drawBehind: no composition and no measure after five seconds of ticks, and more than four draws.
• Expiry: the card ran once more when it flipped to "ended", the order button left, and the ticker stopped.

Honest limits:

• This is not "the card never recomposes". It recomposes when its own parameters change, when it reads other state, or when its parent passes new values. I only moved the per-second reads out of it.
• A text of a different width can make its parent measure again. Tabular figures (fontFeatureSettings = "tnum") keep digits the same width. I did not measure the layout cost of this.
• These numbers come from a desktop test, not from a phone. I still profile on a device (section 5).
• Accessibility. The Compose docs say not to use live regions on content that updates often, such as countdown timers. So the text is not a live region. A screen reader reads it when focused. I can give it a rougher description ("about 2 days") that changes only each minute.

Say this. "The tick never goes into the ViewModel or the list state. It lives in the card, as a State that is read in two small leaves: the text and the bar. The card itself reads only a derived boolean, so it runs again once, when the offer ends."

The follow-up question I expect: "What if there are five countdowns on the screen?"

Share the clock, not the tick: one ServerClock for the app, and each card keeps its own aligned flow. If five wake-ups a second is too much, share one ticker at about 250 ms with stateIn(appScope, SharingStarted.WhileSubscribed(5_000)) and read it through derivedStateOf. A fixed 1 s shared tick is not aligned to each deadline, so a shown second can lag by up to 1 s, and the Order button can stay up for 1 s after the end. Pick the cost you can explain.

4.5 Accept and Decline (minutes 34 to 38)

Your decision. Do you show the result before the server answers (optimistic), or wait?

First idea, and why it fails. Wait, with a spinner, because it is simpler to reason about. But Accept succeeds almost every time and a spinner on every tap feels slow. Optimistic without a rollback plan is worse: the row says "friends" and the server said no.

What I would say. Optimistic, with an explicit overlay. The server status stays in the repository. What the user did is a separate in-flight map in the ViewModel. The UI is server status plus overlay. On failure I drop the overlay and the old state comes back. I would switch to waiting if the action had a cost the user cannot see failing, such as a payment.

• Double tap. The ViewModel checks the map first, so two taps in one frame send one request. A test sends three taps and counts one call. The guard lives as long as the ViewModel. After process death or a new ViewModel it is empty, and the server must treat a repeat as safe.
• Leaving the screen. The call runs in the app scope, so a tap that was sent is not cancelled when the ViewModel is cleared. The refresh runs there too, so a cleared ViewModel cannot leave the repository stuck in "refreshing".
• The answer is lost. A timeout does not mean the server said no. The call may have worked. So a timeout or a 409 is "unknown": the screen says "Could not confirm" and refreshes, and the row shows what the server holds. Only a clear 5xx rolls back with "Try again". An unknown status string is treated the same way, never as a Decline.
• Refresh at the same time. A slow refresh that started before the tap could bring back "Pending" after "Accepted". The repository lets a refresh and a respond take turns. In a test, a slow refresh and an Accept ended in Accepted.
• Token expires. The HTTP layer refreshes the token and retries the same call once. Accept is a state change, so a repeat is safe. If the refresh fails, the user goes to sign-in and the overlay is cleared.
• App killed after the tap. The overlay is lost. The server either got it or not, and the next load shows the truth. I do not add an outbox: Accepts are rare, and a late silent Accept would surprise people.
• If the call creates something (not a state change), I send an idempotency key. If I keep the action across restarts, I save the key with the action and send the same key after the restart. A new key after relaunch would make a duplicate.

5. Break it, ship it, roll it back (minutes 38 to 45)

In short: Every failure ends in a correct clock, a row that comes back, or a row that leaves with a message. A wrong state can show for a moment, but the next refresh fixes it.

5.1 Tests that matter

Everything above the last row ran in my own test setup: 27 tests on Compose 1.7.3 on the desktop JVM, with stand-ins for the Android image library and string resources. None ran on a phone. Not covered by any test: the token refresh (it lives in the HTTP layer), a bad row inside a known type (it fails the whole refresh, and the old list stays), and screen reader behaviour. The test code is in the build guide.

5.2 Ship it and roll it back

• Rollout. A staged release. The new card is behind a remote flag, with the old static card as the fallback.
• What I watch. Jank rate while scrolling (JankStats), crash-free sessions, the share of Order taps that the server rejects as ended (it tells me how wrong the clock is), the time from open to first rows.
• Guardrail. Rejected-as-ended must not go up. If it does, the clock is wrong somewhere, and I do not "fix" it by trusting the device clock.
• Rollback. Turn the flag off. The data model and the repository do not change between the two versions.

6. Follow-ups that change a constraint

In short: Each follow-up changes one constraint. A strong answer says what breaks and what stays.

1. A second countdown appears on another row type. Strong: share the clock for the app, and keep one aligned flow per countdown. If wake-ups matter, one shared ticker at about 250 ms with stateIn(appScope, WhileSubscribed(5_000)), read through derivedStateOf. Weak: "Add another timer."
2. The offer is also shown on the home screen. Strong: the clock object is already app-wide. Only the ticker moves up. The card stays the same. Weak: "Copy the card."
3. The server extends the offer by one hour. Strong: the deadline is data. A refresh or a push replaces expiresAtMs, the remembered Flow has the deadline as a key, so a new one starts. An ended card must be able to come back to a live card. Weak: "Restart the app."
4. Users say the countdown is 3 seconds off. Strong: 3 seconds is more than one network trip, so look for a cached response used as an anchor, a CDN Age header, or an anchor set long after the response arrived. Add half of the round trip, never anchor on cached responses, and compare with the rate of "ended" rejections. Weak: "Use the device clock."
5. The list must work offline for days. Strong: Room as the source of truth, and the last anchor saved with the wall time and the boot count. After a reboot or a wall clock change, the saved anchor is not valid, so mark the countdown as approximate until a response arrives. The server still decides. Weak: "Cache the JSON."
6. The list has thousands of rows. Strong: cursor paging with Paging 3, keys stay, and Room as the source of truth. The clock and the card do not change. Weak: "Load them all."
7. Product wants rows grouped on the phone. Strong: no. The server groups. Rows keep stable IDs when a group grows. If it must be on the phone, a pure function with tests. Weak: "Group inside the composable."
8. Product wants read and unread. Strong: it is server state and a badge count. Mark as read when the row has been on screen for a moment. It is its own case. Weak: "A boolean on the row."

7. What changes by level

In short: As I read it, levels differ in who finds the hard part: the interviewer, the candidate, or the candidate with a plan.

These levels are my own reading. They are not any company's scoring guide.

Trade-offs in one table, for the last two minutes of the round:

Staff answer: the decision and the rollout

• Decision: one ServerClock and one ticker module for the app. Every countdown and every "ago" label uses it.
• Alternative: each screen owns a timer. It ships faster, but every screen has its own drift and its own battery cost.
• Revisit trigger: a screen that needs sub-second updates, or a platform rule that limits wake-ups.
• Rollout: the new card behind a remote flag, then a staged release. Compare jank, crash-free sessions and rejected-as-ended on matched groups.
• Guardrail: none of those may get worse than with the static card.
• Rollback: turn the flag off.

Common weak answers. A timer that counts down a number. A while (true) loop in each card. Reading the tick in the card body. Storing "isExpired" in the model. No lifecycle check, so the timer runs in the background. A server sentence for "12 minutes ago". A second tap that sends a second request. They are not data from a study.

Test yourself

In short: Ten questions from this case. Answer each one out loud first, then open the answer.

Further reading (official docs)

• Build it: a notifications screen in Jetpack Compose: the Kotlin code and tests for this case
• Compose performance best practices: defer reads, lazy layout keys
• Lists and grids in Compose: keys, contentType, animateItem
• Strong skipping mode
• Side-effects in Compose: LaunchedEffect, derivedStateOf
• Collect flows safely in the UI: collectAsStateWithLifecycle, WhileSubscribed(5000)
• SystemClock: elapsedRealtime, uptimeMillis
• Test time in Compose and MainTestClock
• Semantics and live regions
• Arrangement.spacedBy: a negative space makes children overlap

Keep reading

• Build it: a notifications screen in Jetpack Compose
  The Kotlin code, JSON, strings and tests behind this answer.
• Design a news feed
  Paging, optimistic writes, and keeping the cache fresh.
• Design a stock ticker app
  Streaming updates and limiting how often the screen changes.
• Design a hotel or ride booking app
  Holds, server time and payments: another deadline that the server owns.
• Guide: idempotency keys
  How a key makes a repeated request count once.