Nekonečné posouvání v aplikacích: co to je, princip a implementace

Co je nekonečné posouvání v mobilních aplikacích?

Nekonečné posouvání (Infinite Scroll) je vzor načítání dat, při kterém se nové prvky automaticky přidávají na konec seznamu při rolování. Uživatel nemusí klikat na tlačítka „Další„ nebo „Načíst více„ — systém sám určí okamžik, kdy je třeba požádat o další dávku dat, a plynule vloží nové záznamy do stávajícího seznamu.

Infinite Scroll se stal populárním díky sociálním sítím — Twitter, Instagram a TikTok jej používají jako hlavní mechanismus doručování obsahu. Podle Nielsen Norman Group (2024) zvyšuje Infinite Scroll zapojení o 30–50 % u obsahových aplikací, protože snižuje kognitivní zátěž: uživatel nemusí rozhodovat o přechodu na další stránku. Pro úkoly vyžadující přesnou navigaci (vyhledávání, porovnávání zboží) však může Infinite Scroll snižovat efektivitu.

Technicky se nekonečné posouvání skládá ze tří komponent: scroll listener (sleduje pozici rolování), threshold (vzdálenost od konce seznamu pro spuštění načítání) a pagination mechanism (požadavek na API a vložení dat). Správné nastavení threshold je kritické: při příliš brzkém spuštění (1000 px před koncem) obdrží uživatel zbytečné požadavky, při příliš pozdním (50 px) si všimne pauzy v načítání.

Jak funguje Infinite Scroll: architektura a mechanika

Architektura Infinite Scroll je založena na událostním modelu: komponenta seznamu generuje událost při dosažení prahu rolování, ViewModel ji zpracuje a vyvolá repozitář pro načtení další dávky dat. Po obdržení odpovědi se nové prvky vloží do seznamu a UI se aktualizuje prostřednictvím adaptéru. Tento řetězec musí být asynchronní a nesmí blokovat UI vlákno.

Základní algoritmus Infinite Scroll zahrnuje čtyři kroky. Inicializace: při prvním otevření obrazovky se načte první dávka dat (page 1 nebo cursor = null). Sledování: scroll listener kontroluje, zda uživatel dosáhl prahu — obvykle 200–500 px před koncem seznamu. Načítání: odešle se požadavek na API s parametry stránkování, na UI se zobrazí indikátor načítání (spinner v patičce). Vložení: nové prvky se přidají do adaptéru, pozice rolování se upraví, aby se předešlo skoku.

Kritickým aspektem je debounce požadavků. Pokud uživatel rychle roluje až na konec, může se spouštěč aktivovat několikrát před obdržením odpovědi od serveru. Bez debounce to vede k duplicitním požadavkům (race condition). Řešením je blokovat nový požadavek, dokud předchozí není dokončen. Příznak isLoading ve ViewModel zabraňuje vícenásobným voláním: set isLoading = true při odeslání požadavku, reset při obdržení odpovědi nebo chyby.

Na mobilních platformách se pro Infinite Scroll používají specializované mechanismy. Na iOS je to prefetchDataSource v UICollectionView, který automaticky požaduje data pro buňky mimo obrazovku. Na Androidu — Paging 3 Library od Google, která poskytuje hotovou architekturu s PagingSource, PagingData a PagingDataAdapter. Paging 3 podporuje RemoteMediator pro kombinaci síťových a lokálních dat a automaticky spravuje stav načítání.

Cursor-based vs offset-based stránkování

Offset-based stránkování používá parametry page a size: page=2, size=20 vrací záznamy 21–40. Tento přístup je jednoduchý na implementaci, ale má zásadní problém — pokud se mezi požadavky do databáze přidávají nebo odebírají záznamy, posun se naruší (uživatel vidí duplicity nebo mezery). Pro kanály s vysokou frekvencí změn (novinky, komentáře) poskytuje offset-based stránkování nesprávné výsledky.

