Evaluering av tilgjengelige kryssplattformverktøy og serverløsninger

Transkript

1 Evaluering av tilgjengelige kryssplattformverktøy og serverløsninger TDT Datateknologi, fordypningsprosjekt Per Stian Hoff Kent Arne Bjerke Andrzej Thingstad Veiledet av John Krogstie Høst 2014 Institutt for datateknikk og informasjonsvitenskap Norges tekniske-naturvitenskapelige universitet Trondheim, Norway

2 Sammendrag Det finnes mange verktøy tilgjengelig for å utvikle applikasjoner for mobile operativsystemer. På bakgrunn av ios og Android sin markedsdominanse, har utviklere valgt å rette seg mot disse to plattformene og bestemt at ingen av dem kan ekskluderes. For å utvikle native applikasjoner har alternativene vært å utvikle med Objective-C for ios og Java for Android. Problemet med denne tilnærmingen er at utviklere er avhengige av å utvikle to forskjellige versjoner av den samme applikasjonen. Alternativet er å benytte seg av kryssplattformverktøy som kan bidra til å gjenbruke store deler av kodebasen og dermed spare utviklere både tid og kostnader. De fire verktøyene som er blitt evaluert er Sencha Touch, Appcelerator Titanium, Phone- Gap og Xamarin. Verktøyene er valgt ut i forhold til deres popularitet blant andre utviklere. Verktøyene er blitt evaluert med både en kvalitativ og kvantiativ vurdering for å skille deres styrker og svakheter. Den kvantiative evalueringen er blitt gjennomført ved ulike ytelsestester for å vurdere ytelsen til de forskjellige verktøyene, mens den kvalitative vurderingen er forankret i et sett evalueringskriterier. Kvalitativt og kvantiativt er Xamarin det beste alternativet for å utvikle kryssplattformapplikasjoner på Android og ios. Dette på bakgrunn av at verktøyet tillater å utvikle native applikasjoner gjennom C# og kan gjenbruke store deler av kodebasen på tvers av plattformer. I tillegg vil applikasjonene ha native ytelse og brukergrensesnitt. I tillegg er det blitt undersøkt hvilken driftsarkitektur som er den mest hensiktsmessige i forhold til applikasjonen som gruppen skal utvikle som masteroppgave. Alternativene som ble vurdert var Microsoft Azure, Amazon EC2, Google App Engine, GoDaddy Dedikert Server og GoDaddy Privat Virtuell Server. Disse alternativene ble vurdert i forhold til en kvalitativ evaluering på bakgrunn av kriterier satt av gruppen. Videre ble en kvantiativ evaluering gjennomført somm satte fokus på både ytelsen og kostnaden til de forskjellige alternativene. Utifra denne evalueringen ble det konstatert at Google App Engine var det alternativet som medførte de laveste kostnadene, samtidig som den leverte den beste ytelsen i forhold til de andre alternativene. 2

3 Contents 1 Innledning Bakgrunn og problem Leserguide Bakgrunn Applikasjonsutvikling Webapplikasjoner Hybride applikasjoner Native applikasjoner Plattformstatistikk Forskningsmetode 13 4 Valg av Kryssplattformteknologi Kryssplattform Xamarin Hybride rammeverk PhoneGap Appcelerator/Titanium Sencha Touch Evaluering av kryssplattformteknologi Kriterier Kvalitativ Evaluering Xamarin PhoneGap Appcelerator/Titanium Sencha Touch Diskusjon kvalitativ analyse Resultater av kvalitativ evaluering Kvantitativ evaluering Xamarin PhoneGap Appcelerator/Titanium Sencha Touch Resultat av kvantitativ evaluering Test 1: Henting og manipulering av store datamengder Test 2: Oppstartstid med store grafiske elementer Diskusjon av kvantitativ evaluering

4 6 Testapplikasjon Testapplikasjonen Skalering Web-forespørsler for kommunikasjon med serveren Intern lagring på enheten Ytelse Diskusjon Utviklingsprosess Kildekontroll Github Team Foundation Server(TFS) IDE Xamarin Studio Visual Studio Utviklingsprosess Scrum Valg av driftsarkitektur Nettsky Microsoft Azure Google App Engine Amazon Elastic Compute Cloud (EC2) Virtuelle private servere GoDaddy Dedikert server GoDaddy Evaluering av driftsarkitektur Kriterier Kvalitativ evaluering Microsoft Azure Google App Engine Amazon Elastic Compute Cloud (EC2) GoDaddy Dedikert Server GoDaddy Virtuelle Private Server Kvantiativ evaluering Diskusjon av kvalitativ evaluering Diskusjon av kvantiativ evaluering Resultat av kvalitativ og kvantiativ evaluering

5 10 Kjøretidsarkitektur Xamarin: Kompilering Android ios Webtjeneste Konklusjon 62 Kilder 66 5

6 List of Figures 1 Ulike mobile applikasjoner XAML for grafisk brukergrensesnitt Kode for å vise brukergrensesnitt Kode for å hente og manipulere data Kontrolleren til applikasjonen HTML fil for å skrive ut json objektet Kode for test Kode for test Henting og manipulering av store datamengder Gjennomføring av test Oppstartstid med store grafiske elementer Gjennomføring av test to Kodesnutt fra ResolutionRenderer.cs Oppløsning Kode for henting av data fra server Løsning på ios 8 problem Testresultater for Microsoft Azure sine instanser Testresultater for Amazon sine instanser Testresultater for Google App Engine sine instanser Testresultater i sekunder Testresultater i cent C# kildekoden blir en native applikasjon på ulike måter Forespørsel og svar mellom en klient og en webtjeneste

7 List of Tables 1 Smarttelefon forsendelser i Markedsandel til de ulike operativsystemene i Oversikt over tilgjengelige sensorer Resultater av kvalitativ evaluering Pakkeløsninger på Github Pakkeløsninger for Microsoft Azure Pakkeløsninger for EC Pakkeløsninger for GoDaddy Dedikert Server Pakkeløsninger for GoDaddy Private Virtuelle Servere Beskrivelse av tester i DaCapo Priser og konfigurasjoner for Azure [26], App Engine [16] og EC2 [1] 53 7

8 Ordliste API = Application Programming Interface CSS = Cascading Style Sheets DOM = Document Object Model HTML = Hypertext Markup Language HTTP = Hypertext Transfer Protocol JSON = JavaScript Object Notation OS = Operating System SDK = Software Development Kit NDK = Native Development Kit UI = User Interface APK = Android Application Package IDE = Integrated Development Environment IP = Internet Protocol 8

9 1 Innledning Kryssplattformutvikling på mobile enheter har blitt populært gjennom de siste årene, noe som er tydelig fra antallet kryssplattformverktøy som eksisterer. Kryssplattformutvikling har flere fordeler som blant annet lavere kostnader knyttet til utvikling, da det kan utvikles en felles kodebase for de ulike plattformene applikasjonen skal kjøre på. Dette medfører at tiden det tar for en utvikler å få en applikasjon ut på markedet vil minske, da det ikke vil være nødvendig å utvikle to ulike versjoner av den samme applikasjonen for å treffe ulike mobile plattformer. Dette fordypningsprosjektet er forberedelse til en masteroppgave som skal utføres våren 2015 og som skal resultere i en applikasjon som skal kjøre på ios og Android. På bakgrunn av denne masteroppgaven skal det evalueres hvilke kryssplattformverktøy som skal brukes til utvikling av denne applikasjonen, sammen med blant annet hvilken driftsarkitektur og utviklingsmetodikk som skal benyttes. 1.1 Bakgrunn og problem Gruppen skal utvikle en applikasjon som skal bli distribuert på Google Play og App Store, som et ledd i masteroppgaven som skal fullføres våren Applikasjonen er omfattende og i forbindelse med det ønsker gruppen å benytte seg av et kryssplattformverktøy for å redusere utviklingstiden. Det er ikke et alternativ å utvikle i Objective-C og Java for henholdsvis ios og Android. Dette på grunn av manglende erfaring med programmering på Androidplattformen, sammen med den høye læringskurven til Objective-C. Det viktigste kriteriet gruppen har til verktøyet som skal brukes er ytelsen. Videre er det viktig at verktøyet har en lav læringskurve, sammen med muligheter for å utvikle brukergrensesnitt og funksjonalitet som er plattformspesifikke. Ytelsen på de ulike verktøyene skal testes og kvantifiseres, sammen med en kvalitativ vurdering basert på kriterier som gruppen setter. Dette skal bidra til å velge riktig verktøy for masteroppgaven og applikasjonen som skal utvikles. 1.2 Leserguide Kapittel 2: Bakgrunn inneholder teoretisk bakgrunn for nøkkelbegreper brukt senere i rapporten Kapittel 3: Forskningsmetode presenterer forskningsmetoden som brukes. Kapittel 4: Valg av kryssplatformteknologi forklarer hvilke teknologier som skal bli undersøkt i rapporten, og gir en kort introduksjon til hver av de. 9

10 Kapittel 5: Evaluering av kryssplatformteknologi presenterer en kvalitativ vurdering av kryssplattformsverktøyene basert på visse kriterier, og en kvantiativ evaluering som inkluderer ytelsestester. Kapittel 6: Testapplikasjon viser relevante problemer og løsninger som har kommet frem under utvikling av testapplikasjon med valgt teknologi. Kapittel 7: Utviklingsprosess skal brukes under utvikling. inneholder beskrivelse av prosess og verktøy som Kapittel 8: Valg av driftsarkitektur hvordan de fungerer. introduserer ulike serverløsninger og forklarer Kapittel 9: Evaluering av driftsarkitektur evaluerer de forskjellige serverløsningene med en kvalitativ og kvantiativ vurdering. Kapittel 10: Kjøretidsarkitektur beskriver hvordan applikasjonen blir kompilert og kjørt på de ulike plattformene. Kapittel 11: Konklusjon konkluderer forskingen som er blitt gjort og foreslår videre arbeid. 2 Bakgrunn Det finnes mange verktøy tilgjengelig for utviklere som ønsker å utvikle kryssplattform applikasjoner på mobile enheter. Det disse verktøyene har til felles er at de ønsker å kutte ned på både kostnaden og tiden det tar å utvikle en applikasjon, ved å ha kun en delt kodebase over flere plattformer. Der stopper derimot likhetene, siden de har alle ulike tilnærminger til dette problemet og støtter seg på ulike teknologier. 2.1 Applikasjonsutvikling Mobile applikasjoner kan utvikles som en webapplikasjon, hybrid applikasjon eller native applikasjon. Native applikasjoner på Android blir skrevet i Java, mens ios applikasjoner blir skrevet i Objective-C. Native utvikling er kostbart, men tillater for raskere applikasjoner. For å utvikle native applikasjoner kan også verktøy som Xamarin benyttes. Xamarin lager applikasjoner i C# som blir kompilert native til både Android og ios. Utvikling av applikasjoner med webteknologier som HTML5, CSS og JavaScript reduserer ytelsen, men har til gjengjeld andre fordeler som lav kost, lav læringskurve og lav vedlikeholdskostnad. 10

11 (a) Webapplikasjon. (b) Hybride applikasjoner. (c) Native applikasjoner. Figur 1: Ulike mobile applikasjoner I dette kapittelet blir det sett på de forskjellige måtene å utvikle mobile applikasjoner på Webapplikasjoner Nettsider som er tilpasset mobilskjermer kalles webapplikasjoner. Disse applikasjonene er avhengig av å kjøres i en nettleser. For å utvikle slike responsive nettsider kan rammeverk som jquery Mobile eller Bootstrap benyttes. Fordeler: Webapplikasjoner er tilgjengelig for alle enheter som har en nettleser installert. Dette gjør at tilgjengeligheten til applikasjonen er høy og det er ikke behov for å laste ned applikasjonen fra for eksempel App Store eller Google Play. Ulemper: Webapplikasjoner har ikke mulighet til å benytte seg av native funksjonalitet og krever internett for å fungere Hybride applikasjoner Hybride applikasjoner er nettsider som blir pakket i en native beholder. Denne beholderen gir applikasjonen tilgang til native funksjonalitet via plugins. For å utvikle hybride applikasjoner kan teknologi som PhoneGap benyttes. 11

12 Fordeler: Hybride applikasjoner utvikles ved hjelp av webteknologi og kompileres til de forskjellige plattformene. Dette gjør vedlikehold og videreutvikling av applikasjonen enkelt, da det kun er en kodebase som må oppdateres. Hybride applikasjoner gir også mulighet til å benytte seg av native funksjonalitet. Ulemper: Applikasjoner med mange grafiske elementer kan føre til dårlig ytelse Native applikasjoner Programmeringsspråk og utviklingsmiljø er bestemt av hvilken plattform applikasjonen blir utviklet til. Native applikasjoner har full tilgang til maskinvaren og brukergrensesnittet er gjengitt av plattformens SDK. Fordeler: Native applikasjoner utnytter telefonens kapasitet og kan kjøres uavhengig av nettverkstilgang. Ulemper: Ved vedlikehold og videreutvikling av applikasjonen må koden bli oppdatert for alle plattformene. Native applikasjonsutvikling er kostbart og tidskrevende. 2.2 Plattformstatistikk Bakgrunnen for å utvikle applikasjonen på forholdsvis ios og Android er på grunn av den sterke markedsdominansen disse to plattformene er i besittelse av [4]. Tabell 1: Smarttelefon forsendelser i Global Smartphone Operating System Q3 13 Q3 14 Shipments (Millions of Units) Android ios Microsoft BlackBerry Others Total Tabell 2 viser at det er Android som er markedsleder med en økning i markedsandel fra 81.4% i 2013 til 83.6% i Denne økningen kom på bekostning av alle de andre plattformene. ios mistet en prosent av markedsandelen til Android, men dette er hovedsaklig knyttet til fraværet av Apple og ios i det billigere smarttelefonsegmentet hvor Android dominerer[4]. Windows Phone opplevde en 12

