ContentPager

class ContentPager

ContentPager provides support for loading "paged" data on a background thread using the ContentResolver framework. This provides an effective compatibility layer for the ContentResolver "paging" support added in Android O. Those Android O changes, like this class, help reduce or eliminate the occurrence of expensive inter-process shared memory operations (aka "CursorWindow swaps") happening on the UI thread when working with remote providers.

The list of terms used in this document:

• "The provider" is a android.content.ContentProvider supplying data identified by a specific content Uri. A provider is the source of data, and for the sake of this documents, the provider resides in a remote process.
• "supports paging" A provider supports paging when it returns a pre-paged Cursor that honors the paging contract. See @link ContentResolver#QUERY_ARG_OFFSET} and QUERY_ARG_LIMIT for details on the contract.
• "CursorWindow swaps" The process by which new data is loaded into a shared memory via a CursorWindow instance. This is a prominent contributor to UI jank in applications that use Cursor as backing data for UI elements like RecyclerView.

Details

Data will be loaded from a content uri in one of two ways, depending on the runtime environment and if the provider supports paging.

• If the system is Android O and greater and the provider supports paging, the Cursor will be returned, effectively unmodified, to a ContentCallback supplied by your application.
• If the system is less than Android O or the provider does not support paging, the loader will fetch an unpaged Cursor from the provider. The unpaged Cursor will be held by the ContentPager, and data will be copied into a new cursor in a background thread. The new cursor will be returned to a ContentCallback supplied by your application.

In either cases, when an application employs this library it can generally assume that there will be no CursorWindow swap. But picking the right limit for records can help reduce or even eliminate some heavy lifting done to guard against swaps.

How do we avoid that entirely?

Picking a reasonable item limit

Authors are encouraged to experiment with limits using real data and the widest column projection they'll use in their app. The total number of records that will fit into shared memory varies depending on multiple factors.

• The number of columns being requested in the cursor projection. Limit the number of columns, to reduce the size of each row.
• The size of the data in each column.
• the Cursor type.

If the cursor is running in-process, there may be no need for paging. Depending on the Cursor implementation chosen there may be no shared memory/CursorWindow in use. NOTE: If the provider is running in your process, you should implement paging support inorder to make your app run fast and to consume the fewest resources possible.

In common cases where there is a low volume (in the hundreds) of records in the dataset being queried, all of the data should easily fit in shared memory. A debugger can be handy to understand with greater accuracy how many results can fit in shared memory. Inspect the Cursor object returned from a call to query. If the underlying type is a android.database.CrossProcessCursor or android.database.AbstractWindowedCursor it'll have a CursorWindow field. Check getNumRows. If getNumRows returns less than getCount, then you've found something close to the max rows that'll fit in a page. If the data in row is expected to be relatively stable in size, reduce row count by 15-20% to get a reasonable max page size.

What if the limit I guessed was wrong?

The library includes safeguards that protect against situations where an author specifies a record limit that exceeds the number of rows accessible without a CursorWindow swap. In such a circumstance, the Cursor will be adapted to report a count ({Cursor#getCount}) that reflects only records available without CursorWindow swap. But this involves extra work that can be eliminated with a correct limit.

In addition to adjusted coujnt, EXTRA_SUGGESTED_LIMIT will be included in cursor extras. When EXTRA_SUGGESTED_LIMIT is present in extras, the client should strongly consider using this value as the limit for subsequent queries as doing so should help avoid the ned to wrap pre-paged cursors.

Lifecycle and cleanup

Cursors resulting from queries are owned by the requesting client. So they must be closed by the client at the appropriate time.

However, the library retains an internal cache of content that needs to be cleaned up. In order to cleanup, call reset.

Projections

Note that projection is ignored when determining the identity of a query. When adding or removing projection, clients should call reset to clear cached data.

Summary

const val CURSOR_DISPOSITION_COPIED = 1: Int

const val CURSOR_DISPOSITION_PAGED = 2: Int

const val CURSOR_DISPOSITION_REPAGED = 3: Int

const val CURSOR_DISPOSITION_WRAPPED = 4: Int

const val EXTRA_HONORED_ARGS = "android.content.extra.HONORED_ARGS": String!

const val EXTRA_REQUESTED_LIMIT = "android-support:extra-ignored-limit": String!

const val EXTRA_SUGGESTED_LIMIT = "android-support:extra-suggested-limit": String!

const val EXTRA_TOTAL_COUNT = "android.content.extra.TOTAL_COUNT": String!

const val QUERY_ARG_LIMIT = "android:query-arg-limit": String!

const val QUERY_ARG_OFFSET = "android:query-arg-offset": String!

ContentPager(
    resolver: ContentResolver!,
    queryRunner: ContentPager.QueryRunner!
)

ContentPager(
    resolver: ContentResolver,
    queryRunner: ContentPager.QueryRunner,
    cursorCacheSize: Int
)

java-static fun createArgs(offset: Int, limit: Int): Bundle

@MainThread
fun query(
    @RequiresPermission.Read uri: Uri,
    projection: Array<String!>?,
    queryArgs: Bundle,
    cancellationSignal: CancellationSignal?,
    callback: ContentPager.ContentCallback
): Query

@MainThread
fun reset(): Unit