Offline mobilapp működés: hogyan tervezz térerő nélkülre?

Mi történjen, ha munka közben elmegy a térerő? Döntési útmutató az offline mobilapp funkcióihoz, a szinkronizáláshoz és az ütköző adatok kezeléséhez.

Buda Sándor · 2026-09-30

Egy szerelő a pincében tölti ki a munkalapot, egy területi képviselő gyenge térerő mellett rögzít rendelést, egy raktáros pedig olyan csarnokrészben dolgozik, ahol megszakad a kapcsolat. Ilyenkor az alkalmazás értékét az dönti el, hogy folytatható-e a munka, és később hiánytalanul bekerülnek-e az adatok a központi rendszerbe.

Az offline mobilapp működés megtervezése ezért üzleti döntéssorozat. Meg kell határozni, mely feladatok végezhetők internet nélkül, mennyire régi adat fogadható el, és ki dönt az ellentmondó változtatásokról. Ez az útmutató ezekhez ad követhető keretet, egy szemléltető munkalappéldával és átadáskor használható ellenőrzőlistával.

1. Mikor indokolt az offline működés?

Először a megszakadás következményét vizsgáld meg. Ha kapcsolat nélkül egy ritkán használt kimutatás később nyílik meg, elegendő lehet egy érthető hibaüzenet. Ha viszont a munkatárs nem tudja rögzíteni az elvégzett feladatot, papírra ír, majd este újra begépeli, az alkalmazás a legfontosabb pillanatban hagyja magára.

A felméréshez kérj konkrét eseteket a csapattól: hol szakad meg a hálózat, melyik képernyőn akadnak el, milyen adatot veszítenek el, és hogyan pótolják. A gyakoriság mellett számít a következmény is. Egy ritka, de helyszíni munkát megakasztó hiba fontosabb lehet sok rövid várakozásnál. Ne pusztán lefedettségi térkép alapján dönts.

Az üzleti mobilalkalmazás fejlesztésének tervezésekor az offline igényt már a folyamatok feltérképezésénél érdemes rögzíteni. Utólag nehezebb beilleszteni, ha minden képernyő azonnali szerverválaszra épül. Ugyanakkor az összes funkció offline elérhetővé tétele sem automatikus cél: a kritikus feladatok körét kell pontosan kijelölni.

2. Három működési szint közül válassz

Csak a korábban letöltött adatok olvashatók

Ez lehet megfelelő egy termékkatalógushoz vagy a napi feladatlista megtekintéséhez. A felhasználó látja az adatot és az utolsó frissítés idejét, módosítani azonban nem tud. Fontos korlát, hogy amit az eszköz korábban nem töltött le, azt kapcsolat nélkül nem lehet elővarázsolni. Az indulás előtti előkészítés a munkafolyamat része lesz.

Új adatok rögzíthetők, későbbi beküldéssel

A munkatárs jegyzetet, fényképet vagy új munkalapot készíthet, amely a telefonon várakozik. A központ később ellenőrzi és fogadja el. Ez sok terepi feladatnál jó kompromisszum: a helyszíni adatfelvétel folytatható, de a közös nyilvántartást érintő végleges döntéshez kapcsolat kell.

Meglévő közös adatok is szerkeszthetők

Ez a legösszetettebb változat. Két munkatárs ugyanazt a rendelést vagy munkalapot is módosíthatja, miközben egyikük sem látja a másik változtatását. Ilyenkor összevezetési szabályokra, verziókövetésre és kezelhető konfliktusokra van szükség. Csak ott vállald ezt a többletet, ahol a folyamat valóban igényli.

Az Android hivatalos offline-first útmutatója külön kezeli az olvasást és az írást, és a kritikus adatokhoz helyi adatforrást ír le. Üzleti oldalról ennek az a jelentősége, hogy az „offline képes” megjelölés önmagában kevés: funkciónként kell rögzíteni a vállalt működést.

3. Készíts offline funkciólapot

Minden érintett művelethez ugyanazokat a kérdéseket válaszold meg. Így a fejlesztői ajánlatok összehasonlíthatók lesznek, a tesztelés pedig nem áll meg annál, hogy repülő üzemmódban megnyílik az alkalmazás. A funkciólap legyen rövid, de tartalmazzon tényleges üzleti szabályokat.

1. Feladat: mit akar elvégezni a felhasználó, például lezárásra előkészíteni egy munkalapot?
2. Előkészítés: milyen adatokat és mellékleteket kell előre letölteni?
3. Helyi művelet: mi olvasható, hozható létre vagy módosítható kapcsolat nélkül?
4. Frissesség: mikortól számít elavultnak az adat, és ilyenkor mi legyen tiltott?
5. Beküldés: mikor próbálkozik az app, és miből látható a siker?
6. Kivétel: ki oldja fel az ütközést, az elutasítást vagy a hiányzó mellékletet?

A „minden szinkronizálódjon automatikusan” mondatot cseréld ellenőrizhető feltételre. Például: a helyben mentett jegyzet újraindítás után is megmarad, hálózati kapcsolat mellett beküldhető, és a központi elfogadásig várakozó jelölést kap. Ezt már mindkét fél ugyanúgy tudja kipróbálni.

