Offline üzemmóddal rendelkező alkalmazás fejlesztése és szinkronizálás online állapotban

Offline szinkronizálás magánügyfeleknek

Az Offline szinkronizálás akkor fontos, amikor egy alkalmazásnak vagy webes felületnek akkor is használhatónak kell maradnia, ha az internetkapcsolat megszakad. A lényeg egyszerű. Az adat ne vesszen el, a felhasználó tudjon dolgozni, majd a rendszer később rendezze a változásokat. Ez nem csak technikai kényelmi funkció. Sok esetben ettől függ, hogy az ügyfél bízik-e az alkalmazásban.

Magánügyfélként általában nem teljes fejlesztőcsapatot keresel, hanem egy olyan online szakembert, aki érti az adatkezelést, az alkalmazás működését és a felhasználói hibákat is. Szerintem ezen a területen a legfontosabb kérdés nem az, hogy lehet-e szinkront készíteni. Lehet. A kérdés inkább az, hogy milyen helyzetekben kell működnie, és mi történik, ha két eszközön ugyanaz az adat változik meg.

Én azt látom, hogy sok ügyfél csak annyit mond, legyen offline mód. De ez kevés. Más kell egy jegyzetelő felülethez, más egy foglalási rendszerhez, más egy belső nyilvántartáshoz és más egy mobilalkalmazáshoz. A szabadúszó fejlesztő akkor tud pontos árat és határidőt adni, ha látja a jelenlegi működést, az adatok típusát és azt is, hogy a felhasználók milyen gyakran dolgoznak gyenge kapcsolattal.

Kapcsolat nélküli működés célja

A kapcsolat nélküli működés célja nem az, hogy az alkalmazás mindent internet nélkül tudjon. Ez ritkán reális. A jó megoldás inkább azt jelenti, hogy a legfontosabb műveletek helyben elvégezhetők, az adatok ideiglenesen tárolódnak, majd a rendszer új kapcsolatnál elküldi vagy frissíti őket. Így a felhasználó nem érzi azt, hogy minden leállt.

Tapasztalatom szerint az első döntés mindig az, hogy mi legyen elérhető hálózat nélkül. Lehet csak olvasás. Lehet adatbevitel. Lehet módosítás és törlés is. Minél több művelet működik offline, annál bonyolultabb lesz a háttér. Nem azért, mert a fejlesztő túl akarja bonyolítani. Hanem azért, mert az alkalmazásnak tudnia kell, melyik adat régi, melyik új, melyik ütközik, és melyiket kell előnyben részesíteni.

Volt olyan eset, amikor egy ügyfél egy egyszerű űrlap mentését kérte internet nélkül. Elsőre kicsi feladatnak tűnt. Később kiderült, hogy a felhasználók több eszközön dolgoznak, néha ugyanazt a rekordot javítják, és a beküldött adatokhoz fájlok is tartoznak. A munka így már nem csak mentés volt, hanem teljes adatkezelési logika. Ezért érdemes a célokat az elején leírni.

Offline szinkronizálás árak

Az árak nagy szórást mutatnak, mert az offline működés nem egyetlen gomb. Függ a meglévő alkalmazástól, a helyi adattárolástól, a szerver oldali résztől, a hibakezeléstől és a teszteléstől. A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent, mert a hibák nem a fejlesztés közben látszanak, hanem akkor, amikor a felhasználó elveszít egy fontos adatot.

Ezek az összegek tájékoztató jellegűek, de reális kiindulást adnak egy magánügyfélnek. Egy tapasztalt fejlesztő általában nem csak kódot ír, hanem végiggondolja a kockázatokat is. Ez különösen fontos, ha az alkalmazásban ügyféladat, rendelés, foglalás, dokumentum vagy pénzügyi jellegű információ szerepel.

Szinkronizálási logika és adatbiztonság

A szinkronizálási logika lényege, hogy a rendszer tudja, mikor mit kell menteni, frissíteni vagy kihagyni. Egy egyszerű feladatnál elég lehet egy várólista. A felhasználó elküld egy adatot, a rendszer helyben eltárolja, majd később továbbítja. Összetettebb helyzetben verziókezelésre, időbélyegre, felhasználói azonosításra és konfliktuskezelésre is szükség lehet.

Sokan ott hibáznak, hogy csak a sikeres szinkront tervezik meg. Pedig a lényeg a hibás állapot. Mi történik, ha a kapcsolat félúton szakad meg. Mi történik, ha a szerver már kapott egy adatot, de az alkalmazás ezt nem tudja. Mi történik, ha a felhasználó újra megnyomja a mentés gombot. Ezek apró dolgoknak tűnnek, de a gyakorlatban ezek okozzák a legtöbb kellemetlenséget.

Adatbiztonsági szempontból az sem mindegy, hogy mi kerül a készülékre. Nem minden adatot érdemes helyben tárolni. Érzékeny információknál titkosításra, jogosultsági szabályokra és törlési logikára is szükség lehet. Szerintem egy korrekt szabadúszó nem csak azt mondja meg, mit tud megcsinálni, hanem azt is, mit nem tanácsos helyben tartani.

Megfelelő fejlesztő kiválasztása

