FACULTEIT INGENIEURSWETENSCHAPPEN

P R O B L E E M O P L O S S E N E N O N T W E R P E N , D E E L 3

CWB1-0809

Mansour NaimPeeters KirstenScheir Marijn

Smets LaurensStas Nils

Volders Simon

GeoMedia-Eindverslag-

Co-titularisDuval Erik

BegeleidersBoucke NelisFrederix Yves

Haesevoets RobrechtTernier Stefaan

Vandeputte Bram

A C A D E M I E J A A R 2 0 0 8 - 2 0 0 9

Inhoudstafel

Inhoudstafel................................................................................................................................................21. Inleiding.................................................................................................................................................32. Brainstorm..............................................................................................................................................43. Productomschrijving..............................................................................................................................6

3.1 Korte beschrijving van het systeem.................................................................................................63.2 Use cases..........................................................................................................................................63.4 Ervaring............................................................................................................................................9

4. Technologie..........................................................................................................................................104.1 GWT...............................................................................................................................................104.2 Android...........................................................................................................................................10

5. Ontwerp................................................................................................................................................115.1 Ontwerpbeslissingen......................................................................................................................11

5.1.1 Media toevoegen.....................................................................................................................115.1.2 Meerdere mediaobjecten van dezelfde soort...........................................................................115.1.3 Wanneer foto’s weergeven......................................................................................................115.1.4 Opnieuw muziek samenstellen................................................................................................11

5.2 Architectuur....................................................................................................................................125.3 Klassediagram................................................................................................................................135.4 Database..............................................................................................................................................................175.5 Ervaring..........................................................................................................................................17

6. Implementatie.......................................................................................................................................18

6.1.1 Database..................................................................................................................................186.1.2 Activities versus klassen.........................................................................................................186.1.3 ID3, MusicService & Notifications........................................................................................186.1.4 StatusProvider.........................................................................................................................196.1.5 API-keys & LocationManager................................................................................................19

7. Zelfevaluatie.........................................................................................................................................208. Vakintegratie........................................................................................................................................219. Besluit..................................................................................................................................................2310.Appendix: geleverde werk..................................................................................................................25

1. Inleiding

Fototoestellen, GSMs, PDA's en tal van andere apparaten worden steeds meer voorzien van GPS. Hiernaast is er de opmars van draagbare mediaspelers zoals de iPod of Zen. In dit project worden deze twee trends gecombineerd. De opdracht: een applicatie ontwikkelen voor een smartphone die het afspelen van media laat beïnvloeden door de locatie waar men zich bevindt.

In dit verslag wordt weergegeven hoe deze opdracht concreet werd ingevuld en wat de moeilijkheden hierbij waren. Een eerste deel handelt over de productomschrijving. Er wordt duidelijk omschreven wat de belangrijkste features van het programma zijn. Het tweede deel beschrijft hoe het ontwerp tot stand is gekomen. In een derde deel wordt de implementatie en vooral de problemen hiermee nader besproken.

2. BrainstormOmdat P&O een open project is, is het belangrijk dat vooraf verschillende ideeën op tafel werden gelegd. De opdracht van de eerste teamzitting was dan ook een brainstorm met het hele team. Hierin was het minder belangrijk dat de ideeën concreet uitvoerbaar waren, het voornaamste was dat de opdracht vanuit verschillende standpunten werd benaderd zonder zich al zorgen te maken over de technische kant van het verhaal.

2.1 Mindmap

Figuur 1: Mindmap brainstorm

2.2 Verwerking

In overleg met de opdrachtgever maakten we dan een selectie van de ideeën. Deze werden dan verder uitgewerkt en geordend aan de hand van een voorkeurslijst (zie tabel 1).Een eerste idee was de creatie van virtuele stickies, die gebruik maken van YouTube. De gebruiker van de applicatie maakt een filmpje, neemt een foto op en koppelt dat media-item aan de plaats waar het gemaakt is. Wanneer een andere gebruiker vervolgens voorbij die plaats komt, ontvangt hij een melding die zegt dat er op deze locatie een media-item aanwezig is. Tenslotte kan hij zelf beslissen om het media-item al dan niet te bekijken.

Een andere invalshoek was het maken van GPS-games. De gebruiker zou zich kunnen inschrijven om deel te nemen aan een tikspel, een soort “gotcha”. Hij krijgt dan een melding waarin staat welke persoon hij moet tikken, terwijl hij zelf ook een prooi is (ook hij moet worden getraceerd en getikt door een andere gebruiker). Helaas was hier het media-aspect niet genoeg aanwezig en werd dit idee afgekeurd. Verder was er de gedachte om informatie te geven aan de gebruiker van plaatsen waar hij in

de buurt is. Deze informatie kan van heel uiteenlopende aard zijn, bv. openingsuren van culturele gebouwen, de kaart van een café, de film top-10 vanuit de plaatselijke bioscoop.

Fotoroutes leken eveneens een leuk en praktisch principe. Hierbij kan de gebruiker een wandeling maken, tijdens deze tocht foto's trekken van plaatsen waar hij voorbij komt, en de route dan opslaan aan de hand van de foto's (en eventueel coördinaten). Deze route kan dan worden gedeeld met familie of vrienden, of de route kan op een site geplaatst worden zodat elke internetgebruiker de route kan downloaden en uitvoeren.

Een laatste idee was een datingservice te maken. De gebruiker heeft een profiel met daarop persoonlijke gegevens over zijn persoonlijk leven, en kan ook voorkeuren ingeven. Als hij dan een persoon voorbijloopt, die zelf ook een profiel heeft en die voldoet aan zijn eisen, krijgt de gebruiker een melding en kan hij zijn slag slaan.

Elk idee werd beoordeeld op vier eisen die de opdrachtgever stelde. De verschillende eisen hebben een prioriteit die weergegeven wordt door er een gewicht aan toe te kennen. Tabel 1 geeft de analyse van deze, en enkele andere ideeën met behulp van de vooraf bepaalde gewichten weer.

Tabel 1: Analyse van de weerhouden ideeën m.b.v. gewichten

Hieruit bleek dat de fotoroute het beste zou passen binnen de opdracht. Daarop werkten we in team dit idee verder uit. Hieruit ontstond een eerste ruwe schets van wat later ons programma zou worden. Figuur 2 in bijlage is een mindmap waarin deze werd gevisualiseerd.

2.3 Ervaring

