Eindverslag Multimedia

Eindverslag Multimedia MobiLEnvi Matthias Snellings Jordi Tielens Jeroen Wygaerts Professor: Eric Duval

1

Inhouds tafel Eindverslag Multimedia MobiLEnvi Abstract 1 Idee 2 Scenario Scenario 1 Scenario 2 3 Storyboard 4 Globale Architectuur Google login UserService Opslag van data Rest interface 5 Software Ontwerp 5.1 HTML5 Screenflow Implementatie 5.2 Android Screenflow Implementatie 5.3 iOS Screenflow Implementatie Model Controller 6 Vergelijking Technologieën GUI design Doorgeven van data Programmeertalen Ontwikkelingsomgeving Andere Besluit 7 Besluit 8 Appendix Tijdsbesteding Peer Review

Abstract In dit eindverslag voor het vak Multimedia bespreken we de evolutie die we doormaakten bij het maken van een mobiele applicatie in drie technologieën. Die applicatie zal de studenten zo goed mogelijk helpen bij hun alledaagse activiteiten die gerelateerd zijn aan hun studies. We kozen om dit te doen op een smartphone en niet op een tablet omdat er enkele belangrijke use cases zijn waar een tablet te groot is, bijvoorbeeld op de fiets je uurrooster checken.

2

In het hoofdstuk over het idee bespreken we welke principes we gebruikten om te bepalen welke functionaliteiten onze applicatie zou aanbieden. Hierna volgen 2 scenario’s die deze functionaliteiten toelichten. In het storyboard gaan we voor het eerst spreken over ons uiteindelijk resultaat door het originele ontwerp te vergelijken met het uiteindelijke resultaat in html5. Dit omdat HTML5 uiteindelijk het dichts aanleunt bij het originele storyboard. Uiteindelijk bleek dat we te veel hooi op onze vork hadden genomen en dat we niet ons volledig idee konden implementeren. Toch hebben we een behoorlijke hoeveelheid aan functionaliteiten geïmplementeerd en zijn we in de drie technologieën even ver geraakt.

3

1 Idee Ons idee bestond erin een applicatie te ontwerpen voor een learning environment waar de studenten nuttige zaken in verband met hun vakken die ze volgen kunnen terugvinden. We hebben ons vooral gefocust op de nuttige dingen die toledo aanbiedt zoals het uurrooster en de informatie die onder een vak terug te vinden is. We probeerden hierbij aanpassingen te doen die op dit moment beter kunnen in toledo. Zo vonden wij een medium voor het management van groepswerken iets wat ons studentenleven eenvoudiger kan maken. Ten-slotte integreerden we twitter en blogposts in onze applicatie, wat belangrijk is om ondersteuning voor dit vak aan te bieden aan studenten. Het feit dat schermruimte duur is in een mobiele applicatie was ook een belangrijke factor bij de integratie van alle functionaliteiten. In tegenstelling tot andere groepen voelden wij ons niet aangetrokken tot een systeem met gamification dat aangaf hoe goed een student bezig is. Zeker in een richting met veel projectvakken gebeurt het wel eens dat blokvakken een heel jaar verwaarloosd worden tot in de examenperiode. Wij worden er dan liever niet een heel semester op gewezen dat we niet goed bezig zijn voor deze vakken. Ook voelden geen van ons drie de ambitie de hardst werkende student te worden op een leaderboard. Een student moet volgens ons zelf uitmaken hoe hard hij moet en wil werken. Er zijn volgens ons ook nuttigere dingen dan al je tijd in je studies steken om bovenaan op een leaderboard te komen.

2 Scenario In de volgende twee paragrafen worden twee scenario’s gegeven die het originele idee illustreren. Hoe de uiteindelijke applicatie hiervan afwijkt wordt in het storyboard toegelicht.

Scenario 1 Bob wil een half uur voor zijn les Imperatieve Talen kijken waar de les doorgaat. Hij start de applicatie op. Hij krijgt een melding dat er een nieuwe taak is voor Multimedia. Hij klikt hier op door, ziet dat de deadline tegen 5 november is en hij wordt gevraagd of hij dit in zijn agenda wil zetten. Bob bevestigt. Hij gaat nu naar zijn kalender, hij ziet dat de deadline is toegevoegd en ziet ook dat Imperatieve Talen over 25 minuten zal beginnen in lokaal 200A 00.144. In de les aangekomen opent hij de slides van deze les.

Scenario 2

4

Bob heeft in de les met Jan en Piet afgesproken om een groepswerk te beginnen met hen voor het vak Multimedia. Hij wil onze applicatie gebruiken om de samenwerking in dit groepswerk gemakkelijker te maken. Hij start de applicatie en maakt een nieuw groepswerk aan. Hij kan medestudenten selecteren uit een lijst van de medestudenten voor het vak Multimedia. Hij kiest Jan en Piet. Bob wilt deze week samenkomen met de groep. Nadat Jan en Piet hun deelname aan het groepswerk hebben bevestigd, kan Bob de vrije momenten in het groepswerk zien en ziet zo welke momenten vrij zijn voor alle medestudenten binnen de groep. Hij ziet dat woensdagnamiddag vrij is en stelt het voor op het forum van het groepswerk. Drie uur later krijgt hij een melding dat Piet bevestigt dat dit moment goed is voor hem en iets later bevestigt ook Jan. Bob gaat terug naar het groepswerk en vult het moment in in de kalender van het groepswerk, dit komt nu automatisch in de persoonlijke kalender van de de drie studenten. Wanneer ze woensdagnamiddag een brainstormsessie hebben gehouden zetten ze dit in een document en voegen dit toe aan het groepswerk.

