shouldShowRequestPermissionRationale sa Android — ano ito, lohika ng pagpapakita at implementasyon

Ano ang shouldShowRequestPermissionRationale

shouldShowRequestPermissionRationale — ay isang method ng klase ng Activity at Fragment sa Android, na available sa pamamagitan ng ActivityCompat para sa compatibility. Tumatanggap ito ng pangalan ng pahintulot at nagbabalik ng Boolean na nagpapahiwatig kung kailangan bang magpakita ng karagdagang paliwanag sa user bago ang paulit-ulit na kahilingan. Ang method ay lumitaw sa Android 6.0 Marshmallow kasama ang runtime permission model.

Ang mekanismo ng rationale ay binuo sa pagsubaybay sa kasaysayan ng interaksyon ng user sa mga permission dialog. Naaalala ng system kung tinanggihan ng user ang kahilingan dati. Kung ang pagtanggi ay nangyari nang hindi nagtatakda ng flag na Never Ask Again, ang shouldShowRequestPermissionRationale ay nagbabalik ng true. Ito ay isang senyales sa developer: hindi naiintindihan ng user kung bakit kailangan ang pahintulot at kinakailangan ang karagdagang paliwanag. Ayon sa Google Material Design Guidelines, ang pagpapakita ng rationale dialog pagkatapos ng unang pagtanggi ay nagpapataas ng posibilidad ng muling pagbibigay ng pahintulot ng 35 porsyento.

Mahalagang maunawaan ang semantika ng mga ibinalik na halaga: true ay nangangahulugan na may saysay na ipakita ang dialog, false — ang dialog ay hindi kailangan (ang pahintulot ay naibigay na o hindi kailanman hiniling) o walang silbi (Never Ask Again ay aktibo). Ang method ay hindi garantiya na ang dialog ay ipapakita — ito ay nagbibigay lamang ng rekomendasyon. Ang developer mismo ang nagpapasya kung anong UI ang ipapakita bilang tugon.

Kailan lumitaw ang method

Ang shouldShowRequestPermissionRationale ay ipinakilala sa API Level 23 kasama ng isang grupo ng mga method para sa runtime permissions. Bago ang Android 6.0, lahat ng pahintulot ay hinihiling sa pag-install at hindi kinakailangan ang mekanismo ng paliwanag — tinanggap o tinanggihan ng user ang buong listahan nang sabay-sabay. Ang runtime model ay ginawang posible ang sitwasyon kung saan tinatanggihan ng user ang kahilingan nang hindi nauunawaan ang konteksto, at iyon mismo ang dahilan kung bakit kailangan ang rationale.

Paano gumagana ang shouldShowRequestPermissionRationale

Ang lohika ng method ay ang mga sumusunod. Sa unang tawag ng requestPermissions para sa isang partikular na pahintulot, ang shouldShowRequestPermissionRationale ay nagbabalik ng false — hindi pa nakatagpo ng user ang dialog. Kung tinanggihan ng user ang kahilingan (pinindot ang Deny), ang method ay nagsisimulang magbalik ng true. Pagkatapos ng paulit-ulit na pagtanggi gamit ang flag na Never Ask Again, ang method ay nagbabalik ng false.

Kumpletong talahanayan ng mga status:

Ang kombinasyon na shouldShowRequestPermissionRationale = false at checkSelfPermission = DENIED — ay ang pinakamahirap na kaso na iproseso. Ito ay nangangahulugan na ang pahintulot ay hindi kailanman hiniling o ang Never Ask Again ay naitakda. Kailangan ng developer na pag-ibahin ang dalawang status na ito. Ang tanging paraan — ang pag-imbak ng flag na firstRequest sa SharedPreferences o paggamit ng SavedStateHandle. Sa unang kahilingan, itakda ang flag, at kung ang shouldShowRationale ay nagbalik ng false at ang flag ay true na — nangangahulugan ito ng Never Ask Again.

Pag-reset ng status

Ang shouldShowRequestPermissionRationale ay nirereset kung tatanggalin at muling i-install ng user ang application, lilinisin ang data ng application, o irereset ang mga setting ng pahintulot. Pagkatapos ng muling pag-install, ang method ay muling magbabalik ng false para sa unang kahilingan. Ang mga update ng system at pagbabago ng bersyon ng Android ay hindi nirer reset ang kasaysayan — ito ay nakaimbak sa data ng application.

Implementasyon ng rationale dialog

Ang tamang implementasyon ng rationale ay may kasamang tatlong bahagi: pagsusuri ng shouldShowRequestPermissionRationale pagkatapos ng pagtanggi, pagpapakita ng custom na dialog na may paliwanag at paulit-ulit na pagtawag ng requestPermissions pagkatapos ng positibong tugon ng user. Ang dialog ay dapat maging maikli, tiyak at ipaliwanag kung bakit kailangan ng application ang partikular na pahintulot na ito.

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("Bakit kailangan ang access sa geolocation")
        .setMessage(
            "Ginagamit ng application ang geolocation para markahan ang mga lugar sa mapa" +
            ". Kung wala ang pahintulot na ito" +
            " ang function ay hindi gagana."
        )
        .setPositiveButton("Payagan") { _, _ ->
            requestPermissionLauncher.launch(permission)
        }
        .setNegativeButton("Kanselahin", null)
        .show()
}

Mga pattern ng UI para sa rationale

Ang mga pinakamahusay na kasanayan ng Material Design ay nagrerekomenda ng paggamit ng bottom sheet o inline-banner sa halip na modal dialog para sa rationale. Ang bottom sheet ay hindi gaanong nakakaabala at nagbibigay ng konteksto sa user. Ang inline na elemento sa screen (halimbawa, isang card na may paliwanag at button na Payagan) ay nagpapakita na ang function ay hindi available nang walang pahintulot, ngunit hindi hinaharangan ang natitirang interface.

