Hoe zet je professioneel een Flutter project op?

Ga je aan de slag met een mobile Flutter project? Nice! De technische set-up haal je vlot uit de documentatie van Flutter zelf maar hoe pak je nu dat project in z’n geheel aan? Hoe start je van bij het begin aan een professionele set-up? No worries, expert van dienst Yannick neemt je mee door de best practices die we bij RMDY toepassen. Let’s go!

Tekst: Yannick Van Godtsenhoven, Solution Lead bij RMDY Mobile

Om een mobile project professioneel op te zetten, zijn er een aantal best practices die je van bij de start implementeert. Bij RMDY hebben we die ook nog eens volledig geautomatiseerd en geoptimaliseerd – want de beste developer is een luie developer, toch? 😉 Of eerder: eentje die niet graag repetitief werk doet en dus zelf maar een scriptje schrijft.

Project template

Voor we starten met de effectieve stappen naar een professionele set-up, een woordje uitleg over onze project template. Je hoéft onderstaande stappen namelijk niet te automatiseren, ook zonder script zijn het best practices. Maar binnen RMDY deden we het wel. Waarom? Omdat wij naast het automatiseren van repetitief werk ook streven naar efficiëntie, transparantie en vooral: uniformiteit. Dankzij onze template hebben al onze Flutter-projecten dezelfde set-up. Dat maakt het gemakkelijk om nieuwe developers te onboarden of werk over te dragen bij ziekte of vakantie.

1. Eén app, 4 versies

Voor je start met de ontwikkeling van je app, zet je verschillende versies op. Waarom? Dat maakt het gehele proces van developers tot eindgebruiker vlotter, efficiënter en transparanter. De vier versies die we bij RMDY gebruiken zijn: development, test, acceptatie en productie. Elke versie is in het begin een kopie, maar met elk een andere naam, Apple ID, Google Play ID, en een andere backend-omgeving om naar te connecteren… Dankzij deze 4 versies heb je meteen ook 4 kansen om er fouten uit te halen.

Development versie

Dit is het speelveld van de developers, hier zijn alle nieuwste features in beschikbaar. Klaar? Dan gaan die features door naar de volgende versie.

Test versie

De naam zegt het zelf: in deze versie wordt er getest! Vaak door iemand die geen of beperkte development kennis heeft zoals een product owner. Die test de nieuwe features en als die goedgekeurd worden gaat heel de boel naar de acceptatie versie.

💡Er wordt nooit gewerkt met gegevens van echte gebruikers maar met dummy user data.

Acceptatie versie

In deze versie van de app testen de business profielen van de klant. Ze krijgen een change log met alle wijzigingen en welke feature ze moeten checken.

💡Voor de klant wordt er soms wel gewerkt met gegevens van echte gebruikers, maar die worden volledig geanonimiseerd en beveiligd.

Productie versie

Als ook business getest en goedgekeurd heeft, wordt de feature of wijziging gereleased naar de productieversie aka: waar alle eindgebruikers op zitten. De app die je in de stores downloadt.

Nu, we spreken over ‘versies’ maar in praktijk heb je als developer of software lead vier soort van kopies van de app op je telefoon staan. Bovendien is het belangrijk dat die allemaal samen kunnen draaien. Daarom zijn we ook fan van een visueel kenmerk om meteen te zien in welke versie je zit vb. andere achtergrond, icoontje of banner. Soms kiest een klant voor slechts 2 of 3 versies – dat kan zeker, maar wij vinden het niet ideaal. Als bijvoorbeeld ontwikkelaars en testers op dezelfde versie werken, kan het al eens kan gebeuren dat testers geblokkeerd zitten omdat backend ontwikkelaars iets moesten uitproberen waardoor de backend van die versie niet meer werkt of niet meer compatibel is met de mobiele app. 

Voor een Flutter app, zetten we dus steeds twee keer (iOS en Android) 4 versies op = 8 keer ongeveer hetzelfde werk. Bij elk project opnieuw. We moeten je niet uitleggen waarom die template met dat script er gekomen is. 😉

Deze opzet hebben we onder meer voor onze RMDY Grow&Glow app gebruikt. Die versies zijn dan:

be.rmdy.glowandgrow
be.rmdy.glowandgrow.qa
be.rmdy.glowandgrow.dev

💡Na het opzetten van alle versies, start je met programmeren in een IDE.

2. Vier versies op 1 platform

Allright, we hebben dus 4 (of 8) versies van onze app. Die moeten ook allemaal beschikbaar zijn voor de klant, collega-developers, product owners, …

Je zou kunnen afspreken dat je 3 keer per week fysiek samenkomt en de nodige versie van de app installeert op de smartphone van wie ‘m nodig heeft. Of je zou ook iets leukers kunnen doen met die tijd en alle versies geautomatiseerd op een platform zwieren.

