Offline webalkalmazás: terepmunka térerő nélkül

Egy webalkalmazás ott is működhet, ahol nincs térerő – pincében, építkezésen, raktárban vagy vidéken. A feltétel az, hogy az offline módot a munkafolyamat részeként tervezzék meg, ne pedig közvetlenül az indulás előtt toldják hozzá. Technikailag egy service worker alkotja, amely az alkalmazást az eszközön tárolja, egy helyi adatbázis a böngészőben a folyamatban lévő rekordokhoz, valamint a módosítások kimenő sora, amelyet az alkalmazás a kapcsolat helyreállása után elküld a szervernek.

A siker azonban a szabályokon múlik: milyen adatokat visz magával a terepen dolgozó munkatárs, mit tehet meg szerver nélkül, meddig maradhatnak az el nem küldött rekordok a telefonon, és mi történik, ha ugyanazt a rekordot közben az iroda módosítja. A cikk azoknak a cégtulajdonosoknak és vezetőknek szól, akik szerviztechnikusok, helyszíni felmérések, leltárak vagy felülvizsgálatok számára terveznek alkalmazást, és azt mérlegelik, hogyan működjön egy offline webalkalmazás.

Példa: kazánfelülvizsgálatok térerő nélküli pincékben

Szemléltető példa, a cég kitalált. Egy szervizcég gázkazánok felülvizsgálatát végzi, gyakran kazánházakban és pincékben, ahol nincs mobiltérerő. A technikus ma papírra jegyzi fel a megállapításokat, este begépeli őket a rendszerbe, a fotókat pedig egy privát csevegőalkalmazáson küldi el.

Célállapot: reggel a céges Wi-Fi-n az alkalmazás letölti a napi beosztást, a címeket, a berendezések előzményeit és a jegyzőkönyv-űrlapokat. A helyszínen a technikus kitölti a jegyzőkönyvet, csatolja a fotókat, az ügyfél pedig a kijelzőn írja alá. A rekord „Küldésre vár” állapottal mentődik a telefonon. Amikor visszatér a térerő, az alkalmazás elküldi, a szerver visszaigazolja a fogadást, és az állapot „Elküldve” lesz. Ha az iroda közben lemondta a munkát, a technikus feloldandó ütközést lát, nem pedig a munkája csendes felülírását.

Mit kell kezelnie az offline módnak, és mit nem

Az első döntés nem technikai. Minden feladatnál határozza meg, hogy teljesen offline, a szerver által megerősítendő tervezetként vagy csak online végezhető-e. Mindent, aminek egyetlen hiteles állapotra van szüksége – számlák sorszámozása, készlet, árak –, hagyjon a szerveren.

Feladat	Offline	Miért
A napi beosztás és a berendezés előzményeinek megtekintése	Igen, előre letöltött adatokból	A technikusnak térerő nélkül is szüksége van a háttérinformációkra
Jegyzőkönyv kitöltése, fotók és aláírás csatolása	Igen, az alkalmazás helyben menti, és később elküldi	Az offline mód bevezetésének fő oka
Új munka rögzítése a helyszínen	Igen, tervezetként, ideiglenes azonosítóval	A munkaszámot csak a szerver osztja ki
Számla kiállítása vagy áru foglalása	Nem, csak az alapadatok előkészítése	A sorszámokat és a készletet a szerver kezeli
Az árlista vagy a jogosultságok módosítása	Nem	Ezeknek az adatoknak egyetlen hiteles forrása legyen

A táblázat minden „igen” válasza többletfejlesztést és -tesztelést jelent. Az offline módba ezért csak azok a feladatok tartozzanak, amelyeket valóban térerő nélkül végeznek.

Technikai építőelemek és korlátaik

Service worker és a tárolt alkalmazás

A service worker egy külön szálon futó szkript. Telepítéskor el tudja menteni az alkalmazás oldalait, stílusait, szkriptjeit és képeit egy helyi gyorsítótárba, majd elfogja az alkalmazás kéréseit – vagy először a gyorsítótárból, vagy először a hálózatról, a gyorsítótárat tartalékként használva. Az MDN offline és háttérműködésről szóló útmutatója szerint a megfelelő stratégia az adott alkalmazástól függ. Terepi alkalmazásnál azt javasoljuk, hogy magát az alkalmazásfelületet egyértelmű verziózással a gyorsítótárból szolgálják ki, a munkák adatait pedig egy helyi adatbázisban tárolják, amelyet az alkalmazás minden kapcsolódáskor frissít a szerverről.

Helyi adatbázis: IndexedDB, nem localStorage