4. Példa: terepi munkalap internet nélkül

Az alábbi kitalált példa a döntések szemléltetésére szolgál. Egy karbantartó csapat reggel letölti a saját napi feladatait, a szükséges eszközadatokat és a munkavégzési ellenőrzőlistát. A szerelő a helyszínen térerő nélkül rögzíti a megállapításokat, felhasznált anyagokat és fényképeket. Az alkalmazás minden mentésnél jelzi, hogy az adat egyelőre ezen az eszközön található.

A munkalap „beküldésre kész” állapotba kerülhet, de a végleges elszámolást a központ végzi. Ha időközben a diszpécser törölte a megbízást, a később érkező helyszíni jelentés nem állíthatja vissza automatikusan. A rendszer megőrzi a rögzítést, és egy kijelölt felelős elé teszi az eltérést. Így a szerelő munkája és a központi döntés is látható marad.

Ennél a példánál az első változatból kihagyható a teljes ügyféltörténet és az összes raktárkészlet letöltése. Ezek növelnék a tárolási, adatvédelmi és frissítési feladatokat, miközben a helyszíni dokumentálás nélkülük is elvégezhető. Az offline hatókört a napi feladat kiszolgálása indokolja, nem az adatbázis mérete.

5. Mit jelent a mentés, és mit jelent az elfogadás?

A felületen különböztesd meg a helyi mentést, a beküldésre várakozást, a folyamatban lévő küldést, a központi elfogadást és a beavatkozást igénylő hibát. Egyetlen zöld pipa félrevezető, ha a munkatárs abból azt érti, hogy az iroda már megkapta a munkalapot. A státuszhoz rövid magyarázat és szükség esetén következő lépés tartozzon.

A fényképeket külön is kezeld. Előfordulhat, hogy a szöveges munkalap beérkezett, de egy nagy melléklet feltöltése megszakadt. Ilyenkor a központ ne mutasson teljes dokumentációt, ha kötelező bizonyíték hiányzik. A munkatárs lássa, melyik kép várakozik, és ne kelljen az egész munkalapot újra elkészítenie.

Szintén előre tisztázandó a kijelentkezés és az alkalmazás törlésének következménye. A csak helyben tárolt, még be nem küldött munkáról nem feltételezhető, hogy a szerveren visszaállítható. Legyen figyelmeztetés a függő tételekről, és kialakított támogatási folyamat arra, ha a felhasználó nem tudja befejezni a beküldést.

6. Ütköző módosítások: üzleti szabály döntsön

Az „utolsó módosítás nyer” egyszerűnek hangzik, de könnyen elveszíthet értékes információt. Egy megjegyzés hozzáfűzhető az előzményekhez; egy ügyfélcím két eltérő változata viszont döntést kívánhat. Még veszélyesebb, ha valaki offline módon jóváhagyottként jelöl egy rendelést, miközben a központ már visszavonta azt.

Mezőnként és műveletenként határozd meg a szabályt. A különálló fényképek általában együtt megőrizhetők. Egy státuszváltás csak engedélyezett előzményből fogadható el. Mennyiségek módosításánál pedig tisztázni kell, hogy új összértéket rögzítettek, vagy növelést és csökkentést. A két jelentés nem cserélhető fel.

Ha ezek a szabályok a központi munkafolyamatot is érintik, az üzleti logikára szabott szoftver és integráció tervezése az app fejlesztésével együtt szükséges. A telefon önmagában nem tudja eldönteni, melyik szervezeti döntés az érvényes. A vitás eseteket kezelő adminfelület és felelős ugyanúgy része a megoldásnak.

7. Ismételt beküldésből ne legyen dupla munka

Tipikus eset, hogy a központ elfogad egy munkalapot, de a válasz már nem jut vissza a telefonra. Az alkalmazás ilyenkor újrapróbálkozhat. A fogadó rendszernek fel kell ismernie, hogy ugyanarról a műveletről van szó, különben két munkalap, két feladat vagy két értesítés keletkezhet.

A specifikációban ennek üzleti elvárását rögzítsd: egy rögzítés ismételt elküldése ne eredményezzen újabb üzleti eseményt. A technikai megoldás része lehet az egyedi műveletazonosító és a korábbi eredmény visszaadása. A kapcsolódó automatizációkat is vizsgálni kell, mert a dupla e-mail akkor is kellemetlen, ha az adatbázisban csak egy rekord maradt.

Ha a munkalap később ügyfélfeladatot indít, a CRM-folyamat és az automatikus utánkövetés kialakításakor is legyen egyértelmű az indító esemény. A helyi mentés, a központi elfogadás és a vezetői jóváhagyás három külön időpont. Az ügyfélnek csak a megfelelő állapot után menjen visszaigazolás.

8. Frissesség, készlet és jogosultság kapcsolat nélkül

