CoroutineScope — یہ کیا ہے، لائف سائیکل اور کوروٹین میں کام

Kotlin میں CoroutineScope کیا ہے؟

CoroutineScope kotlinx.coroutines لائبریری کا ایک بنیادی انٹرفیس ہے جو کوروٹین کے لیے کنٹینر کا کام کرتا ہے۔ یہ کوروٹین لائف سائیکل کی حدود کی وضاحت کرتا ہے: جب scope مکمل ہوتا ہے، تو اس کے اندر کی تمام کوروٹین خود بخود منسوخ ہو جاتی ہیں۔

public interface CoroutineScope {
    public val coroutineContext: CoroutineContext
}

انٹرفیس میں صرف ایک فیلڈ ہے — coroutineContext۔ اس کے ذریعے، scope اس کے اندر شروع کی گئی تمام کوروٹین کے لیے ایک ڈسپیچر (Dispatcher)، جاب (Job)، استثنا ہینڈلر اور دیگر سیاق عناصر فراہم کرتا ہے۔

kotlinx.coroutines لائبریری میں کردار

کوروٹین شروع کرنے والے تمام فنکشن — launch، async، runBlocking — CoroutineScope پر توسیعی فنکشن ہیں۔ اس کا مطلب ہے کہ انہیں صرف اس وقت کال کیا جا سکتا ہے جب scope آبجیکٹ موجود ہو۔ یہ ڈیزائن اس بات کو یقینی بناتا ہے کہ ہر کوروٹین کا واضح طور پر متعین پیرنٹ اور لائف سائیکل ہو۔

CoroutineScope کہاں استعمال ہوتا ہے

Android میں، ہر آرکیٹیکچرل کمپوننٹ کا اپنا scope ہوتا ہے: ViewModel کے لیے viewModelScope، Activity/Fragment کے لیے lifecycleScope۔ سرور ایپلیکیشن میں، scope کو HTTP درخواست یا ڈیٹابیس کنکشن پول سے منسلک کیا جا سکتا ہے۔

CoroutineScope کیسے کام کرتا ہے: Job اور ساختی ہم وقتی

CoroutineScope کے اندرونی کام کو سمجھنے کے لیے Job کے تصور اور ساختی ہم وقتی کے اصول سے واقفیت ضروری ہے۔

Job — کوروٹین کا کام

ہر کوروٹین شروع ہونے پر ایک Job آبجیکٹ (یا async کے لیے Deferred) لوٹاتا ہے۔ Job ایک محدود لائف سائیکل والے کام کی نمائندگی کرتا ہے: New، Active، Completing، Completed، Cancelling، Cancelled۔ Job آبجیکٹ ایک درخت کی ساخت بناتے ہیں:

• پیرنٹ Job — وہ scope جس میں کوروٹین شروع کی گئی
• چائلڈ Job — launch/async کے ذریعے شروع کی گئی ہر کوروٹین
• پیرنٹ کی منسوخی → تمام چائلڈ کی منسوخی
• چائلڈ میں استثنا → پیرنٹ کی منسوخی (supervisorScope کے علاوہ)

ساختی ہم وقتی کا اصول

ساختی ہم وقتی Kotlin Coroutines کا ایک اہم آرکیٹیکچرل اصول ہے، جس میں کوروٹین کا لائف سائیکل اس کے scope کے لائف سائیکل سے منسلک ہوتا ہے۔ یہ “فائر اینڈ فارگیٹ” ماڈل کے برعکس ہے، جہاں scope مکمل ہونے کے بعد بھی کوروٹین زندہ رہتا ہے۔ ساختی ہم وقتی کے فوائد:

• پیش قیاسی لائف سائیکل — جب scope مکمل ہوتا ہے، تمام کوروٹین رک جاتی ہیں
• خودکار غلطی کا انتظام — کسی بھی چائلڈ کوروٹین میں استثنا scope تک پھیل جاتا ہے
• کوئی میموری لیک نہیں — scope مکمل ہونے کے بعد کوئی کوروٹین چلتی نہیں رہتی
• واضح درجہ بندی — کوڈ متوازی کارروائیوں کی منطقی ساخت کو ظاہر کرتا ہے