3 Storyboard Het storyboard wordt weergegeven in figuur 1. In figuur 2 wordt het uiteindelijke resultaat weergegeven voor HTML5 omdat we in deze technologie het beste het ontwerp van het originele storyboard konden volgen. 1: Wanneer Bob de applicatie start komt hij in het startscherm. Hier staan vier knoppen met daaronder de ongelezen updates in volgorde van belangrijkheid. In het uiteindelijke resultaat is de profielknop niet aanwezig voor het veranderen van eigen gegevens en standaardinstellingen. We hebben ook geen systeem geïmplementeerd om te tracken welke updates al gelezen zijn. De gebruiker laten aangeven dat hij een update gelezen heeft leek ons ook niet aangewezen. Voor de gemakkelijkheid zijn de belangrijkste updates de meest recente. List dividers met de datum waarop de updates gemaakt zijn, zijn toegevoegd voor een overzichtelijkere weergave. 2: Als bob zeker wilt zijn dat hij alle updates gelezen heeft, kan hij op het icoontje voor updates duwen. Hier krijgt hij dezelfde updates te zien als in het startscherm, maar met de mogelijkheid om alle updates te zien en ze te filteren volgens soort van update. Het uiteindelijke resultaat wijkt alleen af van het ontwerp door andere filters aan te bieden. Deadlines en afspraken zijn samen genomen in agenda omdat de aparte tabs te leeg zouden zijn. ‘Andere’ zijn dan gewoon de blogposts en de tweets en zijn hernoemd naar vakken. Een tab voor alle updates leek ons dan overbodig aangezien die al op het startscherm staan.

3: Bob wil zien wat zijn eerstvolgende les is en duwt hiervoor op het agenda icoon op het startscherm. In ons originele storyboard ontbreekt een ontwerp van de agendapagina omdat we geen idee hadden in welke maten we Google Calendar konden integreren in ons programma. Onze voorkeur was om de tabel van de agenda van Google Calendar te tonen en te laten bewerken in ons programma, maar vreesden toen al dat dit zeer ambitieus was. In ons uiteindelijke resultaat maken we geen gebruik meer van Google Calendar. Dit omdat we aan de

5

agenda een dikke week voor de deadline begonnen. Met Google Calendar zouden we dat we op dat moment een risico nemen omdat als dit niet lukte we niets van agenda in onze applicatie hadden. Daarom besloten we stukje voor stukje onze eigen agenda op te bouwen. Dan konden we eventueel een agenda laten zien die gedeeltelijk werkt. Uiteindelijk bleek er genoeg tijd te zijn om onze eigen agenda te bouwen zoals we wouden in de drie applicaties. 4: Bob duwt op het icoontje voor vakken in het startscherm en krijgt een overzicht van alle vakken die hij volgt. Het resultaat kon het ontwerp hier goed volgen. 5: Bob kiest het vak Multimedia en komt op de overzichtspagina van het vak waar hij de vragen en de tweets kan lezen die bij dit vak horen. Hier vindt hij ook de volgende vijf tabbladen: info voor de basis informatie, doc voor de allerhande documenten(8), groep voor groepswerken(7), studenten voor de medestudenten(6) en links voor externe links naar een vakwiki’s, blogs, enzoverder. In het uiteindelijke resultaat hebben we slechts twee tabs kunnen implementeren: info en medestudenten. Voor de rest konden we ons goed aan het ontwerp van deze twee tabbladen houden in html5. Alleen werd redundante informatie zoals het aantal studiepunten weggelaten en moest een systeem bedacht worden dat indien er veel vragen zijn, niet alle tweets naar onder worden geduwd. 7: De tab voor groepswerken zou het eerstvolgende zijn wat we hadden geïmplementeerd als we verder aan de applicatie hadden gewerkt. Hier konden de studenten een afzonderlijke chat voor hun groepswerk houden, maar nog handiger afspraken maken voor samen te komen voor het groepswerk. De applicatie zou de agenda’s van alle studenten samenvoegen en alle momenten weergeven wanner alle groepsleden beschikbaar zijn, gevolgd door alle momenten dat één groepslid niet kan. Dit is ook de rede dat we vrijetijdsmomenten in onze applicatie hebben geïntegreerd, zodat deze ook in rekening konden worden gebracht. 8: Aangezien we gekozen hadden om voor een smartphone te implementeren kreeg het lezen van documenten een zeer lage prioriteit. We zijn hier dan ook niet toe gekomen.

6

Figuur 1: Storyboard

Figuur 2: Resultaat in HTML5

7

