10. iphone toepassing. Groep 8 Blog

MULTIMEDIA 2008-2009

1/10

iPhone toepassing Groep 8 Blog http://mume09-desp.blogspot.com/ Peter De Roovere, 1e Master Ingenieurswetenschappen (CW) Emma Eyckmans, 3e Bachelor Informatica Steven Vermeeren, 3e Bachelor Informatica Dieter Van Loon, 3e Bachelor Informatica Abstract— Dit is het verslag voor opgave 3 van multimedia, van groep 8. Wij hebben een iPhone-toepassing uitgewerkt voor het opvragen van informatie over de nummers die afgespeeld worden op een aantal bekende Belgische radiostations. De toepassing voorziet informatie over de artiest (naam, biografie, toekomstige evenementen) en de meest bekende albums van die artiest, waarvan op dat moment op het geselecteerde radiostation een nummer draait. Ook gelijkaardige artiesten en de lyrics van het nummer dat gespeeld wordt op het geselecteerde radio station kunnen opgevraagd worden. Er is voor elk radiostation de mogelijkheid om informatie over het huidige nummer op te vragen of over het vorige. Daarnaast kan, als extra functionaliteit, deze informatie ook opgezocht worden op basis van een door de gebruiker ingegeven artiestnaam. De belangrijkste uitdagingen waren het leren werken met css (en de IUI tags), javascript en JSP (het framework dat we uitkozen om de server-side functionaliteiten te implementeren). Uit dit project leren wij vooral dat ontwikkelen voor iPhone toestellen snel en relatief eenvoudig kan. Ook merkten we op dat er enorm veel mogelijke platforms beschikbaar zijn, waarvan werken met JSP een goede keuze bleek, aangezien een groot stuk van de java-code geschreven voor het Android-platform gerecupereerd kon worden. Ingediend op: 23november, 2009.

——————————  —————————— 1

IDEE

Onze toepassing voorziet informatie over de nummers die worden afgespeeld op een aantal bekende Belgische radiostations. De informatie die beschikbaar gesteld wordt, bestaat in de eerste plaats uit de titel en uitvoerder van het nummer dat afgespeeld wordt op een door de gebruiker geselecteerd radiostation, op het moment dat de gebruiker de toepassing gebruikt. De gebruiker kan vervolgens meer informatie opvragen, namelijk: de liedjestekst, toekomstige evenementen van de artiest, een lijst van bekende albums van de artiest en een lijst van gerelateerde artiesten. Dezelfde informatie kan ook over het vorige nummer opgevraagd worden. Omdat de toepassing een logische weergave van informatie over een artiest geeft werd het dit keer, in tegenstelling tot onze Android-applicatie, ook mogelijk gemaakt om informatie op te zoeken over artiesten die manueel ingevoerd worden. Dit is echter een extra toevoeging die aanvankelijk niet bij het ‘concept’ van de toepassing hoorde. Het kernidee achter de toepassing is dat radio een medium is dat zich enorm gemanifesteerd heeft in onze maatschappij en dat het merendeel van de mensen hier regelmatig mee in contact komt. Radio is voor veel mensen een manier om nieuwe muziek te leren kennen. Dit gebeurt echter meestal waneer luisteraars hier niet op voorbereid zijn en er is dan niet altijd een computer in de buurt. Het mobiele aspect van de Iphone is dan ook een groot pluspunt voor het gebruik van onze applicatie. Aangezien we dadelijk besloten om grotendeels de functionaliteit van de Android-applicatie te behouden, hebben we geen alternatieven bedacht. De toegevoegde waarde die onze applicatie biedt aan het reeds bestaande radio-medium vinden we een enorm pluspunt. De eenvoud achter de werking van het idee, in combinatie met de kracht die het biedt aan gebruikers om op elk moment nummers te leren kennen gebruik makend van de alomtegenwoordige radio, maken dat wij erg tevreden zijn over het idee van onze applicatie.


