Enter the Paging Library

The Paging library exists to provide greater developer control over exactly what gets loaded from a backing data store and when, handling things like:

• Performing smaller queries, to stay inside a CursorWindow’s bounds, so we can control the threads used for data loads
• Supporting multiple traversal options through a data set: not only classic position-based systems, but ones where you might be navigating a tree and need to retrieve related child objects as part of traversal
• Offering reactive approaches, based on LiveData, so we can ensure that our UI remains responsive.

The Paging library has evolved over the years. The current edition, known as Paging v3, has a powerful Kotlin-centric API, and Room has basic support for returning Paging v3-based responses from queries.

There are a number of classes involved in the Paging library, but for basic scenarios, there are a few of significance:

• A PagingSource represents a source of paged data. Room can be set up to return a PagingSource from a @Query-annotated @Dao function, for example.
• A PagingData represents a chunk of data retrieved from the underlying data source via the PagingSource
• A Pager represents a specific operation for getting paged data out of a PagingSource. We can teach a Pager how many items to retrieve in a “page”, and the Pager gives us a Flow, LiveData, or similar reactive API for getting PagingData objects as needed.
• A PagingDataAdapter is a RecyclerView.Adapter that knows how to work with a PagingData. As the user scrolls the RecyclerView, the PagingDataAdapter can signal that we need more data, triggering the Pager to fetch more data from the PagingSource and emit a fresh PagingData for the PagingDataAdapter to use.

That still leaves a lot of moving parts, which we will examine in greater detail in this chapter.