4 Globale Architectuur De architectuur is gebaseerd op het principe van thin client/thick server. Op die manier moesten we veel van de complexiteit maar één keer ontwikkelen op de server en bleven de applicaties op de verschillende platformen eenvoudig. Zo hebben we alle feeds op de server geïmplementeerd alsook het versturen van twitter berichten zou op de server afgehandeld worden. Op die manier moeten de verschillende devices enkel via JSON met de server kunnen communiceren. Figuur 3 geeft een globaal overzicht van de Architectuur weer. Hierin vindt je de drie grote bouwblokken terug. Namelijk de Mobile Devices, de server en de externe services zoals twittersearch, blog/comment feed en als laatste het versturen van tweets via de Twitter API. Jammer genoeg merkten we twee weken voor het einde van dit project dat we geen tweets meer konden versturen via de server. We denken dat Twitter onze server geblokkeerd heeft om nog onbekende redenen. Na research op het internet blijkt dat er vaak problemen op duiken bij de samenwerking van Twitter en de App Engine. Na lang proberen om het toch nog via de server te doen bleek dat we vanuit de drie applicaties rechtstreeks met Twitter hadden moeten communiceren. Er was echter geen tijd meer om dit nog te implementeren. Hier heeft de thin client/thick server aanpak ons de das omgedaan.

Figuur 3: Overzicht globale architectuur

Google login UserService Om gebruik te maken van onze applicatie moet de gebruiker eerst inloggen. Dit gebeurt via een Google account. Hiervoor maken we gebruik van de UserService API van Google App Engine. Een alternatief is om gebruik te maken van de OAuth API van Google. Dit werkte niet omdat de data verstuurd wordt via REST en deze de coockies met de gebruikersinformatie nodig heeft. Met de UserService API werden de coockies automatisch op het device gezet wat niet het geval

8

is met de OAuth API. Het moet normaal mogelijk zijn om met OAuth API ook de coockies te zetten. Aangezien het met de UserService API al werkte zijn we hier op verder gegaan.

Opslag van data De HCI_Fetcher werkt met Entity objecten maar de rest van de backend maakt gebruik van de JDO (Java Data Objects) API. Die laatste laat ons toe geannoteerde java objecten te bewaren in de database. Aangezien we java objecten bewaren kunnen we eenvoudig lijsten toevoegen aan deze objecten die ook bewaard kunnen worden. Ook kunnen we gemakkelijk referenties naar andere objecten opslaan in de database, iets waartoe Entity objecten niet in staat zijn. Op het eerste zicht leek de JDO API een stuk beter en eenvoudiger te zijn dan het werken met Entity objecten. We wisten in het begin echter niet dat de Java objecten voor JDO moeten voldoen aan een aantal voorwaarden alvorens dit systeem werkt. Daarbovenop legt de DataStore van App Engine ook restricties op die samen voor veel problemen hebben gezorgd. Uiteindelijk hebben we alle velden en lijsten die objecten bevatten verwijderd en vervangen door Key objecten en lijsten met Key objecten. Aangezien die Key objecten een unieke referentie naar het Object hebben laten ze ons toe het Object uit de database te halen. Op die manier waren bijna alle problemen opgelost. Het klassendiagram van de bean klassen wordt weergegeven in figuur 4. Strikt genomen zijn er geen associaties meer tussen de verschillende klassen maar om de leesbaarheid te verhogen hebben we wel associatie lijnen getekend in figuur 4. Deze lijnen geven dus weer welke klassen verbonden zijn met elkaar met behulp van Key objecten. Key objecten kunnen eenvoudig omgezet worden naar een String en vice versa vandaar dat sommige functies werken met Strings in plaats van Key’s.

Figuur 4: Klassendiagram bean objecten

9

Rest interface Figuur 5 toont de klassen van de REST interface. Alle functies die een lijst terug geven hebben ook een rpp (Requests per Page) en page parameter om de data in meerdere stappen te kunnen opvragen. Dit is belangrijk voor het dynamisch opvragen van bijvoorbeeld de tweets. Zo kan je zoveel tweets ophalen als de gebruiker wilt, je vraagt ze gewoon per tien op bijvoorbeeld wanneer de gebruiker naar onder scrollt. Dit verhoogt de performantie aanzienlijk. Het type json in figuur 5 geeft aan dat het over een String in JSON formaat gaat en is dus in feite een gewone String. In de JSON bibliotheek zit een methode die java objecten met een bean specificatie kan omzetten naar een JSONObject. Deze methode hebben we gebruikt om de Bean classen om te zetten naar JSONObjecten.

Figuur 5: Klassendiagram rest package

5 Software Ontwerp Voor de drie technologieën zullen we telkens de screenflow en de implementatie voor elke

10

technologie bespreken. Enkel voor html5 wordt de screenflow uitgebreid besproken. Om niet in herhaling te vallen worden bij de screenflows van de andere technologieën enkel de verschillen met HTML5 toegelicht. We hebben ervoor gekozen om de basis lay-out van elke technologie te behouden. Een alternatief was de interface van de drie technologieën exact hetzelfde te maken zoals Streamy dit doet. De basis layout is vaak verzorgt in de eigen technologie en voor beginners in het mobiel programmeren leek het ons eenvoudiger om hier niet van af te wijken en onze prioriteiten elders te leggen. Sinds het tweede tussentijds verslag hielden we een begroting bij van de nog te implementeren functionaliteiten die we een bepaalde prioriteiten toekenden. Zo konden we naar de deadline toe werken en af en toe vergaderen tot welk stuk we zouden implementeren. Dit leidde er toe dat we op het einde drie applicaties konden afleveren die exact dezelfde functionaliteiten aanbieden.

