Okunmamış ve Toplam mesaj sayıları, aynı “kutuyu” anlatıyor gibi görünse de aslında farklı şeyleri ölçer. Bu iki metrik arasındaki farkı anlamak, gelen kutusu uygulamalarında gördüğünüz sayıların neden bazen “tuhaf” davrandığını çözmenin en hızlı yoludur.
Önce temeli kuralım: Unread ve Total tam olarak neyi ifade eder?
Toplam (Total Messages), belirli bir posta kutusunda ya da bir konuşma akışında mevcut olan tüm mesajların sayısıdır. Buradaki kritik nokta şudur: Total, çoğu zaman sadece “kaç tane mesaj var?” sorusuna cevap verir; mesajların okunup okunmadığıyla doğrudan ilgilenmez.
Okunmamış (Unread) ise bir durum bayrağıdır. Bir mesaj “okunmadı” olarak işaretli ise unread sayısına dahil edilir; okundu olarak işaretlenirse unread azalır. Yani unread, total’ın bir alt kümesidir ama her zaman total ile bire bir aynı hızda değişmez.
Günlük hayattan örnek: Dolabınızda 50 ürün olabilir (total), ama “henüz giymedikleriniz” 7 olabilir (unread gibi). Dolaba yeni bir ürün eklenince total artar; bir ürünü giyince total değişmez ama “giymedikleriniz” azalır. Mesaj tarafında mantık da benzer çalışır.
Neden bazen Unread artıyor ama Total artmıyor?
Bu durum ilk bakışta çelişkili gelebilir. “Okunmamış sayısı artıyorsa yeni mesaj gelmiş olmalı, o zaman toplam da artmalı” diye düşünürüz. Ama pratikte şu senaryolar çok sık yaşanır:
- Durum değişimi: Bazı mesajlar, uygulama tarafından yeniden “okunmadı” olarak işaretlenebilir. Örneğin senkronizasyon sırasında bir bayrak geri dönmüş olabilir ya da çoklu cihazlarda çakışma yaşanmış olabilir.
- Filtre/segment etkisi: Ekranda gördüğünüz “Total”, belirli bir filtreye göre hesaplanıyor olabilir (ör. sadece “Primary” sekmesi, sadece belirli bir etiket). Unread sayısı ise farklı bir kapsamdan geliyor olabilir.
- Konuşma görünümü: Bazı sistemler konuşma bazlı sayar. Konuşma içinde yeni bir mesaj gelince total konuşma sayısı sabit kalır, ama unread konuşma sayısı artabilir.
- Önbellek gecikmesi: Total sayısı daha ağır bir sorgu gerektirdiği için gecikmeli güncellenir; unread daha hızlı güncellenebilir.
Özellikle mobil uygulamalarda “anlık tepki” için unread sayısı hızlı güncellenir, total ise arka planda daha sonra netleşir. Kullanıcı deneyimi açısından bu, uygulamanın “donuk” görünmesini engeller.
Peki tam tersi: Total artıyor ama Unread artmıyorsa?
Bu daha da sık görülür ve çoğu zaman normaldir. Çünkü her yeni mesaj “okunmamış” olmak zorunda değildir.
- Otomatik okundu işaretleme: Bazı istemciler, bildirime tıklayınca ya da mesaj içeriği kısmen önizlemede görünce “okundu” sayabilir.
- Kurallar ve otomasyon: Filtre kuralları bazı mesajları direkt “okundu” veya “arşivlenmiş” olarak işaretleyebilir.
- Spam/Promo ayrımı: Total sayısı bütün klasörü kapsıyor olabilir; unread ise sadece ana kutuyu sayıyor olabilir.
Bir de “toplam” metriğinin kapsamı önemlidir. Uygulama tüm mesajları sayarken, unread yalnızca belirli bir klasör ya da etiket için hesaplanıyor olabilir.
Durum (Status) güncellemeleri nasıl çalışır?
Bir mesaj sisteminde genellikle iki ana veri katmanı vardır: mesaj kayıtları ve durum bayrakları. Mesaj kaydı “bu mesaj var” bilgisidir. Durum bayrakları ise “okundu/okunmadı”, “yıldızlı”, “arşivli”, “spam”, “silindi” gibi etiketlerdir.
Uygulamalar bu durumu yönetirken çoğu zaman şu akışla ilerler:
- Yeni mesaj geldi: Sunucu mesajı oluşturur, istemciye bir güncelleme olayı (push/poll) gider.
- İstemci hızlı güncelleme yapar: Arayüzde unread veya rozet sayısı hemen değişebilir.
- Detay senkronizasyon: Uygulama arka planda “hangi mesajlar var, hangileri okunmuş” gibi listeyi yeniler.
- Sayım yeniden hesaplanır: Total ve unread gibi metrikler yeniden hesaplanıp netleşir.
Bu yüzden bazı ekranlarda sayıların “bir an yanlış görünüp” sonra düzelmesi bir bug değil, çoğu zaman tasarlanmış bir davranıştır.
Unread sayısı nasıl hesaplanır?
Okunmamış sayısı, genellikle “read=false” bayrağına sahip mesajların sayılmasıyla bulunur. Ancak modern sistemlerde bu, sandığınızdan daha karmaşık olabilir:
- Etiket bazlı okundu: Mesaj okundu bayrağı global değil, klasöre/etikete göre tutulabilir.
- Konuşma bazlı mantık: Bir konuşmada 10 mesaj vardır, 1 tanesi okunmadıysa konuşma “unread” sayılabilir.
- Önizleme/okundu sayma farkı: Bazı istemciler mesajı “açtı” saydığı an okundu işaretler, bazıları “tam görüntülendi” sayar.
Bu farklılıklar kullanıcı tarafında “ben okumadım ama okundu görünüyor” şikâyetlerine yol açabilir. Teknik tarafta ise genellikle istemci davranışı + senkronizasyon stratejisi belirleyicidir.
Total sayısı nasıl hesaplanır?
Total, çoğu zaman daha “ham” bir sayıdır: ilgili kutudaki tüm mesajlar. Ama burada da kapsam değişkendir:
- Arşiv dahil mi? Bazı ekranlar arşivi dahil eder, bazıları etmez.
- Spam/silinen dahil mi? Genelde ayrı tutulur ama bazı “All mail” görünümlerinde dahil olabilir.
- Filtreli liste mi? “Sadece bugün gelenler” gibi bir filtre varsa total sayısı o filtreye göre hesaplanır.
Bu yüzden “Total = tüm evrendeki mesaj sayısı” gibi düşünmek yanıltıcıdır. Total her zaman bir bağlama (klasör, etiket, filtre, görünüm) bağlıdır.
Neden sayıların güncellenmesi gecikebiliyor?
Türkiye’de mobil internet koşulları, cihazların arka plan kısıtlamaları ve güç tasarrufu ayarları nedeniyle bu gecikmeler daha görünür olabilir. Ama temel sebepler evrenseldir:
- Önbellek (cache): Liste hızlı açılsın diye eski sayılar gösterilir, sonra güncellenir.
- Batch senkronizasyon: Her mesaj için ayrı istek yerine toplu istek atılır; bu da “aralıklı güncelleme” hissi verir.
- Arka plan kısıtlamaları: Uygulama arka planda çalışamazsa push alınsa bile liste yenilenemez.
- Sunucu tarafı indeksleme: Total sayımı bazen daha pahalıdır; sunucu bunu gecikmeli çıkarabilir.
Sonuç: Unread hızlı değişir, total daha “ağır” hareket eder. Bazı sistemler ise tam tersini tercih edebilir. Önemli olan, iki metriğin aynı ritimde güncellenmek zorunda olmadığıdır.
Doğru yorumlamak için mini kontrol listesi
Bir gelen kutusunda sayılar kafanızı karıştırıyorsa şu soruları sırayla sorun:
- Hangi görünümdeyim? Primary mi, All mail mi, belirli bir etiket mi?
- Konuşma görünümü açık mı? Mesaj mı sayıyor, konuşma mı sayıyor?
- Filtre var mı? Tarih, arama, kategori filtresi total’ı değiştirir.
- Çoklu cihaz kullanıyor muyum? Bir cihaz okundu işaretlediğinde diğerinde sayı düşebilir.
- Arka plan senkron açık mı? Kısıtlıysa sayılar gecikebilir.
Bu soruların en az birine “evet” diyorsanız, gördüğünüz farkın sebebi büyük ihtimalle normal bir sistem davranışıdır.
Küçük bir senaryo: “Niye rozet sayısı bir inip bir çıkıyor?”
Diyelim ki telefonunuzun bildirim rozetinde 3 okunmamış mesaj görüyorsunuz. Uygulamayı açtığınızda bir an 5’e çıkıyor, sonra 3’e düşüyor. Bu genellikle şu şekilde olur:
- Uygulama açılışta hızlıca önbellekten “5” değerini gösterir.
- Arka planda sunucudan güncel durum çekilir ve aslında 2 mesajın daha önce başka cihazda okunduğu anlaşılır.
- Sayım yeniden hesaplanır ve rozet “3”e güncellenir.
Kullanıcı açısından “dalgalanma” gibi görünür. Sistem açısından ise bu, doğru veriye yaklaşma sürecidir.
Sonuç: Unread ve Total farklı soruların cevabıdır
Total size “kaç mesaj var?” der. Unread ise “kaç tanesi hâlâ dikkat istiyor?” der. Bu iki soru farklı olduğu için, cevapların da her zaman aynı anda değişmesini beklemek doğru değildir.
Bir uygulamada sayıların zaman zaman uyuşmaması, çoğu zaman filtreler, konuşma mantığı, önbellek ve senkronizasyon stratejilerinin doğal sonucudur. En iyi yaklaşım, hangi görünümde hangi metriğin hesaplandığını bilmek ve “sayılar niye böyle?” sorusunu bağlamla birlikte okumaktır.