A localStorage csak szöveges kulcs–érték párokat tárol, és az MDN tárhelykvótákról szóló dokumentációja szerint eredetenként (origin) 5 MiB-ra korlátozott. Fotókhoz és a módosítások sorához ez nem elég. Nagyobb strukturált adatokhoz az IndexedDB, fájlokhoz az eredet privát fájlrendszere (OPFS) való.

Kvóták és a tárhely törlése

Az adatok alapértelmezés szerint „best-effort” módban, vagyis tartóssági garancia nélkül tárolódnak: addig maradnak meg, amíg az eredet a kvóta alatt van, az eszközön van elég hely, és a felhasználó nem törli őket. Ha fogy a hely, a böngésző a legrégebben használt eredetek adatait törli – mindig az eredet összes adatát egyszerre, sosem csak egy részét (MDN).

A kvóták magasak, de nem jelentenek garanciát. A Chromium-alapú böngészők egy eredetnek a teljes lemezkapacitás akár 60%-át engedik, a Firefox best-effort módban a lemez 10%-a és a 10 GiB közül a kisebbet, a Safari a 17-es verziótól nagyjából a lemez 60%-át (MDN). A számítás azonban a teljes kapacitásból indul ki, nem a szabad helyből, és a WebKit tárolási szabályokról szóló blogbejegyzése szerint felső határról van szó, garancia nélkül. Az alkalmazásnak ezért kezelnie kell a QuotaExceededError hibát.

A Safari emellett bekapcsolt, webhelyek közötti követés elleni védelem esetén törli a szkript által létrehozott adatokat, ha a felhasználó a böngészőhasználat utolsó hét napjában nem lépett interakcióba a webhellyel. A helyhiány miatti törléstől a tartós (perzisztens) tárhely véd, amelyet az alkalmazás a navigator.storage.persist() hívással kér. A Firefox megkérdezi a felhasználót, a Safari és a legtöbb Chromium-alapú böngésző az interakciók előzményei alapján automatikusan dönt, a WebKit pedig azt is figyelembe veszi, hogy a webhelyet a kezdőképernyőről indították-e. A Chrome csapatának kutatása szerint, amelyre az MDN hivatkozik, a böngészők a rendszeresen látogatott webhelyek adatait nagyon ritkán törlik. A telefont mégis ideiglenes pufferként kezelje, ne olyan helyként, ahol a céges adatoknak maradniuk kell.

Kapcsolati állapot és háttérszinkronizálás

A navigator.onLine tulajdonság nem megbízható: a helyi hálózathoz való csatlakozás általában online állapotnak számít akkor is, ha a hálózatnak nincs internet-hozzáférése. Az MDN ezért azt tanácsolja, hogy ennek alapján ne kapcsoljanak ki funkciókat, csak jelezzék, ha a felhasználó esetleg offline. Csak azt a rekordot tekintse elküldöttnek, amelynek fogadását a szerver visszaigazolta.

A Background Synchronization API lehetővé teszi, hogy az alkalmazás a küldést elhalassza és a service workerre bízza, amíg stabil kapcsolat nem lesz. Az MDN azonban korlátozottan elérhető funkcióként jelöli, és csak biztonságos környezetben (HTTPS) működik. A kérést csak megnyitott alkalmazás mellett lehet regisztrálni, a böngésző csak korlátozott számban próbálkozhat újra, a túl hosszú műveletet pedig leállítja, és a következő kísérlet elölről kezdődik (MDN). A háttérszinkronizálás tehát csak ráadás. Az alap a küldés legyen az alkalmazás megnyitásakor, a kapcsolat helyreállása után és egy „Küldés most” gombbal, kis, biztonságosan megismételhető kötegekben.

Bevezetés hét lépésben

1. Térképezze fel a terepmunkát. Derítse ki, hol és mennyi ideig nincs térereje a munkatársaknak, milyen eszközöket használnak (céges vagy saját, iPhone vagy Android), és naponta hány rekord és fotó keletkezik.
2. Határozza meg az offline terjedelmet. Minden feladatnál a táblázat alapján döntsön: teljesen offline, megerősítendő tervezet vagy csak online.
3. Készítse elő az adatmodellt. Minden rekord már az eszközön egyedi azonosítót (például UUID-t), verziót és szinkronizálási állapotot kap. A szervernek fel kell ismernie az ismételt beküldést, és nem hozhat létre duplikátumot.
4. Építse ki a kimenő sort. A módosítás először a helyi adatbázisba és a sorba kerül, és csak azután indul el – keletkezési sorrendben, kötegekben és újrapróbálkozással. A fotók feltöltése csak akkor kezdődik, amikor a szerver már fogadta magát a rekordot.
5. Gondoskodjon a tárhelyről. Kérjen tartós tárhelyet, kövesse a használati becslést a navigator.storage.estimate() segítségével, mentés előtt kicsinyítse a fotókat arra a felbontásra, amelyre a folyamatnak valóban szüksége van, és a szerver visszaigazolása után törölje a helyi másolatokat.
6. Mutassa a szinkronizálás állapotát. Minden rekordnál látszódjon, hogy küldésre vár, elküldték, vagy ütközés van vele. Kijelentkezés előtt az alkalmazásnak figyelmeztetnie kell, a lejárt bejelentkezés pedig nem állíthatja le a munkát, és nem törölheti a sort.
7. Teszteljen valós körülmények között. Próbálja ki a repülőgép üzemmódot, az internet nélküli Wi-Fi-t, az alkalmazás bezárását küldés közben, a megtelt tárhelyet és egy új verzió telepítését el nem küldött adatokkal – iPhone-on és Androidon is.

