Android’da shouldShowRequestPermissionRationale — bu nima, ko‘rsatish mantiqi va tatbiqi

shouldShowRequestPermissionRationale nima

shouldShowRequestPermissionRationale — Android’dagi Activity va Fragment sinflarining metodidir, moslik uchun ActivityCompat orqali mavjud. U ruxsat nomini qabul qiladi va takroriy so‘rovdan oldin foydalanuvchiga qo‘shimcha tushuntirish ko‘rsatish kerakligini bildiruvchi Boolean qaytaradi. Metod Android 6.0 Marshmallow bilan birga runtime ruxsat modeli bilan taqdim etilgan.

Rationale mexanizmi foydalanuvchining ruxsat dialoglari bilan o‘zaro ta’sir tarixini kuzatishga asoslangan. Tizim foydalanuvchi oldin so‘rovni rad etganmi yoki yo‘qmi eslab qoladi. Agar rad etish Never Ask Again bayrog‘ini o‘rnatmasdan sodir bo‘lgan bo‘lsa, shouldShowRequestPermissionRationale true qaytaradi. Bu dasturchiga signal: foydalanuvchi ruxsat nima uchun kerakligini tushunmayapti va qo‘shimcha tushuntirish talab qilinadi. Google Material Design Guidelines ma’lumotiga ko‘ra, birinchi rad etishdan keyin rationale dialogini ko‘rsatish ruxsatning qayta berilish ehtimolini 35 foizga oshiradi.

Qaytarilgan qiymatlarning semantikasini tushunish muhim: true — dialogni ko‘rsatish mantiqli, false — dialog kerak emas (ruxsat allaqachon berilgan yoki hech qachon so‘ralmagan) yoki foydasiz (Never Ask Again faol). Metod dialog ko‘rsatilishiga kafolat bermaydi — u faqat tavsiya beradi. Dasturchi javoban qanday UI ko‘rsatishni o‘zi hal qiladi.

Metod qachon paydo bo‘ldi

shouldShowRequestPermissionRationale API Level 23 da runtime ruxsat metodlari guruhi bilan birga taqdim etilgan. Android 6.0 dan oldin barcha ruxsatlar o‘rnatish vaqtida so‘ralardi va tushuntirish mexanizmi talab qilinmasdi — foydalanuvchi butun ro‘yxatni birdan qabul yoki rad etardi. Runtime modeli foydalanuvchi kontekstni tushunmay so‘rovni rad etadigan vaziyatni mumkin qildi va aynan shuning uchun rationale kerak.

shouldShowRequestPermissionRationale qanday ishlaydi

Metod mantig‘i quyidagicha. Muayyan ruxsat uchun requestPermissions birinchi chaqirilganda shouldShowRequestPermissionRationale false qaytaradi — foydalanuvchi hali dialog bilan uchrashmagan. Agar foydalanuvchi so‘rovni rad etgan bo‘lsa (Deny tugmasini bosgan), metod true qaytarishni boshlaydi. Never Ask Again bayrog‘i bilan takroriy rad etishdan keyin metod false qaytaradi.

Holatlarning to‘liq jadvali:

shouldShowRequestPermissionRationale = false va checkSelfPermission = DENIED kombinatsiyasi — eng qiyin ishlov beriladigan holat. Bu ruxsat hech qachon so‘ralmagan yoki Never Ask Again o‘rnatilganligini bildiradi. Dasturchi bu ikki holatni farqlashi kerak. Yagona yo‘l — SharedPreferences yoki SavedStateHandle da firstRequest bayrog‘ini saqlash. Birinchi so‘rovda bayroqni o‘rnating va agar shouldShowRationale false qaytargan bo‘lsa va bayroq allaqachon true bo‘lsa — bu Never Ask Again.

Holatni tiklash

shouldShowRequestPermissionRationale, foydalanuvchi ilovani o‘chirib qayta o‘rnatsa, ilova ma’lumotlarini tozalasa yoki ruxsat sozlamalarini tiklasa, tiklanadi. Qayta o‘rnatishdan keyin metod birinchi so‘rov uchun yana false qaytaradi. Tizim yangilanishlari va Android versiyasining o‘zgarishi tarixni tiklamaydi — u ilova ma’lumotlarida saqlanadi.

Rationale dialogini tatbiq qilish

To‘g‘ri tatbiq uch komponentni o‘z ichiga oladi: rad etishdan keyin shouldShowRequestPermissionRationale ni tekshirish, tushuntirish bilan moslashtirilgan dialogni ko‘rsatish va foydalanuvchining ijobiy javobidan keyin requestPermissions ni takroriy chaqirish. Dialog qisqa, aniq bo‘lishi va ilova aynan shu ruxsatga nima uchun muhtojligini tushuntirishi kerak.

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("Geolokatsiyaga kirish nima uchun kerak")
        .setMessage(
            "Ilova xaritadagi joylarni belgilash uchun geolokatsiyadan foydalanadi" +
            ". Bu ruxsatsiz" +
            " funksiya ishlamaydi."
        )
        .setPositiveButton("Ruxsat berish") { _, _ ->
            requestPermissionLauncher.launch(permission)
        }
        .setNegativeButton("Bekor qilish", null)
        .show()
}

Rationale uchun UI namunalari

Material Design ning eng yaxshi amaliyotlari rationale uchun modal dialog o‘rniga bottom sheet yoki inline-bannerdan foydalanishni tavsiya qiladi. Bottom sheet kamroq xalaqit beradi va foydalanuvchiga kontekst beradi. Ekrandagi inline element (masalan, tushuntirish va Ruxsat ber tugmasi bilan karta) funksiya ruxsatsiz mavjud emasligini ko‘rsatadi, lekin qolgan interfeysni bloklamaydi.

