Offline-first mobil tətbiqlərin hazırlanması o deməkdir ki, istifadəçi zəif və ya tam kəsilmiş internetdə də əsas işi yerinə yetirə bilir: iş sifarişini açır, yoxlama siyahısını tamamlayır, foto əlavə edir, müştəri imzasını alır və nəticəni itirmədən saxlayır. Bu, sadəcə ekranda köhnə məlumatı keşləmək deyil. Məhsul komandası lokal məlumat modelini, yazma növbəsini, server idempotensiyasını, konflikt qaydalarını və istifadəçiyə görünən sinxronizasiya vəziyyətlərini birlikdə layihələndirməlidir.

Sahə ustası lift şaxtasında, kuryer zirzəmidə, inspektor sənaye obyektində və ya satış nümayəndəsi uzaq ərazidə işləyə bilər. Belə hallarda “yenidən cəhd edin” mesajı əməliyyat həlli deyil. Tətbiq görülən işi cihazda etibarlı saxlamalı, daha sonra onu düzgün ardıcıllıqla sistemə çatdırmalı və qeyri-müəyyən halları istifadəçidən gizlətməməlidir.

Offline-first üçün əvvəlcə kritik işi müəyyənləşdirin

İlk məhsul sualı “bütün məlumatları telefona endirəkmi?” deyil. Sual budur: bağlantı olmayanda əməkdaş hansı qərarı və hansı işi mütləq tamamlaya bilməlidir? Məsələn, texniki servis tətbiqində bu, günün təyin edilmiş iş sifarişləri, avadanlıq tarixi, təhlükəsizlik yoxlama siyahısı, hissələr kataloqunun seçilmiş hissəsi və imzalı işin bağlanması ola bilər.

  • Yüklənəcək məlumat: istifadəçinin marşrutu, növbəti 7 günün işləri, aid olduğu obyektlər, zəruri forma versiyaları, roluna uyğun qiymət və ya hissə məlumatı.
  • Yalnız onlayn qalmalı məlumat: canlı dispetçer bölgüsü, real vaxt ehtiyat limiti, ödəniş təsdiqi və hüquqi cəhətdən dərhal yoxlanmalı əməliyyatlar.
  • Yüklənməməli məlumat: digər regionların bütün müştəri bazası, lazımsız sənədlər və cihaz itərsə risk yaradan geniş həcmli həssas məlumat.

Bu sərhəd həm təhlükəsizliyi, həm cihaz yaddaşını, həm də sinxronizasiya yükünü idarə edir. UX dizaynı da bu qərardan asılıdır: istifadəçi məlumatın son yenilənmə vaxtını, dəyişikliklərinin “gözləyir”, “göndərilir”, “göndərildi” və ya “nəzərdən keçirilməlidir” vəziyyətində olduğunu aydın görməlidir. Bu cür axınlar UI/UX və məhsul dizaynı mərhələsində, ekranlar hazır olmamışdan əvvəl formalaşdırılmalıdır.

Lokal baza və server eyni rol oynamır

Etibarlı mobile app offline sync architecture adətən UI-nin birbaşa API-dən oxuması ilə qurulmur. Tətbiq ekranları lokal, tranzaksiyalı verilənlər bazasından oxuyur. Sinxronizasiya xidməti isə arxa planda serverdən dəyişiklikləri alır, lokal bazaya tətbiq edir və gözləyən əməliyyatları göndərir.

Praktik model üç hissədən ibarətdir:

  1. Lokal biznes məlumatı: iş sifarişləri, aktivlər, formalar, cavablar və əlavələr.
  2. Outbox və ya əməliyyat növbəsi: istifadəçi hərəkətlərinin dayanıqlı qeydi. Məsələn, “WO-1842 işini tamamla”, “foto əlavə et”, “imzanı yüklə”.
  3. Sinxronizasiya metadatası: lokal dəyişiklik versiyası, server versiyası, son uğurlu sinxronizasiya kursori, cəhd sayı, xəta kodu və konflikt vəziyyəti.