Het is duidelijk geworden dat een breinstorm bij aanvang van een project zeer productief kan zijn. Het was ook goed om eerst even “de regels” toe te lichten zodat de brainstorm vlot kon verlopen. Want bijvoorbeeld het uiten van kritiek of praktische bezwaren doen we vaak als reflex en dit komt de creativiteit absoluut niet ten goede.Iets wat misschien over het hoofd wordt gezien, is dat je ook je eigen ideeën niet mag bekritiseren/censureren. Onrealiseerbare ideeën, kunnen bij andere mensen immers nieuwe gedachten oproepen. Als je jezelf echter al het zwijgen op had gelegd, zou deze stap niet hebben plaatsgevonden. Het is ook belangrijk om zovéél mogelijk ideeën op te noemen en die tot het uiterste uit te puren met alle mogelijke associaties. Achteraf kan men immers behouden wat men wil en dit combineren tot een eerste ontwerp van het project. We vonden het ook een goed idee om een verplichte pauze in te lassen tussen brainstorm en verwerking. Hierdoor moest je even weer afstand nemen om dan met een vernieuwde, heldere blik te kunnen evalueren. Dit hielp goed om de betere van de slechtere ideeën te scheiden.

Figuur 3: beginscherm

3. Productomschrijving

3.1 Korte beschrijving van het systeem

Zoals reeds aangehaald in 2.2 was de uitkomst van de brainstorm een routeplanner met de nodige mediafeatures. Dit houdt concreet in dat persoon A een route kan aanmaken waarop hij naar believen foto’s, commentaar en muziek kan toevoegen. Daarna kan hij deze behouden voor eigen gebruik of hem doorspelen naar persoon B. Persoon B zal nu op zijn beurt de route kunnen afgaan, begeleid door de toegevoegde media die zullen zorgen voor extra gemak en sfeer. In dit opzicht is het programma zeker gericht op sharing. Het zal dan ook niet verbazen dat als mogelijke uitbreiding het doorsturen en oprichten van een community worden aangehaald. In sectie 5 wordt er ingegaan op hoe we tijdens het ontwerpen rekening hebben gehouden met dit sharingaspect. Vooral de manier waarop muziek wordt samengesteld is een voorbeeld bij uitstek.Naast deze functionaliteiten heeft het programma ook een aangenaam grafisch karakter. De nodige tijd werd geïnvesteerd in de lay-out die eigenhandig is ontworpen. Dit gepaard met een eigen logo, naam en baseline (zie figuur 3) zorgt voor een conceptueel geheel. Het spreekwoord luidt niet voor niets “het oog wil ook wat”.

3.2 Use cases

Om een duidelijk beeld van de interactie tussen de gebruiker en het systeem te geven, werd gebruik gemaakt van Use cases. Er wordt namelijk van elke handeling van de gebruiker weergegeven hoe het systeem reageert. Figuur 4 geeft het opgestelde ‘Use case diagram’ weer.

Figuur 4: Use Case diagram

De drie voornaamste use cases worden hieronder weergegeven. ('UC1: Opstarten', 'UC3: Opslaan', 'UC5: Muziek toevoegen aan locatie' en 'UC7: Foto bekijken' zijn weggelaten.)

UC2: Route maken

Primary Actor: Gebruiker

Stakeholders and Interests: Gebruiker: wil een route maken.

Preconditions: de applicatie is opgestart en het hoofdscherm is weergegeven.

Success Guarantee (Postconditions): De gebruiker krijgt een kaartje te zien men zijn eigen locatie. Wanneer deze beweegt update ook zijn eigen locatie. In het optionsmenu kan hij kiezen voor Add Media, Save and quit, Zoom in en Zoom out.

Main Success Scenario (or Basic Flow):

1. Gebruiker klikt in het hoofdscherm op “Route maken”. 2. Er wordt een nieuwe activity gestart die de naam van de route vraagt. 3. De gebruiker vult de gewenste naam in en klikt op OK.

4. Er wordt een nieuwe activity gestart die een mapje weergeeft die de plaats van de gebruiker weergeeft. Deze wordt geupdate wanneer de gebruiker zich verplaatst. In het optionsmenu kan hij kiezen voor Add Media, Save and quit, Zoom in en Zoom out.

Extensions (or Alternative Flows): 1a. De gebruiker klikt in het hoofdscherm op cancel.

De applicatie wordt afgesloten.

1b. De gebruiker klikt in het hoofdscherm op VoerRouteUit.

Hij voert een route uit.

UC4: Media toevoegen aan locatiePrimary Actor: Gebruiker

Stakeholders and Interests: Gebruiker: wil media toevoegen aan de locatie waar hij zich bevindt

Preconditions: De activity van het hoofdscherm van Maak Route is opgestart.

Success Guarantee (Postconditions): de gebruiker heeft media toegevoegd aan de locatie waar hij zich bevindt.

Main Success Scenario (or Basic Flow):

1. De gebruiker klikt in het hoofdscherm van Maak Route op Add Media. 2. De ChooseMediaActivity wordt opgestart. 3a. 1.De gebruiker klikt op Photo. 3a. 2.De PhotoCaptureActivity wordt opgestart. 3a. 3.De gebruiker trekt een foto.

3a. 4. De gebruiker krijgt de getrokken foto te zien waarin hij kan kiezen of hij de foto wil saven of deleten.

3a. 5. De gebruiker klikt op save Photo.3a. 6.Het systeem keert terug naar de activity van ChooseMedia. 3b. 1.De gebruiker klikt op Comment.

3b. 2.De CommentActivity wordt opgestart. 3b. 3.De gebruiker geeft een comment in. 3b. 4.De gebruiker klikt op OK. 3b. 5.Het systeem keert terug naar de activity van ChooseMedia. 3c. 1.De gebruiker klikt op Music. 3c. 2.De MusicActivity wordt opgestart. 3c. 3.Zie UC5: Muziek toevoegen aan locatie. 3c. 4.Het systeem keert terug naar de activity van ChooseMedia. 4. De gebruiker klikt op Save. 5. De media wordt opgeslagen op de locatie waar hij de ChooseMediaActivity heeft gestart. 6. De activity van Maak Route wordt opgestart.

Extensions (or Alternative Flows): 3) De gebruiker klikt op cancel.

De applicatie keert terug naar de maakRouteActivity.

3) De gebruiker selecteerd een mediatype waarvan er al een opgeslagen is op deze locatie.

De gebruiker krijgt een scherm te zien van "U kan slechts 1 file van elk type op 1 locatie opslaan." en een knop met "OK".

De gebruiker klikt op "OK". 3a 5) De gebruiker klikt op delete Photo.

De foto wordt niet opgeslagen en het systeem keert terug naar ChooseMediaActivity.

UC6: Route uitvoerenPrimary Actor: Gebruiker

Stakeholders and Interests: Gebruiker: wil een route uitvoeren.

Preconditions: de applicatie is opgestart en het hoofdscherm is weergegeven.