CoroutineScope کا لائف سائیکل

جب scope.cancel() کال کیا جاتا ہے، scope کا Job Cancelled حالت میں چلا جاتا ہے، جو تمام چائلڈ Job کو بار بار منسوخ کرتا ہے۔ منسوخی کے بعد، scope صرف نیا CoroutineScope مثال بنا کر ہی دوبارہ استعمال کیا جا سکتا ہے۔

CoroutineScope بنانا اور ترتیب دینا

آپ CoroutineScope کو فیکٹری فنکشن کے ذریعے یا اپنی کلاس میں انٹرفیس لاگو کر کے بنا سکتے ہیں۔ دونوں طریقوں کو دیکھتے ہیں۔

فیکٹری فنکشن CoroutineScope()

val scope = CoroutineScope(Dispatchers.Default + SupervisorJob())

scope.launch {
    println("Running on ${Thread.currentThread().name}")
}

فیکٹری فنکشن CoroutineContext لیتا ہے اور مخصوص سیاق کے ساتھ scope بناتا ہے۔ مثال CPU-گہرے کاموں کے لیے Dispatchers.Default اور SupervisorJob استعمال کرتی ہے، جو چائلڈ کوروٹین کے درمیان استثنا کو الگ کرتا ہے۔

کمپوزیشن کے ذریعے انٹرفیس لاگو کرنا

class MyRepository {
    private val scope = CoroutineScope(Dispatchers.IO + Job())

    suspend fun fetchData(): Data = scope.async {
        api.getData()
    }.await()

    fun cleanup() {
        scope.cancel()
    }
}

ہم scope کو کلاس فیلڈ کے طور پر محفوظ کرتے ہیں اور اسے منسوخ کرنے کے لیے دستی طور پر cleanup کال کرتے ہیں۔ یہ طریقہ منظم لائف سائیکل والے کمپوننٹ — جیسے ریپوزٹری یا مینیجر — کے لیے موزوں ہے۔

ڈیلیگیشن کے ذریعے نفاذ

Kotlin by کلیدی لفظ کے ذریعے CoroutineScope کے نفاذ کو ڈیلیگیٹ کرنے کی اجازت دیتا ہے:

class DataLoader : CoroutineScope by CoroutineScope(Dispatchers.IO) {
    fun load() {
        launch {
            // coroutine runs in DataLoader scope
        }
    }
}

یہ طریقہ اس وقت مفید ہے جب کلاس خود ایک scope ہو اور کوروٹین شروع کرنے کے طریقے فراہم کرنا چاہے۔ تاہم محتاط رہیں: کلاس CoroutineScope کے تمام طریقے (cancel سمیت) وراثت میں لے لیتی ہے، جو encapsulation کو توڑ سکتا ہے۔

GlobalScope بمقابلہ کسٹم CoroutineScope

GlobalScope پوری ایپلیکیشن کے لیے ایک سنگلٹن CoroutineScope ہے۔ پروڈکشن کوڈ میں اس کا استعمال سرکاری طور پر تجویز نہیں کیا جاتا۔

GlobalScope کے مسائل

• ساختی ہم وقتی کی کمی — GlobalScope میں کوروٹین کمپوننٹ لائف سائیکل سے منسلک نہیں ہوتیں
• میموری لیک — Activity/Fragment بند ہونے کے بعد بھی کوروٹین چلتی رہ سکتی ہے
• مشکل جانچ — GlobalScope کو ٹیسٹ میں تبدیل نہیں کیا جا سکتا
• بے قابو وسائل کی کھپت — بہت سی کوروٹین متوقع سے زیادہ دیر چل سکتی ہیں

GlobalScope کب جائز ہے

JetBrains GlobalScope کو صرف نایاب منظرناموں میں اجازت دیتا ہے: ایپلیکیشن سطح کے پس منظر کے عمل جو تمام Activity بند ہونے کے بعد بھی چلنے چاہئیں (جیسے ڈیٹا سنکرونائزیشن، تجزیات)۔ لیکن ان صورتوں میں بھی، CoroutineScope(SupervisorJob()) کے ساتھ اپنا scope بنانا بہتر ہے۔