HTML5 Screenflow In figuur 6 zie je de algemene screenflow van de applicatie in HTML5. De applicatie start in het startscherm waar je al direct de 30 recentste updates kan lezen. Een update is een tweet, een nieuwe blogpost, een nieuwe deadline of een nieuwe afspraak. Vanuit dit startscherm kan de gebruiker kiezen om naar de updates pagina, de agenda pagina of de vakkenpagina te gaan door op de passende icoontjes te duwen. Op de updates pagina kan de gebruiker de updates kiezen tussen updates die bij de agenda horen en updates die bij een vak horen. Updates van een agenda zijn nieuwe deadlines of afspraken. Updates van een vak zijn nieuwe tweets, blogpost of blogcomments. De updates zijn gesorteerd op timestamp met de recentste bovenaan. Hier kan de gebruiker ook meer dan alleen de recentste 30 updates bekijken door op ‘toon meer’ te duwen. In dat geval worden de volgende 30 minder recente updates opgehaald van de server en achteraan de lijst geplaatst. Op de agenda pagina worden de komende agenda momenten getoond. Deze zijn gesorteerd op volgorde van begindatum met het eerstvolgende agenda moment bovenaan. Ook hier kan je kiezen tussen enkel de uurrooster momenten, de deadlines, de afspraken en de vrije tijds momenten. Op figuur 6 is enkel het scherm met alle agenda momenten en de uurrooster momenten weergegeven omdat de rest triviaal is. Rechtsboven is een knop ‘plan vrije tijd’ waarmee je een vrije tijds moment kan plannen in het ‘plan afspraak scherm’. Bij deadlines en uurrooster momenten zijn we er vanuit gegaan dat die door een administrator worden toegevoegd. Hoe afspraken worden toegevoegd wordt in de vak pagina uitgelegd.

11

Figuur 6: Algemene screenflow html5

Wanneer de gebruiker op het icoontje duwt om naar de vak pagina te gaan, zal hij eerst een lijst krijgen met alle vakken die hij volgt waarvan hij vervolgens één kiest. Dit scherm is

12

weggelaten in figuur 6 aangezien dit gewoon een lijst is. Het uiteindelijke resultaat van de vakpagina bestaat in HTML5 maar uit twee tabs, een tab voor de vakinfo en een tab voor de medestudenten. In de tab voor de medestudenten staan alle medestudenten die dit vak volgen en in de tab voor vakinfo staat de staf, een vraag- en antwoordforum en de tweets horende bij dit vak. Wanneer je op een lid van de staf duwt (in dit geval enkel de professor) of je duwt op een medestudent kom je op de contact pagina. Hier kan je kiezen uit drie mogelijkheden om de geselecteerde persoon te contacteren. De eerste is mail waarbij de mailingservice van het device wordt geopend. De tweede is tweet waarbij een popup venster komt waarin je een twitterbericht kan typen. Dit bericht wordt naar de server verstuurd die er dan automatisch de @persoon annotatie aan het bericht toevoegd en het op twitter zou moeten posten. De laatste is ‘maak afspraak’ die je terug naar het ‘plan afspraak’ scherm brengt dat gelijkaardig is aan dat voor vrije tijd. Enkel de header is anders (‘plan afspraak’ in plaats van ‘plan vrije tijd’) en nu wordt de te contacteren persoon meegegeven aan de server die dit agenda moment opslaat als een afspraak met de betreffende persoon in plaats van een vrijetijdsmoment. Oorspronkelijk was het de bedoeling om de contact page in een dialog view te tonen zoals dit bij Android en iOS het geval is. Hoewel dit op dezelfde manier is geïmplementeerd als het twitterbericht dat wel als dialog view verschijnt werkt dit niet. Vanuit de info tab van de vakpagina zijn verschillende acties mogelijk. Om figuur 6 niet overvol te maken worden deze apart weergegeven in figuur 7.

13

Figuur 7: screenflow vanuit info tab van een vakpagina

Vanuit de info tab van vakpagina staan na de staf eerst de vragen en vervolgens de tweets horende bij het betreffende vak. In de lijst van vragen is het bovenste item altijd ‘stel een nieuwe vraag’, hierna volgen standaard maximum 2 vragen (hun onderwerp wordt weergegeven) en als er ten slotte meer dan 2 vragen zijn is het laatste item ‘toon alle vragen’. Als je op ‘toon alle vragen’ duwt worden alle vragen weergegeven onder ‘stel een nieuwe vraag’ en is het onderste item ‘verberg alle vragen’, wat terug het origenele scherm geeft. Bij de tweets is ook het bovenste item ‘nieuwe tweet’ om een nieuwe tweet te sturen. Standaard worden er maar twee tweets getoond, maar als je op ‘toon meer tweets’ duwt worden 15 tweets getoond en een knop ‘verberg tweets’. Nog eens op ‘toon meer tweets’ duwen geeft nog eens 15 tweets. Om niet helemaal naar boven te moeten scrollen na het opvragen van veel tweets, kan je op ‘verberg tweets’ duwen wat weer het aantal tweets beperkt tot 2. In iOS en Android is deze ‘Toon Meer Tweets’ knop niet nodig omdat zij de staat van het view kunnen opvragen. Hiermee wordt bedoelt dat zij kunnen opvragen wanneer de gebruiker bijna aan het einde van een scrollview is en kunnen zij dan meer tweets opvragen. Bij HTML5 is dit