A megfelelő fejlesztő kiválasztása ennél a feladatnál különösen fontos. Nem elég, ha valaki általános alkalmazásfejlesztést vállal. Olyan szakember kell, aki már találkozott helyi adattárolással, háttérben futó folyamatokkal, újrapróbálkozással és adatütközéssel. A portfólióban érdemes hasonló munkákat keresni, de nem kell mindennek pontosan ugyanolyannak lennie.

A jó kérdések sokat elárulnak. Ha a fejlesztő rákérdez az adatok típusára, a felhasználói folyamatokra, a szerverre, a jogosultságokra és a hibás kapcsolatra, az jó jel. Ha csak gyors árat mond rövid leírás alapján, az kockázatos. Az Offline szinkronizálás ritkán becsülhető pontosan úgy, hogy még senki sem látta a meglévő rendszert.

A Qjob.hu felületén magánszemélyek is találhatnak olyan online szakembert, aki egy konkrét részfeladatra vagy teljesebb fejlesztésre vállal munkát. Érdemes röviden, de pontosan leírni, milyen alkalmazásról van szó, milyen eszközön fut, milyen adatokat kezel, és mi a legnagyobb jelenlegi gond. Itt a részletes feladatleírás gyorsabb és pontosabb ajánlatot eredményez.

Munka menete és online egyeztetés

A munka általában egy rövid felméréssel indul. A szakember megkérdezi, van-e kész alkalmazás, hozzáférhető-e a forráskód, milyen háttérrendszer működik, és hol jelentkezik a probléma. Ezután jön a megoldási terv. Nem kell túl hosszú dokumentumra gondolni. Sokszor elég egy világos leírás arról, milyen adatok mennek helybe, mikor indul a szinkron, és mit lát a felhasználó hiba esetén.

Az online kommunikáció itt természetes. A képernyőmegosztás, a rövid videós egyeztetés, a tesztfiók és a feladatkezelő sokat segít. A fájlok, hozzáférések és visszajelzések átadása történhet írásban. Ez azért jó, mert később visszakereshető, ki mit kért és mi változott. Egy bonyolultabb fejlesztésnél ez nem adminisztrációs teher, hanem védelem mindkét félnek.

A határidő a feladat méretétől függ. Egy kisebb javítás pár nap alatt elkészülhet. Egy teljesebb kapcsolat nélküli működés több hét is lehet, főleg akkor, ha tesztelni kell több eszközön és több hibás kapcsolati helyzetben. Én inkább olyan ajánlatot tartok komolynak, amelyben külön szerepel a fejlesztés, a tesztelés és az átadás.

Gyakori hibák offline működésnél

A leggyakoribb hiba az, hogy a kliens csak a látható részt nézi. Ha a gomb működik és az adat később megjelenik, akkor késznek tűnik a munka. De a valódi próba az, amikor a kapcsolat megszakad, az alkalmazás újraindul, a felhasználó módosít valamit, majd a rendszer visszatér online állapotba. Ilyenkor derül ki, hogy a megoldás stabil-e.

Másik gyakori gond a túl sok utólagos módosítás. Először csak egy mezőt kell menteni, később képet, majd fájlt, majd több felhasználót, végül jogosultságot is. Ez nem baj, de minden új elem hatással lehet a szinkronra. Ezért a brief legyen őszinte. Nem kell tökéletesnek lennie, de tartalmazza a várható bővítéseket.

A harmadik hiba a visszajelzés hiánya. A felhasználónak tudnia kell, hogy az adat mentve van-e, várakozik-e, hibára futott-e, vagy már sikeresen szinkronizált. Ha nincs egyértelmű állapotjelzés, akkor bizalmatlanság alakul ki. És teljesen jogosan. Egy jó online fejlesztő erre is figyel, nem csak a háttérfolyamatra.

Átadás, tesztelés és későbbi javítások

Az átadásnál nem elég a kész kód. Kell egy rövid magyarázat arról, hogyan működik a szinkron, milyen eseteket kezel, és milyen korlátai vannak. Ez nem feltétlenül hosszú műszaki dokumentáció. Lehet egy egyszerű leírás is, amelyet a megrendelő megért. Tapasztalatom szerint ez később sok félreértést előz meg.

A tesztelésnek tartalmaznia kell normál használatot, gyenge kapcsolatot, teljes kapcsolatvesztést, újraindítást és sikertelen küldést is. Ha fájlok is vannak, azok külön figyelmet igényelnek. A fájlfeltöltés és az adatmentés nem mindig ugyanúgy viselkedik. Egy nagyobb kép vagy dokumentum lassabban megy át, és ilyenkor fontos, hogy a rendszer ne hagyjon félkész állapotot.

Az Offline szinkronizálás hosszabb távon akkor működik jól, ha a későbbi javításokra is gondolnak. Az alkalmazás változik, új mezők jönnek, új képernyők készülnek, és a szinkronlogikát ezekhez igazítani kell. Ezért nem csak az egyszeri fejlesztési díjat érdemes nézni. Fontos, hogy a kiválasztott szakember később is érthetően tudjon belenyúlni a rendszerbe, vagy legalább olyan átadást készítsen, amelyből más fejlesztő is tovább tud dolgozni.