shouldShowRequestPermissionRationale di Android — apa itu, logika tampilan dan implementasi

Apa itu shouldShowRequestPermissionRationale

shouldShowRequestPermissionRationale — adalah metode dari kelas Activity dan Fragment di Android, tersedia melalui ActivityCompat untuk kompatibilitas. Metode ini menerima nama izin dan mengembalikan Boolean yang menunjukkan apakah perlu menampilkan penjelasan tambahan kepada pengguna sebelum permintaan ulang. Metode ini muncul di Android 6.0 Marshmallow bersama dengan model izin runtime.

Mekanisme rationale dibangun dengan melacak riwayat interaksi pengguna dengan dialog izin. Sistem mengingat apakah pengguna menolak permintaan sebelumnya. Jika penolakan terjadi tanpa mengatur bendera Never Ask Again, shouldShowRequestPermissionRationale mengembalikan true. Ini adalah sinyal bagi pengembang: pengguna tidak mengerti mengapa izin diperlukan dan penjelasan tambahan diperlukan. Menurut Google Material Design Guidelines, menampilkan dialog rationale setelah penolakan pertama meningkatkan kemungkinan pemberian izin ulang sebesar 35 persen.

Penting untuk memahami semantik nilai yang dikembalikan: true berarti masuk akal untuk menampilkan dialog, false — dialog tidak diperlukan (izin sudah diberikan atau tidak pernah diminta) atau tidak berguna (Never Ask Again aktif). Metode ini bukan jaminan bahwa dialog akan ditampilkan — metode ini hanya memberikan rekomendasi. Pengembang sendiri yang memutuskan UI apa yang akan ditampilkan sebagai respons.

Kapan metode muncul

shouldShowRequestPermissionRationale diperkenalkan di API Level 23 bersama dengan kelompok metode untuk izin runtime. Sebelum Android 6.0, semua izin diminta saat instalasi dan mekanisme penjelasan tidak diperlukan — pengguna menerima atau menolak seluruh daftar sekaligus. Model runtime memungkinkan situasi di mana pengguna menolak permintaan tanpa memahami konteksnya, dan justru karena itulah rationale diperlukan.

Cara kerja shouldShowRequestPermissionRationale

Logika metode adalah sebagai berikut. Pada panggilan pertama requestPermissions untuk izin tertentu, shouldShowRequestPermissionRationale mengembalikan false — pengguna belum pernah berhadapan dengan dialog. Jika pengguna menolak permintaan (menekan Deny), metode mulai mengembalikan true. Setelah penolakan berulang dengan bendera Never Ask Again, metode mengembalikan false.

Tabel lengkap status:

Kombinasi shouldShowRequestPermissionRationale = false dan checkSelfPermission = DENIED — ini adalah kasus yang paling sulit untuk diproses. Ini berarti izin tidak pernah diminta atau Never Ask Again telah diatur. Pengembang harus membedakan kedua status ini. Satu-satunya cara — menyimpan bendera firstRequest di SharedPreferences atau menggunakan SavedStateHandle. Pada permintaan pertama, atur bendera, dan jika shouldShowRationale mengembalikan false dan bendera sudah true — berarti Never Ask Again.

Mereset status

shouldShowRequestPermissionRationale diatur ulang jika pengguna menghapus dan menginstal ulang aplikasi, membersihkan data aplikasi, atau mereset pengaturan izin. Setelah instalasi ulang, metode akan kembali mengembalikan false untuk permintaan pertama. Pembaruan sistem dan perubahan versi Android tidak mereset riwayat — riwayat disimpan dalam data aplikasi.

Implementasi dialog rationale

Implementasi yang benar dari rationale mencakup tiga komponen: pemeriksaan shouldShowRequestPermissionRationale setelah penolakan, menampilkan dialog kustom dengan penjelasan, dan panggilan ulang requestPermissions setelah respons positif pengguna. Dialog harus singkat, spesifik, dan menjelaskan mengapa aplikasi membutuhkan izin khusus ini.

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("Mengapa akses geolokasi diperlukan")
        .setMessage(
            "Aplikasi menggunakan geolokasi untuk menandai tempat di peta" +
            ". Tanpa izin ini" +
            " fungsi tidak akan berfungsi."
        )
        .setPositiveButton("Izinkan") { _, _ ->
            requestPermissionLauncher.launch(permission)
        }
        .setNegativeButton("Batal", null)
        .show()
}

Pola UI untuk rationale

Praktik terbaik Material Design merekomendasikan penggunaan bottom sheet atau banner inline sebagai pengganti dialog modal untuk rationale. Bottom sheet tidak terlalu mengganggu dan memberikan konteks kepada pengguna. Elemen inline di layar (misalnya, kartu dengan penjelasan dan tombol Izinkan) menunjukkan bahwa fungsi tidak tersedia tanpa izin, tetapi tidak memblokir antarmuka lainnya.

