Offline first is een productbeslissing, geen cachinglaag

Elk buitendienstteam vraagt om offline ondersteuning na hun eerste week zonder bereik. De vraag klinkt als een cachingprobleem. Dat is het nooit.

Vier vragen voor er code geschreven wordt

1. Wanneer twee toestellen offline hetzelfde record aanpassen, welke wint dan?
2. Wat mag de app beloven aan een gebruiker die op dit moment offline is?
3. Hoe lang mogen verouderde gegevens op het scherm blijven voor ze een leugen worden?
4. Wat gebeurt er met een actie in de wachtrij die de server later weigert?

Teams die eerst deze vier vragen beantwoorden, leveren offline ondersteuning in enkele weken. Teams die met een cachingbibliotheek beginnen, ontdekken de vragen maandenlang één bug per keer.

Conflictoplossing is een productregel

Last write wins is een beslissing, geen standaard. In een logistieke app mag de leveringsbevestiging van een chauffeur nooit overschreven worden door een verouderde wijziging van een dispatcher, dus het record draagt zijn oorsprong mee en de merge-regel leest die uit.

fun merge(local: Delivery, remote: Delivery): Delivery = when {
    local.confirmedByDriver && !remote.confirmedByDriver -> local
    remote.updatedAt > local.updatedAt -> remote
    else -> local
}

Toon de status, verberg hem niet

De apps die offline betrouwbaar aanvoelen, zijn de apps die zeggen wat ze weten:

• Gesynchroniseerd — dit komt overeen met de server op een tijdstip dat de gebruiker kan zien.
• In behandeling — lokaal in de wachtrij, wordt verstuurd zodra er weer bereik is.
• Geweigerd — de server heeft het geweigerd, en dit is wat je eraan kunt doen.

Zodra een app offline doet alsof alles in orde is, gelooft de gebruiker hem niet meer wanneer hij online zegt dat alles in orde is.

Wat het kost

De tweede kolom geeft de doorslag. Een cache die op een network-first app wordt vastgeschroefd, genereert supporttickets zolang het product bestaat.

• architecture
• mobile
• kotlin