Final Work: PlantCare

We zijn weer al een eindje verder in de ontwikkeling van mijn thesis. Om nog een overzicht te krijgen van de werking van het huidige systeem en wat er in de laatste maanden is behaald, wil ik dit in deze blogpost even overlopen. Om het probleem op te lossen dat ik in eerdere blogposts heb aangekaart en het doel van mijn thesis is, ben ik begonnen met het visualiseren van een architectuur die de functionaliteit kan voorzien, de "solution architecture". Dit visueel model dient als gids in de ontwikkeling en research proces voor mijn thesis. Deze werd meerdere keren aangepast wanneer er een fout was ontdekt in het model of een meer efficiënte oplossing werd gevonden. Figuur 1:  Solution Architecture Zoals je in de afbeelding hierboven kan zien, bestaat de solution architecture uit 2 hoofd onderdelen. Namelijk, de "actors" en het "systeem". Hierdonder zal deze 2 onderdelen verder toelichten. Actors De actors zijn externe entiteiten die c...

Before going into the specific solution implementations, the domain objects involved and how they interact were visualized in a domain model. These domain objects are the necessary elements involved in tackling the problem. They consist of users, plants, plant types, diseases, logs, classifications. Figure 14 below shows the visualization of these elements and the interactions between them as a domain model. However, this model was altered throughout the project and does not represent the final version. 7 Figure 12 : Sketch of problem domain model Domain Model It is the base for the data structure and design of the implementation. Since this model has such an important role, it is necessary to think this model through. Making a change in this step of software development can cost a lot of time as the whole system is built on top of it. This means that most of the time a redesign of this model influences many function...

Voor het starten met de ontwikkeling van de PlantCare App ben ik begonnen met het schetsen van 2 belangrijke initiële schema's het schema hierboven duid de originele simpele versie van het schermen diagram en de mogelijke flows van de gebruiker hierdoor. Er ontbreken hier nog een aantal pijlen namelijk hoe de gebruiker kan terug gaan van een huidig scherm en zijn er een aantal schermen/sub-schermen bijgekomen. Maar dit schema heeft als gids gediend voor dit project bij het ontwikkelen en het bedenken van verdere stappen in de ontwikkeling. Het schema hieronder wordt ook wel een domein model genoemd. Deze dient om een beeld te krijgen van de soorten informatie dat voor dit product een rol speelt en de relaties hiertussen. Het schema hieronder is opzettelijk niet te specifiek omdat dit erg afhangt van de implementatie en wat er mogelijk is met de technologie. Aangezien ik veel met nieuwe technologie en platformen werk was het beter om dit zo te laten tot een latere fase van ...

In deze versie van de app heb ik ondersteuning toegevoegd voor rotatie van het scherm waarbij de layout zich aanpast hieraan. Ook ondersteunt de app nu nederlandse taal, het vertonen van logs (nog niet het aanmaken). En zijn er wat fouten weg gewerkt. Synchronisatie tussen apparaten: Scherm rotatie verbeteringen: Tab scherm details & logs van gekozen plant (schuifbaar):

Hieronder een overzicht van de functionaliteiten die ik ondertussen heb geïmplementeerd Plant verwijderen (lang drukken) & plant details (kort drukken): Plant toevoegen (met camera en foto galerij): Gebruiker registreren:

Aanmelden & Registreren: Zoals het meestal gaat bij ontwikkeling, start ik met het ontwikkelen van het inlog en registratie scherm. Hiervoor heeft Firebase  een authenticatie service die perfect aansluit bij hun Firebase database systeem. en in de achtergrond gebruiker data bewaard en beheerd. Deze kan vervolgens in de back-end -, in verzoeken naar de database -, in authenticatie en validatie gebruikt worden. Voor de front-end is er gekozen voor een eenvoudig en duidelijk design. Als de gebruiker zich aanmeld dan blijft deze aangemeld tot hij zichzelf afmeld via een knop in de action bar (bovenste navigatie bar) of de app herinstalleert.  Plant Details & Plant overzicht: In de huidige versie van de app is het ook al mogelijk om planten te vertonen van een bepaalde gebruiker, ook heb ik al een "detail scherm" gemaakt waar de gebruiker details kan zien over de plant als hij op een plant drukt. Bij de ontwikkeling van de Plant overzicht heb ik gebruik g...

Aan het begin van de maand decmeber heb ik een simpele ERD (Entity Relationship Diagram) opgemaakt om de data te visualiseren die mijn app zal nodig hebben en de relaties hiertussen. Hierna ben ik begonnen aan een flow schets van mijn app. Dit heb ik gedaan zodat ik een overzicht had van de vooruitgang en om een ruw idee te krijgen van de werking van de app. Voor de communicatie tussen de database en de app had ik een aantal opties. SQL: De bekende en veel gebruikte SQL type database. Met deze soort database heb ik al ruim ervaring. Het vergt veel tijd om op te bouwen maar eenmaal dat deze opgebouwd en ingesteld is is het een krachtige tool. De reden van deze lange opstel tijd is omdat SQL databases een initieel database schema nodig hebben waar de data zich aan zal moeten houden om de werking te garanderen, terwijl bij NoSQL databases dit een dynamisch schema is voor ongestructureerde databases. SQL databases hebben ook een erg krachtige query taal, namelijk SQL(struc...