Daartegenover staat dat er reeds toepassingen op de markt zijn die gelijkaardige functionaliteiten bieden. Shazam1 is een voorbeeld van een toepassing die gebruikers ook in staat stelt nummers te herkennen. Gebruikers kunnen een opname maken van een nummer (dat bijvoorbeeld speelt op de radio), en de toepassing zal dit nummer dan analyseren en identificeren. Informatie over het nummer wordt vervolgens aangeboden aan de gebruiker. Het voordeel van Shazam is dat de toepassing ook buiten het radio-medium gebruikt kan worden. Onze toepassing, aan de andere kant, biedt een bepaalde meerwaarde in het opvragen van voorgaande nummers (het is mogelijk dat het nummer waarin gebruikers geïnteresseerd zijn afgelopen is op het moment dat de gebruiker zijn mobiel apparaat klaar heeft), en het opvragen van informatie van nummers waarvan geen fragment opgenomen kan worden (de gebruiker luistert bijvoorbeeld via een koptelefoon tijdens het joggen). Tenslotte zouden we de functionalitetien van onze toepassing nog kunnen uitbreiden (meer informatie voorzien, de mogelijkheid bieden aan gebruikers om albums online te kopen, informatie over nummers opslaan, e.d.). Aangezien de tijd om deze opdracht uit te voeren beperkt is hebben we deze echter achterwege gelaten. 2

STORYBOARD

Het storyboard van onze iPhone-applicatie kan u, wegens zijn omvang, vinden in de Bijlage, Figuur1, achteraan dit document. Hieronder volgt een korte toelichting (de stappen zijn genummerd volgens de nummering op het storyboard). Stap 1: De gebruiker selecteert een radiostation waarvan hij informatie over het huidige of vorige nummer wil opvragen. Stap 2: Op het scherm verschijnt informatie over het huidige nummer en het vorige nummer op het gekozen radiostation. In een balk bovenaan verschijnt ook het huidige nummer. De informatie in deze balk wordt constant geüpdatet, terwijl de informatie op het scherm enkel op aanvraag (door een druk op de refresh-knop) geüpdatet wordt. Zo blijft de gebruiker op de hoogte van veranderingen in het huidige nummer, maar kan hij rustig zijn zoektocht naar informatie verder zetten. Stap 3: Als op de titel van één van beide nummers gedrukt wordt, worden de lyrics van dat nummer opgehaald en getoond op het scherm. Stap 4 en 5: Als op de artiest van één van beide nummers gedrukt wordt, wordt alle informatie over die artiest opgehaald. De naam van de artiest en een afbeelding worden weergegeven. Daaronder wordt een menu (verder wordt dit artiestmenu genoemd) getoond, van waaruit je de verschillende feiten kan opvragen. Stap 6: Als je in het artiestmenu op ‘Info’ klikt, krijgt je een korte biografie van de artiest. Stap 7, 8 en 9: Als je in het artiestmenu op ‘Upcoming Events’ klikt, krijg je een lijst van events waarop deze artiest zal optreden. Wanneer je verder klikt op zo’n event, krijg je meer informatie over het adres en de datum. Stap 7, 10 en 11: Wanneer je in het artiestmenu op ‘Top Albums’ klikt, krijg je een lijst waarin kleine afbeeldingen en titels van een aantal topalbums van de artiest weergegeven worden. Bij een klik op zo’n album, krijg je een grotere afbeelding, de titel, release datum en meer informatie over het album. Stap 7 en 12: Als je in het artiestmenu op ‘Related Artists’ klikt, krijg je een tag cloud van twintig gerelateerde artiesten. Hoe groter de naam van een artiest wordt weergegeven, hoe meer hij gerelateerd is aan de huidige artiest. In deze lijst van artiesten kan je ook weer doorklikken naar een andere artiest. Over die artiest wordt dan weer dezelfde informatie opgehaald. Het voornaamste verschil met de Android-toepassing zit erin dat evenementen van artiesten niet meer op een kaart worden weergegeven. Dat komt omdat we aanvankelijk dachten dat er op iPhone geen gps beschikbaar was en dan leek het ons moeilijk om dat nog te implementeren. We hebben op de demo echter geleerd dat zo’n gps wel bestaat, maar toen was het natuurlijk te laat. 1

http://www.shazam.com/

2/10