Success Guarantee (Postconditions): De gebruiker krijgt een kaartje te zien met zijn huidige plaats en alle foto's.

Main Success Scenario (or Basic Flow):

1. Gebruiker klikt in het hoofdscherm op Voer Route Uit. 2. De applicatie gaat naar een nieuw scherm dat alle opgeslagen routes weergeeft. 3. De gebruiker selecteert een route. 4. Er wordt een nieuwe activity gestart van de geselecteerde route die een kaartje

weergeeft met zijn huidige plaats en alle foto's.

Extensions (or Alternative Flows): 1a. De gebruiker klikt in het hoofdscherm op cancel.

De applicatie wordt afgesloten.

1b. De gebruiker klikt in het hoofdscherm op Maak Route.

Hij begint een route te maken.

3.3 Domeinmodel

Als basis voor het opstellen van het klassediagram, werd er eerst een domeinmodel opgesteld. Dit is weergegeven in figuur 5. Een sterretje staat voor “meerdere”, terwijl een 1 staat voor één. Bijvoorbeeld: elk mediapoint kan bestaan uit slechts 1 commentaar, maar een commentaar kan horen bij meerdere mediapoints. De functie van het domeinmodel is het overzichtelijk opstellen van de concepten van de applicatie. Hierdoor is het gemakkelijker om het klassediagram op te stellen en beter inzicht te krijgen in de samenstelling van het programma.

Figuur 5: Domeinmodel

3.4 Ervaring

De productomschrijving was zeer nuttig voor alle leden van de groep om een beter inzicht te krijgen in de structuur van ons programma. De use cases zijn zeer duidelijk over de interactie tussen gebruiker en systeem. Het werd dan ook snel duidelijk dat de use cases een essentieel onderdeel waren van het project. Bij het ontwerp en de implementatie van onze applicatie werden deze use cases dan ook veelvuldig gebruikt.

Het domeinmodel werd gebruikt voor het opstellen van het klassediagram en het gaf ook een beter inzicht in de samenstelling van het programma.

4. Technologie

4.1 GWT

Google Web Toolkit (GWT) is een open source Java development framework dat ontwikkelaars toelaat om op AJAX gebaseerde applicaties te maken in Java. Het maakt gebruik van asynchrone server-communicatie, in de stijl van tools zoals bv. Gmail.

VoordelenGWT laat de ontwikkelaar toe om de code te programmeren in Java, terwijl de applicatie draait onder JavaScript. M.a.w., GWT fungeert als een soort van programmeeromgeving met automatische vertalingsmodaliteiten. Hierdoor is het mogelijk om object-georiënteerd te programmeren, wat veel efficiënter en eenvoudiger is voor grote applicaties dan JavaScript.Een tweede voordeel is het feit dat de communicatie met de server asynchroon verloopt. Dit wil zeggen dat een servercall (bv. een druk op een knop) het systeem niet blokkeert tot de call is beantwoord, maar dat de cliënt verder kan werken terwijl in de achtergrond wordt uitgevoerd, wat de applicatie vlotter laat werken. Er is in GWT ook een gesimuleerd browservenster beschikbaar, met refreshfunctie, dat direct eventuele opgeslagen wijzigingen in de broncode weergeeft. En een laatste belangrijk voordeel: GWT is gratis.

NadelenJe kan enkel programma's maken die ook gewoon in JavaScript geprogrammeerd kunnen worden. Speciale bibliotheken die beschikbaar zijn in Java zijn vaak onbruikbaar omdat ze niet compatibel zijn in Java. Ook is de beschikbare database, GWT-ext, niet echt uitgebreid. Dus voor geavanceerde interfaces is het nog steeds nodig om zelf de widgets te ontwikkelen.

4.2 Android

Android Software Design Kit (SDK) is een softwarepakket voor mobiele apparaten, meer bepaald smartphones, met programmeeromgeving en besturingssysteem, dat onlangs door Google Inc. op de markt werd gebracht. Met behulp van de Java programmeertaal kunnen op dit platform applicaties ontwikkeld worden.

VoordelenAndroid werkt met en ondersteunt Java volledig, zodat niet alleen het programmeerwerk object-georiënteerd en dus overzichtelijker kan verlopen, maar dat bovendien aan de gebruikerszijde alle webcontent vlot wordt weergegeven, wat bij andere mobile browsers vaak niet het geval is.Alle standaardapplicaties op het systeem, zoals bv. GoogleMaps en browsers, zijn ook in Android ontwikkeld, en dus bijgevolg zeer gemakkelijk in een zelfgemaakte toepassing kunnen worden geïntegreerd. Er is in de SDK eveneens een emulator ingebouwd, die het uitzicht en de werking heeft van een echte Android phone. De applicatie kan zo zeer efficiënt getest en gedebugged worden.

NadelenDoordat het Androidsysteem zo uitgebreid en complex in elkaar zit, wordt een beginnend ontwikkelaar vaak overrompeld door alle verschillende mogelijkheden van Android. Het is moeilijk om de belangrijke aspecten nog te onderscheiden van de minder belangrijke.

5. Ontwerp

5.1 Ontwerpbeslissingen

5.1.1 Media toevoegenWe zagen twee opties wat betreft het toevoegen van media aan een locatie. Een eerste mogelijkheid was om commentaar en muziek toe te voegen aan een foto. Er moet dan sowieso eerst een foto getrokken worden om muziek of comment aan een locatie toe te voegen. Een tweede optie was om een aparte klasse te maken, een MediaPoint, waaraan we dan de verschillende types media konden toevoegen. We hebben de tweede optie gekozen omwille van de volgende redenen:

Zuiniger gebruik van geheugen. Als de gebruiker bijvoorbeeld enkel muziek wil toevoegen aan een locatie, moet hij geen foto nemen die weer het nodige geheugen in beslag neemt.

Beter voor de uitbreidbaarheid van het programma. Als we bijvoorbeeld later de feature willen implementeren om video's te kunnen toevoegen, moeten we niet eerst een foto trekken. En als we dan een commentaar willen toevoegen aan het filmpje, dan kan dit zonder problemen. Dit geeft duidelijk weer dat een MediaPoint fungeert als mediamapje waaraan je de gewenste media kan toevoegen. Het idee van zo'n mediapunt is ook handig als je de aangemaakte media eerst nog wilt bewerken vooralleer ze op te slaan in de database.

5.1.2 Meerdere mediaobjecten van dezelfde soortHet was ook belangrijk om te beslissen of er meerdere mediabestanden van 1 type aan een mediapunt kunnen worden toegevoegd. Bijvoorbeeld twee foto's aan één locatie. Wij hebben ervoor geopteerd om deze mogelijkheid niet in te voegen, omdat dit een extra moeilijkheid zal brengen bij het implementeren dat het extra genot van deze feature niet compenseert. Nu kunnen we met een relatief eenvoudige databasestructuur toch voldoende functionaliteit bieden.