Ütközések: ki nyer, ha egy rekord két helyen változott

Ütközés akkor keletkezik, amikor a technikus offline szerkeszt egy rekordot, és közben valaki más módosítja a szerveren. Az „utolsó írás nyer” szabályt a legkönnyebb leprogramozni, de csendben elveti az egyikük munkáját. A szabályokat ezért előre, adattípusonként határozza meg.

Helyzet	Javasolt szabály	Kompromisszum
A technikus kiegészíti a jegyzőkönyvet, az iroda javítja az ügyfél elérhetőségét	Mezőnkénti összefésülés, minden mezőnek megvan a gazdája	A mezők gazdáját pontosan meg kell határozni
Az iroda lemondta a munkát, a technikus közben elvégezte	Nem felülírni, hanem ütközésként megjelölni a diszpécser döntéséhez	Valakinek rendszeresen kezelnie kell az ütközéseket
Két technikus módosította ugyanazt a rekordot	Az aktuális verzióra épülő módosítást elfogadni, a másikat ütközésként visszaküldeni	A második technikusnak ellenőriznie kell a módosítását
Fotók, jegyzetek és aláírások	Csak hozzáadni, soha nem felülírni	Több tárolt adat, de semmi sem vész el
Árlisták és törzsadatok	A szerver az egyetlen forrás, az eszköz csak olvassa őket	Offline az eszközön régebbi verzió lehet

Ütközés esetén mindkét verziót őrizze meg a szerzővel és az időponttal együtt. Különben utólag nem lehet eldönteni a vitát arról, hogy a technikus mit rögzített valójában a helyszínen.

Webalkalmazás (PWA) vagy natív alkalmazás?

A webalkalmazásnak egyetlen kódja van minden eszközre, linkkel terjeszthető, az új verziót pedig alkalmazásboltok nélkül telepítheti a szerverre. Ugyanakkor elfogadja a böngésző szabályait: best-effort tárhelyet, ha a böngésző nem ad tartós módot, korlátozott háttérszinkronizálást és egy service workert, amelyet a böngésző leállít, amikor jónak látja. A natív alkalmazás a böngészőn kívül, saját tárhelyen tárolhatja az adatokat, így ezek a kvóták és törlési szabályok nem vonatkoznak rá. Viszont iOS-re és Androidra is fejleszteni kell, a terjesztés pedig alkalmazásboltokon vagy céges eszközkezelésen keresztül történik.

• A webalkalmazás általában elegendő, ha űrlapokról, ellenőrzőlistákról, fotókról és aláírásokról van szó, és az eszközök naponta legalább egyszer csatlakoznak.
• Natív alkalmazást akkor érdemes fontolóra venni, ha a munkatársak egész napokat dolgoznak kapcsolat nélkül, nagy adatmennyiségre van szükségük az eszközön, például térképekre vagy videókra, vagy ha az adatokat a háttérben, az alkalmazás megnyitása nélkül kell elküldeni.

A fejlesztés előtt döntsön. Ha a projekt közepén vált megközelítést, át kell dolgozni a tárolást és a szinkronizálást, vagyis az offline mód magját.

Gyakori hibák

• Offline mód csak az indulás után. A helyi azonosítók és verziók nélküli adatmodellt utólag nehéz átdolgozni.
• A navigator.onLine tulajdonságra hagyatkozás. Az internet nélküli Wi-Fi kapcsolatnak látszik, és a rekordok elakadnak.
• Adatok a localStorage-ban. Csak szöveg és kis kapacitás, fotókhoz és a sorhoz alkalmatlan.
• A telefon mint egyetlen másolat. Az el nem küldött rekordok napokig az eszközön vannak, pedig a böngésző egyszerre törölheti a webhely összes adatát.
• Láthatatlan szinkronizálási állapot. A technikus nem tudja, mi ment el, és kijelentkezik vagy törli a böngésző adatait.
• Új verzió migráció nélkül. A frissítés nem tudja beolvasni az el nem küldött sort, vagy törli azt.
• Privát böngészés. Az adatok a privát munkamenet végén általában törlődnek, ezért terepi munkához ne használja.