Daar waar een productieversie (voor de eindgebruiker) meestal in de App Store of Google Play zit, moeten of mogen de andere versies daar niet staan. Maar hoe krijg je dan die andere versies vlot downloadbaar tot bij iemand die ze nodig heeft? Daar zijn gelukkig tools voor! 🙌

Zowel Apple als Google hebben een versie van hun stores speciaal voor testversies van de apps: TestFlight en Google Play Console. Bij RMDY gebruiken we echter Visual Studio App Center – omdat we ook voor build servers en meer bij Microsoft zitten. Maar er zijn nog meer app distribution services zoals Firebase App Distribution en TestFairy.

In App Center zetten we erg gemakkelijk de verschillende versies – en al hun updates – beschikbaar voor wie toegang krijgt. Nieuwe business owner op het project? Een nieuwe developer die graag de app van 2 updates geleden uitpluist? Simpelweg het e-mailadres toevoegen et voila.

We kunnen ook bij een nieuwe build automatisch de app uploaden naar App Center. De gebruikers (vb. de tester) krijgen een melding van een nieuwe versie, downloaden die en kunnen ook verder aan de slag. 

💡De productieversie van onze Grow & Glow app staat ook in App Center, omdat het een interne applicatie is. Vooral Apple kan al eens moeilijk doen over niet-publieke apps in hun App Store – al die vervuiling, daar houden ze niet van. En gelijk hebben ze.

3.  Automatiseer met build server

De derde stap linkt de vorige twee stappen aan elkaar: we automatiseren dat nieuwe versies van de verschillende versies naar App Center gaan. Dat doen we met een build server (continuous integration server): die compileert, bouwt en test automatisch elke nieuwe versie en brengt het team op de hoogte.

Concreet: developer past een feature aan, die wijziging wordt gepusht naar GIT (version control system), de build server detecteert een nieuwe versie en ‘bouwt’ die tot een developmentversie terwijl ook al verschillende testen worden uitgevoerd. Die developmentversie komt uiteindelijk terecht in App Center. Ook dat gebeurt allemaal automatisch bij RMDY, behalve het publiceren van de productieversie wegens organisatiemanagement. Bij een nieuwe release van een app-versie gaat het namelijk vaak gepaard met communicatie, eventueel persbericht, mailtje naar de eindgebruiker, …

Ook dit nog

Hallo/Hello/Bonjour/Guten Tag

In al onze projecten hebben we meertaligheid van applicaties – dat heb je nu eenmaal in een land als België. Je kan teksten in je code schrijven, maar dan moet elke aanpassing manueel via een developer passeren. Dat wil niemand, toch?!

Daarom werken we met labels in onze code, voorbeeld: “hier komt de tekst met label Homepage_Title”. Onze code linkt met een translation management platform Localise. Daar staan alle labels in, met alle taalversies die je maar wil! De copywriter vult hier – mits controle van aantal tekens – alle copy en vertalingen in die ‘s nachts doorgestuurd wordt naar de developmentversie. En ook omgekeerd: komt er een nieuw label bij in de code, kan de copywriter de dag nadien de tekstuele waarde invullen.

De switch van taal is langs developerzijde erg gemakkelijk en snel – voor die copywriter niet zo want die moet natuurlijk wél elk woord vertalen. Ach, ieder z’n job hé?

Geen stabiel huis zonder architecturaal plan

Save the best for last: start een nieuwe project nooit zonder een technische architectuur op te zetten. Zorg ervoor dat de code van je user interface, business logica, … in aparte lagen of “folders” zit. Of zorg toch zeker dat de bedrijfslogica apart zit; gezien die zelden doorheen de jaren wijzigt, in tegenstelling tot de UI. Doe je dat niet, werk je al snel basically in een vuilnisbak waar alle code door elkaar ligt. Je past iets aan op plek A, maar je ziet niet dat dat invloed heeft op plek Q. En wees eerlijk: je herinnert je ongetwijfeld een project waar dat wél zo was en je hebt stilaan weer tranen in je ogen. 😉

Naast het vermijden van chaos en mental breakdowns, is een architectuur met duidelijke opdeling ook gewoon nodig als je wil Unit Testen. Geen duidelijke units, geen unit testing.

Bovendien is een goede applicatie-architectuur ook technologie-onafhankelijk: net zoals een tekst altijd een titel, inleiding en tussentitels heeft; heeft app architectuur ook altijd dezelfde opbouw. Dus als je binnen je bedrijf dezelfde architectuur voor al je mobiele projecten gebruikt, zijn je iOS of Android developers snel wegwijs in de opbouw als ze overschakelen naar Flutter.

Ziezo. Een kleine inkijk in hoe we bij RMDY op de meest developer-friendly manier een mobile Flutter project opstarten. 😉

Ook aan de slag met een efficiënt, transparant en gestructureerde app door idem team?
Hit us up. 👇

Stuur ons een mailtje en
let’s talk