Rationaleni mahalliylashtirish

Rationale matni mahalliylashtirilgan va muayyan funksiyaga moslashtirilgan bo‘lishi kerak. “Bu ilova ishlashi uchun kerak” kabi umumiy iboralarni ishlatmang. Aniq ko‘rsating: “Yoningizdagi ob-havoni ko‘rsatish uchun” yoki “Fotosuratlarni galereyaga saqlash uchun”. Google UX Research ma’lumotiga ko‘ra, aniq tushuntirishlar ruxsat berilish ehtimolini 50 foizga oshiradi.

Rationale vs Never Ask Again

shouldShowRequestPermissionRationale = true (birinchi rad) va DENIED holatida false (Never Ask Again) o‘rtasidagi farq — ruxsatlarni qayta ishlashdagi asosiy nuqta. Birinchi holatda foydalanuvchi ikkilanardi va qo‘shimcha tushuntirish uni ruxsat berishga ishontirishi mumkin. Ikkinchi holatda — foydalanuvchi yakuniy qaror qabul qilgan va takroriy tizim dialogi faqat g‘azab uyg‘otadi.

Rad etishdan keyin ishlov berish algoritmi quyidagicha bo‘lishi kerak:

• So‘rov callbackidan DENIED natijasini oling
• shouldShowRequestPermissionRationale ni chaqiring
• Agar true — Takrorlash tugmasi bilan moslashtirilgan rationale dialogini ko‘rsating
• Agar false — Sozlamalarni ochish tugmasi bilan dialog ko‘rsating

Tartibni chalkashtirmaslik muhim: avval shouldShowRequestPermissionRationale ni tekshiring, checkSelfPermission ni emas. checkSelfPermission ikkala holatda ham DENIED qaytaradi. Faqat shouldShowRequestPermissionRationale birinchi radni Never Ask Again dan farqlaydi. “Birinchi so‘rov bo‘lgan” bayrog‘ini saqlash uchun SavedStateHandle yoki SharedPreferences dan foydalaning — bu “so‘ralmagan” ni “bloklangan” dan farqlashning yagona ishonchli usuli.

Rationale ko‘rsatishning eng yaxshi amaliyotlari

Rationaleni faqat bir marta ko‘rsating. Agar foydalanuvchi rationaledan keyin so‘rovni yana rad etgan bo‘lsa — boshqa tushuntirish ko‘rsatmang. To‘g‘ridan-to‘g‘ri sozlamalarni ochish taklifiga o‘ting. Rationalening takroriy ko‘rsatilishi bezovtalik sifatida qabul qilinadi va ilova reytingini pasaytiradi. Optimal stsenariy: so‘rov — rad — rationale — takroriy so‘rov — rad — Sozlamalar.

Birinchi so‘rovdan oldin rationaleni ko‘rsatmang. Ba’zi dasturchilar “foydalanuvchi tushunishi kerak” deb birinchi dialogdan oldin tushuntirish ko‘rsatish xatosiga yo‘l qo‘yadilar. Bu UXni yomonlashtiradi: foydalanuvchi bitta o‘rniga ketma-ket ikkita dialog ko‘radi. Google tavsiya qiladi tizim dialogini darhol, rationaleni esa faqat rad etishdan keyin ko‘rsatishni.

Funksiya haqiqatan kerak bo‘lgan paytga bog‘liq kontekstli rationaleden foydalaning. Ilova ishga tushganda barcha ruxsatlarni so‘ramang — bu eng past berilish ko‘rsatkichidir. Foydalanuvchi “Suratga olish” tugmasini bosganida CAMERA va xaritani ochganida LOCATION ni so‘rang. Rationale bilan birgalikda kontekstli so‘rov berilishni boshlang‘ich so‘rovdagi 30 foizga nisbatan 80 foizgacha oshiradi.

Rationale stsenariylarini test qilish

shouldShowRequestPermissionRationale ni test qilish jadvaldagi to‘rt holatni tekshirishni talab qiladi: so‘ralmagan, berilgan, rad etilgan, Never Ask Again. Birlik testlarda sozlanadigan shouldShowRationale xatti-harakati bilan FakePermissionHandler ishlatiladi. Instrumental testlarda — tizim dialoglariga javoblarni emulyatsiya qilish bilan UiAutomator yoki 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
        )
    }
}

Instrumental test uchun asosiy stsenariy — rationale dialogi birinchi rad etishdan keyin haqiqatan ko‘rinishini tekshirish. Tizim dialogini kutish uchun idling resources bilan Espresso dan foydalaning, keyin Deny ni bosing, tushuntirish matni bilan moslashtirilgan dialog paydo bo‘lishini tekshiring va Allow ni bosing — berilishni tekshiring. UIAutomator tugma matni orqali tizim dialogi bilan o‘zaro aloqa qilish imkonini beradi, bu testni barqarorroq qiladi.

Shuningdek, rationale dialogi ichida rad etish stsenariysini test qilishga arziydi. Agar foydalanuvchi moslashtirilgan tushuntirishda Deny ni bosgan bo‘lsa, shouldShowRequestPermissionRationale yana true qaytarishi kerak, chunki Never Ask Again hali faollashtirilmagan. Eng yaxshi amaliyot — ketma-ket ikki rad etishdan keyin foydalanuvchini takroriy tushuntirishlar bilan bezovta qilmaslik va ilova reytingini pasaytirmaslik uchun to‘g‘ridan-to‘g‘ri Sozlamalarga yo‘naltirish.