Android Academy · Lezione

PagingSource e Pager

Definisca come vengono caricate le pagine

PagingSource e Pager è una lezione Android Academy gratuita su CoddyKit. Questa è la lezione 2 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Android Academy, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Android Academy include 4 lezioni in totale.

Definire il caricamento delle pagine

Per eseguire la paginazione da un'API di rete, deve scrivere un PagingSource. Questo risponde a due domande per Paging 3:

Come si carica la pagina corrispondente a una determinata chiave?
Se l'utente aggiorna l'elenco, da dove si deve riprendere?

Quindi lo racchiude in un Pager che lo converte in un Flow<PagingData>.

Parametri di tipo di PagingSource

PagingSource<Key, Value> accetta due parametri di tipo:

Key - identifica una pagina. Per un'API basata sui numeri di pagina è Int; per un'API basata sui cursori è un token String.
Value - il tipo dell'elemento, ad esempio Article.

import androidx.paging.PagingSource
import androidx.paging.PagingState

class ArticlePagingSource(
    private val api: ArticleApi
) : PagingSource<Int, Article>() {
    // implement load() and getRefreshKey()
}

Implementare load()

load() è una funzione suspend. Riceve params.key (la pagina da recuperare) e restituisce un LoadResult.

In caso di successo, restituisce LoadResult.Page con gli elementi e le chiavi precedente e successiva. Un valore null per una chiave indica che non esiste alcuna pagina in quella direzione.

override suspend fun load(
    params: LoadParams<Int>
): LoadResult<Int, Article> {
    val page = params.key ?: 1   // first load has a null key
    return try {
        val response = api.getArticles(page = page, size = params.loadSize)
        LoadResult.Page(
            data = response.items,
            prevKey = if (page == 1) null else page - 1,
            nextKey = if (response.items.isEmpty()) null else page + 1
        )
    } catch (e: Exception) {
        LoadResult.Error(e)
    }
}

Perché prevKey e nextKey sono importanti

Paging utilizza nextKey per caricare le pagine successive mentre l'utente scorre verso il basso e prevKey per caricare quelle precedenti (utile quando si inizia al centro di un elenco).

Restituire null per nextKey comunica a Paging che non ci sono altre pagine, quindi interrompe le richieste. Dimenticarlo può causare richieste vuote infinite.

// Stop forward paging when the server returns an empty page
nextKey = if (response.items.isEmpty()) null else page + 1

// Stop backward paging at the first page
prevKey = if (page == 1) null else page - 1

Implementare getRefreshKey()

Quando l'elenco viene aggiornato (tramite trascinamento verso il basso o invalidazione), Paging deve sapere quale pagina ricaricare, in modo che l'utente rimanga più o meno nella stessa posizione.

getRefreshKey() utilizza anchorPosition corrente, ovvero l'elemento più vicino all'area visibile, per scegliere una chiave appropriata.

override fun getRefreshKey(state: PagingState<Int, Article>): Int? {
    return state.anchorPosition?.let { anchor ->
        val closestPage = state.closestPageToPosition(anchor)
        closestPage?.prevKey?.plus(1)
            ?: closestPage?.nextKey?.minus(1)
    }
}

Gestire gli errori in modo corretto

Racchiuda la chiamata di rete in un try/catch e restituisca LoadResult.Error(e) in caso di errore. Paging espone questo stato nell'interfaccia utente come LoadState.Error, consentendo di mostrare un pulsante per riprovare.

Non lasci mai che un'eccezione esca da load(): la intercetti e la converta in LoadResult.Error.

return try {
    val response = api.getArticles(page = page, size = params.loadSize)
    LoadResult.Page(
        data = response.items,
        prevKey = if (page == 1) null else page - 1,
        nextKey = if (response.items.isEmpty()) null else page + 1
    )
} catch (e: IOException) {        // no network
    LoadResult.Error(e)
} catch (e: HttpException) {       // non-2xx response
    LoadResult.Error(e)
}

Creare un Pager

Un Pager collega il Suo PagingConfig a una factory che crea un nuovo PagingSource. La proprietà .flow è un Flow<PagingData> che l'interfaccia utente raccoglie.

La lambda della factory deve creare una sorgente nuova ogni volta, perché Paging invalida e ricrea la sorgente durante l'aggiornamento.

import androidx.paging.Pager
import androidx.paging.PagingConfig
import androidx.paging.PagingData
import kotlinx.coroutines.flow.Flow