5.1.3 Wanneer foto’s weergevenEen derde ontwerpbeslissing die we hebben gemaakt is of we bij het uitvoeren van een route als standaard eerst de eerstvolgende foto weergeven of een mapje die de af te leggen route weergeeft. We hebben gekozen voor de tweede optie omdat deze praktischer is. Zo weet de gebruiker direct welke weg hij bijvoorbeeld moet inslaan. Hij kan dan de eerstvolgende foto bekijken door op de knop “Show Photo” te klikken. Of in de buurt te komen van de locatie waar de foto is opgeslagen.

5.1.4 Opnieuw muziek samenstellenAan het uitwerken van een consistente manier voor het herbepalen van de muziek hebben we veel werk gehad. De optie om de muziekbestanden zelf bij de route toe te voegen werd al snel afgewezen omdat dit teveel geheugen zou innemen. Er werd dan geopteerd om een genre-tag toe te voegen aan een MediaPoint. Indien de route dan gemaild zou worden naar een andere gebruiker, zou er automatisch een playlist van alle nummers van dit genre worden aangemaakt. Deze zou dan worden afgespeeld totdat een volgend MediaPoint is bereikt waaraan muziek gekoppeld is.

Een ander mogelijkheid is om drie ArrayLists aan te maken die respectievelijk Strings van

titel, album en artiest bevatten. De androidphone van de gebruiker die het programma uitvoert, zou dan eerst zoeken op zijn eigen phone naar dezelfde titel van het eerste nummer. Indien dit niet wordt gevonden, zoekt het programma verder naar een ander nummer van hetzelfde album. Als dit ook niet wordt gevonden, wordt er een nummer gezocht van dezelfde artiest. Als dit ook niet wordt gevonden gaat hij over naar het volgende nummer. Indien er niets wordt gevonden, speelt de smartphone gewoon een random nummer af.

Deze laatste mogelijkheid is het geworden. Hiervoor hadden we weer verschillende redenen:

Een genre is te vaag. Het genre ‘pop’ bijvoorbeeld kan zowel slaan op “Oasis” als op “Kate Ryan”, toch twee –in onze ogen- ver uiteen liggende artiesten. Daarbij komt nog dat men een genre vaak leeg laat .

Er wordt zo specifiek mogelijk gezocht en men zwakt stelselmatig af. Het toevoegen van een randomfunctie voorkomt dan weer dat er een moment is dat de muziek stil valt.

Een nadeel van deze keuze is dat het echter wat rekenwerk vergt van de computer. Dit is vooral merkbaar op de emulator. We hebben het op de Phone zelf al getest met lijsten van 20 à 30 nummers zonder al te veel problemen.

5.2 Architectuur

De architectuur van een applicatie is een hulpmiddel bij het ontwerp, dat in grote lijnen weergeeft welke activiteiten erin kunnen plaats vinden, zowel aan de Client-side als aan de Service-side (zie ook Figuur 6). De Client-side betekent concreet: alle elementen waar de gebruiker uiteindelijk mee zal in contact komen, zoals bijvoorbeeld het geheel van MakeRoute en FollowRoute Views. De verbindings-symbolen stellen interfaces voor. Een component kan een interface aanbieden (bol) - dat is een geheel van functionaliteit -, die door een andere component (haakje) kan worden opgevraagd. De Service-side tenslotte, is het deel van het programma dat permanent onzichtbaar is voor de gebruiker. De architectuur van MediAdventure bestaat uit een Service-side met een RouteMaker en een RouteFollower.

Figuur 6: Architectuur

RouteMaker maakt via een interface gebruik van DatabaseManager om zaken in de database op te kunnen slaan. LocationController wordt gebruikt om de locatie bij te houden tijdens het aanmaken van de route. RouteFollower maakt eveneens gebruik van deze 2 components, om de evidente reden dat ook bij het uitvoeren van een route de locatie moet worden bijgehouden en elementen uit de database moeten worden gehaald. De 2 Views aan de Client-side maken gebruik van de output van RouteMaker en –Follower, om via de interfaces Camera, CommentBox, Menu en Direction een View voor de gebruiker op te stellen.

5.3 Klassediagram

Een applicatie die voor android geschreven wordt, bestaat meestal uit vier grote componenten: Activities, Views, Intents en Services.

ActivitiesElke klasse die de klasse Activity uitbreidt, is in staat om een UI aan de gebruiker te tonen. Bijgevolg is er voor elk schermpje dat in het programma gebruikt wordt, een andere Activity klasse nodig. Het is dus duidelijk dat al deze Activities met elkaar verbonden moeten zijn en dat er een goede flow tussen hen moet zijn.

IntentsOm van de ene activity (lees: schermpje), naar de andere te kunnen gaan, wordt er gebruik gemaakt van intents. Een intent kan dus gezien worden als een boodschap die de intentie symboliseert, om iets te doen. Het is mogelijk om aan een intent informatie mee te geven, die dan in de opgeroepen activity gebruikt wordt.

ViewsDe klasse View bezit de functionaltiteit om interactieve GUI’s te maken. Zo is het mogelijk tekst, afbeeldingen, buttons, .. in de applicatie te gebruiken. Het interactieve aspect zit in het feit, dat er aan al de views, “listeners”,... kunnen worden toegevoegd. Zo zal de applicatie reageren als je op een button klikt, of als er vooraf ingestelde eigenschappen van de views veranderen.Deze views worden toevoegd vannuit de code of door gebruik te maken van XML files.

ServicesUiteraard is het in vele applicaties van belang dat er tijdens het uitvoeren, een heleboel zaken op de achtergrond gebeuren. Hiervoor wordt er gebruik gemaakt van services. Andere klassen kunnen zich aan zo’n service binden en methodes erop aan roepen via remote “calls”.

Voor het opstellen van het klassediagram van onze applicatie, werd rekening gehouden met de relatie tussen deze componenten. figuur A.3 in de bijlage geeft het volledige klassendiagram weer.

De hoofdklasse van het programma is RoutePlanner. Deze klasse zorgt ervoor dat de gebruiker een scherm te zien krijgt, die hem toelaat te kiezen uit ' route uitvoeren' en 'route maken'.

