Technische universiteit Delft
Bacheloreindproject
Do The Math
Begeleiders:
Auteurs: R.G.J. Slag 1507761 R.G.M. Visser 4043480
dhr. ir. L.J. Metz dhr. ir. D. S. van der Meer dhr. H.G. Gross 19 maart 2013
Voorwoord In het curriculum van Technische Informatica aan de TUDelft is in de afsluitende fase van de bachelor een volledig kwartaal gereserveerd voor het zogenaamde Bacheloreindproject. In dit project tonen studenten in groepen aan dat zij zelfstandig een project kunnen uitvoeren. Mogelijkheden hiervoor zijn bijvoorbeeld een stage bij een externe organisatie of deelname aan een onderzoek of ontwikkeling aan de TUDelft. Binnen het project leert de student om zijn/haar kennis, opgedaan aan de TUDelft, binnen een groter geheel toe te passen op het complete traject van softwareontwikkeling. Het project staat in principe gepland voor het laatste kwartaal van het academisch jaar, waarin de student geen andere studieverplichtingen heeft; hiervan kan echter worden afgeweken. Het verslag wat voor u ligt is het eindverslag van dit Bacheloreindproject. Aan dit project is gedurende een half jaar parttime aan gewerkt door twee studenten, in samenwerking met het softwarebedrijf Innovattic. De opdrachtgevers vanuit Innovattic zijn de heren ir. L.J. Metz en ir. D.S. van der Meer. Graag bedanken wij iedereen die heeft bijgedragen aan de succesvolle totstandkoming en afronding van dit project. Allereerst willen we de heren ir. Metz en ir. Van Der Meer bedanken voor het mogelijk maken om dit project uit te voeren onder hun hoede en voor alle hulp die we hebben gekregen tijdens het uitvoeren van het project. Ook willen we deheer H.G. Gross bedanken voor alle begeleiding vanuit de TUDelft. Tenslotte gaat onze dank uit naar mw. D. van Alphen en deheer C. Dekker voor hun ondersteuning op het gebied van design en audio.
Delft, 19 maart 2013
R.G.M. Visser R.G.J. Slag
i
Definities en afkortingen API Application Programming Interface, verzameling definities op basis waarvan een computerprogramma kan communiceren met een ander programma of onderdeel.
APNS ApplePush Notification Service, de service van Apple die de push notificaties afhandelt.
iOS Het besturingssysteem van de iPhone, ontwikkeld door Apple.
JSON JavaScript Object Notation, is een deelverzameling van de programmeertaal JavaScript. Het wordt gebruikt voor het uitwisselen van datastructuren, met name in webapplicaties die asynchroon gegevens ophalen van de webserver.
Obj-C Objective-C, de programmeertaal waarin iPhone apps geschreven worden.
PHP PHP: Hypertext Preprocessor, programeeertaal waarin de API geschreven is.
phpMyAdmin Grafische interface die de een database inzichtelijk maakt.
REST Representational State Transfer, is een veelgebruikte manier om communicatieprotocollen op het internet vast te leggen.
SDK ii
Definities en afkortingen
iii
Software Development Kit, een verzameling hulpmiddelen die de ontwikkeling van een programma op een specifiek gebied faciliteren.
SOAP Simple Object Access Protocol,een computerprotocol dat wordt gebruikt voor communicatie tussen verschillende componenten.
Inhoudsopgave Voorwoord
i
Definities en afkortingen
ii
Samenvatting
vi
1 Inleiding
1
2 Opdrachtbeschrijving 2.1 App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Aanverwante systemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 2 3
3 Tools 3.1 App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Server API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Communicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 4 4 4
4 Planning 4.1 Initi¨ele planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Definitieve planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 6 8
5 Programma van eisen 5.1 Must-haves . . . . 5.2 Should-haves . . . 5.3 Could-haves . . . . 5.4 Won’t-haves . . . .
. . . .
10 10 12 13 14
. . . .
15 15 15 19 23
7 Proces 7.1 Methodiek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Communicatie Innovattic . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Grafisch design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28 28 30 31
8 Testen
32
6 Ontwerp 6.1 Communicatie . . . 6.2 App . . . . . . . . 6.3 API . . . . . . . . 6.4 Server deployment
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
iv
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
Inhoudsopgave 8.1 8.2 8.3 8.4 8.5 8.6
Gebruikerstest app Betatest app . . . HockeyApp . . . . Unit test API . . . Stresstest . . . . . SIG . . . . . . . .
v . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
32 32 33 34 34 35
9 Toekomst 38 9.1 Zelfstandig op de markt brengen . . . . . . . . . . . . . . . . . . . . . . . 38 10 Conclusie
40
11 Evaluatie
41
Appendices
42
A Interactieontwerpen
43
B Gebruikerstest 45 B.1 Antwoorden vragenlijst . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 B.2 Opmerkingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 B.3 Vragenlijst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 C SIG resultaten 49 C.1 Eerste resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 C.2 Tweede resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 D REST aanroepen
51
Bibliografie
54
Samenvatting In de moderne wereld van mobiele apps leek ieder mogelijk spel inmiddels wel beschikbaar te zijn. Niets bleek echter minder waar. Op basis van deze waarneming en wat inventiviteit werd er dan ook besloten om een spel uit te brengen welke draaide om hoofdrekenen. Al snel werd bepaald om deze ontwikkeling onder te brengen in ons bacheloreindproject, welke we vervolgens konden uitvoeren onder de vlag van Innovattic. Het doel van de opdracht was dan ook om dit eerste initi¨ele concept uit te werken tot een volwaardig spelconcept. Dit spelconcept diende zodanig breed aansprekend te zijn voor het publiek, dat hieruit ook een app kon voortvloeien, die daadwerkelijk voor een grote schare fans zou kunnen zorgen. Vervolgens diende dit definitieve concept omgezet te worden in een app inclusief aanverwante systemen. Het eindproduct is een succesvolle vertaalslag geworden van het definitieve concept naar een app, die op het punt staat om uitgebracht te worden in de App Store van iOS. Op basis van ervaringen tijdens de gehouden gebruikerstesten is er dan ook alle reden om te geloven in de potentie van deze app. Binnen de app is er ´e´en speler, die op een turn based manier speelt tegen zijn/haar medespelers. Binnen ieder potje bestaan er verschillende ronden. Iedere ronde is vervolgens van een bepaald type, waarin ieder type ontworpen is om een bepaalde rekenfunctionaliteit van de hersenen te activeren. Men dient vervolgens in deze ronde een bepaald aantal vragen binnen een tijdslimiet op te lossen. Heeft de speler veel vragen goed en tijd over, dan ontvangt hij/zij een aantal extra punten afhankelijk van de resterende tijd. Na drie gespeelde ronden gaat het erom of de speler meer punten heeft weten te scoren dan zijn of haar tegenstander. Tenslotte wint degene met de meeste punten het potje. Naast de ontwikkeling van de app zijn er ook aanverwante systemen ontwikkeld, waarvan de API het meest in het oog springt. Deze API zorgt voor de communicatie tussen de smartphones en is daarmee de centrale spil in de backend. Gezien deze API vele duizenden simultane gebruikers moet kunnen ondersteunen is er dan ook speciale aandacht uitgegaan aan de opzet van de code. Hierdoor is het mogelijk om deze API relatief eenvoudig op te schalen tot vele duizenden gebruikers.
vi
Samenvatting
vii
Hoewel inmiddels het bacheloreindproject is afgelopen, is dit nog niet het einde van het project Do The Math. Inmiddels liggen er plannen voor vervolgversies van Do The Math welke verder zullen worden ontwikkeld in samenwerking met Innovattic.
1. Inleiding Op 29 juni 2007 werd de eerste iPhone uitgebracht. Hoewel het concept alles behalve nieuw was, werd de iPhone al snel het symbool voor de vooruitgang van de smartphone. De massa was snel overtuigd door de userinterface en het design. Dit zijn belangrijke aspecten waarbij de voorgangers van de iPhone (Windows Mobile 5 bijvoorbeeld) veel steken lieten vallen. Met een capacitief scherm kreeg de gebruiker een nieuwe ervaring met het besturen van een smartphone; een stylus was immers niet meer nodig. Al snel volgden concurrenten deze ingeslagen we, zowel de besturingssystemen als Android en meer recent Windows Phone 8 zijn inmiddels geduchte concurrenten binnen deze competitieve markt. De mobiele telefoons van tegenwoordig blinken echter niet alleen maar uit in de meegeleverde software vanuit de fabrikant, maar door de honderdduizenden apps die men kan downloaden vanuit een centraal punt voor het betreffende besturingssysteem (App Store, Google Play). Deze apps bieden een scala aan mogelijkheden. Van spelletjes tot chatapplicaties en van nieuwsapps tot vermaak, er valt voor bijna alles wel iets te downloaden; gratis of tegen betaling. De industrie voor dit soort applicaties (“apps”) is dan ook gigantisch gegroeid door de jaren heen. Succesverhalen als Whatsapp[1], Drawsomething[2] en Instagram[3] worden zelfs door mensen zonder smartphone herkend. Voor vrijwel ieder wat wils is er iets beschikbaar. Tenminste, zo lijkt het. Als snel besloten we dat we voor ons bachelorproject “iets” wilden gaan doen met mobiele apps. Niet alleen omdat wij beiden enthousiast smartphonegebruiker zijn, maar ook omdat een mobiele app veel verschillende technieken combineert. Zo is er een user interface en normale programmalogica, maar ook een uitgebreide serverbackend. Idee na idee werd bedacht met als inzet om te komen tot een wereldwijd bekende app van Nederlandse bodem. Tijdens de brainstormfase zijn verschillende idee¨en de revue gepasseerd en weer verworpen. Op basis van het uiteindelijke idee contact is er opgenomen met Innovattic. Samen met ir. Metz is dit concept vervolgens nog verder uitgewerkt. Uiteindelijk volgde de definitieve “go” van het project. Onder begeleiding van Innovattic kon dit concept worden uitgewerkt tot een volwaardig app voor de iPhone.
1
2. Opdrachtbeschrijving In ´e´en zin luidt het doel van de opdracht als volgt: “Het ontwikkelen van een app voor de Apple iPhone die draait om een turnbased multiplayer spelconcept gebaseerd op getallen met de potentie succesvol te worden.” In dit hoofdstuk zal dit verder uiteengezet worden. Allereerst onderscheiden we het hoofdproduct (de app voor de iPhone) en alle aanverwante systemen die de functionaliteit van de app ondersteunen.
2.1
App
De app is gebaseerd op een zelfbedacht concept. Dit concept is voor aanvang van het project op enkele punten nog verfijnd. Vervolgens heeft dit als leidraad gediend tijdens de uitvoering. Zoals al vermeld in de inleiding lijkt het landschap van mobiele apps meer dan oververzadigd. Voor vrijwel iedere functie lijkt er wel iets voorhanden te zijn. Echter, na wat beter zoeken komt men tot de conclusie dat dit niet het geval is. Waar er honderden spelletjes zijn die zich richten op snelheid, het oplossen van puzzels of het weten van trivia was er in de App Store geen app te vinden die zich op een leuke manier bezig hield met rekenen, iets wat veel mensen ook leuk vinden. Op basis van deze conclusie werd besloten om deze leemte te vullen met het ontwikkelen van een nieuwe app voor dit bacheloreindproject. Het concept draait om het spelenderwijs bezig te zijn met verschillende soorten rekenopgaven. Gebruikers spelen steeds korte spelletjes tegen vrienden. Ieder spel bestaat vervolgens weer uit verschillende ronden. Tijdens iedere ronde krijgen de spelers vragen van een bepaald type die zo snel mogelijk goed beantwoord moeten worden. Na iedere ronde volgt een overzicht waarin de speler kan zien hoe hij/zij heeft gescoord ten opzichte van de medespeler. Tijdens het spelen wordt de speler beloond door bijvoorbeeld achievements te behalen in het spel. Ook groeit de speler door het vaak spelen van deze spelletjes in ervaring, wat ook tot uitdrukking komt in het spel. 2
Opdrachtbeschrijving
2.2
3
Aanverwante systemen
Ter ondersteuning van de app dienen ook enkele aanverwante systemen ontwikkeld te worden. Het meest in het oog springend systeem hiervoor is een centraal communicatiepunt waar alle scores worden bijgehouden, verschillende gebruikers bijeen worden gebracht en de opgaven gegenereerd worden. Ook dienen er diensten als een notificatiesysteem gebouwd te worden dat gebruikers actief op de hoogte kan houden van veranderingen en updates.
3. Tools Binnen dit project worden voor het gemak twee trajecten onderscheiden. Beiden houden sterk verband met hun deployment. Enerzijds hebben we de app zelf, zoals die door het publiek wordt ervaren. Dit is de software die wordt gedownload vanuit de Apple Store naar iemands iPhone. Anderzijds bestaat er een serverbackend, die zorg draagt voor de achtergrondprocessen.
3.1
App
Voor ontwikkeling voor het iOS[4] platform is er eigenlijk weinig te kiezen. Apple ondersteunt slechts ´e´en ontwikkeltaal: Objective-C (“Obj-C”). Deze taal is een superset van C met de mogelijkheid tot object-georienteerd programmeren. Omdat men enkel voor iOS kan programmeren binnen het desktopbesturingssysteem van Apple wordt er gebruik gemaakt van Macs om op te werken. De IDE van Apple zelf (Xcode) is hierop gratis beschikbaar, deze IDE is toegespitst op ontwikkeling van iOS en OSX applicaties. De keuze hiervoor is eenvoudig; er zijn simpelweg geen andere opties.
3.2
Server API
Voor de server kunnen meer keuzes gemaakt worden. Als taal kiezen is gekozen voor PHP[5]. PHP is een krachtige en breed ondersteunde taal voor webdevelopment. Bovendien kan men in PHP eenvoudig snel programmeren. Als extra laag wordt CodeIgniter ingezet[6]. Dit framework voor PHP abstraheert een aantal details weg. Bovendien kunnen er veel plugins voor gevonden worden, waardoor het niet nodig is om basiscode opnieuw te schrijven. Bovendien heeft CodeIgniter goede documentatie, is het snel en de community is erg groot.
3.3
Communicatie
Het voornaamste doel van de server is om communicatie te faciliteren tussen alle smartphones die de app gebruiken. Dit wordt bereikt door de server het centrale punt in de communicatie te laten zijn. De server ontvangt zo de verzoeken van de telefoons, stuurt 4
Tools
5
een antwoord terug en verzendt relevante data naar andere apparaten. Dit geschiedt allemaal door een webinterface gebaseerd op de REST-architectuur (“Representational State Transfer”). REST is een veelgebruikte manier om communicatieprotocollen op het internet vast te leggen. Een alternatief zou het gecompliceerdere SOAP (“Simple Object Access Protocol”) zijn geweest[7]. Echter dit levert geen extra voordelen voor deze situatie op, maar het zorgt wel voor meer complexiteit (en dus kans op fouten). Ook is er voor CodeIgniter een REST plugin beschikbaar. Voor iOS is zelf een heel framework beschikbaar (RestKit[8]) die ook zorgt voor mapping met interne database van iOS (Core Data).
4. Planning Tijdens de eerste week bij Innovattic is er als eerste gekeken naar de planning. Door een planning te maken kan de beschikbare tijd zo nuttig mogelijk ingedeeld worden. Het project is in een aantal fases verdeeld: 1. de ori¨entatiefase, 2. de ontwerpfase, 3. de implementatiefase, 4. het eindverslag/presentatie. Deze onderdelen zijn vervolgens opgenomen in een initi¨ele planning die wordt uitgelegd in §4.1. Er is gepoogd deze planning vast te houden, maar de ervaring leert dat dit nooit volledig lukt. De uiteindelijke planning, die beschrijft hoe het proces is verlopen, wordt dan ook besproken in §4.2.
4.1
Initi¨ ele planning
De initi¨ele planning (figuur 4.1) is aan het begin van het project gemaakt op basis van inschatting. Hierin hebben we vier fases gedefinieerd. Deze zullen kort uiteengezet worden.
Ori¨ entatiefase Voordat het project daadwerkelijk kon beginnen diende eerst de opdracht uitgediept te worden. Gezien voor iOS-ontwikkeling het gebruik van de programmeertaal Objective-C de enige mogelijkheid is, is hier als eerste naar gekeken. Wegens de onbekendheid met de taal was het noodzakelijk om de best-practices en de syntax van de taal te leren. Voor het eindproduct wordt gemikt op een breed publiek. Het moet mogelijk zijn te zijn voor al deze mensen om simultaan te spelen. Om hiermee al zo vroeg mogelijk in het proces rekening te houden is dan ook al snel aandacht aan gegeven. Ten derde is er gekeken naar het psychologische aspect van mobiele games. Als startpunt is onderzocht welke mobiele games succesvol zijn en waarom deze zijn doorgebroken bij 6
Planning
7
het grote publiek. Voor het ontwikkelproces is het noodzakelijk te weten welke factoren wel en welke niet meespelen in de kans om een populaire game te lanceren. Bij deze ori¨entatie kwamen we het bedrijf “Elastique”[9] tegen; zij zijn de ontwikkelaar van de app “De slimste mens” vernoemd naar het gelijknamige televisieprogramma van de NCRV. Er is een afspraak met hen gemaakt om te horen welke problemen zij hebben gehad en hoe zij deze opgelost hebben.
Ontwerpfase In deze fase is er gekeken hoe de app en API technisch in elkaar dienen te zitten. Vanuit de onderzoeken uit de ori¨entatiefase was er al wat informatie bekend over de verschillende best-practices welke door andere ontwikkelaars zijn bewezen. Door deze voorbereiding was er direct een goed beeld welke elementen nodig zijn om een succesvolle app te maken. Deze elementen hebben we opgenomen in een Programma van Eisen (Hoofdstuk 5). Ten tweede is er ook gekeken naar de verschillende paden die een gebruiker door het programma kan nemen. Hier dient niet alleen technisch rekening mee gehouden te worden, maar ook dienen deze paden voor gebruikers logisch aan te voelen. Hiervoor is er een interactieontwerp ontwikkeld om deze route te beschrijven (Appendix A). Deze technische details zijn in overleg met Innovattic opgesteld. Op basis van deze feedback zijn er nog wat kleine details gewijzigd. Uiteindelijk vormen deze twee documenten het Requirements Analysis Document. Op basis van deze Requirements Analysis is een Plan van Aanpak opgesteld. Dit Plan van Aanpak is vervolgens afgewerkt in wekelijkse Scrum-iteraties.
Implementatiefase In deze fase is het product daadwerkelijk ontwikkeld. Hiervoor is het Plan van Aanpak leidend geweest. Tijdens deze fase zijn de app en de API simultaan ontwikkeld. Een van de punten die hierbij naar voren kwam is dat het belangrijk is deze ontwikkeling goed te co¨ordineren, om zo de wachttijd tussen partijen tot een minimum terug te brengen. Features die aan beide kanten implementaties hebben dienen binnen een korte periode na elkaar af te zijn, zodat er direct kan worden getest en eventuele bugs opgelost kunnen worden. Door middel van een goede en duidelijke communicatie is er voor gezorgd dat deze features snel en goed in testversies konden worden ingebouwd.
Planning
8
Eindverslag/presentatie Dit project draait op geen enkel moment om pure programmacode. Het is ook nodig deze code duidelijk te documenteren. Ook dient van zowel het proces als product verslaglegging te worden gedaan. Er is gekozen om dit verslag en presentatie actief tijdens het project bij te houden. Hiermee wordt voorkomen dat richting het einde van de beschikbare tijd een verslag alle beschikbare uren inneemt. Ook vanuit een regressieaspect is het verstandig dit direct bij te houden; veel ontwerpkeuzes zijn moeilijker te reconstrueren indien men inmiddels twee maanden verder is in de productontwikkeling.
Figuur 4.1: Gantt chart Initi¨ele planning
4.2
Definitieve planning
Tijdens ieder proces komt men erachter dat de planning, zoals die initieel is opgesteld, wijzigingen behoeft. Dit project vormt daar geen uitzondering op. Ten eerste bleek dat het ontwerpen van de app meer tijd zou kosten dan oorspronkelijk ingeschat was. Vanwege de intentie om een sterk en volwaardig product af te leveren is hieraan dan ook bewust meer tijd besteed om deze basis direct sterk neer te zetten. Ten tweede zijn er veel ontwerpkeuzes tijdens het proces ge¨evalueerd en geconcludeerd dat een alternatieve manier beter zou kunnen werken. Het verbeteren en aanpassen van de relevante code is een tijdrovende taak; ook omdat deze code na afloop opnieuw getest dient te worden om te voorkomen dat deze code zich anders gedraagt of minder effici¨ent blijkt te zijn. Ten derde bleek ook dat in de implementatiefase meer tijd ging zitten dan oorspronkelijk was ingeschat. Zo kostten het implementeren van veel functionaliteiten meer tijd dan op voorhand ingeschat werd. Voorts zijn verschillende bugs lastig op te sporen of te verhelpen (denk hierbij aan bugs die optreden indien een spel een bepaalde staat heeft). Deze staten moeten eerst exact worden getriggerd, wat redelijk veel werk met
Planning
9
zich brengt. Tijdens de gehele periode is er gedocumenteerd, maar mede door een langere implementatiefase is er later dan gepland begonnen aan het eindverslag (figuur 4.2).
Figuur 4.2: Gantt chart definitieve planning
5. Programma van eisen Voorafgaand aan het ontwikkelen van een softwareproject dient men te definieren aan welke eisen het eindproduct dient te voldoen. Binnen de informatica wordt vaak gebruik gemaakt van het MoSCoW-prioritiseringsmodel. Hierin worden vier categorie¨en onderscheiden. Ten eerste zijn er de Must-haves: zonder deze functionaliteit is het programma simpelweg niet compleet. Deze zullen worden behandeld in §5.1. Ten tweede komen de Should-haves, dit zijn functies die, indien mogelijk, in het eindproduct dienen te zitten. Deze Should-haves worden uiteengezet in §5.2. Ten derde zijn er de Could-haves, deze features zijn wenselijk, maar niet nodig voor het eindproduct. Deze worden toegelicht in hoofdstuk §5.3. Tenslotte zijn er de Won’t-haves, deze features worden uitgesloten van de ontwikkeling en kunnen in een latere versie eventueel worden toegevoegd. Deze features worden uitgelegd in §5.4.
5.1
Must-haves
Een aantal Must-haves spreken in het geval van iOS app ontwikkeling voor zich. Zo dienen potenti¨ele gebruikers de app te kunnen downloaden en worden alle iPhones vanaf de 3GS (inclusief) ondersteund. Er worden twee versies uitgebracht, ´e´en met reclame (gratis) die men kan upgraden naar een reclamevrije variant voor een klein bedrag. Indien er extra features ontwikkeld worden zullen deze ook primair beschikbaar gesteld worden voor de betaalde variant. Het upgraden naar de betaalde variant geschiedt inapp, dit houdt in dat de upgrade in de app zelf gekocht kan worden. Gebruikers hoeven dus geen nieuwe app te downloaden. Gezien de primaire functionaliteit het spelen van spelletjes is, is dit dan ook een Must-have. Ook is het voor toekomstige productontwikkeling noodzakelijk dat gebruikers door de app heen kunnen worden gevolgd zodat hier rekening mee kan worden gehouden.
Accounts Accounts zijn ook van wezenlijke belang voor de game. Iedere speler heeft een account waar vrienden hem/haar aan herkennen. Tegelijkertijd hebben accounts als nadeel dat dit een drempel opwerpt voor gebruikers. Daarom is het mogelijk om een beperkte anonieme account aan te maken. Hiervoor hoeft een gebruiker alleen een gebruikersnaam 10
Programma van eisen
11
te kiezen. Men kan echter ook kiezen voor een koppeling met Facebook, waarmee de vrienden van die persoon uitgenodigd kunnen worden om samen een potje te spelen. Men kan echter ook vrienden uitnodigen door ze te zoeken op gebruikersnaam. Deze gebruikersnaam kunnen mensen zelf instellen en wordt vervolgens in de app gebruikt. Indien men gebruik maakt van een Facebook- of E-mailkoppeling kan men ook het wachtwoord resetten. Tenslotte kan de gebruiker uitloggen.
Aanmaken spel Ook het aanmaken van spellen behoort tot een van de belangrijke mogelijkheden van de app. Zo kan men een spel starten met een bestaande vriend, een Facebookvriend, een nieuwe vriend (gezocht via gebruikersnaam) of een willekeurige speler. Beide spelers dienen het spel te accepteren voordat het gestart wordt. Vervolgens wordt dit spel in het homescreen van beide spelers getoond.
Spelmodi Het spel bevat verschillende spelmodi. Ieder spel bevat verschillende spelmodi verdeeld over drie ronden. Elke ronde heeft een maximale tijdsduur waarbinnen zoveel mogelijk vragen goed dienen te worden beantwoord. Een vraag is goed of fout; goede vragen leveren punten op, foute vragen niet. Binnen een ronde kan een gebruiker een vaststaand aantal vragen beantwoorden. De speler die aan het einde van alle ronden de meeste punten heeft wint het spel. Na afloop van het spel kunnen beide spelers direct een revanche-potje starten.
Talen Om gebruikers de app zo prettig mogelijk te laten ervaren wordt er, waar mogelijk, de taal van de iOS installatie overgenomen. Vanaf de lancering wordt er gemikt op de talen Engels, Nederlands, Spaans, Duits en Frans. Indien een gebruiker een taal heeft die niet door de app wordt ondersteund wordt er teruggevallen op het Engels.
Geluidseffecten Tijdens het spel zijn er verschillende geluidseffecten te horen bij verschillende interacties. Deze dienen ook aan- en uitgezet te kunnen worden in het instellingenmenu.
Programma van eisen
12
Pushnotificaties Om gebruikers zo duidelijk mogelijk te betrekken bij het spel, wordt er gebruik gemaakt van pushnotificaties naar hun iPhone. Gebruikers krijgen dan, vrijwel realtime, notificaties als een nieuw spel of ronde beschikbaar is. Alle actieve spellen staan in het home screen van de app, gesorteerd op wiens beurt het is. Ook wordt het app icoon (badge) binnen iOS aangepast om aan te geven hoeveel spellen nog wachten op een gebruiker, waardoor ze sneller blijven spelen. Zodra het spel is afgerond ontvangt een gebruiker ook een notificatie met de uitslag.
Server API Om de communicatie tussen smartphones centraal te houden wordt er gebruik gemaakt van het client-servermodel. De server is hierin het centrale koppelpunt welke de data bevat en de notificaties verstuurd naar de losse smartphones. De app communiceert met de server via een vastgestelde API via een beveiligde verbinding. De server controleert of het verzoek legitiem is voordat het wordt uitgevoerd. Ook enkele andere precondities (app versie bijvoorbeeld) worden gecontroleerd.
Design userinterface Het is natuurlijk belangrijk om de userinterface een prettige uitstraling te geven. Ook dient de app te voldoen aan interface-elementen die gebruikers verwachten van iOS apps (navigationbars, slide to refresh). Het spreekt voor zich dat de app vloeiend dient te reageren op user input. Ook mag de app niet crashen.
5.2
Should-haves
Achievements Gebruikers dienen achievements (kleine beloningen voor behaalde resultaten) te kunnen halen. Ook moet er tijdens het aanmaken van een spel een moeilijkheidsgraad gekozen kunnen worden.
Programma van eisen
13
Vraag overslaan Een speler kan een vraag overslaan, waarna hij deze later opnieuw krijgt. Dit voorkomt frustraties indien men vast zit op een vraag. Na afloop van de ronde kan men zien hoe men heeft gescoord. Tijdens de ronde is inzichtelijk hoeveel vragen goed of fout waren en hoeveel er nog resteren.
Tutorials en informatie Gebruikers hebben ook verschillende informatiebronnen nodig, zoals tutorials over de spelmodi en informatie over de ontwikkelaars. Deze informatie dient dan ook toegankelijk te zijn voor de gebruikers
Spelstatistieken Ook werkt het erg goed als gebruikers statistieken over hun speelgedrag kunnen inzien, zoals hun progressie over tijd. Deze dient zichtbaar te zijn (eventueel enkel premiumversie). Hetzelfde geldt voor topscores en verhoudingen tussen spelers. Ook hebben spelers een rank welke correspondeert met hun ervaringsniveau, welke wordt gemeten in ervaringspunten.
Chat Door gebruikers zich betrokken te laten voelen bij de game en de spelers is het handig om een mogelijkheid tot communicatie tussen spelers te hebben. Hierbij kan worden gedacht aan een kleine chat functie of een mogelijkheid resultaten te posten op social media.
5.3
Could-haves
Avatars Om de personalisatie en betrokkenheid van de game verder te verhogen kunnen gebruikers avatars instellen, zoals een foto of een plaatje.
Programma van eisen
14
Bonus punten Gebruikers die goed presteren in een spel dienen ook beloond te worden als ze veel vragen goed hebben en nog tijd over op het einde. Ze kunnen dan extra bonuspunten verdienen die meetellen voor het totaal.
Bot Indien een speler tegen een willekeurige tegenstander wil spelen, maar er is er geen beschikbaar binnen enkele minuten is dat niet prettig. In dit geval dient een bot dit op te vangen door zich voor te doen als speler en tegen de gebruiker te spelen.
5.4
Won’t-haves
De Won’t-haves zijn vrij kort. Zo wordt de app in eerste instantie niet uitgebracht met een specifieke iPad layout wegens limitaties in ontwikkeltijd. Ook zal het niet mogelijk worden om zelf een taal te kiezen; dit is altijd de taal welke wordt gebruikt door iOS zelf.
6. Ontwerp Voor het ontwerp is er direct gekeken naar de manieren waarop de productiecode zal worden gedraaid. Het verschil is door de twee platformen evident. Waar de API kan draaien op een centrale server zal elke client maximaal ´e´en app draaien. Hier is binnen het ontwerp dan ook rekening mee gehouden. Tussen deze twee platformen zal gecommuniceerd moeten worden. Deze communicatie dient plaats te vinden via een uniforme interface, welke nader uiteen zal worden gezet in §6.1. Hierna is er gekeken naar de verschillende componenten binnen deze structuur. Voor de app zal dit worden besproken in §6.2, de API wordt in §6.3 behandeld.
6.1
Communicatie
De communicatie tussen de server en de app dient op een duidelijk gespecificeerde manier te geschieden. Er is gekozen om de data te versturen via HTTP met behulp van REST. Op deze wijze wordt de data via JSON gestructureerd verzonden tussen de app en de API. Ook is het in de toekomst eenvoudig mogelijk om nieuwe typen app (bijvoorbeeld Android) te ondersteunen, gezien zowel JSON als REST industriestandaarden zijn. REST is een manier van HTTP-communicatie waarmee servers en apps kunnen communiceren. Zo weten apps bijvoorbeeld niet of ze via een tussenliggende server verbonden zijn; hierdoor is het eenvoudig mogelijk om load-balancing toe te passen binnen de backend. Hiervoor is het ook nodig om niet met sessies te werken, maar ieder verzoek een eigen basis te laten hebben, met bijvoorbeeld authenticatie.
6.2
App
De app wordt ontwikkeld in het programma Xcode, dit programma zorgt ervoor dat een aantal ontwerpkeuzes vast staan. Zo wordt er gebruikt gemaakt van een duidelijk onderscheid tussen model, view en controller: het MVC-model. Voor de models wordt er hoofdzakelijk gebruikt gemaakt van Core Data; een framework binnen iOS voor opslaan van data. Voor de view wordt er gebruik gemaakt van storyboards; een grafische user interface waarbinnen op een visuele manier views ontworpen kunnen worden. Tenslotte wordt er in het geval van controllers voornamelijk geleund op de standaardcontrollers 15
Ontwerp
16
welke beschikbaar zijn in iOS. Deze controllers kunnen vervolgens eenvoudig gesubclassed worden waarmee ze eenvoudig aangepast kunnen worden. Deze drie componenten zullen hieronder uitgebreider beschreven worden.
Core Data Core Data is een iOS framework wat gebruikt wordt voor permanente dataopslag. Core Data is gebaseerd op het entity-relationshipmodel, welke de data geserialiseerd opslaat in een SQLite-database. Deze data kunnen vervolgens weer worden opgehaald door middel van predicaten. Bij het ophalen wordt de data weer terugvertaald naar de oorspronkelijke Obj-C objecten. In figuur 6.1 wordt het domain model van de app getoond. Dit figuur
Figuur 6.1: Domain model core data
kan als volgt ge¨ınterpreteerd worden; binnen de app is er ´e´en gebruiker ingelogd. Deze gebruiker kan vervolgens meerdere vrienden hebben. Tevens heeft de gebruiker meerdere spellen. Ieder spel wordt gespeeld tegen een tegenstander en bevat drie ronden. Deze tegenstander hoeft geen vriend van de gebruiker te zijn. Een ronde bestaat uit een wisselend aantal vragen, dat afhankelijk is van het type ronde. Het type vragen binnen
Ontwerp
17
een ronde is altijd gelijk, het aantal is afhankelijk van specifieke instellingen van de server.
View Binnen Xcode worden views gecre¨eerd door middel van de storyboards. Storyboards zijn een grafische interface binnen iOS voor het aanmaken van de grafische user interface van de gehele app. Men kan hierin de verschillende schermen individueel ontwerpen alsmede het opstellen van de paden welke men tussen deze schermen kan nemen (zogenaamde “segues”). Voordat deze segues geimplementeerd zijn is er een interactieontwerp gemaakt. Dit interactieontwerp is te vinden in appendix A. Het interactieontwerp beschrijft hoe een gebruiker door de app heen kan navigeren en beschrijft welke acties er op welk moment worden uitgevoerd. Het is hiermee een van de eerste hulpmiddelen van de ontwikkelaar om het eindproduct te kunnen beschrijven aan andere belanghebbenden van het project.
Controllers Controllers zijn het grootste deel van de code binnen de app. Ter verduidelijking worden deze onderverdeeld in drie verschillende categorie¨en: Viewcontrollers, Managers en Frameworks.
Viewcontrollers De viewcontrollers zijn verantwoordelijk voor de koppeling tussen het model en de views. Een viewcontroller is voor verantwoordelijk voor een view. Hiervoor handelt hij de gebruikersinteractie af en verzorgt benodigde aanpassingen in het model.
Managers De managers binnen de app zijn verantwoordelijk voor een specifiek onderdeel. Dit zijn meestal acties welke binnen de gehele app plaatsvinden en daarom niet binnen een specifieke viewcontroller zijn geprogrammeerd. Men kan hierbij denken aan geluidseffecten, achievements, vriendschappen en lay-out. Als voorbeeld worden er door de hele app heen door de achievementmanager bijgehouden welke achievements er op dat moment gehaald zijn. Zo kan dit losgekoppeld worden van de viewcontrollers (low coupling) en is het ook eenvoudig nieuwe mogelijkheden toe te voegen zonder dat de gehele app
Ontwerp
18
aangepast dient te worden. Een ander voorbeeld is de lay-out manager, deze is verantwoordelijk voor de presentatie van een consistente userinterface. Dit zorgt ervoor dat indien er een bepaald userinterface-element verandert van uiterlijk dit meteen door de gehele app doorgevoerd wordt.
Frameworks Tenslotte is er gebruik gemaakt van verschillende frameworks. Dit zijn vaak grotere functionaliteiten van derde partijen die gebruikt worden binnen de app. Het grote voordeel van frameworks is evident: het scheelt ontwikkeltijd, implementatie is eenvoudig en een derde partij kan haar framework beter onderhouden.
RestKit
Het belangrijkste framework dat wordt gebruikt is RestKit. RestKit is een
framework dat een koppeling maakt tussen Obj-C en een REST-service. Voor ieder object in het model wordt een mapping gemaakt, deze mapping zorgt vervolgens voor de vertaling van het object naar een JSON- representatie en omgekeerd. Deze JSON representatie wordt vervolgens gebruikt voor de communicatie met de server. Ook zorgt RestKit voor een directe koppeling naar Core Data. Binnen Core Data worden objecten worden aangemaakt, geupdate of verwijderd met behulp van hun unieke primaire key (figuur 6.2). Het gebruik van RestKit elimineert de noodzaak om veel standaard servercommunicatie zelf expliciet af te handelen, zoals correcte data-ontvangst, netwerkstatus en de vertaling en opslag van de data.
Figuur 6.2: Restkit
Facebook
Binnen de app wordt er gebruik gemaakt van gebruikersaccounts. Dit is
noodzakelijk om een profiel te kunnen maken en gegevens over een gebruiker bij te houden. Een van de features van dit systeem is de mogelijkheid om een gebruikersaccount aan te maken door middel van een koppeling met Facebook. Facebook heeft hier een software development kit (SDK)[10] beschikbaar voor gesteld, waarmee een sessie kan worden opgezet worden naar deze service. Via dit framework kan een gebruiker inloggen, de app verifi¨eren en kan de app data van een gebruiker ophalen, zoals zijn informatie en vriendenlijst. Deze data wordt vervolgens ingezet voor het opzetten van het gebruikersprofiel en het zoeken van vrienden. Ook biedt de SDK de mogelijkheid om dingen te posten naar iemands Facebook Wall.
Ontwerp Flurry
19 Als laatste is er het Flurry framework[11]. Flurry is een bedrijf welke statis-
tieken levert aan app-ontwikkelaars over het gebruik van hun apps. Deze SDK wordt eenmalig ingeladen en houdt gespecifieerde acties van de gebruiker bij. Deze worden vervolgens in batches naar de server gestuurd, waarna de ontwikkelaar deze data kan inzien. Deze data kunnen de ontwikkelaar hulp bieden om de verdere ontwikkeling van de app te prioriteren.
6.3
API
Binnen de API kunnen verschillende grote componenten worden onderscheiden. Dit zijn: 1. GameActions 2. Helpers 3. QuestionLibraries
GameActions Het GameActions component bevat alle controllers en models die te maken hebben met de directe calls die de app naar de API doet. Hierin zitten alle acties, zoals het accepteren van een nieuw spelletje tot het versturen. Deze acties worden geinitieerd vanuit de app, die via een REST-verzoek de actie start. De server voert vervolgens de benodigde wijzigingen uit binnen de database en retourneert eventueel relevante data naar de app in het JSON formaat. Al deze verzoeken verlopen via de REST-aanroepen welke worden beschreven in Appendix D.
Helpers De Helpers bevatten klassen welke nodig zijn voor taken als externe communicatie. Hierbij kan worden gedacht aan het uploaden van avatars naar Amazons S3 [12] service, het versturen van E-mails naar Amazon SES of het leggen van contact met APNS. Deze klassen zijn niet zelf geschreven maar geimporteerd van de leveranciers van deze services. Het gebruik van deze externe klassen bracht veel tijdwinst voor het project, gezien de communicatie soms vrij intensief / ingewikkeld is en de eigenaar van de dienst beter kan inspelen op veranderingen of uitzonderingssituaties die kunnen voorkomen in de transacties.
Ontwerp
20
Binnen de Helpers zitten ook klassen die bijvoorbeeld periodiek uitgevoerd worden om feedback te geven of ontvangen van systemen (zoals APNS feedback en het herinneren van gebruikers aan openstaande spelletjes).
QuestionLibraries Tenslotte is er voor het genereren van de vragen uit het spel een apart component welke vragen gegeneerd voor een specifieke moeilijkheidsgraad. Binnen de game bestaan momenteel vier verschillende ronden: 1. Solve: los een opgave op; 2. Right or Wrong: geef aan of uit de expressie de uitkomst volgt; 3. Operators: Er is een expressie gegeven met uitkomst zonder de operatoren. Welke de speler op de goede plek dient te zetten; 4. Twentyfour: Maak van vier getallen het getal 24 (en gebruik alle getallen). Afhankelijk van het type vraag wordt deze real-time gegenereerd of wordt een voorgegenereerde versie opgehaald uit de database. De eerste drie rondetypes worden gegenereerd vanuit de database. Voor de verschillende moeilijkheidsgraden wordt dezelfde methode gebruikt, maar met andere parameters. Het rondetype “Twentyfour” laat zich echter niet zo eenvoudig realtime genereren. Daarom is gekozen om de unieke opgaven die een oplossing hebben eerst te genereren en op te slaan. Vervolgens wordt, afhankelijk van de moeilijkheidsgraad, ´e´en van deze vragen geselecteerd. Mocht de gebruiker een opgave anders oplossen dan de voorbeeldoplossing van de server, en deze oplossing is correct, dan zal deze ook als goed geteld worden. Voor de drie speltypen “Right or Wrong”, “Solve” en “Operators” worden de vragen door de server willekeurig gegenereerd. Hiervoor zijn een aantal kenmerken ge¨ıdentificeerd die de door gebruikers ervaren moeilijkheidsgraad beinvloeden: 1. De lengte van de opgave; 2. De verschillende operatoren binnen de opgave; 3. De grootte van de losse getallen in de opgave; 4. De grootte van de uitkomst van de opgave. Voor “Right or Wrong” wordt er ook nog rekening mee gehouden dat naarmate de moeilijkheidsgraad toeneemt, de variatie met betrekking tot de echte uitkomst kleiner wordt. Tevens worden aan verschillende kenmerken van de opgave punten toegekend. Zo wordt een vermenigvuldiging beschouwd als moeilijker dan een optelling; de opgave krijgt dan
Ontwerp
21
meer punten. Ook grotere getallen of negatieve uitkomsten tellen extra mee voor deze punten. Een opgave van een bepaald type binnen een bepaald bereik van punten te scoren voordat deze wordt geaccepteerd. Voor bepaalde moeilijkheidsgraden wordt er ook gebruik gemaakt van delingen. Het is echter vanuit het oogpunt van gebruiksvriendelijkheid beter om mensen enkel te laten rekenen met gehele getallen (waarbij een deling als 8 / 2 = 4 geaccepteerd wordt, maar 7 / 2 = 3.5 niet). Hiermee dient echter specifiek rekening gehouden worden tijdens het genereren. Indien het algoritme bepaalt om een deling uit te voeren treedt het volgende stappenplan in werking: 1. Neem een willekeurig getal binnen de gestelde grenzen (input 1). 2. Neem vervolgens het vorige gegeneerde deel van de opgave, indien deze niet bestaat neem een tweede willekeurig getal binnen de gestelde grenzen (input 2). 3. Neem een willekeurig getal tussen 0 en 1. Indien dit getal kleiner is dan 0.5, neem stap 4a. Anders neem stap 4b 4. (a) Deel input 1 door input 2. Indien de uitkomst een geheel getal is, accepteer en ga naar stap 5. Anders neem input 1 = input 1 + 1. Ga naar stap 4a (b) Deel input 2 door input 1. Indien de uitkomst een geheel getal is, accepteer en ga door naar stap 5. Anders neem input 1 = input 1 - 1. Ga naar stap 4b 5. De uitkomst van de deling is nu altijd een geheel getal, ga verder met het reguliere algoritme. Het bovenstaande algoritme zal altijd binnen eindige tijd eindigen. In geval 4a wordt input 1 vanzelf gelijk aan input 2 maal factor k. In geval 4b wordt input 1 uiteindelijk 1, waarna de uitkomst ook geheel is. Voor alle andere operatoren is de volgorde niet van belang, omdat negatieve getallen zijn toegestaan. Dit proces ziet er dan als volgt uit: 1. Neem een willekeurig getal binnen de gestelde grenzen (input 1). 2. Neem vervolgens het vorige gegeneerde deel van de opgave, indien deze niet bestaat neem een tweede willekeurig getal binnen de gestelde grenzen (input 2). 3. Neem een willekeurig getal tussen 0 en 1. Indien dit getal kleiner is dan 0.5, neem stap 4a. Anders neem stap 4b 4. (a) output is (input 1 ... input 2) met ... de geselecteerde operator. (b) output is (input 2 ... input 1) met ... de geselecteerde operator. 5. Ga verder met het algoritme totdat de lengte van de opgave is bereikt. Zodra de opgave volledig is opgebouwd wordt deze ge¨evalueerd. Vervolgens wordt de opgave voorbereid voor de app. Dit is afhankelijk van het type opgave.
Ontwerp
22
Solve: 1. Evalueer de opgave en sla het resultaat op. 2. Converteer de opgave naar een string en voeg een = teken toe. 3. Stuur de opgave en het resultaat separaat terug. Right or wrong: 1. Evalueer de opgave en sla het resultaat op. 2. Neem een willekeurig getal tussen 0 en 1. Indien dit getal kleiner is dan 0.5, neem stap 3a. Anders neem stap 3b. 3. Er is in 2 bepaald of het antwoord goed of fout moet zijn. (a) Neem het resultaat en ga verder naar stap 4. Het antwoord is dus goed. (b) Neem het resultaat en neem een afwijking binnen de gestelde grenzen van dit resultaat (dit gaat relatief). Het antwoord is dus fout. 4. Converteer de opgave naar een string en voeg een = teken en de uitkomst van stap 3 toe. 5. Stuur de opgave en of deze goed/fout is terug. Operators 1. Evalueer de opgave en sla het resultaat op. 2. Doorloop de opgave en sla iedere operator op en vervang deze in de oorspronkelijke opgave door een punt-karakter (.). 3. Converteer de opgave naar een string en voeg een = teken en de uitkomst van stap 1 toe. 4. Stuur de opgave, de uitkomst en de oorspronkelijke operators terug. Voor Operators is het mogelijk dat een gebruiker een alternatieve manier bedenkt waarbij het antwoord toch klopt. Deze expressies worden op de cli¨ent berekend en gecontroleerd. Indien deze ook correct is zal deze goed gerekend worden. Na het genereren van de opgave wordt gecontroleerd of deze uiteindelijk voldoet aan de gestelde eisen voor de moeilijkheidsgraad. Dit proces is als volgt: 1. De uitkomst wordt gecontroleerd of deze voldoet aan de eisen. Indien niet wordt de opgave afgewezen. 2. Iedere operator wordt bekeken. Operators hebben ieder een eigen puntenaantal wat wordt toegekend. Dit is afhankelijk van het speltype.
Ontwerp
23
3. Indien het antwoord negatief is kan de vraag meer punten krijgen. 4. Het totale punten aantal dient tussen de gestelde grenzen te liggen. Indien de gegenereerde opgave hier meerdere malen achtereen niet in slaagt, voorkomt de server een loop door deze toch te accepteren. Tenslotte is er een feedbacksysteem voor deze beoordeling. Van iedere vraag wordt bijgehouden welke moeilijkheidsgraad deze heeft en wat de puntenbeoordeling ervan was. Zodra gebruikers de vraag kunnen beantwoorden start in de app een timer die meet hoelang men doet over de vraag (nauwkeurig tot de milliseconde). Ook wordt er opgeslagen of de gebruiker het antwoord goed had. Met enige regelmaat wordt deze informatie gebruikt om de opgelegde grenzen vanuit de database te trainen, waardoor de moeilijkheidsgraden steeds beter aansluiten bij de daadwerkelijke niveaus zoals spelers deze ervaren.
6.4
Server deployment
Mogelijkheden Zodra er is voldaan aan de eis om de server API zodanig te bouwen zodat deze in de toekomst makkelijk opschaalt naar vele simultane gebruikers dient er gekeken te worden naar een opzet waarin deze schaalbaarheid ook tot uiting komt. Een schaalbaar systeem op een niet schaalbaar platform (met bijvoorbeeld slechts ´e´en server) behaalt alsnog niet de vereiste performance. Voor de deployment van servers zijn verschillende mogelijkheden bekeken. Hiervoor is er allereerst contact opgenomen met de makers van het spel “De Slimste Mens”, Elastique. Dit spel heeft in Nederland enkele tienduizenden dagelijkse gebruikers, waardoor schaalbaarheid ook in hun platform is meegenomen. Elastique heeft zelf hiervoor een cluster opgezet, dat in eigen beheer is gebouwd. Vanwege de gemaate afspraken met Elastique over de details van dit platform wordt hier niet verder over uitgeweid. De optie “eigen beheer” is vaak de meest voor de hand liggende optie. De server kan specifiek worden geconfigureerd voor de software welke erop draait. Tevens is dit eenvoudig werken met het oog op de ontwikkeling; men heeft meestal een ontwikkelserver ter beschikking. De code overzetten naar een dedicated machine is dan snel gedaan. Aan deze oplossing kleven echter ook een aantal forse nadelen. Allereerst is er binnen het team en Innovattic geen tot weinig ervaring met het opzetten van dit soort systemen. De kennis voor het goed en effici¨ent opzetten van een dergelijke configuratie is simpelweg
Ontwerp
24
niet aanwezig bij de ontwikkelaars; deze dient dan te worden ingekocht. Ten tweede zijn er redelijke investeringen noodzakelijk voor het kopen en onderhouden van het platform. Ten derde is het huidige team te klein om een 24/7 uurs ondersteuning te leveren op het platform. Tenslotte is er een groot nadeel aan een dergelijke opstelling: hoewel het systeem prima kan schalen binnen haar hardware grenzen, is het lastig snel meer capaciteit toe te voegen indien deze grenzen worden bereikt. Vervolgens is er gekeken naar het uitbesteden van een dergelijke oplossing naar gespecialiseerde partijen. Deze optie viel echter al snel af vanuit kostenoogpunt, de investeringen zouden voor het project te hoog worden. Hierna is er gekeken naar een serveroplossing in de “cloud”. Hierbij wordt er capaciteit afgenomen van een grote partij als Amazon[13], Microsoft[14], RackSpace[15] of Google[16]. Bij een dergelijke oplossing is het eigendom van de hardware uitbesteed aan dergelijke partijen en kan men, relatief eenvoudig, zelf een dergelijk platform opzetten. Voordelen zijn evident: capaciteit is direct bij en af te schalen, afhankelijk van de exacte vraag. Ook qua kosten is deze oplossing effici¨ent; er wordt slechts betaald voor de afgenomen capaciteit, facturatie geschiedt zelfs per seconde. Ook diensten als load- balancing kunnen direct worden afgenomen. Nadeel is dat software alsnog zelf ge¨ınstalleerd en geconfigureerd dient te worden. Tenslotte is er gekeken naar gespecialiseerde cloudgebaseerde diensten voor ontwikkelaars; voorbeelden hiervan zijn Heroku[17]en AppFog[18]. Deze diensten draaien op een platform als Amazons AWS en bieden een omgeving, welke direct geschikt voor ontwikkelaars. Servercode uitrollen is eenvoudig: 1. Geef aan welke omgeving je wilt gebruiken (Amazon AWS of RackSpace bijvoorbeeld), 2. Geef aan welke programmeertaal je code gebruikt, 3. Koppel eventuele databases, 4. Geef een URL op waaronder je code te bereiken is, 5. Upload de code, 6. Schaalbaarheid van code wordt vervolgens geregeld door deze partij.
Keuze In dit geval is er voor AppFog gekozen in plaats van Heroku vanwege een simpele reden: Heroku ondersteunt geen PHP applicaties en AppFog wel. Qua tijdsduur was het geen optie code te herschrijven naar een andere taal. Beide platformen zijn verder vergelijkbaar, hoewel Heroku iets meer add-ons ondersteunt. Het grote verschil tussen de twee is
Ontwerp
25
de wijze van facturatie. Heroku werkt met een model waarbij de gebruiker betaald voor CPU-tijd, terwijl AppFog factureert op basis van RAM gebruik. Beide partijen hebben gratis uitgeklede pakketten beschikbaar die ideaal zijn voor ontwikkeling. De situatie voor AppFog werkt als volgt: binnen AppFog maakt men een applicatie aan. Deze applicatie wordt vervolgens voorzien van een limiet aan RAM, indien een applicatie gedurende enkele seconden over dit limiet heengaat wordt deze opnieuw gestart. Van iedere applicatie kan men meerdere instances (instanties) draaien. Tenslotte maakt een applicatie verbinding met services zoals een SQL-server, welke wordt gedeeld tussen de verschillende instances van een applicatie (dit kan ook tussen verschillende applicaties). Inkomende requests worden automatisch geloadbalanced tussen de verschillende instances van een applicatie. Services als een SQL-server zijn transparant voor de gebruiker opgedeeld over meerdere servers, welke real-time met elkaar repliceren. Instances kunnen direct worden bij en afgeschaald, afhankelijk van de vraag. Facturatie geschiedt door middel van pakketten, waarbij men meer RAM tot zijn beschikking krijgt. Er zijn voor de ontwikkelaar echter een aantal zaken waar men rekening mee moet houden in het ontwerp. Al deze factoren spelen echter ook al mee binnen een schaalbaar platform. Zo delen instances geen schijfruimte; dit impliceert dat er binnen de instances geen data mag worden opgeslagen die van belang is voor het functioneren. Deze data dient te worden opgeslagen op een veilige locatie zoals een database of externe locatie. Ook zaken zoals caches dienen of gedeeld te worden tussen instances (als service bijvoorbeeld) of slechts data te bevatten welke direct opnieuw gegenereerd kan worden. De servercode voldoet aan al deze eisen.
Opzet Voor DoTheMath wordt er in de ontwikkelfase gebruik gemaakt van de gratis versie van AppFog. Hierin is er voor de ontwikkelaar 2 GB RAM beschikbaar, die op te delen valt in blokken van 128 MB. Voor de API zijn er twee versies online; een test en een acceptatie-omgeving. Beiden draaien op 256 MB RAM met slechts ´e´en instance, beide zijn gekoppeld aan dezelfde SQL-service waar de data instaat. De acceptatie is bedoeld voor stabiele code, waar de app naar verbindt. De test is bedoeld om code te testen en te stabiliseren, totdat deze ook naar de acceptatie wordt uitgerold. Voor de uit te brengen app wordt er een productie-omgeving gestart. Deze zal ook 256 MB RAM gebruiken, maar met meerdere instances. Ook zal deze niet verbinden met dezelfde database. Ter bevordering van
Ontwerp
26
de ontwikkeling is er ook een applicatie van phpMyAdmin aanwezig, hierdoor is de database eenvoudig inzichtelijk en kunnen wijzigingen op een praktische manier worden doorgevoerd. Voor alle taken die op bepaalde tijden dienen gedaan te worden is er een kleine applicatie aanwezig die op gezette tijden opdrachten uitvoert, zoals het versturen van pushnotificaties en het laten verlopen van oude spellen.
Dataopslag Zoals al genoemd is het bestandsysteem op de server niet blijvend. Door het opnieuw starten van instances en het feit dat apps op iedere instance kunnen komen kan de beschikbaarheid van de data niet gegarandeerd worden. De API slaat deze data dan ook op bij een externe dienst, in dit geval Amazons S3. Gezien de applicatie al draait op het AWS platform van Amazon binnen AppFog, zorgt het plaatsen van de data binnen hetzelfde platform ervoor dat vertragingen zo laag mogelijk zijn. Tevens heeft Amazon S3 als voordeel dat de data op een gestructureerde manier redundant is opgeslagen, wat de kans op dataverlies minimaliseert. Tenslotte kan deze data, indien gewenst, direct uitgeserveerd worden aan apps, zonder eerst langs de API te moeten. Vooral in het geval van avatars is dit een voordeel, gezien deze zo opgehaald kunnen worden zonder de API te belasten.
E-mail Een andere limitatie is dat AppFog servers geen E-mail kunnen versturen als anti-spam maatregel. Ook hiervoor dient een extra dienst gebruikt te worden. Do The Math maakt heel weinig gebruik van E-mail; enkel om nieuwe gebruikers uit te nodigen of wachtwoorden te herstellen. Desondanks is het nodig om te zorgen dat deze E- mail betrouwbaar wordt afgeleverd zonder problemen. Door de wereldwijde groei van spam is het inmiddels echter niet meer zo trivaal om Email betrouwbaar te laten aankomen; maatregelen als SPF (“Sender policy framework”) en DKIM (“Domain Keys Identified Mail”) dienen goed ge¨ımplementeerd te worden. Hiervoor is ook de kennis en tijd niet aanwezig, waardoor er ook is gekozen dit uit te besteden naar Amazon. Amazon levert hiervoor het SES platform, waarmee men middels een API E-mail kan versturen. Amazon regelt vervolgens de correcte DKIMkeys. Voordat men E-mail kan versturen dient men zelf de aangeleverde SPF records te implementeren.
Ontwerp
27
DKIM en SPF zijn technieken gebruikt om te E-mail te valideren. DKIM signeert een bericht, waarvan de publieke sleutel in de DNS staat. Hiermee kan een ontvanger controleren of de mail daadwerkelijk afkomstig is van een domein. SPF controleert of de server die de E-mail verzendt E-mail mag verzenden namens dat domein. Een complete uitleg van deze technieken gaat echter te ver voor dit verslag.
Deployment diagram In figuur 6.3 is te zien hoe alle componenten samenwerken en communiceren met elkaar.
Figuur 6.3: Deployment diagram
7. Proces Van het ontwikkeltraject zijn er een aantal aspecten welke besproken dienen te worden. Allereerst is de methodiek die is gebruikt gedurende het proces van toepassing; welke techniek was dit en hoe is deze gebruikt. Dit komt aan bod in §7.1. Ten tweede behoeft de communicatie naar Innovattic, het begeleidend bedrijf, een uitleg. Dit zal besproken worden in §7.2. Ten derde wordt de totstandkoming van het grafisch design behandeld in §7.3.
7.1
Methodiek
Er zijn verschillende methoden voor softwareontwikkeling om het proces vorm te geven. Het meest bekende model is het waterval-model, veel gebruikt bij bijvoorbeeld bouwprojecten. Het model wordt echter steeds minder gebruikt in de software-industrie, omdat dit lang niet altijd goed aansluit bij de eisen die de industrie stelt. Tegenwoordig wordt er daarom door steeds meer bedrijven gebruikt gemaakt van verschillende manieren van zogenaamde “agile development” [19] processen. Deze processen werken vaak op basis van features welke in het eindproduct komen in plaats van het volledige eindproduct. Deze features worden vervolgens iteratief ge¨ımplementeerd, met als doel iedere paar weken (afhankelijk van de gekozen intervallengte) een versie uit te brengen welke is uitgebreid met nieuwe mogelijkheden. Voorbeelden hiervan zijn Extreme Programming en Scrum[19]. Voor Do The Math is er gekozen om gebruik te maken van Scrum. Ten eerste lenen mobiele apps zich erg goed voor korte sprints waarbij features worden opgeleverd. Door te ontwikkelen met Scrum methodiek is het mogelijk om iedere week een nieuwe testversie met minder bugs en meer features naar een groep testgebruikers te sturen. Ten tweede is Scrum momenteel de methode die gebruikt wordt binnen Innovattic, het aansluiten aan een bestaande methode is dan ook eenvoudig voor alle betrokkenen. Ten derde ondersteunt Scrum ontwikkelaars sterk om all-round te kunnen functioneren. Binnen de projectgroep is deze kennis ook zodanig verdeeld. Door het gebruik van deze methode wordt wachttijd op elkaar geminimaliseerd en tijdsverlies voorkomen. Het gebruik van Scrum is goed bevallen. Dagelijks werd een korte uitleg gegeven over wie welke taken ging uitvoeren en werd de vorige dag ge¨evalueerd. Ook het gebruik van 28
Proces
29
korte sprints werd als positief ervaren. Nieuwe versies kunnen razendsnel ontwikkeld worden, waardoor eventuele bugs zo snel mogelijk aan het licht komen. Tenslotte zorgt de ontwikkelmethode voor een goed overzicht voor alle partijen; zo is op ieder moment duidelijk waar het project staat en waar het project zal zijn na afloop van de huidige iteratie. Ook zijn er een aantal nadelen ontdekt binnen de gebruikte methodiek. Zo is in dit specifieke geval het onderscheid tussen de verschillende rollen klein. Zo is het team tevens Product Owner. Tevens is de Scrum master in het geheel ook weer Product Owner. Dit zorgt ervoor dat de traditionele rolverdeling zoals Scrum deze definieert niet geheel gevolgd kan worden (dit is deels inherent aan kleine teams). Ten tweede is er in mindere mate gebruik gemaakt van een daadwerkelijk backlog met een burndown-chart. In plaats hiervan is een reguliere issuetracker gebruikt waar alle bugs en features in vermeld waren. Hoewel er wel voor iedere sprint werd gekozen welke features ge¨ımplementeerd zouden gaan worden, is de scheiding tussen bugs en features niet altijd volledig gemaakt. Zoals al even kort aangestipt is er voor het project ook gebruikt gemaakt van een bugen issuetracker: Chili[20]. Chili is een bewezen platform waarin men onder andere de beschikking heeft over een wiki, issuetracker, roadmap en filesharing. De keus voor Chili was al snel evident: het is het reguliere platform binnen Innovattic voor projecten. Door simpelweg gebruik te maken van dit platform is het voor alle betrokkenen eenvoudig om op de hoogte te blijven van de huidige status. In het begin van het project is er in mindere mate gebruik gemaakt van de mogelijkheden van Chili. Hoewel er heel ambitieus werd omgegaan met de documentatie in de ontwerpfase, is deze vervolgens weinig bijgewerkt. Deze situatie ontstond doordat beide teamleden, door het intensieve gebruik van Scrum, zodanig op de hoogte waren van de specificaties en afspraken dat het maken van documentatie vaak werd overgeslagen als zijnde overbodig. Door het project heen zijn features en bugs echter wel consequent in Chili gezet, omdat dit systeem werd gebruikt binnen de Scrumstructuur. Richting het einde van het project is er weer veel documentatie opgeleverd, ook om later uitbreidingen van het spel naar andere mobiele platformen eenvoudig te faciliteren. Bij de aanvang van het project is er allereerst gekeken naar een eisenpakket waar het eindproduct aan diende te voldoen om te kunnen spreken van een geslaagd ontwikkeltraject. Dit eisenpakket is in samenspraak met Innovattic opgesteld en heeft tijdens het project gediend als handvat voor de productontwikkeling. Dit programma van eisen is besproken in hoofdstuk 5. Vervolgens is er aan de hand van dit programma van eisen, in combinatie met de geplande tijdsduur, een initieel plan van aanpak opgesteld. Hierin is opgenomen wanneer
Proces
30
bepaalde mijlpalen bereikt dienden te worden en hoe de ontwikkeling van de verschillende componenten samenhangt.
7.2
Communicatie Innovattic
Gezien de manier waardoor er is gekozen om met Innovattic dit project uit te gaan voeren, is het niet verrassend dat de communicatie op een goede manier is verlopen. Zo is er direct voor gekozen om drie dagen per week aan het project te besteden, gedurende een half jaar. Tijdens deze periode is er bij Innovattic op kantoor gewerkt. Enerzijds omdat dit een zorgt voor een duidelijk moment waar er aan het project gezeten wordt, anderzijds zodat alle betrokkenen duidelijk inzicht hebben in de voortgang van het eindproduct. Binnen Innovattic is er het meest gecommuniceerd met de twee eigenaren en tevens begeleiders van het project: ir. L.J. Metz (Lauwerens) en ir. D.S. van der Meer (Desmond). Voor het project hebben zij ons de ondersteuning geboden die nodig was om het project tot een goed einde te brengen. Aan het begin van iedere week werd er een korte meeting belegd met ir. Metz om te kijken wat deze week de doelen zouden worden. Aan het einde van de week werden deze doelen vervolgens ge¨evalueerd en besproken (als onderdeel van het Scrumproces). Ook hebben er tussendoor een aantal meetings plaatsgevonden die waren gericht op andere aspecten van de game, zoals de gameplay en functionaliteiten. Deze meetings hadden ook als belangrijk punt om te co¨ordineren welke doelen gesteld dienden te worden voor de app om het uiteindelijke succes te meten. Een ander groot voordeel van het werken op het kantoor van Innovattic was dat het mogelijk was om vragen te stellen aan andere ontwikkelaars van Innovattic. Omdat veel onderdelen van het platform nog onbekend waren aan het begin van het project was het zeer nuttig hierover vragen te kunnen stellen. Op dit gebied heeft vooral ir. Van Der Meer ondersteuning geleverd met kennis, ervaringen en best-practices. Veel andere medewerkers van Innovattic hebben ook bijgedragen aan oplossingen met suggesties, bug reports en brainstormsessies. Wederzijds is er tijdens het proces sprake geweest van kennisoverdracht. Zo is er door ir. Van Der Meer meerdere malen naar de programmacode gekeken om deze te voorzien van commentaar en suggesties voor verbeteringen. Omgekeerd is er tijdens informele besprekingen een presentatie gegeven voor het gehele team van Innovattic, waarbij de problemen en oplossingen die gebruikt zijn binnen Do The Math zijn behandeld.
Proces
7.3
31
Grafisch design
Het grafisch design van de app is een belangrijk gegeven. Consumenten zijn zich zeer bewust van het uiterlijk van het beoogde spel; het is dan ook belangrijk om te zorgen dat dit geoptimaliseerd is. Hiervoor is besloten om mw. D. van Alphen (Dorien) aan te trekken, zij is masterstudent Industrieel Ontwerpen aan de TUDelft. In gesprekken met mw. van Alphen is er al in een vroeg stadium gekeken naar de uitstraling die het spel kenmerkte en welke grafische stijl hiervoor gekozen zou worden. Besloten is om een stijl te hanteren die doet denken aan een vrolijke basisschool. Krijt- en prikborden, whiteboards en rekenmachines voeren binnen de verschillende speltypes de boventoon (design is afhankelijk van het speltype). Verder worden er lettertypes gebruikt die het menselijk schrift nabootsen en wordt er veel gebruik gemaakt van kleurrijke cijfers op de achtergronden. Qua kleuren is er gekozen voor contrasten, enerzijds zijn er vele matte tinten aanwezig, anderzijds zijn basiselementen uitgevoerd met een fellere kleurtint. Deze designkeuzes zorgen ervoor dat het product meer als een geheel oogt. Dit zorgt op zijn beurt weer voor een betere speelbaarheid en verhoogde amusementswaarde.
8. Testen 8.1
Gebruikerstest app
Binnen het testen van de app is er voornamelijk gebruik gemaakt van gebruikerstests. Hierbij voeren gebruikers (dit kunnen ook ontwikkelaars zijn) specifieke acties uit binnen de app. Deze acties dienen bepaald gedrag van de app te forceren. De uitkomst van dit gedrag kan vervolgens worden gecontroleerd door de ontwikkelaar. Deze wijze van testen is gekozen door de opzet van de app. De app bevat relatief weinig logica en deze haalt vaak data op van de server. Veel acties, zoals het reageren op aanrakingen, worden vanuit Apple ge¨ımplementeerd. Het automatisch testen van deze onderdelen zorgt voor veel extra werk, terwijl de voordelen klein zijn. Het gebruik van gebruikerstests, in combinatie met snelle en korte iteraties, zorgt ervoor dat het testen intensief gebeurd. Testen gebeurt vanzelfsprekend tijdens de ontwikkeling waardoor evidente bugs niet in een release terecht komen. Aan het einde van een iteratie wordt een testbuild vervolgens verstuurd naar alle testers. Zij kennen het verwachte gedrag van de software; indien er afwijkingen plaatsvinden kunnen zij eenvoudig een bugreport indienen via de projectsoftware. In het geval van een crash zal bij een herstart van de app deze automatisch debugdata opsturen naar het ontwikkelteam. De oorzaak van deze crash kan vervolgens worden uitgezocht zodat deze wordt opgelost in de komende iteratie.
8.2
Betatest app
Na enkele maanden ontwikkeltijd was Do The Math inmiddels stabiel genoeg om getoond te worden aan een selecte groep testers. Het directe doel van deze test was om te bepalen hoe men reageerde op het concept, hoe eenvoudig er door de app te navigeren was en of men tevreden was met de opgaven en de moeilijkheidsgraad ervan. De test is gedaan met tien willekeurig gevraagde studenten van de TUDelft op 27 december 2012 in het YES!Delft gebouw. Vrijwel alle betreffende studenten hadden zelf een iPhone om mee te testen, twee andere studenten kregen een iPhone voor de test vanuit Innovattic. Op de betreffende telefoons was de meest recente stabiele code gezet. De beoordeling van de test werd tweeledig uitgevoerd. Allereerst werd er door het ontwikkelteam simpelweg geobserveerd hoe men reageerde en wat er tegen elkaar gezegd 32
Testen
33
werd. Ten tweede kregen alle studenten na afloop van de test een formulier waarop zij het spel konden beoordelen op verschillende onderdelen. Zodra alle testers de software op hun telefoon hadden staan is er een korte introductie gegeven van Do The Math en is hen verteld waarop deze test zich voornamelijk richtte. Vervolgens konden de testers onderling aan de slag om het spel te spelen gedurende twee uur. Tijdens deze uren is er rondgelopen door het ontwikkelteam waarbij er is gekeken naar de ervaring van mensen. Ook is er gekeken hoe snel mensen doorhadden hoe spelmodi werkten (hier was bewust geen uitleg over gegeven) om zo te kunnen beoordelen in hoeverre deze geschikt zijn voor verschillende gebruikersgroepen. Tijdens deze test is er veel informatie verzameld over hoe mensen reageren op het product. Ook is het heel nuttig om juist diegenen te betrekken welke niet hebben deelgenomen aan het ontwikkelproces. De belangrijkste observatie was dat de testgroep het spel leuk vond om te spelen. Na twee uur werd de test afgesloten, terwijl veel mensen nog wel even door wilden gaan. Vervolgens is besloten om de versie die op hun telefoons stond nog tijdelijk te ondersteunen, zodat testers ook later nog gevolgd konden worden. Ten tweede bleek dat de spellen en hun moeilijkheidsgraad goed werden beoordeeld, helaas met ´e´en uitzondering: TwentyFour. Zeker op de laagste moeilijkheidsgraad is deze spelmodus door het ontwerp nog te lastig vergeleken met andere onderdelen. Onder andere door deze test is vervolgens gekozen om TwentyFour niet meer te laten genereren binnen de laagste moeilijkheidsgraad. Tenslotte gaven de spelers, zowel impliciet door hun gedrag als expliciet op hun formulier, aan dat ze het spel erg leuk vonden om te spelen. Alle relevante resultaten van de gebruikerstest zijn inzichtelijk in appendix B. Hierin worden ook de gemiddelden en varianties van de scores getoond.
8.3
HockeyApp
Voor het uitrollen van testversies naar alle testers wordt gebruik gemaakt van het HockeyApp pakket[21]. Dit pakket is een primair hulpmiddel binnen Innovattic voor het uitrollen van testbuilds naar betrokkenen. Zodra een nieuwe build online wordt gezet ontvangen testers meldingen dat er een nieuwe build beschikbaar is; dit kan via de app zelf of via pushnotificaties. De tester kan de nieuwe versie vervolgens direct installeren. Binnen de HockeyApp website kunnen ontwikkelaars vervolgens bijhouden hoeveel uur er door testers is getest, welke crashes optraden (en in welke versie), welk type telefoon de tester gebruikt en heel veel andere data welke het oplossen van bugs vergemakkelijkt.
Testen
8.4
34
Unit test API
Binnen de API wordt er gebruik gemaakt van unit tests. Software zoals een API leent zich uitstekend voor dit type tests gezien het karakter van een API. Een app stuurt een losstaand verzoek naar de API, waarna deze het verzoek uitvoert. Er is dus in sterke mate controle over pre- en postcondities van ieder verzoek. Binnen de API is er voor ieder mogelijk verzoek een testcase aangebracht. De database wordt in een teststand gebracht, waarna het verzoek wordt ge¨emuleerd door de API via de REST-interface aan te spreken. Vervolgens wordt de eventuele data bekeken welke de API terugstuurt alsook de staat van de database na afloop van het verzoek. Indien beide voldoen slaagt de betreffende testcase. Deze testcases bestaan vervolgens voor alle mogelijke aanroepen en worden uitgevoerd op een losse database. Deze database is zo gemodelleerd dat deze voor ieder verzoek voldoet aan de geldende precondities. Ondanks dat de client-server specificatie exact is opgesteld worden randvoorwaarden en ongeldige API-calls ook getest. De server zal deze niet uitvoeren maar een foutcode teruggeven.
8.5
Stresstest
Voor een mobiele app welke potentieel door tienduizenden mensen simultaan gespeeld dient te kunnen worden is het ook van belang dat de backend van deze app dit aantal verzoeken kan afhandelen. Zoals eerder beschreven is het platform om die reden schaalbaar opgezet (via AppFog). Echter dient er een indicatie gegeven te worden in hoeverre dit platform bezoekers kan verwerken. Om deze reden is er een stresstest uitgevoerd op de backend applicatie. Hiervoor zijn vier instances van de backend ingeschakeld, welke ieder 256 MB RAM ter beschikking hadden. Deze zijn vervolgens met de tool ab (Apache Benchmark) op verschillende concurrency niveaus. Een hoge concurrency simuleert meerdere simultane gebruikers. Vervolgens is ervoor gekozen een van de zwaarste operaties als basisoperatie te gebruiken en is caching volledig uitgeschakeld. Uit deze test blijkt zowel de applicatie als het onderliggende platform schaalt tot een flink aantal gebruikers (met gemak enkele tienduizenden). In de betreffende operatie worden van alle games van een gebruiker alle resultaten opgehaald, van zowel de speler zelf als zijn/haar tegenstander. Deze operatie vereist een aantal verschillende queries om alle data op te halen, welke vervolgens tot enkele honderden malen dienen te worden uitgevoerd.De extrapolatie van concurrency naar gebruikers is helaas niet zo eenvoudig te doen en vereist wat schattingen. Allereerst stuurt een gebruiker niet de hele tijd verzoeken naar de API. Ten tweede voert een gebruiker verschillende verzoeken uit, op
Testen
35
verschillende momenten; zo zal het zware testverzoek niet continu aangeroepen worden. Ten derde zorgt het opvragen van resultaten van dezelfde gebruiker voor databaselocking op plekken waar dit in een reallife situatie niet voor zou komen. Tenslotte zal de uiteindelijke API ook gebruik maken van caching waar mogelijk, wat is deze test nog niet is gebeurd.
8.6
SIG
Zoals gebruikelijk binnen het bacheloreindproject is de code die is gecreeerd ook tweemaal naar SIG [22] gestuurd. De eerste keer werd de code verstuurd in begin januari, de tweede keer op het moment dat alle code daadwerkelijk af was.
Eerste evaluatie De feedback van SIG op de code was positief (Appendix C). Van de totaal haalbare vijf sterren ontving de code van Do The Math de eerste keer al direct vier sterren. Commentaar was er echter ook, zo was de MVC scheiding binnen de iOS code niet altijd goed doorgevoerd. Tevens speelde het dat er enige mate van “duplicate code” aanwezig was in de iOS app. Tenslotte waren er enkele erg lange methoden aanwezig in de code, welke ook de onderhoudbaarheid niet bevorderen. Door deze feedback is er kritisch gekeken naar de code en zijn er een aantal wijzigingen doorgevoerd. Op het gebied van de “duplicate code” en de lange methoden zijn er wijzigingen doorgevoerd om deze methoden drastisch in te korten en waar mogelijk op te splitsen (deze twee wijzigingen hangen dan ook sterk met elkaar samen). Op het gebied van de MVC scheiding is er echter gekozen deze aanbeveling niet te volgen. De code die is opgestuurd naar SIG bestond uit de losse bronbestanden van de code. Binnen de API worden er door het framework voor ieder onderdeel uit het MVC-model losse mappen gebruikt. De structuur welke Xcode aanhoudt is echter anders. Hier worden de bestanden allemaal primair in ´e´en map gezet, wat op het oog (ook voor SIG) inhoudt dat de scheiding tussen MVC niet is doorgevoerd. Echter gebruikt Xcode vervolgens intern zogenaamde “groups” om de code te orderen. Hier is binnen Do The Math dan ook gebruik van gemaakt. Voor een voorbeeld van deze ordening is te zien in figuur 8.1.
Testen
36
Figuur 8.1: Structuur bestanden
Tweede evaluatie Voor de tweede evaluatie heeft de codebase van Do The Math wederom vier sterren gekregen van SIG. Er is veel van de voorgaande feedback ge¨ımplementeerd. Zo is allereerst de code beter gestructureerd gemaakt. Binnen de codebase worden er nu ook mappen gebruikt om de verschillende onderdelen van de MVC-structuur te scheiden van elkaar. Hierdoor is het eenvoudiger bepaalde functionaliteiten te lokaliseren. Echter binnen de API zou er nog de mogelijkheid zijn om de “libraries” map beter te structureren. Hier is echter vanaf gezien door het toch al kleine aantal bestanden wat hier staat.
Testen
37
Tevens zijn ditmaal alle gemaakte unit tests meegestuurd, welke de belangrijkste onderdelen van de code automatisch controleren. Deze tests worden momenteel ge¨ımplementeerd als controller. Hierdoor kunnen deze tests op dezelfde wijze worden aangeroepen. Indien de configuratie dit toelaat wordt er automatisch een unit test database gecre¨eerd waarop deze tests worden uitgevoerd. Een kritiekpunt op deze werkwijze vanuit SIG is dat de unit test code niet volledig gescheiden is van de productiecode. Dit is echter bewust zo gedaan om het draaien van de tests zo laagdrempelig mogelijk te maken. Door deze lage drempel worden de unit tests juist weer veel gebruikt na een wijziging, waardoor er geen bugs optreden in het gedrag van de API. Tenslotte is er verwezen naar de “Duplication” en “Method Size”. Deze scoorden in de eerste evaluatie al vier sterren, waardoor hier relatief weinig aandacht naar is uitgegaan (ook mede door tijdsdruk). Op plekken waar er aan de code is gewerkt en hieraan iets verbeterd kon worden is dit dan ook gedaan. Er is enkel niet verder gezocht naar andere stukken code waar deze verbeteringen op van toepassing konden zijn. In alle stukken code die zijn geschreven na de eerste evaluatie is met deze twee factoren meer rekening gehouden.
9. Toekomst Zowel binnen Innovattic als de projectgroep zelf heerst de opvatting dat er grote mogelijkheden zijn met Do The Math. Deze is vooral ingegeven door twee waarnemingen tijdens het proces. Allereerst bestaat er simpelweg nog geen ander spel voor een mobiel platform dat doet denken aan Do The Math. Ten tweede kan men uit de gebruikerstest (hoewel geen volledig betrouwbare streekproef) concluderen dat het concept ook daadwerkelijk werkt en als erg positief beoordeeld werd.
9.1
Zelfstandig op de markt brengen
Door de opzet van de verschillende App Stores van mobiele platformen is het op de markt brengen eenvoudig. De bedrijven achter de verschillende platformen bieden hiervoor ruimte aan binnen deze App Stores, waarmee de software snel aan eindgebruikers kan worden aangeboden. De App Stores verzorgen vervolgens de hosting van de bundel, bieden mogelijkheden tot opzoeken en updaten en handelen de betalingen van gebruikers af. De daadwerkelijke ontwikkelaar van de app geeft deze diensten uit handen aan Apple, Google of Microsoft (Apple en Microsoft staan zelfs enkel appdistributie toe via hun app stores). In ruil hiervoor nemen deze bedrijven een percentage van de gedraaide omzet van deze apps. Dit percentage gaat enkel over aankopen via deze App Stores, reclame valt hierbuiten. Voor Do The Math wordt er een marktintroductie nagestreefd. Het product is immers al ontwikkeld en klaar voor een release. Kosten voor hosting van de API zijn laag te noemen, waardoor een eventueel financieel risico laag uitvalt. Inkomsten kunnen vervolgens worden gegenereerd door het plaatsen van advertenties in de menu’s van de app (via Googles AdMob)[23] en een premiumversie, waar gebruikers geen reclame meer te zien krijgen. Voor de premiumversie kan in de toekomst vervolgens ook extra premiumfunctionaliteit worden uitgebracht, zoals bepaalde features welke in de gratis versie (met reclames) niet aanwezig is. Na het op de markt brengen van de app is het vervolgens een kwestie van het in de gaten houden van de verkoop en de belasting van de API. Indien nodig dient de API servercapaciteit bijgeschaald te worden. Het monitoren van het aantal downloads en gebruikers is vervolgens belangrijk om objectief in te kunnen schatten in hoeverre er sprake is van een succes. Indien er wordt voldaan aan vooraf gestelde doelen wordt er vervolgens verder ontwikkeld aan het product; hierbij kan men 38
toekomst
39
denken aan extra features of het ontwikkelen voor andere platformen zoals Android. Indien deze doelen echter niet gehaald worden wordt het platform enige tijd in de lucht gehouden voordat het wordt uitgefaseerd.
10. Conclusie De doelstelling waarmee dit bacheloreindproject is aangevangen is: “Het ontwikkelen van een app voor de Apple iPhone welke draait om een turn-based multiplayer spelconcept gebaseerd op getallen met de potentie succesvol te worden.” Deze doelstelling is getracht te bereiken door eerst goed te kijken naar bestaande succesvolle concepten. Na deze concepten te hebben bestudeerd, is er gekeken naar elementen die nog uitgevoerd zijn in de vorm van een app. Al snel werd er geconcludeerd dat er nog geen concept bestond dat als basis van het spel “hoofdrekenen” had. In de app zijn vervolgens vier speltypen gerealiseerd. Deze speltypen zijn alle gericht op een ander soort denkwijze binnen het hoofdrekenen. Hiermee worden spelers continu op een andere wijze uitgedaagd door het spel. Om voor een extra uitdaging te zorgen zijn er ook verschillende niveaus in het spel beschikbaar. Hierdoor wordt iedere speler uitgedaagd op een passend niveau. Tenslotte kan een bestaande speler een spel spelen tegen een vriend die het spel ook speelt. Dit maakt het extra uitdagend vanwege het verhoogde competitie-element. Op basis van de gebruikerstest kan er geconcludeerd worden dat de speelbaarheid hoog is. Tevens blijkt het dat de gebruikers het spel blijven spelen (hoge replayvalue). Naast de gameplay is tevens belangrijk dat een succesvolle app te allen tijde beschikbaar en bruikbaar is. Om dit onderdeel van de doelstelling te bereiken is er rekening gehouden met verschillende aspecten. Zo moest de app te allen tijde kunnen communiceren met de API. Ook dient de API correct data te verwerken. Om aan deze subdoelstellingen te voldoen is de API schaalbaar opgezet en draait deze op een schaalbaar platform. Om te kunnen garanderen dat de API correct data verwerkt, zijn er unit tests geschreven. Deze testen de verschillende functionaliteiten van de API. Overkoepelend kan er geconcludeerd worden dat er aan de doelstelling is voldaan. Uit de gebruikerstest is namelijk gebleken dat men de app leuk vond waaruit blijkt dat de app een zekere potentie heeft om succesvol te worden. Of de app daadwerkelijk succesvol wordt kan pas bepaald worden, nadat de app beschikbaar is gesteld in de App Store.
40
11. Evaluatie Dit bacheloreindproject gaf ons een mogelijkheid om een project uit te voeren in een richting die we al langer wilden doen: app-ontwikkeling. Innovattic bood hiertoe de mogelijkheid. Zij gaven ons de vrijheid een idee uit te werken, mits de resultaten hiervan ook voor henzelf nuttig zou kunnen zijn. De samenwerking met Innovattic is prettig verlopen. Het afgelopen half jaar hebben wij in hun kantoor kunnen werken, drie dagen per week. Eens per week werd een korte meeting belegd tussen ir. Metz en ons, waarin de vooruitgang van afgelopen week werd besproken en de prioriteiten voor komende week werden gesteld. Door het werk bij Innovattic op kantoor uit te voeren was het niet nodig om de koers van het project plots te wijzigen of iets vergelijkbaars, omdat er heel vaak de mogelijkheid tot overleg en feedback bestond. Ook de interne samenwerking verliep prima. Allereerst hebben we aan het begin van het project afgesproken om samen, waar mogelijk, op dezelfde dagen te werken aan het project. Hierdoor waren we te allen tijde goed op de hoogte van de status van iedere feature. Ook werkten we zelfs samen aan hetzelfde bureau waardoor overleg razendsnel kon verlopen. Ook de grootte van de groep (slechts twee personen) droeg in dit geval bij aan de goede onderlinge communicatie. Binnen de groep is er een lichte onderverdeling tot stand gekomen; Ruud is primair bezig geweest met de app en Rogier met de API. Het is echter niet zo dat ´e´en persoon continu bezig is geweest met een onderdeel, beiden hebben geprogrammeerd aan beide onderdelen. Voorts was een groot gedeelte van de materie (deels) nieuw voor ons. Hierdoor was het belangrijk om van de taal Objective-C de syntax en werkwijze te leren voordat er werd begonnen aan het daadwerkelijke programmeren. Ook hebben we ons verdiept in de verschillende aspecten die een app tot een succes kunnen maken; hierbij kan men denken aan de herspeelbaarheid van het spel, de snelheid en specifieke manier waarop gebruikers apps gebruiken. Bij de start van het project is het initi¨ele schema opgesteld. Echter bleek al snel dat dit schema niet geheel realistisch zou zijn. Hier is dan uiteindelijk ook flink vanaf geweken. Deze afweging ontstond voornamelijk doordat de implementatiefase meer tijd kostte dan verwacht en het ontwerp van bepaalde features ertoe leidde dat eerder gedaan werk deels opnieuw gedaan diende te worden. 41
Evaluatie
42
Als we dit project opnieuw zouden mogen uitvoeren zouden er niet veel onderdelen zijn die we anders zouden hebben uitgevoerd. De enige fundamentele verandering zou zijn geweest om in plaats van de API te programmeren in PHP met CodeIgniter gekozen zou zijn voor een webplatform zoals Ruby On Rails. Al met al zijn we dan ook zeer tevreden met het verloop van het project. Het resultaat is in onze ogen zeker geslaagd en het proces is uiterst leerzaam geweest. We kijken dan ook met een tevreden blik terug naar dit project en willen alle betrokkenen ook nogmaals bedanken voor hun hulp in de totstandkoming en uitvoering van dit project.
A. Interactieontwerpen
Figuur A.1: Login flow
Figuur A.2: Instellingen flow
43
Interactieontwerpen
44
Figuur A.3: Nieuw spel starten
Figuur A.4: Flow van een spel
B. Gebruikerstest B.1
Antwoorden vragenlijst
Figuur B.1: Vragenlijst gebruikerstest antwoorden
B.2
Opmerkingen
Opmerkingen van Rogier: • Er moet duidelijker worden getoond dat je moet wachten op de volgende ronde • Reclame laden (full screen) duurt te lang • De score die wordt opgeteld bij je exp klopt niet met de score die wordt getoond • Vanuit Facebook vrienden direct een game starten • Geluidjes zijn momenteel erg irritant • Na pushnotificatie de resultsviewcontroller direct updaten • Pushnotificaties niet tonen in app • CorrectWrong is te simpel op level 4 • Solve is te simpel op level 4 45
Gebruikerstest
46
• Operators te simpel level 2 • Twentyfour wordt niet direct gewaardeerd door iedereen • Low-res reclames admob storend Opmerkingen van Mark: • Na afsluiten terug in homescreen kan het spel niet doorgaan • Geen melding bij match voor random spel • Notificaties tijdens spel is vervelend • Revanche knop werkt niet (Geblokkeerd) • 1 minute to selfdestruct geluid is verwarrend • Evil: Correct/wrong is makkelijk, maar groot verschil tussen de vragen • Kan geen spelverzoeken weigeren • Spel afbreken kan niet (opgeven) • AI/bot om te oefenen • Score scherm: frame om user image heen • Tekst in navbar en buttons staat te hoog • Operators: slepen operators zou leuk zijn • Spellen verwijderen uit lijst • Resolutie van ads is slecht Opmerkingen van Lars: • Design is tof • Rekenmachine knoppen erg klein • Leuke meting op het laatste scherm • Reset knop tijdens 24 handig • Reclame fullscreen preloaden en tonen als de gebruiker klikt Opmerkingen van Stefan: • Als ik start new game klik verwacht ik dat ik kan beginnen • Het is onlogisch dan ik niks kan doen als iemand anders mij nog niet accepteert • Resultaten, na drie seconden doorgaan • Als er geen resultaten zijn deze ook niet laten zien • Volgende knop bij resultaten midden in beeld Opmerkingen van Brian:
Gebruikerstest
47
• Mooi design • Begin gewenning lastig • Misschien verplichte tutorial eerste keer tonen? • Game komt solide over • Friend en game invites zijn verwarrend. • Meldingen tijdens game zijn vervelend • Moeilijkheidsgraad is soms wat uit balans • Leuke game met veel potentie • Android versie? Opmerkingen van Wouter: • Training mode mist • Right or Wrong op lvl 4 is makkelijk • 24 optioneel maken? • Slepen van operators in ¨operators¨ıpv klikken Opmerkingen van Luuk: • Duidelijkere visualisering wanneer je gewonnen hebt van iemand • Als je op accepteer klikt begint er niet direct een spel maar moet je eerst herladen • Geen vooruitgang in hoofdmenu • Meerdere uitdagingen van een persoon zijn onduidelijk • Gat tussen moeilijkheidsgraad medium en hard • Reclames blijven irritant
B.3
Vragenlijst
Gebruikerstest
48
Figuur B.2: Vragenlijst gebruikerstest
C. SIG resultaten C.1
Eerste resultaten
De code van het systeem scoort vier sterren op ons onderhoudbaarheidsmodel, wat betekent dat de code bovengemiddeld onderhoudbaar is. De hoogste score is niet behaald door lagere scores voor Duplication, Unit Size en Component Balance. Wat betreft de component-indeling valt het op dat de PHP-code in duidelijk herkenbare componenten is opgedeeld (controllers, models, etc.), maar dat de Objective C-code niet verder is opgedeeld. Een duidelijke component-indeling maakt het makkelijker om code te lokaliseren, en is tevens een vorm van documentatie. Overigens zorgde de component “libraries” in het PHP-gedeelte voor enige verwarring. Deze naam wordt vaak gebruikt om third party code te scheiden van de zelf ontwikkelde code. In dit geval hebben deze bestanden dezelfde auteur als de rest van het systeem, dus hebben we aangenomen dat de inhoud van deze directory bij het systeem hoort. Voor Duplication wordt er gekeken naar het percentage van de code welke redundant is, oftewel de code die meerdere keren in het systeem voorkomt en in principe verwijderd zou kunnen worden. Vanuit het oogpunt van onderhoudbaarheid is het wenselijk om een laag percentage redundantie te hebben omdat aanpassingen aan deze stukken code doorgaans op meerdere plaatsen moet gebeuren. In dit systeem is er met name duplicatie te vinden in de controllers van de Objective C code. Een voorbeeld is de class UserSettingsViewController, waarin keyboardWillHide en keyboardWillShow dezelfde code bevatten. Het is aan te raden om dit soort duplicaten op te sporen en te verwijderen. Voor Unit Size wordt er gekeken naar het percentage code dat bovengemiddeld lang is. Het opsplitsen van dit soort methodes in kleinere stukken zorgt ervoor dat elk onderdeel makkelijker te begrijpen, te testen en daardoor eenvoudiger te onderhouden wordt. Een voorbeeld van een methode die nog verder opgesplitst zou kunnen worden is setObjectMapping in het bestand MappingManager.m. Deze methode bestaat eigenlijk uit een aantal deelstappen. Het onderscheid tussen die deelstappen wordt nu met commentaar aangegeven, maar dit zou ook kunnen gebeuren door de deelstappen tot aparte methodes te refactoren. Hetzelfde advies geldt ook voor een aantal methodes in GameResultViewController (viewWillAppear, setScores, viewOldLoad). Het is aan te raden kritisch te kijken naar de langere methodes binnen dit systeem en deze waar mogelijk op te splitsen. 49
SIG resultaten
50
Over het algemeen scoort de code bovengemiddeld, hopelijk lukt het om dit niveau te behouden tijdens de rest van de ontwikkelfase. Als laatste nog de opmerking dat er geen (unit)test-code is gevonden in de code-upload. Het is sterk aan te raden om in ieder geval voor de belangrijkste delen van de functionaliteit automatische tests gedefinieerd te hebben om ervoor te zorgen dat eventuele aanpassingen niet voor ongewenst gedrag zorgen.
C.2
Tweede resultaten
In de tweede upload zien we dat het volume van het systeem met ongeveer 20 procent is toegenomen. De onderhoudbaarheid is met vier sterren ongeveer gelijk gebleven. In vergelijking tot de vorige upload is de code-indeling aanzienlijk verbeterd. Zowel de server als de client zijn nu in duidelijke componenten opgedeeld, waardoor het nu veel makkelijker is om bepaalde functionaliteit te lokaliseren. Het punt betreffende de “libraries” directory blijft wel staan, deze directory bevat nog steeds een combinatie van third party code (Curl.php, aph.php) en “eigen” code (TwentyFourQuestion.php, CorrectWrongQuestion.php). Sinds de vorige upload zijn er een aantal unit tests toegevoegd. Deze tests staan momenteel echter tussen de productiecode, namelijk in “application/controllers/unitTests.php”. Dit maakt de tests moeilijk te lokaliseren, al is er wel een bestand toegevoegd met instructies waar je de tests kunt vinden. Dit is echter geen oplossing voor het probleem, als er meer tests bijkomen wordt de scheiding tussen productiecode en testcode steeds onduidelijker. Ditzelfde punt geldt voor de indeling van de tests. Alle tests staan nu in ´e´en bestand, maar deze aanpak schaalt niet als er steeds meer tests bijkomen. Het is aan te raden om de tests zo in te delen dat de testbestanden mappen op de productiebestanden. Wat betreft de duplicatie zijn de gegeven voorbeelden wel aangepast, maar er is geen verder onderzoek gedaan om duplicaten elders in de code te verwijderen. Ditzelfde geldt voor de lengte van methodes. De scores voor Duplication en Unit Size zijn daarom niet significant gestegen sinds de vorige upload. Uit deze observaties kunnen we concluderen dat een deel van de aanbevelingen van de vorige evaluatie zijn meegenomen in het ontwikkeltraject.
D. REST aanroepen /user/(:num)/device POST Via deze aanroep is het mogelijk om voor een gebruiker te registreren met zijn/haar device. Vervolgens kunnen er naar dit device push notificaties verstuurd worden. De app dient deze aanroep slechts aan te roepen indien een gebruiker toestemming heeft gegeven voor pushnotificaties. Andere gebruikers gekoppeld aan het device worden direct ontkoppeld. /user/(:num)/poke POST Via deze aanroep is het mogelijk om een gebruiker te porren. De server staat dit verzoek slechts eens per tijdseenheid toe, welke kan worden ingesteld via de serverinstellingen. Indien een gebruiker te snel probeert om een andere gebruiker te porren stuurt de server een foutcode terug en wordt de actie niet uitgevoerd. /user/(:num)/avatar/(:num) GET Via deze aanroep haalt de app de PNG op welke geassocieerd is met de gebruiker in combinatie met het volgnummer van de avatar. Deze aanroep stuurt een HTTP header door naar de daadwerkelijke avatarlocatie welke de app dient te respecteren/volgen. /user/(:num) GET Haalt de data op van de gebruiker. Deze informatie is gecensureerd i.v.m. privacy overwegingen. /user/me/avatar POST Vervangt de avatar van de huidige gebruiker. De nieuwe avatar dient te worden gestuurd in het file-veld ¨ avatar png”. /user/(:any)/requestPassword POST Verstuurt een wachtwoordreset E-mail naar de gebruiker met de gebruikersnaam (:any). /user/(:num)/resetPassword/(:any) GET Stelt een nieuw wachtwoord in voor de gebruiker met id (:num) en token (verstuurd via de /requestPassword) methode indien deze correct zijn. /user/me GET Haal data op van de huidige gebruiker. Deze is uitgebreider dan de serverdata van een andere gebruiker.
51
REST aanroepen
52
/user/new POST Maakt een nieuwe gebruiker aan. Afhankelijk van de payload is dit een koppeling met Facebook of een anoniem account. /user PUT Update de data van de huidige gebruiker. /match/(:num) GET Haalt de data op van de match met id (:num) /match/(:num) DELETE Retourneer niet meer de data van de match met id (:num) /match/all GET Haalt de data op van alle matches van de huidige speler. Let op: zwaar request en niet bedoeld voor productie. /match/invite/(:num)/difficulty/(:num) POST Stuur een invite naar gebruiker met id = (:num) voor moeilijkheidsgraad (:num) (de tweede). /match/invite/random/difficulty/(:num) POST Stuur een invite naar een random gebruiker voor moeilijkheidsgraad (:num) /match/invites GET Haal alle invites van de huidige gebruiker op /match/invite GET Alias voor /match/invites /match/invite/accept/(:num) POST Accepteer invite met id (:num) /match/invite/decline/(:num) POST Verwerp invite met id (:num) /match/round PUT Update een match door de resultaten van een nieuwe round toe te voegen. /match/status/all GET Toon een statusoverzicht van alle matches met hun status (Retourneert niet de payloaddata van de match) /match/status/(:num) GET Toon de status van de match met id (:num)
REST aanroepen
53
/friend/inviteEmail POST Alias voor /friend/mail /friend/invite/(:num) POST Nodig gebruiker met id (:num) uit om vrienden te worden met de huidige gebruiker /friend/invites GET Toon alle huidige openstaanden vriendschapsverzoeken /friend/invite/(:num)/decline POST Weiger een vriendschapsverzoek met id (:num) /friend/invite/(:num)/accept POST Accepteer een vriendschapsverzoek met id (:num) /friend/search/(:any) GET Zoek naar een toekomstige vriend met een gebruikersnaam welke lijkt op (:any) /friend/facebook POST Stuur een lijst met vrienden en retourneer welke al Do The Math spelen /friend/mail POST Stuur een e-mail naar de persoon die de gebruiker uitnodigt. Dit e-mailadres zit in de data payload /friend GET Haal alle vrienden van de huidige gebruiker op /settings GET Haal alle settings op welke relevant zijn voor de app /settings/rank GET Haal de ranks op met hun puntenniveaus /notifications/ios/send GET Voer een verstuuractie uit van pushnotificaties (intern, niet voor app) /notifications/ios/feedback GET Voer een feedbackactie uit van pushnotificaties (intern, niet voor app)
Literatuurlijst [1] Whatsapp. URL http://www.whatsapp.com/. [2] Draw-something. URL http://www.draw-something-info.nl/. [3] Instagram. URL http://instagram.com/. [4] ios library. URL https://developer.apple.com/library/ios/navigation/. [5] Php.net. URL http://php.net/. [6] Codeigniter. URL http://ellislab.com/codeigniter. [7] Michael zur Muehlen, Jeffrey V. Nickerson, and Keith D. Swenson. Developing web services choreography standard the case of rest vs. soap. Decision Support Systems, 40(1):9 – 29, 2005. ISSN 0167-9236. doi: 10.1016/j.dss.2004.04.008. URL http:// www.sciencedirect.com/science/article/pii/S0167923604000612. Web services and process managemen. [8] Restkit. URL http://restkit.org/. [9] Elastique. URL http://elastique.nl/. [10] Facebook sdk. URL http://developers.facebook.com/ios/. [11] Flurry. URL http://www.flurry.com/flurry-analytics.html. [12] Amazon s3, . URL http://aws.amazon.com/s3/. [13] Amazon aws cloud, . URL http://aws.amazon.com/ec2/. [14] Microsoft cloud.
URL http://www.microsoft.com/nl-nl/server-cloud/
default.aspx. [15] Rackspace. URL http://www.rackspace.com/cloud/. [16] Google cloud. URL https://cloud.google.com/. [17] Heroku. URL http://www.heroku.com/. 54
Literatuurlijst
55
[18] Appfog. URL https://www.appfog.com/. [19] Timothy C. Lethbridge and Robert Lagani`ere. Object-oriented software engineering. McGraw-Hill, 2nd ed. edition, 2005. [20] Chili project. URL https://www.chiliproject.org/. [21] Hockeyapp. URL http://hockeyapp.net/. [22] Software improvement group. URL http://www.sig.eu/en/. [23] Admob. URL http://www.google.com/ads/admob/.