13 nedgang fra 4.1% til 3.3%, selv med en moderat økning i forsendelser fra 10.3 til 10.5 millioner enhter som vist i Tabell 1. På dette tidspunktet anser ikke gruppen det som nødvendig å støtte noen andre plattformer enn ios og Android. Dette på bakgrunn av den lave markedsandelen til de konkurrerende plattformene, sammen med den lave etterspørselen. Tabell 2: Markedsandel til de ulike operativsystemene i Global Smartphone Operating System Q3 13 Q3 14 Marketshare (%) Android ios Microsoft BlackBerry Others Total Forskningsmetode For å avgjøre hvilke kryssplattformverktøy som egner seg best for masteroppgaven, ble det gjennomført en kvalitativ og kvantitativ studie. Den kvalitative studien tok for seg et sett med kriterier som de mest aktuelle verktøyene skulle sammenlignes mot, mens den kvantitative studien bestod primært av et testoppsett som skulle sammenligne ytelsen på ulike testapplikasjoner som ble utviklet med disse verktøyene. Den kvalitative studien baserer seg på et sett med kriterier som de ulike verktøyene skal evalueres opp mot. Disse kriteriene er valgt ut på bakgrunn av applikasjonen som skal utvikles som masteroppgave og skal bidra til å evaluere de mest kritiske delene av verktøyene. Videre vil de viktige egenskapene hos de ulike verktøyene bli forklart og sammenlignet. Et viktig punkt for applikasjonen som skal utvikles er ytelse. I den kvantiative studien vil ytelsen til de forskjellige verktøyene bli målt ved å utvikle forskjellige testapplikasjoner som skal gjennomgå noen utvalgte tester. Disse testene skal ikke være omfattende for å redusere feilmarginen og utføres på en mobil enhet for å gjøre resultatene sammenlignbare og nøyaktige. På bakgrunn av disse testene skal det være mulig å konkludere med hvilke kryssplattformverktøy som har den beste ytelsen. Til slutt vil det bli utviklet en testapplikasjon med det valgte kryssplattformverktøyet som skal vise hvorvidt det valgte verktøyet er egnet for gruppens bruk. Sammenlignet med de kvantitative testene som ikke har noen funksjon, vil denne testapplikasjonen utføre et sett med funksjoner som er viktige for applikasjonen som skal utvikles til masteroppgaven. Denne testapplikasjonen vil vise verktøyet sin egnethet til utvikling. 13

14 For å avgjøre hvilken driftsarkitektur som skal brukes er det blitt gjennomført en kvalitativ og kvantitativ vurdering på lik linje som med kryssplattformverktøyene. Den kvalitative studien baserte seg på et sett kriterier som vurderte de ulike driftsarkitekturene opp mot hverandre, mens den kvantitative studien vurderte både ytelsen og kostnadene knyttet til bruk av den valgte driftsarkitekturen. Ved gjennomføringen av denne studien vil det være mulig å komme fram til en omfattende forståelse av de ulike kryssplattformverktøyene, sammen med de ulike driftsarkitekturene. 4 Valg av Kryssplattformteknologi Litteraturstudiet til masteroppgaven "Cross-platform development - evaluation" of available solutions[24] konkluderte med at de topp seks hybride rammeverkene er PhoneGap, Titanium, Rhodos, DragonRad, MoSync og Sencha Touch basert på deres tilstedeværelse på nettet og i artikler. Gruppen har valgt å fokusere på de tre mest populære av disse [44]; PhoneGap, Titanium og Sencha. Det disse verktøyene har til felles er at de alle benytter seg av webteknologi for å utvikle hybride applikasjoner. Xamarin vil også blir vurdert som et motstykke til de hybride teknologiene, hvor man utvikler native applikasjoner i C# og fremdeles får delt mye av kodebasen. 4.1 Kryssplattform Da mobile applikasjoner først kom, innebar utvikling av ios applikasjoner programmering i Objective-C gjennom Xcode, mens Android applikasjoner måtte utvikles i Java. Hele prosessen måtte gjentas med helt ny kodebase dersom applikasjonen skulle lages for flere plattformer. Med kryssplattformutvikling er det mulig å utvikle en applikasjon som kan kjøres på flere plattformer. Det er både fordeler og ulemper med å utvikle en kryssplattform applikasjon [23]. Blant fordelene er lavere utviklingskostnader da det ikke er nødvendig å utvikle flere forskjellige applikasjoner spesifikt for flere plattformer. Dette bidrar også til at utviklingstiden blir redusert. Videre har mange av verktøyene for å utvikle kryssplattform applikasjonene en lav læringskurve da de baserer seg på allerede kjente webteknologier som CSS, HTML og JavaScript. Ulemper med kryssplattformutvikling er blant annet om et mobilt operativsystem blir oppdatert med funksjonalitet som er plattformavhengig, må applikasjonen bli utviklet med separat kode for den gitte funksjonaliteten. Videre kan det være vanskelig å tilby en native brukeropplevelse på kryssplattformapplikasjoner med mindre verktøyet du utvikler applikasjonen med støtter dette eksplisitt. 14

15 4.1.1 Xamarin Xamarin gjør det mulig å utvikle native mobile applikasjoner i C#, et kraftfullt og moderne programmeringsspråk. Med en delt kodebase for alle plattformer, som inneholder blant annet forretningslogikk og dataaksess, gjør at man kun trenger å skrive egen kode for brukergrensesnittene. Dette sørger for at man får et høyt gjenbruk av kode, men samtidig slipper å gjøre kompromisser når det kommer til brukergrensesnittet. Xamarin gjør også, som eneste kryssplatformteknologi, det mulig å arbeide i Visual Studio, et populært verktøy for utviklere. Støttede plattformer: Android, ios, BlackBerry, Windows Phone, Mac. 4.2 Hybride rammeverk Hybride rammeverk gir utvikleren mulighet til å lage applikasjoner med HTML, CSS og JavaScript PhoneGap I 2008 ble det utviklet en metode som gjorde det mulig å utvikle applikasjoner ved bruk av HTML, CSS og Javascript. Denne metoden utnyttet at alle mobiltelefoner tillater en instans av en nettleser. Nettleser kan kommunisere med brukergrensesnittet ved hjelp av native kode. JavaScript i applikasjonen, plug-ins, kan kalle native kode som gir applikasjonen tilgang til telefonspesifikke funksjoner. Eksempler på slike funksjoner kan være kamera, gyroskop m.m. Denne metoden ble kjent som PhoneGap [10]. I 2011 ble PhoneGap kjøpt opp av Adobe Systems [45]. På bakgrunn av at man enkelt kan lage applikasjoner ved bruk av webteknologi. Støttede plattformer: Android, ios, BlackBerry, Windows Phone, Windows 8, Ubuntu og Firefox OS Appcelerator/Titanium Appcelerator Titanium er en open source løsning for utvikling av applikasjoner med webteknologi. Titanium gjør det mulig å utvikle applikasjonene ved hjelp av HTML, CSS og JavaScript. De har også utviklet et rammeverk, Alloy, som skal gjøre det lettere å lage applikasjoner. Alloy er et rammeverk laget av Appcelerator som er spesialdesignet for Titanium SDK. Den baserer seg på arkitektureren modelview-controller(mvc). Støttede platformer: ios, Android, Windows Phone og BlackBerry [46]. 15

16 4.2.3 Sencha Touch Sencha Touch er et HTML5 basert rammeverk for å utvikle webapplikasjoner som ser ut som om de er blitt utviklet native ved å tilby flere grafiske elementer tilsvarende de du finner på blant annet Android og ios. Applikasjoner utviklet med Sencha kan blir brukt sammen med Cordova eller PhoneGap, og dermed pakke applikasjonen inn i en native container som gir den tilgang til API er som er tilgjengelig for enheten den er installert på. Støttede plattformer Android, ios, Windows Phone, BlackBerry, Tizen [41]. 5 Evaluering av kryssplattformteknologi I dette kapittelet blir de forskjellige teknologiene evaluert opp mot hverandre basert på et sett med utvalgte kriterier. Disse kriteriene er satt opp med tanke på applikasjonen som skal utvikles ved et senere tidspunkt. 5.1 Kriterier Støttede plattformer. Rammeverkene/teknologiene må støtte så mange mobile plattformer som mulig. Det er satt krav til at teknologien må støtte Android og ios. Teknologien må støtte native funksjonalitet for hver plat- Native funksjonalitet. tform. Pris. På bakgrunn av et begrenset budsjett er pris en viktig faktor i valg av kryssplattformteknologi. Dokumentasjon og support. Rammeverkene/teknologiene burde være godt dokumentert og det skal være enkelt å finne informasjon på internett når en har spørsmål eller problemer som en trenger å belyse. Levbarhet. Levbarheten til teknologien er viktig. Det må hele tiden videreutvikles og gi støtte for ny funksjonalitet som kommer i nye mobile enheter. Det er også viktig at feil og mangler blir oppdatert om nødvendig. 5.2 Kvalitativ Evaluering Den kvalitative evalueringen sammenligner de ikke-kvantifiserbare egenskaper til teknologiene. Målet er å finne den teknologien som er den beste å bruke for utvikling av masteroppgaven. 16

17 5.2.1 Xamarin Xamarin er en plattform som tillater brukere å skrive applikasjonene sine i C# og dele kodebasen over flere plattformer som blant annet ios, Android, Windows Phone og Mac. Dette sørger for at en kan bruke det samme språket, de samme API ene og den samme strukturen for hver plattform som applikasjonen blir utviklet for. Alt som kan gjøres med Objective-C, Swift eller Java, kan også gjøres med C# i Xamarin. Xamarin tilbyr native brukergrensesnitt som sørger for at applikasjoner blir utviklet med native brukergrensesnitt elementer for den plattformen det utvikles for. Det tilbys også aksess til native API er og native ytelse som bidrar til at applikasjoner ikke bare ser native ut, men også oppleves som det. Xamarin er blitt et populært verktøy som mange benytter seg av når det kommer til utvikling av applikasjoner som skal fungere på flere forskjellige plattformer. Mye av grunnen til dette er blant annet at det er mulig å gjenbruke store deler av kodebasen på tvers av flere plattformer og det er mulig å skrive applikasjoner i C# som er et språk med høy popularitet verden over og med et stort økosystem rundt seg i form av.net rammeverket til Microsoft. Xamarin tilbyr også en omfattende nettportal hvor utviklere kan finne guider, videoer og eksempelapplikasjoner som viser hvordan man kommer i gang med utvikling, men også hvordan ulik funksjonalitet skal implementeres i Xamarin. Videre har Xamarin en Component-Store hvor det er mulig å finne en haug med ulike komponenter som kan implementeres inn i ulike Xamarin-applikasjoner. Hvem som helst kan utvikle disse komponentene og selv om noen av dem koster et par kroner er mesteparten av de gratis. Personer kan også skrive ønsker til hvilke komponenter de mener mangler på plattformen, slik at andre utviklere kan utvikle disse komponentene. Xamarin tilbyr også same-day support for systemoppdateringer på blant annet Android og ios. Informasjon vedrørende de ulike API ene er svært godt dokumentert på Xamarin sine hjemmesider og det finnes også et forum som brukere aktivt bruker for å få svar på spørsmål som de ikke finner andre steder. Her forteller også brukere Xamarin om ulike bugs de finner og Xamarin sine utviklere er ofte raske til å fikse disse feilene og svare på spørsmål som dukker opp. Et søk etter Xamarin på StackOverflow som er en Q&A side for programvareutviklere gir over resultater, noe som tyder på at utviklere benytter seg av produktet og at det er et bredt community der ute for å hjelpe utviklere som har spørsmål rundt Xamarin. Ved å logge inn på sin Xamarin konto kan man også henvende seg til deres support avdeling som lover svar innen kort tid [52]. Til forskjell fra PhoneGap er Xamarin kun gratis for studenter. De tilbyr riktig nok en Starter Edition som er gratis, men denne versjonen har en øvre grense for hvor stor applikasjonen som blir utviklet kan være samtidig som den er strippet for mange funksjoner som Xamarin tilbyr. Videre har de ulike versjoner som 17

18 støtter flere og flere funksjoner, men disse kommer selvfølgelig med en pris. Indieversjonen starter på 25$ i måneden, etterfulgt av Business på 83$ i måneden og til slutt en Enterprise-editon på 158$ i måneden [50] PhoneGap PhoneGap er en open source løsning for å lage hybrid kryssplattform applikasjoner [36]. Applikasjonene blir utviklet ved hjelp av standard webteknologi som inkluderer HTML, JavaScript og CSS. PhoneGap støtter de fleste sensorer som finnes i moderne mobiltelefoner ved hjelp av plugins(se Tabell 3) Tabell 3: Oversikt over tilgjengelige sensorer. iphone / iphone 3G iphone 3GS og nyere Android Windows Phone 8 Akselerometer Ja Ja Ja Ja Kamera Ja Ja Ja Ja Kompass Nei Ja Ja Ja Kontakter Ja Ja Ja Ja Filer Ja Ja Ja Ja Geolokasjon Ja Ja Ja Ja Media Ja Ja Ja Ja Nettverk Ja Ja Ja Ja Notifikasjon(lyd) Ja Ja Ja Ja Notifikasjon(vibrasjon) Ja Ja Ja Ja Lagring Ja Ja Ja Ja For å kunne støtte ny funksjonalitet er det viktig at videreutviklingen av Phone- Gap er kontinuerlig. I 2014, frem til 21 oktober, har det blitt utviklet og/eller oppdatert 18 plugins som er utviklet av PhoneGap. Det er også utviklet 220 plugins av 3. parts utviklere [37]. Dette er en indikator på at plugins blir kontinuerlig utviklet for å støtte ny funksjonalitet. PhoneGap støtter mange forskjellige plattformer. På bakgrunn av at PhoneGap applikasjoner kjører i et WebView(nettleser) er det enkelt å legge inn støtte for nye plattformer. Det som er mest tidkrevende ved å legge til støtte for nye plattformer er plugins. Disse må lages spesifikt for plattformen slik at native funksjonalitet kan benyttes. Plattformer PhoneGap støtter: Android ios BlackBerry Windows Phone Windows 8 18

19 Ubuntu Firefox OS Amazon-fireos Dokumentasjonen til PhoneGap er strukturert på en bra måte. Det finnes flere tutorials både på PhoneGap sine sider og på youtube. Ved behov for ytterligere informasjon er det enkelt å finne relevant informasjon på internett. Et søk etter PhoneGap på stackoverflow [34], 10 oktober 2014, ga resultater. Dette tyder på at teknologien er godt brukt og det er enkelt å finne løsninger på eventuelle problemer. Phonegap er gratis, uten noen restriksjoner. Dette har bidratt til høy popularitet og mange utviklede applikasjoner. På bakgrunn av dette er det ingen grunn til at videreutviklingen og oppdateringer av PhoneGap skal bli dårligere i overskuelig fremtid. PhoneGap tilbyr ikke support, men det finnes bibliotek som kan benyttes med PhoneGap som tilbyr support. Eksempler på slike bibliotek er jquery [22] Appcelerator/Titanium Titanium er et rammeverk for å bygge native apps, og har noen likheter med f. eks PhoneGap. Begge er teknologier som gjør det mulig med kryssplattform mobilutvikling, og krever bruk av JavaScript. Både Titanium og PhoneGap er open source programvare, men her ender likhetene. Mens PhoneGap brukes til å utvikle hybrid apps, som kjøres i nettleser, er ikke Titanium et forsøk på å "write once, run everywhere". Titanium handler om kodegjenbruk, de har tro på at det er store funksjoner på tvers av flere plattformer som utviklere bør bruke for å øke brukeropplevelsen. Og derfor burde native apps dra nytte av kjente native UI widgets som har høy ytelse, noe som gir utslag ved at applikasjonene flyter godt [10]. Dette betyr at det ikke vil være 100% kodegjenbruk, men heller oppimot 70-80%. Titanium vil altså ta bruk av fordelene med native apps. Plattform-spesifikk kode vil dermed eksistere for å gi best mulig brukeropplevelse, men samtidig slipper utviklere å lære plattformspesifikke API er for å f. eks tegne et rektangel, eller gjøre en HTTP-forespørsel. Man utvikler altså native apps med JavaScript. Titanium kan derfor sammenlignes med Xamarin. Begge gjør det mulig å utvikle native apps med høy kodegjenbruk, men i forskjellige språk, henholdsvis C# og JavaScript. Dokumentasjonen til Titanium er noe rotete og vanskelig å sette seg inn i. Etter mye søking og feiling var eneste mulighet å laste ned en kitchen sink app for å finne ut hvilke native funksjoner som var støttet. En "kitchen sink app" er en demoapplikasjon laget av Appcelerator for å vise de forskjellige funksjonene som er tilgjengelig ved bruk av Titanium. Et søk etter Appcelerator Titanium på stackoverflow [33], 11 obtober 2014, ga kun resultater. Dette tyder på 19

