FACULTEIT INGENIEURSWETENSCHAPPEN
PROBLEEMOPLOSSEN EN ONTWERPEN, DEEL 3
CWA2 Gerry Hendrickx Xiangyu Gao Blas Gallego Irles Ruben Dezeure Albert Jorissen Bart Embrechts
GeoMedia VERSLAG Co-titularis Prof E. Duval Begeleider(s) Bram Vandeputte Stefaan Ternier Yves Frederix Robrecht Haesevoets Nelis Boucke
A CADEMIEJAA R
2008-2009
1
1. Inhoudsopgave 1.
Inhoudsopgave................................................................................................................................. 2
1.
Wie .................................................................................................................................................. 4
2.
Inleiding........................................................................................................................................... 4 Brainstorm ........................................................................................................................................... 4
2.
Verworpen ideeën ........................................................................................................................... 4 Reclame ........................................................................................................................................... 4 Domotica ......................................................................................................................................... 5 Kaart ................................................................................................................................................ 5 Ervaring ............................................................................................................................................... 5
3.
Productomschrijving ....................................................................................................................... 5 Functionaliteit...................................................................................................................................... 5 Muziek ............................................................................................................................................. 5 Foto/info .......................................................................................................................................... 6 Sharing............................................................................................................................................. 6 Use cases ............................................................................................................................................. 6 Gebruiker loopt rond en verandert van locatie ............................................................................... 6 Het aanmaken van een nieuwe (cirkelvormige) zone ..................................................................... 7 Gebruiker vraagt afbeeldingen van bezienswaardigheden op ........................................................ 7 Domein-model ..................................................................................................................................... 7 Ervaring ............................................................................................................................................... 8
4.
Technologie ..................................................................................................................................... 8 Android................................................................................................................................................ 8 Google Web Toolkit & GWT-Ext & GWT RPC ................................................................................. 8
5.
Ontwerp ........................................................................................................................................... 9 Architectuur ......................................................................................................................................... 9 Klassendiagram ................................................................................................................................... 9 Database-structuur ............................................................................................................................... 9 Ontwerpbeslissingen: Waardeanalyses .............................................................................................. 10 Server – client functieverdeling..................................................................................................... 10 Afbeeldingen.................................................................................................................................. 10 Muziek-selectie ............................................................................................................................. 11 Ervaring ............................................................................................................................................. 12
2
6.
Implementatie ................................................................................................................................ 12 Moeilijkheden.................................................................................................................................... 12 Communicatie tussen klassen ........................................................................................................ 12 Beschikbaarheid java bibliotheekklassen ..................................................................................... 13 Nieuwe SDK.................................................................................................................................. 13 Bugs ............................................................................................................................................... 13 Debugbeperking ............................................................................................................................ 13 Ontwerpbeslissingen ......................................................................................................................... 14 Panoramio vs Flickr...................................................................................................................... 14 Zonemanager, AIDL ...................................................................................................................... 14 Shape ............................................................................................................................................. 14 Updaten van songlist ..................................................................................................................... 14 Ervaring ............................................................................................................................................. 14
7.
Demodag ....................................................................................................................................... 15
8.
Zelfevaluatie .................................................................................................................................. 15
9.
Vakintegratie .................................................................................................................................. 16
10. Besluit ............................................................................................................................................ 16 11. Bijlagen .......................................................................................................................................... 17 12. Agenda ........................................................................................................................................... 19
3
1. Wie Het CWA2-team bestaat uit:
Gerry Hendrickx Xiangyu Gao Blas Gallego Irles Ruben Dezeure Albert Jorissen Bart Embrechts
allen uit de 2de bachelor Burgerlijk Ingenieur 2008-2009.
2. Inleiding Het doel van dit project is het ontwerpen van een intelligente mediaspeler. Hij heeft als primaire functie het afspelen van mediabestanden op basis van de locatie van de gebruiker. Dit is echter enkel de hoofdfunctie. De uitdaging van dit project ligt juist in het feit dat men met een goede combinatie van creativiteit en realiseerbaarheid een product aflevert dat ingenieus en vernieuwend is. Door gericht en efficiënt te ontwerpen gaat men in een beperkte tijd een flexibel softwareproject moeten implementeren dat stabiel, gebruiksvriendelijk en gemakkelijk uitbreidbaar is. Om dit te realiseren zal men in een team werken. Met een duidelijke planning en taakverdeling om het project met succes te voltooien.
Brainstorm Aangezien de grenzen van het concept GeoMedia niet echt vastliggen, is er de mogelijkheid om creatieve ideeën uit te werken en toe te passen in dit project. Deze ideeën worden geboren tijdens de eerste stap van het project,namelijk de brainstorm. Belangrijk bij de brainstorm is dat men nog niet te veel moet fixeren op de concrete uitwerking en de problemen die ermee gepaard gaan, maar enkel op de ideeën zelf. Bij de brainstormsessie wordt er op een hoog tempo nieuwe ideeën gegeven via een mindmap. Het resultaat is een grote collectie van vernieuwende functionaliteiten die de mediaspeler zou kunnen hebben. Pas nadien wordt er een selectie gemaakt van de ideeën: sommige ideeën zijn briljant, maar moeilijk realiseerbaar op kort termijn. Deze ideeën worden zeker niet verwijderd, maar enkel aangeduid als minder belangrijk. Via de software Freemind wordt er een overzichtelijke mindmap gemaakt. Zie Illustration 1
2. Verworpen ideeën Reclame Het idee was om reclame van winkels en restaurants door te geven als men erbij in de buurt komt. Bijvoorbeeld als men naast de alma komt krijgt men het menu van de dag en eventuele aanbiedingen. Zo ook bij winkels die aan koopjes doen. Eventuele link naar de website van de desbetreffende winkel of restaurant. Dit is niet echt media-gerelateerd, maar het zou een mogelijke optie kunnen zijn. (bv. voor versie 2)
4
Domotica Het idee bestaat erin om extra mogelijkheden beschikbaar te maken in het eigen huis. Bijvoorbeeld een stereo die automatisch aangaat als de cliënt binnenkomt. Dit hoort niet echt bij de doelstellingen van het project. Het kan even goed als een aparte applicatie geïmplementeerd worden zonder het gebruik van gps.
Kaart Eerst heerste er twijfel over het al dan niet gebruiken van een kaart om de positie van de client aan te duiden. Aangezien de applicatie eerder media gericht is en men ervan uitgaat dat elk gps-toestel kaarten ter beschikking heeft, wordt er minder op dit aspect gefocust.
Ervaring De brainstorm was heel nuttig om te doen. Er werd niet al te veel gezegd, maar iedereen schreef zijn ideeën op het bord. Hierdoor zijn goede, gedurfde ideeën ontstaan die later geconcretiseerd kunnen worden. Het was aangeraden om niet kritisch te zijn maar dit was niet gemakkelijk. Iedereen dacht immers direct na over hoe we het zouden kunnen implementeren. De positieve kant van de creativiteit is dat er zeker genoeg ideeën waren. Eliminatie achteraf was daardoor ook nodig. De brainstorm was efficiënt en bracht in een korte tijd veel resultaten. Kortom het was een succes.
3. Productomschrijving Functionaliteit Het eindproduct is een intelligente mediaspeler die uitvoerbaar is op een Android-gsm-toestel. De hoofdfunctie bestaat erin media-bestanden af te spelen op basis van de toestand van de gebruiker. Een toestand houdt onder andere plaats, snelheid en gemoedstoestand in. Op basis van deze informatie gaat de speler welbepaalde media-bestanden selecteren en afspelen. Media-bestanden bestaan uit muziekbestanden die reeds op het toestel aanwezig zijn en relevante foto's die via het internet worden bekomen. Uiteraard wordt er rekening gehouden met de gebruiksvriendelijkheid, onder meer zullen de voorkeuren voor de selectie aanpasbaar zijn. Deze functionaliteit heeft wel een lagere prioriteit. Het programma zal dus bestaan uit twee grote delen. Het eerste deel is verantwoordelijk voor de muziek. Het tweede deel zorgt voor de foto's en de bijhorende informatie. De functionaliteit van het hele programma wordt weergegeven in het domein-diagram.
Muziek Het muziek-deel heeft als belangrijkste taak muziek af te spelen afhankelijk van de huidige toestand van de gebruiker. Onder de toestand wordt er enerzijds de positie van de gebruiker en anderzijds zijn vervoersmiddel verstaan. Hier zal het systeem onderscheid maken tussen: auto, fietsen, joggen en wandelen. Als secundaire middelen om het systeem nauwkeuriger te maken of meer functionaliteit te kunnen bieden zou er gebruik kunnen gemaakt worden van tijd en gemoedstoestand. Aan de hand van de toestand van gebruiker zullen liedjes worden geselecteerd en in de spelende playlist worden bijgevoegd. En zo worden afgespeeld door het toestel. Dit met alle standaard features zoals play/stop/pauze enz... Ook zal men de optie hebben om liedjes te beoordelen met sterren. Het algoritme dat op basis van de toestand van de gebruiker liedjes suggereert zal gebruik maken van velden die aan een coördinaat zijn toegewezen. Ieder veld heeft een straal en een 5
veldsterkte en zal ook het vervoersmiddel als parameter bevatten. Aan ieder veld worden genres toegewezen. Hierna wordt gekeken of er muziek in de Android muziekbibliotheek zit die aan de genres voldoet. Vervolgens worden er liedjes geselecteerd waarbij er rekening wordt gehouden met de rating van het liedje. Als dit allemaal is voldaan, worden de liedjes in de huidige media-player gezet, en zo afgespeeld.
Foto/info Deze functie geeft een foto en de bijhorende informatie over naburige gebouwen, landschappen, monumenten enz... De foto's zullen foto's zijn die een “geotag” hebben, welke live van het internet (bv. flickr) zullen worden gehaald, dit binnen een bepaalde straal. Als er informatie is te vinden over de locatie, zal deze ook worden weergegeven. Deze functionaliteit kan de gebruiker aan en af zetten.
Sharing Dit deel is optioneel. Gebruikers zouden hun locatie-instellingen (welke muziek men waar wil horen, dit aan de hand van de genres en velden) kunnen uploaden samen met sleutelwoorden. En andere gebruikers zouden deze dan kunnen afhalen. Bv Ik upload mijn velden van het park van Leuven. Ik geef deze dan de woorden 'park' en 'Leuven'. Als er dan andere mensen naar Leuven komen of de locatie-instellingen van andere mensen willen hebben,zouden zij kunnen zoeken op 'Leuven', 'park' en dan mijn locatie-instellingen afhalen. In het domein diagram wordt dit deel voorgesteld door een 1-1 relatie tussen gebruiker en online profiel. Eén gebruiker heeft dus één online profiel waarin alle toestanden (dus ook alle opgeslagen zones met de bijhorende genres) worden opgeslagen. Alle andere gebruikers kunnen dus naar het profiel van de andere users surfen en hun instellingen downloaden en importeren op hun Android.
Use cases Met behulp van use cases kan men de functionele vereisten van het systeem nader toelichten. Ze beschrijven de interactie tussen de primaire actor en het systeem, waarvan de interne werkwijze geabstraheerd wordt. Dit is een nuttige en frequent gebruikte tool bij software engineering. De drie belangrijkste zijn hieronder toegevoegd, de andere zijn schematisch weergegeven in het use-case-diagram. Zie Illustration 3.
Gebruiker loopt rond en verandert van locatie Primary Actor: Gebruiker Stakeholders and Interests: •
Gebruiker: De playlist van de gebruiker wordt aangepast
Preconditions: Gebruiker heeft getagde liedjes op zijn toestel staan en heeft enkele zones definieerd. Success Guarantee (Postconditions): Output naar gebruiker is aangepast aan nieuwe zone Main Success Scenario (or Basic Flow): 1. Gebruiker wandelt rond.
6
2. Wanneer hij in een nieuwe zone (gebied waar bepaalde media mee geassocieerd zijn), wordt de output (de media) aangepast
Het aanmaken van een nieuwe (cirkelvormige) zone Primary Actor:Gebruiker Stakeholders and Interests: •
Gebruiker: Wilt handmatig een nieuwe cirkelvormige zone aanmaken.
Preconditions: Er moet een locatie opgeslagen zijn geregistreerd met de GPS. Success Guarantee (Postconditions): De nieuwe zone werd aangemaakt met erin een locatie, straal en het bijhorende genre. Main Success Scenario (or Basic Flow): 1. 2. 3. 4. 5.
Gebruiker selecteert op de kaart waar hij een zone wil maken Gebruiker geeft in wat de straal van de zone moet zijn Gebruiker bepaalt het genre Gebruiker bevestigt De zone wordt opgeslagen in de database.
Gebruiker vraagt afbeeldingen van bezienswaardigheden op Primary Actor:Gebruiker Stakeholders and Interests: •
Gebruiker: Wilt foto's van bezienswaardigheden in de omgeving zien
Preconditions: Er moet een locatie opgeslagen zijn geregistreerd met de GPS. Success Guarantee (Postconditions): Er wordt een foto van een bezienswaardigheid getoond Main Success Scenario (or Basic Flow): 1. 2. 3. 4.
Gebruiker klikt op de knop 'Panoramio' Er wordt een lijst van bezienswaardigheden getoond. De gebruiker klikt op een item De afbeelding wordt getoond
Domein-model Het domein-model is een mooie weergave van verbanden tussen de design-concepten van de applicatie. Elke rechthoek staat voor een concept en de lijnen geven de verbanden weer. Een verband kan een one-to-many(1 →*), one-to-one(1 → 1) of many-to-many(*→*) verband zijn. Het programma gaat uit van een gebruiker of persoon. Deze heeft bepaalde instellingen zoals of hij al dan niet de muziek-functie wilt opzetten, of hij de foto-functie wilt opzetten,… 1 persoon heeft 1 set instellingen. Een persoon heeft ook een status die verandert doorheen het programma (als de gebruiker van zone verandert en dergelijke). In de status van de gebruiker zit onder andere zijn locatie. Als de gebruiker dan in een bepaalde zone komt, zal er muziek spelen. Elke zone kan maar 1 muziekgenre hebben, maar zones kunnen overlappen. Als een gebruiker dus in een zone zit, zullen alle liedjes van dat genre afspelen. Door tijdgebrek is er geen rating-systeem gekomen, maar normaal had men dus elk liedje een beoordeling kunnen geven. Een status bevat ook een locatie, een gemoedstoestand en een snelheid. Op basis van snelheid wordt het transportmiddel bepaald en op basis van locatie gaat het programma foto's en info geven van jouw locatie. Als extra zou de gebruiker ook zijn zones kunnen uploaden 7
naar een website, waar andere personen dan jouw zones kunnen implementeren op hun toestel. Zie Illustration 4
Ervaring Door alle seminaries is het overgaan van de brainstorm naar een product-omschrijving veel moeilijker gegaan dan als dit op kortere tijd zonder zoveel intermezzo's was gegaan. Door de vele tijd tussen de twee fase, was er een wildgroei aan ideeën ontstaan. Doordat er vele keren steeds te kort werd gediscuteerd, was er ook niet echt een mogelijkheid om dit in te dijken, aangezien de tijd om was tegen dat iedereen zijn nieuwe ideeën had aangebracht. Het voordeel aan die tijd was wel dat er steeds nieuwe ideeën bijkwamen. Zo zeker geen tekort was aan inspiratie. Ook was het hele een goede ervaring om zo eens het hele modelleer-gedeelte mee te maken. In vroegere applicaties begon iedereen direct met programmeren. Dit zou absoluut niet doenbaar geweest zijn bij dit project. Het structureel aanpakken van het hele project gaf ons een zeer goede instap eens we aan het programmeren begonnen.
4. Technologie Android Android is het nieuwe mobiele platform van Google. Het voorziet heel wat basisfunctionaliteit voor de eindgebruiker (bellen, sms, gps, e-mail, ...) maar biedt ontwikkelaars ook de mogelijkheid om eenvoudig applicaties te ontwikkelen. Hiervoor wordt gebruik gemaakt van de Android SDK. Met deze SDK kunnen applicaties gemaakt worden die gebruik maken van zowel software(gezichtsherkenning, telefonie, mediaplayer,...) als hardwarecomponenten (gps, accelerometer, WiFi) van het Android Device. Van de hardware zullen we de GPS en de WiFi Via de ingebouwde GPS kunnen we de huidige locatie van de gebruiker opvragen en zo de muziek aanpassen aan de locatie. Via de internetverbinding kunnen we onze applicatie laten communiceren met de server voor de feedback functie. Van de software componenten zullen de ingebouwde mediaplayer en webbrowser van pas komen. De eerste om de playlists af te spelen, de tweede om informatie te tonen omtrent de huidige locatie. De complexiteit van de terminologie was dan echter een minpunt. Het vereist enige voorkennis om een Android-programma te schrijven. Dit is echter tijdelijk want zodra men vertrouwt geraakt met de werking zou alles vlot moeten verlopen. De structuur van een Android programma verschilt sterk van die van een standaard java programma in de zin dat er niet gewerkt wordt Activities, services
Google Web Toolkit & GWT-Ext & GWT RPC GWT is een enorm handige tool om om web-tools te schrijven. Vb: Een mail-applicatie. Het is nog redelijk nieuw dus er zullen zeker nog wel updates volgen. Bij het zoeken op internet zijn er nog een paar andere alternatieven naar voor gekomen zoals: Echo2, Webcream en J2S. GWT-ext is een uitbreiding van de Google Web Toolkit. Ze voorziet heel wat widgets die het mogelijk maken om op een eenvoudige manier mooie grafische dynamische webpagina’s te maken.
8
GWT-RPC (= Remote Procedure Call) laat toe om van op een client (in ons geval de webbrowser van de gebruiker) een methode aan te roepen op een server (onze Tomcat webserver). In de Google Web Toolkit zit de mogelijkheid om RPC te gebruiken via AJAX. Communicatie met de server kan volledig in java geschreven worden en wordt dan vertaald naar javascript. Ook hier is dus geen kennis nodig van AJAX om toch dynamische websites te kunnen maken.
5. Ontwerp Architectuur De architectuur (Zie Illustration 6: architectuur) van onze applicatie maakt gebruik van de in Android ingebouwde 'Services' (applicaties zonder GUI die op de achtergrond draaien) en 'Activities' (GUI's). De services in onze applicatie zijn StatusProvider, GeoMedia, MusicService en ZoneManager. Deze services hebben geen input van de gebruiker nodig en worden geactiveerd door een verandering van locatie via StatusProvider De Activities zorgen dat de gebruiker toch enige controle heeft over het programma.
Klassendiagram Het klassendiagram (zie Illustration 7: Klassendiagramma/ voor een duidelijkere versie zie wiki) is redelijk uitgebreid. Een grotere versie staat op de wiki (http://ariadne.cs.kuleuven.be/mediawiki/index.php/CWA2-0809#Klassediagram). De applicatie bestaat uit vier grote delen (aangeduid met een verschillende kleur) en één klasse (Geomedia) die het programma opstart. Het statusprovidergedeelte van de applicatie genereert op regelmatige tijdstippen Statusobjecten. Deze objecten worden ingesteld op basis van de huidige locatie, snelheid, gemoedstoestand, etc... . Andere delen van de applicatie gebruiken deze Status-objecten om hun output naar de gebruiker samen te stellen.De andere delen kunnen door via StatusProviderInterface communiceren met StatusProvider. Het Panoramiogedeelte verzorgt het opzoeken en tonen van afbeeldingen van monumenten in de buurt van de huidige locatie. Hiervoor maakt het gebruik van het recentste Status-object. Het haalt de coördinaten eruit en gebruikt dan enkele bibliotheekklassen van Google om foto's op te halen en te tonen. Het muziekdeel van de applicatie (het deel 'achter' MDSInterface) wordt opgestart door StatusProvider. Bij elke significante verandering van toestand, stuurt StatusProvider de recentste gegevens door via MDSInterface.Om de playlist samen te stellen legt MDService verbinding met de ZoneManager via de ZoneManagerInterface. Hierlangs kan MDService de genres ophalen uit de database en op basis daarvan de juiste liedjes toevoegen aan de playlist. De gebruiker kan steeds de huidige playlist bekijken via de MusicDroid Activity. Het zonemanagergedeelte regelt de communicatie met de database. Het is in staat zones toe te voegen, te verwijderen en te updaten.
Database-structuur De database van de applicatie bestaat uit 2 tabellen: Zones en Shapes. Zie Illustration 5: Database structuur. 9
De Zones tabel heeft twee kolommen: _id en genre. _id geeft elke zone een uniek id, dit id wordt gegenereerd door de database zelf (dus niet door de applicatie). Genre bevat de genretag van de liedjes die afgespeeld moeten worden. De Shapes tabel slaat de eigenlijk ruimtelijke gebieden op (het type, de coördinaten, eventuele andere parameters). Deze zijn via de kolom zone_id gekoppeld aan de Zones tabel. Zie Illustration 5: Database structuur
Ontwerpbeslissingen: Waardeanalyses Server – client functieverdeling Men heeft de keuze om bepaalde taken toe te wijzen aan de server, of de specifieke taken lokaal door het toestel(client) te laten volbrengen. Een mogelijkheid bestaat erin om al het denkwerk door de server te laten uitvoeren, en de client enkel de resultaten weergeeft. Hierdoor is de client sterk afhankelijk van de server. Dergelijke client wordt een thin client genoemd. Als tweede mogelijkheid kan men al het uit te voeren werk laten draaien door de client, waardoor het gebruik van een server haast overbodig is. Laatste mogelijkheid is een combinatie van de vorige twee mogelijkheden. Hierbij laat men elk van de beide componenten een deel van het werk doen. Deze drie opties worden beoordeeld aan de hand van de volgende criteria: snelheid uitvoer beschikbaarheid haalbaarheid kosten efficiëntie belasting van de cliënt (bv. batterij, warmteproductie...) belasting van de server(bv. Netwerkbelasting) Voor de laatste twee criteria geldt: hoe hoger het cijfer, hoe minder belasting.
De snelheid van uitvoer van de server is natuurlijk heel hoog, maar wordt beperkt door de verbinding met de cliënt. De beschikbaarheid is het grootst als alles op cliënt draait, aangezien dat hierdoor geen verbinding nodig is met de server. De belasting op cliënt/server volgt logisch uit de verdeling van het werk. De kost is maximaal als er een server nodig is, aangezien het toestel aangekocht wordt door de gebruiker en dat er bij een server kosten kunnen oplopen door onder andere onderhoud. Besluit: Na een uitgebreide analyse van de criteriumwaarden, stelt men vast dat het model met volledig client het meest geschikt is voor de uitwerking van het project.
Afbeeldingen Er zijn 3 mogelijkheden: •
Offline: Afbeeldingen worden lokaal op het toestel bewaard en gelinkt aan een locatie. 10
•
•
Online: De afbeeldingen staan centraal op een server. Het toestel stuurt de coördinaten door naar de server. Indien er op deze locatie relevante afbeeldingen zijn stuurt de server deze naar het toestel. Gedeeld: Op het toestel bevindt zich een database van locaties en id's van eraan gekoppelde afbeeldingen. Wanneer men in de buurt van zo'n locatie komt, worden de coördinaten doorgestuurd naar een server, die dan de specifieke afbeelding doorstuurt.
We gebruiken de volgende criteria: • • • • • • • • •
Up to date (recente foto's) Onderhoud (Achteraf gemakkelijk aan te passen) Bechikbaarheid (Ook beschikbaar wanneer er geen internet is) Haalbaarheid (Realiseerbaar binnen PenO3) Community (foto's van andere providers ... ) Belasting van de client (bv.batterij, warmteproductie...) Belasting van de server(bv. Netwerkbelasting) Kost (Internetverbinding) Gebruiksgemak (Handelingen gebruiker)
Besluit De online methode is duidelijk het meest geschikt voor ons project. Dit komt vooral naar boven door 'up to date' en 'community'. Deze laten toe om steeds de recentst beschikbare foto's te tonen. Hiervoor zullen we gebruik maken van de Flickr-API.
Muziek-selectie Er zijn er 3 mogelijke systemen om muziek te selecteren. Enerzijds kan dit op basis van een genre systeem. Er wordt dus aan een locatie een genre toegewezen. En daarna wordt de muziek gefilterd op basis van dit genre en worden de liedjes die het meest overeenstemmen met de criteria geselecteerd. Omdat de liedjes allemaal 'getagged' zijn (ID3-tags van genre) is het niet meer zo moeilijk om dit te integreren. Anderzijds kan dit gebeuren door een vaste playlist samen te stellen. De locaties worden dan gebonden aan een playlist die door de gebruiker op voorhand is samengesteld. Ten slotte is er de manier van de dynamische playlist. Hier krijgt elk liedje in een bepaalde zone een rating van de gebruiker. Naargelang de rating zal het liedje naar voor of naar achter in de playlist gezonden worden. Deze systemen kunnen geëvalueerd worden op basis van de volgende criteria: • • •
Efficiëntie Flexibiliteit Simpliciteit van integratie
11
Besluit: Omdat zowel het genre-systeem als de dynamische playlist een relatief goede score haalden, zal het project gebaseerd zijn op een combinatie van beide. Een locatie krijgt een bepaald genre (eventueel meerdere) toegewezen. Na selectie van de overeenkomstige muziek, blijven er nog heel wat over. Deze worden dan gesorteerd op basis van rating. De liedjes met de hoogste rating zullen vanboven komen in de playlist en de liedjes met de lagere ratings uiteraard vanonder.
Ervaring Dit deel van het project was nieuw voor velen in het team. De meesten begonnen telkens onmiddellijk te programmeren, maar als je project zo groot is, is deze stap noodzakelijk. We hebben ervaren dat in de ontwerpfase er veel verschillende zichten de functies. De verschillende diagrammen creëren dan een goed beeld van wat het project gaat worden en maakte alles duidelijk voor alle teamleden. Het domein-model is goed om degelijk uit te maken welke functies het programma gaat krijgen en het klassendiagram was een heel goede uitvalsbasis voor het programmeren. Enkel de architectuur werd als minder nuttig ervaren, omdat dit eigenlijk ook in het klassendiagram zit.
6. Implementatie Moeilijkheden Verschillende obstakels traden op tijdens de implementatie. Meestal hadden de problemen te maken met de de nieuwe structuur van Android, die toch wel veel verschilt van het objectgericht programmeren in Java. Soms waren het problemen met de nieuwe versie van de Software Development Kit, die af en toe voor onlogische en vervelende conflicten zorgen . Ondanks deze problemen, werd er geprobeerd om de basis van de applicatie zo succesvol mogelijk uit te werken.
Communicatie tussen klassen Acitivities zijn essentieel in een Androidapplicatie. Elke activity kan beschouwd worden als een bepaald scherm waarop de gebruiker bepaalde acitiviteiten kan laten uitvoeren. Bij de implementatie moet ook elke acitivity als een aparte klasse geïmplementeerd worden. Om de noodzakelijke communicatie tussen de activities mogelijk te maken wanneer de gebruiker overgaat van het ene scherm naar het andere (bv.een zone toevoegen en daarna muziek afspelen) kan men in Android helaas niet gebruik maken van het doorgeven van objecten zoals bij Java. Een intent zorgt voor de essentiele informatie om een service te starten en is noodzakelijk om een goede samenwerking van verschillende acitivities te garanderen. Men kan dus hiermee bij een activity de bijhorende services laten starten en ook acitivities kunnen elkaar laten opstarten, wat nodig is voor een goede werking van de applicatie. Dit lijkt allemaal heel logisch maar in het begin was het niet evident om te redeneren in termen van intents, omdat de mogelijkheden van intents nog niet duidelijk zijn en men de concrete implementatie niet goed kent. 12
Het belangrijkste was dat men de activities en de services door bleef implementeren,ookal werkten ze niet goed samen door gebrek aan goedwerkende intents. Research en tutorials maakten de werking van intents stilaan duidelijk. En tenslotte, nadat de activities en de services van de Geomedia-applicatie vrij onafhankelijk van elkaar reeds een vorm hadden gekregen, werden de intents geïmplementeeerd om voor een succesvolle werking van de applicatie te zorgen.
Beschikbaarheid java bibliotheekklassen Hoewel er gedacht werd dat bijna alle javaklassen bruikbaar zijn in Android, botste men soms toch op iets dat niet beschikbaar was in Android. Voor het fotogedeelte werd eerst beslist om Flickr API te gebruiken om afbeeldingen weer te geven op basis van gps-coördinaten, aangezien dat Flickr over een grote hoeveelheid foto's beschikt van overal ter wereld. Door het feit dat deze API goed gedocumenteerd is, ging alles vrij vlot. De Flickr API maakt gebruik van java.awt en in het bijzonder java.awt.image.BufferedImage om de foto te downloaden. Blijkbaar is de java.awt.image klasse niet beschikbaar in Android. Gelukkig heeft men dit op tijd ontdekt en is men overgestapt van Flickr naar Panoramio, een gelijkaardige website met geogetagde foto's. Er is wat code en een beetje tijd verloren gegaan door deze beslissing, toch is het een wijze beslissing omdat men hierdoor een grotere hoeveelheid tijd en een logischere en stabielere applicatie krijgt die beter uitbreidbaar is.
Nieuwe SDK Eén van de grootste problemen die men tegenkwam was het feit dat men met een nieuwe Software Development Kit werkte. De sdk versie 1.0 release 1 werd uitgebracht eind september 2008. Al de tutorials waren geschreven voor de al langer uitgebrachte 0.9 sdk. Bijgevolg vond men bij het opzoeken van voorbeelden niet veel werkende code. Al de handleidingen waren nog niet vernieuwd, enkel de Android package index bevattte recente informatie. Dit vertraagde het leerproces en bijgevolg had men meer problemen om vertrouwd te geraken met de manier van werken van Android.
Bugs Met het feit dat de sdk nog maar pas was uitgebracht toen PenO3 startte, waren er nog enkel bugs aanwezig. Eén van de grootste problemen was namelijk dat de Android plugin in eclipse automatisch commentaar schreeft in een automatisch gegenereerde tekstdocument. Deze commentaar zorgde er echter voor dat eclipse fouten gaf. De hele werking van het programma werd verstoord door de commentaar die de plugin steeds opnieuw schreef.
Debugbeperking Het debuggen gaf ook enkele problemen. Om te kunnen debuggen moest men namelijk een activity starten en als men een debug point plaatste in de code van een service werd er niet eens gestopt. Dit had tot gevolg dat het vinden van fouten in services wat moeilijk verliep.
13
Ontwerpbeslissingen Panoramio vs Flickr Zoals vermeld was oorspronkelijk de bedoeling om Flickr te gebruiken als bron voor de afbeeldingen. Er is ook een Flickr API beschikbaar genaamd flickrj voor Java zodat men eenvoudig met Flickr kan werken. Het probleem lag dus bij het feit dat deze Flickr API gebruikmaakt van bibliotheekklassen die niet beschikbaar zijn in Android. Bijgevolg kon men het uitgewerkte stuk code niet uitvoeren op Android en moest men naar een andere oplossing. De keuze was gevallen op Panoramio.
Zonemanager, AIDL Een zonemanager object (dat met de database communiceert) wordt aangemaakt in de MusicManager maar zijn methodes moeten ook beschikbaar zijn voor de ZoneActivity. Er mag maar één object aangemaakt worden zodat er uiteindelijk maar één zonedatabase is. Eerst dacht men van het zonemanagerobject een singleton te maken maar men zocht, op aanraden van een assistent, naar een betere oplossing. Er bestaat namelijk een constructie in Android die toelaat objecten door te geven tussen processen. Normaal gezien werkt, op het Androidplatform, elk proces in zijn eigen geheugenruimte en kunnen deze niet aan elkaars geheugenruimte. Android voorziet de AIDL tool die code genereert die toelaat dat twee processen met elkaar communiceren. Op deze manier konden we vanuit meerdere klassen hetzelfde object bereiken.
Shape Men heeft een shape abstracte klasse gemaakt zodat men verschillende vormen kan creëren naar wens. Momenteel zijn er enkel een cirkel en rechthoek mogelijk als vorm al zal in de eerste versie enkel de cirkel vorm gebruikt worden voor de eenvoud.
Updaten van songlist Deze functie bevond zich oorspronkelijk in de MusicDroid-klasse, die een acitivity is. Na wat testen en logisch redeneren, is men tot de conclusie gekomen om deze functie in de MDService-klasse te steken, die een service is. Op die manier kan men de muziek continu laten afspelen als men andere acties wil ondernemen, bv. als men de fotofunctie wil opstarten. Deze beslissing heeft veel invloed op de gebruiksvriendelijkheid, want nu kan de gebruiker andere acties (bv.foto's bekijken, zones toevoegen..) ondernemen terwijl hij naar de muziek kan luisteren. Ook kan men nu instellen hoe frequent de songlist geüpdate wordt en bij elke update wordt nu de gebruiker niet gehinderd, maar enkel de liedjes toevoegd aan de huidige afspeellijst.
Ervaring De ervaring bij de implementatie van de applicatie was zeker positief. In het begin was het even aanpassen en verkennen, maar na een tijd en vooral op het einde ging het wel vlot. In het begin was het een hele uitdaging om te implementeren, omdat men de structuur van Androidapplicaties nog niet goed kende. Door de presentatie en de tutorials wist men wel ongeveer hoe zo een applicatie in elkaar zit, maar zelf geheel een nieuw programma opbouwen vereist toch meer uitgebreide kennis van Android.
14
Om die kennis te verwerven is de efficiëntste methode waarschijnlijk wel zelf proberen. Natuurlijk gebeurde dit niet zonder frustraties, maar iedereen beschouwde de opdracht als een uitdaging. Als het programma uiteindelijk werkt, dan is de voldoening bijzonder groot. Het team werd vaak verdeeld in groepjes van twee om aan een bepaald deel van de applicatie te werken, zodat niemand er alleen voorstond. Dit werd door iedereen als aangenaam en efficiënt ondervonden. Tijdens de implementatie botste men vaak op problemen, maar die werden met hulp van andere teamleden en met wijze raad van de assistenten vrij snel opgelost. Het handige bij de implementatie van een Android- applicatie was dat men bijna direct het resultaat kon testen en debuggen via de emulator. Zo kreeg men direct een idee of het programma werkt. Het debuggen ging gemakkelijk en de bugs werden mits aandacht en tijd vrij snel gevonden. Men kan besluiten dat de implementatie een leerrijke en aangename ervaring is geweest.
7. Demodag Om 8u 30 was het team volledig aanwezig in 300C. Na ons standje te hebben opgezet bleek er nog een laatste bug in ons programma te zitten. Een uurtje later was deze opgelost en onze applicatie nog een functie rijker. Ook werkte onze applicatie tot groot genoegen van het hele team. Na 2 uur te hebben geprobeerd onze applicatie te tekenen zodat het op een echte Android kon worden gedraaid, heeft Bram het uiteindelijk voor ons gedaan. Het resultaat was dat onze applicatie werkte op een echte Android. Spijtig genoeg was ons standje gepositioneerd langs het raam dus ver van deur hierdoor kwamen er niet te veel bezoekers langs. Hierdoor bleef het de hele dag rustig. Wat de meeste mensen lokte was het feit dat onze applicatie echt werkte en ook dat we het op een echte Android konden tonen. Sommige mensen zagen meteen grote doelen voor onze applicatie terwijl andere eerder de reactie hadden wat is het nut van jullie applicatie. Gelukkig reageerden de meeste mensen naar de positieve kant. Om 17 u was het hele gebeuren gedaan. Helaas was bij de groepsfoto één van onze leden er niet meer bij. Deze kon niet blijven tot 17 u. Het team vond de demodag wel een interessante dag. Ook dat we de resultaten van de andere groepen konden bezien was tof.
8. Zelfevaluatie Het team is over het globaal bekeken zeer tevreden met de behaalde resultaten. Ons programma werkte op de demodag. Ook op het gebied van layout vonden we het een geslaagd programma, bij Musicdroid was hierbij nog het meeste verbetering mogelijk. Iedereen had wel het gevoel dat er weinig was gerealiseerd op de gebruikte tijd. Dit kwam volgens ons vooral omdat er in het begin verschillende weken inleidende seminaries werden gegeven, de ene werd al nuttiger als de andere gevonden door het team. Ook Android en zijn totaal nieuwe structuur hebben ons veel tijd gekost. Zeker in het begin omdat alles opgezocht moest worden. Onze sterke punten Er is altijd een goede taakverdeling geweest. Ook heeft iedereen zijn specialisatie in het Android systeem. Er waren mensen die activity's maakten, andere services en andere aidls enz... Hierdoor was er een relatieve goede efficiëntie. Er werd geen dubbel opzoek werk verricht.
15
Onze zwakke punten De implementatie werd door iedereen als het belangrijkste gezien hierdoor zijn die administratieve taken zoals het verslag enz.. wat verwaarloosd. Ook afleiding heeft ons wat tijd gekost, sommige momenten werd er veel gebabbeld over niet Android dingen. Goed voor de teamsfeer iets minder voor het administratieve. In het vervolg zou iedereen eerst veel meer informatie opzoeken over Android. Hierdoor zou er veel tijd gewonnen worden tijdens het programmeren en ontwerpen. Dit omdat Android een zeer unieke structuur heeft welke eerst volledig moet begrepen worden voor men een Android programma kan ontwikkelen. Hier is het bij ons gedeeltelijk misgelopen.
9. Vakintegratie Methodiek van de informatica is het vak waarmee dit project volledig is verweven. De inhoud van het vak: programmeren in Java, ontwerpen van programma's, enz... zijn juist de onderdelen die er nodig zijn om het project tot een succesvol einde te brengen. Ook andere vakken zullen gebruikt worden, zij het in mindere mate, bv. vakken zoals analyse, voor bijvoorbeeld het gedeelte waar er met de coördinaten wordt gewerkt. Ook de leerstof en methodes van peno 1 en 2 zullen gebruikt worden bij het opstellen van onze planning, het schrijven van de verslagen en de presentatie en hopelijk bij het vermijden van bepaalde fouten.
10.
Besluit
Iedereen heeft veel geleerd van PenO3. Allereerst is er de programmeerervaring. Het team heeft leren werken met Eclipse. Dit is een zeer goede omgeving om te programmeren en biedt een enorme waaier van mogelijkheden aan. Het heeft tal van nuttige extra’s, zoals autoaanvulling, een goede debugger,… (In vergelijking met Eclipse stelde BlueJ van vorig jaar dus niets voor.). Eclipse is ook enorm uitbreidbaar en vormt daardoor ook de perfecte omgeving om voor Android te programmeren. Zelf ons klassendiagram is automatisch gegenereerd door een eclipse-plugin. Als leden van het team dus verdergaan in computerwetenschappen, dan was de PenO een goede introductie tot eclipse en SVN. De PenO heeft ook gezorgd dat alle leerstof van Methodiek van de informatica nog eens opgefrist werd. Maar wat we vooral geleerd hebben, is informatie zoeken op het internet. Omdat de kennis van Android zo beperkt was, moesten nog vele dingen opgezocht worden. Het effectief opzoeken en overnemen van informatie was dus zeer belangrijk. Ook verrijkend was de ontwerpfase. Sommigen van ons waren het gewoon om direct te programmeren, maar als een project zo groot is als GeoMedia, kan je dit niet zo doen. Een deftige planning is nodig om alles tot een goed einde te brengen. Als je vanuit een goed klassendiagram begint, is het programmeren zelf niet meer dan het klassendiagram digitaliseren. Wat beter kon in het team zijn alle administratieve taken. Deze kwamen op de 2e plaats. Iedereen was veel enthousiaster over het programmeren dan bijvoorbeeld over het verslag en de wiki. Het team begrijpt wel dat het nodig is dit allemaal te doen, zodat we kunnen geëvalueerd worden, maar het zijn minder toffe taken om uit te voeren. Het is dus nodig om in volgende PenO’s hier meer tijd aan te besteden. Tot slot kan het team terugkijken op een geslaagde PenO. Iedereen is tevreden van het eindresultaat en het was een leerrijke ervaring, aangezien iedereen van het team verder gaat met hoofd- of nevenrichting computerwetenschappen.
16
11.
Bijlagen
Illustratie 1: Mindmap Illustratie 2: Gantt-chart
17
Illustratie 3: Domein model
Illustratie 4: Database structuur Illustratie 5:Architectuur
18
Illustratie 6: Klassendiagram voor een duidelijkere versie zie wiki
12.
Agenda
29 September 2008 Gezamenlijk [4u]: Algemene inleiding, opdracht gekregen van begeleider, brainstorm 02 Oktober 2008 Gezamenlijk [4u]: Presentatie over Subversion, SSH, eclipse en GWT 06 Oktober 2008 Gezamenlijk [4u]: Presentatie over Linux, RPC calls met GWT 09 Oktober 2008 Gezamenlijk [4u]: Werken aan de wiki, mindmap, use cases, related work 13 Oktober 2008 19
Gezamenlijk [4u]: Inleidend seminarie Android, GPS via Android 16 Oktober 2008 Gezamenlijk [2u]: Domein model, Architectuur, Klassendiagramma Individueel [2u]: Gerry, Blas: Domein model, architectuur Ruben, Bart, Xiangyu: Use Cases, Klassendiagram Albert: Wiki, Android 20 Oktober 2008 Gezamenlijk [3u]: Uitwerken van architectuur en klassendiagramma Individueel [1u]: Gerry, Blas: Waardenanalyse playlists, prioriteitenschema, architectuur Ruben, Xiangyu: waardenanalyse server vs. client Albert, Bart: Waardenanalyse afbeeldingen 23 Oktober 2008 Individueel [4u]: Gerry: Klassendiagram, databasestructuur, nalezen verslag Bart: Waardenanalyse van muziek en afbeeldingen, databasestructuur, nalezen verlsag Ruben: Klassendiagram, Use case diagram, inleiding tot use cases en domeinmodel Xiangyu: inleiding van verlsag, Brainstorm en planning voor verslag, inleiding use case en domeindiagram Blas: Productomschrijving, Besluit en vakintegratie van verslag Albert: Klassendiagram, waardenanalyse 6 November 2008 Gezamenlijk [1u]: Klassendiagram, Databasestructuurr Groepjes [3u]: Gerry, Ruben: Klassen Status en StatusProvider uitgewerkt. Blas, Xiangyu: PhotoService en Flickr API Albert, Bart: Klassen Zone, Shape, klassendiagram, Database 13 November 2008 Groepjes [4u]: Gerry, Ruben: Klassen StatusProvider,GeoMedia volledig uitgewerkt.(3u)Daarna wiki en verslag upgedate.(1u) Blas, Xiangyu: PhotoService en Flickr API.(4u) Albert: Zoneactivity & algemeen adviseur.(4u) Bart:Shapes, Circle en Rectangle uitgewerkt.(4u) 17 November 2008 Groepjes [4u]: Gerry, Ruben: Begin implementatie van ZoneManager,Musicmanager, MusicService en MusicService. (2u) Daarna becommentarieren van verschillende klassen(2u) Blas, Xiangyu: PhotoService met gebruik van Panoramio.(4u) Albert:MusicDatabase & helpdesk.(4u) Bart:Aanpassen van klassediagramma en aanpassen van Shapes (3u), planning schrijven en aanpassingen op wiki (1u) 20 November 2008 20
Groepjes [4u]: Gerry, Ruben: ZoneManager vertaald van klasse naar Service, ZoneManagerInterface, ZoneAcitivity, Klassendiagram Xiangyu:MusicDroid Blas:Flyer Presentatie, Panoramio, Layout ZoneActivity Albert:Geomedia, StatusProvider en Panoramio aanpassen naar Androidstructuur. Bart:Logo flyer + layout ZoneAcitivity 27 November 2008 Groepjes [4u]: Gerry, Ruben: Wiki geüpdate(Kalender, gantt-chart en planning), Service gemaakt van ZoneManager. Zone en Status klassen parcelable gemaakt. Connectie van ZoneActivity naar ZoneManager gelegd. Xiangyu, Albert:MusicDroid, SD-kaart emulator Blas, Bart:Layout en MapView ZoneActivity 1 December 2008 Groepjes [4u]: Gerry, Ruben: Geomedia activity UI begonnen, lijst gemaakt met dingen die nodig zijn voor de demo. De poster al wat uitgedacht, Wiki geüpdate(Kalender, gantt-chart en use-cases), verslag geüpdate en modellen aangepast. Xiangyu, Albert:Zonedatabase debuggen, circle en shape parcelable repareren Blas, Bart:ZoneActivity aangepast, addZone aangemaakt, inputzonelayout gemaakt 4 December 2008 Groepjes [4u]: Gerry: Kalender geüpdate, Debuggen van musicdroid, teksten voor poster, ontwerp van poster. Bart:Ontwerp poster, Lay-out van activities. Xiangyu: Debuggen van musicdroid, liedjes op SD-card zetten, Lay-out voor musicplayer. Albert: Debuggen van musicDroid Blas, Ruben:ZoneActivity aangepast, GeoMedia activity gemaakt, Spinner geïmplementeerd. 8 December 2008 Groepjes [4u]: Gerry: Kalender geüpdate, powerpoint voor demodag maken, debuggen van het programma Bart:Lay-out van activities. Xiangyu: buttons van musicdroid. Albert: GeomediaActivity, opzoeken van zoneobjecten uit de database op basis van huidige status Blas, Ruben:ZoneActivity aangepast,geomediaActivity gemaakt, debuggen van panoramio 11 December 2008 Groepjes [4u]: Gerry: Kalender geüpdate, klassendiagram maken, besluit van verslag, ervaring van ontwerpproces,... typen voor verslag. Bart:Powerpointpresentatie gemaakt voor presentatie Xiangyu: verslag: problemen bij ontwerp en ontwerpbeslissingen, ervaringen implementatie Albert: database-structuur en domeinmodel aangepast, automatisatie van GeoMedia, verslag: ontwerp Blas: verslag: zelfevaluatie, mindmap, demodag Ruben: verslag: Samenvoegen van verschillende delen, begin van implementatie. Usecasediagram. 21
