Android'de bildirim izni ne zaman istenmeli (ve Reddet'ten nasıl geri dönülür)

Android 13’ten beri bildirimler varsayılan olarak verilmiyor — kullanıcının kamera veya konum erişimine evet dediği gibi, POST_NOTIFICATIONS iznine de açıkça evet demesi gerekiyor. Bildirimlerin tüm değeri taşıdığı bir uygulama için — bir su hatırlatıcısı, bir ilaç uyarısı — o tek sistem diyaloğu, uygulamanın çalışması ile uygulamanın ara sıra açılan bir ikon olması arasındaki farktır. Zamanlamayı yanlış yaparsanız çoğu kişi, evet demek için bir sebep görmeden önce, refleksle “İzin verme”ye dokunur. Doğru yaparsanız aynı diyalog sıradan bir şeye dönüşür. İznin kendisi değişmez; onu çevreleyen istek değişir.

Diyalog yalnızca bir kez tetiklenir

POST_NOTIFICATIONS, diğer her Android çalışma zamanı izni gibi davranır: sistem diyaloğunu her kurulumda bir kez gösterir. Kullanıcı reddederse, requestPermissionLauncher.launch(Manifest.permission.POST_NOTIFICATIONS)’a sonraki çağrı sessizce false döner — diyalog yok, hata yok, sadece anında bir ret. Test sırasında insanları şaşırtan kısım burası: ikinci bir ActivityResultLauncher isteği hiçbir şey yapmıyormuş gibi görünür, oysa aslında yapması gerekeni tam olarak yapmaktadır.

val requestPermissionLauncher = registerForActivityResult(
    ActivityResultContracts.RequestPermission()
) { granted ->
    if (granted) {
        scheduleDailyReminder()
    } else {
        showNotificationsDisabledState()
    }
}

Sistem diyaloğu için gerçek tek bir şans olduğundan, launch()’ı ne zaman çağırdığınız, nasıl çağırdığınızdan daha önemlidir.

İlk açılışta sormayın

Refleks, onboarding sırasında uygulamanın gelecekte ihtiyaç duyacağı her izni istemektir, böylece uygulamanın geri kalanı hepsinin verildiğini varsayabilir. Özellikle bildirimler için bu, mümkün olan en kötü zamanlamaya yakındır. İlk açılışta kullanıcının, bir hatırlatıcı uygulamasının onu daha sonra neden rahatsız etmek istediğine dair bir bağlamı yoktur — ikonu on saniyedir görüyorlardır. Önce bir sebep gelmeden bir izin diyaloğu, sürtünme olarak okunur, ve tam o anda gelen sürtünme, düşünülmüş bir “İzin ver”den çok refleksif bir “İzin verme” alır.

Çözüm, iznin değerinin kendiliğinden belli olduğu noktada sormaktır. Hydrame’de bu, birinin günlük su hedefini belirlemeyi bitirdiği andır — az önce uygulamaya ne zaman daha fazla su içmek istediğini söylemişlerdir, dolayısıyla bir hatırlatıcı bir kesinti değil, istedikleri özelliktir. OldSchool’da bu, ilk ilacı ve programını ekledikten hemen sonradır. İstek, kullanıcının iznin sağladığı şeyi zaten istediğini ima eden bir eylemi takip eder; sistem diyaloğu sadece bunu resmileştirir.

Isıtma ekranı, çıplak sistem diyaloğundan daha iyidir

Sistem izin diyaloğu tasarım gereği kısadır — bir başlık, bir uygulama adı, İzin ver ve İzin verme. Neden olduğunu açıklayamaz, ve Android size metnini özelleştirmenin bir yolunu vermez. Kontrol edebileceğiniz şey, ondan hemen önce gösterilen ekrandır: uygulamanın ihtiyacı etrafında değil, kullanıcının kendi hedefi etrafında çerçevelenmiş tek bir bağlam cümlesi.

"Az önce belirlediğin programa göre su içmen için sana hatırlatacağım.
 Android'in bu hatırlatmaları gösterebilmesi için iznine ihtiyacı var."

 [ Hatırlatmaları aç ]   [ Şimdi değil ]