In plaats daarvan hebben we dan gezorgd dat gerelateerde artiesten weergegeven werden in een tagcloud, om visueel de band met de gekozen artiest weer te geven. Bovendien wordt nu ook iets meer informatie opgevraagd dan in de Android-applicatie. Zo ontbrak in onze vorige applicatie de korte biografie van de artiest, de informatie over een album, de release datum van een album,… We waren oorspronkelijk ook nog van plan om statistieken bij te houden over de verschillende radiostations, zodat we bijvoorbeeld de ‘liedjes van de dag’ konden laten zien. Dit zou dan bijvoorbeeld een pie chart zijn met de tien meest gespeelde liedjes van die dag op dat station, waarin de grootte van het stuk representeerde hoe vaak ze die dag gespeeld werden. Dit hebben we echter niet in ons storyboard opgenomen, omdat we onze twijfels hadden bij de haalbaarheid van dit plan. We wisten namelijk al dat de verschillende radiostations niet de informatie boden die we daarvoor nodig hadden. We zouden dus zelf om de paar minuten de liedjes moeten gaan opslaan in een database op een server. Dit plan is dus ook effectief niet gelukt, omdat we geen continu lopende server ter beschikking hadden. 3

SOFTWARE-ONTWERP

Het klassendiagram van onze applicatie wordt hieronder weergegeven in Figuur2. In dit diagram zijn enkele klassen niet weergegeven. Het betreft hier de Java klassen ‘Artist’, ‘Album’, ‘Event’, … Dit zijn dezelfde klassen als in de Android-applicatie en ze weergeven zou de grootte van het klassendiagram negatief beïnvloeden. Daarom verwijzen we daarvoor naar het verslag van onze Android-applicatie, Afbeelding 2. Dit klassendiagram is ook bijgevoegd in Bijlage 2.

Figuur 2: Klassendiagram iPhone. Eerst geven we een korte toelichting van de klassen in het systeem, daarna volgt een uitgebreidere bespreking over de werking van het systeem als geheel. We hebben gewerkt met JSP, zodat we de Java klassen die we voor onze Android-applicatie gemaakt hadden, konden hergebruiken. Meer uitleg over het gebruik van JSP vindt u onder de titel ‘Implementatie’. ‘Index.jsp’ is de pagina die toelaat verschillende stations te selecteren. De lijst van de verschillende radiostations wordt hier weergegeven. Vanuit deze pagina, kan je naar de volgende pagina, ‘noa.jsp’ gaan door op een radiostation te klikken.

3/10


