मोबाइल डेवलपमेंट में पेजिनेशन — यह क्या है, प्रकार और कार्य सिद्धांत

पेजिनेशन क्या है?

पेजिनेशन (अंग्रेज़ी pagination — पृष्ठ विभाजन) एक तकनीक है जो एक बड़े डेटा सेट को क्रमिक भागों (पृष्ठों) में विभाजित करती है। मोबाइल ऐप्लिकेशन में, पेजिनेशन का उपयोग संदेश सूचियों, समाचार फ़ीड, उत्पाद सूची, ऑर्डर इतिहास और संभावित रूप से असीमित रिकॉर्ड वाले किसी भी संग्रह को लोड करते समय किया जाता है।

पेजिनेशन के बिना, ऐप्लिकेशन को सभी डेटा एक साथ लोड करने के लिए मजबूर होना पड़ता है, जिससे लंबी प्रतीक्षा, उच्च ट्रैफ़िक खपत और कमज़ोर उपकरणों पर अस्थिर प्रदर्शन होता है। पेजिनेशन वाला API अनुरोध डेटा का केवल एक भाग और अगला भाग लोड करने के लिए मेटा-जानकारी लौटाता है — इस प्रकार, ऐप्लिकेशन प्राप्त जानकारी की मात्रा को नियंत्रित करता है।

पेजिनेशन के मुख्य मीट्रिक: पृष्ठ आकार (page size) — एक पृष्ठ पर रिकॉर्ड की संख्या (आमतौर पर 10–50), और पृष्ठ संख्या या कर्सर — सेट में वर्तमान स्थिति का संकेतक। पृष्ठ आकार का चुनाव डेटा के प्रकार पर निर्भर करता है: कॉम्पैक्ट तत्वों (नाम) के लिए 20–30 पर्याप्त हैं, चित्रों वाले कार्ड के लिए — 10–15।

मोबाइल ऐप्लिकेशन में पेजिनेशन की आवश्यकता क्यों

मोबाइल उपकरणों में सीमित संसाधन होते हैं: रैम, प्रोसेसर की गति और ट्रैफ़िक सीमाएँ। पेजिनेशन तीन मुख्य कार्यों को हल करता है: मेमोरी खपत में कमी (केवल दृश्य तत्व मेमोरी में संग्रहीत होते हैं), पहले प्रदर्शन में तेज़ी (पहला भाग पूरे सेट की तुलना में तेज़ी से लोड होता है), और ट्रैफ़िक की बचत (डेटा तभी लोड होता है जब उपयोगकर्ता सूची को स्क्रॉल करता है)।

पेजिनेशन के मुख्य प्रकार

पेजिनेशन के चार मुख्य प्रकार हैं, प्रत्येक विशिष्ट कार्यों को हल करता है। विधि का चुनाव डेटा स्थिरता आवश्यकताओं, API आर्किटेक्चर, स्टोरेज प्रकार और क्लाइंट और सर्वर पर कार्यान्वयन की स्वीकार्य जटिलता पर निर्भर करता है।

कब किस प्रकार का उपयोग करें

Offset पेजिनेशन स्थिर या शायद ही कभी अपडेट होने वाले डेटा सेट के लिए उपयुक्त है, जब सरल कार्यान्वयन महत्वपूर्ण हो। Cursor और Keyset बार-बार सम्मिलन वाले गतिशील डेटा के लिए हैं। Time-based कालानुक्रमिक फ़ीड के लिए है जहाँ रिकॉर्ड निर्माण समय के अनुसार क्रमबद्ध होते हैं। GraphQL मानक Relay एकमात्र अनुशंसित विधि के रूप में कर्सर पेजिनेशन का उपयोग करता है।

Offset पेजिनेशन: लाभ और कमियाँ

Offset पेजिनेशन पृष्ठ-आधारित लोडिंग का सबसे सरल प्रकार है। क्लाइंट page और limit (या offset और limit) पैरामीटर भेजता है, और सर्वर SQL OFFSET और LIMIT लागू करता है। उदाहरण के लिए, page=2, limit=20 रिकॉर्ड 21 से 40 लौटाता है। यह विधि सहज है और किसी भी स्टैक पर लागू करना आसान है।

from fastapi import FastAPI, Query

app = FastAPI()

