Paging 3 Interview Questions
ARCHITECTURE › Components
When would you reach for Paging 3 versus just a simple 'load next page on scroll' manual implementation backed by a MutableList? What does Paging 3 actually buy you?
What a strong answer covers: Paging 3 buys memory-bounded windowed loading, built-in de-duplication of in-flight requests, structured LoadState for loading and error UI with retry, placeholders, cachedIn to survive config changes, and RemoteMediator for wiring an offline cache to the network. A hand-rolled 'load more' approach is fine for a small, simple list, but it tends to reimplement prefetch distance, cancellation, and error handling poorly; the trap is reaching for full Paging 3 machinery for a tiny static list that never needs any of that.
A user taps 'like' on an item in a paged list. Walk me through how you'd update that single item's state in the UI without triggering a full page reload or losing scroll position.
What a strong answer covers: Because PagingData is a stream of immutable snapshots, you generally don't mutate an item in place; the idiomatic fix is to make the local database the source of truth for that flag, update the row there, and let the Room-backed PagingSource's invalidation mechanism re-emit the affected page automatically, or alternatively apply a .map transform on the PagingData flow to overlay UI-only state without touching the DB. The trap is calling refresh() after every like tap, which reloads from the start and visibly jumps the user's scroll position.
How do you test a PagingSource or RemoteMediator in isolation, without standing up a real Room database or network layer?
What a strong answer covers: You call pagingSource.load() directly with hand-built LoadParams against a fake data provider (or use the androidx.paging:paging-testing library's TestPager) and assert the returned LoadResult.Page contents and keys, and similarly invoke a RemoteMediator's load() with fake API and DAO fakes to assert the returned MediatorResult. The trap is trying to test through the full Pager and Flow<PagingData> collection pipeline, which is slow, indirect, and harder to pin down than exercising load() directly.