Route makenFiguur 7 toont de belangrijkste klassen die gebruikt worden wanneer de gebruiker een route wil aanmaken. Zo zal er eerst de klasse RecordActivity aangeroepen worden. Deze klasse zorgt ervoor dat de gebruiker een mapje te zien krijgt waarop zijn huidige locatie is aangeduid. Tijdens het opnemen van de route wordt telkens de locatie van de persoon wijzigt, zijn nieuwe locatie in de database opgeslagen. Bovendien wordt ook het mapje hertekent en wordt getoond welke weg hij al afgelegd heeft. Voor het opslaan van de locaties in de database maakt RecordActivity gebruik van de OurLocationManager(zie verder).

Figuur 7: klassen aangeroepen bij het aanmaken van een route

Uiteraard is het ook mogelijk op sommige plaatsen media toe te voegen. Hiervoor kan de gebruiker op “add media” klikken.

Op het moment dat gebruiker klikt, wordt er op zijn huidige locatie een nieuw object van de klasse MediaPoint aangemaakt. Een MediaPoint object kan gezien worden als een plaatsgebonden mediamapje, waar foto’s, muziek, commentaar en andere mediabestanden aan toegevoegd kunnen worden. In verband met uitbreidbaarheid, hebben we ervoor gekozen om de klasse Photo, Music, Comment te laten overerven van de klasse MediaFile. Bijgvolg zullen enkel objecten van de klasse MediaFile in een MediaPoint aangemaakt worden. Indien we dus ook filmpjes willen opslaan kunnen we gewoon een nieuwe klasse Movies aanmaken en die laten overerven van MediaFile. Verder moeten er dan bijna niets aan de code aangepast worden.

Voor het toevoegen van mediabestanden, maakt recordActivity gebruik van de ChooseMediaActivity.Wanneer de ChooseMediaActivity aangeroepen wordt, krijgt de gebruiker een scherm te zien waarin hij kan kiezen of hij een foto, playlist of commentaar wilt toevoegen. Afhankelijk van wat er gekozen wordt, spreekt chooseMediaActivity een subactivity(CommentActivity, MusicActivity of PhotoCaptureActivity) aan.Wanneer de gebruiker het mediapunt wilt opslaan, geeft chooseMediaActivity informatie over de mediabestanden die aangemaakt moeten worden door aan RecordActivity. Met behulp van de verkregen informatie worden de verschillende MediaPoint objecten aangemaakt, die dan in het MediaPoint worden geplaatst. Vervolgens wordt OurMediaManager aangeroepen om het mediaunt op te slaan in de database. De gebruiker kan dan op een volgende plaats een nieuw mediapunt aan maken en dit totdat hij de route wilt opslaan.

Het is dus duidelijk dat de interactie met de database gebeurt met behulp van OurLocationManager en OurMediaManager. OurLocationManager zorgt ervoor dat de verschillende locaties in en uit de database kunnen worden opgehaald. OurMediaManager zorgt voor het opslaan van de mediabestanden in de database. Eerst wordt een object van de klasse MediaPoint aangemaakt. Dit wordt vervolgens gevuld met de juiste MediaFile objecten en tenslotte wordt het MediaPoint object opgeslagen.

Route uitvoerenFiguur 8 toont de belangrijkste klassen die gebruikt worden wanneer de gebruiker een route wil uitvoeren. Eerst wordt de klasse ExecuteActivity aangeroepen. Deze klasse start de subactivity LoadRouteActivity die een schermpje toont waarin je een gewenste route kan aanduiden. De informatie voor het aanmaken van de aangeduide route wordt teruggegeven aan ExecuteActivity en vervolgens wordt er een object van de klasse RouteManager aangemaakt. Deze klasse bevat de functionaliteit om een gewenste route in te laden en samen te stellen. De klasse maakt bijgevolg gebruik van OurLocationManager om al de opgeslagen locaties uit de database te halen. OurMediaManager wordt gebruikt om op alle locaties waar media aanwezig is, een mediapunt op te vragen dat dan in een aangemaakt Route object wordt opgeslagen.We kozen ervoor om enkel de mediapunten in het Route object te bewaren omdat anders al de locaties(die om de 5 seconden werden opgenomen) in het Route object moeten aangmaakt worden. Als de route ingeladen is, zal ExecuteActivity een map tonen die de ingeladen route weergeeft. Bovendien zal er op de achtergrond een playlist spelen.

De gebruiker kan de route dan beginnen uitvoeren. Indien hij binnen een bepaalde straal van een nieuw mediapunt komt, wordt de in het mediapunt opgeslagen foto weergegeven, en wordt de playlist geüpdatet op bais van de liedjes die in het MediaPoint zijn opgeslagen. Voor het tonen van de foto wordt er gebruik gemaakt van PhotoViewActivity. Het updaten van de playlist gebeurt in ExecuteActivity.

Figuur 8 : klassen aangeroepen bij het uitvoeren van een route

5.4 Database

De applicatie maakt gebruik van een SQLite database. Deze wordt opgeroepen met behulp van de klasse DatabaseAdapter. De database bestaat uit 6 tables: GeoMedia, Routes, Tracks, Comments, Playlists en Photos (zie ook figuur 6). In principe wordt op elke lijn in de tabel GeoMedia één plaatscoördinaat opgeslagen ( longitude & latitude) met eventueel de daarbij behorende media-items. Opslag van locaties gebeurt automatisch, ongeveer om de 5 seconden.Wanneer de gebruiker kiest om een MediaPoint toe te voegen worden in de database de tabellen Photos, Playlists & Tracks of Comments ingevuld.

Er is ook een tabel Routes, die per punt bijhoudt van welke route het deel uitmaakt. Hierdoor wordt het mogelijk om wanneer later de route uitgevoerd wordt, per geselecteerde route een specifieke set GeoMedia-items op te halen.

Figuur 6: Databasestructuur

5.5 Ervaring

Een degelijk ontwerp is essentieel voor het maken van een goed programma.Dit ontwerpproces verliep niet altijd even gemakkelijk. Vele uren werden gestoken in het maken van een goed klassendiagram. Het eerste ontwerp hiervan, na feedback op het tussentijds verslag, moest volledig herschreven worden. Een aantal klassen moesten meer dan andere in het oog springen, wat eerst niet het geval was, en de flow (verloop) van het programma moest duidelijk weergegeven worden. Ook waren er geen Intents aanwezig, en slechts één Activitiy. Dit laatste kan onmogelijk correct zijn, aangezien een Androidprogramma volledig werkt aan de hand van Activities en View, en ze dus meermaals moeten voorkomen.

Om het klassediagram te herwerken, is uitgegaan van het domeinmodel, en met alle opmerkingen in acht, is dan tot het uiteindelijke resultaat gekomen, waarop we positieve feedback ontvingen.

