React Native ile lojistik uygulamaları: beş projeden çıkan dersler

Müşteri projeleri kapsamında lojistik sektöründen beş firma için mobil uygulama geliştirdim. Bunların dördü müşteriye dönük: Buzmavi, Mitlog, CDA Lojistik ve Almark Global Lojistik için, firmaların müşterilerinin lojistik takip ve iletişim süreçlerini kolaylaştıran uygulamalar. Beşincisi ise içe dönük: TCT Lojistik'in deposunda yük giriş ve çıkışlarını barkodla takip eden bir operasyon uygulaması. Ben Berke Özyaşar; bu yazıda bu projelerden çıkardığım pratik dersleri derledim. Lojistik firmanız için mobil uygulama düşünüyorsanız, başlamadan önce bilmeniz gerekenlerin önemli bir kısmı burada.

Önce soru: uygulama kimin için?

Lojistikte "mobil uygulama" denince birbirinden çok farklı iki ürün akla gelebilir. Birincisi müşteriye dönük uygulama: ihracatçı ya da ithalatçı müşteriniz yükünün nerede olduğunu, hangi aşamada beklediğini ve kime ulaşması gerektiğini telefonundan görür. İkincisi operasyon uygulaması: depo çalışanı, şoför ya da saha personeli işini telefondan yürütür. Aynı firmada bile bu ikisi ayrı uygulamalar olmalı; kullanıcıları, ekranları, güvenlik ihtiyaçları ve başarı ölçütleri tamamen farklı.

Müşteri uygulamasında hedef, operasyon ekibine gelen "yüküm nerede" telefonlarını azaltmak ve müşteriye profesyonel bir kanal sunmak. Operasyon uygulamasında hedef ise hız ve hatasızlık: bir koliyi okutmak gereğinden uzun sürüyorsa ekip uygulamayı kullanmayı bırakır ve kağıda geri döner.

Neden React Native

Bu projelerin hepsini React Native ile geliştirdim. Lojistik firmalarının müşterileri hem iPhone hem Android kullanıyor; iki ayrı yerel uygulama yazmak hem geliştirme hem bakım maliyetini ikiye katlıyor. React Native ile tek kod tabanından iki platform için uygulama çıkıyor ve bir özellik eklendiğinde ikisinde birden yayına giriyor. Kamera, push bildirimleri, harita ve yazıcı iletişimi gibi cihaz özellikleri için olgun kütüphaneler var; gerektiğinde yerel modül yazmak da mümkün.

Platform tercihi her projede aynı olmadı. Buzmavi ve Mitlog hem App Store hem Google Play'de yayında; CDA ve Almark uygulamaları Google Play'de. Depo uygulaması ise depoda kullanılan Android cihazlar için hazırlandı. Kod tabanı baştan iki platforma uygun yazıldığında, ileride bir iOS sürümü eklemek yeni bir proje değil, çok daha küçük bir iş oluyor.

Müşteri uygulamasında olması gerekenler

Müşteriye dönük bir lojistik uygulamasının ilk sürümünde uzun bir özellik listesine gerek yok. Aşağıdaki birkaç başlık doğru yapıldığında uygulama kullanılıyor:

• Gönderi listesi ve detay: Müşterinin aktif yükleri, her birinin güncel durumu ve geçmiş hareketleri. Durum adları operasyon ekibinin iç jargonuyla değil, müşterinin anlayacağı dille yazılmalı.
• Bildirimler: Durum değiştiğinde gelen push bildirimi, uygulamanın en çok değer ürettiği yer. Ama her küçük değişiklikte bildirim göndermek kullanıcının bildirimleri kapatmasıyla sonuçlanır; hangi olayların bildirim gerektirdiğini operasyon ekibiyle birlikte seçmek gerekiyor.
• İletişim: İlgili temsilciye tek dokunuşla arama, e-posta ya da mesaj. Müşteri bir sorun yaşadığında kime ulaşacağını aramamalı.
• Belgeler: Firmanın sistemi dijital olarak tutuyorsa konşimento, fatura ve gümrük evrakı gibi belgelere erişim.
• Güvenli giriş: Her müşteri yalnızca kendi yüklerini görmeli. Yetkilendirme sunucu tarafında yapılmalı; uygulamanın kendisine güvenilmemeli.

En zor kısım: mevcut sisteme bağlanmak

Lojistik firmalarının neredeyse hepsinde yıllardır kullanılan bir operasyon yazılımı ya da veritabanı var. Mobil uygulamanın değeri, bu sistemdeki veriyi doğru ve güncel göstermesine bağlı. Bu yüzden projenin en kritik aşaması çoğu zaman arayüz değil, entegrasyon oluyor.

