ایپس میں لاتعداد اسکرول: یہ کیا ہے، اصول اور نفاذ

موبائل ایپس میں لاتعداد اسکرول کیا ہے؟

لاتعداد اسکرول (Infinite Scroll) ایک ڈیٹا لوڈنگ پیٹرن ہے جس میں صارف کے اسکرول کرنے پر فہرست کے انت میں خودکار طریقے سے نئے عناصر شامل ہو جاتے ہیں۔ صارف «اگلا» یا «مزید لوڈ کریں» بٹن پر کلک نہیں کرتا — سیسٹم خود طے کرتا ہے کہ ڈیٹا کے اگلے بیچ کب مانگنا ہے اور نئی انٹریز کو موجودہ فہرست میں بدریج شامل کرتا ہے۔

Infinite Scroll نے سماجی میڈیا کی بدولت مقبولیت حاصل کی — Twitter، Instagram اور TikTok اسے اپنے بنیادی مواد تقسیم کے طریقے کے طور پر استعمال کرتے ہیں۔ Nielsen Norman Group (2024) کے مطابق، Infinite Scroll مواد کی ایپس کے لیے مصروفیت میں 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 پر ایک لوڈنگ اشارہ (فوٹر میں اسپائنر) دکھایا جاتا ہے۔ درج کرنا: نئے عناصر ایڈاٹر میں شامل کیے جاتے ہیں، چھالاں سے بچنے کے لیے اسکرول پوزیشن کو ایڈجسٹ کیا جاتا ہے۔

ایک اہم پہلو درخواستوں کا debouncing ہے۔ اگر صارف تیزی سے انت تک اسکرول کرتا ہے، تو سرور سے جواب ملنے سے پہلے ہی متحرک کائی بار چل سکتا ہے۔ debounce کے بغیر، یہ دوہرانے درخواستوں (ریس کنڈیشن) کا سبب بنتا ہے۔ حل یہ ہے کہ پځھلے درخواست کے مکمل ہونے تک نئے درخواستوں کو بلاک کیا جائے۔ ViewModel میں ایک isLoading فلیگ اکثر کالز کو روکتا ہے: درخواست بھیجتے وقت isLoading = true سیٹ کریں، جواب یا غلطی ملنے پر ریسیٹ کریں۔

موبائل پلیٹ فارمز پر، لاتعداد اسکرول کے لیے خاص میکانزم استعمال کیے جاتے ہیں۔ iOS پر، UICollectionView میں prefetchDataSource استعمال کیا جاتا ہے، جو آن کے باہر سیلوں کے لیے خودکار طریقے سے ڈیٹا مانگتا ہے۔ Android پر، Google کی Paging 3 لائبریری استعمال کی جاتی ہے، جو PagingSource، PagingData اور PagingDataAdapter کے ساتھ ایک تیار آرکی ٹیکچر فراہم کرتی ہے۔ Paging 3 نیٹورک اور مقامی ڈیٹا کو ملانے کے لیے RemoteMediator کی حمایت کرتی ہے اور خودکار طریقے سے لوڈنگ کی حالت کا انتظام کرتی ہے۔

Cursor-based بنام Offset-based پیجینیشن

Offset-based پیجینیشن page اور size پیرامیٹرز استعمال کرتی ہے: page=2, size=20 ریکارڈ 21–40 واپس کرتا ہے۔ یہ طریقہ نفاذ میں سادہ ہے لیکن اسمیں ایک بنیادی مسئلہ ہے — اگر درخواستوں کے درمیان ڈیٹابیس میں ریکارڈ شامل یا حذف کیے جاتے ہیں، تو آف سیٹ بے جزا ہو جاتا ہے (صارف ڈپلیکیٹس یا خلا جگہیں دیکھتا ہے)۔ اعلی تبدیلی فریکونسی کے فیڈز (خبریں، تبصرے) کے لیے offset-based پیجینیشن غلط نتائج دیتی ہے۔

Cursor-based پیجینیشن آخری عنصر کے ایک منفرد شناختی (cursor) کا استعمال کرتی ہے: after=id_12345&limit=20۔ سرور متعین کرسر کے بعد 20 ریکارڈ واپس کرتا ہے۔ یہ طریقہ انسریشنز اور ڈیلیشنز سے آزاد ڈیٹا مستقلیمی کی ضمانت دیتا ہے۔ GraphQL Best Practices (2024) کے مطابق، ان سب ریال ٹائم ایپس کے لیے cursor-based پیجینیشن کی سفارش کی جاتی ہے جہاں ڈیٹا متحرک طور پر بدلتا ہے۔