Het databasedesign ging aanvankelijk slechts uit van 4 tabellen, omdat gedacht werd dat tracks in playlists konden worden geïntegreerd, en dat een routetabel niet per se nodig was. Na terugkoppeling tijdens zowel de ontwerp- als implementatiefase werd duidelijk dat beide extra tabellen wel degelijk nodig.

6. ImplementatieDe concrete implementatie van het programma, met andere woorden het omzetten van de programmastructuur in Java en het schrijven van de code, was een complex en lang proces, met vele mee- en tegenvallers. Voor het publiek de meest zichtbare kant van het project, namelijk het (werkend) programma, is uiteraard slechts één aspect van het algemene concept; ontwerp speelt minstens een even belangrijke rol.

6.1Moeilijkheden

Uiteraard had het hele team aanvankelijk moeilijkheden met de nieuwe programmeeromgeving, hoewel deze fundamenteel ook op Javataal gebaseerd is. Concepten als Views, Activities, Bundles,... waren niet altijd evident om zonder meer direct te begrijpen.De belangrijkste obstakels die overwonnen moesten worden, zijn hier kort weergegeven.

6.1.1 DatabaseDatabases en hun werking was bijna volledig onbekend terrein in het team. Implementatie in de klasse DatabaseAdapter werkte op compileniveau vrij snel, maar er zaten verscheidene logische fouten in. Zo kon bijvoorbeeld een testklasse geen objecten teruggeven uit de database omdat de Cursor over de foute kolommen itereerde. Na urenlang debuggen en testen bleek dit aan enkele kleine key- (verkeerde toekenning in de velden), syntax- (aanhalingstekens gebruikt waar dit niet mocht) en inzichtsfouten te liggen. Zoiets zorgt snel voor frustraties.

6.1.2 Activities versus klassenEen ander groot probleem dat pas werd ontdekt tijdens het programmeren, had te maken met het ontwerp van de klassentructuur. Het bij het begin van programmeren gebruikte diagram was gebaseerd op de redenering dat Activities & Services ondergeschikt waren aan normale Java-klassen. Het ontwerp bevatte niet de nodige 'flow' van Activities (& Services), dus allemaal gelinkte Activities met subklassen eraan gelinkt, maar eerder een flow van klassen met Activities eraan gelinkt; de omgekeerde wereld dus. Uiteindelijk leidde dit tot het schrappen van een aantal voorheen belangrijke klassen zoals Photo- en MusicManager, waar enkele teamleden toch heel wat tijd in hadden gestoken.

6.1.3 ID3, MusicService & NotificationsHet merendeel van het programma maakt gebruik van de standaard Android libraries, die reeds in de SDK aanwezig zijn. Voor het muziekluik was er echter nood aan externe bibliotheken om ID3-tags te kunnen linken aan en halen uit fotobestanden. De eerste bibliotheek die hiervoor was geïnstalleerd werkte niet naar behoren met de Androidstructuur,

maar dit was lange tijd niet duidelijk, met als gevolg dat werd gezocht naar ontwerp- en codefouten die er eigenlijk niet waren. Downloaden van een andere library loste het probleem uiteindelijk op, na heel wat tijdverlies. Doordat met ID3-tags wordt gewerkt, is men niet afhankelijk van de filenaam om de artiestnaam, albumtitel, etc. te verkrijgen. Hierbij zijn tal van uitbreidingen mogelijk om later te zoeken op artiest, op album, ... bij het selecteren van de muziek.Ook de MusicService bezorgde heel wat kopzorgen, toen bleek dat de interface slechts sporadisch beschikbaar werd gesteld voor de Activity die ervan gebruik maakte. Dit bleek te liggen aan het feit dat eerst de hele OnCreate() methode werd uitgevoerd bij het maken van elke Activity voordat de interface beschikbaar werd gesteld door de Service fatsoenlijk te binden aan de Activity. Hierdoor werden soms geprobeerd de interface te controleren terwijl die nog niet beschikbaar was. Door de nodige zaken te verhuizen naar de onServiceConnected werd dit probleem opgelost. Het voordeel van de huidige externe Service is dat deze indien nodig kan blijven draaien terwijl andere Activities werden aangeroepen en dit is zeer handig bij mogelijke uitbreidingen.

6.1.4 StatusProviderToen net begonnen werd met implementeren, was besloten een aparte groep klassen te maken voor het bijhouden en updaten van de gebruikerslocatie. Deze groep bestond concreet uit een StatusProvider-, die voor de GPS-updates zorgde, en een Statusklasse die deze gegevens opsloeg in 1 object. Het Statusobject kon dan vervolgens doorgegeven worden naar alle plaatsen waar dit nodig was. Na enige tijd, en na bespreking met de begeleider, bleek dat Android zelf exact dezelfde functionaliteit reeds had geïmplementeerd in 1 bruikbaar pakket, waardoor hierop werd overgeschakeld. Ook met het zicht op eventuele uitbreiding zouden deze klassen veel meer mogelijkheden hebben. De originele klassen werden niet meer gebruikt, hoewel ze reeds geprogrammeerd waren.

6.1.5 API-keys & LocationManagerIn extremis, het programma was virtueel klaar, werd nog op een groot probleem met compatibiliteit gestuit. De applicatie werkte op bepaalde computers wel, op andere niet... Dit mysterie had te maken met zogenaamde API-keys, identificatiesleutels voor het correct weergeven van landkaarten. Deze is individueel per computer, maar was per ongeluk met de rest van de code gecommit op de server door een teamlid. Hierdoor kregen de andere computers dezelfde API-key door, maar zonder deze ooit geïnstalleerd te hebben, wat voor een leeg raster in plaats van een kaart zorgde. Ook de LocationManager begaf het op de valreep, weer met een verdachte voorkeur voor bepaalde machines. De locaties die werden opgehaald in de ExecuteActivity waren null-objecten, en dus leverde de uitvoer niets op. De clou zat hem bij de taalvoorkeur van Android. Enkel een engelstalige instelling van de gehele computer deed het geheel werken!! Op zijn minst een raciale bug…

6.2 Aanpassingen ontwerp

Bovenstaande problemen leidden bijna allemaal tot wijzigingen in de ontwerpstructuur, sommige al wat fundamenteler dan de rest. De databasestructuur is grotendeels hetzelfde gebleven, aangezien de problemen zich hier meer intern afspeelden. Een zeer fundamentele wijziging was een gevolg van het conflict Activity-Klasse, dat verstrekkende gevolgen had bij het ontwerp. Schrappen van klassen, andere relaties tussen de overigen, en zelfs enkele

