android-paging-offline-synclisted

# Android Paging and Offline Sync ## Core Principles - Use paging when datasets are large enough that loading everything at once is wasteful. - Prefer database-backed paging for offline-first or cache-aware experiences. - Keep pagination logic in the data layer. - UI renders paged state; it does not own page bookkeeping. - Remote and local sources should cooperate through a clear sync strategy. --- ## When Paging Is Worth It Good fits: - long feeds - search results with many items - media catalogs - server-driven lists with page/cursor APIs Bad fits: - tiny lists that always fit in memory - static settings screens - datasets where pagination adds complexity without benefit --- ## Recommended Architecture For robust paging, prefer: ```text network API <-> RemoteMediator / paging source <-> Room <-> Pager <-> ViewModel <-> Compose UI ``` This keeps Room as the source of truth while the mediator keeps data fresh. See the **android-room-database**, **android-data-layer**, and **android-coroutines-flow** skills. --- ## Repository Contract Expose paging from the repository/data layer, not from UI code: ```kotlin interface NoteRepository { fun observePagedNotes(): Flow<PagingData<Note>> } ``` Or expose UI-ready models from the `ViewModel` when mapping belongs there: ```kotlin val notes: Flow<PagingData<NoteUi>> = repository .observePagedNotes() .map { pagingData -> pagingData.map { it.toNoteUi() } } ``` --- ## PagingSource vs RemoteMediator ### `Pagi