In een vliegtuig, in het buitenland of in een buitengebied; tegenwoordig kom je nog regelmatig situaties tegen waarin je niet online bent of kunt zijn. VPRO Tegenlicht noemde het onlangs zelfs een luxe om af en toe offline te zijn. Hoewel ze schaars zijn, bracht het programma met de ‘White Spots’-app alle plekken op aarde in kaart waar je geen verbinding hebt met internet of Wi-Fi.
Wanneer je een mobiele applicatie ontwikkelt, zul je dus ook met de offline situaties rekening moeten houden. Je wilt uiteraard dat je applicatie steeds optimaal werkt, ook als er even geen verbinding is. Eén van de belangrijkste vraagstukken die je hierbij tegenkomt, is het kiezen voor een data cache-strategie. Waar haal je de data vandaan die nodig is voor een optimale performance? Lokaal of van de server? Maar wat als er geen of juist wel een verbinding beschikbaar is? Haal je dan eerst de data uit lokale bronnen of maak je direct een connectie met de server? Kortom: hoe kies je de juiste cache-strategie?
Bij het ontwikkelen van een mobiele applicatie heb je te maken met twee belangrijke zaken: performance en connectiviteit. Ook word je beperkt door schaarse resources als opslagruimte en batterijduur. Voor een applicatie die data nodig heeft voor de presentatie, is het essentieel dat je je afvraagt welke data je lokaal opslaat en welke op de server. Om de server te bereiken, is de beschikbaarheid van internet natuurlijk noodzakelijk, maar niet altijd aanwezig. Daarom moet je bij het ontwikkelen van de applicatie ook rekening houden met offline scenario’s. Ook de aard van de internetverbinding is belangrijk om te onderkennen. Zo heb je te maken met gsm-verbindingen, die mogelijk worden betaald per MB, of wifi. Bij bulk data over een gsm-verbinding is het het overwegen waard om de gebruiker te informeren over mogelijke kosten voor het ophalen van data.
Om deze situaties te ondervangen, kun je data ook lokaal opslaan. Wanneer je dit doet, heb je in een offline situatie wel de mogelijkheid om de benodigde data te laten zien vanuit de cache. Tijdens het programmeren van een mobiele applicatie heb je een aantal keuzes voor cache-scenario’s.
1. Performance
Als er verbinding is met internet, wordt data altijd eerst van de server afgehaald en daarna pas lokaal opgeslagen. Wanneer je niet verbonden bent, wordt data vervolgens lokaal opgehaald. Dit scenario werkt goed in zowel on- als offline situaties, maar is niet een cache-strategie die de performance van je apparaat bevordert, omdat dit veel vraagt van de netwerkverbinding en batterijduur. Daarnaast moet er data worden opgehaald van een backend en worden getransporteerd over internet. Dit is per definitie trager dan data lokaal ophalen en vraagt ook veel meer van de batterij. Dit scenario heet een ‘server first approach’.
Bij een server first approach is de data vaak het nieuwst en het verst, omdat je altijd via de server werkt en over de meest up-to-date beschikt. Deze approach is bijvoorbeeld erg belangrijk bij applicaties waarbij data vaak vernieuwd wordt, zoals nieuws-applicaties. Wanneer je zo’n app opent, zie je altijd het laatste nieuws. Tenzij je niet verbonden bent, dan zie je (meestal) het laatst opgehaalde nieuws (waarvoor de data uiteraard wel is opgeslagen in cache).
2. Beschikbaarheid
Een andere mogelijkheid is om de applicatie zo te programmeren dat er altijd eerst wordt gekeken of data lokaal beschikbaar is in cache – ongeacht of er op dat moment een internetverbinding aanwezig is. Pas als de benodigde data niet in cache staat, wordt er verbinding gemaakt met internet en wordt de data van de server opgehaald om het vervolgens alsnog in cache op te slaan. Dit scenario heet een ‘cache first approach’.
Een cache first approach wordt meestal toegepast als je te maken hebt met veel data die bijna niet verandert; denk bijvoorbeeld aan een overzicht van rekeningen in een bank-app. Wanneer je deze informatie iedere keer opnieuw van de server af moet halen, kost dat veel netwerkverkeer, resources en batterij. Daarom kun je de data beter ophalen, lokaal opslaan in cache en vervolgens vanuit de cache in de applicatie toepassen. Deze benadering komt de performance en batterijduur zeker ten goede. Daarom noemen we dit ook wel ‘performance cache’.
3. Meerdere caching-strategieeën naast elkaar
Daarnaast heb je ook nog te maken met data die je helemaal niet in cache op wilt slaan en altijd van de server haalt, zoals beveiligingsgevoelige informatie, bijvoorbeeld aan wachtwoorden. Maar ook data die juist heel veranderlijk is, zoals prijsinformatie of informatie over beschikbaarheid, haal je liever altijd live op in plaats van in cache. Het is dan mogelijk om bijvoorbeeld de bijbehorende productinfo wel in cache op te slaan maar de prijsinformatie alleen te laten zien wanneer er verbinding is met de server, zodat je zeker weet dat je altijd de meest actuele informatie toont. In dit scenario kies je er dus voor om meerdere cache-strategieën te hanteren voor verschillende soorten informatie binnen één applicatie.
Beste performance
Als het gaat over het ontwerpen van cache-strategieën, zijn er een aantal manieren om slim met het ophalen van de data om te gaan ten behoeve van de performance en beschikbaarheid van data. Zo kun je een timestamp op de server en de client bijhouden van wanneer de data voor het laatst is bijgewerkt. Bij verbinding wordt deze timestamp gecontroleerd om te kijken of de data in cache nog steeds actueel is voordat er nieuwe data wordt opgehaald.
Er zijn ook libraries voor Xamarin, zoals Akavache, waarbij de cache kan worden gebruikt om de data alvast te laten zien aan de gebruiker, terwijl er op de achtergrond (bij verbinding) de data van de server wordt opgehaald. Nadat deze data is opgehaald, kan de ontwikkelaar de data in cache vervangen met de serverversie.
Dit maakt dat de applicatie qua performance goed presteert, offline data beschikbaar heeft en bij verbinding ook data vers kan bijhouden. Ook hier geldt dat dit wellicht voor veel data interessant kan zijn, maar niet voor iedere soort data geschikt is.
Behalve het kiezen voor een cache-strategie, moet je bij het ontwikkelen van een applicatie natuurlijk ook online en offline situaties detecteren, bepalen hoe je dan met de data omgaat en of en hoe je dat aan de gebruiker laat zien. Veel mobiele applicaties geven bijvoorbeeld tegenwoordig een melding aan de eindgebruiker als ze niet verbonden zijn en tonen dan de laatst opgehaalde informatie vanuit de cache. Bij het bepalen van de juiste data en cache-strategie kan de grootte van de data ook een rol spelen. Zo kun je tegenwoordig met de mobiele devices prima beschikken over redelijk grote bestanden, maar het ophalen ervan kan lang duren en eventueel veel geld kosten bij gsm-verbindingen.
Om de juiste data cache-strategie te kiezen, moet je je dus een aantal zaken afvragen. Het kiezen van de juiste strategie is trouwens niet alleen een it-vraagstuk. Ook de business moet hierover nadenken en beslissen over de volgende punten:
- Hoe actueel moet de data zijn?
- Welke data moet live zijn en welke niet?
- Hoe groot is de data?
- Welke tijdsindicatie wil ik hanteren voor het verversen van de data uit de cache?
- Hoe veel resources (batterij, opslagruimte) mag het kosten?
- Hoe laat ik de gebruiker weten dat er data uit cache wordt gebruikt?
Actieve ontwerpstap
Het feit dat je na moet denken over data cache-strategieën, maakt het ontwikkelen van een mobiele applicatie uitdagender dan het ontwikkelen van een webapplicatie die altijd verbonden is. Je hebt te maken met beperkte capaciteiten voor storage en beperkte capaciteiten in verband met batterijduur, maar je wilt natuurlijk wel altijd de beste performance van je app. Kiezen voor de juiste cache-strategie vereist een actieve ontwerpstap waarmee nog niet altijd rekening wordt gehouden. De grootste fout die ontwikkelaars maken is ervan uitgaan dat de eindgebruiker overal en altijd verbonden is.