20 at teknologien ikke er like mye brukt som for eksempel PhonGap og Xamarin. Det er også vanskeligere å finne informasjon om eventuelle problemer grunnet lite informasjon på internett. Titanium er gratis og inkluderer SDK en samt Titanium Studio, men man må betale for support og APi kall til cloud tjenester. Prisene her kommet helt an på hvor ofte og tidskrevende support som trengs, samt hvilke APi kall man skal gjøre mot cloud tjenestene Sencha Touch Sencha Touch er et HTML5 basert rammeverk som inneholder et JavaScript bibliotek spesielt utviklet for mobile webapplikasjoner. På denne måten er det mulig å utvikle applikasjoner med brukergrensesnitt som ser og tildels føles native. Sensa er basert på veletablerte webstandarder som HTML5, CSS og JavaScript. Rammeverket kommer med et stort antall predefinerte layouter som hjelper til med å plassere UI-elementer på skjermen, samtidig som CSS brukes for fleksiblitet og posisjonering for å oppdatere UI raskt. Fordelen med dette er at rammeverket tar seg av designet responsivt. Responsivt design vil si at det du ser vil endre seg etter størrelsen på skjermen du bruker. Dette er spesielt hensiktsmessig når orienteringen på enheten blir forandret til og fra landskapsmodus. Man vil oftest finne en layout som passer med applikasjonen en ønsker å utvikle, dersom det ikke er tilfelle tillater Sencha utviklere å bygge sine egne layouts. Sencha er et tungt objektorientert rammeverk og har et av det mest avanserte klassesystemet av samtlige JavaScript-bibliotekene tilgjengelig. Annet enn å bare være et verktøy, bidrar klassesystemet til pent strukturert applikasjonsutvikling. Mye av funksjonaliteten er basert på abstraksjon som bidrar til at utviklere kan opprette egendefinerte komponenter, plugins eller utvidet funksjonalitet ved hjelp av ulike designmønstre. Plattformer som Sencha Touch støtter er blant annet Android, ios, Windows Phone, BlackBerry og Samsung sitt Tizen. Sencha Touch er gratis og er mulig å laste ned og prøve for hvem som helst. Sencha Touch sin bundle koster derimot 3 900$ for opp til 5 utviklere. Denne bundelen inneholder blant annet Sencha Touch, Arhitect, Charts, Elipse Plugin og mer [42]. Dokumentasjonen som er tilstede på Sencha Touch sine hjemmesider er omfattende og hjelper nye utviklere med å implementere og forstå nye komponenter og konsepter ved Sencha Touch. Videre har de også videoer med tutorials for å vise utviklere hvordan de selv kan implementere ulike funksjonaliteter med Sencha. De har også et svært levedyktig forum hvor Sencha sine utviklere er tilstede, samtidig som rammeverket er svært diskutert på internett. Et søk etter "Sencha" på stackoverflow [35], 11 obtober 2014, ga resultater.dette er noen av pekepinnene på at Sencha ikke kommer til å forsvinne helt med det første. Som med Titanium, så er support kun inkludert i den betalte versjonen. 20

21 5.3 Diskusjon kvalitativ analyse Xamarin står øyeblikkelig frem som et solid alternativ når det kommer til funksjonalitet som er native for plattformen det skal utvikles på. Utvikler en ios applikasjoner så vil man med Xamarin ha tilgang til Xcode sin GUI-builder som sørger for at en blant annet har tilgang til alle UI-elementene som er tilgjengelig på iosplattformen. Videre har Xamarin native API er for plattformspesifikk funksjonalitet som blant annet Game Center, In App Purchase, iad, NewsStand og mer. For Android er det mulig å utvikle all funksjonalitet og GUI direkte gjennom Xamarin sin IDE eller ved bruk av Visual Studio. I motsetning til f. eks. Sencha og PhoneGap så kompileres en Xamarin app til en native binary, istedenfor å tolkes. Denne native kompileringen skal gi brukerne bedre app ytelse for de mer krevende scenarioene. Xamarin hevder at applikasjonene [53] har langt raskere oppstartstid, og som kjører like raskt som om man utvikler en app i Java på Android eller i Objective-C/Swift på IOS. UI-elementene som blir brukt med blant annet Sencha, PhoneGap og Appcelerator Titanium kan virke som de er native, men er ikke det. De benytter seg av CSS for å emulere en native utseendet og følelse. Dermed vil applikasjoner utviklet med disse teknologiene være avhengig av å oppdateres når nye os versjoner blir lansert, da nye os versjoner ofte kommer med nye retningslinjer for hvordan applikasjoner skal se ut. Da må en enten endre på CSS en selv for å matche de nye UI-elementene eller så må en vente til de respektive aktørene oppdaterer sin CSS. Når CSS en er blitt endret må en oppdatere applikasjonen for deretter å vente til de respektive app storene godkjenner applikasjonen. På Android kan det ta et par timer, mens med ios kan det ta en uke. Med Xamarin vil ikke dette være et problem da de benytter seg av native UI-elementer og det vil være os versjonen som bestemmer hvordan en knapp ser ut. Kvaliteten på brukergrensesnittet til hybrid apps utviklet i for eksempel Phone- Gap og Sencha vil variere basert på kvaliteten i nettvisningen (webview) og renderingsmotoren på plattformen. Mens den Webkit-baserte renderingsmotoren på ios gir god ytelse, er android sin nettvisning funksjonell, men har noen bemerkelsesverdige begrensninger. Blant annet er det ikke lett å fange opp hendelser generert av visningen. På andre plattformer kan ytelsen på nettvisningen være avhengig av OS versjonen. Det finnes også en del problemer knyttet til nettlesere som utviklere av kryssplattformapplikasjoner alltid har måtte forholde seg til. Det er langt vanskeligere å få brukergrensesnittene til å oppføre seg konsistent på flere plattformer, derfor kreves blant annet fallback håndtering. Mobile nettlesere forbedres hele tiden, noe som vil bidra til å redusere disse problemene. Men å komme nærmere native kvalitet og ytelse i brukergrensesnittene er ikke en triviell oppgave. Sencha sysselsetter et stort team av webutvikling som er dedikert på heltid for å løse dette problemet. Selv med iherdig prøving er det enda ikke mulig å nå native kvalitet, ytelse og respons på brukergrensesnittene, heller ikke med et 21

22 rammeverk så avansert som Sencha Touch. Spørsmålet blir, er nettleserne gode nok til å møte våre behov? Dette skal undersøkes nærmere under den kvantative evalueringen. Alle teknologiene oppfyller minstekravet som er satt til å støtte Android og ios enheter. Titanium, PhoneGap og Sencha Touch støtter også en rekke mindre operativsystemer som for eksempel Tizen og BlackBerry. Xamarin støtter kun de tre store operativsystemene Android, ios og Windows Phone. Dette på bakgrunn av at brukergrensesnittet og API ene blir portet native og ikke med webteknologi som de andre teknologiene bruker. Sencha Touch er gratis for hvem som helst å bruke, men er begrenset med tanke på funksjonalitet og verktøy som er tilgjengelig. Skal man ha tilgang til de mange verktøyene som Sencha tilbyr for applikasjonsutvikling med HTML5, så er man avhengig av å kjøpe en bundle. Bundelen inneholder: Eclipse Plugin for ExT JS & Touch Sencha Touch Charts og Grid Sencha Mobile Packaging Enterprise DataConnectors, Sencha Support Package Sencha Architect som bidrar til at en kan bygge og prototype en HTML5 app visuelt. Dette alternativet er rikt på funksjonalitet og verktøy, men koster også deretter. Sencha skal ha 4 825$. PhoneGap på sin side er gratis å bruke, men er noe begrenset i funksjonalitet og verktøy som følger med. Det kommer for eksempel ikke med en egen IDE til PhoneGap. Utvikleren må derfor laste ned en separat teksteditor for å utvikle applikasjoner. Det finnes mange biblioteker man kan laste ned og benyttet seg av sammen med PhoneGap. Appcelerator Titanium er gratis å bruke og kommer også med en del ekstra som blant annet en IDE ved navn Titanium Studio og et MVC rammeverk. De har også en innebygget skytjeneste som er gratis for opp til API kall per dag, med et tak på 5 millioner API kall i måneden, sammen med 20 GB. Det er mulig å betale for å få noe som heter Appcelerator Studio som er en oppgradert IDE i forhold til gratisversjonen. En vil også få tilgang til profesjonell support og tilleggsfunksjonaliteter til rammeverket. Xamarin har en gratis evalueringsversjon som hvem som helst kan laste ned og prøve. Denne versjonen er strippet for funksjonalitet og har en begrensning på hvor stor applikasjonen som skal utvikles kan være. Denne begrensningen bidrar til at om en ønsker å utvikle en applikasjon av størrelse så er man avhengig av å kjøpe noen av de andre versjonene som starter på 25$ i måneden og opp mot 158$ i måneden [51]. Hva som ikke kommer fram på prissidene til Xamarin er at det er muligheter for å få tak i en studentversjon som innehar like mye funksjonalitet som 22

23 Business-versjonen gratis. Dette innebærer at en er i stand til å fremvise gyldig studentbevis. En utviklingsplatform må ha god dokumentasjon som viser funksjonaliteten og kapasiteten til teknologien. Det må være enkelt for utviklere å søke på informasjon og finne løsninger på internett. Alle teknologiene vi har sett på har hatt oversiktlige sider med god informasjon. Det har også vært tilgang til forum hvor brukerne kan skrive eller svare på spørsmål. Appcelerator sin side er den siden som utpekte seg som dårligst med tanke på dokumentasjon. Det var vanskelig å finne informasjon om pris og eksempler på kode. Xamarin, Sencha Touch og PhoneGap har gode sider med både kodeeksempler og brukerveiledninger. Support er et annet aspekt som ikke må undervurdes når man skal utvikle med relativt nye teknologier. Xamarin har 24/7 gratis support for de som har business-versjonen, som inkluderer studenter. Det er viktig med teknologi som videreutvikler seg og gir støtte for ny funksjonalitet som kommer i nye mobile enhetene. Sikkerhet er også en viktig faktor når det kommer til levbarhet. Hvis teknologien ikke oppdateres kan applikasjonen være utsatt for nye sikkerhetshull og feil. De store selskapene som Facebook og Google har gått vekk fra kryssplatform web-applikasjoner til native applikasjoner [18]. I et innlegg fra programvareutvikleren Jonathan Dann som jobber for facebook står det: "One of the biggest advantages we ve gained from building on native ios has been the ability to make the app fast" [53]. Selv om det viser seg at flere større teknologiselskaper satser mer på native applikasjoner vil ikke nødvendigvis utvikling av HTML5 baserte applikasjoner komme til å forsvinne. En grunn til at webbasert applikasjonsutvikling ble populært var blant annet at utviklere ikke ønsket å lage og vedlikeholde flere kodebaser for ulike plattformer. Dette resulterte ikke nødvendigvis i en bedre brukeropplevelse for brukeren av applikasjonen, men det sparte utviklere både tid og penger. Xamarin sin tilnærming til kryssplattformutvikling er spennende da det er mulig å dele svært mye kode over flere plattformer, samtidig som ytelsen og funksjonaliteten til applikasjonen som blir utviklet er native. Flere og flere utviklere har begynt å bruke Xamarin for å utvikle kryssplatform applikasjoner og nylig har Microsoft annonsert at Visual Studio skal bli gratis, samtidig som den skal få støtte ut av boksen for Xamarin Starter Edition [9]. Dette indikerer at Xamarin har en betydelig framtid foran seg når en tung aktør som Microsoft stiller seg bak. 5.4 Resultater av kvalitativ evaluering Resultatet er basert på diskusjonen i kapittel 5.3, hvor vi tok utgangspunkt i kriteriene beskrevet i kapittel 5.1. Poeng basert på hvor godt rammeverket oppfyllerer kriteriene: Høyt: 3 Medium: 2 23

24 Lavt: 1 Ikke: 0 Tabell 4: Resultater av kvalitativ evaluering. Kriterier Xamarin PhoneGap Sencha Touch Appcelerator/ Titanium Native funksjonalitet Støttede platformer Pris 3* Dokumentasjon Support Levbarhet Totalt * Business edition er gratis for studenter. Native funksjonalitet. Under punktet native funksjonalitet har vi tenkt på både brukergrensesnitt og enhetens spesifikke funksjonaliteter som for eksempel kamera, kompass, GPS osv. Alle teknologiene støtter bruken av enhetenes innebygde sensorer og spesifikasjoner, men kun Xamarin støtter native brukergrensesnitt. Støttede platformer. Alle rammeverkene/teknologiene støtter de nødvendige plattformene som er blitt beskrevet i den kvalitative analysen. Xamarin støtter til gjengjeld ikke like mange plattformer som de HMLT5-baserte rammeverkene. Dette på grunn av at HTML5-rammeverkene kan kjøres i nettleseren kontra Xamarin som kjører som en native applikasjon. Pris. Xamarin er gratis å bruke for studenter ved framvisning av gyldig studentbevis. I tillegg har Xamarin en gratis evalueringsversjon som en kan bruke for å teste ut rammeverket, men denne versjonen kommer med en begrensing som sørger for at en ikke kan kompilere applikasjoner over en viss størrelse. Appcelerator Titanium har en gratisversjon som har en IDE med begrenset funksjonalitet og et begrenset antall API kall til nettskyen. Med betalingsversjonen får man i tillegg en IDE med utvidet funksjonalitet og support. PhoneGap og Sencha kommer i gratisversjoner, men man kan også kjøpe versjoner av Sencha med utvidet funksjonalitet og support. Dokumentasjon. Alle teknologiene har egne forum hvor man kan legge inn spørsmål og lete etter svar. Dokumentasjonen på hjemmesidene til PhoneGap, Xamarin og Sencha er også godt strukturert og rik på informasjon. Titanium skiller seg ut her med dårligere informasjon på nettsiden, samt mindre aktivitet på f. eks stackoverflow. 24

