Android Toepassing Groep 3

PROJECT MULTIMEDIA, 2008-2009

1

Android Toepassing Groep 3 Tom Crauwels, Tonny Vander Poorten, Wim Beck 3e Bachelor Informatica [email protected], [email protected], [email protected]

Abstract— Onze vorige projecten bevatten een verscheidenheid aan multimedia (zoals karaoke, muziek, spelletjes), met steeds het hoofdthema “Party”. We wilden niet opnieuw dezelfde toepassing implementeren in Android, dus hebben we ons toegespitst op e´ e´ n aspect hiervan, namelijk een muziekspelletje.

multimedia, android I. I DEE Het idee is tot stand gekomen doordat in onze vorige projecten de spelletjes niet helemaal uitgewerkt waren. We wilden daarom eens een spelletje ontwerpen dat rond muziek draaide. Ook had de introductie tijdens de eerste sessie ons laten zien wat er allemaal mogelijk was met android. Het spelletje bestaat uit een aangepaste versie van het spelletje “Simon”, een spel waarbij het memoriseren van geluiden zeer belangrijk is. Verschillende spelletjes waren mogelijk, zoals bv. een soort “Guitar Hero”, maar we kozen uiteindelijk voor deze applicatie omdat deze het meest haalbaar was. In de applicatie wordt een sequentie van dierengeluiden afgespeeld, waarna de gebruiker deze moet naspelen door op de bijhorende prentjes van de dieren te drukken. De dierengeluiden hadden we reeds gebruikt om de mediaplayer van ons Flex-project te testen, we vonden het leuk om deze te hergebruiken. We hadden even gedacht om het naspelen van dierengeluiden via knopjes te vervangen door muzieknoten te spelen in een ocarina-achtige toepassing (zoals op de iPhone mogelijk is), maar besloten dit niet uit te werken, omdat onze applicatie dan te specifiek gericht zou zijn (niet iedereen kan vloeiend ocarina spelen . . . ). Het mobiele aspect konden we uitbuiten door met behulp van sms’en een multiplayer-versie (ée´ n tegen e´ e´ n) van ons spelletje te implementeren, zodat het gespeeld kan worden met iedereen die het spelletje op zijn toestel heeft staan, ongeacht de locatie. Indien de android omgeving een algemene standaard zou worden die gebruikt wordt op verschillende soorten toestellen, blijft dit zelfs niet beperkt tot enkel android phones. II. S TORYBOARD We moesten in hoofdzaak twee schermen ontwerpen: in het eerste scherm werden de geluiden voor de gebruiker afgespeeld, in het tweede moest de gebruiker de sequentie van geluiden nabootsen. Het eerste scherm vonden we visueel minder belangrijk, omdat er in de eerste plaats geluisterd moest worden. We

voorzagen daarom enkele eenvoudige knopjes om de geluiden af te spelen, en verder te gaan naar het speelscherm. Het tweede scherm omvat de eigenlijke interactie tussen gebruiker en game. We voorzagen vier grote knoppen (1 voor elk dier). Om het wat aantrekkelijker te maken, wilden we een grappige afbeelding van het dier op de knop plaatsen. Verder werden gaandeweg nog enkele schermen toegevoegd, zoals een scorevenster, een welkomstvenster, een scherm om tussen single- en multiplayer te kiezen, enz. Zie appendix voor een foto van het storyboard. III. S OFTWARE - ONTWERP Elk scherm moest worden voorgesteld als een Activity, zodat we naar een ander scherm konden overgaan en data meegeven. Er werd een aparte klasse FunkyButton voorzien, die overerft van ImageButton, zodat we onze dierenknopjes konden aanpassen naar onze eigen wensen. We moesten ook beslissen op welke manier we onze multiplayer mode wilden implementeren. Dit kon via draadloos netwerk of via SMS. We hebben besloten onze implementatie op SMS te baseren, omdat dit eenvoudiger was, en geschikt voor onze applicatie : er is immers geen permanente verbinding nodig, de sequentie van geluiden kan in numerieke vorm verstuurd worden wanneer een speler klaar is. Zie appendix voor het klassediagramma. IV. I MPLEMENTATIE Voor de layout moesten we even zoeken hoe dit werkte in Android. Er is een grafische editor beschikbaar om schermen te ontwerpen, maar deze vonden we niet zo gebruiksvriendelijk. Bij elk element wordt heel de lijst parameters weergegeven, en dan is het zoeken naar de juiste. Om bv. de tekst op een knopje te wijzigen, moet zo’n 10 seconden door de parameterlijst gescrolld worden. Het bleek eenvoudiger om de xml-bestanden manueel te wijzigen. Om onze dierenknopjes te personaliseren, maakten we een klasse FunkyButton. Hierin wilden we dingen aangeven zoals een gewijzigde achtergrondkleur wanneer de knop ingedrukt werd, of andere kleine visuele aanpassinkjes. Uiteindelijk werd voorrang gegeven aan de functionaliteit van de applicatie, zodat we ook standaard ImageButtons hadden kunnen gebruiken. De klasse hebben we echter laten staan, omdat ze toekomstige aanpassingen zou kunnen vereenvoudigen.


