Tüm yazılar Mobil Geliştirme

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.

DT
Demir Taşdemir Mobil Uygulama & Web Geliştirici
— dk okuma

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)
}
Uygulama her açıldığında da gönderin

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:

SebepNe olur
Pil optimizasyonu / uyku moduBildirim 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
Paylaş: LinkedIn X WhatsApp
DT

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.