Android Toepassing Groep 5 Maarten Decat
Thomas De l’Arbre
1e Master Ingenieurswetenschappen: Computerwetenschappen Optie Gedistribueerde systemen
3e Bachelor Informatica Minor Verbreding
[email protected] Benjamin Slegers
[email protected] Wouter Theetaert
1e Master Ingenieurswetenschappen: Computerwetenschappen Optie Gedistribueerde systemen
1e Master Ingenieurswetenschappen: Computerwetenschappen Optie Gedistribueerde systemen
[email protected]
[email protected]
ABSTRACT Het vierde en laatste onderdeel van het vak “Multimedia: modelleren en programmeren” richtte zich op het ontwerpen van een applicatie met behulp van Google Android.
een vooraf gedefinieerde omgeving met een GPhone in de hand. Aan de hand van GPS-coördinaten wordt hun positie getraceerd. Alle deelnemers zien op hun scherm een kaart (Google Maps) met daarop de posities van de andere spelers (permanent alle speurders, af en toe Mister X).
Het gebruik van een nieuw ontwikkelplatform – in dit geval zelfs fundamenteel verschillend vanwege de extra mogelijkheden en beperkingen die een GPhone biedt in vergelijking met een gewone pc – vraagt natuurlijk om een nieuw storyboard. Net omwille van de fundamenteel andere eigenschappen die een GPhone biedt, werd zelfs geopteerd om vanuit een totaal nieuw idee te werken.
Er wordt gebruik gemaakt van de verschillende toepassingen die het Android-platform en een GPhone aanbieden: •
GPS: de gebruikers worden aan de hand van hun GPScoördinaten getraceerd en hun positie wordt op de kaart weergegeven.
Er werd getracht om de verschillende aspecten van de mobiliteit van de GPhone optimaal te benutten en tot een harmonieus geheel te smelten. Uiteraard werd de rode draad doorheen het vak, het thema ‘muziek’, niet over het hoofd gezien.
•
Internettoegang: er is een gameserver waar de verschillende deelnemers naar connecteren. Het zou een uitbreiding zijn om bv. high scores online te plaatsen.
•
Lijst van contactpersonen: er kan gecontroleerd worden of er iemand uit de persoonlijke contactpersonenlijst reeds deelneemt aan een bestaand spel.
•
Telefonie: de speurders kunnen onderling met elkaar communiceren door gewoon naar elkaar te bellen.
•
SMS: als alternatief voor de internettoegang kan met sms'en gewerkt worden (om bv. de GPS- en chatdata tussen de verschillende clients door te sturen). Het gebruik van SMS kan een goedkoop alternatief zijn voor een internetverbinding, daar verschillende GSM-operatoren voordelige SMS-tarieven aanbieden (waar mobiel internet vaak erg duur is).
•
Afspelen van muziek.
Het resultaat (de uiteindelijke applicatie) kan online gevonden worden [1].
1. IDEE Aangezien de applicatie die met Flex en mash-ups werd uitgewerkt (het aanbieden van een platform waarop jonge, onbekende bandjes zichzelf kunnen voorstellen) niet gericht is op mobiel gebruik, werd ervoor gekozen om een nieuw concept uit te werken. De ontwikkelde toepassing is een variant op het bordspel 'Mister X' (ook bekend onder andere namen, bv. 'Scotland Yard'). Het is de bedoeling dat één deelnemer, Mister X, uit de klauwen blijft van de andere deelnemers (de speurders). Mister X is op elk moment op de hoogte van de posities van de speurders, terwijl laatstgenoemden maar om een bepaald aantal minuten zien waar Mister X zich op dat moment bevindt. Mister X wint het spel als hij een bepaalde locatie kan bereiken voor hij gesnapt wordt, de speurders winnen als ze Mister X insluiten en 'doden' (door dicht genoeg in zijn buurt te komen). Dit spel kan een stuk interactiever worden als de deelnemers niet langer pionnen op een spelbord gebruiken, maar in realiteit op zoek gaan naar Mister X. Ze kunnen zich dan verplaatsen binnen
Om de voeling met het concept "muziek" niet helemaal te verliezen, werd deze multimediavorm ook een plaats in het project toebedeeld. De muziek die de speurders horen is afhankelijk van hun huidige afstand tot Mister X. Als ze ver van het target verwijderd zijn, weerklinkt rustige muziek. Hoe dichter ze bij Mister X komen, hoe spannender de muziek (analogie "warm koud").
Het gebruik van een GPhone brengt het bordspel tot leven. Het is voor de gebruiker veel aangenamer om zelf in het spel te duiken en actief deel te nemen. Het feit dat dergelijke concepten reeds uitgewerkt zijn (bv. als teambuilding-activiteit) bewijst dat hier wel degelijk een markt voor is. De implementatie van ons team heeft als voordeel dat de prijs voor een dergelijke activiteit kan gedrukt worden: iedereen downloadt gewoon het spel op zijn GPhone en er kan gespeeld worden.
2. STORYBOARD Bij het uitwerken van een storyboard dient rekening gehouden te worden met de beperkte grootte van het scherm van een GPhone. Er mogen niet teveel data-items in één keer tegelijk worden weergegeven, anders kan de leesbaarheid te slecht worden. Het storyboard is op ware grootte opgenomen als bijlage bij dit verslag. In de tekst wordt met behulp van verkleinde figuren verwezen naar de juiste pagina uit het storyboard. De gebruikte menustructuur en globale lay-out is vrij eenvoudig: het is de bedoeling dat de gebruiker zich volop op de omgeving kan concentreren en enkel noodzakelijke info krijgt via zijn mobiele toestel. Tijdens het grootste gedeelte van het spel wordt de beschikbare schermruimte dan ook vooral door een kaart ingenomen.
Figuur 2: Deelnemen aan een bestaand spel Na het kiezen van het gewenste spel, komt de deelnemer op het scherm dat eruit ziet zoals weergegeven in figuur 3. De gebruiker kan chatten met andere deelnemers, en ziet ook de andere conversaties op het scherm verschijnen. Deze worden afgewisseld met systeemberichten.
Wanneer de gebruiker de toepassing start, komt hij terecht op een scherm zoals weergegeven in figuur 1. Er zijn drie mogelijke keuzes: ofwel wordt een nieuw spel gestart, ofwel neemt de gebruiker deel aan een bestaand spel, ofwel verlaat hij de applicatie.
Figuur 3: Chatvenster
Figuur 1: Startscherm Wanneer de gebruiker ervoor gekozen heeft deel te nemen aan een bestaand spel, krijgt hij/zij een overzicht van alle spelen waar het maximaal aantal deelnemers nog niet bereikt is (figuur 2). Via het tekstinvoer-venster kan de gebruiker gericht op zoek gaan naar het juiste spel (gebruik van een filter). Deze filter is niet opgenomen in de uiteindelijke applicatie, omdat er wordt vanuit gegaan dat er nooit zodanig veel spelen beschikbaar zullen zijn op een bepaalde locatie dat het gebruik van een filter voordeel biedt.
Het scherm zoals weergegeven in figuur 3 wordt getoond zolang er niet genoeg spelers aanwezig zijn om het spel te starten. Wanneer dit aantal wel bereikt is, krijgt elke speler een scherm te zien zoals in figuur 4. Er wordt een kaart getoond, met daarop de beginpositie van de speler in kwestie. De speler dient zich naar dat punt te begeven. Aan de hand van zijn GPS-coördinaten wordt gecontroleerd of hij al dan niet op de locatie aanwezig is. Onder de kaart worden systeemberichten weergegeven, bv. indien een medespeler zijn beginpositie bereikt heeft.
Figuur 4: Startpositie Figuur 6: Spelscherm Wanneer elke speler zich op de juiste beginpositie bevindt, kan het spel echt beginnen. Er verschijnt een aftelklok op het scherm, die elke speler aanmaant om zich klaar te houden (figuur 5).
Het laatste scherm uit het storyboard (figuur 7) stelt de persoonlijke doelen van de deelnemer in kwestie voor. Dit is een lijst van plaatsen die een speler kan bereiken en waarvoor hij extra voordelen krijgt. Er is eveneens aangegeven of de plaats in kwestie al door een andere speler is bezocht (door middel van een vinkje). De deelnemers kunnen ook zien wanneer het target opnieuw zichtbaar wordt. Dit scherm biedt bovendien mogelijkheid tot uitbreidingen: hier kan meer info komen dan enkel de doelen die er nu staan.
Figuur 5: Aftelklok Het scherm uit figuur 6 wordt gedurende het ganse spel weergegeven. De speler ziet een kaart van de spelomgeving, met daarop de eigen positie en die van de medespelers waarvan de deelnemer op dat moment de positie mag kennen. Er is ook plaats voor enkele systeemberichten (bijvoorbeeld als iemand een opdracht heeft vervuld). De “shoot”-knop, waarmee een speurder het target kan doden, is prominent aanwezig op het scherm van een speurder (deze knop is uiteraard niet aanwezig bij het target zelf). Dit is eveneens het geval voor de knop “goals” die de deelnemer naar het scherm met zijn persoonlijke opdrachten leidt (figuur 7).
Figuur 7: Persoonlijke doelen
3. SOFTWARE-O/TWERP Er moet eerlijkheidshalve toegegeven worden dat een degelijk software-onwerp niet de voornaamste zorg geweest in dit project. Het werken met de API leverde af en toe verwarrende fouten op, bijvoorbeeld bij het in werking stellen van nieuwe Acitivities. Om die belemmeringen te vermijden, werd het totaal van het ontwerp is onderbracht in slechts twee klassen: TheTargetMenu.java en Game.java. Het bijhorende klassendiagram is gegeven in figuur 8. Het is eveneens op ware grootte toegevoegd als bijlage bij dit verslag.
Omdat het ontwikkelen van de GUI zo'n langdurig werk was, is er voor gekozen om alleen maar de schermen te ontwikkelen die nodig waren voor een demo. In casu is dat een startscherm, een scherm om een spel te joinen, twee tussenschermen naar het spel en het scherm van het spel zelf. Er waren nog heel wat extra mogelijkheden om nuttige menu's, optieschermen, enz. te ontwikkelen, maar wegens tijdsgebrek zijn die niet uitgewerkt.
Figuur 8: Klassendiagram Beide klassen erven over van MapActivity, dewelke op zijn beurt een subklasse is van Activity. Een Activity is de basiseenheid van een Android programma. Op elk moment kan slechts een Activity in uitvoering zijn. Een Activity kan een andere opstarten waarbij de nieuwe de uitvoerende wordt. Bij afsluiten van een Activity neemt zijn opstarter terug over. Op deze manier wordt een stackstructuur van uitvoerende Activities gevormd. Google Maps kan slechts gebruikt worden in MapActivities, wat verklaart waarom deze klasses daarvan overerven. TheTargetMenu implementeert meer specifiek het menu van de applicatie, van het startmenu tot het begin van een eigenlijk spel. Hierna wordt een Game Activity gestart die het eigenlijke spel bevat. Naast de twee grote klasses die hiervoor vermeld zijn, is op het klassendiagram ook de klasse Marker te zien. Deze klasse stelt een marker op een Google Maps kaartje voor en laat toe gemakkelijk locaties op de kaart aan te duiden. Op dit moment wordt deze klasse enkel gebruikt in TheTargetMenu. Game bevat ook kaartjes maar deze zijn in de demo nog niet bevolkt met markers. In de uiteindelijke applicatie moet dit uiteraard wel gebeuren. Dit ontwerp levert zoals gezegd twee grote klassen die het hele ontwerp behelzen. Dit is niet de beste ontwerpstrategie voor grotere softwareprojecten maar het leverde hier wel een degelijke snelheidswinst op. Moest The Target het ooit echt halen tot een volwaardige Android-applicatie, zou dit echter wel met de juiste design patterns gedaan worden.
4. IMPLEME/TATIE Tijdens de implementatie zijn er een aantal problemen geweest waarvan het oplossen veel tijd heeft gekost. Vooral het creëren van de GUI, het gebruik van Google Maps en GPS en het implementeren van een muziekspeler heeft heel wat tijd gevraagd. Uiteindelijk is het wel gelukt om een werkende demo van het spel af te krijgen, waar alle data 'hard coded' in werd geïmplementeerd. Een van de elementen dat het meeste tijd heeft gekost, was het ontwikkelen van de GUI. Het systeem waarbij alles dubbel neergeschreven moet worden, één keer in het XML-bestand en één keer in de Java-code zorgt voor veel overhead. Deze manier van werken zorgt natuurlijk wel voor een meer uitbreidbaar en logisch duidelijker resultaat, maar in een project met een strakke tijdsplanning misschien eerder een vertraging dan een voordeel. Zeker in vergelijking met de 'drag and drop'-werking zoals die bijvoorbeeld in FlexBuilder gebruikt kan worden, is het schikken van de menu's voor de gebruiker heel traag.
Het gebruiken van Google Maps in Android ging ook niet onmiddellijk van een leien dakje. Hoewel Google Maps eerder ook al in de mash-up gebruikt werd, hielp deze kennis niet echt in Android omdat het gebruik van de API sterk verschilde. Terwijl het gebruik van de AP in de mash-up nogal straightforward was, waren bij Android heel wat extra elementen nodig. Zo moet er onder andere in de 'manifest'-file vermeld worden welke packages geïmporteerd worden en welke extra permissies de applicatie nodig heeft. Een ander probleem, waar de oplossing veel tijd vroeg, is het feit dat de Google Maps in Android de klassieke Google Mapsmarkers niet ondersteunen. Om een vergelijkbaar effect te krijgen moet de ontwikkelaar in Android zelf zijn markers tekenen, wat beduidend ingewikkelder is dan de werking met markers in de klassieke Google Maps. Het heeft een tijdje geduurd eer de GPS-toepassingen die Android aanbiedt gebruikt konden worden. Het teamlid dat verantwoordelijk was voor het implementeren van het GPSgedeelte kon de dummy-data die nodig zijn om de GPS te gebruiken niet testen. Herinstalleren van zowel Eclipse als de Android-SDK in Ubuntu en in Windows heeft niet geholpen dit probleem op te lossen. Uiteindelijk zijn er dan verantwoordelijkheden doorgeschoven, zodat iemand anders zich op de GPS kon concentreren. Op andere pc's waren er immers geen problemen met de testdata. Het laatste probleem dat vermeldenswaardig is, was het implementeren van een aftelklok die gebruikt wordt als begin van het spel. De eerste bedoeling was om deze klok zelf met behulp van threads in Java te implementeren. Dit leek eenvoudiger dan het zoeken en leren gebruiken van een bestaande klok. Na een aantal testen bleek echter dat de eigen implementatie niet werkte. Daarom is er uiteindelijk wel besloten om gebruik te maken van een voorgedefinieerde klasse voor Android, namelijk 'CountDownTimer'. Het gebruik van deze hulpklasse loste alle problemen met de counter op. Wegens de beperkte tijd is er voor gekozen om niet het hele spel te implementeren, maar alleen een demo waarin de bedoeling van het spel duidelijk gemaakt kan worden. In dat opzicht is er voor gekozen om de demo gebruik te laten maken van 'hard coded' data in plaats van echte data te zoeken en te verwerken in de applicatie. Een voorbeeld van deze dummy-data is de beweging van de medespelers op het spelscherm. Deze bewegingen zijn gedefinieerd in de Java-code, en zijn niet gebaseerd op realistische bewegingen.
5. RESULTAAT Dit project heeft nogmaals geleerd dat het bedenken van een concept gemakkelijker is dan het effectief implementeren ervan. Uiteindelijk is een applicatie gemaakt die een idee geeft van hoe het geheel er zou moeten gaan uitzien, maar niet alle onderdelen werken effectief. Het bleek immers erg moeilijk om eenvoudige dingen als een menustructuur in Android te maken, waardoor er
weinig tijd overbleef om aan de implementatie van de verschillende onderdelen te werken. De globale menustructuur, de ‘kapstok’ waaraan het hele spel vast hangt, is er uiteindelijk wel gekomen. Het is mogelijk om door het menu te navigeren en een idee te vormen van hoe het spel zich zou gedragen. Alle knoppen zijn bijvoorbeeld aanwezig. Verschillende data is echter hardcoded in de gepresenteerde oplossing opgenomen. De chatvensters zijn niet dynamisch: het is dus niet mogelijk om nieuwe tekst te laten verschijnen. Ook de verschillende systeemberichten en de doelen die een deelnemer kan bereiken zijn in de voorbeeldapplicatie ingebakken. Uiteindelijk is het niet zo belangrijk om tijd te stoppen in dergelijke zaken: het team heeft voeling gekregen met het product ‘Android’ en de mening hierover zou niet gewijzigd zijn na het implementeren van verdere functionaliteit in het programma. Een aantal losse onderdelen zijn wel afzonderlijk getest en werkend bevonden. Zo is het mogelijk om de huidige positie van de deelnemer op te vragen met behulp van de ingebouwde GPS. Het spreekt voor zich dat deze op de emulator aangestuurd wordt door (zelfbepaalde) dummy-data. Het is eveneens mogelijk de gewenste posities weer te geven op een kaart. Hiervoor werd gebruik gemaakt van de technologie die Google Maps aanbiedt. Aangezien reeds eerder (met name bij de mash-up-implementatie) met Google Maps was gewerkt, was er deze keer een vrij lage instapdrempel. Er moet wel opgemerkt worden dat er verschillen in functionaliteit zijn tussen de Google Maps in een webomgeving en de Google Maps op Android (bijvoorbeeld bij het gebruik van markers). Een ander werkend onderdeel is de aftelklok. Hoewel het een banaal implementatiedetail lijkt, leverde dit toch enkele problemen op. Het is niet zo eenvoudig om op Android met verschillende threads te werken. Of – en die kans is reëel – er is door ons team te weinig diep op ingegaan. Gelukkig bracht een voorbeeldimplementatie op het wereldwijde web soelaas. Tenslotte dient opgemerkt te worden dat er doorheen de hele applicatie muziek te horen valt. Hiervoor werd gebruik gemaakt van de interne muziekspeler, die vrij eenvoudig aan te spreken bleek. Wanneer de applicatie wordt gerund op een echte GPhone, zou dit onderdeel alvast geen noemenswaardige problemen mogen opleveren. Al bij al is de implementatie vrij vlot verlopen. Dankzij de lage instapdrempel van Java bleven syntax-moeilijkheden achterwege en kon vrij rap op de functionaliteit gefocust worden. Omwille van de beperkte tijd is niet alles uitgewerkt en zijn sommige delen hardcoded in de applicatie verwerkt, maar er is getracht om met de werkende delen aan te tonen dat het team weldegelijk kennis heeft gemaakt met de Android-technologie.
6. A/DROID Android gebruikt een degelijke Java API in combinatie met een uitgebreide emulator en Eclipse plugin om de ontwikkeling van applicaties te vergemakkelijken. Het gebruik van Java als programmeertaal verlaagt in de eerste plaats de instapdrempel tot het schrijven van werkende code. De emulator is een broodnodige tool voor het ontwikkelen van Android-toepassingen. Het zou praktisch onmogelijk zijn applicaties steeds te moeten testen op een volwaardige GPhone. De emulator heeft bovendien de moeilijke opdracht van het ondersteunen van bijvoorbeeld GPS,
SMS en internettoegang op elegante manieren opgevangen. Zo is het bijvoorbeeld mogelijk dummy GPS-data naar de emulator te sturen, wat het mogelijk maakt de applicatie te testen in een zeer groot aantal verschillende toestanden. Het feit dat het hele Android-pakket toelaat om zonder uitgebreide kennis van smartphones toch een applicatie te schrijven die gebruik maakt zowat alle mogelijkheden die de GPhone biedt, is een heel sterk punt van de Android-omgeving. Het biedt geen onoverkomelijke moeilijkheden om bijvoorbeeld SMS, GPS, internet, contactlijsten of de agenda te aan te spreken, al deze zaken zijn voorzien in de uitermate handige Android API. We kunnen besluiten dat de gedane ervaring met Android als ontwikkelomgeving positief was. De enige opmerking die gemaakt kan worden is dat er nog een degelijke drag-and-drop designtool ontbreekt. Dit zou de ontwikkeling van GUI's sterk versnellen. Afgezien daarvan biedt Android een enorm gamma aan mogelijkheden die op een eenvoudige manier benut kunnen worden en bovendien in een strak jasje gegoten kunnen worden.
7. ERVARI/G Het einde van het semester brengt traditioneel papers, deadlines en ander leuks met zich mee, waardoor er aan het Android-project minder buiten de sessies gewerkt is dan aan de vorige projecten. Het grootste gedeelte van de implementatie vond plaats tijdens de sessies zelf. Net zoals bij de vorige projecten werd het project opgedeeld in logische eenheden, zodat iedereen volgens zijn eigen planning kon werken (daarbij het geheel niet uit het oog verliezend). Die opdeling bleek goed gekozen, aangezien het samenbrengen van de verschillende entiteiten niet echt grote problemen met zich heeft meegebracht. Omwille van het tijdsgebrek zijn bepaalde delen van het project niet tot in de puntjes uitgewerkt en kan hier en daar hardcoded informatie worden gevonden. Voor bepaalde onderdelen verliep de implementatie trager dan verwacht: de documentatie van Android leek op het eerste zicht erg nauwkeurig, maar al gauw bleek dat het vaak nodig was om voorbeelden en tutorials af te schuimen vooraleer iets degelijk werkte. Het team heeft echter getracht de beschikbare tijd zo goed mogelijk te benutten en er is dan ook vooral naar de demo toe gewerkt: het bekomen resultaat biedt de mogelijkheid om weer te geven hoe de echte applicatie eruit zou zien, zonder dat daarbij elk detail werkt. De belangrijkste onderdelen (GPS, map, menustructuur, muziek) werden wel werkend gekregen. Als het Android-project opnieuw zou starten, zou waarschijnlijk voor dezelfde keuzes geopteerd worden.
8. GLOBALE FEEDBACK Onze algemene indruk over dit vak was positief: het was een fijn vak waarin meerdere interessante technologieën aan bod kwamen. Naast de positieve punten kunnen er echter wel enkele bijkomstige opmerkingen gegeven worden. De inhoud van het vak is een positief punt. Het vergelijken van meerdere technologieën maakt het beeld op de informatica een pak ruimer. De meeste onderwerpen in dit vak klonken op voorhand al bekend in de oren maar bleken daardoor niet minder interessant. Flex, Android en Mash-ups zijn stuk voor stuk technologieën die door een groter publiek gebruikt worden maar toch ook hun nut kennen voor meer gespecialiseerde gebruikers.
Dit is misschien één van de belangrijkste bijdragen van het vak: aantonen dat er nog een wereld is buiten Java. Wel kan hierbij opgemerkt worden dat het maken van een grotere applicatie waarbinnen de verschillende technologieën passen een verbetering zou vormen, als zo'n applicatie natuurlijk niet té hard bij de haren getrokken is. We kunnen ook een kleine opmerking geven omtrent de werklast. Deze is op zich niet te zwaar maar er mag wel meer geschikt worden met de examens en andere vakken in het achterhoofd. Niet alle technologieën vereisen even veel werk en het zou aangenamer zijn de minder belastende delen naar het einde van het semester te verschuiven. Deze tijd durft er in het algemeen al hectisch aan toegaan. De manier van feedback geven in dit vak valt ook als voordeel aan te halen. Op het eerste zicht lijkt het schrijven van verslagen eerder een overhead dan een bijdrage aan het vak. Dit is in onze ogen echter een misopvatting. Voor het eerst in de opleiding wordt er namelijk gegronde en uitgebreide commentaar gegeven op die verslagen! Het schrijven van goede verslagen is een noodzaak voor het juist overbrengen van informatie en is daarom ook iets wat de studenten van vandaag zo snel mogelijk onder de knie moeten hebben. Het was daarom zeer positief dat hier de nodige hoeveelheid aandacht aan werd besteed. Dit kan trouwens ook gezegd worden over het werken in team. Teamwerk is eveneens een vaardigheid die niet sterk genoeg benadrukt kan worden. Om een team op één lijn te houden en het teamwerk zo vlot mogelijk te laten verlopen, bestaat een ruim gamma aan technieken waarvan tot nu toe maar een klein aantal is aangehaald. Het was dan ook zeer nuttig eens te brainstormen, een wiki op te stellen, een story board te maken etc. Of we een medestudent zouden aanraden dit vak te volgen, hangt af van zijn/haar interesses. De meerwaarde van het vak is geen diepgaande kennis van de aangeboden technologieën maar eerder een ruimere blik op wat allemaal mogelijk is, gecombineerd met een welgekomen training in teamwork en verslagen schrijven. Als hij/zij op een interactieve manier en met de nodige hulp een aantal nieuwe aspecten van de informatica wilt ontdekken is dit zeker een aan te raden vak. Als hij/zij echter de meer technische vakken opzoekt, zijn er misschien betere keuzes.
APPE/DIX A. APPE/DIX: TIJDSBESTEDI/G De volledige en gedetailleerde tijdsbesteding voor groep 5 kan gevonden worden op de wiki-pagina van de groep (doorklikken via ‘Tijdsbesteding’ [2]. De tijdsbesteding zoals hieronder in de tabel aangegeven geldt enkel voor het derde deel van de cursus, de Androidimplementatie. Zoals eerder in het verslag aangehaald is het meeste werk gedurende de sessies gebeurd. Iedereen was elke sessie aanwezig, de verschillen die opduiken zijn te wijten aan laat aankomen of langer doorwerken na de sessie. Het werk buiten de sessies werd opgesplitst. Maarten heeft zich intensief bezig gehouden met het implementeren van de menustructuur, de rode draad doorheen het project. Hij heeft er eveneens voor gezorgd dat alle aparte onderdelen werden samengevoegd tot een werkend geheel. Wouter heeft in het begin uitgedokterd hoe de GPS van Android werkte. Omwille van onvoorziene computerpech heeft Benjamin die taak overgenomen, en daaraan ook het stuk rond Google Maps gebreid. Thomas was de persoon die zich bezighield met het afspelen van de muziek. Uiteindelijk heeft Wouter hierbij geholpen tot het geheel werkte. Iedereen heeft geholpen bij het schrijven van het verslag, en Wouter heeft de verschillende onderdelen samengebracht en waar nodig aangepast. /aam
Binnen sessie
Buiten sessie
Maarten
13.5u
14.5u
Thomas
13.5u
4u
Benjamin
14.5u
7.5u
Wouter
12.5u
11u
9. REFERE/TIES [1] De applicatie: Mister X (Android implementatie) http://mdecat.ulyssis.be/TheTargetMenu.zip
[2] Tijdsbesteding Groep 5 op Wiki http://ariadne.cs.kuleuven.be/mediawiki2/index.php/Tij dsbesteding_Groep5
B. APPE/DIX: FIGURE/ OP WARE GROOTTE Zie bijlage op volgende pagina’s.
