Zu Paging 3 migrieren (Views)

Konzepte und Jetpack Compose-Implementierungarrow_forward

Paging 3 unterscheidet sich erheblich von früheren Versionen der Paging-Bibliothek. Diese Version bietet erweiterte Funktionen und behebt häufige Probleme bei der Verwendung von Paging 2. Wenn Ihre App bereits eine frühere Version der Paging-Bibliothek verwendet, finden Sie auf dieser Seite weitere Informationen zur Migration zu Paging 3.

Wenn Paging 3 die erste Version der Paging-Bibliothek ist, die Sie in Ihrer App verwenden, finden Sie unter Paging-Daten laden und anzeigen grundlegende Informationen zur Verwendung.

Vorteile der Migration zu Paging 3

Paging 3 enthält die folgenden Funktionen, die in früheren Versionen der Bibliothek nicht vorhanden waren:

• Erstklassige Unterstützung für Kotlin-Koroutinen und Flow.
• Unterstützung für asynchrones Laden mit den RxJava-Primitiven Single oder Guava ListenableFuture.
• Integrierte Ladezustands- und Fehlersignale für ein reaktionsschnelles UI-Design, einschließlich Funktionen für Wiederholung und Aktualisierung.
• Verbesserungen an der Repository-Ebene, einschließlich Unterstützung für die Abbruchfunktion und einer vereinfachten Datenquellenschnittstelle.
• Verbesserungen an der Präsentationsebene, Listentrennzeichen, benutzerdefinierte Seitentransformationen sowie Kopf- und Fußzeilen für den Ladezustand.

App zu Paging 3 migrieren

Für eine vollständige Migration zu Paging 3 müssen Sie alle drei Hauptkomponenten von Paging 2 migrieren:

• DataSource-Klassen
• PagedList
• PagedListAdapter

Einige Paging 3-Komponenten sind jedoch abwärtskompatibel mit früheren Versionen von Paging. Insbesondere kann die PagingSource-API von Paging 3 eine Datenquelle für LivePagedListBuilder und RxPagedListBuilder aus älteren Versionen sein. Ebenso kann die Pager API ältere DataSource Objekte mit der asPagingSourceFactory Methode verwenden. Das bedeutet, dass Sie die folgenden Migrationsoptionen haben:

• Sie können Ihre DataSource zu PagingSource migrieren, aber den Rest Ihrer Paging-Implementierung unverändert lassen.
• Sie können Ihre PagedList und PagedListAdapter migrieren, aber weiterhin die ältere DataSource API verwenden.
• Sie können die gesamte Paging-Implementierung migrieren, um Ihre App vollständig zu Paging 3 zu migrieren.

In den Abschnitten auf dieser Seite wird erläutert, wie Sie Paging-Komponenten auf jeder Ebene Ihrer App migrieren.

Übersicht über die Migration

Wenn Sie vollständig zu Paging 3 migrieren und Ihre RecyclerView-Implementierung beibehalten möchten, müssen Sie die folgenden Komponenten aktualisieren:

DataSource-Klassen

In diesem Abschnitt werden die erforderlichen Änderungen beschrieben, um eine ältere Paging-Implementierung zu migrieren, damit PagingSource verwendet wird.

Die Klassen PageKeyedDataSource, PositionalDataSource und ItemKeyedDataSource aus Paging 2 sind in Paging 3 in der PagingSource-API zusammengefasst. Die Lademethoden aus allen alten API-Klassen sind in PagingSource in einer einzigen load-Methode zusammengefasst. Dadurch wird die Codeduplikation reduziert, da ein Großteil der Logik in den Lademethoden in Implementierungen der alten API-Klassen oft identisch ist.

Alle Parameter der Lademethode werden in Paging 3 durch eine versiegelte LoadParams-Klasse ersetzt, die Unterklassen für jeden Ladetyp enthält. Wenn Sie in Ihrer load Methode zwischen Ladetypen unterscheiden müssen, prüfen Sie, welche abgeleitete Klasse von LoadParams übergeben wurde: LoadParams.Refresh, LoadParams.Prepend oder LoadParams.Append.

Weitere Informationen zur Implementierung von PagingSource finden Sie unter Datenquelle definieren.

Aktualisierungsschlüssel

Implementierungen von PagingSource müssen definieren, wie Aktualisierungen ab der Mitte der geladenen Paging-Daten fortgesetzt werden. Implementieren Sie dazu getRefreshKey um den richtigen Anfangsschlüssel mit state.anchorPosition als zuletzt aufgerufenen Index zuzuordnen.