14

niet mogelijk en moet dit dus aan de gebruiker gevraagd worden.

Implementatie In figuur 8 wordt een overzicht gegeven van de files die de implementatie van de HTML applicatie bevatten. De hele markup zit in index.html. Hierin zitten alle pages uit figuur 6 en figuur 7. De dynamische data wordt opgehaald door de javascript files. Aangezien javascript geen OO taal is hadden evengoed alle javascript functies in één file kunnen geschreven worden. Het leek echter overzichtelijk om de verantwoordelijkheden te spreiden over meerdere javascript files. login.js handelt de login met Google af. courses.js handelt het ophalen van alle vakken af en het selecteren van een vak. course.js handelt dan het inladen van alle dynamische data op de vakpagina af. Voor de rest zitten de verantwoordelijkheden van de javascript files in de naam.

Figuur 8: overzicht html5

15

5.2 Android Screenflow

Figuur 9: screenflow vanuit de start pagina

16

De screenflow in android is heel gelijkaardig aan die van HTML5. Toch was in android zeer moeilijk om twee tabellen onder elkaar te zetten. Twee tabellen met een vaste hoogte onder elkaar zou erg klein geweest zijn aangezien dan iedere tabel dan altijd de helft van het scherm in neemt en zelf een degelijke custom scrollview maken was veel te moeilijk. Vandaar hebben we gekozen voor een apart scherm met de zowel de Tweets als de Blog posts. Aangezien Android een hardware menu en back knop heeft kunnen we hieraan ook functies toekennen. Hierdoor kunnen sommige knoppen verplaatst worden van het scherm naar het menu om zo meer informatie weer te kunnen geven op het scherm. Ook kunnen de annuleer knoppen weg gelaten worden aangezien we hiervoor de Back knop kunnen gebruiken.

Figuur 10: Screenflow vanuit de vakinfo pagina

17

Implementatie De Android applicatie bestaat uit vijf grote packages. De Pagina package waarin alle Activity’s zitten, de ArrayAdapter package met alle Adapters, het Framework met de data objecten, de ListProxy’s en als laatste de HulpKlassen. De meeste functionaliteit zit in de ListProxy’s en de HulpKlassen vandaar dat we ook enkel deze packages gaan bespreken. In Figuur 10 zie je een overzicht van die twee packages. Als eerste hebben we de DataFetcher. Die zal de benodigde data beetje bij beetje ophalen in een aparte thread. Deze klasse is generisch waardoor weinig of geen cast’s moeten gebruikt worden. Het voordeel van deze klasse generisch te maken is dat er zeer weinig code duplicatie in de code zit. Het nadeel is wel dat de DataFetcher enkel correct kan werken als ook de server volledig consistent is opgebouwd. De DataFetcher krijgt een JSONParser mee die een JSON String omzet naar een lijst van JavaObjecten gebruik makende van Java Reflections. Door de methode-namen te vergelijken met de velden van het JSON object worden de String en Integer velden automatisch overgezet naar de bijhorende JavaObjecten. Voor alle andere data types moet er code geschreven worden. Om te melden aan de gebruiker dat de DataFetcher de data aan het laden is hebben we LoadingProxy’s gemaakt. Die tonen in de eerste of de laatste rij van de tabel een melding dat de data aan het laden is. Als de DataFetcher klaar is met laden verdwijnt deze melding. Aangezien dit Proxy’s zijn kunnen deze voor eender welke lijst toegepast worden. Een tweede Proxy is de DeviderProxy die scheidings rijen plaatst in de tabel op basis van de inhoud van de data. Aangezien de DeviderProxy een lijst krijgt met devidable objecten kan hij opvragen welke de tekst moet zijn op de scheidings rijen.

18

Fig. 10: Android Framework

19

5.3 iOS In dit deel gaan we de iOS technologie bespreken. Eerst gaan we de verschillen in de screenflow bespreken t.o.v. de andere technologieën. Vervolgens bespreken we de implementatie.

Screenflow De screenflow van de iOS applicatie wordt weergegeven in figuur 12 en 13. De algemene lay-out is ook in deze technologie voor het grootste stuk hetzelfde als in de twee andere technologieën. We bespreken daarom voornamelijk de verschillen. In figuur 12 zien we een scherm dat een nieuwe kalender item kan aanmaken. Dit verschilt wel van de andere technologieën. Hier maken we gebruik van een date picker die dan de datum van het begin -en eindmoment kan zetten. Om een contactpersoon te contacteren maken we net als in Android gebruik van een popup box waarna men dan de te wensen contactmanier kan selecteren zoals getoond in figuur 12. Net als in Android maken we in iOS ook gebruik van een aparte tab voor het bekijken van de updates van een bepaald vak. Dit is gedaan om dezelfde reden als in Android, omdat het moeilijk is om twee tableViews onder elkaar te implementeren. Ook worden hier het aantal updates per tien afgehaald. Als men aan de laatste update komt worden vervolgens de volgende tien updates afgehaald. Dit wordt getoond op het rechterboven scherm van figuur 13.

20