25 Support. Ikke alle teknologiene tilbyr support. Sencha Touch og Appcelerator/Titanium tilbyr support ved betaling. Dette betyr at utvikleren må kjøpe en pakkeløsning for å kunne benytte seg av support funksjonen. Xamarin tilbyr support for Business, som inkluderer studenter og Enterprise edition. PhoneGap er den eneste teknologien som ikke tilbyr support. Levbarhet. Det er ingenting som tilsier at noen av rammeverkene vil forsvinne i den nærmeste fremtid. Basert på evalueringen er det ikke mye som skiller de ulike HTML5 baserte verktøyene fra hverandre. Xamarin stiller særdeles sterkt på bakgrunn av native funksjonalitet, pris, support og mange muligheter når det kommer til tilleggsfunksjonalitet. På bakgrunn av den kvalitative evalueringen kan vi konkludere med at Xamarin er det beste alternativet. 5.5 Kvantitativ evaluering Gruppen har valgt å teste de aktuelle teknologiene med ytelsesmålinger: Tiden registreres før en oppgave skal utføres og etter den er ferdig for å se hvor lang tid utføringen tok. Ved slike ytelsesmålinger er det svært viktig med likt testmiljø for de ulike teknologiene. Testene er derfor utført på samme nettverk med følgende enhet: Samsung Galaxy S4 Active 2048 MB RAM 1900 MHz Quad core 1920x1080 oppløsning Android 4.3 OS Oppsett. Oppsett av utviklingsmiljø er første møtet med ny teknologi og danner førsteinntrykket. Det finnes flere teknologier som har et så avansert oppsett at det er fort gjort å gi opp før man er kommet i gang med selve utviklingen. Test 1: Henting og manipulering av store datamengder. I denne testen skal applikasjonen hente ut en JSON-fil på 12 MB og prosessere, lagre og skrive ut data fra denne i brukergrensesnittet. JSON-filen blir hentet fra en server som er satt opp lokalt. På bakgrunn av at JSON-filen ikke ligger i applikasjonen, men blir hentet fra en server er det viktig å kjøre testen mange ganger for å oppnå et pålitelig resultat. Informasjonen som skal velges fra JSON-filen og printes ut på skjermen består av 6100 linjer med tekst. 25

26 Test 2: Oppstartstid med store grafiske elementer. I test to skal applikasjonens oppstartstid testes. Når applikasjonen er lastet inn vil det bli printet ut et bilde på 1 MB 30 ganger etter hverandre. Når alle bildene er printet ut på skjermen blir tidtakingen stoppet. Testene er valgt ut for å sjekke hvordan teknologiene gjør det på de områdene som er viktige med tanke på den kommende masteroppgaven: Henting av data fra en webtjeneste, visning av mye informasjon, oppstartstid og bildelasting Xamarin Oppsett av Xamarin. Installasjonsfilen kan lastes ned fra Xamarin sine nettsider [49], for så å kjøres. Siden datamaskinen som ble brukt allerede hadde Visual Studio installert, måtte filstien til de nye komponentene som ble installert eksplisitt bli spesifisert. Visual Studio(2012) ->Tools->Xamarin for så å bla opp filstien til Android SDK og Android NDK. Deretter må det opprettes et Android prosjekt som vil opprette en filstruktur for prosjektet som resulterer i en applikasjon med teksten "Hello World". Oppsettet av Xamarin.iOS var helt likt, men for å kunne utvikle i Visual Studio på Windows måtte en Mac være tilkoblet samme nettverk og parres med Windows-maskinen. Dermed kan man utvikle native for både Windows, Android og ios i Visual Studio på en Windows maskin. Utvikling og implementering av test 1. Først lages en enkel LinearLayout i XAML som kan inneholde mange ulike visninger(se Figur 2). Siden inneholdet skal legges til gjennom C# koden etter at JSON-filen er mottatt fra webtjenesten må Linear- Layout objektet fås tak i. Figur 2: XAML for grafisk brukergrensesnitt. 26

27 Figur 3: Kode for å vise brukergrensesnitt. På Figuren 3 blir en LinearLayout og en knapp generert ved oppstart som har hendelsen getevents() bundet til seg ved et klikk. Figur 4: Kode for å hente og manipulere data. Ved kjøring av getevents() starter tidtakingen, for så å kjøre metoden GetResponse() hvor data mottas i JSON-format fra web-tjenesten. Videre velges den informasjonen JSON-objektene som skal vises. Til slutt lages et TextView som blir lagt til i LinaerLayout objektet for å bli synlig på skjermen. Koden er vist i Figur 4. Utvikling og implementering av test 2. Ved denne testen skal applikasjonen kun vise 30 bilder. Disse vises ved å lage et ImageView for hvert bilde. Dette må gjøres på alle 30 bildevisningene. For å finne ut hvor lang tid det tar fra oppstart til alle bildene er blitt lastet opp til minnet og vist frem til skjermen bruker vi.net sin Process klasse som kan hente ut start tiden til prosessen. 27

28 5.5.2 PhoneGap Oppsett av PhoneGap. PhoneGap kan lastes ned og installeres ved å bruke NodeJS sin pakkebehandler. NodeJS er et miljø laget i JavaScript som ofte blir brukt til server-side og nettverksapplikasjoner. Etter installasjon av NodeJS kan man skrive "npm install -g phonegap" i kommandolinjen. Dette resulterer i at PhoneGap blir lastet ned og installert på datamaskinen. For å lage et nytt prosjekt kan man nå skrive "phonegap create new-app" i kommandolinjen. Da vil det bli laget en prosjektmappe som inneholder alle nødvendige filer for å kjøre applikasjonen. For å kjøre applikasjonen på en Android enhet må Android sin software development kit (SDK) lastes ned. Etter installasjon av SDK en må både "bin" mappen til Android sin SDK og Java sin Java development kit(jdk) refereres til i miljøvariablene til datamaskinen. Dette stod det ikke noe om på PhoneGap sine sider, noe som resulterte i søking etter feilmeldinger ved kjøring av applikasjonen. For å kjøre applikasjonen på en iphone er det krav om å bygge koden på en Mac. Fremgangsmåten er ellers lik, som ved bygging og kjøring av et Android prosjekt. Utvikling og implementering av test 1. For å kunne teste PhoneGap ble det lastet ned AngularJS. AngularJS ble benyttet for å få en god struktur på applikasjonen, samt ha en god måte å manipulere JSON-objekt. På Figur 5 blir kontrolleren til applikasjonen laget. Funksjonen getcontent() blir kalt når en knapp i brukergrensesnittet blir trykket på. Deretter blir det gjort et kall mot serveren etter JSON-filen. Når applikasjonen får en response fra serveren blir objektet lagt i en variabel som heter "events". Figur 5: Kontrolleren til applikasjonen. Funksjonen starttimer() blir kalt rett etter at getcontent() funksjonen er startet. 28

29 For å stoppe klokka blir det kalt en funksjon stoptimer() etter at HTML-koden er laget og printet. Brukergrensesnittet blir enkelt laget ved hjelp av HTML. AngularJS gjør det mulig å skrive ut alle elementene i events variabelen ved hjelp av ng-repeat, se Figur 6 under. Figur 6: HTML fil for å skrive ut json objektet. Utvikling og implementering av test 2. Test 2 ble laget for å kunne teste oppstartstiden og hvordan PhoneGap behandler mange store grafiske elementer. Ved å fjerne all unødvendig funksjonalitet kunne vi teste applikasjonen under perfekte forhold Appcelerator/Titanium Oppsett av Appcelerator/Titanium. Tilsvarende som PhoneGap, bare at installasjonsfilen hentes fra Appcelerator sine sider [5]. Kjøringen av installasjonsfilen resulterer i Titanium Studio, hvor man kan opprette prosjekter og begynne å utvikle. For å lage en ios applikasjon trenger man å installere Titanium Studio på en Mac. Utvikling og implementering av test 1. På Figur 7 vises doclick() funksjonen som blir kjørt ved at knappen i brukergrensesnittet blir trykt på. Her blir en HTTPklient først opprettet ved å bruke Titanium sitt bibliotek. Siden resultatet av webforespørselen er et JSON-objekt må responsteksten parses. Til slutt kjøres to for-løkker for å hente ut og vise frem ønsket informasjon fra JSON-objektet. 29

30 Figur 7: Kode for test 1. Utvikling og implementering av test 2. Det grafiske i Titanium kan utvikles i Alloy som er et deklarativt språk [20]. Syntaksmessig er Alloy svært likt XML, noe som gjorde testingen enkel. En bildevisning blir lagd for hvert bilde Sencha Touch Oppsett av Sencha Touch. Sencha Touch kan lastes ned fra Sencha sine nettsider [40]. Filen som blir lastet ned er en mappe med HTML-filer. HTML-filene kan kjøres i nettleseren og er en guide på hvordan Sencha Touch blir installert. For å kunne kjøre Sencha er det satt krav til å installere Sencha sin kommando integrasjon. Når denne.exe filen er kjørt vil det være mulig å bruke Sencha sine kommandoer i Windows sin kommandolinje. Ruby må også installeres på maskinen før utvikling av applikasjoner kan starte. Ruby er et dynamisk programmeringspråk som har åpen kildekode. Når Ruby er lastet ned og installert på datamaskinen er Sencha Touch ferdig installert. Ved kjøring og bygging av applikasjonene i Sencha blir det vist en feilmelding i kommandolinjen. Denne feilmeldingen sier at Sencha ikke klarer å kjøre en bakgrunnsprosess. Bakgrunnsprosessen som ikke blir kjørt i Sencha Cmd v er Sass sin kompilator. For å kunne bygge prosjektet må derfor Sass-kompilatoren slås av manuelt ved å skrive "skip.sass=1" i filen "sencha.cfg". For å overføre applikasjonen til en mobil enhet må Sencha SDK Tool lastes ned. Denne kjørbare filen var ikke tilgjengelig på Sencha sine sider da vi fikk en "404 File Not Found Exception". Derfor måtte filen lastes ned fra en annen nettside. Det var vanskelig å finne en fungerende guide som viste hvordan applikasjonsmappen 30

31 skulle bli generert til en apk-fil. Etter mye feiling med å integrere Sencha SDK Tool ble applikasjonsmappen til slutt generert til en apk-fil. Utvikling og implementering av test 1. Ved kjøring av test 1 blir funksjonen get- Data() kalt. Denne funksjonen kaller webserveren og får tilbake en JSON-fil som resultat. For å vise innholdet i brukergrensesnittet blir resultatet manipulert og ønsket informasjon hentet ut. Deretter blir informasjonen skrevet ut i en tekstboks på skjermen, se Figur 8. Figur 8: Kode for test 1. Utvikling og implementering av test 2. I test 2 ble det lastet og vist 30 bilder i brukergrensesnittet. For å teste applikasjonen under best mulige forhold slettet vi unødvendig funksjonalitet. 5.6 Resultat av kvantitativ evaluering Resultatene av ytelsestestingen er presentert i en graf. Skjermbilder av de forskjellige testene er også satt sammen forå vise hvordan testene fungerte og hvor likt det var på hver plattform. 31

32 5.6.1 Test 1: Henting og manipulering av store datamengder Den første testen gikk ut på å hente en stor JSON-fil med data fra en lokal server. Dataene skulle så lagres i en liste og spesifikke elementer av listen skulle skrives ut. I Figur 9 under er resultatet vist i millisekunder. Resultatet ble regnet ut ved å kjøre applikasjonen 100 ganger for så å ta gjennomsnittet av kjøretiden. Xamarin vant denne testen med en kjøretid på kun 2 404,3 ms. PhoneGap fikk dårligst resultat med en gjennomsnittlig kjøretid på ,1 ms, mens Sencha fikk et resultat på ,2ms og Titanium et resultat på ms. Figur 9: Henting og manipulering av store datamengder. I Figur 10 under er resultatene etter en gjennomføring med de forskjellige teknologiene. Figur 10: Gjennomføring av test 1. 32

33 5.6.2 Test 2: Oppstartstid med store grafiske elementer I den andre testen er det fokus på hvor godt teknologiene behandler store grafiske elementer. For å kunne teste dette ble det lagt inn 30 bilder på 961 kb hver. Bildene ble så printet ut på skjermen. Stoppeklokken ble startet ved applikasjonsstart og stoppet når alle grafiske elementer hadde blitt skrevet ut på skjermen. I Figur 11 under er resultatet vist i millisekunder. Resultatet ble regnet ut ved å kjøre applikasjonen 100 ganger for så å ta gjennomsnittet av kjøretiden. Xamarin kommer også i denne testen best ut med et resultat på 1 512,1 ms. PhoneGap (2 324,7 ms), Sencha Touch (2 352 ms) og Titanium (2 361 ms) får alle en kjøretid på rundt ms. Figur 11: Oppstartstid med store grafiske elementer. I Figur 12 under er resultatene etter en gjennomføring med de forskjellige teknologiene. Figur 12: Gjennomføring av test to. 33

34 5.7 Diskusjon av kvantitativ evaluering Xamarin utfører, i gjennomsnitt, den første testen 6.3 ganger raskere enn Phone- Gap og den andre testen 1.6 ganger raskere. Siden test to går såpass mye raskere, er det naturlig at det er mindre forskjell i utføringen av denne. Det er en tydelig tendens, spesielt i test en, at Xamarin og Titanium som kompilerer til native kode er raskere enn hybrid løsningene. Titanium viste seg å ha veldig mye overhead, testapplikasjonene ble store i motsetning til de andre teknologiene. Testapplikasjonen ble 7.3 MB med Xamarin og hele 22.3 MB med Titanium. Resultatene er entydige på at Xamarin utfører oppgavene raskest. Man merker det også på brukeropplevelsen, ved å for eksempel skrolle i visninger som inneholder mye tekst at applikasjonene flyter bedre. Da Xamarin har kommet seirende ut både på den kvalitative og kvantitative evalueringen er det Xamarin som er det klare valget å gå videre med. 6 Testapplikasjon Da det ble bestemt å gå for Xamarin på bakgrunn av den kvalitative og kvantiative evalueringen, var det neste steget å utvikle en applikasjon for å undersøke viktig funksjonalitet i bibliotekene som følger med Xamarin. Dette for å kvalitetssikre at det faktisk er mulig å utvikle den funksjonaliteten som kreves. 6.1 Testapplikasjonen Siden mye av poenget er å dra mest mulig nytte av kodedeling på tvers av plattformene, vil testapplikasjonen ha et hovedprosjekt med logikk og dataaksess. Prosjektene. Testapplikasjonen blir delt inn i de tre følgende prosjektene: Xamarin.Android som vil inneholde plattformspesifikt brukergrensesnitt til Android. Xamarin.iOS som vil inneholde plattformspesifikt brukergrensesnitt til ios. PCLCore som vil inneholde dataaksess og logikk. PCL står for Portable Class Library og sørger for at det kun er tillatt med kode som kan kjøre på valgte plattformer, som i vårt tilfelle er ios og Android. Dersom man prøver å skrive plattformspesifikk kode i dette prosjektet vil man få en feilmelding med en gang. Det ble fokusert på tre hovedpunkter: Intern lagring på enheten Fordi applikasjonen som skal utvikles som masteroppgave må kunne lagre data på enheten, slik at noe av funksjonaliteten vil fungere uten internett tilgang. 34