Elk scherm werd voorgesteld door een aparte activity. Deze activities moesten manueel aan de manifest worden toegevoegd, iets wat we pas doorhadden na het doorworstelen van vele errors. . . Een ander probleem was het doorgeven van data tussen schermen. In Android kan dit gemplementeerd worden via intents. Informatie over de gebruikswijze hiervan, bleek echter niet zo consistent te zijn op het web, vermoedelijk omdat er veel manieren zijn om deze intents te gebruiken. Door de stukjes en beetjes samen te puzzelen, zijn we er toch in geslaagd om primitieve datatypes en lijsten mee te geven tussen activities. Abstracte datatypes (ook indien ze serializeerbaar zijn) meegeven via een intent, werkt echter niet op intutieve manier. Zo hadden we een State-klasse, die info bijhield over of een game single- of multiplayer was, en eventueel het telefoonnummer van de tegenstander. We wilden instanties van deze klasse meegeven via intents, maar uiteindelijk bleek het eenvoudiger om deze State-klasse te verwijderen en de info via primitieve datatypes mee te geven (een boolean voor single/multiplayer, en een string voor het telefoonnummer). Afspelen van muziek bleek verrassend eenvoudig in Android. Omdat we maar vier korte geluidjes hoefden af te spelen, konden we deze in de resources van ons project plaatsen. Met enkele regeltjes code werd een mediaplayer aangemaakt die dit geluidje afspeelde. Om de multiplayer te implementeren moesten we twee doelen realiseren, namelijk het sturen en ontvangen van sms’en vanuit onze applicatie. De applicatie begint met het sturen van een sms als de speler de juiste combinatie ingeeft. In een eerste versie was het zo dat de speler dan naar een scherm werd gestuurd en daar het nummer van de andere speler nog moest invullen vooraleer op verzenden te kunnen klikken. Maar aangezien je daar telkens de telefoon voor moest openschuiven en het niet zo proper leek dat we uit onze applicatie gingen, hebben we verder gezocht naar een manier om een sms intern te versturen. Dit konden we doen door de SmsManager op te roepen en die een sms te laten versturen. Het adres waarnaar we die sms sturen krijgen we ofwel via gebruikers input ofwel van een sms die we ontvangen van de tegenspeler. Voor deze implemantie van het versturen van een sms hadden we wel een android permission nodig, en voor de eerste niet (via het extra scherm). Dit betekent dat we in de manifest deze permission moeten aanvragen als volgt: <uses-permission android:name=“android.permission.SEND SMS” /> Om zelf een sms te ontvangen moesten we eerst ook nog een andere android permission aanvragen, namelijk: <uses-permission android:name=“android.permission.RECEIVE SMS” /> Als iemand ons spel wilt installeren krijgt hij dan al de permissions te zien en de vraag of hij de applicatie dan nog wilt installeren. Vervolgens maakten we een SMSReceiver klasse die overerft van de klasse BroadcastReceiver. Die klassa kan dan intents van android ontvangen. Dan gaan we kijken of een intent die wordt uitgezonden de intent is voor een binnenkomende sms. Indien dit het geval is, halen we het sms bericht uit die intent. De methode hiervoor zat eerst standaard in de android SDK, maar blijkbaar hebben ze die er sinds versie 1.0 uitgehaald. Gelukkig voor ons hebben we gevonden hoe we die methode zelf konden schrijven. Nu we de sms hebben,

2

met daarin het bericht en de afzender, kunnen we kijken of het bericht begint met “MMGAME”, zodat we onze applicatie kunnen starten en de gestuurde combinatie meegeven. Een laatste stukje implementatie was dat als een speler een verkeerde combinatie ingeeft in de multiplayer mode, automatisch een sms met daarin “MMGAME I LOST” verstuurd werd naar de tegenspeler. Dan moesten we in de SMSReceiver enkel nog controleren of het aangekomen bericht een nieuwe combinatie aangaf, of dat het spel afgelopen was en, afhangend van deze SMS het juiste scherm oproepen. V. R ESULTAAT We hebben onze doelstellingen bereikt: een functionele game bouwen die met meerdere mensen tegen elkaar (in ons geval met twee emulators) kan gespeeld worden. Het resultaat is intu¨ıtief te gebruiken, en grappig (vooral de olifant is een “must hear”. . . ). Qua visueel aspect is onze applicatie nog voor verbetering vatbaar. We hebben hier functionaliteit boven uitzicht verkozen (liever iets dat werkt dan iets dat er mooi uitziet), aangezien de graphics achteraf nog altijd eenvoudig aangepast en verbeterd kunnen worden. Ook nog een klein minpuntje: elke keer een sms aankomt, wordt de inhoud automatisch op het bovenste regeltje van de GooglePhone getoond. In ons geval is dat “MMGAME” met een serie cijfers erachter. Het zou handig zijn indien dit uitgeschakeld kon worden, aangezien de speler nu telkens ongewild een herinnering krijgt wat de vorige sequentie van geluiden was. . . VI. A NDROID A. Pluspunten •

•

•

•