Cursor-based stránkování používá unikátní identifikátor posledního prvku (kurzor): after=id_12345&limit=20. Server vrací 20 záznamů následujících po zadaném kurzoru. Tento přístup zaručuje konzistenci dat bez ohledu na vkládání a mazání. Podle GraphQL Best Practices (2024) se cursor-based stránkování doporučuje pro všechny real-time aplikace, kde se data dynamicky mění.

Výběr mezi přístupy závisí na typu aplikace. Pro sociální sítě (Instagram, TikTok) — pouze cursor-based, protože se kanál neustále aktualizuje. Pro katalogy se vzácnými změnami (kategorie zboží internetového obchodu) je offset-based stránkování přípustné. Pro hybridní scénáře Google doporučuje Paging 3 RemoteMediator, který kombinuje cursor-based stránkování ze sítě s offset-based stránkováním z lokální databáze Room.

Implementace Infinite Scroll na iOS a Android

Na Androidu je standardním přístupem knihovna Paging 3 z Jetpack. PagingSource definuje zdroj dat (síť nebo DB), PagingData obsahuje bloky dat a PagingDataAdapter je zobrazuje v RecyclerView. Paging 3 automaticky spravuje prefetch distance, retry a refresh. Pro integraci se sítí se používá RemoteMediator: načítá data z API, ukládá je do Room a informuje PagingSource o aktualizaci. Podle Google I/O 2024 používá Paging 3 více než 60 % Android aplikací s Infinite Scroll.

Příklad základní implementace Paging 3:

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
        )
    }
}

Na iOS se pro implementaci Infinite Scroll používá kombinace UICollectionView s prefetchDataSource. Protokol UICollectionViewDataSourcePrefetching obsahuje metodu collectionView(_:prefetchItemsAt:), která se volá, když systém předvídá rolování k určitým index paths. Na rozdíl od Android Paging 3 nemá iOS vestavěnou knihovnu stránkování — vývojáři ji implementují ručně nebo používají řešení třetích stran jako RxSwift + NSLayoutConstraint nebo Combine-based pipeline.

Příklad prefetch na iOS:

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()
        }
    }
}

SwiftUI poskytuje deklarativnější přístup prostřednictvím modifikátoru onAppear. Vývojář umístí ProgressView na konec seznamu a při jeho zobrazení zavolá načtení další stránky. Podle Apple WWDC 2024 nové API AsyncSequence a Swift Algorithms zjednodušují implementaci nekonečného posouvání tím, že poskytují vestavěné operátory chunking a debounce.

UX problémy nekonečného posouvání a jejich řešení

Hlavním UX problémem Infinite Scroll je ztráta patičky a navigace. V internetových obchodech chce uživatel často přejít do patičky pro kontakty nebo odkazy. Nekonečné posouvání činí patičku nedostupnou — neustále odjíždí dolů při načítání. Řešením je přidat floating tlačítko rychlého posunu nahoru (FAB) nebo ukotvit patičku odděleně od seznamu.

Druhým problémem je absence historie rolování. Pokud uživatel viděl zajímavé zboží na pozici 3, prolistoval až na 50. pozici a poté stiskl „Zpět„ — vrací se na začátek seznamu a musí znovu rolovat na pozici 50. Řešením je ukládat scroll position ve ViewModel nebo použít state restoration na úrovni Activity/UIViewController. iOS podporuje NSUserActivity pro obnovení pozice, Android — onSaveInstanceState.

Třetím problémem je výkon při tisících prvcích. Pokud virtualizace není nastavena, po 500–1000 načtených prvcích začne aplikace zpomalovat kvůli růstu spotřeby paměti. Řešením je použít virtualizaci RecyclerView nebo UICollectionView, která v paměti uchovává pouze viditelné + prefetched buňky. Pravidelné čištění starých dat (discard pages vzdálenějších než N stránek) také snižuje zátěž.