nieuwe (vb. MusicService) gooiden het klassediagram grondig door elkaar. Initieel gebruik van StatusProvider en Status werd later ongedaan gemaakt, om eerder vermelde redenen.In principe is er uiteindelijk niet zoveel veranderd, aangezien het ontwerp heel wat tijd in beslag nam, en dus degelijk in elkaar paste.

6.3Ervaring

In het algemeen is de implementatiefase goed verlopen, alhoewel het werk soms wel te gefragmenteerd werd beschouwd. Natuurlijk is het nodig om taken onder te verdelen en in modules te werken, wat ook veel geholpen heeft, maar er moet ook op regelmatige tijdstippen worden samengevoegd en teruggekoppeld over het bereikte resultaat. Dit is onvoldoende gebeurd in het team. Kortom, een betere onderlinge communicatie kan bij herhaling van dit project een verbetering vormen. In dit opzicht bracht ook het (verplichte) gebruik van SVN een hele versoepeling van het werk met zich mee. In het team werd hier in het begin geen gebruik van gemaakt, wat al snel leidde tot inconsistenties en niet combineerbare programmaonderdelen. Gelukkig kwam het inzicht al na een oefenzitting en werden catastrofes vermeden.

7. Zelfevaluatie

Als team hebben we getracht op een originele en leuke manier media te linken aan locaties, geïntegreerd in een toegankelijke toepassing. Algemeen gezien zijn we zeker in dit opzet geslaagd.

Een sterk punt van MediAdventure is zeker de gebruiksvriendelijkheid. In elk menu en op elk scherm wordt weergegeven wat er van de gebruiker verwacht wordt, zodat het ook voor leken een zeer toegankelijk programma is. Daarnaast is er veel aandacht besteed aan de grafische vormgeving; custom gerenderde knoppen in plaats van de Android-standaard, passende achtergronden, een eigen naam, baseline en logo. In de eerste plaats om esthetische redenen, maar ook om een conceptueel geheel te vormen. Het vermelden waard zijn bijvoorbeeld de quotes van allerlei bekende en minder bekende figuren i.v.m. reizen. Zowel een goede manier om de laadtijd te verdoezelen als een bouwsteen in de idee.

De gebruikte programmeertaal, Java in Android, heeft eveneens voordelen aangezien ze object-georiënteerd is. Hierdoor zijn uitbreidingen redelijk simpel door te voeren. Hieraan is ook effectief gedacht. Zo kunnen er bijvoorbeeld nog video's toegevoegd worden in plaats van foto’s als media-items, en comments kunnen ingegeven worden aan de hand van spraak in plaats van tekst. Ten slotte was het een significant pluspunt dat de applicatie op de Androidphone zelf heeft kunnen draaien. Hierdoor kon aan de geïnteresseerden getoond worden dat het niet enkel om een computersimulatie ging, en kreeg men ook een ‘echtere’ ervaring.

Toch moeten ook enkele negatieve punten vermeld worden. De grootste fout die gemaakt is, is het feit dat tijdens de initiële oefenzittingen niet duidelijk is afgesproken wat het concrete plan was. Hierdoor had iedereen een verschillend beeld van de doelstelling. Dit heeft geleid tot miscommunicatie, gebrek aan efficiënt teamwerk en heel wat verloren tijd. Als we vanaf het begin meteen ondubbelzinnig hadden neergeschreven wat we exact gingen doen, zou niet iedereen een eigen interpretatie hebben van waar we het eigenlijk mondeling over eens waren. Dit zou zowel geholpen hebben bij het algemeen begrijpen van het programma als bij de concrete implementatie ervan. Het nut van een productomschrijving, zelfs voor er nog maar spraken is van een product, is ons nu dus bij deze zeker duidelijk

Tijdens de demodag is ook een ander negatief punt aan het licht gekomen. In ons ontwerp is geen activity opgenomen waarmee de gebruiker zijn eigen instellingen kan wijzigen. Ondanks we over de huidige instellingen goed hebben nagedacht, zou het misschien beter zijn de gebruiker zelf de keus te laten. Enkele dingen waar we bijvoorbeeld aan dachten, zijn:

De gebruiker zelf laten kiezen hoe dicht hij bij een mediapunt moet zijn voor deze in werking treed. Iemand die veel op de autosnelweg rijdt, zal liever een kilometer vooraf willlen weten welke afslag hij moet nemen. Bij iemand die op kleine weggetjes rijdt kan dit veelal irritant zijn.

Laat je een liedje uitspelen wanneer een nieuwe playlist wordt aangemaakt? Bij korte routes (zoals diegene op de demodag) doet dit het concept van sfeer bij een locatie teniet. Bij langere routes kan dit wel aangenamer zijn voor de bestuurder.

Welke mapview standaard als eerste wordt ingeladen. (street of satellite)

Dat je kan kiezen of je, wanneer je op “add media” klikt, het mediapoint toevoegd aan de locatie op het moment van de klik of het moment van de save.

Op vlak van tijdsbesteding is het project redelijk gelijkmatig verlopen, al is de doelstelling om enkel tijdens de seminarie-uren te werken (uiteraard) niet gehaald. Dit mag niet verwonderlijk zijn, aangezien een P&O-opdracht, een creatief en veeleisend team, een complex programmeerplatform en het gegeven tijdsbestek nu eenmaal inherent incompatibel zijn. In dat opzicht was het opzet om de instructieseminaries van GeoSport eveneens aan de GeoMedia-teams te geven, hoewel interessant, misschien overbodig. “Time is all that really matters, except for maybe a little love” zei iemand ooit, en hoewel creatieve capaciteiten bij een project als dit uitgebreid worden aangesproken, was de tijdsdruk steeds aanwezig. Komt er daar nog eens bij dat je toch wel graag iets laat zien aan mama en papa op de demodag. Al bij al viel het nog wel mee zoals je in de appendix kan zien. En het resultaat van talrijke sessies hard werk mag uiteindelijk zeker gezien worden, en misschien ooit verkocht, wie weet.

8. VakintegratieDit punt handelt over hoe kennis verworven in vakken uit 1e en 2de bachelor ingenieurswetenschappen aan bod kwam tijdens het uitvoeren van de opdracht.

Logischerwijze is het vak dat het meest in het project geïntegreerd Methodiek van de Informatica. Een basiskennis van Java, en de competentie om oplossingen te zoeken aan de hand van Javadocumentatie op het internet of in tutorials, is zeker vereist. Het leren werken

met Google Android was desalniettemin een hele opgave, om eerder vermelde redenen. Het ontwikkelen van een softwaredesign om effectief programmeren mogelijk te maken, samen met de bijhorende capaciteit om een probleem tot een abstract niveau te tillen, was eveneens cruciaal, en kwam uitgebreid aan bod bij het ontwerpen van het klassediagram.