Lokalisasi rationale

Teks rationale harus dilokalisasi dan disesuaikan dengan fungsi tertentu. Jangan gunakan frasa umum seperti “Ini diperlukan untuk menjalankan aplikasi”. Sebutkan secara spesifik: “Untuk menampilkan cuaca di sekitar Anda” atau “Untuk menyimpan foto ke galeri”. Menurut Google UX Research, penjelasan spesifik meningkatkan kemungkinan pemberian izin sebesar 50 persen.

Rationale vs Never Ask Again

Perbedaan antara shouldShowRequestPermissionRationale = true (penolakan pertama) dan false saat DENIED (Never Ask Again) — adalah poin kunci dalam pemrosesan izin. Dalam kasus pertama, pengguna ragu-ragu dan penjelasan tambahan dapat meyakinkannya untuk memberikan akses. Dalam kasus kedua — pengguna telah membuat keputusan akhir dan dialog sistem berulang hanya akan menyebabkan kejengkelan.

Algoritma pemrosesan setelah penolakan harus sebagai berikut:

• Dapatkan hasil DENIED dari callback permintaan
• Panggil shouldShowRequestPermissionRationale
• Jika true — tampilkan dialog rationale kustom dengan tombol Ulangi
• Jika false — tampilkan dialog dengan tombol Buka Pengaturan

Penting untuk tidak membingungkan urutan: pertama periksa shouldShowRequestPermissionRationale, bukan checkSelfPermission. checkSelfPermission akan tetap mengembalikan DENIED dalam kedua kasus. Hanya shouldShowRequestPermissionRationale yang membedakan penolakan pertama dari Never Ask Again. Gunakan SavedStateHandle atau SharedPreferences untuk menyimpan bendera “permintaan pertama sudah dilakukan” — ini adalah satu-satunya cara yang dapat diandalkan untuk membedakan “belum diminta” dari “diblokir”.

Praktik terbaik menampilkan rationale

Tampilkan rationale hanya sekali. Jika pengguna menolak permintaan lagi setelah rationale — jangan tampilkan penjelasan lagi. Langsung beralih ke proposal untuk membuka pengaturan. Menampilkan rationale berulang kali dianggap mengganggu dan menurunkan peringkat aplikasi. Skenario optimal: permintaan — penolakan — rationale — permintaan ulang — penolakan — Pengaturan.

Jangan tampilkan rationale sebelum permintaan pertama. Beberapa pengembang secara keliru menampilkan penjelasan sebelum dialog pertama, dengan alasan bahwa “pengguna harus mengerti”. Ini memperburuk UX: pengguna melihat dua dialog berurutan, bukan satu. Google merekomendasikan untuk menampilkan dialog sistem segera, dan rationale hanya setelah penolakan.

Gunakan rationale kontekstual yang terkait dengan saat fungsi benar-benar diperlukan. Jangan meminta semua izin saat memulai aplikasi — ini adalah tingkat pemberian terendah. Minta CAMERA saat pengguna menekan tombol “Ambil Foto” dan LOCATION saat ia membuka peta. Permintaan kontekstual yang dikombinasikan dengan rationale meningkatkan pemberian hingga 80 persen dibandingkan 30 persen pada permintaan awal.

Pengujian skenario rationale

Pengujian shouldShowRequestPermissionRationale memerlukan pemeriksaan empat status dari tabel: belum diminta, diberikan, ditolak, Never Ask Again. Dalam pengujian unit, digunakan FakePermissionHandler dengan perilaku shouldShowRationale yang dapat dikonfigurasi. Dalam pengujian instrumental — UiAutomator atau Espresso dengan emulasi respons terhadap dialog sistem.

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

Skenario kunci untuk pengujian instrumental — memeriksa bahwa dialog rationale benar-benar muncul setelah penolakan pertama. Gunakan Espresso dengan idling resources untuk menunggu dialog sistem, lalu tekan Deny, periksa munculnya dialog kustom dengan teks penjelasan dan tekan Allow — periksa pemberian. UIAutomator memungkinkan interaksi dengan dialog sistem melalui teks tombol, yang membuat pengujian lebih stabil.

Juga perlu menguji skenario penolakan di dalam dialog rationale. Jika pengguna menekan Deny di penjelasan kustom, shouldShowRequestPermissionRationale harus kembali mengembalikan true, karena Never Ask Again belum diaktifkan. Praktik terbaik — setelah dua penolakan berturut-turut, langsung arahkan ke Pengaturan untuk tidak mengganggu pengguna dengan penjelasan berulang dan menurunkan peringkat aplikasi.