@app.get("/items")
async def get_items(
    page: int = Query(default=1, ge=1),
    limit: int = Query(default=20, le=100)
):
    offset = (page - 1) * limit
    items = await fetch_items(offset, limit)
    total = await count_items()
    return {
        "items": items,
        "total": total,
        "page": page,
        "pages": (total + limit - 1) // limit
    }

डेटा असंगति की समस्या

Offset पेजिनेशन का मुख्य दोष गुम और डुप्लिकेट रिकॉर्ड की समस्या है। यदि दो अनुरोधों के बीच तालिका में नए रिकॉर्ड जोड़े जाते हैं, तो OFFSET खिसक जाता है: उपयोगकर्ता एक ही रिकॉर्ड दो बार देख सकता है या एक नया रिकॉर्ड छोड़ सकता है। यह समाचार फ़ीड और चैट के लिए महत्वपूर्ण है जहाँ स्थिरता मायने रखती है।

एक और समस्या बड़े OFFSET मानों पर प्रदर्शन में गिरावट है। परिणाम लौटाने से पहले डेटाबेस को पहले offset रिकॉर्ड को स्कैन और छोड़ना पड़ता है। offset=100000 पर LIMIT 20 के साथ भी, सर्वर स्कैनिंग में उल्लेखनीय समय बिताएगा। PostgreSQL और MySQL OFFSET बढ़ने के साथ गति में रैखिक गिरावट दिखाते हैं।

Offset अभी भी कब अच्छा है

Offset पेजिनेशन इसके लिए सबसे अच्छा विकल्प बना हुआ है: प्रशासनिक पैनल (डेटा शायद ही कभी बदलता है, पृष्ठ नेविगेशन आवश्यक है), रिपोर्ट और ऐतिहासिक लॉग (डेटा का निश्चित स्नैपशॉट), फ़िल्टर के साथ सूची (किसी भी पृष्ठ पर जा सकते हैं)। Offset क्लाइंट पर लागू करना भी सबसे आसान है — RecyclerView Paging 3 के साथ इसे बॉक्स से बाहर समर्थन करता है।

Keyset और Time-based पेजिनेशन

Keyset पेजिनेशन रिकॉर्ड को फ़िल्टर करने के लिए एक अद्वितीय कुंजी (आमतौर पर प्राथमिक कुंजी) का उपयोग करता है। OFFSET के बजाय, क्वेरी WHERE id > last_seen_id का उपयोग करती है। यह रिकॉर्ड की संख्या की परवाह किए बिना स्थिर प्रदर्शन और सम्मिलन पर कोई डुप्लिकेट सुनिश्चित नहीं करता है, क्योंकि नए रिकॉर्ड में हमेशा बड़ा id होता है।

-- Offset पेजिनेशन (समस्याग्रस्त)
SELECT * FROM posts
ORDER BY id
LIMIT 20 OFFSET 100;

-- Keyset पेजिनेशन (स्थिर)
SELECT * FROM posts
WHERE id > 100
ORDER BY id
LIMIT 20;

Time-based पेजिनेशन

Time-based पेजिनेशन (या समय के अनुसार कर्सर) नेविगेशन के लिए created_at टाइमस्टैम्प का उपयोग करता है। क्लाइंट अंतिम लोड किए गए रिकॉर्ड का टाइमस्टैम्प भेजता है, और सर्वर उस टाइमस्टैम्प से पहले या बाद में बनाए गए रिकॉर्ड लौटाता है। यह विधि सोशल नेटवर्क और समाचार फ़ीड में लोकप्रिय है जहाँ रिकॉर्ड का क्रम प्रकाशन समय द्वारा निर्धारित होता है।

Time-based पेजिनेशन की एक विशेषता — यदि दो रिकॉर्ड एक ही मिलीसेकंड में बनाए जाते हैं तो डुप्लिकेट संभव हैं। इस समस्या को खत्म करने के लिए, एक अद्वितीय id के साथ समय-आधारित कुंजी को मिलाएँ: WHERE (created_at, id) < (last_time, last_id)। ऐसा समग्र कर्सर प्रत्येक रिकॉर्ड की विशिष्टता और सटीक क्रम की गारंटी देता है।

Keyset और Time-based की तुलना