35 Webforespørsler for kommunikasjon med serveren For å lese og skrive data til en server. Skalering Da det finnes utallige oppløsninger så trengs det en god måte å skalere brukergrensesnittet opp/ned på. Valget falt på å utvikle et spill da det krever god ytelse, og vil gi en veldig god pekepinne på hvordan Xamarin håndterer animasjoner, prosessortunge beregninger og flyt i brukergrensesnittet Skalering Ved å lage en ResolutionRenderer klasse med en bestemt virtuelle bredde og høyde på 2560x1440 for så å ta inn enhetens egentlig oppløsing var det mulig å regne ut størst mulig område som passer til enhetens aspect ratio, se Figur 13 Figur 13: Kodesnutt fra ResolutionRenderer.cs. Valget falt på en fast virtuell oppløsning på 2560x1440. Det er bedre å bruke bilder og animasjoner i forhold til den høyeste oppløsningen, for så å skalere nedover for enheter med lavere oppløsning enn motsatt for å unngå et pikslete brukergrensesnitt. 35

36 (a) ipad Air 2040x1536, aspect ratio: 1,33 (b) iphone 4s 1136x640, aspect ratio: 1,77 Figur 14: Oppløsning Som vist på Figur 14 er resultatet likt på to enheter med forskjellige oppløsninger og aspect ratio Web-forespørsler for kommunikasjon med serveren For å teste webforespørsler ble det implementert scoreboards i applikasjonen. Ved å ha en server med en MySQL database, samt ulike PHP-script for uthenting av data samt skriving av data liggende på serveren, var det lite kode som trengtes for databehandlingen. Det er PHP-scriptene som tar seg av all funksjonalitet som er knyttet opp mot databasen, som f. eks å kjøre SQL spørringer..net har en HttpWebRequest klasse som innehar all funksjonalitet som trengs for å gjøre webforespørsler, se Figur 15. Figur 15: Kode for henting av data fra server. Det lages en forespørsel med den aktuelle nettadressen, for så å definere hvilken metode som skal benyttes. Request.Timeout bestemmer hvor lang tid det maksimalt kan ta før det kastes en WebException. Vi mottar en respons for så å lukke tilkoblingen Intern lagring på enheten Å finne en måte å lagre filer og databaser på som funker på begge plattformene har store fordeler med tanke på å spare tid og antall kodelinjer. Dette medfører mindre 36

37 kodebase å vedlikeholde. Gjennom Xamarin har man tilgang til System.IO som inneholder en del klasser som tilsammen utgjør Isolated Storage. IsolatedStorage- File har metoden GetUserStoreForApplication som finner filstien til hvor appen har bruksrettigheter, og da kan opprette filer og databaser der. Mens Isolated- StorageFileStream.CreateFile oppretter filen og lagrer den hvor IsolatedStorage- File objektet har spesifert at applikasjonen har lese og skrive rettigheter. For å skrive til filen lages et StreamWriter objekt som har avhengighet til et Isolated- StorageFileStream objekt. Samme prosedyre for å lese filen, men da trengs det et StreamReader objekt. Ved å benytte seg av Isolated Storage og strømmer er det mulig å lagre både filer og databaser. Ved opplastning av mobile applikasjoner til App Store har Apple en vurdering av applikasjonen før den slippes ut. Resultat av anmeldelsen var at applikasjonen ble avvist. Dette på grunn av en feil ved at applikasjonen kræsjer ved oppstart. Ved disse tilfellene sender apple med en krasjrapport. Krasjrapporten inneholdt veldig mye informasjon som det var vanskelig å få noe fornuftig ut av. Det som ved første øyekast virket interessant var en feilmelding som het: EXC_CRASH (SIGABRT). Et raskt søk sa følgende om en SIGABRT: SIGABRT errors are caused by your program aborting due to a fatal error. Det viste seg at det finnes mange grunner for at en SIGABRT oppstår. Unhandled managed exception: Access to the path "/var/mobile/documents/.config" is denied. (System.UnauthorizedAccessException) Denne linjen befant seg midt i krasjrapporten som består av hundrevis av linjer, men gav virkelig et stort hint til hvor problemet var. Applikasjonen har altså ikke tilgang til en filsti som brukes, og eneste plassen i Wire Loop hvor det kunne være var FileManageren hvor IsolatedStorage ble brukt. Unntaket ble kastet når IsolatedStorageFile.GetUserStoreForApplication kjørte. Selv om dette forklarte hvor problemet oppsto, var det fortsatt uforståelig hvorfor det skjedde når Apple testet appen. Dette oppstod ikke ved tidligere testing av applikasjonen på reelle enheter(både ios 7 og ios 8). IsolatedStorage finnes i mscorlib.dll som kommer med Xamarin og er derfor deres ansvarsområde. Etter en rask mail til Xamarin support visste det seg at dette problemet nettopp hadde blitt oppdaget. I feilrapporten som var opprettet av Xamarin kom det også frem at dette kun skjedde på ios 8, og på enheter som ikke var blitt brukt til utvikling. Dette forklarte hvorfor probelemet ikke oppstod under testing. Neste spørsmål som dukket opp var hva som var annerledes med filplasseringer på ios 7 og 8. Apple har lagt ut et teknisk notat om dette med følgende forklaring. ios 8 splits the data of an application from the application bundle. Code which attempts to derive the path to the Documents or Library directories will return an invalid path on ios 8. Attempting to access this path will fail, and may terminate your app [6]. Løsningen på problemet kan sees i Figur 16 37

38 Figur 16: Løsning på ios 8 problem. Det sjekkes først hvilken ios versjon enheten har. Er det ios 7 eller eldre, brukes gamlemetoden. Dersom det er versjon 8 eller nyere spør applikasjonen operativsystemet om å få plasseringen til katologen dokumenter. Wire Loop passerte så testprosessen og ble tilgjengelig i App Store Ytelse Under utvikling av test applikasjonen ble det laget en FPSCounter klasse for å kunne følge med på hvordan spillet gjorde det ytelsesmessig på både Android og ios. Applikasjonen lå i stabilt på 60 frames per second. Dette førte til at applikasjonen kjørtes uten forsinkelser. 6.2 Diskusjon Testapplikasjonen delte omkring 90% av kodebasen mellom ios - og Androidplattformen. Håndtering av webforespørsler og skalering viste seg å ikke være utfordrende i forhold til muligheten for å lagre data internt på enheten. Dette måtte gjøres på to forskjellige måter grunnet Apple sin nylige oppdatering fra ios 7 til ios 8. Det ble brukt plattformspesifikke klasser for ios som NSFileManager og UIDevice, noe som resulterte i to forskjellige versjoner av klassen FileManager. Denne klassen kunne dermed ikke lengre være lokalisert i PCL prosjektet, men ble istedenfor implementert plattformspesifikt for de to aktuelle plattformene. Dette er en av ulempene med å utvikle kryssplattformapplikasjoner med Xamarin. Ved større systemoppdateringer på ios eller Android er det en mulighet for at noe av funksjonaliteten i Xamarin sine biblioteker ikke fungerer lenger. Dermed må utviklere vente på at Xamarin oppdaterer de bibliotekene som er berørt, noe som kan føre til forsinkelser. Hadde applikasjonen blitt utviklet i Objective-C for ios, ville en løsning vært tilgjengelig fra Apple samme dag som lanseringen av operativsystemet. Dette problemet ble riktignok løst i dette tilfellet ved at Xamarin raskt svarte på henvendelser og hadde en midlertidig løsning klar. Gjennom utvikling av testappliksjonen ble det bekreftet at: 38

39 Man ender opp med en applikasjon hvor mesteparten av kodebasen kan kjøres på både ios og Android. Applikasjonen som ble uviklet setter høye krav til FPS. Dette kravet ble innfridd. Visual Studio viste seg å være en god IDE for utvikling av mobile applikasjoner. God support. Det fantes både et aktiv forum og en egen supportavdeling som svarte raskt på eventuelle problemer som oppstod. 7 Utviklingsprosess Prosess og verktøy som støtter opp under utviklingsprosessen blir beskrevet i dette kapittelet. 7.1 Kildekontroll Github Github tilbyr tilgang til kode som er lagret eksternt på en server. Det tilbys også mange egenskaper som gjør det lettere å sammarbeide med andre. Disse egenskapene er wikis, oppgave behandling, feilrapportering og deling av kode [11]. Github tilbyr i hovedsak offentlige lagring av kode. Dette betyr at andre kan få tilgang til koden ved å søke etter prosjektet på google eller github sine sider. Hvis utviklerene ikke vil ha offentlig lagring av koden kan de kjøpe seg private oppbevaringssteder på github, se Tabell 5. Github tillater integrasjon av tredjepart programvare. Dette gir muligheten til å velge egen programvare til de forskjellige egenskapene git har. Et eksempel på et slikt tredjeparts program kan være KDiff3 som gjør det lettere å slå sammen kode fra ulike kilder [43]. Tabell 5: Pakkeløsninger på Github. Free $0/mnd Micro $7/mnd Small $12/mnd Medium $22/mnd Large $50/mnd Medlemmer Unlimited Unlimited Unlimited Unlimited Unlimited Public repositories Unlimited Unlimited Unlimited Unlimited Unlimited Private repositories Team Foundation Server(TFS) TFS er hovedsakelig laget for Microsoft Visual Studio. Det er alikevell muligheter til å implementere TFS i Eclipse ved hjelp av plugins [28]. Github og TFS har 39

40 mye av den samme funksjonaliteten og gjør det lettere å dele kode i form av oppgavebehandlig, deling av kode, sammensetting av kode fra forskjellige kilder med mer. TFS tilbyr også testing og administrasjonsfunksjoner for utgivelse av programvare. Administrasjonsfunksjonene for utgivelse av programvare ble integrert i TFS 2013 og sørget for en kontinuerlig distribusjonsløsning med mulighet for å overvåke utviklingen av en eller flere utgivelser. TFS følger med Microsoft Visual Studio, men kan også kjøpes separat til $499 for integrering i andre IDE er [31]. 7.2 IDE En IDE eller et integrert utviklingsmiljø er et program som skal bistå utviklere med programvareutvikling. Den består som regel av en teksteditor, verktøy for å bygge en programvareløsning og en debugger. Nyere IDE er tilbyr også muligheten for kodefullføring. På bakgrunn av den kvalitative og kvantiative evalueringen i kapittel 5, ble det fastslått at verktøyet som skulle brukes under utvikling var Xamarin. Dette begrenser alternativene for hvilke IDE er som kan brukes da Xamarin, foruten å komme med sin egen IDE, kun har støtte for å bruke Visual Studio Xamarin Studio Xamarin Studio er en IDE for mobil kryssplattformutvikling som kommer med Xamarin, og sørger for at det er mulig å utvikle applikasjoner for ios, Android og Mac. Den kommer med kodefullføring, muligheten for å få utvidet informasjon om koden og refaktorering. Videre inkluderer den en designer for utvikling av brukergrensesnitt, uten å skrive det i XML. Ved hjelp av integrasjon med Xcode, kan en også utvikle brukergrensesnitt for ios enheter. Noen av funksjonene til Xamarin Studio: Kodefullføring i C#. Skrive native applikasjoner på ios, Android og Windows. Utvikle native brukergrensenitt og dele kodebase på tvers av plattformene. Integrere UI-kontrollere, backend-systemer, skytjenester og tredjeparts biblioteker direkte i applikasjoner. Uvikle brukergrensenitt i Android uten bruk av XML. Pakke og distribuere applikasjonene til Google Play, App Store og Windows Store. 40

41 7.2.2 Visual Studio Visual Studio er et integrert utviklingsmiljø fra Microsoft og brukes blant annet til å utvikle grafiske brukergrensesnitt sammen med Windows Forms - eller Windows Presentation Foundation-applikasjoner, nettsider, webapplikasjoner og webtjenester. Visual Studio støtter alle språkene i.net-plattformen til Microsoft. Visual Studio sørger for å lette på programmeringsbyrden til utviklere ved å tilby innebygde verktøy som blant annet ulike designere for å utvikle brukergrensesnitt, websider, klasser og databaser. Sammen med mange innebygde funksjoner har også Visual Studio støtte for tredjeparts plugins som kan bidra til å forbedre og tilby ekstra funksjonalitet som blant annet støtte for ulike versjonskontrollsystemer. Noen av funksjonene til Visual studio: Støtter ulike programmeringspråk som blant annet Ajax, ASP.NET, XAML, JavaScript, DHTML, HTML, Visual Basic, Visual C#, Visual C++. Inkluderer en teksteditor som støtter syntaks utheving og kodefullføring ved bruk av Intellisens [30]. Uvikle brukergrensesnitt med Windows Form - og WPF designer. Mulighet for å tilpasse utviklingsmiljøet som en selv ønsker. Lag ulike byggekonfigurasjoner for løsninger og prosjekter. Debugging under byggeprosessen. Mulighet for å laste ned utvidelser. 7.3 Utviklingsprosess En iterativ og inkrementell utviklingsprosess består av en rekke iterasjoner som tilslutt ender opp med et ferdig resultat. Hovedpoenget med prosessen er sterkt korrelert med det faktum at alle kravene til programvare som skal utvikles ikke bestandig er kjent på forhånd. Derfor må disse kravene skaffes underveis og systemet blir levert i inkrementer, hvor hvert inkrement realiserer en del av systemets funksjonalitet. Hvert inkrement vil inneholde en samling av krav, analyse, design, implementasjon og testing. Brukerne får dermed presentert håndfaste resultater tidlig i prosessen og kan gi tilbakemelding om systemet tilfredstiller forventningene. Et synonym som har blitt brukt for å beskrive denne utviklingsprosessen er smidig utvikling [19]. Det finnes flere forskjellige prosessrammeverk som tar i bruk prinsippene bak smidig utvikling, men det mest populære [32] blir kalt Scrum. Da gruppen har mest erfaring med nettopp Scrum, samt at det er en veldokumentert og utprøvd prosess er det nettopp den valget faller på. 41

