In een serie artikelen vertellen onze teams welke technieken en tools zij momenteel gebruiken om tot hoogwaardige webapplicaties, API’s, websites, shops en portals voor onze klanten te komen. Dit is het tweede artikel, waarin we kijken in de keuken van team Matchminds, specialisten in (big) data, machine learning en search. Als full-stack-team zorgt dit team voor datarijke apps en webapplicaties met een fantastische gebruikerservaring. Daarnaast hebben zij Pandosearch ontwikkeld, een award winning search tool voor contentrijke websites waar al veel klanten gebruik van maken. In dit artikel zetten zij een van hun favoriete tools in de spotlight.
Bij Enrise werken we in zelfsturende teams. Dat zijn multidisciplinaire ontwikkelteams met een eigen propositie en een eigen (interne) naam. Als klant pas je op basis van je branche, uitdaging, bedrijfsgrootte, budget en technische stack dus beter bij het ene team dan het andere. Elk team heeft daarom een eigen set met de beste tools, technieken en frameworks.
React Native
Bij Enrise zijn we gek op React Native. Waarom?
- De apps die we bouwen zijn geschikt voor zowel Android als iOS;
- De apps hebben een native look and feel, in tegenstelling tot HTML webview apps;
- De performance van apps is geweldig, veel beter dan bijvoorbeeld Cordova;
- React Native apps worden geschreven in Javascript, waar we veel ervaring mee hebben.
Meer redenen waarom we fan zijn van React Native kun je vinden in een van onze eerdere artikelen.
En lees ook het blog: 3 totaal verschillende design patterns voor React
Bekijk deze case van Competentie Thermometer ook eens om te zien hoe we React inzetten.
Expo
Bovenop React Native maken we bij voorkeur gebruik van Expo. Dit is een toolchain, die ons het volgende biedt:
- Helperfuncties die het gebruiken van geodata, camera etc. vereenvoudigen;
- Een service voor push notificaties;
- Het stelt ons in staat om realtime updates van de app te publiceren.
Met name vinden we dat laatste erg praktisch! Normaliter moet elke update van een app eerst goedgekeurd worden door Apple en Google, voor de klant (of eindgebruiker) ‘m kan gebruiken. Met Expo ligt dit anders; de app zelf is als het ware een schil, die we eenmalig publiceren. Vervolgens kunnen we geautomatiseerd nieuwe versies van de code publiceren, waardoor klanten of eindgebruikers direct over de nieuwste versie van de app beschikken.
Tijdens de ontwikkelingsfase van de app is dit al een erg prettige manier van werken. Elke feature die klaar is, is meteen beschikbaar voor de klant.
Waarom zou je niet voor Expo gaan?
In een app die gebruik maakt van Expo, is het niet mogelijk om écht native code te schrijven. Je kunt alleen gebruik maken van de functionaliteiten die de Expo SDK aanbiedt. Je hebt echter situaties waarin je toch native code wilt toevoegen. Bijvoorbeeld als je afhankelijk bent van taken die op de achtergrond moeten draaien als de app inactief is. Gelukkig is de lijst van mogelijkheden die Expo biedt inmiddels vrij groot en groeit deze gestaag door.
Een ander ding om in het achterhoofd te houden, is dat je vast zit aan de Expo push notification service. Je hebt niet de mogelijkheid om bijvoorbeeld OneSignal of FCM in te zetten. De praktijk leert dat de push notification service van Expo prima werkt, maar dat bijvoorbeeld AB-testing of specifieke targeting niet mogelijk is.
Móet je vooraf voor Expo kiezen, of kan het ook later?
Voordat we een project starten sparren we met de klant over de functionaliteiten die in de app moeten komen. En wat er eventueel voor de toekomst op de planning staat. Hierop gebaseerd adviseren we hoe we de app willen gaan bouwen.
In de meeste gevallen zullen we adviseren om Expo in te zetten. In uitzonderlijke gevallen zullen we afraden om Expo in te zetten, omdat we beperkingen voorzien. Of we adviseren zelfs om React Native helemaal niet te gebruiken als dat niet de ideale tool blijkt.
Het is altijd mogelijk om in een later stadium de app van Expo te ontkoppelen. Dat is prettig, want dat zorgt ervoor dat we niet in een glazen bol hoeven te kijken aan het begin van een project en dus niet vastzitten aan onze initiële keuze!
Conclusie
Als we voorzien dat er geen native code in het project geschreven moet gaan worden, zullen we neigen naar Expo. Het geeft elk project een kickstart en zorgt voor een soepel reviewproces van de app. Het is natuurlijk tof om al in een vroeg stadium de app te kunnen gebruiken!
De mogelijkheden van Expo blijven maar groeien, dus de kans dat je maatwerk native code moet toevoegen wordt bij elke release een stuk kleiner.
Meer Keukengeheimen lezen? Je vindt hier het artikel van team Fusion over onder andere VueJS, Docker en Laravel.
