shouldShowRequestPermissionRationale in Android — nedir, görüntüleme mantığı ve uygulaması

shouldShowRequestPermissionRationale Nedir

shouldShowRequestPermissionRationale, Android'deki Activity ve Fragment sınıflarının bir yöntemidir ve uyumluluk için ActivityCompat aracılığıyla kullanılabilir. Bir izin adı alır ve yeniden istemeden önce kullanıcıya ek bir açıklama gösterilmesi gerekip gerekmediğini belirten bir Boolean döndürür. Yöntem, Android 6.0 Marshmallow ile birlikte çalışma zamanı izin modeliyle ortaya çıkmıştır.

Gerekçe mekanizması, kullanıcının izin iletişim kutularıyla etkileşim geçmişinin izlenmesi üzerine kurulmuştur. Sistem, kullanıcının daha önce isteği reddedip reddetmediğini hatırlar. Reddetme, Never Ask Again bayrağı ayarlanmadan gerçekleştiyse, shouldShowRequestPermissionRationale true döndürür. Bu, geliştirici için bir sinyaldir: kullanıcı iznin neden gerekli olduğunu anlamıyor ve ek açıklama gerekiyor. Google Material Design Yönergeleri'ne göre, ilk reddetmeden sonra bir gerekçe iletişim kutusu göstermek, iznin yeniden verilme olasılığını yüzde 35 artırır.

Dönüş değerlerinin anlamını anlamak önemlidir: true, iletişim kutusunu göstermenin anlamlı olduğu anlamına gelir, false ise iletişim kutusunun gerekli olmadığı (izin zaten verilmiş veya hiç istenmemiş) veya yararsız olduğu (Never Ask Again etkin) anlamına gelir. Yöntem, iletişim kutusunun gösterileceğinin garantisi değildir — yalnızca bir öneri verir. Geliştirici, yanıt olarak hangi UI'nın gösterileceğine karar verir.

Yöntem Ne Zaman Tanıtıldı

shouldShowRequestPermissionRationale, API Seviyesi 23'te çalışma zamanı izinleri için bir grup yöntemle birlikte tanıtıldı. Android 6.0'dan önce, tüm izinler kurulum sırasında isteniyordu ve hiçbir açıklama mekanizması gerekmiyordu — kullanıcı tüm listeyi bir kerede kabul eder veya reddederdi. Çalışma zamanı modeli, bir kullanıcının bağlamı anlamadan bir isteği reddetmesini mümkün kıldı ve işte tam da bu nedenle gerekçe gereklidir.

shouldShowRequestPermissionRationale Nasıl Çalışır

Yöntemin mantığı şu şekilde çalışır. Belirli bir izin için requestPermissions'in ilk çağrısında, shouldShowRequestPermissionRationale false döndürür — kullanıcı henüz iletişim kutusuyla karşılaşmamıştır. Kullanıcı isteği reddederse (Reddet'e basarsa), yöntem true döndürmeye başlar. Never Ask Again bayrağıyla tekrarlanan reddetmeden sonra, yöntem false döndürür.

Tam durum tablosu:

shouldShowRequestPermissionRationale = false ve checkSelfPermission = DENIED kombinasyonu, işlenmesi en zor durumdur. Bu, iznin hiç istenmediği veya Never Ask Again'in ayarlandığı anlamına gelir. Geliştiricinin bu iki durumu ayırt etmesi gerekir. Tek yol, SharedPreferences'te veya SavedStateHandle kullanarak bir isFirstRequest bayrağı saklamaktır. İlk istekte bayrağı ayarlayın ve bayrak zaten true iken shouldShowRationale false döndürürse — bu Never Ask Again anlamına gelir.

Durum Sıfırlama

Kullanıcı uygulamayı kaldırıp yeniden yüklerse, uygulama verilerini temizlerse veya izin ayarlarını sıfırlarsa shouldShowRequestPermissionRationale sıfırlanır. Yeniden yüklemeden sonra, yöntem ilk istek için tekrar false döndürecektir. Sistem güncellemeleri ve Android sürüm değişiklikleri geçmişi sıfırlamaz — uygulama verilerinde saklanır.

Gerekçe İletişim Kutusu Uygulaması

Doğru bir gerekçe uygulaması üç bileşen içerir: reddetmeden sonra shouldShowRequestPermissionRationale'yi kontrol etme, bir açıklama ile özel bir iletişim kutusu gösterme ve kullanıcının olumlu yanıtından sonra requestPermissions'i yeniden çağırma. İletişim kutusu kısa, spesifik olmalı ve uygulamanın bu belirli izne neden ihtiyaç duyduğunu açıklamalıdır.

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("Konum erişimine neden ihtiyaç var")
        .setMessage(
            "Uygulama, haritadaki yerleri işaretlemek için konumu kullanır" +
            ". Bu izin olmadan" +
            " işlev çalışmayacaktır."
        )
        .setPositiveButton("İzin Ver") { _, _ ->
            requestPermissionLauncher.launch(permission)
        }
        .setNegativeButton("İptal", null)
        .show()
}

Gerekçe için UI Kalıpları