42 7.3.1 Scrum Scrum er en iterativ, inkrementell utviklingsmodell, som betyr at utvikling foregår i iterasjoner og utvalgte deler av systemet utvikles for hver iterasjon. En slik iterasjon kalles en sprint. En sprint gis oftest en varighet på 1 til 4 uker på å fullføres. Et viktig poeng er at en sprint ikke er for lang, fordi da vil det gå for lang tid før tilbakemelding blir gitt fra brukere og andre interessenter. Er en sprint for kort, vil ikke teamet rekke å gjøre nyttig arbeid. Derfor er 14 dager den mest vanlige varigheten for en sprint. Product backlog er en liste over hva som skal gjennomføres i utvikling av prosjektet og tar utgangspunkt i de sentrale use casene for prosjektet. Product backlogen er inndelt i det som kalles "stories" eller historier, og sorteres etter viktighet, lengde, avhengigheter osv. Alle disse faktorene er med på å gi en verdiestimering, som viser rekkefølgen over hvilke historier som bør prioriteres først i de ulike sprintene. Sprintkø lages som et utdrag fra product backlogen. Man velger ut noen historier fra product backlogen og bryter disse ned i mindre oppgaver som Scrum-teamet skal gjennomføre i løpet av den aktuelle sprinten. Hver sprint starter med et planleggingsmøte. Møtet brukes for å velge krav og funksjonalitet som finnes i product backlogen, som teamet mener de kan omgjøre til leveringsklar funksjonalitet i løpet av sprinten sin varighet. Et daglig Scrum-møte holdes under hver sprint. På møtet forteller Scrum medlemmene hva de fikk gjort i går, hva skal de gjøre i dag og er det noen hindringer som kan oppstå. I slutten av hver sprint gjennomførers et demonstrasjonsmøte hvor gruppemedlemmene demonstrerer funksjonalitet som er blitt utviklet under sprinten. Etter endt demonstrasjonsmøte, gjennomføres det et evalueringsmøte. Møtet starter opp med at alle medlemmene besvarer to spørsmål:"hva fungerer bra i sprinten? Hva kan forberedes til neste sprint?". Dette for å evaluere hvordan neste sprint kan bli bedre og ta med seg videre hva som gikk bra. En av fordelene med Scrum er blant annet muligheten for å minimere risikoen i et utviklingsprosjekt og raskt håndtere endringer, ved at det utvikles funksjonalitet i korte sprinter. Dette bidrar med tilbakemeldinger fra brukere og kan forhindre feil og misforståelser. Det finnes mange tilgjengelige verktøy for å administrere sprinter i scrum. På bakgrunn av at utvikling med Xamarin begrenser valget av IDE til Xamarin Studio og Visual Studio, er det mulig å benytte seg av innebygde verktøy for å håndtere Scrum. For å lage, administrere og endre product backlogen tilbyr Visual Studio funksjonalitet for dette gjennom TFS [27]]. Andre verktøy som kan benyttes er JIRA. Dette verktøyet gir muligheten for å lage product backlog, fordele arbeidsoppgaver og generere burndown charts [8] 42

43 8 Valg av driftsarkitektur Valg av serverløsning er viktig for å sikre god ytelse, lave kostnader og minst mulig vedlikeholding. I dette kapittelet kommer beskrivelser av serverløsninger valgt basert på popularitet. 8.1 Nettsky Databehandling i nettskyen er i hovedsak lagring og bruk av programmer og data som ikke ligger lokalt på en datamaskin, men som er tilgjengelig over internett. Skyen er kun en metafor for internett. Med databehandling i nettskyen er det mulig at flere brukere deler ressurser som er tilgjengelig seg imellom. Alle brukere kan benytte seg av en applikasjon og trenger ikke å vite at både applikasjonen og dataene den besitter ligger flere tidssoner unna og at det er hundre - kanskje tusenvis av andre brukere som deler disse imellom seg. Tjenester i nettskyen kommer i flere varianter: Infrastructure as a Service (IaaS): Nettskyen tilbyr en virtuell maskin til utviklere eller systemadminsitratorer. Platform as a Service (PaaS): Tilbyr en utviklings - og distribusjonsplattform i skyen. Software as a Service (SaaS): Lar forbrukere kjøre applikasjoner i skyen. Infrastructure as a Service(IaaS). Noen av tjenestene som IaaS tilbyr er: Automatisk reallokering av IP-adresser i tilfelle en feil med den underliggende virtuelle maskinen oppstår. Denne tjenesten er nyttig hvis instansen har en offentlig IP-adresse. Automatisk skalering. En av de viktigste prinsippene med en skytjeneste er at nye instanser fort og enkelt kan bli opprettet eller slettet ved behov. Platform as a Service (PaaS). Platform as a Service tilbyr utviklere en plass i nettskyen hvor applikasjoner kan kjøres. Skytjenesten tilbyr også automatisk skalering over virtuelle maskiner basert på kundemengden, automatisk deteksjon av feil og gjennoppretting, sikkerhet og automatisk oppdatering av operativsystem. Leverandører som tilbyr PaaS øker stadig. To av de mest kjente leverandørende av PaaS er: Google App Engine tilbyr et utviklingsmiljø for Python, Java, Ruby og GO. Google styrer distribusjonen og kjører koden. 43

44 Microsoft Azure tilbyr et operativsystem og en utviklingsplatform for å aksessere/utvikle applikasjoner på Microsoft sine datasenter. Azure tilbyr et utviklingsmiljø for applikasjoner som kjøres på Windows med.net. Azure har også et databasesenter som automatisk lagrer kopier av din database. Software as a Service (SaaS). Software as a Service er en distribusjonsmodell der programmer er tilbydd av en tjensteleverandør og gjort tilgjengelig for kunden. SaaS bidrar til at organisasjoner kan få tilgang til funksjonalitet til en kostnad som vanligvis er mindre enn hva lisensierte applikasjoner koster. På bakgrunn av at programvaren ligger eksternt trenger ikke kunden å investere i maskinvare som støtter applikasjonene som skal brukes. Fordeler: Med databehandling i nettskyen finnes muligheten til å fokusere mer på kjernevirksomheten til bedriften fremfor å fokusere på å administrere ulike datasentre. På denne måten frigjør en ressurser som kan brukes til blant annet å utvikle programvare som har en forretningsverdi for bedriften. Ved å utnytte IaaS, er man istand til å raskt bygge ut ny infrastruktur for å støtte nye applikasjoner. Forutsatt at applikasjonen er bygd på en hensiktsmessig måte, når belastningen på applikasjonen øker, kan en skalere dette enkelt ved å tilegne nye servere. Finansielt er databehandling i nettskyen fornuftig for små og nyoppstartede bedrifter med begrensede budsjetter. Det benyttes en pay-as-you-go (PAYG) betalingsmodell som innebærer at man betaler for den størrelsen og ytelsen det er behov for til enhver tid. Om en av skyserverne skulle bli utilgjengelig på bakgrunn av systemkrasj eller lignende er det en enkel oppgave å starte opp en ny server instans og fortsette med å kjøre applikasjonen eller tjenesten uten at altfor mye tid er blitt tapt. Ulemper: Skytjenesten er tilgjengelig over internett, uavhengig av hvor du er i verden. Dette medfører at om et datainnbrudd finner sted som følge av en hacker, dårlig bruker/passord-sikkerhet eller en uforsiktig ansatt, så kan verdifull bedriftsdata være kompromittert. I ly av de nylige NSA avsløringene i USA, så har blant annet Michael Redding, administrerende direktør i Accenture Technology Labs, uttalt følgende: "Because large cloud computing companies have more resources, he says, they are often able to offer levels of security an average small business may not be able to afford implementing on its own servers" [47]. 44

45 Det er ikke mulig å endre operativsystem eller selv velge hvilket programmeringsspråk som skal benyttes under utvikling av applikasjoner i nettskyen. Ved behov for et annet operativsystem eller programmeringsspråk må det leies en ny instans fra en skytjeneste som støtter det Microsoft Azure Microsoft Azure er en plattform som er utviklet av Microsoft. Den tilbyr både PaaS - og IaaS-tjenester og støtter en rekke forskjellige programmeringsspråk, rammeverk og verktøy som bidrar til at en kan bygge, distribuere og administrere sine applikasjoner og tjenester på Microsoft sine servere Google App Engine Google App Engine er en PaaS for å utvikle og drifte web-applikasjoner på Google sin infrastruktur. Den støtter programmeringsspråkene Java, Python, PHP og Go. Google App Engine bidrar til at applikasjoner kjører pålitelig under høy belastning og med store mengder data. Applikasjoner kjører i et sandboxed miljø som er sikkert og som tillater App Engine å distribuere forespørsler på tvers over mange servere for å hjelpe til med skalerbarheten når det er behov for det Amazon Elastic Compute Cloud (EC2) Amazon Elastic Compute Cloud er en del av Amazon sin cloud computing plattform kalt Amazon web Services. EC2 tillater brukere å kjøre sine applikasjoner på virtuelle maskiner og bidrar til at det er mulig med en skalerbar distribusjon av applikasjoner ved at brukere kan starte og avslutte nye serverinstanser når de ser behov for det. 8.2 Virtuelle private servere En virtuell privat server, VPS, har mange av de samme egenskapene en dedikert server har. Det er en plass for å legge kjørbar kode som må være tilgjengelig hele døgnet. På en virtuell privat server kan man laste opp egen programvare. Forkjellen på en virtuell privat server og en dedikert server er at en dedikert server er en hel server dedikert til ditt nettsted eller din applikasjon. VPS er en isolert partisjon som ikke forholder seg til de andre virtuelle serverne på primær serveren. Derfor er det mulig å ha en virtuell privat server med stabil ytelse som ikke blir påvirket av andre servere som kjører på primærserveren. Fordeler Virtuelle private servere er ikke like kostbare som en dedikert server. 45

46 Mange VPS pakkeløsninger kan bli tilpasset applikasjonens behov. Pakkeløsningene kan oppgraderes ved behov. Det er mulig å starte med en liten pakkeløsning med minimum tilgjengelige ressurser og oppgradere ettersom applikasjonen vokser. Ulemper På noen VPS plattformer må brukerne dele programvare med hverandre. Dette kan resultere i at konfigurasjon av programvaren ikke er mulig. Ressurser som RAM og CPU blir i noen tilfeller delt med brukerne av serveren. Derfor kan konflikter oppstå med lasting av data og minnebruk GoDaddy GoDaddy tilbyr mye av de samme funksjonalitetene på VPS som de gjør på de dedikerte serverne. Det finnes alikevell forskjeller. Lagringskapasiteten til de forskjellige pakkene er mye mindre enn de er på pakkene til de dedikerte serverne. Prisen er også noe lavere enn de er på de dedikerte serverne. Dette skyldes av spesifikasjonene på de virtuelle private serverne er noe dårligere enn de dedikerte serverne. 8.3 Dedikert server Selv om nettskytjenester har vokst betydelig de siste par årene, så debatteres det fremdeles hvorvidt en skal benytte seg av det fremfor dedikerte servere. Dedikerte servere er den tradisjonelle måten å hoste på hvor en bruker kjøper eller leier en server hos en leverandør og betaler for de ressursene serveren har tilgjengelig. Fordeler Har man et scenario hvor ressursbehovet er mer eller mindre konstant, vil det være fordelaktig og kostnadseffektivt å holde fast med en dedikert server. Dette på grunn av at ressursene i en slik server vil være mer ideelt for å håndtere denne type last. En dedikert server som kun brukes for å kjøre en applikasjon eller en type tjeneste vil være raskere enn en server som kjører flere ulike programmer. Hvor den dedikerte serveren vinner på ytelse, vil den derimot tape terreng når det kommer til effektivitet. Med en dedikert server vil en ha full kontroll på hvordan serveren skal konfigureres. Valg av operativsystem, lagringsalternativer, CPU, RAM og båndbredde bidrar til at en server kan tilpasses i det uendelige i forhold til kravene som blir stilt av applikasjonen eller tjeneste som skal hostes. 46

47 Ulemper En dedikert server kan koste fra hundre til tusenvis av kroner hver måned avhengig av hvilken konfigurasjon som velges. Disse månedlige avgiftene påløper og må betales uavhengig om alle ressursene på serveren brukes. På denne måten vil en i mange tilfeller betale for ressurser som en i utgangspunktet ikke har behov for. Dette er den største grunnen til at mange velger virtualiserte alternativer, da det der vanskelig å få utnyttet alle tilgjengelige ressurser i et dedikert miljø. Muligheten for å skalere ressurser på en dedikert server har en sterk korrelasjon med de ressursene som er tilgjengelig på den fysiske maskinvaren. Om en ønsker å skalere ut programmer eller tjenester med ekstra ressurser, krever dette ekstra maskinvare. Dette kan i mange tilfeller bli kostbart, og komplisert og tidskrevende å gjennomføre. Ved vedlikehold og drift av en dedikert server er det nødvendig med forkunnskaper med tanke på blant annet IP routing og ulike servermekanismer. Om en ikke besitter denne kompetansen selv må en outsource jobben videre. Om en dedikert server krasjer må den ha et duplikat tilgjengelig eller så må serveren repareres eller skiftes ut før applikasjonen eller tjenesten kan kjøres igjen. I slike tilfeller vil en gjennopprettingsplan være nødvendig for å spare tid og penger, men dette kommer selvfølgelig med en betydelig kostnad på den eksisterende løsningen GoDaddy Godaddy tilbyr dedikerte servere hvor man selv kan velge forhåndslagde pakker med forskjellige spesifikasjoner. Serverne kan bli brukt til en rekke formål og ikke bare hosting for nettsider. Eksempler på dette kan være spilling, virtuell hosting eller delt hosting, back-end server-services m.m. Godaddy gir brukeren administrasjonstillgang slik at det er mulig å legge til programvare på serveren. Kunden kan selv velge om de vil ha en Windows basert eller Linux basert server. 9 Evaluering av driftsarkitektur Kvantiativ og kvalitativ evaluering blir brukt i dette kapittelet for å komme frem til hvilken serverløsning som skal brukes. 9.1 Kriterier Oppetid. Det er viktig at tjenesten er tilgjengelig hele tiden. Derfor er det satt et krav til en oppetid på 99%. 47

48 Skalerbarhet. Det er viktig at arkitekturen tilbyr høy fleksiblitet når det kommer til skalerbarhet. Det må være mulig å skalere antall serverinstanser opp og ned avhengig av ressursbehov. Pris. På bakgrunn av et begrenset budsjett er pris en viktig faktor i valg av driftsarkitektur. Språk. Arkitekturen skal ha støtte for de vanligste programmeringsspråkene, slik at det ikke skal være nødvendig å bruke tid og ressurser på å lære ny teknologi. 9.2 Kvalitativ evaluering Microsoft Azure Tabell 6: Pakkeløsninger for Microsoft Azure. Instans Kjerner RAM Lagring Pris [kr/m] A GB 19 GB 86,04 A GB 224 GB 344,15 A GB 489 GB 682,57 A3 4 7 GB 999 GB 1 365,13 A GB 2039 GB 2 730,25 A GB 489 GB 1 491,31 A GB 999 GB 3 028,51 A GB 2039 GB 6 016,86 A GB 1777 GB ,37 A GB 1777 GB ,73 Azure bekrefter på sine sider at de har en oppetid på 99,99% [29], noe som tilsvarer rundt 53 minutter nedetid i året. Dette er hva vi kan forvente av nedetid av Azure, men det garanterer ikke at nedetiden ikke kan bli mer. Azure organiserer rolle instanser i logiske grupperinger som kalles oppgraderingsdomener. Når en ønsker å oppdatere en eller flere rolle instanser så vil Azure oppdatere de i forhold til hvilke oppgraderingsdomener de tilhører. Azure stopper alle instanser i et gitt oppgraderingsdomene, oppdaterer de, bringer de online igjen, for deretter å fortsette til neste oppgraderingsdomene. Ved å stoppe kun de instansene som kjører i det gitte oppgraderingsdomenet kan Azure sørge for at en oppdatering har minst mulig innvirkning på tjenesten som driftes. Microsoft Azure gjør det også mulig å programmere i.net, Java, Python og Ruby. Azure tilbyr muligheten for brukere å skalere applikasjonen som ligger i nettskyen i forhold til behov. Når en laster en applikasjon opp til Azure deployes to roller; en web-rolle og en arbeids-rolle for å håndtere backend prosessering [25]. Når applikasjonen kjører i Azure, kjører rollene som rolleinstanser, hvor en rolleinstans 48

