Gerçek Zamanlı Veri: Mobilde "Canlı"nın Gerçek Maliyeti

Gerçek zamanlı kavramı, IoT ürün spesifikasyonlarında en fazla anlam yüklenen terimlerden biridir. Kullanıcı için 'canlı veri', ekrandaki sayının sensörün o anda ölçtüğü değeri yansıtması demektir. Bunun mimarideki karşılığı ise tamamen güncelleme frekansına bağlıdır; maliyeti belirleyen de bu frekanstır.

• 500ms veya daha hızlı güncellenen sensör verisi: QoS 0 ile WebSocket veya MQTT. Bu frekansta onay mesajlarının (ACK) getirdiği ek yük (overhead), neden olduğu gecikmeye değmez.

• 1 ila 10 saniyede bir güncelleme: QoS 1 ile MQTT veya buluttan SSE. Güvenilir, hafif, altyapı karmaşıklığı olmadan ölçeklenir.

• 30 saniye veya daha yavaş güncelleme: HTTP polling. Build etmesi basit, hata ayıklaması kolay, kalıcı bağlantı ek yükü sıfır.

UX sorusu teknik soru kadar belirleyicidir. Sıcaklık sensörü okuyan kullanıcı 500ms güncellemeye ihtiyaç duymaz. Hastanın oksijen satürasyonunu izleyen cerrah duyar. Polling aralığı cihazın kapasitesine değil, kullanıcının gerçek karar hızına göre belirlenir.

Ham sensör değerlerini doğrudan ekrana yansıtmak nadiren doğru tasarımdır. Saniyede 20 kez değişen sayı bilgi değil, gürültüdür. Mobil katman veriyi render etmeden önce yumuşatmalı, toplamalı veya eşiklemelidir. Bu bir performans optimizasyonu değil, ürün kararıdır.

Canlı değerlerin yanında geçmiş verileri de göstermesi gereken uygulamalar için InfluxDB, TimescaleDB veya Amazon Timestream gibi bir zaman serisi arka ucu doğru seçimdir. Sensör olaylarını ilişkisel veritabanında saklamak, kullanıcı yüksek çözünürlükte son 30 günü görüntülemek istediği anda sorgu performans sorunları üretir.

Çevrimdışı Davranış: Çoğu Ekibin Çok Geç Aldığı Karar

Her IoT mobil uygulama, güvenilmez bağlantının olduğu bir ortamda kullanılacaktır. Depolar, inşaat alanları, hastane katları, kırsal bölgeler ve metro istasyonları yaygın dağıtım ortamlarıdır. Soru uygulamanın çevrimdışı senaryoları yönetip yönetmeyeceği değildir. Soru, arka uca ulaşamadığında ne yapacağıdır.

Üç geçerli strateji vardır ve seçim, kullanıcının harekete geçmek için hangi veriye ihtiyaç duyduğuna bağlıdır:

• Salt okunur önbellek. Uygulama bilinen son cihaz durumunu yerel olarak saklar ve çevrimdışı olduğunda net zaman damgasıyla görüntüler. Yazmalar engellenir ya da kullanıcıya bildirimle kuyruğa alınır. Çoğu tüketici IoT uygulaması için doğru varsayılan budur.

• Senkronizasyon kuyruğuyla çevrimdışı öncelik. Tüm kullanıcı aksiyonları önce yerel olarak yazılır, senkronizasyon için kuyruğa alınır ve bağlantı döndüğünde arka uca iletilir. Çakışmalar zaman damgasıyla veya kullanıcıya gösterilerek çözülür. Saha servis uygulamaları, medikal cihazlar ve kullanıcının bağlantıdan bağımsız çalışmaya devam etmesi gereken uygulamalar için doğru yapı budur.

• Bağlantı durumuna duyarlı arayüz. Uygulama bağlantı kaybını tespit eder ve arayüzünü açıkça düşürür: gerçek zamanlı grafikleri ve bulut gidiş-dönüşü gerektiren komutları devre dışı bırakır, kullanıcıyı bilgilendirir ve işlevsel tutar. Bulut bağlantısı olmaksızın BLE üzerinden cihaza erişimin sürdüğü durumlarda uygundur.

Flutter'da çevrimdışı öncelikli yapı bir yerel veritabanı (sqflite veya Drift üzerinden SQLite ya da daha basit şemalar için Hive), bir bağlantı dinleyicisi (connectivity_plus) ve bekleyen yazmaların kuyruğunu işleyen bir senkronizasyon motoru gerektirir. Çakışma çözüm stratejisi implementasyondan önce belirlenmek zorundadır; sonradan eklemek küçük bir özellik ekleme değil, büyük bir yeniden yazımdır. Zaman damgası bazlı son yazan kazanır stratejisi çoğu tüketici uygulaması için yeterlidir. İşbirlikçi veya güvenlik açısından kritik veriler için birleştirme stratejileri ya da kullanıcıya yönelik çakışma arayüzü gerekir.

Çoğu ekibin gözden kaçırdığı ayrıntı: senkronizasyon kuyruğu uygulama yeniden başlatmalarında hayatta kalmalıdır. Bekleyen aksiyonları yalnızca belleğe yazmak çevrimdışı öncelikli değildir. Uygulama kapanınca her şey gider.