Material Design en iyi uygulamaları, gerekçe için modal iletişim kutusu yerine alt sayfa veya satır içi banner kullanılmasını önerir. Alt sayfa daha az müdahalecidir ve kullanıcıya bağlam sağlar. Ekrandaki bir satır içi öğe (örneğin, bir açıklama ve İzin Ver düğmesi olan bir kart), izin olmadan işlevin kullanılamayacağını gösterir ancak arayüzün geri kalanını engellemez.

Gerekçe Yerelleştirmesi

Gerekçe metni yerelleştirilmeli ve belirli işleve uyarlanmalıdır. “Uygulamanın çalışması için bu gereklidir” gibi genel ifadeler kullanmayın. Somut olarak belirtin: “Yakınınızdaki havayı göstermek için” veya “Fotoğrafları galeriye kaydetmek için.” Spesifik açıklamalar, Google UX Araştırması'na göre izin verme olasılığını yüzde 50 artırır.

Gerekçe vs Never Ask Again

Arasındaki fark shouldShowRequestPermissionRationale = true (ilk reddetme) ve DENIED ile false (Never Ask Again), izin yönetiminde önemli bir noktadır. İlk durumda, kullanıcı tereddüt etti ve ek açıklama onu erişim izni vermeye ikna edebilir. İkincisinde, kullanıcı nihai bir karar verdi ve sistem iletişim kutusunu tekrarlamak yalnızca rahatsızlığa neden olacaktır.

Reddetmeden sonraki işleme algoritması şu şekilde olmalıdır:

• İstek geri çağrısından DENIED sonucunu al
• shouldShowRequestPermissionRationale çağır
• True ise — Yeniden Dene düğmesiyle özel bir gerekçe iletişim kutusu göster
• False ise — Ayarları Aç düğmesiyle bir iletişim kutusu göster

Sırayı karıştırmamak önemlidir: önce shouldShowRequestPermissionRationale'yi kontrol edin, checkSelfPermission'ı değil. checkSelfPermission her iki durumda da DENIED döndürecektir. Yalnızca shouldShowRequestPermissionRationale, ilk reddetmeyi Never Ask Again'den ayırt eder. “İlk istek yapıldı” bayrağını saklamak için SavedStateHandle veya SharedPreferences kullanın — “hiç istenmedi”yi “engellendi”den ayırmanın tek güvenilir yolu budur.

Gerekçe Göstermek için En İyi Uygulamalar

Gerekçeyi yalnızca bir kez gösterin. Kullanıcı gerekçeyi gördükten sonra isteği tekrar reddederse, açıklamayı bir daha göstermeyin. Doğrudan Ayarlar'ı açmayı teklif edin. Gerekçeyi tekrar tekrar göstermek rahatsız edici olarak algılanır ve uygulama puanını düşürür. En uygun senaryo: istek — reddetme — gerekçe — yeniden istek — reddetme — Ayarlar.

İlk istekten önce gerekçe göstermeyin. Bazı geliştiriciler, “kullanıcı anlamalı” diyerek ilk iletişim kutusundan önce yanlışlıkla bir açıklama gösterir. Bu, UX'i kötüleştirir: kullanıcı bir yerine iki iletişim kutusunu üst üste görür. Google, sistem iletişim kutusunun hemen gösterilmesini ve gerekçenin yalnızca reddetmeden sonra gösterilmesini önerir.

İşlevin gerçekten gerekli olduğu ana bağlı bağlamsal gerekçe kullanın. Uygulama başlangıcında tüm izinleri istemeyin — bu en düşük izin verme oranına sahiptir. Kullanıcı “Fotoğraf Çek” düğmesine dokunduğunda KAMERA'yı ve haritayı açtığında KONUM'u isteyin. Bağlamsal istek gerekçeyle birleştiğinde, başlangıçta istendiğinde yüzde 30'a karşılık, izin verme oranını yüzde 80'e çıkarır.

Gerekçe Senaryolarını Test Etme

shouldShowRequestPermissionRationale'yi test etme, tablodaki dört durumun kontrol edilmesini gerektirir: istenmedi, verildi, reddedildi, Never Ask Again. Birim testlerinde, yapılandırılabilir shouldShowRationale davranışına sahip FakePermissionHandler kullanın. Araç testlerinde, iletişim kutusu yanıtı öykünmesiyle UiAutomator veya Espresso kullanın.

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

Bir araç testi için temel senaryo, ilk reddetmeden sonra gerekçe iletişim kutusunun gerçekten görüntülendiğini doğrulamaktır. Sistem iletişim kutusunu beklemek için idling resources ile Espresso kullanın, ardından Reddet'e basın, özel açıklama iletişim kutusunun göründüğünü kontrol edin ve İzin Ver'e basın — izni doğrulayın. UIAutomator, düğme metniyle sistem iletişim kutusuyla etkileşime izin vererek testi daha kararlı hale getirir.

Ayrıca gerekçe iletişim kutusunun içinde reddetme senaryosunu da test etmek gerekir. Kullanıcı özel açıklamada Reddet'e basarsa, shouldShowRequestPermissionRationale tekrar true döndürmelidir, çünkü Never Ask Again henüz etkinleştirilmemiştir. En iyi uygulama, kullanıcıyı tekrarlanan açıklamalarla rahatsız etmemek ve uygulama puanını düşürmemek için art arda iki reddetmeden sonra Ayarlar'a yönlendirmektir.