Een ander vak dat belang had bij deze P&O, was Informatieoverdracht en –verwerking . De communicatie tussen cliënt en server gebeurt volgens procedures die beschreven worden in dit vak. Ook bij de communicatie tussen de smartphone en de server, kan er uit principes over overdrachtscapaciteit, signaalsterkte e. d. geput worden.

Ten derde kunnen verscheidene elementen uit de vorige projecten van Probleemoplossen en Ontwerpen aangehaald worden. De vaardigheid in het schrijven van verslagen werd in deze projecte grotendeels ontwikkeld. Het werken in teamverband, en onderlinge constructieve samenwerking, elementaire bestanddelen van een goed project, zijn reeds geoptimaliseerd in de vorige P&O’s. Hierbij hoort eveneens het plannen van de taken en het verdelen van de verantwoordelijkheden.

Ook het programmaonderdeel “ICT-werktuigen” uit P&O 1, is bruikbaar gebleken. Wiki’s kunnen nu gebruikt worden om te communiceren met teamgenoten. De site ‘Flickr’, een besproken item, geeft een eerste idee over hoe men GPS kan linken aan media. Standaardzaken zoals het gebruik van tekstverwerkingsprogramma's en rekenbladen werden behandeld. Een concreet voorbeeld is het gebruik van versiebeheer. Zeer handig wanneer meerdere mensen aan hetzelfde verslag moeten werken en er na verloop van tijd meer versies dan alinea’s bestaan. Tot slot kan het efficiënt gebruik van zoekmachines nog worden vermeld. Zo werd bijvoorbeeld op blogs gezocht via BlogSearch van Google en een RSS-feed geplaatst bij een blog over geotagging.

9. BesluitHet P&O3-project GeoMedia had als doel om ingenieursstudenten kennis te laten maken met een real-life ontwerpopdracht. Hierdoor werd tegelijk ook een zinvolle inkijk gegeven op het ontwikkelingsproces van een gecompliceerde softwareapplicatie, waarbij een gedetailleerde planning van essentieel belang bleek. Zonder deze planning - duidelijk vastgelegde deadlines en taakverdelingen - zou het werk nooit zijn af geraakt.

Als gevolg van wijzigingen in het ontwerp en implementatie is de planning gedurende het project verscheidene keren aangepast moeten worden. Dit was uiteraard te verwachten. Aangezien er in de oorspronkelijke planning met brede tijdsmarges was gewerkt, konden mensen makkelijk naar andere projecten verschoven worden. De planning was een rode draad die noodzakelijk was voor een goed verloop. Het werd nogmaals duidelijk dat je de geïnvesteerde tijd er later sowieso weer uithaalt.

In het eerste kwart van de ontwerpcyclus was er een heleboel verwarring doordat niet iedereen hetzelfde concept in gedachten had. Hierdoor was het moeilijk om een duidelijk klassendiagram samen te stellen wanneer sommige features zelfs nog niet zeker waren. Zo bleek dat muziek een vereiste was, terwijl andere zaken werden weggelaten (LocationManager voor uitgebreidere status). Ook was er onduidelijkheid over de mogelijkheden van Android en of bepaalde features mogelijk waren binnen de tijdspanne die we voor ogen hadden. Meer research was dus nodig.

Op een bepaald punt heeft de groep dan zichzelf samengeroepen en is samen de productomschrijving neergeschreven en een feature preference list opgesteld. Duidelijke afspraken waren nodig om dubbel werk te vermijden en niets over het hoofd te zien. De lessen die hieruit getrokken moeten worden, is dat goede communicatie levensnoodzakelijk is om een vlot verloop te verzekeren.

De informatiebalans, de verhouding van wat elk teamlid weet over elk aspect van de applicatie, moet optimaal zijn. Niemand kan als het ware “alles over alles” weten, maar iedereen moet over alles wel iets kunnen zeggen, en de globale werking begrijpen. In het begin werd er teveel gefocust op het eigen gebied. Naarmate dat de verschillende onderdelen werden samengebracht, was het geen voordeel, maar een vereiste om over voldoende inzicht in de werking van beide onderdelen te beschikken en erover te kunnen communiceren.

Een initieel ondergewaardeerd aspect was zeker documentatie; enerzijds het schrijven, maar toch vooral het lezen van uitleg bij codefragmenten, klassen en methodes. Een zekere ‘haast’ (mogelijk gerelateerd met de tijdsdruk) dreef velen er toe vaak onbezonnen te werk te gaan en als het ware een sprong in het diepe te maken. Daarna was het opletten dat men niet kopje onder ging in hun eigen code.

Door dit op tijd in te zien en over te schakelen op een meer beredeneerde (sommigen zouden zeggen wijze) manier van werken, is de efficiëntie van het team enorm toegenomen. Dit was niet enkel te zien aan de hoeveelheid code, maar ook aan het aantal bugs die tegelijk eruit gefilterd werden. Het aantal voltooide features volgde elkaar in een snel tempo op.

Natuurlijk legde dit een druk op het testen van onze applicatie, waarvan we vooraf wisten dat het cruciaal was voor succes. De aparte onderdelen waren dan wel getest voor ze samen werden gebracht, maar dan begon vaak pas het echte werk. Er was gezamenlijk afgesproken om een aantal gekende technieken te gebruiken bij het coderen, zoals simuleren van nog niet bestaande of werkende onderdelen, gebruiken van LogCat (de console voor debug output van het systeem), handmatig de console doorlopen, breakpoints gebruiken, ...

Het voordeel was dat zo samen in het debugproces kon gewerkt worden. Aangezien vaak twee delen werden samengevoegd die door twee verschillende mensen waren gemaakt, was de gezamenlijke kennis nodig en dus ook de noodzakelijkheid dat beiden dezelfde technieken beheersten. Ook was het testen opgedeeld in twee aparte onderdelen: het opnemen van de route en het uitvoeren. Daardoor konden twee teams probleemloos naast elkaar werken.

Het spreekt voor zich dat GeoMedia de studenten heel wat heeft bijgebracht over programmeren in Java en werken met Android in het algemeen. Ook met programma’s als Eclipse, Visual Paradigm en de Linux-based OS Ubuntu is het grootste deel vertrouwd. Zo zijn nu enkele Windows-gebruikers overgeschakeld naar Ubuntu op hun eigen desktops. Open-source software werd ook een bekend begrip naarmate we zelf gebruik maakten van ander hun werk in de vorm van externe bibliotheken of gewoon Android op zich al. Dat op zich is al een levensles voor iedere zichzelf respecterende programmeur.

10. Appendix: geleverde werk

Figuur 2: mindmap van ons idee

Figuur A.3: het volledige klassendiagram