shouldShowRequestPermissionRationale in Android — یہ کیا ہے، ظاہری منطق اور نفاذ

shouldShowRequestPermissionRationale کیا ہے

shouldShowRequestPermissionRationale Android میں Activity اور Fragment کلاسز کا ایک طریقہ ہے، جو مطابقت کے لیے ActivityCompat کے ذریعے دستیاب ہے۔ یہ اجازت کا نام لیتا ہے اور ایک Boolean لوٹاتا ہے جو بتاتا ہے کہ دوبارہ درخواست کرنے سے پہلے صارف کو اضافی وضاحت دکھانی چاہیے یا نہیں۔ یہ طریقہ Android 6.0 Marshmallow میں رن ٹائم اجازت ماڈل کے ساتھ ظاہر ہوا۔

دلیل کا طریقہ کار اجازت کے ڈائیلاگ کے ساتھ صارف کے تعامل کی تاریخ کو ٹریک کرنے پر مبنی ہے۔ سسٹم یاد رکھتا ہے کہ صارف نے پہلے درخواست مسترد کی تھی یا نہیں۔ اگر Never Ask Again پرچم سیٹ کیے بغیر انکار ہوا، تو shouldShowRequestPermissionRationale true لوٹاتا ہے۔ یہ ڈیولپر کے لیے ایک اشارہ ہے: صارف نہیں سمجھتا کہ اجازت کیوں ضروری ہے، اور اضافی وضاحت کی ضرورت ہے۔ Google میٹریل ڈیزائن رہنما خطوط کے مطابق، پہلے انکار کے بعد دلیل ڈائیلاگ دکھانے سے اجازت دوبارہ دینے کے امکانات 35 فیصد بڑھ جاتے ہیں۔

لوٹائی گئی قدروں کے معنی سمجھنا ضروری ہے: true کا مطلب ہے کہ ڈائیلاگ دکھانا معنی رکھتا ہے، false کا مطلب ہے کہ ڈائیلاگ یا تو ضروری نہیں (اجازت پہلے ہی دی گئی یا کبھی درخواست نہیں کی گئی) یا بیکار ہے (Never Ask Again فعال)۔ طریقہ اس بات کی ضمانت نہیں ہے کہ ڈائیلاگ دکھایا جائے گا — یہ صرف ایک سفارش دیتا ہے۔ ڈیولپر فیصلہ کرتا ہے کہ جواب میں کون سا UI دکھانا ہے۔

طریقہ کب متعارف ہوا

shouldShowRequestPermissionRationale API لیول 23 میں رن ٹائم اجازتوں کے طریقوں کے ایک گروپ کے ساتھ متعارف کرایا گیا تھا۔ Android 6.0 سے پہلے، تمام اجازتیں انسٹالیشن کے وقت درخواست کی جاتی تھیں، اور کسی وضاحت کے طریقہ کار کی ضرورت نہیں تھی — صارف ایک بار میں پوری فہرست قبول یا مسترد کرتا تھا۔ رن ٹائم ماڈل نے یہ ممکن بنایا کہ صارف سیاق و سباق کو سمجھے بغیر درخواست مسترد کر سکتا ہے، اور اسی لیے دلیل کی ضرورت ہے۔

shouldShowRequestPermissionRationale کیسے کام کرتا ہے

طریقہ کی منطق اس طرح کام کرتی ہے۔ کسی مخصوص اجازت کے لیے requestPermissions کی پہلی کال پر، shouldShowRequestPermissionRationale false لوٹاتا ہے — صارف نے ابھی تک ڈائیلاگ کا سامنا نہیں کیا۔ اگر صارف درخواست مسترد کرتا ہے (Deny دباتا ہے)، تو طریقہ true لوٹانا شروع کر دیتا ہے۔ Never Ask Again پرچم کے ساتھ بار بار انکار کے بعد، طریقہ false لوٹاتا ہے۔

مکمل حالت کا جدول:

shouldShowRequestPermissionRationale = false اور checkSelfPermission = DENIED کا مجموعہ سب سے مشکل صورت ہے۔ اس کا مطلب ہے کہ یا تو اجازت کبھی درخواست نہیں کی گئی یا Never Ask Again سیٹ ہے۔ ڈیولپر کو ان دو حالتوں میں فرق کرنا ہوگا۔ واحد راستہ SharedPreferences میں یا SavedStateHandle استعمال کرکے isFirstRequest پرچم محفوظ کرنا ہے۔ پہلی درخواست پر پرچم سیٹ کریں، اور اگر shouldShowRationale false لوٹاتا ہے جبکہ پرچم پہلے سے true ہے — تو اس کا مطلب Never Ask Again ہے۔

حالت ری سیٹ

