Hallo allemaal!
Leuk dat jullie hier weer zijn om dit project te volgen. In deze post neem ik jullie mee in de planning voor de codestructuur van de app die ik aan het maken ben. Omdat dit mijn eerste eigen Flutter project is, neem ik veel informatie over van andere bronnen. Hierdoor leer je op een andere manier (dan je automatische piloot) kijken naar het opzetten van projecten. En wanneer dit bevalt kan je dat uiteraard inbouwen in je automatische werkwijze voor je volgende projecten!
Stappenplan App maken
In de vorige post van dit project1 heb ik de vereisten vastgesteld. In die fase beschreef ik wat de app moet hebben om de klant haar problemen op te lossen. Maar op technisch vlak is dan nog niets bepaald. Deze fase gaat over het technische vlak, namelijk wat zijn de technische stappen die nodig zijn om de app op te leveren. Voor dit project heb ik grofweg de App Development Workflow van Code with Andrea2 aangehouden.
Over de eerste twee stappen, Design en Database/Backend, kan ik kort zijn. Het Design zal een simpele lijstweergave zijn (de standaard ingebouwd in Flutter). En voor versie 1 (V1) hebben we gezegd: hardcoded practices (dus geen database) en er is ook geen backend nodig. Dat waren de eerste twee stappen al, maar de volgende stap is een stuk uitdagender!
De derde stap is namelijk het bepalen van de app architectuur. Nu is dit dus mijn eerste Flutter project en heb ik nog geen goed idee over wat de handigste app structuur voor een Flutter project is. Gelukkig werk ik ondertussen wel aan een andere Flutter app waarin we Flutter Blocs gebruiken. En in de voorbeelden van Flutter Blocs kwam ik een structuur tegen die mij aansprak3. Hieronder heb ik diezelfde structuur vertaald naar de app die ik aan het maken ben.
Opmerking: Onderstaande alinea’s zijn technisch, maar daar ontkom je niet aan bij het bepalen van de app architectuur :).
De Data Layer is, zoals de naam van de layer ook omschrijft, de connectie naar je onbewerkte data. Deze wil je het liefste zo generiek mogelijk houden en is vaak een simpele API om CRUD (Create, Read, Update, Delete) operaties uit te voeren. In de app Data Layer zitten twee componenten, de Daily Practices API en Hardcoded Daily Practices API. De eerstgenoemde is de generieke interface (een soort van blauwdruk van je verschillende implementaties). Als V1 heb ik vastgesteld dat de Daily Practices hardcoded en niet aanpasbaar zijn. Daarom hebben deze APIs voor V1 alleen een leesoperatie nodig. De specifieke implementatie hiervan wordt gedaan in de Hardcoded Daily Practices API.
De volgende laag is de Domain Layer. Hierin koppel je de data APIs in een repository. Je voegt hieraan zogeheten business rules toe om bijvoorbeeld data te filteren of in een bepaalde structuur door te geven aan je Blocs in de feature layer.
De repository layer geeft de data dus door aan je Blocs in de Feature Layer. Hierdoor fungeert je Bloc als brug tussen de data en de (User Interface) UI in je app. De Bloc bevat je business (b) logic (loc). Afhankelijk van acties van de gebruiker vraagt de Bloc data op uit (mogelijk verschillende) repositories. Hierdoor verandert de state van je Bloc. Deze verandering wordt opgepikt door de UI en daardoor past de UI van de app zich aan. Het grootste voordeel van deze structuur is dat de business logic en UI gescheiden zijn. Dit reduceert coupling en daardoor zijn de afzonderlijke onderdelen van je app in isolatie te testen en te gebruiken!
Nadat de app architectuur is bepaald, kan je samen met de vereisten een project board maken. In eerste instantie gebruikte ik Trello maar later dacht ik dat het handiger zou zijn om alles op 1 plek te hebben. Daarom ben ik overgestapt naar Github Projects4. Ik heb geprobeerd om het zo volledig mogelijk te maken, maar het zal vast zijn dat ik zaken ben vergeten. Dus dat vul ik in wanneer ik dat tegenkom. Het project board heb ik opgedeeld in verschillende onderwerpen (Test, UI, Flutter en CI/CD). En daaronder heb ik dan de verschillende taken bedacht en aangemaakt. Toen dat gedaan was kon ik beginnen aan de volgende stap, de CI/CD pipeline.
Door te beginnen met de CI/CD pipeline kan je zo vroeg mogelijk beginnen met testen. Omdat alles op Github staat gebruiken we in dit geval Github Actions voor onze (in eerste instantie niet CD) CI pipeline. De specifieke implementatie van de Github Actions zal ik in een volgende post vertellen.
De laatste stap is het uitvoeren van de taken op je project board! Ondertussen ben ik al begonnen. Doordat ik bij mijn vorige projecten een andere werkwijze aanhield, was even wennen. Maar eenmaal in het ritme gekomen ging alles voortvarend! Ik heb veel geleerd en veel van de taken zijn voltooid. Op dit moment ben ik vastgelopen op het notificatie deel maar wanneer dat werkt is V1 zo goed als af! Hopelijk lukt dat binnenkort!
Tot de volgende keer :)
Mees