Vier jaar geleden heeft Pinch besloten Flutter toe te voegen aan haar portfolio met een toegewijd team naast hun bestaande native Android- en iOS-ontwikkelingsteams.
Thomas stond aan de wieg hiervan en legt uit hoe dat allemaal tot zijn werking is gekomen. In zijn blog benadrukt hij hoe Flutter, in tegenstelling tot andere cross-platform tools, geen gebruik maakt van webpagina’s of een bridge naar native componenten, maar in plaats daarvan een canvas biedt om alles te tekenen wat je wilt. De Flutter-engine optimaliseert dus de prestaties voor soepele animaties en responsiviteit, waardoor het mogelijk is om op verschillende apparaten te draaien. Thomas bespreekt ook de evolutie van Flutter-projecten bij Pinch en hoe het team BlocProvider begon te gebruiken, een bloc-architectuur gecombineerd met rxdart, om streams van gegevens voor invoer en uitvoer te bieden. Wil je meer weten, lees hieronder de volledige blog.
Toen ik (Thomas) voor het eerst begon met ‘mobile development’ in 2014, had ik nooit kunnen denken dat ik zou eindigen als ‘teamslead’ van een cross-platform oplossing. Ik begon als Android-ontwikkelaar, probeerde de likes van iOS en Windows Phone uit in de beginjaren, maar bleef bij Google voor de lange termijn. Op een gegeven moment probeerde ik Xamarin uit, en binnen Pinch deden we zelfs React Native voor een van onze klanten, maar beide oplossingen misten die native touch, het uiterlijk en gevoel, de ontwikkelaars ervaring. De cross-platform tools hadden altijd wel wat eigenaardigheden.
Het was na een jaar of 2 bij Pinch dat ik een eerste glimp opving van Google’s UI-toolkit: Flutter. Onze Android-lead probeerde tijdens een hackathon te werken met Flutter, liet zijn bevindingen zien en was onder de indruk, maar nog niet overtuigd. Het was destijds nog in Alpha, dus we hielden het in de gaten en probeerden het opnieuw uit toen het (bijna) stabiel was. Samen met een van mijn collega’s, John van der Vaart, probeerde wij gedurende 2 dagen een bestaande app opnieuw te schrijven in Flutter, zonder kennis of ervaring. Na 4 jaar kan ik makkelijk zeggen dat we het beter hadden kunnen doen, maar destijds verrasten we onszelf over hoe gemakkelijk het was om Flutter op te pakken, hoe snel we resultaten zagen, hoe het uiterlijk en gevoel je zou misleiden om te denken dat het native was in plaats van een cross-platform tool, en hoe prettig de ontwikkelaars ervaring was! We waren behoorlijk verwend met Kotlin, maar hoewel Dart aanvoelde als een stap terug in vergelijking met Kotlin, was het gemakkelijk en prettig om mee te werken! Er waren overeenkomsten en een enorm potentieel.
Uiteindelijk heeft onze demo het management van Pinch overtuigd en zo is de Flutter-trein bij Pinch in gang gezet. Pinch is van nature een bedrijf dat zich focust op native app-ontwikkeling en hoewel we steeds nieuwe ideeën uitproberen en bijvoorbeeld React Native een kans hebben gegeven, is gebleken dat niets in de buurt komt van native mobiele apps. Toch konden ze de vooruitgang die we in slechts twee dagen hadden geboekt niet negeren. De look and feel was zo goed dat het moeilijk was om te zien dat het geen native app was. We hebben toen een klant gevonden die deze avontuur met ons wilde aangaan en in 2019 hebben we onze eerste productie-app live gezet! Daarna volgden meer klanten en inmiddels is Flutter een toegewijd team binnen Pinch, naast de native Android- en iOS-ontwikkelingsteams die we altijd al hadden 💪
Waarom zal Flutter blijven bestaan?
Cross-platform oplossingen zijn niet nieuw in de wereld van mobiele ontwikkeling. We begonnen met web varianten zoals Ionic en Cordova: mooi en makkelijk, vooral als je een achtergrond hebt in webontwikkeling, maar ver van het native uiterlijk. Deze oplossingen waren voor Pinch altijd een makkelijke afwijzing, simpelweg omdat we nooit die kwaliteitsapp zouden krijgen die we beloven te leveren.
Toen kwamen we in de wereld van het bridgen naar native componenten. Hier komen cross-platform tools als Xamarin Forms en React Native om de hoek kijken. Zeker een goede stap voorwaarts en het proberen waard. Voordat we Flutter gebruikten, hebben we een productie-app gemaakt met React Native en hoewel het veelbelovend leek, had het een aantal eigenaardigheden waardoor we er uiteindelijk vanaf hebben gezien. Toen we React Native gebruikten in 2019, waren er nogal wat prestatieproblemen, zelfs met eenvoudige dingen zoals het tonen en scrollen van een lijst in sommige gevallen. De ontwikkelervaring was ook niet geweldig: debugging was behoorlijk moeilijk en ik hoef niet veel te zeggen over Javascript versus talen als Kotlin of Swift, toch?
Maar waarom is Flutter zo anders dan deze andere tools, waarom geeft het ons als native-first bedrijf vertrouwen? Flutter gebruikt geen webpagina’s of bridge naar native componenten. In plaats daarvan geeft Flutter je gewoon een canvas en de Flutter-engine tekent alles wat je wilt op dat canvas. Alles gebeurt binnen het Flutter-framework! Dit is precies waarom Flutter ook gemakkelijk op andere apparaten kan draaien: mobiel, desktop, web, smartwatches, embedded systemen, zolang we het Flutter-canvas hebben, zal het vergelijkbaar zijn met elk ander platform vanaf dat moment! (ja, dit is een zeer vereenvoudigde kijk op apparaat ondersteuning, sorry Google 🤓).
Afgezien van de UI betekent het feit dat alles wordt uitgevoerd in een engine die speciaal is gewijd aan Flutter, ook dat de prestaties zijn geoptimaliseerd om zo soepel mogelijke animaties en responsiviteit, iets waar native apps meestal het beste in zijn. Win/win! Het gebruik van Flutter leidt tot een zeer goede gebruikers ervaring èn met een uitstekende developers experience. Zo werkt debugging zoals je zou verwachten van native, we kunnen zelfs een krachtige IDE zoals Android Studio gebruiken voor ontwikkeling, en Dart evolueert echt als programmeertaal, en wordt net zo goed als Kotlin en Swift.
Vanaf de basis begonnen
We hebben sinds 2019 een lange weg afgelegd met de Flutter-projecten. Het eerste waar we aan denken als we nadenken over hoe Flutter-ontwikkeling en onze projecten zich hebben ontwikkeld, is een vrij actueel onderwerp binnen de Flutter-community: architecturen.
We begonnen met bloc, of liever gezegd BlocProvider. Gecombineerd met rxdart kwamen we tot iets wat leek op wat we gewend waren op Android: ViewModels en LiveData. Een Bloc was een eenvoudige klasse die op dat moment niets uitbreiden of implementeren en bevatte onderwerpen om streams van gegevens te hebben, zowel voor input als output. BlocProvider bood deze blocs aan je widget-tree, net zoals je nu blocs en cubits zou gebruiken. We gebruikten het op deze manier in onze eerste paar projecten en het werkte behoorlijk goed, niets om over te klagen! Ik heb wel andere dingen uitgeprobeerd: Provider, Riverpod, GetX, maar die ‘klikten’ nooit echt in mijn hoofd. Ik heb op een gegeven moment Redux gebruikt voor een van onze klanten, wat ook een tijdje niet werkte 🤓, maar het gaf wel een betere vorm van stabiliteit aan het project, de scheiding was duidelijk en de code was redelijk eenvoudig te testen. Uiteindelijk besloten we voor de bloc-pattern te gaan die we tegenwoordig gebruiken, waarbij we voornamelijk cubits gebruiken in plaats van blocs, en we vinden het nog steeds erg prettig.
Andere hoogtepunten in onze Flutter-reis? Kijkend naar dependency injection begonnen we met GetIt, wat meer een service locator is, maar oké. We begonnen het te gebruiken in ons allereerste project en implementeren het nog steeds in de nieuwste, geweldige pakket! Networking is iets wat we altijd deden met Dio. Later voegden we Retrofit toe aan de mix en nu gaan we over op de Flutter Favorite Chopper. Het laatste wat ik zeker wil benadrukken is Melos: een tool om multi-package projecten gemakkelijk te beheren. Onze projecten zijn meestal opgesplitst op een schone manier: presentatie, domein, gegevens, gegevens bronnen, enz. Door deze in aparte pakketten te plaatsen, wordt de scheiding verbeterd, en Melos maakt het echt gemakkelijk om al die pakketten te beheren. Ik zou het aanraden!
Waar staan we nu met Flutter?
We zien veel verbeteringen: een nieuwe rendering engine, 3D-ondersteuning, verbeteringen voor Flutter web, ondersteuning voor nieuwe architecturen en de constante verbeteringen van Dart, maar wat levert het ons op?
Het is moeilijk te zeggen hoe de toekomst eruit zal zien: ik zal Google’s Fuchsia OS altijd aan de lijst toevoegen, aangezien Flutter het ondersteunt, maar wie weet wanneer dat meer gebruikt zal worden. Tenminste, we zagen er al een glimp van bij de Nest Hubs, toch?
Component-based development zou al een ding kunnen zijn en zal naar mijn mening blijven groeien. Dit zal van groot nut zijn, vooral voor grotere bedrijven die meerdere apps hebben die dezelfde componenten, styling of wat dan ook gebruiken. Door een eenvoudige functie zoals een inlog flow of uw UI-kit in een apart, zelfstandig pakket te extraheren, kunt u deze hergebruiken in uw apps: Flutter, native, web, noem maar op! Maak één keer, onderhoud één keer, minder werk, meer consistentie 👌
Last but not least: ik ben ook nieuwsgierig naar de 3D-ondersteuning die werd getoond op Flutter Forward 2023. Ik weet niet zeker of game development in 3D een ding zal zijn met Flutter, maar wat dacht je van Augmented Reality? 😏