‘Noa.jsp’ staat in voor het weergeven van het huidige en het vorige liedje op het gekozen station. In deze klasse wordt een nieuwe instantie van een ‘NoaHandler’ aangemaakt. De functie van die Handler bestaat erin dat ze basisinformatie over het huidige en vorige liedje (meer bepaald de titel en artiest) zal gaan opvragen en teruggeven. Om dat te doen, zal de Handler de API van het geselecteerde radiostation aanspreken en het xml-bestand, dat hij terug krijgt, interpreteren. Ook de refresh-functionaliteit en het terugekeren naar index.jsp om het station te veranderen, zitten in deze klasse vervat. ‘Song.jsp’ is de klasse die ervoor zorgt dat, wanneer in ‘noa.jsp’ op een liedje geklikt wordt, de lyrics van dat liedje worden opgehaald en weergegeven. Om de lyrics op te halen, wordt een LyricsHandler aangemaakt. Die zal bij onze lyrics API (www.leoslyrics.com) de lyrics van het gekozen nummer gaan ophalen en opsmukken voor gebruik. ‘Artist.jsp’ is de klasse die ervoor zorgt dat, wanneer op de artiest geklikt wordt, de nodige informatie voor die artiest opgehaald wordt. Vijf verschillende Handlers zullen zorgen dat zowel informatie over de artiest zelf (‘ArtistInfoHandler’), als informatie over zijn topalbums (‘TopAlbumHandler’ en ‘AlbumInfoHandler’) worden opgehaald. Eveneens wordt informatie over de evenementen van de artiest opgehaald (‘ArtistEventHandler’) en over de gerelateerde artiesten (‘ArtistSimilarHandler’). Al deze informatie wordt opgehaald bij de last.fm API (www.last.fm/api). Al deze opgehaalde informatie is bereikbaar vanuit deze pagina. ‘Searchprocess.jsp’ en ‘search.jsp’ laten toe om informatie over een artiest op te zoeken, die nu niet op de radio aan het spelen is. Er wordt een zoekveld getoond, waarin je de naam van de artiest kan intypen. Verder wordt door ‘artist.jsp’ de informatie over die artiest op dezelfde manier opgehaald en weergegeven als voor artiesten die op de radio te horen zijn. ‘Search.jsp’ zorgt er ook voor dat als de artiest die je hebt ingegeven niet bestaat, je de grootste matches in een lijst krijgt, zodat je eventueel van daaruit verder kan zoeken. ‘Marquee.jsp’, ‘currentsong.jsp’ en ‘updater.js’ zorgen er samen voor dat op iedere pagina bovenaan een balk verschijnt waarin het huidige nummer op het gekozen radiostation constant geüpdatet wordt. Alle jsp-klassen zouden dus ook pijlen naar deze drie klassen moeten bevatten, maar dat zou te rommelig worden. ‘Marquee.jsp’ is de klasse die ervoor zorgt dat er bovenaan een balk wordt weergegeven. Om die constant geüpdated te houden, hebben we een klein trucje moeten toepassen. Op elke pagina waar die balk voorkomt, is er verborgen op de achtergrond een pagina die de informatie over het huidig spelend nummer ophaalt en weergeeft (‘currentsong.jsp’). Deze pagina vernieuwt zichzelf heel de tijd. Naast deze onzichtbare pagina, is er ook een JavaScript ‘updater.js’ die door middel van de AJAX technologie (http://www.w3schools.com/Ajax/Default.Asp) de informatie die ‘currentsong.jsp’ weergeeft gaat inlezen en op de marquee zal afdrukken. Op deze manier wordt de zichtbare pagina niet vernieuwd en wordt de informatie op de balk toch up to date gehouden. De werking van het volledige systeem volgt makkelijk uit het klassendiagram en de vorige bespreking. Het opstarten zorgt ervoor dat ‘index.jsp’ aangeroepen wordt. Van daaruit kiest men ofwel een station ofwel wil men gaan zoeken op artiestnaam. In ‘noa.jsp’ wordt dat onderscheid gemaakt. Als een station aangeduid werd, worden het huidige en vorige nummer van dat station weergeven. Als er geen station geselecteerd werd, wordt je doorverwezen naar ‘search.jsp’ die het mogelijk maakt om een artiest op te zoeken. Wanneer op de titel van een liedje geklikt wordt, zorgt ‘song.jsp’ ervoor dat de lyrics op het scherm verschijnen. Als er op een artiest geklikt wordt, of een artiest wordt opgezocht met behulp van de zoekfunctie, zorgt ‘artist.jsp’ ervoor dat er allerhande informatie over de artiest beschikbaar is. Zo kan je een korte biografie lezen, topalbums bekijken, events nagaan en de gerelateerde artiesten opzoeken. Op elk ogenblik kan je naar ‘index.jsp’ terugkeren om het station te veranderen. Ook zijn er drie klassen: ‘marquee.jsp’, ‘updater.js’ en ‘currentsong.jsp’, die ervoor zorgen dat er bovenaan het scherm een balk is, waarin het huidige nummer op het gekozen station wordt weergegeven. Voor deze applicatie zijn we veranderd van lyrics API. De vorige moest wekelijks geheractiveerd worden met een nieuwe sleutel, er stond veel reclame in de lyrics en je kreeg maar 30 procent van de

4/10


lyrics terug. De huidige API is iets beter, maar nog niet geweldig. Hier worden namelijk de lyrics van minder liedjes gevonden. We krijgen nu echter al hele liedjesteksten met minder commentaar in. We vinden ons ontwerp zelf zeer goed gestructureerd. Met de uitleg hierboven zou zelfs een leek moeten kunnen begrijpen wat er precies gebeurt in ons programma. We hebben de verschillende functionaliteiten in verschillende klassen gestopt en die klassen elkaar laten aanspreken. We hebben ook handig gebruik gemaakt van de Java-klassen, die we al ontworpen hadden voor de Android-applicatie. 4

IMPLEMENTATIE

We hebben gebruik gemaakt van de JSP technologie voor de implementatie van onze iPhone applicatie. JSP (Java Server Pages) zijn in essentie Java bestanden die worden uitgevoerd op het moment dat de pagina geladen wordt. Deze files drukken HTML code af die dan de zichtbare pagina beschrijft. Dit maakte het voor ons mogelijk om de Java klassen die we voor ons Android project geschreven hadden, te herbruiken voor dit project. Alle uitbreidingen hierop (zoals het zoeken naar een artiest) hebben we dan ook in Java geschreven. De codering van de meeste pagina’s is vrij vanzelfsprekend: eerst wordt alle nodige informatie opgehaald uit de Java klassen en dan weergegeven op de html-pagina. In het vorige deel werd de communicatie met de verschillende API’s al kort uitgelegd. Het voornaamste punt is dat alle communicatie met de API’s gebeurd via Handler-objecten. Die objecten zorgen voor het aanspreken van de API door de juiste link aan te roepen en het opvangen van het xml-bestand dat de API’s als antwoord op de aanroep terugsturen. Elke soort informatie die opgevraagd wordt, bijvoorbeeld events tegenover albums, vereist een andere Handler. Er moet namelijk een andere url worden aangemaakt om de API aan te spreken en het xml-bestand dat terug gestuurd wordt heeft telkens een andere vorm. De belangrijkste moeilijkheid die we tegen kwamen, was degene die ervoor gezorgd heeft dat we de statistieken, waarover in deel 2 al gesproken werd, niet hebben kunnen implementeren. Zoals wij het zagen waren er 2 mogelijkheden om de informatie, die we nodig hadden om conclusies te trekken, te verkrijgen; enerzijds zouden de databases van de radio-stations aangesproken kunnen worden; anderzijds zouden we er zelf voor kunnen zorgen dat deze informatie regelmatig (bijvoorbeeld eens per minuut) bijgehouden werd in een eigen database. Na wat ge-experimenteer met de functies aangeboden door de providers van station-informatie werd al snel duidelijk dat de eerste optie niet mogelijk was. Playlists van radio-stations kunnen opgevraagd worden, maar de verkregen informatie is meestal niet beschikbaar over een tijdsspanne van 24 uur (wat we toch een minimum vereiste vonden om interessante statistieken te berekenen). De enige oplossing bestond er dus in nummers zelf, na vaste intervals, toe te voegen in een eigen database. In theorie is dit mogelijk. De oplossingen waar we aanvankelijk aan dachten waren het gebruik van cron-jobs op een server, of werken met een php-script dat blijft draaien. Aangezien we niet beschikten over een server waar we elke minuut een cron-script op konden laten draaien werd besloten grondig onderzoek te doen naar de php-oplossing. Met succes, we vonden een functie (‘ignore_user_abort’) die toelaat dat een aangeroepen php-script kan blijven draaien, zelfs nadat de gebruiker zijn browser venster sluit. Deze functie zou, in combinatie met de functie ‘set_time_limit’ ervoor kunnen zorgen dat een script oneindig lang kan draaien op de server, zonder dat interactie met een browser of andere client nodig is. Helaas waren alle php-servers, die tot onze beschikking stonden, beschermd tegen het gebruik van deze functies. Omdat er reeds wat tijd verstreken was na het onderzoeken van de hierboven beschreven mogelijkheden werd besloten geen station-statistieken meer te implementeren.

5/10


Een ander nadeeltje dat we ondervonden, was dat het betrekkelijk lang duurde om alle informatie over een artiest op te halen uit de last.fm API. We vermoeden dat dat niets met onze applicatie te maken heeft, maar vooral met de API zelf. Nog een andere nieuwe uitdaging was het zoeken op artiest. Deze functie kwam in onze vorige applicaties nog niet voor en hadden we ook nog niet in het storyboard vermeld. We hadden echter nog wat tijd over en besloten dan maar als kers op de taart een extra zoekfunctie in te bouwen. Als er een geldige artiest werd ingegeven, was er geen probleem. We konden dan immers gewoon de hele ‘artist.jsp’ klasse opnieuw gebruiken met een andere artiestnaam. Als er echter een ongeldige naam werd ingegeven, kregen we een foutmelding van de last.fm API (uiteraard). In ‘artist.jsp’ hebben we er dan voor gezorgd dat, wanneer een onbestaande artiest werd ingegeven, een lijst van bestaande, matchende artiesten werd weergegeven. Als men van daaruit verder klikt, kan ‘artist.jsp’ zijn oude functie hervatten. Ook de tagcloud van gerelateerde artiesten was een nieuwe functionaliteit. Daarvoor schreven we een functie die een match-percentage omzette naar lettergrootte en –dikte voor het weergeven van een artiest. Het oorspronkelijke stroyboard is enkel aangepast door de zoekfunctie op artiest toe te voegen. We konden bijna alle functionaliteit uit de Android-applicatie overnemen, dus hadden we tijd om ook deze functie nog toe te voegen. Over het ontwerp hebben we bijgevolg ook niet lang moeten nadenken aangezien we de klassen uit de vorige applicatie hergebruikt hebben. We wilden enkel een logische indeling in de getoonde pagina’s en naar onze mening zijn we daarin geslaagd. 5

RESULTAAT

We zijn allemaal best tevreden over het bekomen resultaat. We hebben een goed werkende applicatie, die ook vlot werkt op een echt Iphone-toestel (we hebben dit getest op de gsm van Peter). We zijn tevreden over de structuur van de applicatie, zowel op het vlak van het ontwerp en de programmaarchitectuur, als op het vlak van de gebruikersinterface. De structuur van het ontwerp lijkt ons logisch en relatief goed georganiseerd, en de interface is opgedeeld in logische delen. De functionaliteiten aangeboden door de toepassing zijn een mooie illustratie van het idee waarvan we vertrokken zijn. Toch vinden we het spijtig dat we functies als het bestellen van albums, het opslaan van informatie en uiteraard het tonen van radio-station-specifieke statistieken niet geimplementeerd hebben. De tijdsspanne waarbinnen het project afgemaakt diende te worden, samen met de eerder besproken problemen (zie punt 4: implementatie) lieten ons dit echter niet toe. Een ander minpuntje vinden we zelf de laadtijd van de informatie over een artiest, maar zoals in het vorige deel al aangegeven hebben we niet echt het idee dat dat aan onze applicatie ligt. We hebben het ontwerp, noch het idee achter de toepassing gebaseerd op bestaande toepassingen. Wel kunnen we achteraf de vergelijking maken met bestaande applicaties. Een vergelijking met Shazam werd reeds gemaakt in deel 1. Een andere verwante applicatie is ‘LastOnAmFm’ (http://www.cs.kuleuven.be/~sten/lastonamfm/#) van Sten Govaerts. Deze applicatie geeft een overzicht van de nummers gespeeld op verscheidene radio stations, en geeft aanduidingen van de locaties van de artiesten van de gespeelde nummers. Het kernidee achter deze toepassing is anders dan dat van onze toepassing, maar het werken met informatie over de nummers gespeeld op bekende Belgische radiostations is ook hier het beginpunt. Daar waar de toepassing van Mr. Govaerts interessante conclusies kan opleveren in verband met onder andere de wereldwijde verspreiding van muziek en hun populariteit, spitst onze toepassing zich meer toe op de ontdekking van muziek en het bieden van informatie over nummers waarnaar de gebruiker luistert. We vinden dan ook dat onze toepassing, hoewel minder uitgebreid, in het domein van mobiele applicaties zeker tot zijn recht komt.

6/10


6

OVER IPHONE (0,5 BLZ)

Het is duidelijk dat dit ontwikkelingsplatform iets helemaal anders was dan de vorige twee. We gingen dan ook een webapplicatie ontwikkelen en niet een echte native applicatie voor een iPhone. Daardoor konden we veel van de functionaliteiten die in de iPhone vervat zitten, niet gebruiken. Bij Android konden we bijvoorbeeld gebruik maken van de ingebouwde gps om makkelijk kaarten weer te geven en dergelijke. Wij hadden het geluk dat onze oorspronkelijke applicatie verder geen gebruik hoefde te maken van ingebouwde functionaliteiten (bijvoorbeeld een camera). Het ontwikkelen zelf ging redelijk vlot. Net zoals in Android, wordt de structuur van de lay-out en de eigenlijke functionaliteit ook in webapplicaties mooi gescheiden. Css-bestanden beschrijven de lay-out terwijl html in combinatie met jsp voor de invulling van die layout zorgde. Werken met AJAXtechnologie kan ervoor zorgen dat slechts bepaalde delen van een interface geladen worden, wat een enorm voordeel oplevert voor de manier waarop de gebruiker de applicatie ziet (voorbeeld: het balkje dat constant de juiste up-to-date informatie weergeeft). Dankzij het gegeven ‘iui.css’ bestand en de standaard componenten van iPhone, was het niet moeilijk om een standaard, maar toch mooie lay-out te verkrijgen. Ook Android had mooie standaardcomponenten ingebouwd, die klaar waren voor gebruik en via een xml-structuur geplaatst konden worden. Doordat het een webapplicatie was, was het natuurlijk een volledig andere manier van werken dan Android. We moesten nu zowel server- als client-side programmeren. Html-code, jsp en css vallen ook in de verste verten niet te vergelijken met de Java-code die we voor Android konden gebruiken. Het leuke aan het ontwikkelen van een webapplicatie is natuurlijk dat je ze ook gewoon op je computer kan laten draaien. Aangezien niet iedereen van ons een iPhone bezit, is het leuk dat onze applicatie ook nog op een andere manier gebruikt kan worden. Uiteraard is de flex-applicatie die we ontwikkelden hiervoor beter geschikt. Omdat vanuit een webapplicatie weinig functionaliteit van de iPhone zelf beschikbaar is, lijkt het ons vooral nuttig om webapplicaties voor standaard, niet op locatie gerichte applicaties zoals agendas, mail,... Voor andere functionaliteiten zouden we liever een native applicatie maken. 7

EXTRA

Een video-opname van de mogelijkheden van onze toepassing is te vinden op onze blog (link zie titel van dit document). Daarop is iets duidelijker te zien hoe de balk met real-time informatie er precies uit ziet en vooral hoe die tekst beweegt. Ook de code is hier beschikbaar. 8

BESLUIT

Samenvattend kunnen we stellen dat we tevreden zijn over onze prestatie voor het maken van deze webapplicatie. We hadden nog niet veel ervaring met het maken van webapplicaties, enkel Steven wist er al wat meer over. We hebben vooral geleerd om in html, css, JavaScript en JSP te werken. Op zich zijn die technieken allemaal niet zo ingewikkeld, maar de combinatie en het feit dat het er niet één, maar meerdere zijn, maakte het toch nog moeilijk genoeg. In het besluit van het vorige verslag hadden we vermeld dat we het spijtig vonden dat we nog steeds niet echt veel visualisatie hadden ingebouwd. We wilden daar voornamelijk iets aan doen door de statistieken die we zouden berekenen op een visueel mooie manier voor te stellen. Toen dat plannetje echter niet bleek te werken, hebben we geprobeerd er toch nog het beste van te maken. De balk met real-time informatie over het huidige nummer op het gekozen radiostation vinden we persoonlijk wel een mooie toevoeging. Het feit dat die tekst beweegt, maakt het een tikkeltje specialer dan onze vorige applicaties. Verder hebben we ook nog een tagcloud gemaakt van de gerelateerde artiesten. Ook dat doet de applicatie er beter uit zien. Toch hopen we in onze volgende applicatie nog iets meer visualisatie toe te kunnen voegen.

7/10


8/10

De structuur die we vooraf hadden opgesteld bleek goed realiseerbaar. Ook de layout die we voor ogen hadden hebben we voor het grootste deel kunnen toepassen. Zo kwam onze applicatie redelijk vlot tot stand, mede door het feit dat we de Android-functionaliteit bijna volledig konden hergebruiken. Het werken met tools voor webapplicaties was ook best leuk. Niet alleen om iPhone applicaties te maken, maar we hebben nu ook een basis voor eender welke webapplicatie te schrijven. Al bij al zijn we dus tevreden over het geleverde resultaat. Zoals ook het geval bij de twee vorige opdrachten was, staan we te kijken van hoe eenvoudig het kan zijn een nuttige, functionele applicatie te bouwen gebruik makend van externe diensten. Er is natuurlijk ruimte voor verbetering, en de functionaliteiten aangeboden door onze toepassing zijn verre van wat ze zouden kunnen zijn. Maar we zijn vooral trots op het feit dat we een werkende, mooie en vooral nuttige applicatie gemaakt hebben, waar we zelf ook af en toe handig gebruik van maken. APPENDIX Steven Vermeeren Storyboard Ontwerp Implementatie Verslag schrijven Tutorials Totaal

1 2 38 1 2 44

Emma Eyckmans 1 2 25 5 6 39

Peter De Roovere 3 3 22 4 7 39

Dieter Van Loon 1 2 22 1 4 30

Totaal 6 9 107 11 19 152


9/10

Bijlage 1:

Figuur 1: storyboard iPhone


Bijlage 2

Figuur 2: klassediagram iPhone (deels)

10/10

10. iphone toepassing. Groep 8 Blog

Recommend Documents