Нескінченний скрол в додатках: що це, принцип та реалізація

Що таке нескінченний скрол у мобільних додатках?

Нескінченний скрол (Infinite Scroll) — патерн завантаження даних, при якому нові елементи автоматично додаються в кінець списку під час прокрутки. Користувач не натискає кнопки «Далі» або «Завантажити ще» — система сама визначає момент, коли запитати наступну порцію даних, і безшовно додає нові записи в існуючий список.

Infinite Scroll став популярним завдяки соціальним мережам — Twitter, Instagram та TikTok використовують його як основний механізм подачі контенту. За даними Nielsen Norman Group (2024), нескінченний скрол збільшує залученість на 30–50% для контентних додатків, оскільки знижує когнітивне навантаження: користувачу не потрібно приймати рішення про перехід на наступну сторінку. Однак для завдань, що потребують точної навігації (пошук, порівняння товарів), нескінченний скрол може знижувати ефективність.

Технічно нескінченний скрол складається з трьох компонентів: scroll listener (відстежує позицію прокрутки), threshold (відстань до кінця списку для тригера завантаження) та механізм пагінації (запит до API та вставка даних). Правильне налаштування threshold критичне: при занадто ранньому тригері (1000 px до кінця) користувач отримає непотрібні запити, при занадто пізньому (50 px) — помітить паузу завантаження.

Як працює Infinite Scroll: архітектура та механіка

Архітектура нескінченного скролу базується на подійній моделі: компонент списку генерує подію при досягненні порога прокрутки, ViewModel обробляє її та викликає репозиторій для завантаження наступної порції даних. Після отримання відповіді нові елементи вставляються в список, а UI оновлюється через адаптер. Цей ланцюг повинен бути асинхронним і не блокувати UI-потік.

Базовий алгоритм нескінченного скролу включає чотири кроки. Ініціалізація: при першому відкритті екрану завантажується перша порція даних (сторінка 1 або cursor = null). Відстеження: scroll listener перевіряє, чи досяг користувач порога — звичайно це 200–500 px від кінця списку. Завантаження: надсилається запит до API з параметрами пагінації, на UI показується індикатор завантаження (spinner у нижньому колонтитулі). Вставка: нові елементи додаються в адаптер, позиція прокрутки коригується, щоб уникнути стрибка.

Критичний аспект — debounce запитів. Якщо користувач швидко прокручує до кінця, тригер може спрацювати кілька разів до отримання відповіді від сервера. Без debounce це призводить до дублювання запитів (race condition). Рішення — блокувати новий запит, поки попередній не завершиться. Прапорець isLoading в ViewModel запобігає множинним викликам: встановіть isLoading = true при відправці запиту, скиньте при отриманні відповіді або помилки.

На мобільних платформах для нескінченного скролу використовуються спеціалізовані механізми. На iOS це prefetchDataSource в UICollectionView, який автоматично запитує дані для комірок за межами екрану. На Android — Paging 3 Library від Google, яка надає готову архітектуру з PagingSource, PagingData та PagingDataAdapter. Paging 3 підтримує RemoteMediator для комбінації мережевих та локальних даних і автоматично керує станом завантаження.

Cursor-based vs offset-based пагінація

Offset-based пагінація використовує параметри page та size: page=2, size=20 повертає записи 21–40. Цей підхід простий у реалізації, але має фундаментальну проблему — якщо між запитами в базу даних додаються або видаляються записи, зміщення збивається (користувач бачить дублікати або пропуски). Для стрічок з високою частотою змін (новини, коментарі) offset-based пагінація дає некоректні результати.

Cursor-based пагінація використовує унікальний ідентифікатор останнього елемента (курсор): after=id_12345&limit=20. Сервер повертає 20 записів після вказаного курсора. Цей підхід гарантує консистентність даних незалежно від вставок та видалень. За даними GraphQL Best Practices (2024), cursor-based пагінація рекомендується для всіх реального часу додатків, де дані динамічно змінюються.

Вибір між підходами залежить від типу додатка. Для соціальних мереж (Instagram, TikTok) — тільки cursor-based, оскільки стрічка постійно оновлюється. Для каталогів з рідкими змінами (категорії товарів інтернет-магазину) offset-based пагінація прийнятна. Для гібридних сценаріїв Google рекомендує Paging 3 RemoteMediator, який об’єднує cursor-based пагінацію з мережі та offset-based пагінацію з локальної бази даних Room.

Реалізація Infinite Scroll на iOS та Android

На Android стандартний підхід — бібліотека Paging 3 з Jetpack. PagingSource визначає джерело даних (мережу або БД), PagingData містить чанки даних, а PagingDataAdapter відображає їх у RecyclerView. Paging 3 автоматично керує prefetch відстанню, повторними спробами та оновленнями. Для інтеграції з мережею використовується RemoteMediator: він завантажує дані з API, зберігає в Room та сповіщає PagingSource про оновлення. За даними Google I/O 2024, понад 60% Android-додатків з нескінченним скролом використовують Paging 3.

Приклад базової реалізації 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
        )
    }
}

На iOS для реалізації нескінченного скролу використовується UICollectionView з prefetchDataSource. Протокол UICollectionViewDataSourcePrefetching містить метод collectionView(_:prefetchItemsAt:), який викликається, коли система передбачає прокрутку до певних index paths. На відміну від Android Paging 3, на iOS немає вбудованої бібліотеки пагінації — розробники реалізують її вручну або використовують сторонні рішення типу RxSwift + NSLayoutConstraint або Combine-основані конвеєри.

Приклад prefetch на 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 надає більш декларативний підхід через модифікатор onAppear. Розробник розміщує ProgressView в кінці списку і при його появі запускає завантаження наступної сторінки. За даними Apple WWDC 2024, нові API AsyncSequence та Swift Algorithms спрощують реалізацію нескінченного скролу, надаючи вбудовані оператори chunking та debounce.

UX-проблеми нескінченного скролу та їх вирішення

Головна UX-проблема нескінченного скролу — втрата нижнього колонтитулу та навігації. У інтернет-магазинах користувач часто хоче перейти в нижній колонтитул за контактами або посиланнями. Нескінченний скрол робить нижній колонтитул недоступним — він постійно їде вниз у міру завантаження нового контенту. Рішення — додати плаваючу кнопку швидкого прокручування догори (FAB) або закріпити нижній колонтитул окремо від списку.

Друга проблема — відсутність історії прокрутки. Якщо користувач побачив цікавий товар на позиції 3, прокрутив до 50-ї, а потім натиснув «Назад» — він повертається на початок списку і змушений знову прокручувати до позиції 50. Рішення — зберігати позицію прокрутки в ViewModel або використовувати відновлення стану на рівні Activity/UIViewController. iOS підтримує NSUserActivity для відновлення позиції, Android — onSaveInstanceState.

Третя проблема — продуктивність при тисячах елементів. Якщо віртуалізація не налаштована, через 500–1000 завантажених елементів додаток починає гальмувати через зростання споживання пам’яті. Рішення — використовувати віртуалізацію RecyclerView або UICollectionView, яка зберігає в пам’яті тільки видимі та prefetched комірки. Періодичне очищення старих даних (відкидання сторінок далі за N сторінок) також знижує навантаження.