İstifadəçi “Tamamlandı” düyməsini basanda tətbiq əvvəlcə lokal bazada işin vəziyyətini dəyişir və eyni tranzaksiyada outbox-a əməliyyat əlavə edir. Ekran dərhal yeni vəziyyəti göstərir; şəbəkə sonradan mövcud olarsa, fon işçisi növbəni göndərir. Lokal dəyişiklik və növbə ayrıca yazılarsa, tətbiq qəfil bağlananda biri yazılıb digərinin itməsi riski yaranır.

Növbəyə alınan yazılar: retry deyil, audit olunan əməliyyatlar

Növbədə hər sətir təkcə HTTP sorğusu olmamalıdır. Onun biznes mənası və izlənə bilən identifikatoru olmalıdır. Minimum sahələrə əməliyyat identifikatoru, obyekt identifikatoru, əməliyyat növü, payload versiyası, yaradılma vaxtı, asılılıqlar, cəhd sayı və vəziyyət daxildir.

Məsələn, inspektor fotoşəkilləri əlavə edib yekun hesabatı təsdiqləyirsə, “hesabatı tamamla” əməliyyatı foto yüklənməsindən asılı ola bilər. Sistem əvvəl yekun statusu göndərib, sonra fotonu itirməməlidir. Böyük media faylları üçün ayrıca davam etdirilə bilən yükləmə mexanizmi, yoxlama cəmi və yenidən cəhd siyasəti lazımdır.

Retry siyasəti şəbəkə dəyişən kimi yüzlərlə sorğunu eyni anda göndərməməlidir. Bağlantı, autentifikasiya, serverin müvəqqəti xətası və daimi biznes xətası fərqləndirilməlidir. Keçici xətalarda artan fasilə (exponential backoff) və təsadüfi gecikmə tətbiq edilir. Məsələn, “hissə kodu artıq aktiv deyil” cavabı avtomatik yenidən cəhd ediləcək xəta yox, istifadəçiyə və ya dispetçerə yönləndiriləcək istisnadır.

İdempotensiya dublların qarşısını alır

Mobil cihaz sorğunu göndərə, cavabı almadan tunelə girə və sonra eyni əməliyyatı yenidən göndərə bilər. Server hər cəhdi yeni iş kimi qəbul edərsə, iki servis hesabatı, iki stok silinməsi və ya iki ödəniş qeydi yarana bilər. Buna görə hər yazma əməliyyəti sabit, unikal idempotensiya açarı ilə göndərilməli; server isə həmin açarı, istifadəçi və payload barmaq izi ilə birlikdə yadda saxlamalıdır.

Eyni açar və eyni payload təkrar gələndə server əvvəlki nəticəni qaytarmalıdır. Eyni açarın fərqli payload-la istifadəsi isə xəta olmalıdır. Bu qayda yalnız mobil tətbiqdə deyil, API və inzibati sistemdə də həyata keçirilməlidir. POLADO-da mobil tətbiqlərin hazırlanması işini backend müqavilələri, tətbiq vəziyyətləri və əməliyyat monitorinqi ilə birlikdə planlamaq məhz buna görə vacibdir.

Konflikt həlli biznes qaydasıdır

İki cihaz eyni iş sifarişini offline redaktə edə bilər; dispetçer veb paneldən prioriteti dəyişə bilər; texnik isə köhnə versiyadakı checklisti tamamlayar. “Son yazan qalibdir” bəzən məqbul olsa da, universial mobile conflict resolution strategy deyil.

  • Birləşdirilə bilən sahələr: qeydlər, etiketlər və bir-birindən asılı olmayan cavablar sahə-sahə birləşdirilə bilər.
  • Server səlahiyyətlidir: təhlükəsizlik bloklaması, işin ləğvi, istifadəçi icazələri və cari ehtiyat qalığı lokal dəyişiklikdən üstün olmalıdır.
  • İnsan qərarı tələb olunur: iki fərqli sayğac göstəricisi, eyni işə zidd “tamamlandı” və “giriş mümkün olmadı” nəticələri, yaxud müqavilə üçün kritik məlumat.

