Multimedia: modelleren en programmeren Verslag: ontwerp en implementatie Groep 9 http://professorduvaliseengenie.wordpress.com/ Joris Baken, 3de fase Informatica Stijn Dejongh, 3de fase Informatica Pieter Van Riet, 2de fase Informatica Bart Gerard, 3de fase Informatica November 6, 2009 Abstract Dit is het verslag van het tweede ontwerpproject voor het vak Multimedia: modelleren en programeren. We bespreken het ontwerp en de implementatie van een Android toepassing, gericht op het weergeven van grafische informatie omtrent muziek. We openen met een kleine toelichting bij het idee achter onze toepassing. Nadien volgt een uiteenzetting van ons storyboard en een verantwoording van ons initieel ontwerp. Vervolgens pogen we om het uiteindelijke ontwerp te verduidelijken en de gebruikte klassen te verklaren. Daarna verwoorden we onze mening over het uiteindelijke resultaat en daarbij aansluitend formuleren we onze visie over het Android platform. In het hoofdstuk extra is onze code terug te vinden en een link naar een video van onze applicatie. In het laatste hoofdstuk trekken we ons besluit. De belangrijkste uitdagingen waren: • Een soepele en vlotte samenwerking bewerkstelligen. • Betere planning en spreiding van het werk bereiken. • Een meer consistent en overzichtelijk verslag afleveren. Uit dit project leerden we vooral dat: • Een betere analyse van het probleem zorgt voor een effici¨enter en doelgerichter werken naar een finale oplossing. • Een goede planning is onontbeerlijk in weken met een overload aan deadlines.
Ingediend op: maandag 2 november 2009
1
Contents 1 Idee
3
2 Storyboard
4
3 Software-Ontwerp 3.1 Concert . . . . 3.2 ConcertHandler 3.3 MapHandler . . 3.4 FlickrHandler .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
4 Implementatie 4.1 Problemen . . . . . . . . . . . . . . . . 4.1.1 ArtistHandler, ConcertHandler, 4.2 Veranderingen . . . . . . . . . . . . . . 4.2.1 Storyboard Veranderingen . . . 4.2.2 Ontwerpveranderingen . . . . . 4.3 Aknowledgements . . . . . . . . . . . . 5 Resultaat
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
5 5 5 6 6
. . . . . . . . . PictureHandler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
7 7 7 9 9 9 9
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
10
6 Over Android 11 6.1 Het systeem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2 De Android SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7 Besluit
12
8 Appendix 13 8.1 Uren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.2 Gebruikte Resources . . . . . . . . . . . . . . . . . . . . . . . . . 13
2
1
Idee
Het basisidee achter deze Android toepassing was het implementeren van een soort van GPS dewelke de weg kan tonen naar een concert van een gekozen artiest. Aanvankelijk bestond het concept er in de naam van de gewenste artiest in te vullen in het startvenster. Bij een druk op de zoekknop zou dan een googlemaps venster openen met daarop alle komende optredens van de artiest in kwestie. Wanneer de gebruiker een marker selecteerde, horende bij een bepaald optreden, zou de route tot het optreden getoond worden vertrekkende vanaf de huidige locatie. Een ander idee combineerde het gebruik van de ingebouwde GPS en gyroscopische functionaliteiten met de ingebouwde camera. Na het invullen van de artiestennaam zou dit concept het beeld van de camera tonen op de achtergrond. Wanneer de camera in de richting van een bepaald concert van deze artiest gehouden wordt, zou extra informatie over dit event getoond worden. Uiteindelijk hebben we gekozen om eerst het basisidee uit te werken omdat dit dichter bij onze voorgaande ontwerpopdracht lag. Wegens een gebrek aan tijd hebben we dit idee laten vallen en vooral gefocust op de port van onze flexapplicatie. Een zwak punt aan beide idee¨en is het feit dat beide applicaties een internetconnectie vereisen. Zonder internetconnectie kan de benodigde informatie niet afgehaald worden. Omdat deze applicatie als mashup zijn informatie ergens moet halen, is dit punt bewust genegeerd. Omdat het basisidee slechts ´e´en specifieke datastroom aanboort, is als uitbreiding geopteerd om informatie te tonen en foto’s op te halen met betrekking op de geselecteerde artiest. Binnen deze uitbreiding komt als voornaamste sterke punt naar voren dat er gestructureerd een grote vari¨eteit aan informatie wordt getoond.
3
2
Storyboard Home
Map 1
Map 2
Foto’s
Focus Foto
Help
Home De gebruiker typt een artiestennaam in of kiest ervoor de help pagina te bekijken. Map 1 Nadat de gebruiker een artiest heeft gekozen, toont de kaart ’markers’ die concertlocaties voorstellen. De kaart zal ook de huidige locatie van de gebruiker aanduiden, en zich hierrond centreren. Map 2 Wanneer de gebruiker op een marker klikt, wordt er een paneel weergegeven. Dit paneel bevat informatie over het concert. Ook wordt er een route getekend vanaf de gebruiker zijn huidige locatie tot aan de gekozen marker. Foto’s
Geeft een ’gridview’ van foto’s weer.
Focus Foto Een geselecteerde foto wordt uitvergroot. De gebruiker kan makkelijk tussen foto’s wisselen. Help
De ’help’-pagina die de gebruiker uitlegt hoe met de applicatie te werken.
4
3
Software-Ontwerp
3.1
Concert
Waar we vorige keer gekozen hadden om de standaard klassen van Last.FM over te nemen, is dit maal onze keuze gevallen om zelf onze basis klassen te ontwerpen. Dit om verwarring met gevraagde argumenten te vermijden. Een concert bestaat uit volgende velden: • een titel: naam van het evenement • een locatie: naam van de locatie • x- en y-co¨ordinaten: de ligging van het evenement • een beschrijving: beschrijving gegeven door de persoon die het evenement heeft aangemaakt op Last.FM • een startdatum: de datum wanneer het evenement aanvangt
3.2
ConcertHandler
Deze klasse staat in voor de communicatie met Last.FM en vraagt daar van een gegeven artiest alle toekomstige optredens op. De opgehaalde events worden omgezet naar Concerts, en een rij van concerten wordt teruggegeven naar de oproepende klasse.
5
3.3
MapHandler
Deze klasse staat in voor het aanmaken van markers. MapHandler krijgt een lijst met Concerten binnen, en gebruikt deze info voor het aanmaken van zogenaamde ’OverlayItems’. Bij elk van deze markers hoort ook een beschrijving. MapHandler maakt ook een info paneel aan voor de weergave hiervan. MapHandler zorgt hiernaast ook voor het tonen van een route vanaf de huidige locatie tot aan de huidig geselecteerde marker.
3.4
FlickrHandler
Deze klasse staat in voor het binnenhalen van Flickr-fotos die verwant zijn met de opgegeven artiest. Ook zet FlickrHandler deze om in een formaat dat op Android makkelijker weergeefbaar is.
6
4 4.1
Implementatie Problemen
Debugging Over het hele project door hebben we problemen gehad met debugging. Dit omdat de Android VM slechts zijn algemene foutenboodschap geeft. Omdat logcat ook niet altijd naar behoren werkte, hadden we meestal het raden naar wat er precies misliep. Een voorbeeld van zulke problemen is het crashen van de kaart bij meermaals openen, of als een artiest geen concerten geeft. API’s versus XML parsing We waren oorspronkelijk van plan om onze informatie uit de Last.FM API op te halen, net zoals we dat daarvoor al deden. Deze werkte echter niet zoals verhoopt. Het importeren van en programmeren met de API’s was geen probleem. Alles liep echter fout toen we de applicatie voor de eerste keer runden. Het probleem lag er in dat de site zijn info niet juist kon doorgeven. Onze oplossing bestaat erin dat we zelf enkele XML-parsers hebben geschreven: ’ArtistHandler’, ’ConcertHandler’ en ’PictureHandler’. 4.1.1
ArtistHandler, ConcertHandler, PictureHandler
Aan de hand van een gegeven artiestennaam, geeft ArtistHandler deze door aan de audioscrobbler service (zie sectie 8.2). Audioscrobbler genereert op zijn beurt een XML-pagina die onze applicatie uitleest. Het uitlezen gebeurt op een na¨ıeve manier: de Handler zoekt een bepaalde tag-combinatie. Vervolgens leest hij wat daartussen staat met behulp van de ’substring’ methode. Tot slot wordt de ingelezen String terug gegeven aan de oproepende methode. We gaan er van uit dat de gegeven XML invoer correct is. ArtistHandler vangt eveneens het probleem op dat zich voordoet als de gebruiker een niet door Audioscrobbler gekende artiest ingeeft. Dit doet hij door het toevoegen van een indirectie in het aanmaken van een nieuwe artiest. Een Artist-object wordt in onze implementatie immers niet aangemaakt door het oproepen van zijn constructor, maar door het oproepen van de ’initArtist()’methode in ArtistHandler. Deze gooit een exception als de artiest niet gevonden wordt. De exception wordt op zijn beurt in de main class opgevangen en naar de gebruiker doorgecommuniceerd via een bericht op het scherm. ConcertHandler werkt conform ArtistHandler. Het voornaamste verschil zit erin dat de XML-pagina die ConcertHandler moet verwerken, een wederkerend patroon ’<event>’ bevat. Deze events worden iteratief ingelezen en in een lijst geplaatst. Dit is eveneens de lijst die doorgegeven wordt naar MapHandler voor het aanmaken van de bijhorende markers. PictureHandler werkt op analoge wijze. Deze klasse gebruikt de functie ’getImages()’ voor het inladen van de XML pagina. Maps Route Deze functionaliteit was volledig en correct ge¨ımplementeerd maar zorgde ervoor dat de Android VM veel te traag begon te werken. We
7
hebben het weergeven van de route noodsgewijs uit de finale versie moeten halen.
4.2 4.2.1
Veranderingen Storyboard Veranderingen
Artist Info Na het ingeven van een artiestennaam en het aanklikken de zoekknop, krijgt de gebruiker niet een kaart te zien (zoals in het oorspronkelijk storyboard beschreven in sectie 2). In plaats hiervan komt hij/zij terecht op een pagina met informatie over de gekozen artiest. Toast In het originele storyboard stond te lezen dat het aanklikken van een marker tot gevolg had dat er een klein info-paneel geopend wordt. Dit paneel zou informatie bevatten betreffende het geselecteerde concert. Tijdens de implementatie bleek het tonen van een info-veldje niet zo gemakkelijk als dat was in Flex. We hebben er toen voor gekozen om dit veld niet via de API, maar manueel te tekenen op het scherm. Dit zorgde echter voor een niet-stabiele applicatie. In de eindversie maken we gebruik van de default weergave-tool ’Toast’ om concert-informatie weer te geven. 4.2.2
Ontwerpveranderingen
Artist Deze klasse werd aangemaakt om de interne voorstelling van een artiest eenvoudiger te maken. Ze komt niet voor in het origineel ontwerp, omdat het weergeven van artiesteninformatie niet gepland was (zie ook 4.2.1). Artist biedt methodes aan voor het opvragen van onder meer: de naam, de biografie, het aantal luisteraars en gelijkaardige artiesten. Deze velden worden ingevuld door de cre¨erende klasse ArtistHandler. ArtistHandler Deze klasse wordt al uitvoerig beschreven in sectie 4.1.1 . FlickrHandler PhotoHandler.
4.3
Deze klasse is uit ons ontwerp gehaald en vervangen door
Aknowledgements
groep 8
groep 11
Voor de informatie over het weergeven van concert-info in een apart paneel (maps). In de eindversie hebben we dit echter anders gedaan. Het idee van het scrapen van de XML files
8
5
Resultaat
Het is ons gelukt vrij trouw te blijven aan ons oorspronkelijk concept, we hebben zelfs functionaliteit toegevoegd. We bemerken wel dat onze applicatie uiteindelijk enorm traag werkt. Dit merk je vooral bij het openen van een nieuwe tab. De duur van het laden van de markers op een GoogleMaps kaart zit al gauw in de grootteorde van minuten. Het openen van de Flickr-tab gaat nog trager. We weten zelf niet hoe het komt dat onze applicatie zo een trage runtime heeft. Dit kan liggen aan de virtuele machine, de websites die we gebruiken of aan onze applicatie zelf. Ook heeft onze applicatie te lijden onder enkele random crashes. We hebben vooralsnog geen idee waardoor deze veroorzaakt worden, maar hebben een licht vermoeden dat deze de schuld zijn van de VM zelf. Gezien de substanti¨ele tijdspanne die we erin ge¨ınvesteerd hebben, zijn we licht ontgoocheld in ons eindresultaat. Enkele verbeteringen voor eventuele toekomstige updates zijn: • het versnellen van de applicatie • stabiliteit garanderen • de gebruiker een keuze aanbieden tussen meerdere artiesten met eenzelfde artiestennaam
9
6 6.1
Over Android Het systeem
Omdat we in onze opleiding al legio ervaring hebben met het programmeren in Java, voelde het ontwikkelen voor de Android telefoon vertrouwd aan. We gebruikten de Eclipse omgeving voor de implementatie en het samenwerken (SVN via Subclipse), hetwelk een erg positieve invloed heeft gehad op de interne communicatie. De interne structuur van een Android applicatie is in het begin nogal overweldigend. Maar ergens is de opsplitsing in ’interne’-klassen en ’layout’-files logisch, na enig wennen. Tot slot vinden we het leuk om te ontwikkelen voor een Open Source telefoon zoals de Android. Onze groep is ervan overtuigd dat dit platform een goede kans maakt om door te breken op de markt van de mobiele telefonie, mits er voldoende (leuke) toepassingen beschikbaar worden. We merken wel op dat er veel zal afhangen van de concurrentie met de iPhone.
6.2
De Android SDK
Onze mening over de Android SDK is verdeeld. Enerzijds is het handiger om een virtuele machine te gebruiken voor het testen van de applicatie, dan deze steeds op een fysieke telefoon over te zetten. Anderzijds is deze virtuele machine log en even stabiel als de gemiddelde Jenga-toren. We hebben heel vaak problemen gehad met crashende interne functies die niets te maken hadden met onze applicatie maar wel alles om zeep hielpen. We denken hier aan de interne klok, de internet verbinding en het toetsenbord dat niet reageerde. De enige oplossing bestaat erin de VM opnieuw op te starten. Op zich zou dat niet zo een probleem zijn, ware het niet dat het opstarten van een virtuele Android telefoon tergend traag gaat.
10
7
Besluit
Deze opdracht hebben we fundamenteel anders aangepakt dan de vorige. Deze keer hebben we in het begin van het ontwerpproces onze tijd genomen voor een duidelijke analyse, hetgeen geresulteerd heeft in een duidelijker ontwerp. De samenwerking verliep ook veel vlotter. Dit is voornamelijk het gevolg van de betere planning en het gebruik van SVN. Hieruit hebben we geleerd dat het toepassen van de technieken die we in andere vakken hebben geleerd voor grotere projecten ook enorm nuttig zijn voor kleinere toepassingen. Achteraf gezien hebben we enkele dingen minder dan optimaal aangepakt. Zo hebben we heel het project problemen gehad met de gebrekkige debugging. Dit had voornamelijk twee oorzaken: enerzijds geeft de Android VM geen duidelijke foutenboodschappen en anderzijds leek het ons een heel geknoei om een tekst op het scherm weer te geven. In de latere fases van het ontwerpproces kwamen we in aanraking met de ’Toast’ functionaliteit van de Android telefoon. We hadden deze eventueel kunnen gebruiken als hulpmiddel bij het debuggen. Het zoeken naar fouten heeft ons veel tijd gekost. De finale versie van onze applicatie draait trager dan verwacht. Dit heeft tot gevolg gehad dat er enkele functies niet in de uiteindelijke toepassing zitten, hoewel deze in hun geheel ge¨ımplementeerd zijn. In het algemeen doet onze applicatie wel wat we vooropgesteld hadden maar dit niet binnen de gewenste tijdspanne.
11
8 8.1
Appendix Uren
Storyboard Ontwerp Implementatie Android Leren Verslag schrijven Bloggen Installatie Praktische regelingen Totaal
8.2
Stijn 5 5 30 5 14 1 1 1 62
Bart 4 5 35 15 5 0 1 1 66
Joris 4 5 30 1 1 0 2 1 44
Pieter 4 5 44 10 4 1 2 1 71
Totaal 17 20 139 31 24 2 6 4 243
Gebruikte Resources
http://ws.audioscrobbler.com/2.0/ http://www.droiddraw.org/
12
Site die XML pagina’s genereert op basis van last.FM informatie Tool gebruikt voor onze vormgeving.
