Hoe ontwerp je een app? Wat zijn je uitgangspunten? Wat zijn de verschillende stappen? Of te wel, hoe kom je van een idee naar een €€€ opleverende app? Welkom bij mijn tweede blog in de serie hoe honkbal mij heeft geraakt.
Disclaimer: mijn gedachtenprocessen zijn de mijne, mijn gedachtesprongen werken voor mij, your mileage may vary…
Om iedereen weer up to speed te brengen. Ik ben een app aan het bouwen om te gebruiken bij honkbal waarbij we tijdens de honkbal trainingen verschillende statistieken van de pitchers gaan bijhouden.
Hoofdprocessen
Ik begon, zoals ik meestal m’n testprojecten ook aanpak, met het begrijpen van de hoofdprocessen en welke verandering en/of uitbreiding die men wil. Als je dit inzichtelijk hebt vallen de benodigde kwaliteitsattributen ook snel op hun plek is mijn ervaring.
In dit geval waren de hoofdprocessen nog niet beschreven, ik had tenslotte een blanco IDE om te vullen. Bij het bepalen van deze processen, werkte ik meteen ook de “hoe” uit in de code.
Ik had nog daarbij wel een andere “Hoe” in gedachten, ik wilde namelijk geen hardcoded variabelen (een contradictie ik weet het). De programmatuur moest zodanig gebouwd worden dat het kan schalen (kwaliteitsattribuut: schaalbaarheid). Daarvoor maak ik gebruik van Object Oriented Programming zoals Java dat kent.
RecyclerView
Het eerste proces om uit te werken werd dan ook het vastleggen van de gegevens van de spelers. Welke data heb je daarvoor nodig? Ik stelde mijn lijstje op: Naam, e-mail adres, welke arm gooit de speler mee en is de speler (nog) actief? Check, dit moet het gaan worden.
Dus ik maak een tabel aan waar je data per speler in zet, maar… de data moet ook getoond worden op je telefoon/ tablet. Hoe doe je dat? Na wat onderzoek, bleek de RecyclerView het handigst omdat deze weinig systeemresources gebruikt. Ik had nog nooit met deze view gewerkt in Java, dus Google en Youtube zijn m’n beste vrienden geworden. Naast het tonen, wil je hier tevens de flow van data in je app onderkennen zodat je deze ook goed kan testen.
Data
Daarna volgde al snel het proces vastleggen van de data tijdens een trainingssessie. Dat vereiste nogal wat werk, omdat ik ook rekening wilde houden met situaties dat iemand per ongeluk de app halverwege een sessie afsluit (kwaliteitsattributen: continuïteit, herstelbaarheid). Dus moeten het tussendoor opslaan van de data (kwaliteitsattribuut: gebruikersvriendelijkheid) en tussentijds voortgang tonen van het aantal pitches en het percentage slagballen weergeven mogelijk zijn. Mocht onverhoopt de app tussentijds afgesloten worden, dan dient het scherm weer op te bouwen alsof er niets is gebeurd. Dat vereiste weer het verder uitdenken van sub-processen om data integriteit te bewerkstelligen.
Tenslotte moet er als de sessie klaar is een samenvatting worden opslagen voor een eerste snelle analyse. Of te wel, rekening houden met verschillende scenario’s die als gevolg hebben dat je code-base in korte tijd explodeert.
