Végtelen görgetés alkalmazásokban: mi ez, elv és megvalósítás

Mi a végtelen görgetés a mobilalkalmazásokban?

Végtelen görgetés (Infinite Scroll) egy adatbetöltési minta, ahol az új elemek automatikusan a lista végére kerülnek a görgetés során. A felhasználó nem kattint a „Következő” vagy „Több betöltése” gombokra — a rendszer maga határozza meg, mikor kell kérni a következő adatcsomagot, és zökkenőmentesen beszúrja az új rekordokat a meglévő listába.

Az Infinite Scroll a közösségi médiának köszönhetően vált népszerűvé — a Twitter, Instagram és TikTok fő tartalomszolgáltatási mechanizmusként használja. A Nielsen Norman Group (2024) adatai szerint az Infinite Scroll 30–50%-kal növeli az elköteleződést a tartalomalkalmazásokban, mivel csökkenti a kognitív terhelést: a felhasználónak nem kell döntenie a következő oldalra lépésről. Azonban a precíz navigációt igénylő feladatoknál (keresés, termékösszehasonlítás) az Infinite Scroll csökkentheti a hatékonyságot.

Technikailag a végtelen görgetés három összetevőből áll: scroll listener (követi a görgetési pozíciót), threshold (távolság a lista végéig a betöltés kiváltásához) és pagination mechanism (API-kérés és adatbeszúrás). A küszöbérték helyes beállítása kritikus: túl korai kiváltásnál (1000 px a végéig) a felhasználó szükségtelen kéréseket kap, túl későnél (50 px) — észreveszi a betöltési szünetet.

Hogyan működik az Infinite Scroll: architektúra és mechanika

Az Infinite Scroll architektúrája az eseménymodellen alapul: a lista komponense eseményt generál a görgetési küszöb elérésekor, a ViewModel feldolgozza azt és meghívja a repository-t a következő adatcsomag betöltéséhez. A válasz kézhezvétele után az új elemek bekerülnek a listába, és a UI frissül az adapteren keresztül. Ennek a láncnak aszinkronnak kell lennie, és nem blokkolhatja a UI szálat.

Az Infinite Scroll alapalgoritmusa négy lépésből áll. Inicializálás: a képernyő első megnyitásakor betöltődik az első adatcsomag (1. oldal vagy cursor = null). Követés: a scroll listener ellenőrzi, hogy a felhasználó elérte-e a küszöbértéket — általában 200–500 px a lista végéig. Betöltés: kérés küldése az API-nak lapozási paraméterekkel, a UI-n betöltő jelző jelenik meg (spinner a láblécben). Beszúrás: az új elemek hozzáadása az adapterhez, a görgetési pozíció korrigálása az ugrás elkerülése érdekében.

Kritikus szempont a kérések debounce-olása. Ha a felhasználó gyorsan a végére görget, a kiváltó többször is aktiválódhat, mielőtt a válasz megérkezne a szervertől. Debounce nélkül ez duplikált kérésekhez (versenyhelyzethez) vezet. A megoldás az új kérés blokkolása, amíg az előző be nem fejeződik. Az isLoading jelző a ViewModel-ben megakadályozza a többszörös hívásokat: állítsa be az isLoading = true értéket a kérés elküldésekor, és állítsa vissza a válasz vagy hiba kézhezvételekor.

A mobil platformokon speciális mechanizmusokat használnak az Infinite Scroll-hoz. iOS-en ez a prefetchDataSource az UICollectionView-ben, amely automatikusan kér adatokat a képernyőn kívüli cellákhoz. Androidon — a Google Paging 3 könyvtára, amely kész architektúrát biztosít PagingSource, PagingData és PagingDataAdapter segítségével. A Paging 3 támogatja a RemoteMediator-t a hálózati és helyi adatok kombinálásához, és automatikusan kezeli a betöltési állapotot.

Cursor-alapú vs offset-alapú lapozás

Offset-alapú lapozás a page és size paramétereket használja: page=2, size=20 a 21–40-es rekordokat adja vissza. Ez a megközelítés egyszerű a megvalósításban, de alapvető problémája van — ha a kérések között rekordokat adnak hozzá vagy törölnek az adatbázisban, az eltolás elromlik (a felhasználó duplikátumokat vagy hiányokat lát). A magas változási gyakoriságú csatornáknál (hírek, hozzászólások) az offset-alapú lapozás helytelen eredményeket ad.

Cursor-alapú lapozás az utolsó elem egyedi azonosítóját (kurzort) használja: after=id_12345&limit=20. A szerver 20 rekordot ad vissza a megadott kurzor után. Ez a megközelítés garantálja az adatok konzisztenciáját a beszúrásoktól és törlésektől függetlenül. A GraphQL Best Practices (2024) szerint a cursor-alapú lapozás ajánlott minden valós idejű alkalmazáshoz, ahol az adatok dinamikusan változnak.