49 er en virtuell maskin. Brukeren kan selv spesifisere hvor mange rolleinstanser vedkommende ønsker for hver rolle. Desto flere rolleinstanser, desto mer ytelse har man tilgjengelig, men det vil samtidig koste mer. Dette kalles å skalere ut. Azure tilbyr også muligheten for å skalere opp ved å øke størrelsen på rolleinstansene til å tilby flere kjerner, RAM og diskstørrelse per rolleinstans istedenfor å legge til flere små rolleinstanser. Både størrelsen og antallet instanser per rolle kan man bestemme selv når en først deployer en applikasjon til Azure. En kan også legge til og fjerne rolleinstanser samtidig som applikasjonen kjører, enten gjennom en web-portal eller gjennom programmering. Ved å ha muligheten til å legge til og fjerne rolleinstanser mens applikasjonen kjører, kan en balansere ytelsen i forhold til driftskostnadene. En kan legge til instanser når behovet er høyt og fjerne dem når behovet ikke lenger er tilstede. Microsoft sin skytjeneste Azure har ti ulike løsningspakker som brukerne kan velge mellom, se Tabell 6. Disse løsningspakkene varierer fra små skytjenester med lite ram og lagring til kraftigere skytjenester for prosessering av store mengder data Google App Engine Google App Engine opererer med en oppetid på 99.95%, noe som tilsvarer rundt 4,38 timer i året. Her er det viktig å bemerke seg at Google opererer med spesielle betingelser i sin Service Level Agreement som sier at all nedetid som ikke overskrider fem minutter med kontinuerlig nedetid, ikke teller mot den totale nedetiden til applikasjonen. Dermed vil man ikke få økonomisk godtgjørelse på bakgrunn av denne type nedetid [13]. Slik som Azure er det også mulig med automatisk skalering av server instanser. Dette løses med et orchestration rammeverk som involverer et verktøy implementert som en App Engine applikasjon. Verktøyet spør periodisk alle Compute Engine instanser for status [14]. Avhengig av applikasjonen, så kan denne statusen være belastning på CPU, minnebruk eller hvor mange oppgaver som venter på å bli gjort. Basert på brukerdefinerte kriterier, starter rammeverket opp nye instanser om det er behov for det og slår de av når det ikke er behov. Det er også mulig å endre skalering manuelt ved blant annet å estimere et gjennomsittlig behov for ressurser eller ved å prøve å estimere når belastningen er på sitt høyeste og planlegge utifra det. Problemet med begge disse tilnærmingene er at det er vanskelig å beregne slik bruk, samtidig som det er kostbart om spådommene ikke slår til. Google App Engine har støtte for Java, Python, PHP og GO. Google App Engine tilbyr en omfattende mengde ulike konfigurasjoner og er å finne på Google sine hjemmesider [16]. 49

50 9.2.3 Amazon Elastic Compute Cloud (EC2) Amazon EC2 opererer med samme oppetid som Google App Engine på 99,95%, noe som tilsvarer rundt 4,38 timer i året. Brukere får også en godtgjørelse på 10% av månedsfakturaen om oppetiden den aktuelle måneden er under 99,95%, men fremdeles over 99%. All nedetid under 99% blir gjort opp med 30% godtgjørelse på den månedlige fakturaen [2]. Som med både Azure og Google App Engine er det mulig å skalere opp eller ned instanser med Amazon ved behov. Med Auto Scaling oppretter en samling av EC2 instanser som kalles Auto Scaling Groups. Disse gruppene kan opprettes fra bunnen av med helt nye instanser eller med instanser som allerede er i produksjon. Hver gruppe kan inneholde en eller flere kriterier for når gruppen skal starte eller eliminere EC2 instanser innenfor den gruppa [3]. Med Auto Scaling kan applikasjoner bli mer feiltolerante ved at den oppdager når en instans er usunn og dermed terminere den og starte en ny instans for å erstatte den. De kan også bli mer tilgjengelige ved at Auto Scaling kan bruke ulike subnett og tilgjengelighetssoner. Dermed hvis et subnet eller en sone er utilgjengelig, kan Auto Scaling opprette nye instanser i et annet subnet eller tilgjengelighetssone for å kompensere. Som med Microsoft Azure så er det mulig å programmere i.net, Java, Python, Ruby og PHP. Amazon EC2 tilbyr mange forskjellige instanser med forskjellige spesifikasjoner. I Tabell 7 under ser dere grunnpakkene til Amazon. Dette er løsningspakker som er laget for både mindre og større applikasjoner. Amazon EC2 tilbyr også mange andre pakker som er spesiallaget for den enkelte applikasjonen. Dette kan være applikasjoner som trenger en rask prosessor, mye lagringsplass eller for eksempel mye RAM. Tabell 7: Pakkeløsninger for EC2 Instans RAM Lagring Pris [ $/time] t2.micro 1 GB Kun EBS t2.small 2 GB Kun EBS t2.medium 4 GB Kun EBS m3.medium 3.75 GB 1 x 4 GB SSD m3.large 7.5 GB 1 x 32 GB SSD m3.xlarge 15 GB 2 x 40 GB SSD m3.xlarge 30 GB 2 x 80 GB SSD GoDaddy Dedikert Server GoDaddy sine dedikerte servere garanterer en oppetid på 99,9%. Dette tilsvarer 8,76 timer i året [12]. Ved bruk av inntrengingsbeskyttelse som beskytter serveren fra DDoS og andre angrep fra eksterne kilder klarer GoDaddy å opprettholde oppetiden på 99,9%. GoDaddy opererer også med brannmur som sikrer angrep 50

51 mot serveren. Vedlikehold av sikkerheten blir gjort av fagpersonell som jobber for Godaddy. Det er enkelt å laste opp ny kode til GoDaddy ved bruk av for eksempel FTP, også kalt File Transfer Protocol. FTP er en protokoll som gjør det mulig å koble seg til en server og laste opp filer. Skalerbarhet hos GoDaddy er også mulig. Det er mulig å oppgradere til en større løsningspakke hos GoDaddy når som helst. Et problem med dette er at man ikke kan velge helt fritt hva man skal oppgradere. Det er for eksempel ikke mulig å kun oppgradere prosessoren Det er kun mulig å velge mellom en av pakkeløsningene til GoDaddy, se Tabell 8. Hver pakke inneholder en dedikert server med forskjellige spesifikasjoner. De varierer også i pris ut ifra ytelse og lagringskapasitet. Tabell 8: Pakkeløsninger for GoDaddy Dedikert Server. Instans Kjerner RAM Lagring Bredbånd Pris [kr/m] Economy Intel Core i3-2 kjerner 2 GB 2 x 160 GB 5 TB 86,04 Deluxe Intel Core i5-4 kjerner 8 GB 2 x 1 TB 10 TB 344,15 Premium Intel Core i7-4 kjerner 16 GB 2 x 2 TB 20 TB 682,57 Verditilbud Intel Core i5-4 kjerner 4 GB 2 x 300 GB 10 TB 1 365,13 Kraftbruker Intel Core i7-4 kjerner 8 GB 2 x 1 TB 15 TB 2 730,25 Minnemonster Intel Core i5-4 kjerner 32 GB 2 x 1 TB 15 TB 1 491, GoDaddy Virtuelle Private Server GoDaddy sine virtuelle private servere har også en oppetid på 99,9%. På grunnlag av at det også her er GoDaddy som eier de virtuelle private serverne er egenskapene, sikkerheten og vedlikeholdet likt som på de dedikerte serverne til Go- Daddy. En forskjell på de virtuelle private serverne og de dedikerte serverne til GoDaddy er pris og spesifikasjonene på de forhåndslagde løsningspakkene, se Tabell 9 for VPS løsningspakker. På grunn av at de virtuelle private serverne er isolerte vil de ikke bli påvirket av andre servere på primærserveren, se kapittel 5.4 for mer informasjon om virtuelle private servere. Dette gjør at serveren vil ha en jevn ytelse og ikke bli påvirket av andre servere. Tabell 9: Pakkeløsninger for GoDaddy Private Virtuelle Servere. Instans Båndbredde RAM Lagring Pris [kr/m] Economy 1 TB 1 GB 40 GB 222,99 Verdi 2 TB 2 GB 60 GB 296,99 Deluxe 3 TB 3 GB 90 GB 445,99 Premium 4 TB 4 GB 120 GB 593,99 Ultimat 8 TB 8 GB 240 GB 1 112,99 51

52 9.3 Kvantiativ evaluering For å vurdere ytelsen til Microsoft Azure, Amazon EC2 og Google App Engine ble det brukt tester som ble utført av Peter Wayner i februar 2014 [48]. Peter Wayner er en medvirkende redaktør hos InfoWorld, teknolog og forfatter. Ytelsen ble vurdert ved å bruke en open source testpakke som går under navnet DaCapo [38]. DaCapo inneholder et sett med ulike open source programmer som stresser maskinvare på ulike aspekter. Noen programmer vil stresse CPU, andre vil stresse RAM og enkelte vil stresse begge deler. Dette sørger for allsidighet siden det ikke er en maksinvarekonfigurasjon som vil være optimal for alle programmene. Alt dette er tilgjengelig i en enkel JAR-fil. Kort beskrivelse av de ulike testene som er tilgjengelig i testpakken vises i Tabell 10: Tabell 10: Beskrivelse av tester i DaCapo. Avrora Batik Eclipse FOP H2 Jython Luindex Lusearch PMD Sunflow Tomcat Tradebeans Tradesoap Xalan Simulerer en rekke programmer som kjøres på et rutenett av AVR mikrokontrollere Produserer en rekke SVG bilder basert på enhetstestene i Apache Batik Utfører noen av JDT ytelsestestene for Eclipse IDE Tar utgangspunkt i en XSL-FO-fil, analyserer og formaterer den, før den genererer en PDF-fil Utfører en rekke transaksjoner mot en modell av en bankapplikasjon Tolker en Python-test kalt pybench Bruker Lucene for å indeksere et sett med tekstdokumenter Foretar et tekstsøk over et sett med dokumenter Analyserer et sett med Java-klasser etter en rekke kidlekodeproblemer Renderer et sett med bilder ved hjelp av strålesporing Foretar et sett spørringer mot en Tomcat server, for så å hente og verifisere de resulterende nettsidene Kjører ytelsestesten Daytrader via JavaBeans på en GERONIMO backend som inneholder en in-memory H2 database. Kjører ytelsestesten Daytrader via SOAP på en GERONIMO backend som inneholder en in-memory H2 database Forvandler XML dokumenter til HTML Det ble testet tre forskjellige Linux instanser fra hver av de ulike skyene. Disse er ikke en perfekt sammenligning, men de er omtrent like i forhold til konfigurasjon og pris. Den eneste forskjellen fra testen som ble gjort i februar 2014 og til november 2014 var at prisene på de ulike maskinvarekonfigurasjonene har blitt endret. Dette er også blitt tatt hensyn til i resultatene når det kommer til kostnader. De ulike instansene er beskrevet i Tabell 11: 52

53 Tabell 11: Priser og konfigurasjoner for Azure [26], App Engine [16] og EC2 [1] Navn Antall kjerner RAM [GB] Pris [ $/time] Amazon m3.medium ,070 Amazon c3.large ,105 Amazon m3.2xlarge ,560 Google n1-standard ,049 Google n1-highcpu ,061 Google n1-standard ,385 Microsoft Azure a ,047 Microsoft Azure a ,094 Microsoft Azure a ,376 Det ble samlet sammen to sett av data fra hver instans. Det ene settet inneholdt data om hvor raskt instansen fullførte benchmarken fra en kaldstart. Dermed måtte instansen bli startet, koden måtte bli lastet opp for deretter å bli kjørt. Det andre settet inneholdt tall fra en alternativt start, som kjører benchmarken helt til konsistense resultater fremkommer. Figurene 17, 18 og 19 viser resultatene av de ulike testene. Rød farge viser dårligst tid/kost av samtlige instanser, blå viser hverken dårligst eller best, grønn viser best tid/kost av samtlige instanser. Tiden er målt i sekunder og kosten er i cent: Figur 17: Testresultater for Microsoft Azure sine instanser. 53

54 Figur 18: Testresultater for Amazon sine instanser. Figur 19: Testresultater for Google App Engine sine instanser. Utifra resultatene fra testene er det en del mønster som går igjen som det er mulig å gjenkjenne når vi sammenligner instanser fra de ulike tilbyderne med hverandre: 54

55 På de små instansene var Google raskest på 12 av 13 tester, Azure var ikke raskest på noen, mens Amazon kun var raskest på Tradesoaptesten. På de mellomstore instansene var Amazon raskest på 7 av 13 tester, Google var raskest på 5 av 13, mens Azure var raskest kun på Lusearchtesten. På de store instansene var Google raskest på 11 av 13 tester, Amazon var raskest på Lusearchtesten, mens Azure var raskest på Avroratesten. Totalt brukte Google minst tid på å utføre alle testene på de tre ulike instansene, mens Microsoft brukte mest tid. Google sin App Engine var det billigste alternativet på alle de ulike instansene. Foruten den minste instansen var Azure den dyreste av alle alternativene. Totalt fullført Google App engine alle testene raskest på både de små, mellomstore og store instansene. Google sin n1-highcpu 2 fullførte testene mest økonomisk av alle de ulike konfigurasjonene, mens Azure a4 kostet mest. En ting som er verdt å bemerke seg er at når en leier en instans hos skytjenestene, så deler du en liten del av en større maskin med mange andre. Dette betyr at det er en mulighet for at andre brukere kan påvirke ytelsen din og dette kan endre seg fra dag til dag. Andre aspekter som en la merke til er at større og dyrere maskiner ikke bestandig var raskere. Dette var spesielt tydelig på Avrora testen hvor blant annet Google og Microsoft sine to - og åttekjerne maskiner var tregere til å fullføre testen enn deres minste instans. På mange av de andre testene derimot så var de større maskinen raskere til å fullføre testene. Selv om de større maskinene var raskere til å fullføre testene sine, men noen få unntak, så er det viktig å belyse at disse maskinene koster opp mot åtte ganger mer enn sine minste instanser. Videre var ikke ytelsen til disse maskinene i nærheten av å være åtte ganger raskere, men heller 2 og 4 ganger raskere på de fleste testene. Eneste testen hvor disse store instansene var i nærheten av å yte i forhold til prisnivået var på Sunflow-testen. Der var Google 4, Microsoft 5 og Amazon 6 ganger raskere enn deres minste instans som ble testet. Noen av maskinene kunne oppleve korte tidsperioder med økt ytelse. Dette er noe skytilbyderne gjør om det er en mulighet til det og tidspunkt og varighet for disse korte ytelsesøkningene er vanskelig å spå. Dermed kan enkelte av testresultatene være påvirket av denne opppførselen. 9.4 Diskusjon av kvalitativ evaluering Basert på oppetid er det ikke mye forskjell på de ulike tilbyderne. Oppetiden ligger stabilt på over 99% for de alle, samtidig som både Google og Amazon tilbyr 55