Keyset पेजिनेशन के लिए एक अद्वितीय और नीरस रूप से बढ़ते मान (ऑटो-इंक्रीमेंट id, UUID v7) वाले कॉलम की आवश्यकता होती है। Time-based created_at वाली किसी भी तालिका के लिए उपयुक्त है, लेकिन इसके लिए अतिरिक्त डुप्लिकेट हैंडलिंग की आवश्यकता होती है। मुख्य अंतर: Keyset किसी भी सम्मिलन संचालन पर स्थिर रूप से काम करता है, जबकि Time-based समान टाइमस्टैम्प के प्रति संवेदनशील है।

अपने प्रोजेक्ट के लिए पेजिनेशन का प्रकार कैसे चुनें

पेजिनेशन के प्रकार का चुनाव डेटा की प्रकृति और उपयोगकर्ता अनुभव आवश्यकताओं पर निर्भर करता है। नीचे मोबाइल डेवलपमेंट में विशिष्ट परिदृश्यों के लिए सिफारिशें दी गई हैं। कोई सार्वभौमिक समाधान नहीं है — प्रत्येक विधि का एक क्षेत्र है जहाँ वह इष्टतम है।

• चैट / मैसेंजर — Cursor पेजिनेशन (संदेश id द्वारा)। नए संदेश शीर्ष पर जुड़ते हैं, कर्सर नहीं टूटता।
• समाचार फ़ीड — Time-based पेजिनेशन (created_at द्वारा)। रिकॉर्ड समय के अनुसार क्रमबद्ध होते हैं, कालक्रम महत्वपूर्ण है।
• उत्पाद सूची — Offset पेजिनेशन। उपयोगकर्ता किसी विशिष्ट पृष्ठ पर जा सकता है, डेटा शायद ही कभी बदलता है।
• ऑर्डर इतिहास — Cursor पेजिनेशन। स्थिरता महत्वपूर्ण है क्योंकि लोड के बीच नए ऑर्डर जुड़ते हैं।
• टिप्पणियाँ — Keyset पेजिनेशन। प्रत्येक टिप्पणी का अद्वितीय id होता है, बिना डुप्लिकेट के बड़ी मात्रा।

Paging 3 के साथ Android पर कार्यान्वयन

Android Paging 3 लाइब्रेरी PagingSource के माध्यम से सभी प्रकार के पेजिनेशन का समर्थन करती है। Offset के लिए — Int कुंजी (page) वाला PagingSource, Cursor के लिए — String या Long कुंजी (cursor) वाला। PagingSource स्वचालित रूप से लोडिंग, कैशिंग और त्रुटियों पर पुनः प्रयास का प्रबंधन करता है।

class PostPagingSource(
    private val api: PostApi
) : PagingSource<Long, Post>() {

    override suspend fun load(
        params: LoadParams<Long>
    ): LoadResult<Long, Post> {
        val cursor = params.key ?: Long.MAX_VALUE
        return try {
            val response = api.getPosts(cursor, params.loadSize)
            LoadResult.Page(
                data = response.items,
                prevKey = null,
                nextKey = response.items.lastOrNull()?.id
            )
        } catch (e: Exception) {
            LoadResult.Error(e)
        }
    }

    override fun getRefreshKey(state: PagingState<Long, Post>): Long? {
        return state.anchorPosition?.let {
            state.closestItemToPosition(it)?.id
        }
    }
}

पृष्ठ आकार के लिए सिफारिशें

पृष्ठ का आकार लोडिंग गति और प्रदर्शन की धारणा को प्रभावित करता है। मोबाइल ऐप्लिकेशन के लिए, इष्टतम सीमा प्रति पृष्ठ 10–25 आइटम है। 10 से कम — API पर बहुत अधिक अनुरोध और रुक-रुक कर स्क्रॉल। 25 से अधिक — धीमी नेटवर्क पर पहले भाग की धीमी लोडिंग।

चित्रों और वीडियो के लिए, पृष्ठ का आकार 5–10 तक कम करें, क्योंकि प्रत्येक तत्व को मीडिया लोड करने में अतिरिक्त समय लगता है। टेक्स्ट-आधारित सूचियों (टिप्पणियाँ, लॉग) के लिए, आकार को 30–50 रिकॉर्ड तक बढ़ाया जा सकता है। API के माध्यम से पृष्ठ आकार को कॉन्फ़िगरेबल बनाने की अनुशंसा की जाती है ताकि क्लाइंट विभिन्न नेटवर्क स्थितियों के अनुकूल हो सके।