Question 4
Pagination and large feeds
You're building a feed that loads large amounts of data. How do you handle pagination and ensure smooth performance?
Answer outline
Load the feed in pages, and request the next page before the user reaches the end. That keeps each request small and the scroll view responsive.
Prefer cursor-based pagination for feeds. Instead of asking for items 21 to 40 by offset, the client asks for the next 20 items after a position. The server returns a cursor, an opaque token that the client never interprets and sends back unchanged on the next request.
This beats offset-based pagination because a feed changes constantly. A cursor means 'continue from here' rather than 'start at item 20', so new insertions don't shift or duplicate what the client receives.
On the UI side, send that next-page request a few screens before the end, since the last row is too late. Keep a single pagination state (idle, loading, exhausted) so a fast scroll can't request the same page twice. Scrolling stays smooth when cell configuration is cheap, images decode off the main thread, and only changed rows are updated.
Principles
- Prefer cursor-based pagination for feeds because it stays stable when items are inserted or deleted, unlike offsets.
- Prefetch the next page before the user reaches the end so there are no loading gaps.
- Track explicit pagination state (idle, loading, exhausted) so overlapping requests can't fire.
- Cell configuration runs on the main thread mid-scroll, so keep it cheap, decode and cache images elsewhere, and reload only changed rows.
- Watch memory as the feed grows, and release off-screen data or cap the number of pages held.
