Offset Pagination sa mobile development: ano ito at kung paano ipatupad

Ano ang Offset Pagination?

Offset Pagination — ay isang paraan ng paghahati ng data nang pahina, kung saan ang request ng client ay naglalaman ng dalawang parameter: offset (ilang record lalaktawan) at limit (ilang record ibabalik). Ang server ay nagsasagawa ng SQL query na may OFFSET at LIMIT, nilalaktawan ang tinukoy na bilang ng mga row, at ibinabalik ang result set na may nakapirming laki.

Ang pamamaraan ay lumitaw sa relational database bilang pinakasimpleng paraan upang ayusin ang nabigasyon sa mga pahina at inilipat sa HTTP API kasabay ng pag-unlad ng REST architecture. Ang Offset Pagination ay hindi nangangailangan ng pag-imbak ng estado sa server — bawat request ay independyente at naglalaman ng lahat ng impormasyong kailangan para sa pagkuha.

Ayon sa pananaliksik sa disenyo ng API mula sa Postman (2025), ang offset-pagination ay ginagamit sa 72% ng pampublikong REST API, na ginagawa itong dominanteng pamantayan sa kabila ng mga kilalang limitasyon sa performance sa malalaking volume ng data.

Istraktura ng request at response

Ang tipikal na REST request na may Offset Pagination ay may kasamang query parameter na offset at limit. Ang response ay naglalaman ng listahan ng mga record ng hinihinging pahina at metadata para sa pagbuo ng nabigasyon interface.

Ang parameter na limit ay naglilimita sa bilang ng mga ibinalik na record at pinoprotektahan ang server at client mula sa labis na pagkarga. Mga tipikal na halaga ng limit — mula 10 hanggang 50 record bawat pahina depende sa pagiging kumplikado ng data.

data class PageRequest(
    val offset: Int,
    val limit: Int
)

data class PageResponse<T>(
    val items: List<T>,
    val total: Int,
    val hasMore: Boolean
)

fun RetrofitApi.fetchPage(request: PageRequest): Call<PageResponse<Item>>

Paano gumagana ang Offset Pagination

Offset Pagination ay na-convert sa SQL query na may OFFSET at FETCH NEXT (o LIMIT sa MySQL/SQLite). Ang database server ay nag-scan ng table, nilalaktawan ang bilang ng mga row na katumbas ng offset, at ibinabalik ang susunod na limit row. Kung mas malaki ang offset, mas matagal ang query.

Ang problema sa performance ay nauugnay sa katotohanan na ang database ay hindi direktang makapunta sa posisyong offset — kailangan nitong basahin at itapon ang lahat ng naunang row. Sa offset = 100000 at limit = 20, ang DBMS ay magbabasa ng 100020 row at magbabalik lamang ng 20.

SQL query sa ilalim ng hood

SQL — ang wika kung saan isinasagawa ng server ang offset-pagination. Sa PostgreSQL at MySQL ginagamit ang LIMIT, sa SQL Server at Oracle — OFFSET...FETCH. Iba't ibang DBMS ang nag-o-optimize ng query na ito sa kani-kanilang paraan, ngunit ang pangunahing problema sa pag-scan ay nananatiling pareho.

SELECT id, title, created_at
FROM articles
ORDER BY created_at DESC
OFFSET 100000 ROWS
FETCH NEXT 20 ROWS ONLY;

Problema sa consistency

Consistency ng data — pangunahing disadvantage ng Offset Pagination kapag nagtatrabaho sa mga dynamic na set. Kung sa pagitan ng dalawang request ng user ay may idinagdag na bagong record sa simula ng table, lahat ng umiiral na record ay lilipat. Nakikita ng user ang mga duplicate o paglaktaw.

Isipin ang isang table na may 100 record na may limit = 20. Sa pahina 1, nakikita ng user ang mga record 1-20. Ang administrator ay nagdagdag ng 5 bagong record. Sa pahina 2, nakikita ng user ang mga record 26-45 sa halip na inaasahang 21-40 — ang mga record 21-25 ay nalaktawan at ang mga record 21-25 mula sa nakaraang set ay na-duplicate sa pahina 1.