Doordat Android werkt zoals Java, konden we nog eens lekker ouderwets programmeren. Code schrijven gaat daarom vlotter dan bij andere ontwikkelingsplatformen die met een geheel eigen taal komen, omdat we Java gewend zijn. Opmaak en code worden voor de gebruiker gescheiden gehouden, maar worden achterliggend automatisch aangepast (via de klasse R). Heel handig. De emulator is leuk om mee te werken en handig om alles te testen. Vooral ook omdat we er meerdere kunnen opstarten en zo smsen konden sturen. Het feit dat er echt gsm’s zijn die android gebruiken en we dus onze applicatie zouden kunnen zien op een werkende gsm was interessant.

B. Minpunten •

• •

Niet alle wijzigingen worden automatisch doorgevoerd (zoals bv. de noodzaak om activities manueel aan de manifest toe te voegen). De grafische editor om schermen te ontwerpen, is niet echt gebruiksvriendelijk. De online API documentatie van Android is een ramp. Elke klasse bevat een overrompeling aan informatie, waardoor het praktisch onmogelijk wordt om de officile online documentatie te gebruiken. De tutorials zijn dus voor een goede reden op de site geplaatst.


C. Besluit Android lijkt ons heel geschikt om kleine applicaties mee te maken met enkele screens en wat data, maar niet om grote projecten in te implementeren. VII. E RVARING Zoals voor elk project is op tijd beginnen een must. Het duurde even voor we Android goed in de vingers hadden, maar daarna ging het programmeren vrij vlot. Het werk werd in het begin verdeeld tussen Layout, Multiplayer en Muziek, maar dit bleek al snel hier en daar te overlappen, dus werd uiteindelijk bijgesprongen waar nodig. Nu het project af is, zou een betere taakverdeling gemaakt kunnen worden, maar dat is natuurlijk meestal het geval. . . VIII. G LOBALE FEEDBACK A. Pluspunten •

• • •

De verhouding tussen de inleidende theorie en de praktische uitwerking was zeer goed. We moesten namelijk applicaties maken die echt gebruikt kunnen worden. Open opdrachten, invulling gebeurt naargelang je eigen inspiratie. Veel feedback en interactie Autoriteiten in het vakgebied die hun ervaringen delen

B. Drie punten vatbaar voor verbetering Structuur van de cursus lag dit jaar precies nog niet zo goed vast • Sommigen zijn niet van plan om het onderzoeksprofiel te volgen in hun masterjaren. Nieuwe technologieën zijn zeker interessant (zoals Android), maar het “proeven van de onderzoekswereld” lijkt een beetje een poging om ons naar een bepaald profiel te loodsen. . . • Meestal zit een technologie pas goed in de vingers na het maken van het project. In de beginfase wordt veel tijd gespendeerd aan het eigen maken van het ontwikkelingsplatform, tijd die afgaat van het implementeren van het project. Hier is natuurlijk weinig aan te veranderen, maar nadien voelt het soms alsof hierdoor veel tijd verloren gaat. Het is dus misschien een beter idee om ipv een inleidende video te tonen, een kleine opdracht op te leggen waardoor de studenten zelf al met de applicatie in aanraking komen. Er wordt dan ook duidelijk gemaakt wat de mogelijkheden van die technologie zijn en tegelijk is er al een eerste kennismaking. Aan medestudenten zou ik zeggen: als je iets praktisch wilt doen, waar je je eigen ideeën kan uitwerken, dan is dit vak een aanrader. Je steekt er alleen al snel meer tijd in dan oorspronkelijk je bedoeling was. Een goede planning uit kunnen werken is dus zeker een must, zeker indien je ook nog andere lopende projecten hebt van andere vakken. . . •

3


A PPENDIX Storyboard

4

Screenshot


Klassediagramma

5


6

Tijdsbesteding A. Binnen les vr 28/11 vr 05/12 1) Wim: vr 12/12

Idee uitwerken maken van Custom views (buttons) opzoeken muziek + listeners voor buttons Totaal : vr 28/11 Idee uitwerken vr 05/12 maken van Custom views (buttons) 2) Tom: vr 12/12 opzoeken muziek + listeners voor buttons Totaal : vr 28/11 Idee uitwerken vr 05/12 maken van Custom views (buttons) 3) Tonny: vr 12/12 opzoeken muziek + listeners voor buttons Totaal :

4u. 4.5u. 4.5u. 13u. 4u. 4.5u. 4.5u. 13u. 4u. 4.5u. 4.5u. 13u.

B. Buiten les wo 17/12 do 18/12 1) Wim: wo 24/12

Muziek spelen in applicatie samenvoegen van ieders stuk werk + afwerking verslag Totaal : wo 17/12 SMS versturen tussen verschillende emulators do 18/12 samenvoegen van ieders stuk werk + afwerking 2) Tom: wo 24/12 verslag Totaal : wo 17/12 screens aanmaken + switchen tussen screens do 18/12 samenvoegen van ieders stuk werk + afwerking 3) Tonny: wo 24/12 verslag Totaal :

4u. 6u. 4u. 14u 6u. 6u. 4u. 16u 6u. 6u. 4u. 16u

Android Toepassing Groep 3

Recommend Documents