Lokalisasyon ng rationale

Ang teksto ng rationale ay dapat na localized at iakma sa partikular na function. Huwag gumamit ng mga pangkalahatang parirala tulad ng “Ito ay kailangan para sa pagpapatakbo ng application”. Tukuyin nang konkreto: “Para sa pagpapakita ng panahon malapit sa iyo” o “Para sa pag-save ng mga larawan sa gallery”. Ayon sa Google UX Research, ang mga konkretong paliwanag ay nagpapataas ng posibilidad ng pagbibigay ng pahintulot ng 50 porsyento.

Rationale vs Never Ask Again

Ang pagkakaiba sa pagitan ng shouldShowRequestPermissionRationale = true (unang pagtanggi) at false sa DENIED (Never Ask Again) — ay ang pangunahing punto sa pagproseso ng mga pahintulot. Sa unang kaso, nag-alinlangan ang user at ang karagdagang paliwanag ay maaaring makumbinsi siya na ibigay ang access. Sa ikalawang kaso — ang user ay gumawa ng pinal na desisyon at ang paulit-ulit na system dialog ay magdudulot lamang ng inis.

Ang algorithm ng pagproseso pagkatapos ng pagtanggi ay dapat na ganito:

• Kunin ang resulta na DENIED mula sa callback ng kahilingan
• Tawagin ang shouldShowRequestPermissionRationale
• Kung true — magpakita ng custom na rationale dialog na may button na Ulitin
• Kung false — magpakita ng dialog na may button na Buksan ang Settings

Mahalagang hindi malito ang pagkakasunod-sunod: una suriin ang shouldShowRequestPermissionRationale, hindi ang checkSelfPermission. Ang checkSelfPermission ay magbabalik pa rin ng DENIED sa parehong kaso. Tanging ang shouldShowRequestPermissionRationale ang nag-iiba ng unang pagtanggi mula sa Never Ask Again. Gamitin ang SavedStateHandle o SharedPreferences para sa pag-imbak ng flag na “unang kahilingan ay naganap” — ito ang tanging maaasahang paraan upang pag-ibahin ang “hindi hiniling” mula sa “naka-block”.

Mga pinakamahusay na kasanayan sa pagpapakita ng rationale

Magpakita ng rationale nang isang beses lamang. Kung muling tinanggihan ng user ang kahilingan pagkatapos ng rationale — huwag nang magpakita ng paliwanag. Direktang lumipat sa mungkahing buksan ang mga setting. Ang paulit-ulit na pagpapakita ng rationale ay itinuturing na pang-iistorbo at nagpapababa ng rating ng application. Ang pinakamainam na scenario: kahilingan — pagtanggi — rationale — paulit-ulit na kahilingan — pagtanggi — Settings.

Huwag magpakita ng rationale bago ang unang kahilingan. Ang ilang developer ay nagkakamaling nagpapakita ng paliwanag bago ang unang dialog, na nangangatwiran na “dapat maintindihan ng user”. Ito ay nagpapalala ng UX: ang user ay nakakakita ng dalawang dialog na magkasunod sa halip na isa. Inirerekomenda ng Google na agad na ipakita ang system dialog, at ang rationale — pagkatapos lamang ng pagtanggi.

Gumamit ng kontekstwal na rationale, na nakatali sa sandaling talagang kailangan ang function. Huwag humingi ng lahat ng pahintulot sa pagsisimula ng application — ito ang pinakamababang rate ng pagbibigay. Humingi ng CAMERA kapag pinindot ng user ang button na “Kumuha ng Larawan” at LOCATION kapag binuksan niya ang mapa. Ang kontekstwal na kahilingan na sinamahan ng rationale ay nagpapataas ng pagbibigay sa 80 porsyento kumpara sa 30 porsyento sa unang kahilingan.

Pagsubok ng mga rationale scenario

Ang pagsubok ng shouldShowRequestPermissionRationale ay nangangailangan ng pagsusuri ng apat na status mula sa talahanayan: hindi hiniling, naibigay, tinanggihan, Never Ask Again. Sa unit tests, ginagamit ang FakePermissionHandler na may nako-configure na pag-uugali ng shouldShowRationale. Sa instrumental tests — UiAutomator o Espresso na may emulasyon ng mga tugon sa system dialog.

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
        )
    }
}

Ang pangunahing scenario para sa instrumental test — pagsusuri na ang rationale dialog ay talagang lumilitaw pagkatapos ng unang pagtanggi. Gamitin ang Espresso na may idling resources para maghintay ng system dialog, pagkatapos ay pindutin ang Deny, suriin ang paglitaw ng custom na dialog na may teksto ng paliwanag at pindutin ang Allow — suriin ang pagbibigay. Ang UIAutomator ay nagbibigay-daan sa pakikipag-ugnayan sa system dialog sa pamamagitan ng teksto ng button, na ginagawang mas matatag ang test.

Dapat ding subukan ang scenario ng pagtanggi sa loob ng rationale dialog. Kung pinindot ng user ang Deny sa custom na paliwanag, ang shouldShowRequestPermissionRationale ay dapat muling magbalik ng true, dahil hindi pa na-activate ang Never Ask Again. Pinakamahusay na kasanayan — pagkatapos ng dalawang magkasunod na pagtanggi, direktang i-redirect sa Settings upang hindi ma-istorbo ang user ng paulit-ulit na paliwanag at hindi mapababa ang rating ng application.