Offset vs Cursor-based: paghahambing ng mga approach

Cursor-based pagination — alternatibo sa Offset Pagination, na gumagamit ng pointer sa huling record ng kasalukuyang pahina. Sa halip na numerikong offset, ang client ay nagpapadala ng identifier ng huling natanggap na record, at ang server ay nagbabalik ng susunod na N record pagkatapos nito.

Ang cursor-based approach ay lumulutas sa problema ng consistency: ang posisyon ng cursor ay hindi nagbabago sa pagpasok o pagtanggal, dahil ang cursor ay tumutukoy sa isang partikular na record, hindi sa isang posisyon. Gayunpaman, ito ay mas kumplikadong ipatupad — nangangailangan ng natatanging field na maaaring ayusin (karaniwan ay ID o timestamp).

Ang pagpili sa pagitan ng mga approach ay nakadepende sa mga kinakailangan ng interface ng user. Kung kailangan ang nabigasyon na may numero ng pahina at direktang pagtalon — mas simple ang Offset Pagination. Para sa walang katapusang scroll o news feed, mas gusto ang mga cursor.

Keyset pagination

Keyset pagination — isang variant ng cursor-based approach, kung saan ang pag-filter ay ginagawa sa pamamagitan ng natatanging key gamit ang WHERE sa halip na OFFSET. Ang SQL query ay gumagamit ng kondisyong WHERE id > lastId, na nagpapahintulot sa database na gumamit ng index nang hindi nag-scan ng mga itinapon na row.

Ayon sa PostgreSQL Wiki, ang keyset pagination ay isinasagawa nang 100-1000 beses na mas mabilis kaysa sa offset query sa malalaking paglipat, dahil ang index scan ay pumapalit sa buong pag-ikot ng table. Disadvantage — hindi maaaring tumalon sa anumang pahina nang walang sunod-sunod na daan.

Kailan gagamitin ang Offset Pagination

Offset Pagination ay optimal para sa maliit at katamtamang laki ng data set (hanggang 10000 record), kung saan kailangan ng user ang interface na may numero ng pahina. Mga tipikal na scenario — admin panel, listahan ng order, catalog na may filter at pagination sa bawat pahina.

Para sa mobile application, ang offset-pagination ay angkop kapag naglo-load ng historical data, kung saan ang pagpasok ng bagong record ay bihira o imposible — halimbawa, kasaysayan ng order ng user, listahan ng natapos na gawain, archive ng transaksyon. Sa mga scenario na ito, hindi lumilitaw ang problema sa consistency.

Hindi inirerekomenda ang paggamit ng Offset Pagination para sa social media feed, listahan ng komento, chat at iba pang dynamic na set na may madalas na pagpasok. Sa mga kasong ito, ang paglaktaw at pagdoble ng record ay sumisira sa karanasan ng user at nangangailangan ng karagdagang logic ng deduplication sa client.

Hybrid approach

Hybrid pagination ay pinagsasama ang offset at cursor: ang unang request ay gumagamit ng offset para ipakita ang simula ng pahina, at ang mga sumusunod ay gumagamit ng cursor para mag-load ng walang katapusang scroll. Ang approach na ito ay ipinatupad sa Instagram at Twitter, kung saan ang unang pahina ay nilo-load sa pamamagitan ng cursor, ngunit ang offset ay ginagamit para kalkulahin ang posisyon kapag bumalik sa nakaraang view.

Ang implementasyon ng hybrid approach ay nangangailangan ng pag-imbak ng virtual na posisyon ng user sa client at koordinasyon ng dalawang mekanismo ng pagination sa server. Ayon sa blog ng Instagram Engineering, ang kanilang team ay gumagamit ng cursor-based pagination na may karagdagang field na startCursor, na pumapalit sa offset para sa initial load.

Offset Pagination sa mga mobile application