Figuur 12: Algemene screenflow iOS

21

Figuur 13: Screenflow van de vakpagina in iOS

Implementatie In iOs wordt er verplicht gebruik gemaakt van het Model-View-Controller patroon. Hierdoor wordt de weergave van de applicatie gescheiden van het data model. Het Model bevat dus de data die weergegeven moet worden en de views bepalen hoe deze data wordt weergegeven. De controller vormt de link tussen de twee en zorgt ervoor dat de juiste view de juiste data krijgt. Hieronder bespreken we nog het model en de controllers. De views zijn al getoond in de vorige sectie en in figuren 12 en 13.

Model Het onderstaande klassendiagram toont hoe het Model van deze applicatie eruit ziet.

22

Figuur 14: Klassendiagram Model iOS

23

We maken in ons Model gebruik van een singelton omalle data te kunnen doorgeven aan de verschillende views. Dit is de klasse User, die alle nodige info bevat voor de verschillende views. Deze houdt buiten de info van de gebruiker ook alle updates, calenderitems en vakken bij. In de ViewController van een bepaald vak wordt deze singleton terug aangeroepen en kan men dus aan alle benodigde informatie. Een alternatief zou zijn om de klasse User bij te houden in de klasse AppDelegate. Dit is ook een singleton en zou de klasse User dus maar één keer aanmaken. Een ander alternatief dat mogelijk is om de klasse User door te geven aan het volgende view. Dit vergt erchter meer implementatie. De klassen User erft van de klasse Person over. Deze laatste is ook de superklasse van de klassen Prof en Student. De informatie die overeenkomt zit in de superklasse. De klasse Updates houdt alle mogelijke updates bij. Hij maakt hier gebruik van de klassen Tweet, BogEntry en BlogComment. Deze drie klassen erven over van de klasse Update. BlogEntry en BlogComment verschillen voorlopig nog niet van elkaar, maar om eventuele uitbreiding te voorzien zijn deze toch opgesplitst in verschillende klassen. De klasse Course bevat alle informatie betreffende van één vak. De klasse Calendar geeft een duidelijk beeld van de verschillende tijdsbestedingen van de gebruiker. De verschillende tijdsbestedingen worden voorgesteld in de klassen Meeting, Deadline, Schedule en Leisure. Deze klassen erven over van de klasse CalendarItem. Van elk type object wordt een array bijgehouden, maar we houden ook één globale array van alle updates bij. Bij het maken van de objecten wordt ook al direct de juiste JSON geparste. Zo zal bij het initialiseren van en object Student een JSON moeten meegegeven worden om het object te kunnen maken. In iOS is het gemakkelijk om data uit een JSON te halen met behulp van het NSDictionary object. Door deze laatste klasse van Objective C kunnen we elk element uit de JSON halen. Het ophalen van de JSON wordt gedaan in de controllers. Dit wordt in de volgende sectie besproken.

Controller Voor elke view die geïmplementeerd is hebben we een controller gemaakt. We hebben hier geen figuur van gemaakt omdat alle views analoog zijn opgebouwd. Als er data voor een view moet worden opgehaald gaan we dit starten in de methode ViewDidLoad. Deze wordt automatisch aangesproken bij het laden van de view. Eenmaal de data binnen is zullen we deze data gaan fetchen. We halen een JSON uit de response en gaan deze JSON vervolgens door de bijhorende klasse fetchen. Eenmaal dit gedaan is gaan we de nodige elementen van dit view terug herladen.

24

6 Vergelijking Technologieën Om de vergelijking tussen de verschillende technologiën te maken hebben we een aantal onderverdelingen gemaakt zodat we de verschillen en de gelijkenissen kunnen bespreken.

GUI design De technologie die hier het beste uitkomt is iOS. Dit komt omdat het maken van de GUI in deze technologie zeer eenvoudig is omdat dit volledig grafisch gebeurt. Alle knoppen en labels kunnen gewoon op het scherm gesleept worden. Bij Android kan dit ook, maar het verschil is hier dat Android met veel schermresoluties kan werken waar iOS maar twee verschillende resoluties heeft, namelijk voor de iPhone en iPad. Doordat Android veel resoluties ondersteunt,is het maken van de GUI moeilijker is. Dit maakt dat je in Android niet kan zeggen dat je een bepaald GUI element op een bepaalde plaats wilt zetten. Je kan enkel zeggen dat iets relatief links, rechts, boven of onder een ander element moet staan. Bij HTML kan de GUI helemaal niet grafisch gemaakt worden. Dit moet allemaal handmatig geprogrammeerd worden. Android en iOS bieden meer basisonderdelen aan dan html5. Dit is natuurlijk sterk afhankelijk van het gebruikte framework, JQuery Mobile. Frapant is bijvoorbeeld dat JQuery Mobile geen handige date picker aanbiedt. Er bestaat een demo versie maar die bevatte nog enkele bugs waardoor we hem uiteindelijk niet konden gebruiken. Elementen in de GUI te zoeken om bijvoorbeeld de tekst van een label te veranderen is bij Android en HTML makkelijker als in iOS. iOS werkt met outlets die manueel gekoppeld moeten worden tussen de viewcontroller en het view zelf. Bij Android en HTML kunnen deze elementen gewoon opgezocht worden door hun id, en kan men deze dan updaten. Het nadeel van zo’n id is dat er geen compiler is die controleert of er geen twee elementen met dezelfde id zijn. In html5 hebben we bijvoorbeeld drie uur naar een bug gezocht omdat twee listviews dezelfde id hadden zonder dat er een foutmelding kwam. Een voordeel van HTML is dat deze zijn views altijd laat scrollen, in Android en iOS moet dit expliciet geimplementeerd worden.

