Weather App

Decouple what we render from whether we refresh. We always render the cached forecast immediately, whatever its age, and we separately decide whether to kick off a background refresh. The TTL no longer gates rendering; it only gates the refresh.

fun observeForecast(locationKey: String): Flow<Forecast> = flow {
  forecastDao.get(locationKey)?.let { emit(it.toForecast()) }   // instant, any age
  if (isStale(locationKey) && online()) {
    val fresh = api.getForecast(lat, lon)
    forecastDao.upsert(fresh.toCached(locationKey))             // Flow re-emits fresh
  }
}

Because the UI observes the Room table as a Flow, the refresh doesn't need a callback into the view - writing the new row re-emits, and the screen swaps from stale to fresh on its own. The user sees a forecast in the first frame; if it was stale, it quietly updates a moment later. Offline, the refresh is skipped and the cached value simply stays - the honest-offline dive below handles how the screen says so.

This is the standard cache pattern; libraries like OkHttp's response cache and Store implement the same stale-while-revalidate shape. The seam is worth stating outright: render and revalidate are two independent decisions over one cached row.

lastLocation can be null - a fresh boot, location services off, a device that's never been located - and the permission can be flat-out denied. A staff answer treats "no location" as a normal state, not an error. When we can't resolve a position, we fall back to a saved or default city the user can set, and the app stays fully useful: it's a weather app for a place, just not an auto-detected one.

So location resolution is a tiered fallback: lastLocation -> fresh getCurrentLocation -> saved city. Each tier is the previous one's failure handler, and the bottom tier never fails, so the screen always has coordinates to fetch. Permission denial routes straight to the saved-city tier and surfaces a quiet "set your location" affordance rather than an error screen.

Drive the screen off a discriminated UiState that distinguishes the cases the user must tell apart: live-and-fresh, showing-cached-while-refreshing, and offline-with-cache. The rule that ties it together: a spinner means "work is happening, wait for it." Offline, no work is happening, so a spinner is a lie - we show the cached forecast with an offline banner and the "last updated" time instead.

sealed interface UiState {
  data class Live(val forecast: Forecast) : UiState           // fresh, online
  data class Cached(val forecast: Forecast, val refreshing: Boolean) : UiState
  data class Offline(val forecast: Forecast) : UiState         // cached, no network
  data object Empty : UiState                                  // no cache, no network
}

Each state renders a different truth: Live shows the forecast plainly, Cached shows it with a quiet refresh indicator, Offline shows it with a banner and the age, and the rare Empty (first run with no network and no cache) is the only honest place for an empty state with a retry. The spinner appears only when a fetch is genuinely in flight - on first load or a pull-to-refresh - never as a stand-in for "we don't know."

A bare periodic job still wakes on a dead network and wastes a fetch, and it forgets the surface that benefits most from background freshness. Two refinements. Constraints: gate the worker on NetworkType.CONNECTED (and optionally battery-not-low) so it only runs when it can actually succeed, instead of spinning up the radio to fail. The widget: the same worker that writes the Room cache also pushes the new forecast to a home-screen widget, so the glanceable surface is fresh without the app ever being opened.

val refresh = PeriodicWorkRequestBuilder<RefreshWorker>(3, TimeUnit.HOURS)
  .setConstraints(
    Constraints.Builder()
      .setRequiredNetworkType(NetworkType.CONNECTED)
      .setRequiresBatteryNotLow(true)
      .build())
  .build()

The worker's body is the same RefreshForecast the foreground uses - resolve location, fetch, write Room - so the cache has exactly one writer path whether the trigger is an open, a pull, or the scheduler. The open app picks up the worker's write through the same observed Flow; nothing special connects them.