دونوں طریقوں کے درمیان انتخاب ایپس کی قسم پر منحصر ہے۔ سماجی میڈیا (Instagram, TikTok) کے لیے — صرف cursor-based، کیونکہ فیڈ مسلسل اپ ڈیٹ ہوتا رہتا ہے۔ محدود تبدیلیوں والے کیٹالوگ (آن لائن اسٹور کے مصنوعات کے زمرہ) کے لیے offset-based پیجینیشن قابل قبول ہے۔ هائبرڈ مناظر کے لیے، Google Paging 3 RemoteMediator کی سفارش کرتا ہے، جو نیٹورک سے cursor-based پیجینیشن کو مقامی Room ڈیٹابیس سے offset-based پیجینیشن کے ساتھ ملاتا ہے۔

iOS اور Android پر Infinite Scroll کا نفاذ

Android پر، معیاری طریقہ Jetpack سے Paging 3 لائبریری ہے۔ PagingSource ڈیٹا مخذ (نیٹورک یا ڈیٹابیس) کی وضاحت کرتا ہے، PagingData ڈیٹا کے چانک رکھتا ہے، اور PagingDataAdapter انہیں RecyclerView میں دیکھاتا ہے۔ Paging 3 خودکار طریقے سے prefetch فاصلہ، دوبارہ کوشش اور تازہ کرنے کا انتظام کرتا ہے۔ نیٹورک انٹیگریشن کے لیے RemoteMediator استعمال کیا جاتا ہے: یہ API سے ڈیٹا لوڈ کرتا ہے، Room میں محفوظ کرتا ہے، اور PagingSource کو اپ ڈیٹ کے بارے میں مطلع کرتا ہے۔ Google I/O 2024 کے مطابق، Infinite Scroll استعمال کرنے والے 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 پر، Infinite Scroll کو UICollectionView کے ساتھ prefetchDataSource استعمال کرکے نفاذ کیا جاتا ہے۔ UICollectionViewDataSourcePrefetching پروٹوکل میں collectionView(_:prefetchItemsAt:) طریقہ ہے، جو تب کال کیا جاتا ہے جب سیسٹم مختصص index paths پر اسکرول کی پیش گوئی لگاتا ہے۔ Android Paging 3 کے برخلاف، iOS میں کوئی بیلٹ ان پیجینیشن لائبریری نہیں ہے — ڈیویلپرز اسے دستی طور پر نفاذ کرتے ہیں یا RxSwift + NSLayoutConstraint یا Combine پر مبنی پائپ لائنز جیسے تیسرے فریق کے حل استعمال کرتے ہیں۔

iOS پر prefetch کی مثال:

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 کے مطابق، نئے AsyncSequence اور Swift Algorithms API بیلٹ ان chunking اور debounce آپریٹرز فراہم کرکے Infinite Scroll کے نفاذ کو آسان بناتے ہیں۔

لاتعداد اسکرول کے UX مسائل اور ان کے حل

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

دوسرا مسئلہ اسکرول هسٹری کی کمی ہے۔ اگر کوئی صارف مقام 3 پر ایک دلچسپ مصنوع دیکھتا ہے، مقام 50 تک اسکرول کرتا ہے، اور پھر «واپس» دباتا ہے — تو وہ فہرست کے اوپر واپس آتا ہے اور دوبارہ مقام 50 تک اسکرول کرنا پڑتا ہے۔ حل ViewModel میں اسکرول پوزیشن محفوظ کرنا یا Activity/UIViewController سطح پر حالت بحال استعمال کرنا ہے۔ iOS مقام بحال کے لیے NSUserActivity کی حمایت کرتا ہے، Android onSaveInstanceState کی حمایت کرتا ہے۔

تیسرا مسئلہ ہزاروں عناصر کے ساتھ کارکردگی ہے۔ اگر ورچوئلائزیشن ترتیب نہیں کی گئی، تو 500–1000 لوڈ شدہ عناصر کے بعد، میمری کی کھپت میں اضافے کی وجہ سے ایپس سسٹم سہل ہونے لگتا ہے۔ حل یہ ہے کہ RecyclerView یا UICollectionView کے ساتھ ورچوئلائزیشن استعمال کریں، جو صرف نمائیاں + prefetched سیلز کو میمری میں رکھتا ہے۔ پرانے ڈیٹا کی متوقتہ صفائی (N صفحوں سے آگے کے صفحے کو ضائع کرنا) بھی بوجھ کو کم کرتا ہے۔