A megközelítések közötti választás az alkalmazás típusától függ. Közösségi médiában (Instagram, TikTok) — csak cursor-alapú, mert a csatorna folyamatosan frissül. Katalógusokban ritka változásokkal (online áruház termékkategóriái) az offset-alapú lapozás elfogadható. Hibrid forgatókönyvekhez a Google a Paging 3 RemoteMediator-t ajánlja, amely a hálózatról származó cursor-alapú lapozást kombinálja a helyi Room adatbázis offset-alapú lapozásával.

Infinite Scroll megvalósítása iOS-en és Androidon

Androidon a standard megközelítés a Jetpack Paging 3 könyvtára. A PagingSource meghatározza az adatforrást (hálózat vagy AB), a PagingData adattöredékeket tartalmaz, a PagingDataAdapter pedig megjeleníti azokat a RecyclerView-ban. A Paging 3 automatikusan kezeli a prefetch távolságot, az újrapróbálkozást és a frissítést. A hálózattal való integrációhoz a RemoteMediator-t használják: betölti az adatokat az API-ból, elmenti a Room-ba és értesíti a PagingSource-t a frissítésről. A Google I/O 2024 szerint az Infinite Scroll-t használó Android-alkalmazások több mint 60%-a Paging 3-at használ.

Példa a Paging 3 alap megvalósítására:

class FeedPagingSource(
    private val api: FeedApi
) : PagingSource<String, Post>() {
    override suspend fun load(
        params: LoadParams<String>
    ): LoadResult<String, Post> {
        val response = api.getFeed(
            cursor = params.key,
            limit = params.loadSize
        )
        return LoadResult.Page(
            data = response.items,
            prevKey = null,
            nextKey = response.nextCursor
        )
    }
}

iOS-en az Infinite Scroll megvalósításához UICollectionView-t használnak prefetchDataSource-szal. Az UICollectionViewDataSourcePrefetching protokoll tartalmazza a collectionView(_:prefetchItemsAt:) metódust, amely akkor hívódik meg, amikor a rendszer elŐre jelzi a görgetést bizonyos index paths-ekhez. Az Android Paging 3-tól eltérően az iOS-en nincs beépített lapozási könyvtár — a fejlesztők manuálisan valósítják meg, vagy harmadik fél megoldásait használják, mint a RxSwift + NSLayoutConstraint vagy Combine-alapú pipeline-ok.

Példa a prefetch-re iOS-en:

extension FeedViewController: UICollectionViewDataSourcePrefetching {
    func collectionView(
        _ collectionView: UICollectionView,
        prefetchItemsAt indexPaths: [IndexPath]
    ) {
        let lastRow = collectionView.numberOfItems(inSection: 0) - 1
        if indexPaths.contains(IndexPath(row: lastRow, section: 0)) {
            viewModel.loadNextPage()
        }
    }
}

A SwiftUI egy deklaratívabb megközelítést kínál az onAppear módosítón keresztül. A fejlesztő egy ProgressView-t helyez a lista végére, és amikor az megjelenik, kiváltja a következő oldal betöltését. Az Apple WWDC 2024 szerint az új AsyncSequence és Swift Algorithms API-k leegyszerűsítik a végtelen görgetés megvalósítását a beépített chunking és debounce operátorok biztosításával.

A végtelen görgetés UX-problémái és megoldásaik

Az Infinite Scroll fő UX-problémája a lábléc és navigáció elvesztése. Az online áruházakban a felhasználó gyakran szeretne a lábléchez menni kapcsolatfelvételi adatokért vagy linkekért. A végtelen görgetés elérhetetlenné teszi a láblécet — az folyamatosan lefelé mozog a betöltéssel együtt. A megoldás egy lebegő gyors felgörgetési gomb (FAB) hozzáadása vagy a lábléc rögzítése a listától elküllönítve.

A második probléma a görgetési előzmények hiánya. Ha a felhasználó látott egy érdekes terméket a 3. pozícióban, a 50-ig görgetett, majd rákattintott a „Vissza” gombra — visszatér a lista elejére, és újra a 50. pozícióig kell görgetnie. A megoldás a görgetési pozíció mentése a ViewModel-ben vagy a state restoration használata Activity/UIViewController szinten. Az iOS támogatja a NSUserActivity-t a pozíció visszaállításához, az Android pedig az onSaveInstanceState-t.

A harmadik probléma a teljesítmény ezres nagyságrendű elemekkel. Ha a virtualizáció nincs konfigurálva, 500–1000 betöltött elem után az alkalmazás lassulni kezd a megnövekedett memóriahasználat miatt. A megoldás a virtualizáció használata RecyclerView vagy UICollectionView esetén, amely csak a látható és az előre betöltött cellákat tartja a memóriában. A régi adatok időszakos tisztítása (az N oldalnál távolabbi oldalak eldobása) szintén csökkenti a terhelést.