Doorgeven van data Het doorgeven van data bij het veranderen van pagina gebeurt in alle technologieën anders. In HTML wordt er gebruik gemaakt van de locale datastore. In Android wordt de data geserialiseerd en doorgegeven aan de intent die deze nodig heeft. In iOS wordt er gebruik gemaakt van een singleton. Deze werkwijze kan in Android en iOS veranderd worden omdat er nog andere mogelijkheden zijn om data door te kunnen geven. In HTML is dit niet het geval, maar het is wel heel gemakkelijk om te implementeren. Android en iOS zijn dus wel meer flexibel als HTML, maar er is wel meer implementatie voor nodig.

Programmeertalen 25

HTML is geen programmeertaal maar een opmaaktaal, we maken hierdoor gebruik van Javascript om met dynamische data te kunnen werken. Javascript is echter een scripting taal en het is hier dus moeilijker om objecten te maken. Een voordeel van HTML is dat we rechtstreeks met de opgehaalde JSON kunnen verderwerken wat in de andere twee talen niet mogelijk is. Hierdoor hebben we dus geen objecten meer nodig. In de andere talen moeten we de JSON eerst parsen naar objecten om er gemakkelijk mee verder te kunnen werken. Het grootste verschil tussen Java en Objective C is het memory management dat nodig is in Objective C. In Java gebeurt dit automatisch wat de implementatie toch een stuk makkelijker maakt. Ook het typechecken is beter in Java. Bij Objective C geeft de compiler wel een warning als er een methode niet bestaat voor een object, maar geeft pas een fout bij de uitvoering. Bij Java vindt de compiler deze fout bij het compileren. Het asynchroon ophalen van de benodigde data is voor Android het zwaarste om te implementeren. In Javascript kunnen we gebruik maken van Ajax, in iOS is hier ook een standaard functie voor. Maar in Android moeten we echter zelf een nieuwe thread schrijven die dan de data blijft afhalen.

Ontwikkelingsomgeving Voor iOS zijn we verplicht om te werken met de Xcode ontwikkelomgeving, bij de HTML en Android kan de ontwikkelomgeving gekozen worden. Dit is een groot nadeel omdat we hiervoor een Mac tot onze beschikking moeten hebben. Het weergeven van foutmeldingen komt in Android het beste over. Hier worden concrete foutmeldingen gegeven waar we in iOS wel eens moesten zoeken achter de fout. In HTML worden deze foutmeldingen ook beter vermeld.

Andere Een moeilijkheid bij html5 is dat niet alle browsers dezelfde functies ondersteunen. Zo kon het zijn dat we een stuk implementatie schreven en dit op Google Chrome testte. Het kon zijn dat dit werkte zonder problemen en dat we later vaststelden dat dit stuk niet werkte op een device. In html5 kan je de staat van je view niet opvragen. Bij het dynamisch opvragen van de tweets per 20 om serverbelasting te vermijden kan je in Android en iOS een scrollview gebruiken. In Android en iOS kan je de staat van je view opvragen, kan je weten wanneer de gebruiker bijna onderaan de lijst aan het scrollen is en meer data op de server ophalen. In html5 is dat niet mogelijk en moet er dus een ‘Toon Meer Tweets’ knop voorzien worden.

Besluit Alle technologieën hebben hun voor- en nadelen, maar het is zeer moeilijk te besluiten dat er één technologie veel beter is als een andere. We kunnen wel stellen dat Android over het algemeen het meest flexibel is en iOS heeft de grootste leercurve door het memory management.

26

Onderstaande tabel geeft nog een overzicht van de besproken punten. Android

HTML5

iOS

Matig

Niet

Zeer goed

Zeer goed

Matig

Zeer goed

GUI: Vinden elementen

Goed

Goed

Goed

Doorgeven data

Goed

Goed

Zeer goed

Programmeertaal: leercurve

Zeer goed

Zeer goed

Matig

Programmeertaal: Oo

Zeer goed

Slecht

Zeer goed

Programmeertaal: Data ophalen

Goed

Zeer goed

Zeer goed

Ontwikkelingsomgeving

Zeer goed

Matig

Zeer goed

Duidelijkheid foutmeldingen

Zeer goed

Goed

Matig

GUI: Drag and drop GUI: Basisonderdelen

27

