Push Bildirimlerin Kimsenin Anlatmadığı Kısmı
Bildirim entegrasyonu yirmi dakika sürer, doğru çalışması aylar. Token döngüsü, sessiz başarısızlıklar ve bildirimden doğru ekrana gitmek üzerine.
Push bildirim kurulumu belgelerdeki hâliyle yirmi dakika sürüyor: kütüphaneyi ekle, anahtarı koy, test bildirimi gönder, geldi. Sorun şu ki gerçek uygulamada işin %80'i o yirmi dakikadan sonra başlıyor.
Aşağıdakiler, uygulamalarımda bildirim tarafında öğrendiğim ve belgelerde tek yerde toplanmış hâlde bulamadığım şeyler.
1. Token sabit değildir
En temel yanılgı bu. Cihaz token'ı kalıcı sanılıyor, bir kez alınıp sunucuya gönderiliyor ve unutuluyor. Oysa token şu durumlarda değişiyor:
- Kullanıcı uygulamayı silip yeniden kurduğunda
- Uygulama verisi temizlendiğinde
- Cihaz yedekten geri yüklendiğinde
- Sistemin kendi yenileme döngüsünde
Token yenilendiğinde sunucudaki kayıt eskiyor ve o kullanıcı sessizce bildirim almamaya başlıyor. Hata da vermiyor — sadece bildirim gitmiyor.
// Token her yenilendiğinde sunucuya bildir
FirebaseMessaging.getInstance().token.addOnSuccessListener { token ->
sunucuyaKaydet(token)
}
// Ve yenilenme olayını da dinle
override fun onNewToken(token: String) {
sunucuyaKaydet(token)
}
Yenilenme olayını kaçırma ihtimaline karşı, uygulama her açıldığında mevcut token'ı sunucuya göndermek ucuz bir sigorta. Sunucu tarafında aynıysa hiçbir şey yapmaz.
2. Ölü token'ları temizleyin
Kullanıcı uygulamayı sildiğinde token geçersiz hâle geliyor. Gönderim servisi size bunu bir hata koduyla bildiriyor. Bu kodu yakalayıp kaydı veritabanından silmezseniz, zamanla gönderdiğiniz bildirimlerin büyük kısmı hiç kimseye ulaşmayan çöp trafiğe dönüşüyor.
Gönderim sonucunu işlemek, "gönderdim, bitti" demekten çok daha önemli:
// Gönderim yanıtındaki hataları işle
if (hata == "UNREGISTERED" || hata == "INVALID_ARGUMENT") {
tokenKaydiniSil(token) // bu cihaz artık yok
}
3. İzni doğru anda isteyin
Hem iOS'ta hem de Android 13 ve sonrasında bildirim izni açıkça isteniyor. Ve bu izin bir kez reddedilirse sistem kutusunu bir daha gösteremiyorsunuz — kullanıcıyı ayarlara yönlendirmek zorunda kalıyorsunuz.
Bu yüzden izni uygulamanın ilk açılışında istemek en kötü strateji. Kullanıcı daha uygulamanın ne işe yaradığını bilmiyor, refleks olarak reddediyor ve o hakkı kalıcı kaybediyorsunuz.
İzlediğim yol: önce kendi ekranımda neden bildirim göndereceğimi anlatmak, kullanıcı "olur" derse sistem kutusunu açmak. "Şimdi değil" derse sistem kutusunu hiç açmamak — hakkı saklı kalıyor, sonra tekrar sorabiliyorum.
4. Bildirim gitmesi, ulaşması demek değil
Gönderim servisi "başarılı" dediğinde bildirim cihaza teslim edilmiş olmuyor; sadece kuyruğa alınmış oluyor. Arada ulaşmayı engelleyen katmanlar var:
| Sebep | Ne olur |
|---|---|
| Pil optimizasyonu / uyku modu | Bildirim gecikir veya toplu gelir |
| Üretici kısıtlamaları | Bazı markalar arka plan uygulamalarını agresif kapatır |
| Cihaz uzun süre kapalı | Süresi dolan bildirim düşer |
| Kullanıcı bildirimleri kapatmış | Sessizce hiç görünmez |
Bu yüzden kritik bilgiyi yalnızca bildirime emanet etmeyin. Bildirim bir hatırlatma katmanıdır; asıl bilgi uygulama açıldığında da görünebilir olmalı.
5. Bildirime tıklanınca doğru ekran açılmalı
En sık gördüğüm eksik bu. Kullanıcı "siparişiniz kargoya verildi" bildirimine tıklıyor, uygulama ana ekranda açılıyor ve siparişi kendisi bulmak zorunda kalıyor.
Doğru davranış, bildirimin taşıdığı veriyle doğrudan ilgili ekrana gitmek. Burada dikkat edilmesi gereken şey, uygulamanın iki farklı durumda açılabilmesi:
- Soğuk başlangıç: uygulama kapalıyken tıklandı. Bildirim verisi başlangıç akışında okunmalı ve yönlendirme, ana ekran hazır olduktan sonra yapılmalı.
- Sıcak başlangıç: uygulama arka plandaydı. Bu sefer başlangıç akışı çalışmıyor, ayrı bir olay tetikleniyor.
İki durumu ayrı ayrı ele almazsanız, biri çalışırken diğeri sessizce ana ekranda kalıyor. Test ederken ikisini de mutlaka deneyin: uygulamayı tamamen kapatıp bir kez, arka plana alıp bir kez.
6. Geri dönüş yolunu düşünün
Bildirimle derin bir ekrana giden kullanıcı geri tuşuna bastığında ne olmalı? Uygulamadan çıkmak genelde yanlış davranış. Doğru olan, o ekranın üstüne mantıklı bir gezinme yığını kurmak — kullanıcı geri bastığında ana ekrana düşmeli.
7. Sıklık, içerikten daha belirleyici
Bildirimin kullanıcıyı kaçırmasının en yaygın sebebi içeriğin kötü olması değil, çok sık gelmesi. Bildirim izni kapatıldığında geri kazanmak neredeyse imkânsız.
- Kullanıcıya bildirim türlerini ayrı ayrı kapatma imkânı verin — hepsini birden kapatmak zorunda kalmasın.
- Gece saatlerinde göndermeyin; kullanıcının yerel saatine göre planlayın.
- Aynı konuda üst üste bildirim göndermeyin, birleştirin.
Push bildirim, kullanıcının size verdiği en kırılgan izin. Bir kez kötüye kullandığınızda geri alamıyorsunuz.
- Push bildirim
- FCM
- Token yönetimi
- Derin bağlantı
- İzinler
Demir Taşdemir
Mobil Uygulama & Web Geliştirici
2018'den beri yazılım geliştiriyorum. App Store ve Google Play'de 11 uygulama yayınladım; şu an 6 mobil uygulama, 1 e-ticaret platformu ve 1 masaüstü oyun üzerinde çalışıyorum.
Detayları atlamayan bir geliştirici
Çalışan bir özellikle güvenilir çalışan bir özellik arasındaki fark, bu tür ayrıntılarda.