Buna bazen “ön-izin” veya “yumuşak sorma” ekranı denir, ve değeri kozmetik değildir — bir an sonra göründüğünde sistem diyaloğunun ne anlama geldiğini değiştirir. O olmadan, işletim sistemi diyaloğu kullanıcının aldığı ilk ve tek açıklamadır. Onunla birlikte, işletim sistemi diyaloğu, kullanıcının zaten kabul ettiği bir şeyin sadece bir onayıdır. Isıtma ekranındaki bir “Şimdi değil” de hiçbir şeye mal olmaz: gerçek izne hiç dokunmaz, dolayısıyla tek sistem denemesi, kullanıcı uygulamada daha fazla zaman geçirip isteğe daha fazla güven duyduktan sonra daha sonra hâlâ kullanılabilir.

Ret nihai değildir — shouldShowRequestPermissionRationale

Biri sistem diyaloğunu reddettiğinde, ActivityCompat.shouldShowRequestPermissionRationale(), bir sonraki istekten önce kendi gerekçenizi tekrar göstermeye değip değmeyeceğini, ya da kullanıcının izni kalıcı olarak reddedip reddetmediğini (“Bir daha sorma”yı işaretlemiş ya da Android’in daha yeni, daha katı yeniden sorma kurallarına göre bir kez zaten reddetmiş) söyler.

fun onReminderCardTapped(activity: Activity) {
    val granted = ContextCompat.checkSelfPermission(
        activity, Manifest.permission.POST_NOTIFICATIONS
    ) == PackageManager.PERMISSION_GRANTED

    when {
        granted -> scheduleDailyReminder()
        ActivityCompat.shouldShowRequestPermissionRationale(
            activity, Manifest.permission.POST_NOTIFICATIONS
        ) -> showRationaleThenRequest()
        else -> openAppNotificationSettings(activity)
    }
}

Önceki bir retten sonra false döndüğünde, launch()’ı nasıl çağırırsanız çağırın sistem diyaloğunu bir daha göstermez — geri dönüşün tek yolu, paketinize özgü bir Intent(Settings.ACTION_APP_NOTIFICATION_SETTINGS) ile ulaşılan uygulamanın bildirim ayarları sayfasıdır. Bunu genel bir “ayarlarını kontrol et” mesajının arkasına saklamayın; intent kullanıcıyı doğrudan doğru ekrana götürür, gezinmeye gerek kalmaz.

”Hayır”ı gerçek bir durum olarak tasarlayın, bir hata olarak değil

Bazı kullanıcılar bunu reddedecek ve bunu kastedecek — uygulamayı bunun desteklenen bir durum olacağı, bozuk olmayacağı şekilde inşa edin. Hydrame hatırlatmalar olmadan da suyu kaydetmeye devam eder; sadece seri ve geçmiş bir dürtü almaz. OldSchool, uygulama içi ilaç listesini tamamen kullanılabilir tutar ve özellik ateşlenemediğinde var olduğunu iddia etmek yerine kalıcı, kapatılabilir bir banner gösterir — “Hatırlatmalar kapalı”. Bir hatırlatmanın zamanlandığı ama izin hiç verilmediği için hiç görünmediği sessiz bir başarısızlık, dürüst bir eksik özellikten daha kötüdür: kullanıcının yaptığı bir seçim gibi değil, uygulamanın güvenilmez olduğu gibi görünür.

Tek sistem diyaloğu, kurulumuna değer

POST_NOTIFICATIONS zor bir API değildir — registerForActivityResult ve tek bir izin dizesi, mekaniğin birkaç satırda halledilmesini sağlar. Verme oranını gerçekten belirleyen şey, o satırların etrafındaki her şeydir: değerin belirgin hale geldiği andan sonra sormak, düz dilde tek bir bağlam cümlesiyle ısıtmak, ve retin olmayacağını varsaymak yerine ona gerçek bir yanıtınızın olması. Hatırlatmanın ürünün kendisi olduğu herhangi bir uygulama için bu bir cila değildir — bunun çalışması özelliğin ta kendisidir.