// Replaces ItemKeyedDataSource.
@Nullable
@Override
String getRefreshKey(state: PagingState<String, User>) {
  Integer anchorPosition = state.anchorPosition;
  if (anchorPosition == null) {
    return null;
  }

  return state.getClosestItemToPosition(anchorPosition);
}

// Replaces PositionalDataSource.
@Nullable
@Override
Integer getRefreshKey(state: PagingState<Integer, User>) {
  return state.anchorPosition;
}

// Replaces ItemKeyedDataSource.
@Nullable
@Override
String getRefreshKey(state: PagingState<String, User>) {
  Integer anchorPosition = state.anchorPosition;
  if (anchorPosition == null) {
    return null;
  }

  return state.getClosestItemToPosition(anchorPosition);
}

// Replaces PositionalDataSource.
@Nullable
@Override
Integer getRefreshKey(state: PagingState<Integer, User>) {
  return state.anchorPosition;
}

PagedList

In diesem Abschnitt werden alle erforderlichen Änderungen beschrieben, um eine ältere Paging-Implementierung zu migrieren, damit Pager und PagingData in Paging 3 verwendet werden.

PagedListBuilder-Klassen

PagingData ersetzt die vorhandene PagedList aus Paging 2. Wenn Sie zu PagingData migrieren möchten, müssen Sie Folgendes aktualisieren:

• Die Paging-Konfiguration wurde von PagedList.Config zu PagingConfig verschoben.
• LivePagedListBuilder und RxPagedListBuilder wurden zu einer einzigen Pager-Klasse zusammengefasst.

• Pager stellt mit seiner Flow<PagingData> eine beobachtbare Eigenschaft bereit .flow-Eigenschaft. RxJava- und LiveData-Varianten sind auch als Erweiterungseigenschaften verfügbar, die von Java über statische Methoden aufgerufen werden können und aus den Modulen paging-rxjava* bzw. paging-runtime bereitgestellt werden.

// CoroutineScope helper provided by the lifecycle-viewmodel-ktx artifact.
CoroutineScope viewModelScope = ViewModelKt.getViewModelScope(viewModel);
Pager<Integer, User> pager = Pager<>(
  new PagingConfig(/* pageSize = */ 20),
  () -> ExamplePagingSource(backend, query));

Flowable<PagingData<User>> flowable = PagingRx.getFlowable(pager);
PagingRx.cachedIn(flowable, viewModelScope);

// CoroutineScope helper provided by the lifecycle-viewmodel-ktx artifact.
CoroutineScope viewModelScope = ViewModelKt.getViewModelScope(viewModel);
Pager<Integer, User> pager = Pager<>(
  new PagingConfig(/* pageSize = */ 20),
  () -> ExamplePagingSource(backend, query));

PagingLiveData.cachedIn(PagingLiveData.getLiveData(pager), viewModelScope);

Weitere Informationen zum Einrichten eines reaktiven Streams von PagingData Objekten mit Paging 3 finden Sie unter Stream von PagingData einrichten.

PagedListAdapter

In diesem Abschnitt werden alle erforderlichen Änderungen beschrieben, um eine ältere Paging-Implementierung zu migrieren, damit die Klassen PagingDataAdapter oder AsyncPagingDataDiffer aus Paging 3 verwendet werden.

In Paging 2 wird PagedListAdapter verwendet, um eine PagedList an eine RecyclerView zu binden. In Paging 3 ersetzt PagingData die Klasse PagedList.

Paging 3 bietet PagingDataAdapter zur Verarbeitung der neuen PagingData reaktiven Streams. Ansonsten haben PagedListAdapter und PagingDataAdapter dieselbe Schnittstelle. Wenn Sie von PagedListAdapter zu PagingDataAdapter migrieren möchten, ändern Sie Ihre Implementierung von PagedListAdapter so, dass sie stattdessen PagingDataAdapter erweitert.

Weitere Informationen zu PagingDataAdapter finden Sie unter RecyclerView Adapter definieren.

AsyncPagedListDiffer

Wenn Sie derzeit eine benutzerdefinierte RecyclerView.Adapter-Implementierung mit AsyncPagedListDiffer verwenden, migrieren Sie Ihre Implementierung so, dass stattdessen die in Paging 3 bereitgestellte AsyncPagingDataDiffer verwendet wird:

AsyncPagingDataDiffer(diffCallback, listUpdateCallback)

new AsyncPagingDataDiffer(diffCallback, listUpdateCallback);

new AsyncPagingDataDiffer(diffCallback, listUpdateCallback);