موبائل ڈیولپمنٹ میں Offset Pagination: یہ کیا ہے اور اسے کیسے لاگو کریں

Offset Pagination کیا ہے؟

Offset Pagination ڈیٹا کی پیجینیشن کا ایک طریقہ ہے جس میں کلائنٹ کی درخواست میں دو پیرامیٹر ہوتے ہیں: offset (کتنے ریکارڈ چھوڑنے ہیں) اور limit (کتنے ریکارڈ واپس کرنے ہیں)۔ سرور OFFSET اور LIMIT کے ساتھ SQL استفسار پر عمل کرتا ہے، مخصوص تعداد میں قطاریں چھوڑتا ہے اور ایک مقررہ سائز کا نتیجہ سیٹ واپس کرتا ہے۔

یہ طریقہ ریلیشنل ڈیٹا بیسز میں صفحہ نیویگیشن کو منظم کرنے کے آسان ترین طریقہ کے طور پر پیدا ہوا اور REST آرکیٹیکچر کی ترقی کے ساتھ HTTP API میں منتقل ہوا۔ Offset Pagination کو سرور پر حالت ذخیرہ کرنے کی ضرورت نہیں ہے — ہر درخواست آزاد ہے اور اس میں استفسار کے لیے تمام ضروری معلومات ہوتی ہیں۔

Postman (2025) کی API ڈیزائن رپورٹ کے مطابق، آفسیٹ پیجینیشن 72% عوامی REST API میں استعمال ہوتی ہے، جو بڑے ڈیٹا سیٹس پر معروف کارکردگی کی حدود کے باوجود اسے غالب معیار بناتی ہے۔

درخواست اور جواب کی ساخت

Offset Pagination کے ساتھ ایک عام REST درخواست میں استفسار کے پیرامیٹرز offset اور limit شامل ہوتے ہیں۔ جواب میں درخواست کردہ صفحہ کی ریکارڈ فہرست اور نیویگیشن انٹرفیس بنانے کے لیے میٹا ڈیٹا ہوتا ہے۔

Limit پیرامیٹر واپس کیے گئے ریکارڈز کی تعداد کو محدود کرتا ہے اور سرور اور کلائنٹ کو ضرورت سے زیادہ لوڈ سے بچاتا ہے۔ ڈیٹا کی پیچیدگی کے لحاظ سے limit کی عام قدریں 10 سے 50 ریکارڈ فی صفحہ ہوتی ہیں۔

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

Offset Pagination کیسے کام کرتی ہے

Offset Pagination OFFSET اور FETCH NEXT (یا MySQL/SQLite میں LIMIT) کی تعمیرات کے ساتھ SQL استفسار میں تبدیل ہوتی ہے۔ ڈیٹا بیس سرور ٹیبل کو اسکین کرتا ہے، آفسیٹ کے برابر قطاریں چھوڑتا ہے اور اگلی limit قطاریں واپس کرتا ہے۔ آفسیٹ جتنا بڑا ہوگا، استفسار اتنا ہی سست ہوگا۔

کارکردگی کا مسئلہ اس حقیقت سے متعلق ہے کہ ڈیٹا بیس براہ راست آفسیٹ پوزیشن پر نہیں جا سکتا — اسے پچھلی تمام قطاریں پڑھنی اور ضائع کرنی ہوتی ہیں۔ offset = 100000 اور limit = 20 پر، DBMS 100,020 قطاریں پڑھتا ہے اور صرف 20 واپس کرتا ہے۔

SQL استفسار کے اندر

SQL — وہ زبان جس میں سرور آفسیٹ پیجینیشن انجام دیتا ہے۔ PostgreSQL اور MySQL LIMIT استعمال کرتے ہیں، جبکہ SQL Server اور Oracle OFFSET...FETCH استعمال کرتے ہیں۔ مختلف DBMS اس استفسار کو مختلف طریقے سے بہتر بناتے ہیں، لیکن بنیادی اسکیننگ کا مسئلہ وہی رہتا ہے۔

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

مستقل مزاجی کا مسئلہ

ڈیٹا کی مستقل مزاجی متحرک سیٹ کے ساتھ کام کرتے وقت Offset Pagination کی سب سے بڑی خامی ہے۔ اگر دو صارف درخواستوں کے درمیان ٹیبل کے شروع میں ایک نیا ریکارڈ شامل کیا جاتا ہے، تو تمام موجودہ ریکارڈ منتقل ہو جاتے ہیں۔ صارف ڈپلیکیٹ یا خلا دیکھتا ہے۔

limit = 20 کے ساتھ 100 ریکارڈ کی ٹیبل پر غور کریں۔ صفحہ 1 پر، صارف ریکارڈ 1-20 دیکھتا ہے۔ ایک منتظم 5 نئے ریکارڈ شامل کرتا ہے۔ صفحہ 2 پر، صارف متوقع 21-40 کے بجائے ریکارڈ 26-45 دیکھتا ہے — ریکارڈ 21-25 چھوٹ گئے، اور پچھلے سیٹ کے ریکارڈ 21-25 صفحہ 1 پر ڈپلیکیٹ ہو گئے۔