56 økonomisk godtgjørelse om oppetiden beveger seg under 99%. Her er det viktig å bemerke seg at Google definerer nedetid først når en applikasjon har vært kontinuerlig nede i fem sammenhengende minutter. Alt under det vil ikke telle på den totale nedtiden og det vil ikke være mulig å kreve økonomisk godtgjørelse. GoDaddy tilbyr også økonomisk godtgjørelse for nedetid. Da er en avhengig av å kontakte GoDaddy selv og be om 5% kreditt på den månedlige fakturaen som en må bruke på tjenester eller produkter som GoDaddy tilbyr [12]. Alle alternativene som er blitt sett på har støtte for å programmere i Java, PHP, Python og Ruby. Google App Engine støtter også programmeringsspråket GO, mens de resterende støtter også.net. Med tanke på at applikasjonen som skal utvikles vil bli utviklet i et.netmiljø vil det være en vurderingssak hvorvidt det er viktig med muligheten for å programmere i.net på serversiden, selv om det ikke vil by på større utfordringer å programmere dette i Java. Når det kommer til muligheten for å skalerbarhet er de ulike nettsky tilbyderne med henholdsvis Google, Microsoft og Amazon like. Det er mulig å fastsette brukerdefinerte kriterier for hvor store, hvor mange og under hvilke omstendigheter nye instanser skal starte og avslutte. Det er også mulig å bestemme dette manuelt ved å spå når belastningen på applikasjonen er høy/lav og planlegge hvor mange instanser en har behov for utifra det. Dedikerte og private virtuelle servere har ikke denne fleksibliteten som nettskyen tilbyr, noe som fører til at om en har behov for mer ytelse er en avhengig av å oppgradere abonnementet sitt hos GoDaddy. På bakgrunn av denne skalerbarheten er det vanskelig å anbefale bruk av Go- Daddy sine servere over nettskyalternativene, da applikasjonen som skal driftes på arkitekturen ikke vil oppleve et konstant ytelsesbehov. Dette behovet vil variere gjennom dagen og med en dedikert server, vil denne være inaktiv deler av dagen og ikke gjøre noe annet enn å kaste bort cpu-sykluser. Dette vil være i sterk kontrast til det fleksible alternativet nettskyene tilbyr, ved å skalere antall instanser både i størrelse og antall avhengig av ytelsesbehovet applikasjonen har ved det aktuelle tidspunktet. Utifra dette er det ikke aktuelt å gå videre med GoDaddy sine alternativer. 9.5 Diskusjon av kvantiativ evaluering Når det kommer til ytelses - og kosttestene som ble utført på de ulike nettskyene er det viktig å ta med i betrakningen at selv om det ble testet tre ulike instanser fra henholdsvis Amazon, Google og Microsoft, er det fremdeles mange ulike konfigurasjoner med ulik mengde RAM, CPU og lagring som ikke er blitt testet. Derfor er det viktig å ta med i betraktningen at det ikke er et fasitsvar på hva det beste alternativet vil være i dette tilfellet, men testene som er blitt gjort kan gi oss en generell pekepinne på hvordan de ulike aktørene klarer seg mot hverandre. Amazon var med sin enkjernes konfigurasjon dårligst ut når det kom til kostnadene ved å utføre de utvalgte testene, selv om den ikke kom dårligst ut med 56

57 tanke på tiden den brukte. Derimot var deres to - og åttekjernes konfigurasjon mer konkurransedyktig både med tanke på pris og ytelse, hvor tokjernes konfigurasjonen hadde den raskeste tiden på 7 av 13 tester. Microsoft Azure sin enkjernes konfigurasjon var den neste beste når det kom til kostnadene ved å utføre testene, men var aldri raskest på å utføre noen av testene. Dette var ikke et mønster som vedvarte med deres to - og åttekjernes konfigurasjoner hvor de var omtrent de dårligste når det kom til kostnader, samtidig som de kun var raskest på Lusearchtesten. Google sine instanser var overlegne når det kom til ytelse og pris, og dette var gjennomgående for en, to - og åttekjernes konfigurasjonene. Med tanke på pris er det Google sine instanser som viste seg å være mest økonomisk gjennom testperioden, mens Azure viste seg å være den som kostet mest. Ser man på prisene på de ulike instansene individuelt derimot blir det plutselig litt mer kompleks. De ulike nettskytilbyderne dobler omtrent prisen om de dobler størrelsen på instansen, selv om ytelsen ikke nødvendigvis blir doblet. Om en ønsker å få mest mulig klokkesykluser per krone, må en nesten gjøre egne beregninger. Amazon tilbyr også muligheten for å foreta en engangsbetaling for å reservere en instans og til gjengjeld få en lavere pris på den instansen om den blir reservert for 1 eller 3 år. Google har også flere prisalternativer avhengig av hvor mye instansen blir brukt i løpet av måneden. Kjører instansen på nærmere 100% av hva den er kapabel til i løpet av en måned, vil det bli påført en rabatt på fakturaen. Brukes den derimot mindre enn 25% av hva den er kapabel til i løpet av en måned, vil det bli dyrere enn den typiske prisen på instansen. Den typiske prisen på instansen reflekterer hva Google mener er gjennomsnittsbruken av en instans som blir regnet ut over alle Compute Engine brukerne. Microsoft og Amazon tilbyr også Windowsinstanser, men disse koster ekstra i forhold til Linuxinstanser. 9.6 Resultat av kvalitativ og kvantiativ evaluering Etter den kvalitative vurderingen ble det fastslått at på grunn av mangelen på skalerbarhet på GoDaddy sine servere, var det ikke aktuelt å satse på denne arkitekturen. Dermed står valget mellom Amazon EC2, Google App Engine og Microsoft Azure som alle tilbyr instanser i nettskyen. I den kvantiative evalueringen kom vi fram til at Google App Engine sine instanser var raskest med å fullføre de ulike testene som er tilstede i DaCapotestpakken, med en stor margin. Videre ser vi fra Figur 20 at Amazon og Microsoft var nogenlunde like på de små instansene, men Azure brukte lengst tid på medium og store instanser. 57

58 Figur 20: Testresultater i sekunder. Når det kommer til kostnadene de ulike nettskytilbyderne var Google sine instanser igjen de mest økonomiske gjennom testperioden. Amazon var dyrest på den minste instansen, mens Microsoft var dyrest på både den mellomstore og den største instansen som vi ser på Figur 21. Figur 21: Testresultater i cent. På bakgrunn av den kvalitative og kvantiative evalueringen er det Google App Engine som fremstår som det mest åpenbare valget. Både prisen og ytelsen til Google sine instanser har vist seg å være svært konkurransedyktige i forhold til de andre nettskytilbyderne. Dessverre er det ikke støtte for å leie instanser med Windows fra Google sin nettsky, noe som utelukker muligheten for å programmere i et.net-miljø på serversiden. Dette vil derimot ikke bli et problem da Google har støtte for en rekke andre programmeringsspråk. 10 Kjøretidsarkitektur I kapittel 5.1 ble det satt krav til å støtte Google og Apple sine mobile operativsystemer. På bakgrunn av det vil man i dette kapittelet se nærmere på Android og ios. Dette inkluderer hvordan Xamarin kompilerer på de ulike plattformene og hvordan kjøretiden fungerer på henholdsvis Android og ios. Til slutt kommer 58

59 kapittel 10.4 Webtjeneste, hvor det blir forklart hvordan en slik tjeneste fungerer og er bygd opp Xamarin: Kompilering Selv om Xamarin gjør det mulig å utvikle applikasjoner i C#, og dele kode på tvers av flere plattformer, er den faktiske gjennomføringen på hvert system svært forskjellig. Figur 22: C# kildekoden blir en native applikasjon på ulike måter. ios - C# kompileres Ahead Of Time (AOT) til språket ARM assembly som vist i Figur 22..NET rammeverket er inkludert, men ubrukte klasser blir strippet vekk for å redusere størrelsen til applikasjonen. Siden Apple ikke tillater kjøretids kodegenerering på ios, er noen språkfunksjoner ikke tilgjengelig. Android - Her blir C# kompilert til Intermediate Language (IL) og pakket med Just-In-Time (JIT). IL er et objektorientert programmeringsspråk designet for å bli brukt av kompilatorer for.net rammeverket før en statisk/dynamisk kompilering til maskinkode [21]. Ubrukte klasser blir også her strippet vekk under linking. Applikasjonen kjører sammen med Java/Dalvik og samhandler med de native typene via Java Native Interface (JNI) Android Kjøretid består av programvare instruksjoner som kjøres når et valgt program kjører. Disse instruksjonene oversetter programvarens egen kode om til kode som datamaskinen klarer å kjøre. Derfor trenger alle programmeringsspråk et type kjøretidsmiljø som korrekt kan oversette og kjøre koden skrevet i det språket. Android bruker en virtuell maskin som sitt kjøretidsmiljø for å kunne kjøre APK filene. Det er to store fordeler med å bruke en virtuell maskin som kjøretidsmiljø. 59

60 Dette er: Applikasjonskoden er isolert fra kjernen av operativsystemet. Hvis en feil skulle oppstå i applikasjonskoden vil det derfor ikke påvirke operativsystemet. Dette isolerte miljøet vil også beskytte systemfilene til operativsystemet ved kjøring av skadelig kode. En virtuell maskin gir muligheten for krysskompatibilitet. Krysskompatibilitet er en stor fordel for utviklere da de kan utvikle applikasjonen på en datamaskin og kjøre samme kode på den mobile plattformen ved å bruke den virtuelle maskinen. Det finnes to virtuelle maskiner, Dalvik og ART, som blir brukt på Android enheter. Fra og med Android 5.0 Lollipop som ble gitt ut 3. November 2014 har Android gått vekk fra Dalvik og begynt å bruke ART som virtuell maskin. Hovedforskjellen på Dalvik og Android Runtime, ART, er kompileringsmetoden. Dalvik bruker Just-In-Time (JIT) for å kompilere applikasjonen, mens ART bruker Ahead-Of-Time (AOT) kompilering. AOT kompilerer bytekoden ved innstallasjon av applikasjonen. Dette fører til redusert bruk av prosessoren og bedre batterilevetid. Dalvik bruker en kompileringsmetode som heter JIT hvor kompilering av bytekode blir kompilert hver gang en applikasjon blir kjørt. ART tilbyr også forbedringer innen ytelse, garbage collection, applikasjonsdebugging og profilering ios Den moderne versjonen av kjøretidsmiljøet til ios-applikasjoner ble introdusert med Objective-C 2.0 og inneholder en del nye funksjoner [7]. Blant annet er instansvariabler i det moderne kjøretidsmiljøet "non-fragile". Dette betyr at om en endrer layouten til en instansvariabel i en klasse, trenger en ikke å rekompilere andre klasser som arver fra denne klassen. Programmer skrevet i Objective-C interagerer med kjøretidsmiljøet på tre forskjellige nivåer: gjennom Objective-C kode, gjennom metoder definert i NSObject klassen og gjennom direkte kall til funksjoner i kjøretidsmiljøet. Når kode som inneholder Objective-C blir kompilert, lager kompilatoren datastrukturer og funksjonskall som implementerer de dynamiske egenskapene til språket. De fleste objektene i Cocoa-rammeverket er subklasser av NSObjekt klassen og arver de metodene denne klassen definerer. Kjøretidsmiljøet er et delt og dynamisk bibliotek med et felles grensesnitt som består av en rekke funksjoner og datastrukturer lokalisert i header-filene i katalogen usr/include/objc. Mange av disse funksjonene tillater brukeren å skrive i ren C-kode for å gjenskape hva kompilatoren gjør når en skriver Objective-C kode. Andre funksjoner danner grunnlaget for funksjonalitet eksportert gjennom 60

61 metoder i NSObject klassen. Disse funksjonene gjør det mulig å endre grensesnittet til kjøretidsmiljøet og utvide utviklingsmiljøet, men de er ikke nødvendige når en programmerer i Objective-C. For å kompilere Objective-C kode blir det brukt en LLVM kompilator. LLVM bruker Clang [39] på front end for å parse kildekode til et midlertidig format. Deretter overtar kodegenerasjonslaget til LLVM over og gjør dette midlertidige formatet til maskinkode. Xcode har også støtte for å bruke en LLVM GCC kompilator, hvor GCC blir brukt på frontend for å sikre kompabilitet, mens LLVM brukes på backend Webtjeneste I kapittel 9.6 ble det konkludert med at Google App Engine var det beste valget av skytjeneste. Google App Engine støtter programmeringsspråkene Java, Python, PHP og Go [17]. En webtjeneste gjør det mulig for en klient å for eksempel endre og motta data via HTTP protokollen. Det er altså en forespørsel/svar mekanisme som muliggjør utveksling av data mellom klient og server som vist i Figur 23. Mens en vanlig nettside returnerer HTML, returnerer en webtjeneste som oftest data i XML - eller JSON-format som andre program kan forstå. Grunnen til dette er at de fleste klientrammeverkene er designet rundt bruk av JSON og XML. I testapplikasjonen, kapittel 6.2, ser man et konkret eksempel på hvordan klienten kommuniserer med webtjenesten. Applikasjonen kjører en HTTP-forespørsel mot en spesifikk adresse hvor backend koden (som f. eks henter ut og returnerer etterspurt data fra en database) ligger. Det er fordelaktig å gjøre oppgaver som krever mye ytelse på serveren. Dette sparer klienten fra å foreta tunge prosesser, som igjen fører til at applikasjonen flyter bedre for sluttbrukeren. Figur 23: Forespørsel og svar mellom en klient og en webtjeneste. Webtjenesten vil bli skrevet i Java, siden det er syntaksmessig mest likt C# noe som fører til sparte ressurser. Google App Engine vil da vite at Java sitt kjøretidsmiljø må brukes for å oversette Java koden til kode serveren klarer å kjøre. Java 7 JVM (java virtual machine) [15] er installert på Google App Engine, hvor applikasjonen blir kjørt på en isolert virtuell maskin. Se kapittel 10.2 for mer utdyping om kjøretidsmiljø og virtuelle maskiner. 61