Mga mobile application ay gumagamit ng Offset Pagination kasama ng Retrofit/OkHttp sa Android at URLSession/Combine sa iOS. Ang tipikal na pattern — pag-load ng susunod na pahina kapag nag-scroll sa dulo ng listahan sa pamamagitan ng RecyclerView.OnScrollListener o UICollectionView prefetching.

Ang implementasyon ng offset-pagination sa mobile client ay may tatlong component: manager ng pagination (nag-iimbak ng kasalukuyang offset at hasMore), adapter ng listahan (nagpapakita ng mga elemento at indicator ng pag-load), at repository (nagsasagawa ng mga request at humahawak ng mga error). Ang Android Jetpack ay nag-aalok ng Paging 3 Library, na sumusuporta sa parehong offset at cursor-based pagination mula sa labas ng kahon.

Implementasyon sa Kotlin na may Paging 3

Paging 3 — Android Jetpack library para sa pag-load ng data nang pahina. Ito ay nag-e-encapsulate ng logic ng pagination, kabilang ang pagsubaybay sa offset, pamamahala ng estado ng pag-load, at awtomatikong pag-load sa pag-scroll. Ang PagingSource ay tumutukoy ng mga key para sa susunod at nakaraang pahina.

class OffsetPagingSource(
    private val api: ApiService,
    private val limit: Int = 20
) : PagingSource<Int, Item>() {

    override suspend fun load(
        params: LoadParams<Int>
    ): LoadResult<Int, Item> {
        val offset = params.key ?: 0
        return try {
            val response = api.getItems(offset, limit)
            LoadResult.Page(
                data = response.items,
                prevKey = null,
                nextKey = if (response.hasMore) offset + limit else null
            )
        } catch (e: Exception) {
            LoadResult.Error(e)
        }
    }
}

PagingSource ay tumutukoy ng mga key na prevKey at nextKey para sa nabigasyon ng pahina. Sa offset-pagination, ang prevKey ay palaging null (hindi maaaring pumunta sa nakaraang pahina nang hindi nag-iimbak ng kasaysayan), at ang nextKey ay tumataas ng limit sa bawat pag-load, hanggang sa ang server ay magbalik ng hasMore = false. Ito ay isang simple at predictable na modelo para sa mobile listahan.

Mga karaniwang pagkakamali sa Offset Pagination

Unang pagkakamali — pag-asa sa pagkakasunod-sunod ng record nang walang pag-uuri. Ang Offset Pagination ay nangangailangan ng stable na ORDER BY sorting sa isang natatanging field. Kung wala ito, ang DBMS ay maaaring magbalik ng mga record sa anumang pagkakasunod-sunod, na nagdudulot ng random na duplicate at paglaktaw sa pagitan ng mga pahina.

Pangalawang pagkakamali — paggamit ng offset para kalkulahin ang numero ng pahina sa interface. Ang formula na page = offset / limit + 1 ay gumagana lamang sa kondisyon na walang record na natanggal o naidagdag sa pagitan ng mga pag-load. Sa dynamic na data, ang numero ng pahina ay nagiging hindi tumpak at nakikita ng user ang maling impormasyon.

Pangatlong pagkakamali — pagbalewala sa timeout ng query na may malaking offset. Sa offset na higit sa 100000, ang query ay maaaring tumagal ng mga sampung segundo, na humaharang sa interface at gumagamit ng resources ng server. Inirerekomenda na magtakda ng maximum na halaga ng offset sa antas ng API (halimbawa, 10000) at gumamit ng cursor-based pagination para sa malalaking volume.

Pang-apat na pagkakamali — hindi pagdaragdag ng total count sa response. Kung walang kabuuang bilang ng record, hindi maaaring ipakita ng client ang bilang ng mga pahina at ipatupad ang pagination na may numero. Gayunpaman, ang pag-compute ng COUNT(*) sa malalaking table ay mahal din — para sa mga set na higit sa 100000 record, gumamit ng tinatayang pagtatantya o limitahan ang maximum na halaga ng total.