De Construction fase verliep niet zoals gepland. Er waren 8 constructieve uren per dag gerekend, iets wat niet is gehaald. Hierdoor werd het werk niet gehaald in de uren die er voor stonden en liep de planning uit. Dit is beschreven in H7.1.1 Ook de einddatum van het project was niet goed gepland, dit omdat er een verkeerde datum was gecommuniceerd die later werd bijgesteld, tijdens het proces. Achteraf bleek er toch nog wat meer tijd voor het maken van het project dan op voorhand was bedacht. De iteraties zijn wel gevolgd, alleen is er wel vertraging opgelopen.
In de iteraties zal getracht worden de volgende activiteiten te realiseren.
Deze iteraties verschillen wel met het oorspronkelijke plan. Dat plan was namelijk om eerst de applicatie te maken, dan de backend en daarna alles te gaan koppelen. Er is hierover verder nagedacht waarbij de conclusie is getrokken dat eerst een applicatie maken, dan de backend en dan hopen dat je alles goed aan elkaar kan koppelen een te groot risico zou gaan vormen voor de voortgang van de applicatie.
Hierdoor is besloten voor de onderstaande verdeling. Deze geeft telkens een applicatie die voldoende werkt om ingezet te kunnen worden en dekt een risico af dat er door omstandigheden te weinig tijd overblijft voor functionaliteit.
In de eerste iteratie zullen de volgende must‟s worden gerealiseerd: - Inloggen
- Backend werkend krijgen.
In de tweede iteratie zullen de volgende must‟s worden gerealiseerd: - Hulpvraag maken op basis van locatie
- Notificatie tijdstip mee verzenden
In de derde iteratie zullen de volgende must‟s worden gerealiseerd: - Locatie op Google Maps aangeven
- Op hulpvraag reageren
6.4.1 Iteratie 1
De eerste twee functionele eisen die zijn geïmplementeerd zijn het inloggen en het werkend krijgen van de backend. Allereerst is gestart met het inloggen gedeelte. Omdat er nog geen backend aanwezig is, zijn de XML‟s die worden gebruikt eerst hard in de code gezet.
De XML‟s zorgen voor de dataoverdracht tussen de server en de applicatie. Ze hebben een eenduidig formaat en dienen aan ontwerpregels te voldoen. Deze regels zijn opgenomen in zogenaamde XSD bestanden. Deze code hiervan is uitgewerkt en te vinden in de bijlagen. Hierdoor kan ook goed worden getest of het klassendiagram, en dus de flow, in de applicatie zelf goed vooraf is bedacht. Bij het opzetten van het klassendiagram is vooraf bedacht welke klassen er nodig zijn om de functionaliteit te realiseren die gewenst is. Een functionaliteit zal dus door verschillende klassen lopen en dat is de flow die de applicatie in zich heeft.
Dit bleek dus niet het geval te zijn. Er miste nog handler klassen in het klassendiagram. Deze zijn toegevoegd. In de bijlage is een rapport opgenomen met alle klassen die in de applicatie zitten.
Logica - Notificatie service voor snelle hulp Uitvoering
page 32 of 39
De uiteindelijke flow door de applicatie zelf is de volgende:
Vanuit de applicatie komt een aanvraag om in te loggen. Deze aanvraag maakt via de writer klasse een XML met de gegevens die zijn ingevoerd door de gebruiker. Deze writer wordt door de reader gestuurd naar de webserver. Deze reader ontvangt ook het resultaat van webserver. Binnen de reader zal de XML worden geparsed door een handler. Deze handler geeft een XMLResponse terug aan de reader welke het resultaat teruggeeft aan klasse die de aanvraag deed. Het figuur hieronder geeft dit schematisch weer.
Figuur 10 Flow applicatie
Met de scheiding van de taken, schrijven, lezen en behandelen wordt de code gescheiden gehouden wat de herbruikbaarheid en onderhoudbaarheid ten goede komt.
Tijdens de ontwikkeling van het inloggen zijn ook het request en response XSD aangepast. Deze XSD valideert de XML. Nadat het inloggen werkt met de XML hard in de code geschreven, werd het tijd om aan de backend te gaan werken.
De backend is een PHP webserver en een MySQL database server. Deze twee zijn op één server geïnstalleerd. De bedoeling van dit project is een werkende applicatie. De focus ligt op de applicatie en niet op de backend. Daarom is de backend heel simpel gehouden en enkel die taken te laten doen die ook zijn bedacht. Namelijk het kunnen verwerken van een XML en een response teruggeven in de vorm van een XML.
Tussen de applicatie en de webserver wordt een POST request gestuurd waarin de XML staat en het type aanvraag wat wordt gedaan. Bijvoorbeeld: login.
Doormiddel van dit type maakt de XMLFactory klasse van de webserver de goede parser aan in de webserver. Deze verwerkt de XML en genereert een XML die als response wordt terug gestuurd.
Om de webserver goed in te kunnen richten, en dus ook goed te kunnen testen, is de webserver ook afzonderlijk gebouwd. De POST request wordt nagebootst zodat eventuele fouten niet door de communicatie tussen de applicatie en de webserver konden optreden.
Door telkens de request in de code te zetten tijdens het testen is er geen kans geweest op extra vertraging tijdens het ontwikkelen door communicatieproblemen. Dit heeft het hele proces bespoedigd.
Logica - Notificatie service voor snelle hulp Uitvoering
Voor het inloggen is een database nodig met een tabel met de gegevens voor het inloggen. De tabel zit er als volgt uit:
Van de gebruikers wordt een ID aangemaakt en de gebruikersnaam en wachtwoord opgeslagen. Het wachtwoord is versleuteld als: SHA1(MD5(wachtwoord)+MD5(wachtwoord)). Er is voor deze versleuteling gekozen omdat deze niet heel veel wordt gebruikt en dat er hiervoor dan geen tabellen zijn te vinden waarbij staat dat hash X gelijk is aan wachtwoord X. Hierdoor is het wachtwoord voldoende beschermd in het geval dat iemand toegang krijgt tot de database die daar geen toegang tot heeft.
Als iemand succesvol wordt ingelogd, wordt er een rij in de tabel tokens aangemaakt. De combinatie van userID, deviceID en token wordt gehasht mee terugverzonden. Door deze hash hoeft een gebruiker niet telkens in te loggen. De relatie die tussen users en tokens is gelegd heeft een NO ACTION relatie op de update en CASCADE op de delete.
Voor deze twee functionaliteiten, het inloggen en het werkend krijgen van backend, is een week gepland. Dit is echter niet gehaald. Er was wel ervaring met het ontwikkelen van een Android applicatie, maar deze ervaring moest weer worden opgefrist. Daarnaast was er nog geen ervaring met het verwerken van een XML in Android. Ook is er vertraging in het ontwikkelen ontstaan door problemen met de webserver. Het was de bedoeling om een Linux webserver op te zetten. Dit door middel van een VirtualBox op de Windows ontwikkelcomputer. Door technische problemen veroorzaakte VirtualBox tot drie keer toe een vastlopende laptop. Daarna is besloten om de webserver gewoon onder Windows te laten draaien door middel van XAMPP. Dit is een platform wat direct Apache2, PHP 5.3 en MySQL 5.0 installeert en conFiguurert. Hierdoor zijn de vijf werkdagen om te ontwikkelen in deze iteratie onvoldoende. Ook het verslaggedeelte van twee werkdagen bleek te kort. Er is namelijk kort voor de Construction fase begonnen aan het schrijven van dit document. Hierdoor konden de twee werkdagen niet worden ingezet om over iteratie 1 te schrijven.
6.4.2 Iteratie 2
Twee functionaliteiten staan gepland in deze iteratie. Namelijk die van een hulpvraag aanmaken en een tijdstip van notificatie mee verzenden. Allereerst is begonnen met het ontwikkelen van een hulpvraag aanmaken. Dit proces bestond uit twee aparte delen: Namelijk het maken van het gedeelte in de applicatie en het maken van de verwerking in de backend. Allereerst is begonnen met het realiseren van de backend implementatie. Zodat het maken van hulpvraag in de applicatie op een goede manier kon worden uitgevoerd. Een hulpvraag dient te worden opgeslagen in de database. Hiervoor zijn de volgende tabellen gemaakt:
Logica - Notificatie service voor snelle hulp Uitvoering
page 34 of 39
vastgestelde XML voldeed voor het maken van deze functionaliteit. Na het maken van het backend gedeelte van de functionaliteit moet ook de kant van de applicatie in elkaar worden gezet. Hiervoor is een menu toegevoegd waarbij het item „Nieuw hulpvraag‟ is toegevoegd. Als daarop wordt geklikt, wordt er een check gedaan of de gecachede items nog up-to-date zijn. Zo niet dan zullen de hulpvragen en categorieën opnieuw worden ingeladen. Anders wordt de cache opgevraagd. Vervolgens komt er een scherm naar voren waar je eerst een categorie moet selecteren en daarna een hulpvraag kunt selecteren. Nadat dit is gedaan wordt kan men de hulpvraag inschieten.
Nadat de hulpvraag aanmaken functionaliteit is geïmplementeerd kwam het item „Notificatie tijdstip mee verzenden‟ aanbod. Er is besloten om „Locatie op Google Maps aangeven‟ te ruilen met „Notificatie tijdstip mee verzenden‟. Dit omdat de locatie aangeven past bij het maken van een hulpvraag en dat het tijdstip van de notificatie mee verzenden heel goed past bij de functionaliteit van de derde iteratie. Namelijk die van „Op hulpvraag reageren‟.
Er kan immers enkel op een hulpvraag worden gereageerd als men een notificatie heeft gehad dat er een hulpvraag in de buurt aanwezig is.
Het scherm van een hulpvraag aanmaken is uitgebreid met een „verder‟knop waarbij een Google Maps kaart wordt geladen. Daar wordt het punt, waarvan de applicatie denkt dat je bent, aangegeven. Door op de juist locatie te klikken kan dit punt worden aangepast. Dit moet wel binnen een redelijk straal van de verwachte locatie liggen. Na de check of de locatie die je aanklikt wel in de buurt ligt, zal de waarde die is aangegeven worden mee verzonden aan de backend.
Deze iteratie ging ook niet altijd zo soepel als gepland. Voor het aspect van een goede GUI was een lastig stuk. Hieraan is wel wat meer tijd besteed dan verwacht. Er is moeilijker over de GUI gedacht dan achteraf nodig was. Denk hierbij aan het manipuleren van data en de GUI laten aanpassen op gedrag van de gebruiker. Dat heeft tijd gekost.
6.4.3 Iteratie 3
„Notificatie tijdstip mee verzenden‟ is naar iteratie drie verplaatst. De op te leveren functionaliteiten in deze iteratie zijn dus geworden: Het „Notificatie tijdstip mee verzenden‟ en „Op hulpvraag reageren‟.
Om een notificatie naar een hulpverlener te kunnen versturen moet eerst een service worden gemaakt die wordt gestart als het inloggen succesvol is verlopen.
Deze service zal elke minuut de locatie updaten van de persoon die is ingelogd. Zodoende weet het systeem twee dingen: Welke mensen waar aanwezig zijn en welke personen hun internet aan hebben en dus een notificatie kunnen ontvangen.
Elke minuut zal op de webserver een script draaien die kijkt of er nieuwe hulpvragen zijn gemaakt. Per hulpvraag zullen de gebruikers die in de buurt zijn, worden gezocht en zal er via een Google service een push bericht worden gestuurd. In dit bericht staat het tijdstip van de hulpvraag.
Als een notificatie binnenkomt, zal de applicatie de betreffende hulpvraag ophalen. Deze wordt in een lijst getoond. Door op een hulpvraag te klikken, komt er meer informatie beschikbaar. In dit scherm is de mogelijkheid om te reageren op de hulpvraag.
De Google services aanspreken maakte deze iteratie wat langer dan gepland. Het duurde even voordat alles werkte zoals het moest gaan werken. Dit door kleine fouten zoals verkeerde syntax, vergeten variabelen of meegegeven verkeerde variabelen.
Logica - Notificatie service voor snelle hulp Uitvoering