TCT projesinde uygulama, firmanın mevcut ASP.NET Core ve SQL Server altyapısına bağlandı; mevcut sistemi değiştirmek yerine onun üzerine kuruldu. Genel yaklaşımım da bu: mobil uygulama doğrudan veritabanına değil, kimlik doğrulaması yapan ve yalnızca gereken veriyi dönen bir API katmanına bağlanmalı. Böylece veritabanı yapısı değişse bile mobil uygulama etkilenmez, güvenlik tek noktadan yönetilir.

Entegrasyonda dikkat ettiğim noktalar:

• Durum kodlarının ve alanların anlamını operasyon ekibiyle tek tek doğrulamak. Veritabanındaki bir alanın adı ile gerçekte ne için kullanıldığı her zaman aynı değil.
• Yavaş ya da kesintili ağlarda uygulamanın donmaması için zaman aşımları, yeniden deneme ve anlaşılır hata mesajları.
• Uzun listelerde sayfalama; yıllar içinde biriken veriyi tek seferde telefona çekmemek.
• Oturum süresi ve token yenileme. TCT uygulamasında kimlik doğrulama JWT ile yapılıyor.

Operasyon uygulaması başka bir dünya

TCT depo uygulaması müşteri uygulamalarından çok farklı bir iş çıkardı. Burada kullanıcı depo çalışanı; uygulama yük girişinde ve çıkışında koli barkodlarını kamerayla okuyor, barkod okunamadığında OCR ile etiketteki yazıyı okuyor, araç plakası seçiliyor ve etiketler Zebra yazıcılardan ağ üzerinden basılıyor. Böyle bir uygulamada başarı ölçütü ekranların görünüşü değil; eldiven giymiş birinin, kötü ışıkta, hızlıca ve hatasız işlem yapabilmesi. Büyük dokunma alanları, net geri bildirim ve en az adımlı akışlar bu yüzden önemli. Bu projenin teknik ayrıntılarını barkodlu depo uygulaması yazısında anlattım.

Mağaza süreci: hesabı baştan planlayın

Müşteri projelerinde uygulamanın kimin adına yayınlanacağı baştan netleşmeli. Buzmavi ve Mitlog, App Store'da firmaların kendi geliştirici hesaplarıyla yayında; uygulama mağazada firmanın adıyla görünüyor ve hesap firmada kalıyor. Bunun için kurumsal bir Apple Developer hesabı gerekiyor ve D-U-N-S numarası gibi adımlar yüzünden bu süreç beklenenden uzun sürebiliyor. Geliştirmeye başlarken hesap başvurusunu da başlatmak, yayın tarihini kaydırmamanın en kolay yolu.

Mağaza incelemesinde lojistik uygulamalarına özgü birkaç konu var:

• Demo hesap: Uygulama girişle açılıyorsa, inceleme ekibine içinde örnek veri olan bir test hesabı verilmeli. Gerçek müşteri verisi göstermeden bunu hazırlamak ayrı bir iş.
• Hesap silme: Uygulamada hesap oluşturulabiliyorsa, kullanıcının hesabını silebileceği bir yol sunulmalı.
• İzin açıklamaları: Konum, bildirim ve kamera gibi izinlerin neden istendiği açıkça yazılmalı; kullanılmayan izin istenmemeli.
• Web sitesini saran uygulamalar incelemede sorun yaşayabiliyor. Uygulamanın bildirimler ve yerel ekranlarla gerçek bir mobil deneyim sunması gerekiyor.

Yayından sonra

Mobil uygulama yayınlandığı gün bitmiyor. iOS ve Android her yıl yeni sürümler çıkarıyor, Google Play hedef SDK şartlarını düzenli olarak güncelliyor ve React Native'in kendisi de hızla gelişiyor. Bakımı planlanmamış bir uygulama bir iki yıl içinde güncellenemez hale gelebiliyor. Bu yüzden yayın sonrasında da düzenli sürüm güncellemesi yapılmasını öneriyorum; bu hem güvenlik hem mağaza uyumluluğu için gerekli.

Özetle

Lojistik firması için iyi bir mobil uygulama az ama doğru ekranla başlar: gönderi durumu, anlamlı bildirimler ve kolay iletişim. İşin asıl zorluğu mevcut sisteme sağlam bir API ile bağlanmak ve mağaza sürecini baştan planlamak. Firmanız için benzer bir uygulama düşünüyorsanız, mobil uygulama geliştirme sayfasında nasıl çalıştığımı bulabilir, oradan bana ulaşabilirsiniz.