오프라인 우선 캐싱 전략

An offline-first app shows saved data immediately, even with no signal, then quietly refreshes when the network returns. 📶

The UI always reads from Room, never the network directly. The local database is the one thing the screen ever observes.

On launch you read the cached rows, so the screen fills instantly while any fresh fetch happens in the background.

When the network responds, the repository writes results into Room. The query Flow emits and the UI updates by itself.

Composables observe Room only. Networking just updates the cache, keeping a single, predictable data path.

If a fetch fails, you simply keep the cached data on screen and surface a gentle message instead of an empty error page.

Refresh on screen open, on pull-to-refresh, or when data is stale. Store a timestamp to know how old the cache is.

Use OnConflictStrategy.REPLACE so re-fetching the same ids updates existing rows instead of creating duplicates.

Edits made offline are saved locally first, then pushed to the server once the connection returns. The user never waits.

Network in, Room as truth, UI out: this simple loop makes caching predictable and your app resilient to flaky connections.

Because the screen depends only on the cache, your app feels fast and stays usable whether the user is online or not.

In an offline-first app, where does the Compose UI read its data from?

You made Room the source of truth, served the cache first, and synced the network in the background. That is a robust, snappy app done right.