Mobile Design Rounds
Follow-up roundAndroid3 min read

Follow-up round: the user changes the phone clock

. Drafted with AI assistance, then edited by Manuel. Based on the notifications screen case. Android and Compose only.

The setup

You designed a notifications screen in Jetpack Compose. One row is an album offer with a countdown: "2 days, 2 hours, 43 minutes and 5 seconds". The server sends the deadline.

The question

The interviewer asks: "The user opens Settings and moves the phone date forward by three days. What does the countdown show when they come back?"

Stop here and answer out loud for one minute.

A weak reply

"I compare the deadline with the current time, and I update it every second." This reads System.currentTimeMillis(). That is the wall clock, and the user or the network can change it. After the change, the card says the offer ended, or shows a number that is three days wrong. A second problem: a timer that only counts ticks in a composable also goes wrong when the app is in the background, because the ticks stop.

A strong reply

  • The deadline is data from the server. I never count down a number. Each tick I read a clock and subtract.
  • The clock is the server time from the last response, plus the time since then. I measure that gap with SystemClock.elapsedRealtime(). It counts from boot, including sleep, and the user cannot set it.
  • The wall clock change does not move this clock. The countdown shows the same value as before.
  • The timer only says "wake me near the next second". If a wake-up is late, the next reading is still right. I collect it only while the screen is started.

The twist many people miss

The interviewer asks: "The phone restarts, or the system kills your app. The user opens it again."

A good answer: the saved gap is gone. elapsedRealtime() starts again from zero after a restart, so an old anchor means nothing. I do not save the anchor on disk. I load the list again, and every response carries a new server time and a new anchor. The server also checks the deadline when the user taps Order. So the card only shows the time. It never decides if the offer is still valid.

Check yourself

  • Did you say the wall clock can jump, and name a clock that does not?
  • Did you say where the deadline lives and where the current time lives?
  • Did you cover the restart, where the anchor is lost?
  • Did you say the server has the final say on the offer?

Score your answer on the score sheet.

Go deeper

All follow-up rounds

Get the follow-up round by email

One short email each week. The cheat sheet comes with the first one.

You confirm your address first. Unsubscribe any time. Privacy.