کنکشن ٹوٹنا — عام وجوہات اور حل کے طریقے

موبائل ایپس میں «کنکشن ٹوٹنا» کا کیا مطلب ہے؟

کنکشن ٹوٹنا — ایک صارف کی اصطلاح جو اس صورتحال کو بیان کرتی ہے جب ایپ سرور سے کنکشن کھو دیتی ہے، اعمال کا جواب دینا بند کر دیتی ہے یا غلطی کے ساتھ ختم ہو جاتی ہے۔ تکنیکی طور پر یہ ہو سکتا ہے: نیٹ ورک کی غلطی (ٹائم آؤٹ، DNS ناکامی)، ANR (UI تھریڈ کا منجمد ہونا)، کریش (غیر ہینڈل شدہ استثنا) یا ریس کنڈیشن۔

صارف کے نقطہ نظر سے، یہ تمام منظرنامے ایک جیسے نظر آتے ہیں: ایپ کام کرنا بند کر دیتی ہے۔ ڈویلپرز کے لیے فرق تشخیص اور اصلاح کے طریقہ کار میں ہے۔ نیٹ ورک کی غلطیاں دوبارہ کوشش کے طریقہ کار سے حل ہوتی ہیں، ANR UI تھریڈ سے آپریشن ہٹا کر، کریش استثنا ہینڈلنگ سے۔

Crittercism (اب Apteligent) کے مطابق، اوسطاً ایک موبائل ایپ ہر کریش کے ساتھ 1-2% صارفین کھو دیتی ہے۔ 1 ملین صارفین والی ایپ کے لیے، اس کا مطلب ہے 10-20 ہزار کھوئی ہوئی انسٹالز فی ایک بگ۔ یہ خاص طور پر مالی اور طبی شعبوں کی ایپس کے لیے اہم ہے۔

کنکشن کھونے کی اہم وجوہات

غیر مستحکم نیٹ ورک — موبائل ڈیوائسز مسلسل Wi-Fi اور موبائل نیٹ ورک کے درمیان سوئچ کرتی ہیں، کوریج کے بغیر علاقوں (میٹرو، لفٹ، تہہ خانہ) میں داخل ہوتی ہیں۔ ہر سوئچ عارضی کنکشن کے نقصان کا سبب بنتا ہے جسے ایپ کو صحیح طریقے سے ہینڈل کرنا چاہیے۔

ٹائم آؤٹ — اگر سرور مقررہ ٹائم آؤٹ (عام طور پر 10-30 سیکنڈ) کے اندر جواب نہیں دیتا تو کلائنٹ SocketTimeoutException پھینکتا ہے۔ فیڈ بیک کے بغیر لمبے ٹائم آؤٹ صارف کے ذریعے منجمد ہونے کے طور پر سمجھے جاتے ہیں۔ ٹائم آؤٹ 15 سیکنڈ سے زیادہ نہ سیٹ کرنے کی سفارش کی جاتی ہے۔

val client = OkHttpClient.Builder()
    .connectTimeout(10, TimeUnit.SECONDS)
    .readTimeout(15, TimeUnit.SECONDS)
    .writeTimeout(15, TimeUnit.SECONDS)
    .retryOnConnectionFailure(true)
    .build()

ریس کنڈیشن — اس وقت ہوتی ہے جب متعدد تھریڈز بیک وقت ایک ہی ڈیٹا کو سنکرونائزیشن کے بغیر پڑھتے اور لکھتے ہیں۔ مثال کے طور پر، نیٹ ورک سے کیش اپ ڈیٹ کرنے کے متوازی UI تھریڈ میں کیش سے ڈیٹا لوڈ کرنا پرانا یا غلط ڈیٹا ظاہر کر سکتا ہے۔

• غیر ہینڈل شدہ استثنائیں کال بیک یا کوروٹین میں ایپ کریش کا سبب بنتی ہیں
• میموری دباؤ — سسٹم ایپ کو مار دیتا ہے جب فارگراؤنڈ ایپ کے لیے کافی میموری نہیں ہوتی
• لائف سائیکل ریس — ایک غیر مطابقت پذیر آپریشن Activity/Fragment کے تباہ ہونے کے بعد مکمل ہوتا ہے
• UI بلاک کرنا — مین تھریڈ پر نیٹ ورک یا ڈیٹا بیس آپریشن کرنے سے 5 سیکنڈ بعد ANR ہوتا ہے

غلطی برداشت کرنے والی ایپلیکیشنز کے لیے آرکیٹیکچر

Offline-first — ایک آرکیٹیکچرل پیٹرن جہاں مقامی اسٹوریج (Room, CoreData) سچائی کا واحد ذریعہ ہے۔ نیٹ ورک پس منظر میں ڈیٹا سنکرونائزیشن کے لیے استعمال ہوتا ہے۔ صارف نیٹ ورک کنکشن کے بغیر بھی مقامی کیش سے ہمیشہ تازہ ترین ڈیٹا دیکھتا ہے۔

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