Hər sinxronizasiya edilən obyekt üçün server versiyası və ya dəyişiklik tokeni saxlayın. Müştəri yeniləməni “mən bunu versiya 42 əsasında etdim” məlumatı ilə göndərsin. Server versiya 43-dədirsə, kor-koranə yazmaq əvəzinə konflikt cavabı və ya deterministik birləşdirmə qaytarır. Konflikt ekranı istifadəçiyə nəyi seçdiyini, hansı məlumatın serverdən gəldiyini və hansı məlumatın qorunacağını başa salmalıdır.

Cihazda məlumatın təhlükəsizliyi

Offline iş daha çox məlumatın cihazda qalması deməkdir. Rol əsaslı yükləmə, qısa sessiya müddəti, cihazdan çıxış zamanı lokal həssas məlumatın təmizlənməsi, platformanın təhlükəsiz açar anbarından istifadə və backup qaydalarının yoxlanması məhsulun tələbləri olmalıdır. Tokenləri, açarları və həssas qeydləri loglarda və ya paylaşılmış fayl qovluqlarında saxlamayın. Cihaz oğurlandıqda və əməkdaşın rolu dəyişdikdə məlumatın ləğv edilməsi və növbənin necə davranacağı da əvvəlcədən müəyyən edilməlidir.

Buraxılışdan əvvəl test ediləcək ssenarilər

  • Formanın ortasında airplane mode; tətbiqi bağlayıb yenidən açmaq.
  • Sorğu serverə çatdıqdan sonra cavab itməsi və eyni əməliyyatın təkrar göndərilməsi.
  • Şəbəkənin Wi-Fi, zəif mobil internet və tam kəsinti arasında dəfələrlə dəyişməsi.
  • İki cihazın eyni iş sifarişini offline dəyişdirməsi.
  • Sinxronizasiya zamanı tokenin bitməsi, istifadəçinin çıxış etməsi və rolunun ləğv olunması.
  • Yarımçıq foto yükləməsi, yaddaşın dolması, köhnə tətbiq versiyası və server sxeminin yenilənməsi.
  • 10, 100 və 1,000 gözləyən əməliyyatla növbənin ardıcıllığı, sürəti və müşahidə oluna bilməsi.

Bu testlər yalnız QA tapşırığı deyil. Məhsul, mobil, backend və əməliyyat komandası birlikdə qəbul meyarlarını yazmalıdır. Buraxılışdan sonra isə uğursuz sinxronizasiya faizi, növbənin yaşı, konflikt sayı, təkrar cəhdlər və istifadəçinin əl ilə müdaxilə etdiyi hallar izlənməlidir. Davamlı monitorinq, təhlükəsiz yeniləmələr və istehsalat problemlərinin araşdırılması üçün texniki dəstək və konsaltinq planı da məhsulun bir hissəsidir.

Nəticə: offline rejim funksiyadır, keş isə yalnız vasitədir

Etibarlı offline-first tətbiq işçilərə internetin ideal olmasını gözləmədən işi tamamlamağa imkan verir. Bunun üçün seçilmiş məlumat dəsti, lokal mənbədən işləyən ekranlar, davamlı yazma növbəsi, idempotent API-lər, açıq konflikt qaydaları, cihaz təhlükəsizliyi və şəbəkə nasazlıqlarına qarşı test tələb olunur. Sahə xidməti, logistika və inspeksiya məhsulunuz üçün bu qərarları kodlaşdırmadan əvvəl dəqiqləşdirmək istəyirsinizsə, POLADO ilə mobil arxitektura və tətbiq axınları üzrə konsultasiya planlaşdırın.