Aplicația offline: când merită să meargă fără internet

O aplicație trebuie să meargă fără internet atunci când oamenii o folosesc exact în locurile unde semnalul lipsește: în subsoluri, în depozite, pe șantiere, la evenimente aglomerate sau pe drum. Dacă ai nevoie de ea doar la birou, pe WiFi, nu merită efortul. Între cele două extreme sunt trei trepte, și de cele mai multe ori prima sau a doua ajung.

Întrebarea de pornire: unde stă omul când o folosește

Nu începe cu tehnologia. Începe cu o zi din viața celui care ține telefonul:

• un tehnician care face o intervenție într-o centrală termică din subsol;
• un agent de vânzări care ia comenzi la clienți din zone fără acoperire bună;
• un ospătar pe o terasă mare, unde WiFi-ul nu ajunge până la ultimele mese;
• un organizator care scanează bilete la intrare, când o mie de telefoane din jur încarcă rețeaua.

Dacă pierderea semnalului îl oprește din lucru sau îl face să noteze pe hârtie și să introducă după, aplicația are nevoie de un mod offline. Dacă semnalul lipsește rar și omul poate aștepta un minut, un mesaj clar („Nu ai conexiune, încearcă din nou”) e de ajuns.

Ghidul Android pentru aplicații „offline-first” pornește de la aceleași situații: conexiune slabă, întreruperi scurte (liftul, tunelul) și dispozitive care au internet doar uneori.

Cele trei trepte ale „offline”

1. Citire fără internet

Aplicația păstrează pe telefon ultimele date văzute: lista de clienți, programul zilei, catalogul de produse. Fără semnal, omul le vede, dar nu poate modifica nimic. E treapta cea mai simplă și rezolvă multe cazuri. Ghidul Android o numește minimul pentru o aplicație offline-first: să poată citi fără rețea.

2. Scriere pusă la coadă

Omul completează un raport sau o comandă, iar aplicația o salvează local și o trimite singură când revine semnalul. Merge bine când ce scrie el nu intră în conflict cu ce scriu alții, de exemplu un raport de intervenție care îi aparține doar lui.

3. Lucru complet offline, cu sincronizare

Mai mulți oameni modifică aceleași date fără internet, iar la revenire totul trebuie împăcat. Aici apare problema conflictelor: dacă doi agenți schimbă aceeași comandă, care variantă câștigă? O regulă des folosită la aplicațiile mobile e „ultima modificare câștigă”, dar nu e potrivită peste tot. La un stoc de produse, de exemplu, două scăderi trebuie adunate, nu înlocuite una cu alta.

Fiecare treaptă cere mai multă muncă decât cea dinainte, mai ales la testare.

Ce trebuie decis înainte, nu după

1. Ce date stau pe telefon. Tot catalogul sau doar ce e alocat omului respectiv? Mai multe date înseamnă mai mult spațiu și sincronizări mai lungi.
2. Ce acțiuni cer neapărat internet. O plată, o rezervare la un loc care se poate ocupa între timp, o verificare de stoc în timp real. Astea rămân „doar online”, iar aplicația spune clar de ce butonul nu merge acum.
3. Cum arată starea. Omul trebuie să vadă dacă e offline și ce n-a plecat încă: „3 rapoarte așteaptă să fie trimise”. Fără asta, închide aplicația convins că a terminat.
4. Ce se întâmplă la conflict. Regula se scrie de la început, pentru fiecare tip de date.
5. Cât timp pot sta datele nesincronizate. O oră, o zi, o săptămână de deplasare? Răspunsul schimbă felul în care se face sincronizarea.

Aplicație din magazin sau aplicație web

Și o aplicație nativă (din App Store sau Google Play), și una web pot merge offline. Pe web, piesa de bază e service worker-ul: un script care stă între aplicație și rețea, poate păstra fișiere în cache și poate răspunde cererilor când nu există conexiune. Merge doar pe HTTPS. Datele mai mari se țin în IndexedDB, baza de date a browserului.

Există însă o capcană pe iPhone. Safari șterge datele salvate de un site (inclusiv cache-ul service worker-ului și IndexedDB) dacă omul nu a folosit site-ul șapte zile în Safari. Aplicațiile web adăugate pe ecranul principal au propriul contor și, în practică, nu sunt afectate. Pentru o echipă care folosește aplicația zilnic nu e o problemă; pentru una folosită o dată pe lună, da. Despre alegerea dintre web și magazin am scris în articolul despre aplicația web sau din magazin.

Ce influențează efortul

Nu putem spune un cost fără să vedem fluxurile, dar știm ce îl mărește: treapta aleasă (a treia e de departe cea mai grea), câte tipuri de date se sincronizează, câți oameni modifică aceleași lucruri și pe câte platforme rulează aplicația. Testarea contează și ea: fiecare flux trebuie încercat și cu semnal, și fără, și cu semnal care vine și pleacă.

Dacă vrei să vedem împreună ce treaptă îți trebuie, vezi serviciile App Dev.