class UserRepository(
    private val api: UserApi,
    private val dao: UserDao
) {
    suspend fun getUsers(): Result<List<User>> {
        return try {
            val remote = api.fetchUsers()
            dao.insertAll(remote)
            Result.success(remote)
        } catch (e: IOException) {
            val cached = dao.getAll()
            if (cached.isNotEmpty()) {
                Result.success(cached) // return cache on network error
            } else {
                Result.failure(e)
            }
        }
    }
}

سرکٹ بریکر — ایک پیٹرن جو سرور کو غیر دستیاب ہونے پر درخواستوں کے سیلاب سے بچاتا ہے۔ لگاتار N غلطیوں کے بعد، سرکٹ بریکر کھل جاتا ہے، اور تمام درخواستیں کنکشن کی کوشش کیے بغیر فوری طور پر غلطی لوٹاتی ہیں۔ ایک مقررہ ٹائم آؤٹ کے بعد، سرکٹ بریکر ٹیسٹ کی درخواست کے لیے آدھے کھلے حالت میں چلا جاتا ہے۔

نیٹ ورک کی غلطیوں کو کیسے ہینڈل کریں؟

ایکسپونینشل بیک آف — ایک معیاری دوبارہ کوشش کا طریقہ کار۔ پہلی ناکامی کے بعد، 1 سیکنڈ انتظار کریں؛ دوسری کے بعد، 2 سیکنڈ؛ پھر 4، 8، 16۔ سرور اور بیٹری کو اوور لوڈ نہ کرنے کے لیے زیادہ سے زیادہ دوبارہ کوششوں (عام طور پر 3-5) کو محدود کریں۔

صارف کا فیڈ بیک — نیٹ ورک کی غلطی پر، ایک واضح پیغام دکھائیں: «کوئی کنکشن نہیں»، «سرور عارضی طور پر دستیاب نہیں»، «اپنا انٹرنیٹ چیک کریں»۔ Snackbar یا Inline State View استعمال کریں۔ صارف کو کبھی تکنیکی غلطیاں (HTTP 500, SocketException) نہ دکھائیں۔

ConnectivityManager — نیٹ ورک کی نگرانی کے لیے Android API۔ ایپ کو تبدیلیوں پر ردعمل ظاہر کرنے دیں: کنکشن کھونے پر پلیس ہولڈر دکھائیں، بحالی پر خود بخود ڈیٹا اپ ڈیٹ کریں۔ iOS میں Network فریم ورک سے NWPathMonitor استعمال کریں۔

class NetworkMonitor(private val context: Context) {
    private val manager =
        context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager

    fun isOnline(): Boolean {
        val network = manager.activeNetwork ?: return false
        val caps = manager.getNetworkCapabilities(network) ?: return false
        return caps.hasCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET)
    }
}

نگرانی اور لاگنگ کے اوزار

Crashlytics (Firebase) — موبائل ایپس کے لیے ایک معیاری کریش رپورٹنگ ٹول۔ یہ تمام غیر ہینڈل شدہ استثناؤں کے اسٹیک ٹریس، OS ورژن، ڈیوائس ماڈل اور کریش کا وقت جمع کرتا ہے۔ یہ غلطیوں کو گروپ کرنے اور اصلاحات کے لیے ذمہ دار افراد مقرر کرنے کی اجازت دیتا ہے۔

Sentry — کارکردگی کی نگرانی کے ساتھ Crashlytics کا متبادل۔ یہ مخصوص لین دین (مثال کے طور پر، «صارف کی اجازت») کو ٹریس کرنے اور دیکھنے کی اجازت دیتا ہے کہ کس مرحلے پر غلطی ہوئی۔ کارکردگی کا ٹریسنگ نیٹ ورک ٹائم آؤٹ کو ایپ منطق میں بگ سے فرق کرنے میں مدد کرتا ہے۔

Timber — Android کے لیے لاگنگ لائبریری جو کلاس کے مطابق خود بخود ٹیگ شامل کرتی ہے۔ ڈیبگ بلڈ میں، تمام نیٹ ورک درخواستوں اور جوابات کو لاگ کریں۔ ریلیز بلڈ میں، Crashlytics.setCustomLog کے ذریعے صرف غلطیاں اور انتباہات لاگ کریں۔

Firebase Summit 2023 کے مطابق، وہ ایپس جنہوں نے Crashlytics + Performance Monitoring نافذ کیا، اہم بگ کا پتہ لگانے اور ٹھیک کرنے کا اوسط وقت 3 دن سے 4 گھنٹے تک کم کرتی ہیں۔ فعال صارفین کے 0.1% سے زیادہ تعدد والے ہر کریش کے لیے الرٹ سیٹ کرنے کی سفارش کی جاتی ہے۔