shouldShowRequestPermissionRationale ری سیٹ ہو جاتا ہے اگر صارف ایپ ان انسٹال اور دوبارہ انسٹال کرتا ہے، ایپ ڈیٹا صاف کرتا ہے، یا اجازت کی ترتیبات ری سیٹ کرتا ہے۔ دوبارہ انسٹالیشن کے بعد، طریقہ پہلی درخواست کے لیے دوبارہ false لوٹائے گا۔ سسٹم اپ ڈیٹس اور Android ورژن تبدیلیاں تاریخ کو ری سیٹ نہیں کرتیں — یہ ایپ ڈیٹا میں محفوظ ہوتی ہے۔

دلیل ڈائیلاگ کا نفاذ

دلیل کا صحیح نفاذ تین اجزاء پر مشتمل ہے: انکار کے بعد shouldShowRequestPermissionRationale کی جانچ، وضاحت کے ساتھ ایک حسب ضرورت ڈائیلاگ دکھانا، اور صارف کے مثبت جواب کے بعد requestPermissions کو دوبارہ کال کرنا۔ ڈائیلاگ مختصر، مخصوص ہونا چاہیے اور بتانا چاہیے کہ ایپ کو اس خاص اجازت کی ضرورت کیوں ہے۔

private fun requestLocationWithRationale() {
    val permission = Manifest.permission.ACCESS_FINE_LOCATION

    when {
        ContextCompat.checkSelfPermission(
            this, permission
        ) == PackageManager.PERMISSION_GRANTED -> {
            startLocationTracking()
        }
        ActivityCompat.shouldShowRequestPermissionRationale(
            this, permission
        ) -> {
            showRationaleDialog(permission)
        }
        else -> {
            requestPermissionLauncher.launch(permission)
        }
    }
}

private fun showRationaleDialog(
    permission: String
) {
    AlertDialog.Builder(this)
        .setTitle("مقام تک رسائی کیوں ضروری ہے")
        .setMessage(
            "ایپ نقشے پر مقامات کو نشان زد کرنے کے لیے مقام استعمال کرتی ہے" +
            "۔ اس اجازت کے بغیر،" +
            " فنکشن کام نہیں کرے گا۔"
        )
        .setPositiveButton("اجازت دیں") { _, _ ->
            requestPermissionLauncher.launch(permission)
        }
        .setNegativeButton("منسوخ", null)
        .show()
}

دلیل کے لیے UI پیٹرن

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

دلیل کا لوکلائزیشن

دلیل کا متن لوکلائز اور مخصوص فنکشن کے مطابق ڈھالا جانا چاہیے۔ «ایپ کے کام کرنے کے لیے یہ ضروری ہے» جیسے عام جملے استعمال نہ کریں۔ واضح طور پر بتائیں: «آپ کے قریب موسم دکھانے کے لیے» یا «تصاویر کو گیلری میں محفوظ کرنے کے لیے۔» مخصوص وضاحتیں Google UX تحقیق کے مطابق اجازت دینے کے امکانات کو 50 فیصد تک بڑھاتی ہیں۔

دلیل بمقابلہ Never Ask Again

کے درمیان فرق shouldShowRequestPermissionRationale = true (پہلا انکار) اور DENIED کے ساتھ false (Never Ask Again) اجازت کی ہینڈلنگ میں ایک اہم نکتہ ہے۔ پہلی صورت میں، صارف ہچکچا رہا تھا، اور اضافی وضاحت اسے رسائی دینے پر قائل کر سکتی ہے۔ دوسری صورت میں، صارف نے حتمی فیصلہ کر لیا ہے، اور سسٹم ڈائیلاگ کو دہرانے سے صرف غصہ آئے گا۔

انکار کے بعد ہینڈلنگ الگورتھم اس طرح ہونا چاہیے:

• درخواست کال بیک سے DENIED نتیجہ حاصل کریں
• shouldShowRequestPermissionRationale کال کریں
• اگر true — دوبارہ کوشش کریں بٹن کے ساتھ ایک حسب ضرورت دلیل ڈائیلاگ دکھائیں
• اگر false — ترتیبات کھولیں بٹن کے ساتھ ایک ڈائیلاگ دکھائیں

ترتیب کو الجھانا نہیں چاہیے: پہلے shouldShowRequestPermissionRationale چیک کریں، checkSelfPermission نہیں۔ checkSelfPermission دونوں صورتوں میں DENIED لوٹائے گا۔ صرف shouldShowRequestPermissionRationale پہلے انکار کو Never Ask Again سے ممتاز کرتا ہے۔ «پہلی درخواست کی گئی تھی» پرچم محفوظ کرنے کے لیے SavedStateHandle یا SharedPreferences استعمال کریں — «کبھی درخواست نہیں کی گئی» کو «مسدود» سے ممتاز کرنے کا یہی واحد قابل اعتماد طریقہ ہے۔

