İş uygulamalarında NFC ve barkod tarama: pratik veri akışı
Ön saha ekiplerinin hızlı ve güvenilir çalışması için iş uygulamalarında NFC ve barkod taramayı net bir veri akışı, sağlam hata yönetimi ve çevrimdışı depolama ile tasarlayın.

Önde çalışanlar için taramanın hızlı hissetmesi gerekenler
Önde çalışanların tarama işi sakin bir masa işi değildir. İnsanlar yürürken, eldivenle, bir kutuya tutunurken veya telefonu tek elle dengelerken tarama yapar. Aydınlatma sert olabilir, ortam gürültülü olabilir ve ağ aniden kopabilir.
Hız çoğunlukla tereddüdü ortadan kaldırmaktan gelir. Uygulama, sunucu yavaş veya ulaşılamaz olsa bile her taramayı hemen bitmiş gibi hissettirmelidir. Bu, çalışanların güvendiği bir tarama uygulaması ile yoğun olduğunda kaçındıkları bir uygulama arasındaki farktır.
Tasarlamanız gereken gerçek kısıtlar
Tarayıcı akışları küçük, öngörülebilir şekillerde başarısız olur: etiketlerde parlamalar, titreyen eller, çok hızlı veya yeterince yakın olmayan NFC dokunuşları ve yanlışlıkla kolayca basılabilen düğmeler.
Bağlantı en büyük gizli kısıttır. Her tarama backend'e gidip gelmeyi gerektiriyorsa sıra yavaşlar. İnsanlar yeniden tarar, çoğaltmalar birikir ve uygulama güven kaybeder.
"Hız" sayılarla nasıl görünür
Birkaç başarı metriği seçin ve UI ile veri akışını bunları tutacak şekilde tasarlayın:
- Tarama başına süre (tetikleme ile onay arası)
- Hata oranı (kötü okumalar, geçersiz kodlar, çiftler)
- Kurtarma süresi (hata, düzeltme, devam)
- Çevrimdışı başarı oranı (ağ olmadan kaydedilen taramalar)
Her taramada neler olmalı
Basit iş akışları bile aynı ritmi paylaşır: yakala, kontrol et, yorumla, mevcut göreve iliştir ve onayla. Bu ritmi tutarlı tutun ki kullanıcıların düşünmesine gerek kalmasın.
Her taramada uygulama şunları yapmalıdır:
- Girdiyi yakala (barkod stringi veya NFC yükü)
- Doğrula (format, check digit, izin verilen tür)
- Ne anlama geldiğini çözümle (kalem, varlık, konum, sipariş)
- Bunu mevcut göreve uygula (kabul, toplama, denetim)
- Hemen onayla (ses, titreşim, ekranda net durum)
Örnek: bir kabul görevlisi bir karton barkodunu tarar, sonra palet üzerinde bir NFC etiketi dokunur. Uygulama "Added to Receiving: PO-1842" gibi bir onayı hemen göstermeli, ayrıntılı ürün adı bir saniye sonra yüklense bile. Eğer arama başarısız olursa, kullanıcı hâlâ "Çevrimdışı kaydedildi, bağlantı olunca doğrulanacak" veya "İncelemesi gerekiyor: bilinmeyen kod" gibi net bir sonraki adım gösteren kayıt görmelidir.
Planlanacak girdiler ve tarama olayları
Tarama ancak bir tanımlayıcının uygulamaya girebileceği her yolu planlarsanız anlık hisseder; sadece mutlu yolu düşünmeyin. Her girdiyi aynı türde bir şey olarak ele alın: yakalanması, kontrol edilmesi ve hızla kabul veya reddedilmesi gereken bir aday kimlik.
Çoğu ekip koşullar değiştiği için birden fazla girdi yöntemine ihtiyaç duyar (eldiven, düşük ışık, kırık etiketler, boş pil). Yaygın girdiler kamera tarama, donanım tarayıcılar (Bluetooth veya yerleşik tetikleyiciler), NFC dokunuşları ve manuel giriştir. Kısa bir “son taramalar” listesi, biri yeniden taramadan öğeyi yeniden seçmesi gerektiğinde yardımcı olur.
Girdiler netleşince, küçük bir durum makinesi gibi tarama tetiklerini ve olayları tanımlayın. Bu UI'yi öngörülebilir kılar ve günlükleme ile hata ayıklamayı kolaylaştırır:
- Tarama başladı
- Tarama okundu
- Çift tespit edildi
- Zaman aşımı
- İptal edildi
Her tarama okuması için, doğrulama başarısız olsa bile neyi saklayacağınıza karar verin. Ham değeri (kesin string) ve ayrıştırılmış alanları (SKU veya GTIN gibi) kaydedin. Barkodlar için, varsa simboloji (QR, Code 128, EAN-13) ve herhangi bir tarayıcı meta verisini saklayın. NFC için, etiket UID'sini ve NDEF okunuyorsa ham yükü saklayın.
Bağlamı da yakalayın: zaman damgası, cihaz modeli, uygulama sürümü ve “nerede” (depo, konum, kullanıcı, oturum, iş akışı adımı). Bu bağlam genellikle belirsiz bir destek kaydı ile hızlı bir düzeltme arasındaki farktır.
Veri modeli: tarama kayıtlarını basit ve izlenebilir tutun
Hız, kasıtlı olarak sıkıcı bir veri modeliyle başlar. Amaç, her taramayı hızlıca kaydetmek, ne anlama geldiğini çözmek ve daha sonra kim, nerede ve ne zaman yaptığını kanıtlayabilmektir.
Item, Location, Task/WorkOrder, User ve Device gibi stabil temel varlıklarla başlayın. Bunları tutarlı tutun ki tarama akışı karmaşık join'lere veya isteğe bağlı alanlara bağlı olmasın.
Ardından bir merkezi olay tablosu ekleyin: ScanRecord. Bunu değişmez bir günlük olarak ele alın. Bir şey düzeltilmesi gerekiyorsa, geçmişi yeniden yazmak yerine eski kayda referans veren yeni bir kayıt oluşturun.
Pratik bir ScanRecord genellikle şunları içerir:
scan_id(yerel UUID)scanned_value(ham string veya NFC yükü)scan_type(barkod, QR, NFC)parsed_fields(sku, lot, serial, tag_id, eşleşen Item ID)status(captured, parsed, validated, queued, synced, rejected)error_code(sayılabilir kısa, tutarlı kodlar)retry_count(sonsuz denemeyi önlemek için)
Ayrıştırılmış alanları küçük ve öngörülebilir tutun. Bir barkod birden fazla parça kodluyorsa, ham değeri ve ayrıştırılmış parçaları saklayın ki kurallar değişirse daha sonra yeniden ayrıştırabilesiniz.
İdempotans, biri iki kez taradığında, Kaydet'e iki kez bastığında veya ağ yeniden denediğinde çift işleme önler. Bir idempotency_key iş eylemi başına üretin, API çağrısı başına değil. Basit bir kural: task_id + scan_type + scanned_value + time_bucket(2-5 seconds). Sunucuda, kopyaları reddedin ve orijinal sonucu döndürün.
Örnek: kabul sırasında bir çalışan palet NFC etiketini tarar, sonra üç ürün barkodu tarar. Her tarama kendi ScanRecord'u olur ve aynı Task'e bağlanır. Cihaz çevrimdışıysa bile uygulama hemen “captured” gösterir ve sonraki senkron güvenle yeniden oynatılabilir, çift alımlar oluşturulmaz.
Tarama ile kaydedilmiş sonuç arasındaki adım adım veri akışı
Hızlı bir tarama akışı iki kurala dayanır: anında onayla ve ağ düşse bile taramayı asla kaybetme.
1) Taramayı yakala ve anında onayla
Kamera çözücüsü veya NFC okuyucusu bir değer döndüğünde bunu bir olay gibi ele alın. Yerel olarak hemen onaylayın: kısa bir bip, bir titreşim ve ekranda hızlı bir “Kaydedildi” etiketi veya vurgusu. Bunu herhangi bir ağ çağrısından önce yapın.
Ham girdiyi hemen saklayın (örneğin: rawValue, symbology veya tagType, zaman damgası, cihaz id, kullanıcı id). Bu, UI'nin duyarlı hissetmesini sağlar ve sonraki adımlar başarısız olsa bile saklanacak bir şey verir.
2) Kolay hataları yakalamak için yerelde doğrulayın
Cihazda ucuz kontroller çalıştırın: beklenen uzunluk, check digit (yaygın kodlar için), bilinen önekler ve izin verilen NFC etiket türleri. Eğer başarısız olursa, kullanıcıya ne yapması gerektiğini söyleyen kısa bir mesaj gösterin ("Yanlış etiket türü. Raf etiketini tarayın."), sonra tarayıcıyı bir sonraki denemeye hazır tutun.
3) Önce yerel referans verisini kullanarak anlamı çözün
Ham taramayı iş anlamına dönüştürün (SKU, varlık id, konum id). Öncelikle yerelde önbelleğe alınmış referans tablolarla başlayın ki çoğu tarama ağ gerektirmesin. Kod bilinmiyorsa, şimdi sunucuyu çağırıp çağırmamaya iş akışına göre karar verin; veya “çözümlenmemiş” olarak kabul edip devam edin.
4) İş kurallarını uygulayın ve değişmez bir tarama kaydı yazın
Yerelde kuralları uygulayın: miktar varsayılanları, izin verilen konum, görev durumu (receiving vs picking), çift işleme yönetimi ve gerekli alanlar.
Sonra yerel veritabanına tek bir işlem olarak yazın:
- Bir scan record oluşturun (ham girdi + ayrıştırılmış id + kim/nerede/ne zaman)
- Çalışma belgesini güncelleyin (fiş, sayım sayfası, iş emri)
- Kararı kaydedin (accepted, rejected, needs review)
- UI için yerel sayaçları güncelleyin
Bu “tarama kaydı ekle, sonra toplamları türet” yaklaşımı denetimleri ve düzeltmeleri çok daha kolay yapar.
5) Senkron kuyruğu oluşturun, UI'yi güncelleyin ve kullanıcıyı ilerletin
Kaydedilen tarama kaydına işaret eden bir senkron olay oluşturun, onu pending olarak işaretleyin ve kontrolü kullanıcıya geri verin. Bir sonraki alana geçin, taramaya döngüyle devam edin veya beklemeden bir sonraki adıma ilerleyin.
Kötü bağlantıyı atlatan çevrimdışı depolama ve senkronizasyon
Ağın en kötü zamanda başarısız olacağını varsayın: bir deponun arka köşesinde, bir kamyon içinde veya kimsenin bir yükleme çarkını bekleyemeyeceği yoğun bir vardiyada.
Burada çevrimdışı-öncelikli yaklaşım iyi çalışır: kullanıcı çalışırken yerel veritabanı gerçek kaynak olur. Her tarama önce yerelde yazılır. Senkron arka planda yakalanmak için bir görev olarak çalışır.
Çevrimdışında neyin olması gerektiğine karar verin. Çoğu ekip, tüm şirket veritabanını değil, vardiya için gereken alt kümesini önbelleğe almakla en iyi sonucu alır: aktif görevler için SKU alt kümesi, açık kabul veya toplama listeleri, konum ve konteyner ID'leri, izin anlık görüntüsü ve birim/sebep kodları gibi temel referans verileri.
Yazmaları güvenli tutmak için bir outbox kuyruğu kullanın. Sunucu verisini değiştiren her tarama bir kuyruk komutu oluşturur (örneğin, "X öğesini B kutusuna Y adet alındı"). Uygulama komut kaydedildiği anda başarıyı gösterir, sonra senkron komutları sırayla gönderir.
Outbox kurallarını katı tutun:
- Sıralamanın korunması gereken eylemler için sırayı koruyun
- Geri denemelerde backoff kullanın, ancak kalıcı hatalar için durdurup net mesaj gösterin
- Müşteri tarafından üretilen ID ile komutları idempotent yapın
- Komutu oluşturanın kim olduğunu, ne zaman ve hangi cihazı kaydedin
Çakışma kuralları gerçek dünyaya uymalıdır. Envanter için sunucu genellikle miktarlar konusunda yetkilidir, ancak taramayı engellememelisiniz, zorunda kalmadığınız sürece. Yaygın yaklaşım: çevrimdışını izin verin, sonra senkron esnasında çatışmaları çözün ve net bir "inceleme gerekli" durumu gösterin (örneğin, kutu kilitli veya görev kapatılmış). Sadece eylem güvensiz olursa (izin yok, bilinmeyen konum) yerelde engelleyin.
Yeniden başlatmaları planlayın. Bir uygulama yeniden başlatmasından sonra önbelleği yeniden yükleyin, outbox'ı yeniden canlandırın ve kullanıcıya hiçbir şeyi yeniden yapmasını sormadan senkronizasyona devam edin.
Örnek: bir kabul görevlisi uçak modu sırasında 40 karton tarar. Her karton "received (pending sync)" olarak görünür. Wi-Fi geri geldiğinde uygulama outbox'u yükler. Eğer 2 karton başka bir çalışan tarafından zaten alındıysa, o satırlar "çakışma" durumuna geçer ve kısa bir işlem sunar: "bu fişten çıkar" veya "farklı bir göreve ata".
Kullanıcıların saniyeler içinde toparlanmasına yardımcı olan hata yönetimi
Ön saha taramaları birkaç öngörülebilir şekilde başarısız olur. Bu hataları açıkça adlandırın ve her birini amaçlı olarak ele alın; böylece insanlar tahmin etmeyi bırakır.
Basit bir taksonomi yardımcı olur:
- Okuma hatası: kamera barkodu göremiyor, NFC menzil dışında, izin reddedildi
- Doğrulama hatası: okunabiliyor ama yanlış format (yanlış simboloji, kötü check digit, beklenmeyen etiket türü)
- İş kuralı hatası: geçerli kod ama izinli değil (bu PO'da değil, zaten alındı, yanlış konum)
- Sunucu hatası: API ulaşılamıyor veya backend 5xx döndürüyor
Kullanıcının gördüğü teknik nedenden daha önemlidir. İyi bir mesaj üç şeyi cevaplar:
- Ne oldu (bir cümle)
- Sonraki adım ne (bir net eylem)
- Nasıl düzeltilir (bir hızlı ipucu)
Örnekler: “Barkod okunamadı. Sabit tutun ve daha yakınlaştırın. Etiket parlaksa el fenerini açın.” Veya: “Bu ürün teslimat listesinde değil. PO numarasını kontrol edin veya Manuel giriş seçin.”
Hataları engelleyici veya engelleyici olmayan olarak görün. Engelleyici hatalar iş akışını durdurur çünkü uygulama taramaya güvenemez veya devam etmek kötü envanter yaratır. Engelleyici olmayan hatalar hattı durdurmamalıdır. Sunucu çalışmıyorsa, yerelde zaman damgası, cihaz ID, kullanıcı ve ham değer ile kaydedip "pending sync" olarak işaretleyin ve kullanıcıya devam etme imkanı verin.
Kullanıcının uygulamayı gözlemlemesi gerekmesin diye otomatik kurtarma kurun. Ağ çağrılarını kısa backoff ile yeniden deneyin, bayat önbellekleri yenileyin ve mümkünse çevrimdışı bakmaya geri dönün. Güvenliyse, denetimli bir geçersiz kılmaya izin verin (örneğin, bilinmeyen kodu bir sebep notu ve yönetici PIN'i ile kabul et).
Yüksek hacimli tarama için performans desenleri
İnsanlar saatte yüzlerce öğe taradığında uygulamanın tek işi: sonraki taramayı anında kabul etmektir. Tarayıcı ekranını asla engellemeyen, asla zıplamayan ve kullanıcıyı ağa bekleten bir merkez gibi ele alın.
“Bir tarama, bir sunucu çağrısı” yapmayı durdurun. Önce yerelde kaydedin, sonra toplu olarak senkronize edin. Eğer bir şeyi doğrulamanız gerekiyorsa (örneğin "bu SKU bu siparişte izinli mi?"), öncelikle önceden yüklenmiş referans verileri kullanmayı tercih edin ve bir şey yanlış görünüyorsa sunucuya yükseltin.
Birkaç küçük seçim büyük fark yaratır:
- Her taramadan sonra spinner göstermeyin. Kayıt yazılırken yerelde onay verin (ses, dokunma, renk flaşı).
- Ağ işlerini partiler halinde yapın. Her N taramada veya her X saniyede yükleyin ve senkron sırasında taramaya devam edin.
- Çiftleri debounce edin. Aynı kod 1-3 saniye içinde tekrar okunursa, çift saymak yerine bir uyarı gösterin.
- Görev için gerekenleri önceden yükleyin. Kabul listelerini, izin verilen konumları ve item master verisini taramadan önce önbelleğe alın.
- Ekranı stabil tutun. Taramanın gerçekleştiği alanı odakta tutun ve onayı hep aynı yerde gösterin.
Debounce için kullanıcıların güveneceği bir kural gerekir. "Aynı payload + aynı bağlam (sipariş, konum, kullanıcı) kısa bir pencere içinde = çift" açıklaması kolaydır. Yine de iki aynı barkodlu iki ayrı ürün gibi meşru tekrarlar için geçersiz kılma izni verin.
"Yavaş hissetmek"ten ziyade adım başına süreyi ölçün
Hatı ölçmüyorsanız yanlış tahmin edersiniz. Hangi kısmın darboğaz olduğunu görmek için tarama başına zamanlamaları kaydedin:
- Yakalamadan dekoda değere kadar
- Dekoddan ayrıştırılmış alanlara (SKU, parti, tag ID)
- Ayrıştırmadan yerel yazma tamamlanmasına
- Yerel yazmadan senkron kuyruğuna
- Senkron kuyruğundan sunucunun kabulüne
Örnek: vardiya başladığında satın alma siparişindeki öğeleri önceden yükleyin. Her tarama hemen yerel bir fiş satırı yazar. Senkron arka planda parçalara ayrılarak olur. Bağlantı düşerse, tarama hızı aynı kalır ve kullanıcı sadece küçük bir "Senkron beklemede" sayacı görür.
İş akışını yavaşlatmadan güvenlik ve denetim
Taramalar genellikle yoğun, halka açık yerlerde gerçekleşir. Kodların fotoğraflanabileceğini, kopyalanabileceğini veya paylaşılabileceğini varsayın. Taranan değerleri kimlik kanıtı değil, güvensiz girdi olarak ele alın.
Ek tıklama eklemeden daha güvenli kalmanın basit bir kuralı: kullanıcıya işi bitirmek için gereken kadarını saklayın. Eğer tarama sadece bir arama anahtarı ise, anahtarı ve ekranda gösterdiğiniz sonucu saklayın, tam yükü değil. Yerel önbellekleri paylaşılan cihazlarda vardiya sonunda veya kısa bir boşta kalma penceresinde temizleyin.
Oynatılmış veya garip girdilere karşı koruma
Hızlı doğrulama kötü verinin yayılmasını engeller. Ağırlıklı olarak ağ çağrısı veya pahalı ayrıştırmadan önce hemen ucuz kontroller yapın:
- Beklenmeyen önekleri veya simbolojileri reddedin
- Uzunluk sınırları ve karakter setlerini zorunlu kılın
- Gerekirse kodlama ve yapı doğrulaması yapın (UTF-8, base64, gerekli JSON alanları)
- Basit bütünlük kurallarını kontrol edin (check digit, izin verilen aralık, bilinen etiket türü)
- Açıkça tehlikeli içeriği engelleyin (çok uzun stringler, kontrol karakterleri)
Bir tarama doğrulamadan geçmezse, tek satırlık bir neden ve bir kurtarma eylemi gösterin (Yeniden Tara, Elle Gir, Sonlardan Seç). Korkutucu ifadelerden kaçının. Kullanıcının sadece bir sonraki adımı bilmesi yeterlidir.
Taramanın yavaşlamadığı denetim izleri
Denetim ekstra ekran gerektirmemeli. Uygulama taramayı kabul ettiği anda yakalasın:
- Kim: giriş yapılmış kullanıcı ID'si (ve gerekirse rol)
- Nerede: site/bölge (kullandığınızsa GPS bucket)
- Ne zaman: cihaz zamanı artı senkron esnasında sunucu zamanı
- Ne: ham tarama değeri (veya hash'i), ayrıştırılmış kimlik ve eşleşen varlık ID
- Eylem: received, moved, counted, issued, corrected, voided
Örnek: kabulde uygulama bir palet barkodunu ve sonra bir konumda NFC etiketine dokunmayı tarar. Her iki olayı zaman damgası ve oluşan hareketle kaydedin. Çevrimdışıysa denetim olaylarını yerelde kuyruklayın ve senkronlaştığında sunucu fiş ID'sini ekleyin.
Örnek: barkod + NFC ile depo kabul akışı
Bir kamyon karışık bir palet getirir: bazı vakalar basılı barkod içerir, bazıları etiketin içinde bir NFC etiketi de barındırır. Alıcının amacı basittir: PO için doğru ürünleri onaylamak, hızlı saymak ve hattı durdurmadan stoku yerleştirmek.
Alıcı "Receive PO" ekranını açar, PO'yu seçer ve taramaya başlar. Her tarama hemen yerel bir ScanRecord oluşturur (zaman damgası, kullanıcı, PO id, öğe kimliği, ham tarama değeri, cihaz id ve pending gibi bir durum). Ekran öncelikle yerel veriden toplamları günceller; böylece sayım anında hissedilir.
Adım adım: taramadan yerleştirmeye kadar
Döngü basit kalmalıdır:
- Barkodu tara (veya NFC'ye dokun). Uygulama bunu PO maddesiyle eşleştirir ve öğe adı ile kalan beklenen miktarı gösterir.
- Miktarı gir (varsayılan 1, kutular için hızlı +/- düğmeleri). Uygulama kaydeder ve toplamları günceller.
- Depolama konumunu tara veya seç. Uygulama konum kurallarını doğrular ve atamayı kaydeder.
- Senkron durumu için küçük bir bant tutun (Online veya Offline) ama sonraki taramayı engellemeyin.
Ağ bir paletin ortasında düşerse, hiçbir şey durmaz. Taramalar devam eder ve PO açıkken indirilen önbelleğe alınmış PO satırları ve konum kurallarına göre doğrulanır. Her kayıt çevrimdışı kuyrukta pending kalır.
Bağlantı geri geldiğinde, senkron arka planda çalışır: bekleyen kayıtları sırayla yükler, sonra güncellenmiş PO toplamlarını çeker. Başka bir cihaz aynı PO'yu aynı anda almışsa, sunucu kalan miktarları ayarlayabilir. Uygulama "Senkron sonrası toplamlar güncellendi" gibi kesintisiz bir bildirim göstermelidir.
Hatalar kullanıcıyı yavaşlatmadan nasıl gösterilir
Hataları spesifik ve eylem odaklı tutun:
- Yanlış ürün: "Bu PO'da yok" seçenekleriyle (PO değiştir veya beklenmeyen olarak işaretle)
- Çift tarama: "Zaten alındı" son taramayı hızlıca gösteren ve izin verilmişse geçersiz kıl seçenekli bir görünüm
- Kısıtlı konum: "Bu ürün için izinli değil" yakındaki önerilen konumla
- Hasarlı etiket: manuel girişe (son 4-6 hane) veya varsa NFC'ye geçiş
Hızlı kontrol listesi ve sonraki adımlar
Gömmeden önce, gerçek bir cihazla sahada test edin. Hız, kullanıcının gördüğüne ve ağ kötü olduğunda uygulamanın ne yapmaya devam ettiğine bağlıdır.
En çok sorunu yakalayan hızlı kontroller:
- Her taramada anında geri bildirim (ses, titreşim, net ekranda durum)
- Önce yerelde kaydet, sonra senkronize et (hiçbir tarama sunucu round trip'ine bağlı olmasın)
- Basit durumlu görünür bir senkron kuyruğu (Pending, Sent, Failed)
- Gerçek kurallarınıza uyan çift koruması
- Tek en iyi sonraki eylemi sunan net hatalar
İş akışını insanların gerçekten çalışma şekliyle baskı testi yapın:
- Bir vardiya boyunca uçak modu, sonra yeniden bağlanıp senkronize edin
- Parti ortasında zorla kapat, yeniden aç ve hiçbir şey kaybolmadığını doğrula
- Yanlış cihaz saati (clock skew) ve saat dilimi değişiklikleri
- Düşük pil modu ve neredeyse bitmek üzere olan bir pil
- Büyük partiler (500+ tarama) ve tek oturumda karışık NFC + barkod
Operasyonel alışkanlıklar da önemlidir. Basit bir kural öğretin: bir tarama iki kez başarısız olursa, manuel giriş yapın ve not ekleyin. Kötü etiketleri bildirme yöntemini tanımlayın (fotoğraf, "okunamaz" işareti, kenara ayırma) ki tek bir kötü etiket hattı bloke etmesin.
Eğer sıfırdan başlamak istemiyor ve bu tür çevrimdışı-öncelikli bir tarama uygulaması inşa etmek istiyorsanız, AppMaster (appmaster.io) size veri modelini, iş mantığını ve mobil UI'yı tek bir yerde modelleme ve üretime hazır backend, web ve native iOS/Android uygulamaları oluşturma imkanı verir.
SSS
Anında yerel onay hedefleyin: tarayıcı bir değer döndüğünde hemen bir bip veya titreşim ile net bir ekranda “kaydedildi” durumu gösterin. Sunucudan yanıt beklemeyin; taramayı önce yerelde kaydedin ve arka planda senkronize edin.
Kamera taraması, dahili veya Bluetooth donanım tetikleyicileri, NFC dokunuşları ve yedek olarak manuel giriş için tasarlayın. Hepsini aynı şekilde ele alın: hızlıca yakalanan, doğrulanan ve kabul veya reddedilen bir aday kimlik; onay davranışı aynı olsun.
Her zaman ham taranan değeri (tam string veya NFC yükü), tarama türünü, zaman damgasını, kullanıcıyı, cihazı ve iş akışı bağlamını (görev, konum, adım) saklayın. Mümkünse ayrıştırılmış alanları da kaydedin ki daha sonra hata ayıklama veya yeniden ayrıştırma yapabilesiniz.
Basit bir olay tablosu olan ScanRecord gibi değişmez bir günlük kullanın ve geçmişi yeniden yazmaktan kaçının. Bir şey düzeltilmesi gerekiyorsa, orijinal taramayı kaybetmeden eski kayda referans veren yeni bir kayıt oluşturun.
İşsel eylem başına bir idempotency anahtarı oluşturun, böylece yeniden denemeler veya çift taramalar yinelenen kayıt oluşturmaz. Pratik bir varsayılan, görev bağlamı + taranan değer + kısa bir zaman kutusunu birleştirmektir; sunucu aynı anahtarı görürse orijinal sonucu döndürsün.
Cihazda önce ucuz kontroller yapın: beklenen uzunluk, izin verilen önekler, yaygın kodlar için doğrulama basamakları ve NFC için izin verilen etiket türleri. Doğrulama başarısız olursa, tek satırlık bir yönerge gösterin ve tarayıcıyı hemen sonraki denemeye hazır tutun.
Yerel veritabanını vardiya sırasında gerçek kaynak olarak kullanın: her taramayı önce yerelde kaydedin, sonra bir outbox kuyruğuna senkron komutu ekleyin. Senkron otomatik olarak geri denemeli, gerektiğinde sıra korumalı, ve uygulama yeniden başlatıldığında kullanıcıdan işi tekrar etmesini istemeden devam edebilmelidir.
Basit, tutarlı hata türleri kullanın: okuma hatası, doğrulama hatası, iş kuralı hatası ve sunucu hatası. Her mesaj ne olduğunu, sonraki yapılacak tek adımı ve kısa bir ipucunu söylemeli; yalnızca ilerlemek güvensiz veri yaratacaksa iş akışını engelleyin.
“Bir tarama, bir sunucu çağrısı” modelinden kaçının. Yerelde kaydedin, N taramadan veya X saniyeden sonra toplu yükleyin, görev referans verisini önceden yükleyin ve tarama UI'sını stabil tutun; böylece sonraki tarama her zaman anında kabul edilir.
Taranan değerleri kimlik kanıtı değil, güvensiz girdi olarak ele alın ve derin işleme yapmadan önce yapı ve uzunluk doğrulaması yapın. Kabul anında otomatik olarak denetim verisini yakalayın (kim, ne zaman, nerede, ne ve eylem) ve paylaşılan cihazlarda yerel önbellekleri kısa süreli tutarak güvenliğin ekstra tıklama getirmemesini sağlayın.


