Constructieprincipes voor de informaticus: (11) Apparaat onafhankelijk ontwikkelen

De wens vanuit de bedrijfsarchitectuur heeft gevolgen voor een aantal te maken keuzes in de softwareontwikkeling (naast keuzes over apparaat beheer, infrastructuur, beveiliging en updates, kennis bij de helpdesk etc.). Zo is een keuze nodig over welke besturingssystemen moeten worden ondersteund (afgeleid van de apparaten – ook wel eindapparatuur of user devices genoemd - waarvoor de functionaliteit te gebruiken moet zijn). Je kunt natuurlijk als organisatie kiezen om alleen Microsoft Windows als OS/platform te ondersteunen maar in de praktijk ontkom je niet aan iOS en Android, want de Windows smartphone en tablet zijn nu eenmaal niet de marktleider. Meerdere platformen of ecosystemen kunnen ondersteunen, wordt daarom een eis. De keuze voor apparaat onafhankelijk werken betekent; platform onafhankelijk werken.

Een ander belangrijk aspect is het ontwerp van de schermen (UI en UX). De schermgrootte van verschillende apparaten verschilt, dus hoe kun je die laten schalen per apparaat zonder eindeloos scrollen en inzoomen?

Als apparaat onafhankelijk werken betekent dat je platform onafhankelijk moet kunnen werken dan is het gevolg dat je de functionaliteiten voor elk toegestaan platform moet ontwikkelen. Hier komt de wens om platform onafhankelijk te kunnen ontwikkelen vandaan, anders moet je meerdere ontwikkelstraten inrichten.

Het goede van platformonafhankelijk ontwikkelen is dat ontwikkelaars de ontwikkelingstijd kunnen beperken door eenmaal code te schrijven die gebruikt kan worden voor meerdere platforms. Je hoeft maar eenmaal te ontwikkelen; de code is herbruikbaar “cross platform”!

Het is daarmee een vorm van ontkoppelen tussen software en platform.

Eén oplossing is om een ontwikkelframework te kiezen dat gebruikers toestaat om applicaties in een dynamische programmeertaal te schrijven (de populairste is Javascript, hoewel veel frameworks ook Ruby of Python ondersteunen). Met een dynamische programmeertaal zullen de frameworks compileren met de bibliotheken van een specifiek platform en een applicatie (de zogenaamde “native app”) produceren voor elke platform die de ontwikkelaar heeft gekozen. Voor deployment (app store), testen en beheer heb je wel dubbel tijd nodig.

Een andere oplossing is kiezen voor een “web app”. Een web app werkt in elke browser, ongeacht het platform, en hoef je dus ook maar eenmaal te ontwikkelen, testen en deployen. De web app moet natuurlijk wel geoptimaliseerd worden voor de verschillende toestellen waarop het gebruikt gaat worden. Een goed responsive design is cruciaal voor een goede gebruikerservaring en dat kan ook behoorlijk ontwikkeltijd in beslag nemen. Daarnaast moet je zorgen dat de web app onafhankelijk is van de gebruikte browser en geen plug-ins vereist, anders moet de eindgebruiker toch iets installeren.

Een variant van de web app is het gebruik van een beveiligde webomgeving zoals Citrix om de applicatie ter beschikking te stellen.

Tegenwoordig is ook een tussenvariant in opkomst; de hybride app. Deze app download je uit de App store maar de basis voor een hybride app is een web app, welke vervolgens geschikt wordt gemaakt voor de gewenste besturingssystemen. De keuze tussen deze drie manieren van efficiënt te ontwikkelen is weer afhankelijk van de vraag of op het mobiele apparaat qua functie een “native app” vereist of niet.

Bij specifieke interactie tussen OS/apparaat en de software ontkom je vaak niet aan een native app. Denk aan gebruik van de sensoren of specifieke knoppen van het apparaat en bijvoorbeeld push notificaties. Dit werkt per apparaat en platform anders en dat maakt noodzakelijk dat ook de software specifiek wordt gemaakt. Het grote verschil tussen native en web apps hierin is, dat een native app de taal van de telefoon perfect spreekt. Een native app is daarom vaak sneller, efficiënter en voelt beter aan. Als apparaatspecifieke hardware, gebruikersvriendelijkheid en snelheid belangrijk zijn dan kies je voor native. Ook de eis om bijvoorbeeld offline te kunnen blijven werken leidt naar native. Een web app werkt immers alleen als je een internetverbinding hebt!

Het grootste voordeel van een web app is dat deze eenvoudig te bereiken is. De gebruiker hoeft de app namelijk niet eerst te downloaden en installeren. Bovendien is de ontwikkeltijd vaak korter en liggen de kosten dus vaak ook lager. Daarnaast hoeft een web app niet goedgekeurd te worden door een Apple – of Google play store, wat extra werk met zich meebrengt en meer tijd kost. Een update wordt instantaan doorgevoerd. Tenslotte is er bij een web app ook geen dataopslag op het apparaat, wat een voordeel kan zijn.

De hybride app zit hier een beetje tussenin en maakt de keuzemogelijkheden breder.

Als informaticus zijn er dus heel wat afwegingen te maken om een keuze te maken in de mogelijke oplossingen. Daarvoor heeft de rijksoverheid een handig afwegingskader geschreven dat je hier kunt vinden.

1. Betekenisloze identiteitsaanduiding, lees hier.
2. Ontkoppelpunten voor complexiteitsreductie en flexibiliteit, maximale onafhankelijkheid van delen, lees hier.
3. Consistentie van taal, lees hier.
4. Duidelijke verantwoordelijkheidsverdeling en functiescheiding voor de administratie, lees hier.
5. Beslissingsbevoegdheid voor de uitvoering zo laag mogelijk beleggen, lees hier.
6. Autorisatie loskoppelen van identificatie/authenticatie, lees hier.
7. Enkelvoudige vastlegging van stamdata, lees hier.
8. Data en metadata scheiden in opslag en verwerking, lees hier.
9. Standaardpatronen toepassen zonder afwijkingen, lees hier.
10. Applicatiefunctie en dataopslag scheiden, lees hier.
11. Apparaat onafhankelijk ontwikkelen, lees hier.