Offset vs Cursor-based: طریقوں کا موازنہ

Cursor-based پیجینیشن Offset Pagination کا ایک متبادل ہے جو موجودہ صفحہ کے آخری ریکارڈ پر پوائنٹر استعمال کرتی ہے۔ عددی آفسیٹ کے بجائے، کلائنٹ آخری موصولہ ریکارڈ کا شناخت کنندہ بھیجتا ہے، اور سرور اس کے بعد اگلے N ریکارڈ واپس کرتا ہے۔

Cursor-based نقطہ نظر مستقل مزاجی کے مسئلے کو حل کرتا ہے: کرسر کی پوزیشن اندراج یا حذف کرنے پر تبدیل نہیں ہوتی کیونکہ کرسر پوزیشن کے بجائے ایک مخصوص ریکارڈ کا حوالہ دیتا ہے۔ تاہم، یہ نفاذ میں زیادہ پیچیدہ ہے — اس کے لیے ایک منفرد ترتیب پذیر فیلڈ (عام طور پر ID یا timestamp) کی ضرورت ہوتی ہے۔

طریقوں کے درمیان انتخاب صارف کے انٹرفیس کی ضروریات پر منحصر ہے۔ اگر صفحہ نمبروں اور براہ راست چھلانگ کے ساتھ نیویگیشن کی ضرورت ہو — Offset Pagination آسان ہے۔ لامتناہی اسکرول یا نیوز فیڈز کے لیے، کرسر ترجیح دیے جاتے ہیں۔

Keyset پیجینیشن

Keyset پیجینیشن cursor-based نقطہ نظر کی ایک قسم ہے جس میں OFFSET کے بجائے WHERE کا استعمال کرتے ہوئے منفرد کلید پر فلٹرنگ کی جاتی ہے۔ SQL استفسار WHERE id > lastId جیسی شرط استعمال کرتا ہے، جو ڈیٹا بیس کو ضائع شدہ قطاروں کو اسکین کیے بغیر انڈیکس استعمال کرنے کی اجازت دیتا ہے۔

PostgreSQL Wiki کے مطابق، keyset پیجینیشن بڑے آفسیٹس پر آفسیٹ استفسارات سے 100-1000 گنا تیز چلتی ہے کیونکہ انڈیکس اسکین مکمل ٹیبل اسکین کی جگہ لے لیتا ہے۔ نقصان یہ ہے کہ ترتیبی گزراؤ کے بغیر کسی بھی صفحہ پر چھلانگ نہیں لگا سکتے۔

Offset Pagination کب استعمال کریں

Offset Pagination چھوٹے سے درمیانے ڈیٹا سیٹس (10,000 ریکارڈ تک) کے لیے بہترین ہے جہاں صارف کو صفحہ نمبر انٹرفیس کی ضرورت ہوتی ہے۔ عام منظرناموں میں ایڈمن پینلز، آرڈر کی فہرستیں اور صفحہ پر مبنی پیجینیشن کے ساتھ فلٹر شدہ کیٹلاگ شامل ہیں۔

موبائل ایپلیکیشنز کے لیے، آفسیٹ پیجینیشن تاریخی ڈیٹا لوڈ کرتے وقت موزوں ہے جہاں نئے اندراج نایاب یا ناممکن ہوں — مثال کے طور پر، صارف کے آرڈر کی تاریخ، مکمل کاموں کی فہرستیں، لین دین کا آرکائیو۔ ان منظرناموں میں، مستقل مزاجی کا مسئلہ پیدا نہیں ہوتا۔

سوشل میڈیا فیڈز، تبصرے کی فہرستوں، چیٹس اور بار بار اندراج والے دیگر متحرک سیٹس کے لیے سفارش نہیں کی جاتی۔ ان صورتوں میں، خلا اور ڈپلیکیٹ ریکارڈ صارف کے تجربے کو خراب کرتے ہیں اور کلائنٹ پر اضافی ڈیڈپلیکیشن منطق کی ضرورت ہوتی ہے۔

مخلوط طریقہ

مخلوط پیجینیشن offset اور cursor کو یکجا کرتی ہے: پہلی درخواست ابتدائی صفحہ دکھانے کے لیے offset استعمال کرتی ہے، جبکہ بعد کی درخواستیں لامتناہی اسکرول لوڈنگ کے لیے cursor استعمال کرتی ہیں۔ یہ طریقہ Instagram اور Twitter میں استعمال ہوتا ہے، جہاں پہلا صفحہ cursor کے ذریعے لوڈ ہوتا ہے، لیکن پچھلے منظر پر واپسی پر پوزیشن کا حساب لگانے کے لیے offset استعمال ہوتا ہے۔