سفارش

واضح لائف سائیکل انتظام کے ساتھ ہمیشہ کسٹم CoroutineScope استعمال کریں۔ Android میں، یہ viewModelScope اور lifecycleScope ہیں۔ سرور ایپلیکیشن میں، ہر درخواست یا کنکشن پول کے لیے scope بنائیں۔

coroutineScope بمقابلہ supervisorScope: فرق کیا ہے

دونوں فنکشن معطل فنکشن ہیں جو متوازی کاموں کے لیے عارضی scope بناتے ہیں، لیکن استثنا کے ساتھ ان کا رویہ بنیادی طور پر مختلف ہے۔

coroutineScope کب انتخاب کریں

coroutineScope استعمال کریں جب متعدد متوازی کارروائیاں ایک واحد ایٹمی عمل تشکیل دیں۔ مثال کے طور پر، تین سرورز سے ڈیٹا لوڈ کرنا: اگر ایک درخواست ناکام ہو، باقی بے معنی ہیں۔

suspend fun loadProductPage(): ProductPage = coroutineScope {
    val product = async { api.getProduct() }
    val reviews = async { api.getReviews() }
    ProductPage(product.await(), reviews.await())
}

اگر getProduct یا getReviews استثنا پھینکتا ہے — دونوں کوروٹین منسوخ ہو جاتی ہیں اور استثنا کالر کوڈ میں پھیل جاتا ہے۔

supervisorScope کب انتخاب کریں

supervisorScope استعمال کریں جب متوازی کارروائیاں ایک دوسرے پر منحصر نہ ہوں۔ مثال کے طور پر، متعدد آزاد حصوں میں پروفائل ڈیٹا لوڈ کرنا: اگر سفارشات کا حصہ ناکام ہو، پروفائل ہیڈر اور دوستوں کی فہرست ظاہر ہونی چاہیے۔

CoroutineScope کے ساتھ کام کرتے وقت عام غلطیاں

Kotlin میں CoroutineScope استعمال کرتے وقت ڈویلپرز کی سب سے عام غلطیوں پر نظر ڈالتے ہیں۔

غلطی 1: Scope منسوخ کرنا بھولنا

کوروٹین لیک کا سب سے عام منظرنامہ کمپوننٹ ختم ہونے پر cancel کال کیے بغیر scope بنانا ہے۔ اگر scope منسوخ نہیں کیا گیا، کوروٹین چلتی رہتی ہیں، اشیاء کے حوالے رکھتی ہیں۔ Android میں، viewModelScope یا lifecycleScope استعمال کریں، جو خود بخود منسوخ ہو جاتے ہیں۔

غلطی 2: Activity یا Fragment میں GlobalScope استعمال کرنا

GlobalScope Android کمپوننٹ لائف سائیکل کو نظر انداز کرتا ہے۔ Activity بند ہونے کے بعد GlobalScope میں شروع کی گئی کوروٹین چلتی رہے گی اور UI کو اپ ڈیٹ کرنے کی کوشش کرے گی — جو کریش کا سبب بنے گی۔ UI کمپوننٹ کے لیے ہمیشہ lifecycleScope استعمال کریں۔

غلطی 3: منسوخ شدہ scope کو دوبارہ استعمال کرنا

cancel() کال کرنے کے بعد، scope دوبارہ استعمال نہیں کیا جا سکتا — اس کے اندر کی تمام کوروٹین پہلے ہی مکمل ہو چکی ہیں۔ فیکٹری فنکشن کے ذریعے نیا CoroutineScope مثال بنائیں۔ Job() دوبارہ فعال کرنے کی حمایت نہیں کرتا۔

غلطی 4: CoroutineScope انٹرفیس کی غلط ڈیلیگیشن

by سے ڈیلیگیٹ کرنے پر، کلاس کو عوامی cancel() طریقہ ملتا ہے جو کہیں سے بھی کال کیا جا سکتا ہے، encapsulation توڑتا ہے۔ انٹرفیس ڈیلیگیٹ کرنے کے بجائے scope کو نجی فیلڈ کے طور پر محفوظ کریں۔