Ellenőrzőlista az élesítés előtt

• A feladattáblázatot (offline, tervezet, csak online) a terepi csapat és az iroda is jóváhagyta.
• Minden rekordnak van helyi egyedi azonosítója, verziója és szinkronizálási állapota.
• A szerver felismeri az ismételt beküldést, és nem hoz létre duplikátumot.
• A rekordok és a fotók IndexedDB-ben vagy OPFS-ben vannak, nem a localStorage-ban.
• Az alkalmazás tartós tárhelyet kér, figyeli annak használatát, és kezeli a megtelt tárhelyet.
• A sikeres küldést a szerver igazolja vissza, nem a böngésző kapcsolati állapota.
• A szinkronizálás a Background Synchronization API nélkül is működik.
• Az ütközési szabályok le vannak írva, tesztelve vannak, és valaki felel az ütközések kezeléséért.
• Sem a kijelentkezés, sem a lejárt bejelentkezés nem törli figyelmeztetés nélkül az el nem küldött adatokat.
• Az eszközökön csak az aktuális munkákhoz szükséges adatok vannak, és a telefonokon be van kapcsolva a képernyőzár.

Gyakran ismételt kérdések

Működik az offline webalkalmazás iPhone-on is?

Igen. A Safari a 17-es verziótól teljes mértékben támogatja a Storage API-t, és a kezdőképernyőhöz adott webalkalmazásra ugyanazok a kvóták vonatkoznak, mint a böngészőben. A WebKit a tartós tárhely iránti kérésnél figyelembe veszi, hogy a webhelyet kezdőképernyős alkalmazásként nyitották-e meg (WebKit). Ezért azt javasoljuk, hogy adja hozzá az alkalmazást a kezdőképernyőhöz, és naponta legalább egyszer szinkronizáljon. Az EU-ban az iOS 17.4-es verziójától más motorral működő böngészők is futhatnak, amelyek saját tárolási szabályokat alkalmaznak (MDN).

Mennyi adatot tárolhat az alkalmazás a telefonon?

Ez a böngészőtől és az eszköztől függ. A felső határok magasak, de a teljes lemezkapacitásból számolódnak, nem a szabad helyből, így a tényleges korlát egy megtelt telefon is lehet. Az alkalmazásnak figyelnie kell a használati becslést, kicsinyítenie kell a fotókat, és a szerver visszaigazolása után törölnie kell a helyi másolatokat.

Mi történik, ha a technikus a küldés előtt bezárja az alkalmazást?

Az IndexedDB-ben mentett rekordok az eszközön maradnak, és az alkalmazás a következő megnyitáskor elküldi őket. Ha a böngésző támogatja a Background Synchronization API-t, és a kérést megnyitott alkalmazás mellett regisztrálták, bezárás után is elküldheti őket. Ez a funkció azonban nem mindenhol érhető el, és a böngésző korlátozza a próbálkozások számát és időtartamát is, ezért a technikusnak mindig látnia kell, mi vár még küldésre.

Szükségünk van natív alkalmazásra az offline mód miatt?

Űrlapok, fotók és aláírások esetén napi szinkronizálással általában nem. Natív alkalmazást kapcsolat nélküli napok, az eszközön tárolt nagy adatmennyiség vagy háttérben történő adatküldés esetén érdemes fontolóra venni. A döntést még a fejlesztés előtt hozza meg.

Hogyan kezdjen hozzá

Ha szeretné, hogy terepen dolgozó munkatársai ne gépeljék be újra a papírokat, és ne csevegőalkalmazáson küldjék a fotókat, kezdje a feladattáblázattal és egy valódi terepi munkanappal. Nézze meg, hogyan fejlesztünk egyedi webalkalmazásokat, vagy írjon nekünk a kapcsolati oldalon. Segítünk meghatározni az offline terjedelmet, megtervezni a szinkronizálást és az ütközési szabályokat, valamint tesztelni az alkalmazást azok között a körülmények között, amelyek között használni fogja. Ha a jegyzőkönyveknek tovább kell jutniuk egy ERP- vagy CRM-rendszerbe, az API-integrációt is elkészítjük. További gyakorlati útmutatókat a blogunkon talál.

Források

• Tárhelykvóták és az adatok törlésének feltételei – MDN Web Docs (angol nyelven)
• Offline és háttérműködés a progresszív webalkalmazásokban – MDN Web Docs (angol nyelven)
• Background Synchronization API – MDN Web Docs (angol nyelven)
• A navigator.onLine tulajdonság – MDN Web Docs (angol nyelven)
• A WebKit tárolási szabályainak frissítése – WebKit blog (angol nyelven)