Offline-first mobil tətbiq hazırlanması o deməkdir ki, istifadəçi əsas işini şəbəkə cavabını gözləmədən cihazda yerinə yetirə bilir; əlaqə bərpa olunanda məlumat təhlükəsiz şəkildə serverlə uzlaşdırılır. Bu yanaşma mütləq hər mobil məhsul üçün lazım deyil. Lakin texnikin zirzəmidə akt doldurduğu, sürücünün marşrut boyunca təhvil təsdiqi aldığı və ya satış əməkdaşının müştəri ziyarətini qeydə aldığı tətbiqdə əlaqə yalnız “əlavə rahatlıq” deyil, əməliyyat riskidir.
Yoxlama, logistika, avtomobil, pərakəndə satış və field service mobile app development layihələrində ekranların dizaynı başlanğıc nöqtəsidir. Həqiqi məhsul qərarları isə belə suallardadır: hansı məlumat cihazda saxlanacaq, istifadəçi iki dəfə eyni əməliyyatı etsə nə baş verəcək, iki əməkdaş eyni qeydi dəyişsə hansı versiya qalacaq və istifadəçi göndərdiyi işin həqiqətən serverə çatdığını necə anlayacaq?
Offline-first yanaşma nə vaxt vacibdir?
Aşağıdakı hallarda tətbiqi “online işləyər, internet yoxdursa xəta göstərər” məntiqi ilə qurmaq adətən zəif təcrübə yaradır:
- İnspeksiya və audit: forma, yoxlama siyahısı, foto, imza və ölçmələr obyektin daxilində toplanır.
- Çatdırılma və logistika: təhvil statusu, barkod skanı, imza, foto-sübut və geolokasiya yolda qeydə alınır.
- Servis və avtomobil komandaları: ustanın iş sifarişi, istifadə olunan hissə və görülən iş sahədə tamamlanır.
- Səyyar satış: müştəri qeydləri, sifariş və məhsul kataloqu ziyarət zamanı açılmalıdır.
- Tədbir və böyük obyektlər: sıxlıq, beton konstruksiya və ya lokal şəbəkə səbəbindən bağlantı qeyri-sabit ola bilər.
Offline rejim təkcə “məlumatı keşləmək” deyil. Əsas məqsəd iş axınının davam etməsidir: əməkdaş yeni akt yarada, şəkil əlavə edə, statusu dəyişə və nəticəni göndərilmə növbəsinə qoya bilməlidir. Məsələn, avtomobil yönümlü mobil məhsullarda istifadəçi təcrübəsi və cihaz imkanlarının prosesə uyğunlaşdırılması ayrıca məhsul işidir; bunun üçün Car City layihəsinə və mobil tətbiqlərin hazırlanması xidmətinə baxa bilərsiniz.
Offline mobil tətbiq arxitekturasının əsas hissələri
1. Lokal məlumat bazası: nə saxlanır, nə saxlanmır?
Lokal yaddaşın sərhədi əvvəlcədən müəyyən edilməlidir. Sahə işçisi üçün lazım olan cari tapşırıqlar, əlaqəli müştəri məlumatı, forma şablonları, məhsul siyahısının uyğun hissəsi və hələ göndərilməmiş əməliyyatlar cihazda olmalıdır. Bütün korporativ verilənlər bazasını telefona köçürmək isə həm təhlükəsizlik, həm də performans baxımından düzgün deyil.
Yaxşı modeldə hər lokal obyektin sabit identifikatoru, son dəyişmə vaxtı, server versiyası və sinxronizasiya vəziyyəti olur. Məsələn, iş sifarişi draft, queued, syncing, synced və ya needs review vəziyyətlərindən birində ola bilər. Fayllar üçün ayrıca siyasət lazımdır: böyük foto və videoları dərhal yükləməyə çalışmaq əvəzinə, metadata və fayl növbəsini ayrıca idarə etmək daha dayanıqlıdır.
2. Növbəyə alınan əməliyyatlar
İstifadəçi “Tamamla” düyməsini basanda tətbiq əvvəlcə lokal bazaya əməliyyatı yazmalı, sonra onu göndərilmə növbəsinə əlavə etməlidir. Şəbəkə varsa sinxronizasiya başlayır; yoxdursa əməkdaş işini davam etdirir. Bu yanaşma ekranın server cavabından asılılığını azaldır.
Hər növbə elementi əməliyyat növünü, obyekt identifikatorunu, yaradılma vaxtını, təkrar cəhd sayını və mümkün olduqda unikal idempotency key saxlamalıdır. Bu açar eyni sorğunun bağlantı qırıldığı üçün təkrar göndərilməsi zamanı serverin iki ayrı təhvil və ya iki eyni sifariş yaratmasının qarşısını alır. Sorğu uğurlu cavab almadan kəsilərsə, tətbiq “əməliyyat uğursuz oldu” nəticəsinə tələsməməlidir: serverin əməliyyatı qəbul edib-etmədiyini təhlükəsiz yoxlamaq lazımdır.
3. Delta sinxronizasiya və server həqiqət mənbəyi kimi
İlkin yükləmədən sonra tətbiqin hər dəfə bütün kataloqu endirməsi baha və yavaşdır. Daha səmərəli mobile app data synchronization modeli son uğurlu sinxronizasiyadan sonra dəyişən qeydləri — delta məlumatı — alır. Server dəyişiklik nişanı, versiya nömrəsi və ya ardıcıl jurnal təqdim edə bilər. Tətbiq əvvəlcə öz növbəsindəki yazıları göndərir, sonra uzaq dəyişiklikləri çəkir və lokal görünüşü yeniləyir.
Server biznes qaydalarının son tətbiq olunduğu yerdir. Məsələn, artıq bağlanmış iş sifarişinə hissə əlavə etmək qadağandırsa, tətbiq bunu lokal olaraq da göstərə bilər, amma server yenə qaydanı yoxlamalıdır. Offline imkanlar server validasiyasını aradan qaldırmır; sadəcə validasiya nəticəsinin sonradan gələcəyini nəzərə alır.
Sinxronizasiya konfliktlərini gizlətməyin
Konflikt eyni obyekt cihazda dəyişdirildikdən sonra serverdə də dəyişiklik olduqda yaranır. “Son yazan qalib gəlir” qaydası bəzi sahələr üçün uyğun ola bilər: məsələn, istifadəçinin şəxsi görünüş seçimi. Lakin mühəndisin qeyd etdiyi sayğac göstəricisi, anbar qalıqları və ya təhlükəsizlik yoxlaması üçün bu yanaşma məlumat itkisinə səbəb ola bilər.
Konflikt strategiyasını məlumat növünə görə seçin:
- Sahə səviyyəsində birləşdirmə: fərqli sahələr dəyişibsə, onları avtomatik birləşdirin.
- Əlavə olunan qeydlər: şərhlər, foto və fəaliyyət jurnalı əsas obyektin üzərinə yazılmamalı, ayrıca element kimi saxlanmalıdır.
- Server qaydası üstün: status keçidləri və stok kimi həssas məlumat server tərəfindən həll edilir.
- İnsan qərarı: iki zidd ölçmə və ya qiymət olduqda tətbiq fərqi göstərir, istifadəçidən və ya menecerdən seçim istəyir.
İstifadəçiyə sadəcə “Sync error” göstərmək kifayət deyil. Hansı qeyd, hansı sahə və hansı səbəb problem yaratdığını aydın izah edin; lokal dəyişiklik itirilməsin. Lazım gəldikdə istifadəçi öz versiyasını ixrac edə, yenidən göndərə və ya rəhbərin qərarını gözləyə bilməlidir.
Kamera, lokasiya və bildiriş icazələri məhsul axınının hissəsidir
Foto-sübut, barkod, imza, xəritə və status bildirişləri sahə tətbiqlərində adi görünür, amma icazələr başlanğıcda kütləvi şəkildə istənməməlidir. Kamera icazəsini istifadəçi “Foto əlavə et” seçəndə, lokasiyanı “Gəlişi təsdiqlə” funksiyasında istəyin. İcazə rədd edilərsə, prosesin işlək alternativi olsun: foto yerinə qeyd, avtomatik koordinat əvəzinə ünvan seçimi və ya menecer yoxlaması.
Lokasiya üçün dəqiqlik və vaxt sərhədi biznes ehtiyacı ilə uyğun olmalıdır. Bir təhvilin yerini təsdiqləmək üçün davamlı arxa-plan izləmə tələb olunmaya bilər. Əksinə, real vaxt marşrut izləmə məhsulun əsas funksiyasıdırsa, istifadəçiyə bunun səbəbi, aktiv olduğu müddət və batareya təsiri açıq bildirilməlidir. Android-də kamera, mikrofon və lokasiya kimi həssas icazələr iş vaxtında soruşulmalı, rədd cavabları ayrıca test edilməlidir; fon lokasiyası isə xüsusi əsaslandırma tələb edir.
Push notifications sinxronizasiya mexanizmi deyil. Bildiriş yeni tapşırıq, dəyişmiş prioritet və ya istifadəçi diqqəti tələb edən konflikt barədə xəbər verə bilər. Lakin tətbiq açıldıqda və ya şəbəkə bərpa olunanda yenə serverdən dəyişiklikləri etibarlı şəkildə almalıdır.
Arxa-plan sinxronizasiyası: zəmanət deyil, planlı təkrar cəhddir
Mobil əməliyyat sistemləri batareya və məxfilik üçün fon işlərini məhdudlaşdırır. Buna görə “internet gələn kimi proqram arxa planda dərhal hər şeyi göndərəcək” vədi texniki zəmanət kimi verilməməlidir. Android-də davamlı işlər üçün WorkManager şəbəkə, batareya və enerji kimi şərtlərlə planlaşdırıla bilər. iOS-da sistemin idarə etdiyi background URLSession ötürmələri fayl yükləmə və endirmələr üçün uyğundur, lakin istifadəçi tətbiqi məcburi bağladıqda fon ötürmələri ləğv oluna bilər.
Praktik yanaşma üç qatlıdır: tətbiq açıqkən dərhal sinxronizasiya; uyğun şərtlərdə fon təkrarı; istifadəçi növbəti dəfə tətbiqə qayıdanda qalıq əməliyyatların yoxlanması. Növbə davamlı yaddaşda qalmalı, eksponensial geriçəkmə tətbiq olunmalı və autentifikasiya xətası, validasiya xətası, konflikt və şəbəkə xətası bir-birindən fərqləndirilməlidir.
İstifadəçi sinxronizasiya vəziyyətini görməlidir
Offline-first arxitektura istifadəçiyə görünməz ola bilər, amma onun nəticəsi görünməlidir. Ekranda son uğurlu sinxronizasiya vaxtı, gözləyən dəyişikliklərin sayı, göndəriş xətası və “indi yenilə” əməliyyatı olmalıdır. Kritik iş tamamlananda “Yadda saxlandı — göndərilmə gözləyir” mesajı “Göndərildi” mesajından fərqlənməlidir.
Bu detal xüsusilə hüquqi, maliyyə və ya təhlükəsizlik əhəmiyyətli işlərdə vacibdir. İstifadəçi foto və imzanın sadəcə telefonunda qaldığını, yoxsa mərkəzi sistemə çatdığını bilməlidir. Dizayn sistemində bu vəziyyətləri əvvəlcədən qurmaq üçün UI/UX və məhsul dizaynı xidmətindən, arxa plan monitorinqi və buraxılış prosesləri üçün isə texniki dəstək və konsaltinq xidmətindən yararlanmaq mümkündür.
Real cihazlar üzrə əməliyyat testi siyahısı
- Wi-Fi-dan mobil şəbəkəyə və əksinə keçid zamanı forma, foto və növbənin davranışını yoxlayın.
- Əməliyyat göndərilərkən şəbəkəni kəsin; tətbiqi bağlayıb yenidən açın; eyni əməliyyatın dublikat olmadığını təsdiqləyin.
- Uzun müddət offline qalan, köhnə məlumatla işləyən cihazda konflikt ssenarisini yoxlayın.
- Kamera və lokasiya icazələrini rədd, yalnız bir dəfə icazə və sonradan sistem parametrlərindən ləğv edilmiş hallarda test edin.
- Az yaddaş, aşağı batareya, zəif şəbəkə və böyük media faylları ilə sınaq aparın.
- Fərqli OS versiyaları, istehsalçılar və real sahə marşrutları üzrə pilot keçirin.
- Server jurnallarında növbə identifikatoru, istifadəçi, cihaz, nəticə və konflikt səbəbini izlənə bilən edin.
Nəticə: offline-first qərarı funksional tələbdən əvvəl məhsul qərarıdır
Etibarlı sahə tətbiqi internet yox olduqda “dayanmayan” tətbiqdir, lakin bunun üçün lokal məlumat modeli, idempotent əməliyyatlar, konflikt qaydaları, mərhələli icazələr və müşahidə edilən sinxronizasiya birlikdə hazırlanmalıdır. Bu məsələləri dizayn təsdiqlənməmişdən əvvəl müəyyənləşdirmək sonradan bahalı yenidənqurmanın qarşısını alır.
Komandanız üçün inspeksiya, çatdırılma, servis və ya səyyar satış tətbiqi planlaşdırırsınızsa, POLADO ilə konsultasiyada sahə axınlarını, offline sərhədlərini, inteqrasiyaları və ilk buraxılışın texniki risklərini birlikdə xəritələndirə bilərik.