Offlineläge – när behöver appen det?
Av CodexierPublicerad 6 min läsning
Offlinestöd står på nästan varje kravlista för appar och definieras nästan aldrig. Det kan betyda att appen inte kraschar utan täckning, eller att en tekniker redigerar en arbetsorder i en källare, en kollega redigerar samma order på kontoret, och båda ändringarna överlever. Det första är en dags arbete; det andra är ett eget projekt. Den här guiden beskriver nivåerna, vad varje nivå kostar och hur ni avgör utifrån var era användare faktiskt befinner sig när täckningen försvinner.
Vem som faktiskt arbetar offline
Sverige har bra mobiltäckning i tätorter och ojämn täckning på exakt de platser där arbete sker: källare, fläktrum, skog, färjor, Norrlands inland, lager med stålhyllor. Be de som ska använda appen beskriva senaste gången de saknade täckning på jobbet och vad de behövde göra i det ögonblicket. Är svaret läsa en checklista är det en nivå. Är svaret registrera en leverans med signatur och foto är det en annan. Kan ingen minnas behöver ni troligen bara första nivån.
Nivåer av offlinestöd
Varje nivå lägger till en förmåga och en klass av problem. Att namnge nivån i kraven är det som gör en vag önskan till något en utvecklare kan uppskatta.
| Nivå | Vad användaren kan göra utan täckning | Vad appen måste hantera | Typiskt behov |
|---|---|---|---|
| 1. Mjuk nedgradering | Se de senast laddade skärmarna; tydliga meddelanden när åtgärder kräver uppkoppling | Cacha svar, känna av uppkoppling, försöka igen | Nästan varje app |
| 2. Cachad läsning | Bläddra i ett valt datamängd fullt ut: schema, kundlista, manualer | Lokal databas, bakgrundsuppdatering, markering av gammal data | Sälj, service, vårdpersonal |
| 3. Köade åtgärder | Skapa och skicka poster som laddas upp senare: rapporter, signaturer, foton | Utkorg, ordning, omförsök, dubblettskydd | Fältservice, transport, besiktning |
| 4. Full redigering offline med synk | Redigera delade poster offline och slå ihop med andras ändringar | Konfliktdetektering och lösning, versionering, sammanslagningsbeslut för användaren | Sällsynt: delade dokument, flera användare i fält |
Synkkonflikter förklarade
En konflikt uppstår när två personer ändrar samma post medan minst en av dem är offline. Appen kan inte veta vilken ändring som är rätt, och varje strategi för att avgöra det har ett fall där den misslyckas. Det är mekanismen som gör nivå fyra dyr: koden är inte svår att skriva, men varje regel måste förklaras för användarna och testas för varje posttyp.
Senaste ändringen vinner
Den nyaste ändringen skriver över den tidigare. Enkelt, och tappar arbete i tysthet. Acceptabelt för fält med lågt värde som en anteckning, inte för en status eller ett antal.
Sammanslagning per fält
Ändringar i olika fält på samma post överlever båda; ändringar i samma fält ger konflikt. Hanterar de flesta verkliga fall men kräver spårning per fält och en regel för resten.
Fråga användaren
Visa båda versionerna och låt en person välja. Korrekt, men bara hanterbart när konflikter är sällsynta och användaren förstår posten. Låt aldrig en förare lösa en sammanslagning vid en lastkaj.
Undvik genom design
Ge varje post en ägare medan den är ute i fält, så att ingen annan kan redigera den. Det är den billigaste strategin och fungerar för de flesta fältarbetsflöden.
Kostnaden för varje nivå
Kostnaden är inte bara byggtid; det är den löpande vikt varje framtida funktion bär. På nivå ett är en ny skärm en ny skärm. På nivå tre behöver en ny skärm som skapar poster en utkorgspost, en omförsöksregel och ett test för vad som händer om enheten dör mitt i uppladdningen. På nivå fyra behöver den också en sammanslagningsregel. Var ärliga med om arbetsflödet motiverar det på varje funktion för alltid.
- Nivå ett: en liten del av appbudgeten, mest felhantering och cachning. Gör det alltid.
- Nivå två: en lokal databas och ett synkschema; måttligt, och det gör också appen snabbare online, vilket användare märker mer än offline.
- Nivå tre: en utkorg med ordning, omförsök och idempotenta uppladdningar så att en rapport aldrig skapas två gånger. Foton och signaturer är där lagrings- och uppladdningsfallen bor.
- Nivå fyra: konflikthantering per posttyp, plus gränssnittet som förklarar den. Ofta flera gånger kostnaden för nivå tre, och den växer med varje ny posttyp.
- Alla nivåer: testtiden stiger brant, eftersom varje flöde måste testas online, offline och i övergången däremellan.
Testa beteendet offline
Offlinebuggar gömmer sig i övergångarna: täckningen som försvinner under en uppladdning, uppkopplingen som kommer tillbaka i tre sekunder, telefonen som startar om med en halvt skickad utkorg. En testplan för offline är en lista över de övergångarna, körd på riktiga enheter, inte bara i simulatorns flygplansläge.
- Starta en åtgärd online, bryt uppkopplingen mitt i anropet och bekräfta att appen varken tappar eller dubblerar posten.
- Arbeta offline i en timme, starta om telefonen, koppla upp igen och kontrollera att allt laddas upp i ordning.
- Använd en dålig uppkoppling, inte ingen uppkoppling; långsam och hackig är vanligare än frånvarande och knäcker annan kod.
- Låt två användare redigera samma post med en offline, och kontrollera att utfallet matchar regeln ni valde.
- Fyll enhetens lagring med foton och bekräfta att utkorgen hanterar det och att användaren informeras.
När ni inte behöver detta: en app som används på kontor, i butiker och i hem med normal täckning behöver nivå ett och kanske nivå två för hastighetens skull, och en leverantör som föreslår mer säljer komplexitet. Där nivå tre och fyra tjänar in sin kostnad är ett dokumenterat arbetsflöde på platser utan täckning, med åtgärder som inte får gå förlorade. Den analysen är en del av att avgränsa en plattformsoberoende MVP-app med oss: vi namnger nivån i planen, så att uppskattningen på prissidan betyder samma sak för båda sidor. Är ni osäkra på vilken nivå era användare behöver, boka ett samtal och beskriv var de arbetar.
Vanliga frågor
Räcker en webbapp eller PWA för offlineanvändning?
För nivå ett och lätt nivå två kan en välbyggd PWA med service worker cacha skärmar och data. Pålitliga köade uppladdningar med foton, bakgrundssynk och stora lokala datamängder är där native- eller plattformsoberoende appar är mer tillförlitliga, särskilt på iOS, som begränsar vad en PWA får göra i bakgrunden.
Hur mycket data kan vi lagra i telefonen?
Strukturerad data för ett schema eller en kundlista är liten; foton och dokument är det som fyller enheter. Sätt en regel för hur många dagars poster som sparas lokalt och komprimera foton före lagring, och berätta för användaren när lagringen håller på att ta slut i stället för att misslyckas tyst.
Påverkar offlinestöd GDPR?
Ja. Personuppgifter cachade på en enhet är personuppgifter ni ansvarar för, på en enhet som kan tappas bort. Kryptera lokal lagring, håll den cachade mängden minimal, låt den gå ut, och gör fjärradering eller utloggning på förlorade enheter till en del av planen.
Kan vi lägga till offlinestöd senare?
Nivå ett och två kan läggas till i en befintlig app med måttlig insats. Nivå tre och fyra är mycket enklare att designa in från början, eftersom de formar hur poster identifieras och hur backend tar emot uppladdningar. Är fältanvändning trolig, bestäm nivån innan datamodellen byggs.
Osäker på vilken offlinenivå er app behöver?
Femton minuter: beskriv var och hur era användare arbetar, så säger vi vilken nivå som passar, vad den ändrar i bygget och vad den kostar.
Boka ett kostnadsfritt 15-minuterssamtal