Terug naar developement-overzicht
Ik heb een poos geleden voor de Geluksroute een Android-app gemaakt, en gepubliceerd. In de tussentijd is er op het gebied van Android-developement nogal wat veranderd. Zo is er nu room: een ORM en Compose, een nieuwe manier voor het maken van UI, co-routines. Als programmeertaal is nu Kotlin beschikbaar.
Bij het ontwikkelen van de eerste versie van de app gebruikte ik cursors voor de database-io, en activities/fragments met XML-layouts voor de UI. Fraai vond ik het niet: de cursor API, verpakt in een service, was in mijn ogen overengineered, en de implementatie van vooral fragments was onhandig, met name als je die in een navigatie-stack had, en device-rotation ondersteunde.
Nu is alles anders... Room werkt veel lichter dan de cursors, en is meer een ORM. Jetpack Composition introduceert een nieuwe manier voor het maken van user-interfaces als vervanging voor XML-views binnen fragments of activities. Nu is anders niet altijd beter, zeker bij Google. Omdat ik nooit blij was met de oude werkwijze, ga ik dit toch verkennen. Compose is echter nog niet release-waardig, daarom gebruik ik nu canary- of betaversies van Android Studio, en kan de app pas gereleased worden als Compose uit Beta is. Dat zou volgens aankondigingen in juli kunnen zijn. Nog even afwachten dus.
De app die ik ga herbouwen is te vinden in de Play-store. De functionaliteit blijft gelijk: het gaat nu alleen om het actualiseren van de code. In een later stadium wil ik ook functionaliteit wijzigen. Nu is dat niet aan de orde. Voor meer informatie over het doel van de app en de gedachte achter Geluksroute, zie hier.
Android-developement werd traditioneel gedaan in Java. Google heeft dat veranderd, en nu is Kotlin de eerste keus. Jetpack Compose vereist het zelfs. Ik vind dat een verbetering. De Java-syntax is naar mijn mening omstandig, de support voor generics was beperkt, lambda´s konden alleen via een onhandige omweg en met Kotlin komen Co-routines, de nieuwste manier voor asynchroon programmeren.
Java is intussen ook uitgebreid, maar vanwege de Compose-ondersteuning was voor mij de keus makkelijk. Als je al Java en C# kent, dan zijn de syntax en concepten achter de taal niet zo moeilijk te leren. De compactere syntax betekent ook minder code regels, en (wat) sneller werken.
Met Room is er nu een standaard ORM-framework beschikbaar in Android. Ik ben tot dusver geen bijzondere mogelijkheden ervan tegen gekomen, maar het integreert mooi met de andere frameworks en Compose, dmv Flow.
Asynchroon programmeren is een must in mobile development. Om een vloeiende gebruikerservaring te bieden moeten tijdrovende operaties zoals netwerk-calls en database-calls asynchroon t.o.v de UI uitgevoerd worden. Dit was in het ´oude´ Android een gedoe, omdat het wel eens voor kwam dat de ontvanger van de data verdwenen was als de asynchrone operatie klaar was. Een fragment wordt weggegooid en opnieuw gemaakt bij een configuratie-wijziging. Roteren van rechtop naar dwars veroorzaakte zo´n configuratiewijziging. Een data-operatie die liep tijdens zo´n wijziging verliest dan zijn bijbehorende fragment. Vaak crashte de app dan.
Google heeft voor dat probleem ViewControllers in het leven geroepen. Die blijven bestaan als een fragment of activity opnieuw wordt opgebouwd, en worden weer opgepikt door de nieuwe objecten (MVVM architectuur).
Jetpack Compose is een nieuwe manier voor het beschrijven van de UI in een app. Dat gebeurde tot dusver met layout-declaraties in XML-formaat die werden getoond in een activity of fragment. In principe is dit nu overboord gezet. Je kunt nu de UI-componenten geheel buiten die structuur beschrijven. Het blijft overigens mogelijk om fragments met XM_layouts te gebruiken, en ook fragmants met een Compose UI zijn mogelijk.
De app-herbouw is ook een goed moment om dependency injection te gaan toepassen. Daarvoor is nu Hilt+Dagger als hulpmiddel beschikbaar. Dependency injection bestaat natuurlijk al een tijdje, maar was op Android geen gemeengoed toen ik de eerste versie van mijn app bouwde. Inmiddels is het dat wel, en wil ik ook daar ervaring mee opdoen.
Tests zijn niet echt een nieuw deel van de Android-toolset. Ik had er echter in de vorige app geen gebruik van gemaakt, en besloot om dat nu vanaf het begin wel te doen. Ik heb al gemerkt dat het runnen van de tests goed werkt om te controleren of de build-omgeving goed is. Met de Canary-versie van Android Studio wil nog wel eens wat misgaan. Ook de dependencies kloppen niet altijd, en je hebt er aardig wat nodig.
Ook kan ik hier dingen uitproberen, zoals db queries, waarvan ik niet zeker ben of ze goed werken. Unit-tests uitvoeren gaat sneller dan steeds weer de app runnen om een kleinigheid te proberen.