În lumea mobilă, aflată în continuă evoluție, se acordă foarte multă atenție celor mai noi tendințe, tehnologii și potențialului uimitor, dar neexploatat, al celor mai noi dispozitive și descoperiri din domeniul internetului. Și, chiar dacă toate aceste elemente ar trebui, de fapt, să fie în centrul atenției, uneori este bine să ne amintim și să privim mai de aproape elementele inițiale care au făcut ca universul mobile să evolueze la forma pe care o știm astăzi. Una dintre aceste pietre de temelie este capacitatea aplicațiilor mobile de a funcționa offline.
În ceea ce privește utilizarea, modul offline este una dintre cele mai răspândite caracteristici ale aplicațiilor mobile, fiind disponibil în aproape toate aplicațiile cu mai mult de 1 miliard de utilizatori (Gmail, Google Drive, Facebook, Google Photos, Netflix etc.).
Având în vedere necesitatea de a oferi continuitate experienței utilizatorilor în mediul aplicațiilor mobile, precum și nevoia de persistență a datelor în condiții slabe de conexiune, suportul offline este o parte integrantă a modului în care sunt structurate aplicațiile moderne.
Există multe variante arhitecturale pentru suportul offline în cadrul aplicațiilor, acestea variind în funcție de modelul de afacere în care sunt integrate și de fluxul care trebuie optimizat.
Diagrama de bază poate fi sumarizată astfel:
Sursă imagine: https://developer.android.com/topic/architecture/data-layer/offline-first
Nivelul local de stocare a datelor (Local Data Layer)
Este considerat sursa primordială de adevăr. Sursa de adevăr conține întotdeauna date consistente, corecte și actualizate.
Ar trebui utilizat ca sursă exclusivă de adevăr în comunicarea cu straturile superioare ale aplicației.
Nivelul de date de rețea (Network Data Layer)
Reprezintă starea actuală a aplicației.
Straturile superioare ale aplicației nu ar trebui să comunice niciodată direct cu nivelul de date de rețea.
Încercările de a citi din sursa de date de rețea sunt efectuate la intervale de timp crescătoare până când citirea reușește sau alte condiții dictează că ar trebui să se oprească.
Sursă imagine: https://developer.android.com/topic/architecture/data-layer/offline-first
Încercările de citire sunt puse în coadă până când sunt îndeplinite condițiile ideale pentru actualizări (de exemplu, când se stabilește conexiunea la internet).
Sursă imagine: https://developer.android.com/topic/architecture/data-layer/offline-first
Dacă încercarea de a scrie datele prin rețea reușește, sursa locală de date se actualizează. În caz contrar, se aruncă o excepție, lăsând apelantul să răspundă în mod corespunzător.
Se aplică frecvent pentru scenarii de scriere care trebuie să aibă loc online în timp aproape real, de exemplu, un transfer bancar.
Sursă imagine: https://developer.android.com/topic/architecture/data-layer/offline-first
Când există informații care trebuie scrise, acestea sunt introduse într-o coadă. Coada este parcursă în sistem de reîncercare exponențială atunci când aplicația revine online.
Sursă imagine: https://developer.android.com/topic/architecture/data-layer/offline-first
Scrierea datelor se face mai întâi local. Apoi, datele sunt puse în coadă pentru a notifica rețeaua cu prima ocazie când sunt îndeplinite condițiile ideale de scriere.
Sursă imagine: https://developer.android.com/topic/architecture/data-layer/offline-first
În această abordare, sursa locală de date încearcă să replice sursa de date de rețea cât mai bine posibil.
În sincronizarea bazată pe pull, aplicația mobilă accesează rețeaua pentru a citi cele mai recente date disponibile, atunci când este necesar.
Un flux comun pentru această abordare este cel bazat pe navigare, unde aplicația mobilă recuperează datele doar înainte de a trebui să le prezinte utilizatorului.
| Avantaje | Dezavantaje |
|---|---|
| Viteza: Suportul offline oferă o | Complexitate crescută în dezvoltare: |
| experiență mobilă mai fluidă, deoarece | Echipa de dezvoltare trebuie să ia în |
| nu se bazează complet pe datele de pe | considerare un mecanism de cache, |
| server, evitând timpi de așteptare mari | rezolvarea conflictelor și sincronizarea |
| cauzați de o conexiune slabă. | datelor. |
| Eficiență: Elimină nevoia unei | Durata inițială de încărcare: |
| conexiuni stabile la internet pentru a | Stocarea în cache a datelor mari |
| putea continua cu un anumit scenariu. | crește dimensiunea conținutului util, |
| afectând timpii de încărcare și mărind | |
| dimensiunea aplicației pe disc. | |
| Întotdeauna disponibil: Face | Spațiul de stocare: Spațiul de |
| funcțiile esențiale ale aplicației să | stocare pe dispozitiv trebuie optimizat |
| fie disponibile, indiferent de | pentru a nu afecta negativ experiența |
| conectivitatea la internet. | utilizatorului. |
Încă de la apariția lor, principalul factor determinant al aplicațiilor mobile, a fost experiența utilizatorilor. Acest aspect a făcut întotdeauna diferența între succesul unei aplicații și eșecul acesteia. Păstrând acest lucru în minte, industria de IT a lucrat neîncetat la îmbunătățirea și dezvoltarea unei experiențe "perfecte" pentru utilizatorii săi. Dintre multitudinea de tehnici și inovații pe acest subiect, bazat pe longevitatea aceste caracteristici implementate în aplicațiile mobile, putem constata că suportul offline a trecut testul timpului și s-a concretizat ca una dintre pietrele fundamentale în dezvoltarea aplicațiilor și în asigurarea unei experiențe ideale pentru utilizatorii săi.
de Ovidiu Mățan
de Diana Gabor
de Ovidiu Popa