A tegnap letöltött ár vagy készlet nem feltétlenül érvényes ma. A felhasználónak látnia kell az utolsó sikeres frissítés idejét, de ez önmagában nem elég. Döntsd el, meddig használható az adat, és mi történik a határ után: figyelmeztetés, csak olvasható mód vagy az adott művelet tiltása következik.

Közös készletnél különösen fontos a korlát. Két offline eszköz nem tudja biztosan, hogy a másik mennyit foglalt le. Lehetséges üzleti megoldás az előzetesen elkülönített készletkeret, az előzetes rendelési igény rögzítése vagy az online véglegesítés. A döntés attól függ, milyen következménnyel járna a túlfoglalás.

A központban visszavont hozzáférés sem jut el azonnal egy hálózatról leválasztott telefonra. Ezért meg kell határozni az offline hozzáférés időbeli és adatkörbeli korlátait. Csak a munkához szükséges adat kerüljön a készülékre, megfelelő helyi védelemmel. A később beküldött módosításokat a szerver az aktuális jogosultságok alapján is ellenőrizze.

9. A háttérszinkron mellett legyen látható befejezés

A munkafolyamatot úgy tervezd, hogy a munkatárs ellenőrizhesse a napi függő tételeket és kezdeményezhesse a szinkronizálást. Ne abból indulj ki, hogy a háttérben minden mindig azonnal elkészül. Az eszköz állapota, az alkalmazás futása és a hálózat minősége is befolyásolhatja a tényleges befejezést; ezt a célplatformokon külön kell tesztelni.

A műszak lezárásának része lehet a be nem küldött munkalapok áttekintése. A vezetői felület pedig külön mutassa a beérkezett és a hiányos tételeket. Ez nem jelenthet folyamatos kézi ellenőrzést: a cél az, hogy a kivételek kerüljenek ember elé, a normál folyamat pedig követhetően haladjon.

10. Így teszteld a valódi megszakításokat

A repülő üzemmód csak a kiindulópont. A hibák gyakran kapcsolatváltáskor, részleges feltöltésnél vagy újraindítás után jelentkeznek. A tesztet valós szerepkörökkel, külön tesztadatokkal és a tervezett készülékeken végezzétek. Minden esethez legyen előre rögzített elvárt eredmény, különben a „nálam működik” lesz az elfogadási feltétel.

• Megnyitható a napi feladat, ha az előkészítő letöltés sikerült?
• Érthető jelzés látható, ha a szükséges adat még sosem került a telefonra?
• Megmarad a helyben mentett munka az app bezárása és újraindítása után?
• Megkülönböztethető a helyi mentés a központi elfogadástól?
• Folytatható a megszakadt mellékletfeltöltés adatvesztés nélkül?
• Ugyanazon művelet ismételt beküldése nem hoz létre második üzleti eseményt?
• Kezelhető, ha két eszköz ugyanazt a rekordot módosítja?
• Látható marad az elutasított módosítás oka és a megoldás felelőse?
• Érvényesül a lejárt adat és a megváltozott jogosultság szabálya?
• Figyelmeztet a rendszer kijelentkezés előtt a még függő munkára?

A tesztjegyzőkönyvben az adat útját is kövessétek: mit lát a telefon, mi érkezett meg a szerverre, és milyen automatizmus indult el. Ezzel elkülöníthető a kijelzési hiba a hiányos feldolgozástól. A felhasználói sikerjelzés csak akkor megbízható, ha a mögötte álló üzleti eredmény is helyes.

11. Mi növeli a költséget, és mivel kezdj?

A ráfordítást az offline módosítható adatkörök száma, a közös szerkesztés, a mellékletek, az adatérzékenység és az integrációk viselkedése alakítja. Egy letölthető katalógus más feladat, mint több telephely párhuzamos készletmozgásainak kezelése. Az ajánlatban külön jelenjen meg a mobilos működés, a szerveroldali feldolgozás és a konfliktusok kezelésének felülete.

Kezdésként válassz egyetlen teljes munkafolyamatot: előkészítés, helyszíni rögzítés, beküldés, elfogadás és hibajavítás. Kis felhasználói körben figyeld meg, hány tétel marad függőben, hol kell kézi beavatkozás, és mennyi ismételt adminisztráció marad. A bővítést ezekhez a tapasztalatokhoz igazítsd, ne a kívánságlista hosszához.

Összegzés: a megszakítás is legyen megtervezett állapot

Egy jól megtervezett offline mobilapp pontosan megmondja, mi végezhető el internet nélkül, hol található az adat, és mikor tekinthető véglegesnek a művelet. A megbízhatóságot az egyértelmű határok, az ellenőrizhető mentés, a duplikációk kivédése és a rendezett kivételkezelés adja. Ezeket már az első használható verzióban érdemes végigvinni.

Ha terepi vagy időszakosan kapcsolat nélküli munkához tervezel alkalmazást, hozd el egy tipikus munkanap folyamatát és a leggyakoribb elakadást a BudaWeb mobilapp-fejlesztési konzultációjára. Ebből meghatározható a szükséges offline funkciók köre, az első verzió határa és az a teszt, amellyel átadáskor ellenőrizhető a működés.