class ArticleRepository(private val api: ArticleApi) {
    fun articleStream(): Flow<PagingData<Article>> = Pager(
        config = PagingConfig(pageSize = 20, prefetchDistance = 5),
        pagingSourceFactory = { ArticlePagingSource(api) }
    ).flow
}

cachedIn per i ViewModel

La raccolta di PagingData è un'operazione eseguibile una sola volta; raccoglierlo di nuovo riavvia il caricamento. Per superare i cambiamenti di configurazione e consentire a più collector di condividere i dati, memorizzi nella cache il flow nell'ambito di viewModelScope usando cachedIn.

import androidx.lifecycle.ViewModel
import androidx.lifecycle.viewModelScope
import androidx.paging.cachedIn

class ArticleViewModel(
    repo: ArticleRepository
) : ViewModel() {
    val articles = repo.articleStream()
        .cachedIn(viewModelScope)
}

loadSize e pageSize

Noti che load() legge params.loadSize, non direttamente il valore pageSize configurato.

Durante il primo caricamento Paging può richiedere un blocco iniziale più grande (controllato da initialLoadSize in PagingConfig, con valore predefinito pari a 3 volte la dimensione della pagina). Passi sempre params.loadSize all'API, in modo che la richiesta corrisponda a ciò che Paging si aspetta di ricevere.

// Correct: respect the size Paging asks for
val response = api.getArticles(page = page, size = params.loadSize)

// PagingConfig can tune the first load:
PagingConfig(pageSize = 20, initialLoadSize = 40)

API basate sui cursori

Non tutte le API utilizzano numeri di pagina. Alcune restituiscono un cursore o un token che indica la pagina successiva. Lo schema è identico: deve solo cambiare il tipo Key in String e utilizzare il token restituito dalla risposta.

class CursorArticleSource(
    private val api: ArticleApi
) : PagingSource<String, Article>() {
    override suspend fun load(
        params: LoadParams<String>
    ): LoadResult<String, Article> {
        val cursor = params.key   // null on first load
        return try {
            val res = api.getArticles(cursor = cursor, size = params.loadSize)
            LoadResult.Page(
                data = res.items,
                prevKey = null,            // forward-only cursor
                nextKey = res.nextCursor   // null when exhausted
            )
        } catch (e: Exception) {
            LoadResult.Error(e)
        }
    }

    override fun getRefreshKey(state: PagingState<String, Article>) = null
}

Mettere tutto insieme

Ora dispone dell'intero livello dati: un PagingSource che carica una pagina, un Pager che trasmette le pagine e un ViewModel che memorizza nella cache il flow.

Il livello dell'interfaccia utente raccoglie semplicemente viewModel.articles, che visualizzeremo nella prossima lezione con un LazyColumn di Compose.

// Data layer summary
// 1. ArticlePagingSource : PagingSource<Int, Article>
// 2. Pager(config, factory).flow  -> Flow<PagingData<Article>>
// 3. ViewModel: repo.articleStream().cachedIn(viewModelScope)
// UI just collects viewModel.articles

Verifica rapida

In un PagingSource basato sui numeri di pagina, cosa indica la restituzione di nextKey = null da load()?

Riepilogo: PagingSource e Pager

Ha creato il livello dati per la paginazione:

PagingSource<Key, Value> implementa load() e getRefreshKey()
load() restituisce LoadResult.Page con prevKey/nextKey oppure LoadResult.Error
Una chiave null interrompe la paginazione in quella direzione
Pager(config, factory).flow produce un Flow<PagingData>
cachedIn(viewModelScope) conserva i dati tra i cambiamenti di configurazione

Prossimo argomento: visualizzare questo flow in un elenco Compose.

Domande Frequenti

La lezione «PagingSource e Pager» è gratuita?

Sì — il testo completo di «PagingSource e Pager» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Android Academy, passa a CoddyKit PRO. Il corso Android Academy include 4 lezioni in totale.

Cosa imparerò in «PagingSource e Pager»?

Definisca come vengono caricate le pagine Eserciti Android Academy con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare Android Academy?

Non è richiesta alcuna esperienza precedente. Android Academy su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 2 di 4.

Quanto tempo richiede la lezione «PagingSource e Pager»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione Android Academy?

Sì. Ogni lezione Android Academy include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

← Torna a Android Academy