دلیل دکھانے کے بہترین طریقے

دلیل صرف ایک بار دکھائیں۔ اگر صارف دلیل دیکھنے کے بعد دوبارہ درخواست مسترد کرتا ہے، تو دوبارہ وضاحت نہ دکھائیں۔ براہ راست ترتیبات کھولنے کی پیشکش پر جائیں۔ بار بار دلیل دکھانا پریشان کن سمجھا جاتا ہے اور ایپ کی درجہ بندی کم کرتا ہے۔ بہترین منظر نامہ: درخواست — انکار — دلیل — دوبارہ درخواست — انکار — ترتیبات۔

پہلی درخواست سے پہلے دلیل نہ دکھائیں۔ کچھ ڈیولپرز غلطی سے پہلے ڈائیلاگ سے پہلے وضاحت دکھاتے ہیں، یہ دلیل دیتے ہوئے کہ «صارف کو سمجھنا چاہیے۔» یہ UX کو خراب کرتا ہے: صارف ایک کے بجائے لگاتار دو ڈائیلاگ دیکھتا ہے۔ Google تجویز کرتا ہے کہ سسٹم ڈائیلاگ فوری دکھایا جائے، اور دلیل صرف انکار کے بعد۔

سیاق و سباق کے مطابق دلیل استعمال کریں جو اس لمحے سے منسلک ہو جب فنکشن واقعی ضروری ہو۔ ایپ اسٹارٹ اپ پر تمام اجازتیں درخواست نہ کریں — اس کی منظوری کی شرح سب سے کم ہے۔ کیمرہ اس وقت درخواست کریں جب صارف «تصویر لیں» بٹن دبائے اور مقام اس وقت جب وہ نقشہ کھولے۔ سیاق و سباق کی درخواست دلیل کے ساتھ مل کر اسٹارٹ اپ پر درخواست کرنے پر 30 فیصد کے مقابلے میں منظوری کو 80 فیصد تک بڑھا دیتی ہے۔

دلیل کے منظرناموں کی جانچ

shouldShowRequestPermissionRationale کی جانچ میں جدول کی چار حالتوں کی تصدیق درکار ہے: درخواست نہیں کی گئی، دی گئی، مسترد، Never Ask Again۔ یونٹ ٹیسٹ میں، قابل ترتیب shouldShowRationale رویے کے ساتھ FakePermissionHandler استعمال کریں۔ انسٹرومینٹیشن ٹیسٹ میں، ڈائیلاگ رسپانس ایمولیشن کے ساتھ UiAutomator یا Espresso استعمال کریں۔

class RationaleViewModelTest {

    private val handler = FakePermissionHandler()
    private val viewModel = PermissionsViewModel(handler)

    fun testFirstDenial_shouldShowRationale() {
        handler.shouldShowRationale = true
        handler.cameraResult =
            PermissionResult.DENIED(true)

        viewModel.onCameraRequested()

        assertEquals(
            PermissionUiState.Denied(true),
            viewModel.uiState.value
        )
    }

    fun testNeverAskAgain_redirectToSettings() {
        handler.shouldShowRationale = false
        handler.cameraResult =
            PermissionResult.DENIED(false)

        viewModel.onCameraRequested()

        assertEquals(
            PermissionUiState.RedirectToSettings,
            viewModel.uiState.value
        )
    }
}

انسٹرومینٹیشن ٹیسٹ کا اہم منظر نامہ یہ تصدیق کرنا ہے کہ پہلے انکار کے بعد دلیل ڈائیلاگ ظاہر ہوتا ہے۔ سسٹم ڈائیلاگ کے انتظار کے لیے idling resources کے ساتھ Espresso استعمال کریں، پھر Deny دبائیں، حسب ضرورت وضاحت ڈائیلاگ کی موجودگی چیک کریں اور Allow دبائیں — منظوری کی تصدیق کریں۔ UIAutomator بٹن کے متن کے ذریعے سسٹم ڈائیلاگ کے ساتھ تعامل کی اجازت دیتا ہے، جو ٹیسٹ کو زیادہ مستحکم بناتا ہے۔

دلیل ڈائیلاگ کے اندر انکار کے منظر نامے کی بھی جانچ کرنی چاہیے۔ اگر صارف حسب ضرورت وضاحت میں Deny دباتا ہے، تو shouldShowRequestPermissionRationale کو دوبارہ true لوٹانا چاہیے، کیونکہ Never Ask Again ابھی فعال نہیں ہوا۔ بہترین عمل یہ ہے کہ لگاتار دو انکار کے بعد ترتیبات پر بھیج دیا جائے تاکہ صارف کو بار بار وضاحت سے پریشان نہ کیا جائے اور ایپ کی درجہ بندی کم نہ ہو۔