مخلوط طریقہ کو لاگو کرنے کے لیے کلائنٹ پر صارف کی مجازی پوزیشن ذخیرہ کرنے اور سرور پر دو پیجینیشن میکانزم کو مربوط کرنے کی ضرورت ہوتی ہے۔ Instagram Engineering بلاگ کے مطابق، ان کی ٹیم ابتدائی لوڈنگ کے لیے offset کو تبدیل کرنے والے اضافی startCursor فیلڈ کے ساتھ cursor-based پیجینیشن استعمال کرتی ہے۔

موبائل ایپلیکیشنز میں Offset Pagination

موبائل ایپلیکیشنز Android پر Retrofit/OkHttp اور iOS پر URLSession/Combine کے ساتھ Offset Pagination استعمال کرتی ہیں۔ عام نمونہ RecyclerView.OnScrollListener یا UICollectionView prefetching کے ذریعے فہرست کے آخر تک اسکرول کرنے پر اگلا صفحہ لوڈ کرنا ہے۔

موبائل کلائنٹ پر آفسیٹ پیجینیشن کے نفاذ میں تین اجزاء شامل ہیں: ایک پیجینیشن مینیجر (موجودہ offset اور hasMore ذخیرہ کرتا ہے)، ایک فہرست ایڈاپٹر (آئٹمز اور لوڈنگ اشارے دکھاتا ہے)، اور ایک ذخیرہ (درخواستیں انجام دیتا ہے اور خرابیوں کو سنبھالتا ہے)۔ Android Jetpack Paging 3 لائبریری پیش کرتا ہے، جو باکس سے باہر offset اور cursor-based دونوں پیجینیشن کو سپورٹ کرتی ہے۔

Paging 3 کے ساتھ Kotlin میں نفاذ

Paging 3 صفحہ بہ صفحہ ڈیٹا لوڈ کرنے کے لیے Android Jetpack لائبریری ہے۔ یہ آفسیٹ ٹریکنگ، لوڈنگ اسٹیٹ مینجمنٹ اور اسکرول پر خودکار پریفچنگ سمیت پیجینیشن منطق کو سمیٹتی ہے۔ PagingSource اگلے اور پچھلے صفحات کی کنجیاں متعین کرتا ہے۔

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 صفحہ نیویگیشن کے لیے prevKey اور nextKey کنجیاں متعین کرتا ہے۔ آفسیٹ پیجینیشن کے ساتھ، prevKey ہمیشہ null ہوتا ہے (تاریخ محفوظ کیے بغیر پچھلے صفحہ پر نہیں جا سکتے)، جبکہ nextKey ہر لوڈ کے ساتھ limit سے بڑھتا ہے جب تک سرور hasMore = false واپس نہ کرے۔ یہ موبائل فہرستوں کے لیے ایک سادہ اور پیش قیاسی ماڈل ہے۔

Offset Pagination میں عام غلطیاں

پہلی غلطی — ترتیب دیے بغیر ریکارڈ کی ترتیب پر انحصار کرنا۔ Offset Pagination کو ایک منفرد فیلڈ پر مستحکم ORDER BY ترتیب درکار ہے۔ اس کے بغیر، DBMS ریکارڈ من مانی ترتیب میں واپس کر سکتا ہے، جس سے صفحات کے درمیان بے ترتیب ڈپلیکیٹ اور خلا پیدا ہوتے ہیں۔

دوسری غلطی — UI میں صفحہ نمبر کا حساب لگانے کے لیے offset استعمال کرنا۔ فارمولا page = offset / limit + 1 صرف اس وقت کام کرتا ہے جب لوڈنگ کے درمیان کوئی ریکارڈ حذف یا شامل نہ کیا گیا ہو۔ متحرک ڈیٹا کے ساتھ، صفحہ نمبر غلط ہو جاتا ہے اور صارف غلط معلومات دیکھتا ہے۔

تیسری غلطی — بڑے offset والے استفسار کے ٹائم آؤٹ کو نظر انداز کرنا۔ 100,000 سے زیادہ offset پر، استفسار دسیوں سیکنڈ لے سکتا ہے، UI کو روک سکتا ہے اور سرور کے وسائل استعمال کر سکتا ہے۔ API سطح پر زیادہ سے زیادہ offset قدر (مثلاً 10,000) مقرر کرنے اور بڑے حجم کے لیے cursor-based پیجینیشن استعمال کرنے کی سفارش کی جاتی ہے۔

چوتھی غلطی — جواب میں total count شامل نہ کرنا۔ ریکارڈ کی کل تعداد کے بغیر، کلائنٹ صفحہ کی گنتی ظاہر نہیں کر سکتا اور نمبر والی پیجینیشن لاگو نہیں کر سکتا۔ تاہم، بڑی میزوں پر COUNT(*) مہنگا ہے — 100,000 ریکارڈ سے زیادہ سیٹس کے لیے، قریبی تخمینے استعمال کریں یا زیادہ سے زیادہ کل قدر محدود کریں۔