7 Besluit Initieel bleken we het meerste problemen te hebben met de implementatie van de applicatie in iOS maar dit kwam vooral omdat we hierin de grootste leercurve nodig hadden. Wij hadden namelijk alledrie meer ervaring met java dan met objective C. Eens dat we deze technologie onder de knie hadden bleek dit de eenvoudigste om een eenvoudige gui te maken. Zodra je meer custom gui elementen wil maken lijkt Android geschikter. Het grootste voordeel van HTML5 is dat het op alle platformen werkt: Android, iPhone, blackberry, enzoverder. Als we achteraf onze applicatie bekijken, lijkt deze misschien geschikter voor een tablet dan een smartphone. Voor de use case om snel je uurrooster nog op de fiets te checken blijft de smartphone handiger, maar voor de andere functies lijkt het tablet geschikter. Zo zal je meer vragen, meer updates en meer agenda items in één keer kunnen bekijken. Ook het scherm om een afspraak te maken, past niet op het scherm van een smartphone. Als de applicatie nog wordt uitgebreid met groepswerken en zeker met documenten, zal een tablet ook geschikter blijken. Bij zo’n applicatie is participatie van zoveel mogelijk studenten belangrijk. Als het om een commerciële applicatie zou gaan, is het feit dat er meer studenten een smartphone dan een tablet hebben nog een belangrijk argument. Maar als je daar abstractie van neemt, zou een tablet geschikter zijn. We zijn in alledrie de technologieën even ver geraakt met de implementatie van ons initieel idee. De manier waarop we gewerkt hebben, is echter wel verschillend. Dit komt omdat er weinig overleg is geweest over de manier van implementatie in elke technologie. We hebben wel afgesproken welke delen we prioriteit gaven, maar niet op de manier van implementatie. Zo maken we in iOS gebruik van een singleton om data door te geven aan de verschillende views. Waar we in HTML5 de local datastore gebruiken en in Android de klasse serializable te maken en door te geven aan de gewenste intent. De manier van implementatie kan dus heel verschillend zijn ongeacht de technologie, aangezien er verschillende methodes zijn om dit te

28

8 Appendix Tijdsbesteding Matthias Snellings

Jordi Tielens

Jeroen Wygaerts

Breinstorm

1

1

2

Scenario

2

1

2

Storyboard

3

4

3

Eigen blog

4

1

2

Blog van anderen

1

3

2

Twitter

0.5

1

1

aanleren technologie

15

10

25

programmeren

120

130

110

intern overleg

6

6

6

verslag 1

4

2

2

verslag 2

4

7

4

verslag 3

18

18

18

Totaal

178.5

184

177

Peer Review De scores voor de peer review gaan van -2 to +2.

29

Matthias Snellings /

Jordi Tielens

Jeroen Wygaerts

Job Performance

+2 De Android applicatie was volledig af tot het afgesproken punt en werkte naar behoren. Daarenboven heeft Jordi het meeste van de server geïmplementeerd

+2 De iOS applicatie was volledig af en werkte naar behoren.

Attitude

+2 Heeft een positieve attitude en helpt zelfs de andere als zij vastzitten met hun eigen technologie.

+1 Niets op aan te merken

Leadership/Innitiative

+2 Nam het meeste van de server op zich en ging ook anderen helpen zoals hierboven vermeld.

+1 Moest nooit vragen om iets te doen. Nam genoeg initiatief om het werk zelf te zoeken.

Management of Resources

+2 Deed zijn werk gelijkmatig en alles was op tijd af.

+2 Werkte met een gigantische eindsprint, maar iedereen deelt zijn tijd in zoals hij wil. Alle deadlines werden op tijd gehaald.

Communication

+2 Overleg gebeurt vlot. Jordi luistert altijd, afspreken gaat gemakkelijk en communicatie via mail verloopt ook vlot.

+2 Overleg gebeurt vlot. Jeroen luistert altijd, afspreken gaat gemakkelijk en communicatie via mail verloopt ook vlot.

30

Jordi Tielens /

Matthias Snellings

Jeroen Wygaerts

Job Performance

+2 De HTML5 app werkte goed

+2 Heeft een mooie iOs applicatie afgeleverd

Attitude

+2 Geeft feedback aan de groep op een opbouwende manier

+1 Niets op aan te merken

Leadership/Innitiative

+2 Durft soms de leiding te nemen en neemt vaak initiatief

+1 Zou wat meer leiding mogen geven en blijft soms wat op de achtergrond

Management of Resources

+2 Werkte op een gelijkmatig tempo naar het einde toe. En uiteindelijk was alles op tijd af.

+2 Heeft de achterstand die hij had volledig ingehaald dus ook hier niets op aan te merken

Communication

+2 Zowel mondeling als schriftelijk via mail zijn er nooit problemen geweest

+2 Zowel mondeling als schriftelijk via mail zijn er nooit problemen geweest

Jeroen Wygaerts /

Matthias Snellings

Jordi Tielens

Job Performance

+1: Alles is afgeraakt en werkt goed door.

+2: Alles is afgeraakt en werkt goed door. Heeft het meeste van de implementatie van de back-end gedaan.

Attitude

+2: Werkt altijd goed door. Is nooit negatief.

+2: Werkt altijd goed door. Is nooit negatief.

Leadership/Innitiative

+1: Doet zijn taken.

+2: Doet zijn taken. Heeft ook het initiatief genomen om aan de back-end te beginnen.

Management of Resources

+1: Voert zijn taken altijd op tijd uit. Is soms wel met andere dingen bezig dan nodig wat er dringender is.

+1: Voert zijn taken altijd op tijd uit. Is soms wel met andere dingen bezig dan nodig wat er dringender is.

Communication

+2: Communicatie verloopt vlot. In vergaderingen en met mails.

+2: Communicatie verloopt vlot. In vergaderingen en met mails.

31