Evaluering av tilgjengeligekryssplattformverktøy

og serverløsninger

TDT4501 - Datateknologi, fordypningsprosjekt

Per Stian HoffKent Arne BjerkeAndrzej Thingstad

Veiledet avJohn Krogstie

Høst 2014

Institutt for datateknikk og informasjonsvitenskapNorges tekniske-naturvitenskapelige universitet

Trondheim, Norway

SammendragDet finnes mange verktøy tilgjengelig for å utvikle applikasjoner for mobile operativsyste-

mer. På bakgrunn av iOS og Android sin markedsdominanse, har utviklere valgt å rette segmot disse to plattformene og bestemt at ingen av dem kan ekskluderes. For å utvikle nativeapplikasjoner 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 forskjelligeversjoner av den samme applikasjonen. Alternativet er å benytte seg av kryssplattformverk-tøy som kan bidra til å gjenbruke store deler av kodebasen og dermed spare utviklere bådetid 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 deresstyrker og svakheter. Den kvantiative evalueringen er blitt gjennomført ved ulike ytelses-tester for å vurdere ytelsen til de forskjellige verktøyene, mens den kvalitative vurderingener forankret i et sett evalueringskriterier.

Kvalitativt og kvantiativt er Xamarin det beste alternativet for å utvikle kryssplat-tformapplikasjoner på Android og iOS. Dette på bakgrunn av at verktøyet tillater å utviklenative applikasjoner gjennom C# og kan gjenbruke store deler av kodebasen på tvers avplattformer. I tillegg vil applikasjonene ha native ytelse og brukergrensesnitt.

I tillegg er det blitt undersøkt hvilken driftsarkitektur som er den mest hensiktsmessigei forhold til applikasjonen som gruppen skal utvikle som masteroppgave. Alternativene somble vurdert var Microsoft Azure, Amazon EC2, Google App Engine, GoDaddy DedikertServer og GoDaddy Privat Virtuell Server. Disse alternativene ble vurdert i forhold til enkvalitativ evaluering på bakgrunn av kriterier satt av gruppen. Videre ble en kvantiativevaluering gjennomført somm satte fokus på både ytelsen og kostnaden til de forskjelligealternativene.

Utifra denne evalueringen ble det konstatert at Google App Engine var det alternativetsom medførte de laveste kostnadene, samtidig som den leverte den beste ytelsen i forhold tilde andre alternativene.

2

Contents

1 Innledning 91.1 Bakgrunn og problem . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2 Leserguide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Bakgrunn 102.1 Applikasjonsutvikling . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.1 Webapplikasjoner . . . . . . . . . . . . . . . . . . . . . . . . 112.1.2 Hybride applikasjoner . . . . . . . . . . . . . . . . . . . . . 112.1.3 Native applikasjoner . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Plattformstatistikk . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Forskningsmetode 13

4 Valg av Kryssplattformteknologi 144.1 Kryssplattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1.1 Xamarin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2 Hybride rammeverk . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2.1 PhoneGap . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2.2 Appcelerator/Titanium . . . . . . . . . . . . . . . . . . . . . 154.2.3 Sencha Touch . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5 Evaluering av kryssplattformteknologi 165.1 Kriterier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.2 Kvalitativ Evaluering . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.2.1 Xamarin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.2.2 PhoneGap . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.2.3 Appcelerator/Titanium . . . . . . . . . . . . . . . . . . . . . 195.2.4 Sencha Touch . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.3 Diskusjon kvalitativ analyse . . . . . . . . . . . . . . . . . . . . . . 215.4 Resultater av kvalitativ evaluering . . . . . . . . . . . . . . . . . . . 235.5 Kvantitativ evaluering . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.5.1 Xamarin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.5.2 PhoneGap . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.5.3 Appcelerator/Titanium . . . . . . . . . . . . . . . . . . . . . 295.5.4 Sencha Touch . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.6 Resultat av kvantitativ evaluering . . . . . . . . . . . . . . . . . . . 315.6.1 Test 1: Henting og manipulering av store datamengder . . . 325.6.2 Test 2: Oppstartstid med store grafiske elementer . . . . . . 33

5.7 Diskusjon av kvantitativ evaluering . . . . . . . . . . . . . . . . . . 34

3

6 Testapplikasjon 346.1 Testapplikasjonen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.1.1 Skalering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.1.2 Web-forespørsler for kommunikasjon med serveren . . . . . . 366.1.3 Intern lagring på enheten . . . . . . . . . . . . . . . . . . . . 366.1.4 Ytelse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.2 Diskusjon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7 Utviklingsprosess 397.1 Kildekontroll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

7.1.1 Github . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.1.2 Team Foundation Server(TFS) . . . . . . . . . . . . . . . . . 39

7.2 IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.2.1 Xamarin Studio . . . . . . . . . . . . . . . . . . . . . . . . . 407.2.2 Visual Studio . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.3 Utviklingsprosess . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417.3.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

8 Valg av driftsarkitektur 438.1 Nettsky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

8.1.1 Microsoft Azure . . . . . . . . . . . . . . . . . . . . . . . . . 458.1.2 Google App Engine . . . . . . . . . . . . . . . . . . . . . . . 458.1.3 Amazon Elastic Compute Cloud (EC2) . . . . . . . . . . . . 45

8.2 Virtuelle private servere . . . . . . . . . . . . . . . . . . . . . . . . 458.2.1 GoDaddy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

8.3 Dedikert server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468.3.1 GoDaddy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

9 Evaluering av driftsarkitektur 479.1 Kriterier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479.2 Kvalitativ evaluering . . . . . . . . . . . . . . . . . . . . . . . . . . 48

9.2.1 Microsoft Azure . . . . . . . . . . . . . . . . . . . . . . . . . 489.2.2 Google App Engine . . . . . . . . . . . . . . . . . . . . . . . 499.2.3 Amazon Elastic Compute Cloud (EC2) . . . . . . . . . . . . 509.2.4 GoDaddy Dedikert Server . . . . . . . . . . . . . . . . . . . 509.2.5 GoDaddy Virtuelle Private Server . . . . . . . . . . . . . . . 51

9.3 Kvantiativ evaluering . . . . . . . . . . . . . . . . . . . . . . . . . . 529.4 Diskusjon av kvalitativ evaluering . . . . . . . . . . . . . . . . . . . 559.5 Diskusjon av kvantiativ evaluering . . . . . . . . . . . . . . . . . . . 569.6 Resultat av kvalitativ og kvantiativ evaluering . . . . . . . . . . . . 57

4

10 Kjøretidsarkitektur 5810.1 Xamarin: Kompilering . . . . . . . . . . . . . . . . . . . . . . . . . 5910.2 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5910.3 iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6010.4 Webtjeneste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

11 Konklusjon 62

Kilder 66

5

List of Figures

1 Ulike mobile applikasjoner . . . . . . . . . . . . . . . . . . . . . . . 112 XAML for grafisk brukergrensesnitt. . . . . . . . . . . . . . . . . . 263 Kode for å vise brukergrensesnitt. . . . . . . . . . . . . . . . . . . . 274 Kode for å hente og manipulere data. . . . . . . . . . . . . . . . . . 275 Kontrolleren til applikasjonen. . . . . . . . . . . . . . . . . . . . . . 286 HTML fil for å skrive ut json objektet. . . . . . . . . . . . . . . . . 297 Kode for test 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 Kode for test 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 Henting og manipulering av store datamengder. . . . . . . . . . . . 3210 Gjennomføring av test 1. . . . . . . . . . . . . . . . . . . . . . . . . 3211 Oppstartstid med store grafiske elementer. . . . . . . . . . . . . . . 3312 Gjennomføring av test to. . . . . . . . . . . . . . . . . . . . . . . . 3313 Kodesnutt fra ResolutionRenderer.cs. . . . . . . . . . . . . . . . . . 3514 Oppløsning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3615 Kode for henting av data fra server. . . . . . . . . . . . . . . . . . . 3616 Løsning på iOS 8 problem. . . . . . . . . . . . . . . . . . . . . . . . 3817 Testresultater for Microsoft Azure sine instanser. . . . . . . . . . . 5318 Testresultater for Amazon sine instanser. . . . . . . . . . . . . . . . 5419 Testresultater for Google App Engine sine instanser. . . . . . . . . . 5420 Testresultater i sekunder. . . . . . . . . . . . . . . . . . . . . . . . . 5821 Testresultater i cent. . . . . . . . . . . . . . . . . . . . . . . . . . . 5822 C# kildekoden blir en native applikasjon på ulike måter. . . . . . . 5923 Forespørsel og svar mellom en klient og en webtjeneste. . . . . . . . 61

6

List of Tables

1 Smarttelefon forsendelser i 2014. . . . . . . . . . . . . . . . . . . . . 122 Markedsandel til de ulike operativsystemene i 2014. . . . . . . . . . 133 Oversikt over tilgjengelige sensorer. . . . . . . . . . . . . . . . . . . 184 Resultater av kvalitativ evaluering. . . . . . . . . . . . . . . . . . . 245 Pakkeløsninger på Github. . . . . . . . . . . . . . . . . . . . . . . . 396 Pakkeløsninger for Microsoft Azure. . . . . . . . . . . . . . . . . . . 487 Pakkeløsninger for EC2 . . . . . . . . . . . . . . . . . . . . . . . . . 508 Pakkeløsninger for GoDaddy Dedikert Server. . . . . . . . . . . . . 519 Pakkeløsninger for GoDaddy Private Virtuelle Servere. . . . . . . . 5110 Beskrivelse av tester i DaCapo. . . . . . . . . . . . . . . . . . . . . 5211 Priser og konfigurasjoner for Azure [26], App Engine [16] og EC2 [1] 53

7

Ordliste

API = Application Programming InterfaceCSS = Cascading Style SheetsDOM = Document Object ModelHTML = Hypertext Markup LanguageHTTP = Hypertext Transfer ProtocolJSON = JavaScript Object NotationOS = Operating SystemSDK = Software Development KitNDK = Native Development KitUI = User InterfaceAPK = Android Application PackageIDE = Integrated Development EnvironmentIP = Internet Protocol

8

1 Innledning

Kryssplattformutvikling på mobile enheter har blitt populært gjennom de sisteårene, noe som er tydelig fra antallet kryssplattformverktøy som eksisterer. Kryssplat-tformutvikling har flere fordeler som blant annet lavere kostnader knyttet tilutvikling, da det kan utvikles en felles kodebase for de ulike plattformene app-likasjonen skal kjøre på. Dette medfører at tiden det tar for en utvikler å få enapplikasjon ut på markedet vil minske, da det ikke vil være nødvendig å utvikle toulike versjoner av den samme applikasjonen for å treffe ulike mobile plattformer.

Dette fordypningsprosjektet er forberedelse til en masteroppgave som skal ut-føres våren 2015 og som skal resultere i en applikasjon som skal kjøre på iOS og An-droid. På bakgrunn av denne masteroppgaven skal det evalueres hvilke kryssplat-tformverktøy som skal brukes til utvikling av denne applikasjonen, sammen medblant 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 ogApp Store, som et ledd i masteroppgaven som skal fullføres våren 2015. App-likasjonen er omfattende og i forbindelse med det ønsker gruppen å benytte seg avet kryssplattformverktøy for å redusere utviklingstiden. Det er ikke et alternativå utvikle i Objective-C og Java for henholdsvis iOS og Android. Dette på grunnav manglende erfaring med programmering på Androidplattformen, sammen medden 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 mu-ligheter for å utvikle brukergrensesnitt og funksjonalitet som er plattformspesi-fikke. Ytelsen på de ulike verktøyene skal testes og kvantifiseres, sammen med enkvalitativ 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 bruktsenere i rapporten

Kapittel 3: Forskningsmetode presenterer forskningsmetoden som brukes.

Kapittel 4: Valg av kryssplatformteknologi forklarer hvilke teknologier som skalbli undersøkt i rapporten, og gir en kort introduksjon til hver av de.

9

Kapittel 5: Evaluering av kryssplatformteknologi presenterer en kvalitativ vur-dering av kryssplattformsverktøyene basert på visse kriterier, og en kvantiativevaluering som inkluderer ytelsestester.

Kapittel 6: Testapplikasjon viser relevante problemer og løsninger som har kom-met frem under utvikling av testapplikasjon med valgt teknologi.

Kapittel 7: Utviklingsprosess inneholder beskrivelse av prosess og verktøy somskal brukes under utvikling.

Kapittel 8: Valg av driftsarkitektur introduserer ulike serverløsninger og forklarerhvordan de fungerer.

Kapittel 9: Evaluering av driftsarkitektur evaluerer de forskjellige serverløsnin-gene med en kvalitativ og kvantiativ vurdering.

Kapittel 10: Kjøretidsarkitektur beskriver hvordan applikasjonen blir kompilertog kjørt på de ulike plattformene.

Kapittel 11: Konklusjon konkluderer forskingen som er blitt gjort og foreslårvidere arbeid.

2 Bakgrunn

Det finnes mange verktøy tilgjengelig for utviklere som ønsker å utvikle kryssplat-tform 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å uliketeknologier.

2.1 Applikasjonsutvikling

Mobile applikasjoner kan utvikles som en webapplikasjon, hybrid applikasjon ellernative applikasjon. Native applikasjoner på Android blir skrevet i Java, mens iOSapplikasjoner blir skrevet i Objective-C. Native utvikling er kostbart, men tillaterfor raskere applikasjoner. For å utvikle native applikasjoner kan også verktøy somXamarin benyttes. Xamarin lager applikasjoner i C# som blir kompilert native tilbåde Android og iOS. Utvikling av applikasjoner med webteknologier som HTML5,CSS og JavaScript reduserer ytelsen, men har til gjengjeld andre fordeler som lavkost, lav læringskurve og lav vedlikeholdskostnad.

10

(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 app-likasjoner på.

2.1.1 Webapplikasjoner

Nettsider som er tilpasset mobilskjermer kalles webapplikasjoner. Disse app-likasjonene er avhengig av å kjøres i en nettleser. For å utvikle slike responsivenettsider kan rammeverk som jQuery Mobile eller Bootstrap benyttes.

Fordeler:

• Webapplikasjoner er tilgjengelig for alle enheter som har en nettleser in-stallert. Dette gjør at tilgjengeligheten til applikasjonen er høy og det erikke behov for å laste ned applikasjonen fra for eksempel App Store ellerGoogle Play.

Ulemper:

• Webapplikasjoner har ikke mulighet til å benytte seg av native funksjonalitetog krever internett for å fungere.

2.1.2 Hybride applikasjoner

Hybride applikasjoner er nettsider som blir pakket i en native beholder. Dennebeholderen gir applikasjonen tilgang til native funksjonalitet via plugins. For åutvikle hybride applikasjoner kan teknologi som PhoneGap benyttes.

11

Fordeler:

• Hybride applikasjoner utvikles ved hjelp av webteknologi og kompileres tilde forskjellige plattformene. Dette gjør vedlikehold og videreutvikling avapplikasjonen enkelt, da det kun er en kodebase som må oppdateres. Hybrideapplikasjoner gir også mulighet til å benytte seg av native funksjonalitet.

Ulemper:

• Applikasjoner med mange grafiske elementer kan føre til dårlig ytelse.

2.1.3 Native applikasjoner

Programmeringsspråk og utviklingsmiljø er bestemt av hvilken plattform app-likasjonen blir utviklet til. Native applikasjoner har full tilgang til maskinvarenog brukergrensesnittet er gjengitt av plattformens SDK.

Fordeler:

• Native applikasjoner utnytter telefonens kapasitet og kan kjøres uavhengigav nettverkstilgang.

Ulemper:

• Ved vedlikehold og videreutvikling av applikasjonen må koden bli oppdatertfor alle plattformene. Native applikasjonsutvikling er kostbart og tidskrevende.

2.2 Plattformstatistikk

Bakgrunnen for å utvikle applikasjonen på forholdsvis iOS og Android er på grunnav den sterke markedsdominansen disse to plattformene er i besittelse av [4].

Tabell 1: Smarttelefon forsendelser i 2014.

Global Smartphone Operating SystemShipments (Millions of Units)

Q3’13 Q3’14

Android 205.9 268.0iOS 33.8 39.3Microsoft 10.3 10.5BlackBerry 2.5 2.3Others 0.4 0.3Total 252.9 320.4

Tabell 2 viser at det er Android som er markedsleder med en økning i marked-sandel fra 81.4% i 2013 til 83.6% i 2014. Denne økningen kom på bekostningav alle de andre plattformene. iOS mistet en prosent av markedsandelen til An-droid, men dette er hovedsaklig knyttet til fraværet av Apple og iOS i det billigeresmarttelefonsegmentet hvor Android dominerer[4]. Windows Phone opplevde en

12

nedgang fra 4.1% til 3.3%, selv med en moderat økning i forsendelser fra 10.3 til10.5 millioner enhter som vist i Tabell 1. På dette tidspunktet anser ikke gruppendet som nødvendig å støtte noen andre plattformer enn iOS og Android. Dette påbakgrunn av den lave markedsandelen til de konkurrerende plattformene, sammenmed den lave etterspørselen.

Tabell 2: Markedsandel til de ulike operativsystemene i 2014.

Global Smartphone Operating SystemMarketshare (%)

Q3’13 Q3’14

Android 81.4 83.6iOS 13.4 12.3Microsoft 4.1 3.3BlackBerry 1.0 0.7Others 0.2 0.1Total 100 100

3 Forskningsmetode

For å avgjøre hvilke kryssplattformverktøy som egner seg best for masteroppgaven,ble det gjennomført en kvalitativ og kvantitativ studie. Den kvalitative studientok for seg et sett med kriterier som de mest aktuelle verktøyene skulle sammen-lignes mot, mens den kvantitative studien bestod primært av et testoppsett somskulle sammenligne ytelsen på ulike testapplikasjoner som ble utviklet med disseverktøyene.

Den kvalitative studien baserer seg på et sett med kriterier som de ulike verk-tøyene skal evalueres opp mot. Disse kriteriene er valgt ut på bakgrunn av ap-plikasjonen som skal utvikles som masteroppgave og skal bidra til å evaluere demest kritiske delene av verktøyene. Videre vil de viktige egenskapene hos de ulikeverktøyene bli forklart og sammenlignet.

Et viktig punkt for applikasjonen som skal utvikles er ytelse. I den kvantiativestudien vil ytelsen til de forskjellige verktøyene bli målt ved å utvikle forskjelligetestapplikasjoner som skal gjennomgå noen utvalgte tester. Disse testene skal ikkevæ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 skaldet være mulig å konkludere med hvilke kryssplattformverktøy som har den besteytelsen.

Til slutt vil det bli utviklet en testapplikasjon med det valgte kryssplattfor-mverktø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 dennetestapplikasjonen utføre et sett med funksjoner som er viktige for applikasjonensom skal utvikles til masteroppgaven. Denne testapplikasjonen vil vise verktøyetsin egnethet til utvikling.

13

For å avgjøre hvilken driftsarkitektur som skal brukes er det blitt gjennomførten kvalitativ og kvantitativ vurdering på lik linje som med kryssplattformverk-tøyene. Den kvalitative studien baserte seg på et sett kriterier som vurderte deulike driftsarkitekturene opp mot hverandre, mens den kvantitative studien vur-derte 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 enomfattende forståelse av de ulike kryssplattformverktøyene, sammen med de ulikedriftsarkitekturene.

4 Valg av Kryssplattformteknologi

Litteraturstudiet til masteroppgaven "Cross-platform development - evaluation"of available solutions[24] konkluderte med at de topp seks hybride rammeverkeneer PhoneGap, Titanium, Rhodos, DragonRad, MoSync og Sencha Touch basertpå 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 disseverktøyene har til felles er at de alle benytter seg av webteknologi for å utviklehybride applikasjoner. Xamarin vil også blir vurdert som et motstykke til dehybride teknologiene, hvor man utvikler native applikasjoner i C# og fremdelesfår delt mye av kodebasen.

4.1 Kryssplattform

Da mobile applikasjoner først kom, innebar utvikling av iOS applikasjoner pro-grammering i Objective-C gjennom Xcode, mens Android applikasjoner måtteutvikles i Java. Hele prosessen måtte gjentas med helt ny kodebase dersom ap-plikasjonen skulle lages for flere plattformer. Med kryssplattformutvikling er detmulig å 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 å utvikleflere forskjellige applikasjoner spesifikt for flere plattformer. Dette bidrar også tilat utviklingstiden blir redusert. Videre har mange av verktøyene for å utviklekryssplattform applikasjonene en lav læringskurve da de baserer seg på alleredekjente webteknologier som CSS, HTML og JavaScript.

Ulemper med kryssplattformutvikling er blant annet om et mobilt operativsys-tem blir oppdatert med funksjonalitet som er plattformavhengig, må applikasjonenbli utviklet med separat kode for den gitte funksjonaliteten. Videre kan det værevanskelig å tilby en native brukeropplevelse på kryssplattformapplikasjoner medmindre verktøyet du utvikler applikasjonen med støtter dette eksplisitt.

14

4.1.1 Xamarin

Xamarin gjør det mulig å utvikle native mobile applikasjoner i C#, et kraftfulltog moderne programmeringsspråk. Med en delt kodebase for alle plattformer, sominneholder 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øytgjenbruk av kode, men samtidig slipper å gjøre kompromisser når det kommer tilbrukergrensesnittet.

Xamarin gjør også, som eneste kryssplatformteknologi, det mulig å arbeide iVisual 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.

4.2.1 PhoneGap

I 2008 ble det utviklet en metode som gjorde det mulig å utvikle applikasjoner vedbruk av HTML, CSS og Javascript. Denne metoden utnyttet at alle mobiltelefonertillater en instans av en nettleser. Nettleser kan kommunisere med brukergrens-esnittet ved hjelp av native kode. JavaScript i applikasjonen, plug-ins, kan kallenative kode som gir applikasjonen tilgang til telefonspesifikke funksjoner. Eksem-pler på slike funksjoner kan være kamera, gyroskop m.m. Denne metoden ble kjentsom 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, Windows8, Ubuntu og Firefox OS.

4.2.2 Appcelerator/Titanium

Appcelerator Titanium er en open source løsning for utvikling av applikasjonermed webteknologi. Titanium gjør det mulig å utvikle applikasjonene ved hjelp avHTML, CSS og JavaScript. De har også utviklet et rammeverk, Alloy, som skalgjøre det lettere å lage applikasjoner. Alloy er et rammeverk laget av Appceleratorsom er spesialdesignet for Titanium SDK. Den baserer seg på arkitektureren model-view-controller(MVC).

• Støttede platformer: iOS, Android, Windows Phone og BlackBerry [46].

15

4.2.3 Sencha Touch

Sencha Touch er et HTML5 basert rammeverk for å utvikle webapplikasjoner somser ut som om de er blitt utviklet native ved å tilby flere grafiske elementertilsvarende de du finner på blant annet Android og iOS. Applikasjoner utvikletmed Sencha kan blir brukt sammen med Cordova eller PhoneGap, og dermedpakke applikasjonen inn i en native container som gir den tilgang til API’er somer 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 basertpå et sett med utvalgte kriterier. Disse kriteriene er satt opp med tanke på app-likasjonen som skal utvikles ved et senere tidspunkt.

5.1 Kriterier

Støttede plattformer. Rammeverkene/teknologiene må støtte så mange mobileplattformer som mulig. Det er satt krav til at teknologien må støtte Android ogiOS.

Native funksjonalitet. Teknologien må støtte native funksjonalitet for hver plat-tform.

Pris. På bakgrunn av et begrenset budsjett er pris en viktig faktor i valg avkryssplattformteknologi.

Dokumentasjon og support. Rammeverkene/teknologiene burde være godt doku-mentert og det skal være enkelt å finne informasjon på internett når en harspørsmål eller problemer som en trenger å belyse.

Levbarhet. Levbarheten til teknologien er viktig. Det må hele tiden videreutviklesog 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 tilteknologiene. Målet er å finne den teknologien som er den beste å bruke forutvikling av masteroppgaven.

16

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, Win-dows Phone og Mac. Dette sørger for at en kan bruke det samme språket, desamme API’ene og den samme strukturen for hver plattform som applikasjonenblir 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 blirutviklet med native brukergrensesnitt elementer for den plattformen det utviklesfor. Det tilbys også aksess til native API’er og native ytelse som bidrar til atapplikasjoner 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 kom-mer 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 delerav kodebasen på tvers av flere plattformer og det er mulig å skrive applikasjoneri C# som er et språk med høy popularitet verden over og med et stort økosystemrundt 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 medutvikling, men også hvordan ulik funksjonalitet skal implementeres i Xamarin.Videre har Xamarin en Component-Store hvor det er mulig å finne en haug medulike komponenter som kan implementeres inn i ulike Xamarin-applikasjoner. Hvemsom helst kan utvikle disse komponentene og selv om noen av dem koster et parkroner er mesteparten av de gratis. Personer kan også skrive ønsker til hvilke kom-ponenter de mener mangler på plattformen, slik at andre utviklere kan utvikle dissekomponentene. 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å Xam-arin 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å brukereXamarin 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 Xamarinpå StackOverflow som er en Q&A side for programvareutviklere gir over 12 000resultater, noe som tyder på at utviklere benytter seg av produktet og at det er etbredt 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 supportavdeling som lover svar innen kort tid [52].

Til forskjell fra PhoneGap er Xamarin kun gratis for studenter. De tilbyr riktignok en Starter Edition som er gratis, men denne versjonen har en øvre grense forhvor stor applikasjonen som blir utviklet kan være samtidig som den er strippetfor mange funksjoner som Xamarin tilbyr. Videre har de ulike versjoner som

17

støtter flere og flere funksjoner, men disse kommer selvfølgelig med en pris. Indie-versjonen starter på 25$ i måneden, etterfulgt av Business på 83$ i måneden og tilslutt en Enterprise-editon på 158$ i måneden [50].

5.2.2 PhoneGap

PhoneGap er en open source løsning for å lage hybrid kryssplattform applikasjoner [36].Applikasjonene blir utviklet ved hjelp av standard webteknologi som inkludererHTML, JavaScript og CSS. PhoneGap støtter de fleste sensorer som finnes i mod-erne mobiltelefoner ved hjelp av plugins(se Tabell 3)

Tabell 3: Oversikt over tilgjengelige sensorer.

iPhone / iPhone 3G iPhone 3GS og nyere Android Windows Phone 8Akselerometer Ja Ja Ja JaKamera Ja Ja Ja JaKompass Nei Ja Ja JaKontakter Ja Ja Ja JaFiler Ja Ja Ja JaGeolokasjon Ja Ja Ja JaMedia Ja Ja Ja JaNettverk Ja Ja Ja JaNotifikasjon(lyd) Ja Ja Ja JaNotifikasjon(vibrasjon) Ja Ja Ja JaLagring 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 op-pdatert 18 plugins som er utviklet av PhoneGap. Det er også utviklet 220 pluginsav 3. parts utviklere [37]. Dette er en indikator på at plugins blir kontinuerligutviklet for å støtte ny funksjonalitet.

PhoneGap støtter mange forskjellige plattformer. På bakgrunn av at PhoneGapapplikasjoner kjører i et WebView(nettleser) er det enkelt å legge inn støtte for nyeplattformer. Det som er mest tidkrevende ved å legge til støtte for nye plattformerer plugins. Disse må lages spesifikt for plattformen slik at native funksjonalitetkan benyttes.

Plattformer PhoneGap støtter:

• Android

• iOS

• BlackBerry

• Windows Phone

• Windows 8

18

• Ubuntu

• Firefox OS

• Amazon-fireos

Dokumentasjonen til PhoneGap er strukturert på en bra måte. Det finnes fleretutorials både på PhoneGap sine sider og på youtube. Ved behov for ytterligereinformasjon er det enkelt å finne relevant informasjon på internett. Et søk etterPhoneGap på stackoverflow [34], 10 oktober 2014, ga 50 733 resultater. Dette tyderpå at teknologien er godt brukt og det er enkelt å finne løsninger på eventuelleproblemer.

Phonegap er gratis, uten noen restriksjoner. Dette har bidratt til høy popular-itet og mange utviklede applikasjoner. På bakgrunn av dette er det ingen grunn tilat videreutviklingen og oppdateringer av PhoneGap skal bli dårligere i overskueligfremtid.

PhoneGap tilbyr ikke support, men det finnes bibliotek som kan benyttes medPhoneGap som tilbyr support. Eksempler på slike bibliotek er jQuery [22].

5.2.3 Appcelerator/Titanium

Titanium er et rammeverk for å bygge native apps, og har noen likheter medf. eks PhoneGap. Begge er teknologier som gjør det mulig med kryssplattformmobilutvikling, og krever bruk av JavaScript. Både Titanium og PhoneGap eropen 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å å "writeonce, run everywhere". Titanium handler om kodegjenbruk, de har tro på at deter store funksjoner på tvers av flere plattformer som utviklere bør bruke for å økebrukeropplevelsen. Og derfor burde native apps dra nytte av kjente native UI wid-gets 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 kodevil dermed eksistere for å gi best mulig brukeropplevelse, men samtidig slipperutviklere å lære plattformspesifikke API’er for å f. eks tegne et rektangel, ellergjøre en HTTP-forespørsel. Man utvikler altså native apps med JavaScript. Ti-tanium kan derfor sammenlignes med Xamarin. Begge gjør det mulig å utviklenative apps med høy kodegjenbruk, men i forskjellige språk, henholdsvis C# ogJavaScript.

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" eren demoapplikasjon laget av Appcelerator for å vise de forskjellige funksjonenesom er tilgjengelig ved bruk av Titanium. Et søk etter “Appcelerator Titanium”på stackoverflow [33], 11 obtober 2014, ga kun 1 903 resultater. Dette tyder på

19

at teknologien ikke er like mye brukt som for eksempel PhonGap og Xamarin.Det er også vanskeligere å finne informasjon om eventuelle problemer grunnet liteinformasjon 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øremot cloud tjenestene.

5.2.4 Sencha Touch

Sencha Touch er et HTML5 basert rammeverk som inneholder et JavaScript bib-liotek spesielt utviklet for mobile webapplikasjoner. På denne måten er det muligå utvikle applikasjoner med brukergrensesnitt som ser og tildels føles native. Sensaer basert på veletablerte webstandarder som HTML5, CSS og JavaScript. Ram-meverket kommer med et stort antall predefinerte layouter som hjelper til medå plassere UI-elementer på skjermen, samtidig som CSS brukes for fleksiblitet ogposisjonering for å oppdatere UI raskt. Fordelen med dette er at rammeverkettar seg av designet responsivt. Responsivt design vil si at det du ser vil endreseg etter størrelsen på skjermen du bruker. Dette er spesielt hensiktsmessig nårorienteringen på enheten blir forandret til og fra landskapsmodus. Man vil oftestfinne en layout som passer med applikasjonen en ønsker å utvikle, dersom det ikkeer tilfelle tillater Sencha utviklere å bygge sine egne layouts.

Sencha er et tungt objektorientert rammeverk og har et av det mest avanserteklassesystemet av samtlige JavaScript-bibliotekene tilgjengelig. Annet enn å barevære et verktøy, bidrar klassesystemet til pent strukturert applikasjonsutvikling.Mye av funksjonaliteten er basert på abstraksjon som bidrar til at utviklere kanopprette egendefinerte komponenter, plugins eller utvidet funksjonalitet ved hjelpav ulike designmønstre.

Plattformer som Sencha Touch støtter er blant annet Android, iOS, WindowsPhone, 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 3900$ 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 omfat-tende og hjelper nye utviklere med å implementere og forstå nye komponenter ogkonsepter ved Sencha Touch. Videre har de også videoer med tutorials for å viseutviklere hvordan de selv kan implementere ulike funksjonaliteter med Sencha. Dehar også et svært levedyktig forum hvor Sencha sine utviklere er tilstede, samtidigsom rammeverket er svært diskutert på internett. Et søk etter "Sencha" på stack-overflow [35], 11 obtober 2014, ga 12 503 resultater.Dette er noen av pekepinnenepå at Sencha ikke kommer til å forsvinne helt med det første. Som med Titanium,så er support kun inkludert i den betalte versjonen.

20

5.3 Diskusjon kvalitativ analyse

Xamarin står øyeblikkelig frem som et solid alternativ når det kommer til funksjon-alitet som er native for plattformen det skal utvikles på. Utvikler en iOS app-likasjoner så vil man med Xamarin ha tilgang til Xcode sin GUI-builder som sørgerfor at en blant annet har tilgang til alle UI-elementene som er tilgjengelig på iOS-plattformen. Videre har Xamarin native API’er for plattformspesifikk funksjon-alitet som blant annet Game Center, In App Purchase, iAd, NewsStand og mer.For Android er det mulig å utvikle all funksjonalitet og GUI direkte gjennom Xa-marin sin IDE eller ved bruk av Visual Studio. I motsetning til f. eks. Sencha ogPhoneGap så kompileres en Xamarin app til en native binary, istedenfor å tolkes.Denne native kompileringen skal gi brukerne bedre app ytelse for de mer krevendescenarioene. Xamarin hevder at applikasjonene [53] har langt raskere oppstart-stid, og som kjører like raskt som om man utvikler en app i Java på Android elleri Objective-C/Swift på IOS.

UI-elementene som blir brukt med blant annet Sencha, PhoneGap og Appcel-erator Titanium kan virke som de er native, men er ikke det. De benytter seg avCSS for å emulere en native utseendet og følelse. Dermed vil applikasjoner utvikletmed disse teknologiene være avhengig av å oppdateres når nye os versjoner blirlansert, da nye os versjoner ofte kommer med nye retningslinjer for hvordan app-likasjoner skal se ut. Da må en enten endre på CSS’en selv for å matche de nyeUI-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 tilde respektive app storene godkjenner applikasjonen. På Android kan det ta etpar timer, mens med iOS kan det ta en uke. Med Xamarin vil ikke dette være etproblem da de benytter seg av native UI-elementer og det vil være os versjonensom 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 ren-deringsmotoren på plattformen. Mens den Webkit-baserte renderingsmotoren påiOS gir god ytelse, er android sin nettvisning funksjonell, men har noen be-merkelsesverdige begrensninger. Blant annet er det ikke lett å fange opp hendelsergenerert av visningen. På andre plattformer kan ytelsen på nettvisningen væreavhengig av OS versjonen. Det finnes også en del problemer knyttet til nettleseresom 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 nettlesereforbedres hele tiden, noe som vil bidra til å redusere disse problemene. Men åkomme nærmere native kvalitet og ytelse i brukergrensesnittene er ikke en trivielloppgave. 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

rammeverk så avansert som Sencha Touch. Spørsmålet blir, er nettleserne godenok til å møte våre behov? Dette skal undersøkes nærmere under den kvantativeevalueringen.

Alle teknologiene oppfyller minstekravet som er satt til å støtte Android ogiOS enheter. Titanium, PhoneGap og Sencha Touch støtter også en rekke mindreoperativsystemer som for eksempel Tizen og BlackBerry. Xamarin støtter kun detre store operativsystemene Android, iOS og Windows Phone. Dette på bakgrunnav at brukergrensesnittet og API’ene blir portet native og ikke med webteknologisom de andre teknologiene bruker.

Sencha Touch er gratis for hvem som helst å bruke, men er begrenset med tankepå funksjonalitet og verktøy som er tilgjengelig. Skal man ha tilgang til de mangeverktøyene som Sencha tilbyr for applikasjonsutvikling med HTML5, så er manavhengig 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 appvisuelt.

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 funksjonalitetog verktøy som følger med. Det kommer for eksempel ikke med en egen IDE tilPhoneGap. Utvikleren må derfor laste ned en separat teksteditor for å utvikleapplikasjoner. Det finnes mange biblioteker man kan laste ned og benyttet segav sammen med PhoneGap. Appcelerator Titanium er gratis å bruke og kommerogså med en del ekstra som blant annet en IDE ved navn Titanium Studio og etMVC rammeverk. De har også en innebygget skytjeneste som er gratis for opp til250 000 API kall per dag, med et tak på 5 millioner API kall i måneden, sammenmed 20 GB. Det er mulig å betale for å få noe som heter Appcelerator Studiosom er en oppgradert IDE i forhold til gratisversjonen. En vil også få tilgang tilprofesjonell support og tilleggsfunksjonaliteter til rammeverket.

Xamarin har en gratis evalueringsversjon som hvem som helst kan laste ned ogprøve. Denne versjonen er strippet for funksjonalitet og har en begrensning påhvor stor applikasjonen som skal utvikles kan være. Denne begrensningen bidrartil 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 ermuligheter for å få tak i en studentversjon som innehar like mye funksjonalitet som

22

Business-versjonen gratis. Dette innebærer at en er i stand til å fremvise gyldigstudentbevis.

En utviklingsplatform må ha god dokumentasjon som viser funksjonaliteten ogkapasiteten til teknologien. Det må være enkelt for utviklere å søke på informasjonog finne løsninger på internett. Alle teknologiene vi har sett på har hatt oversiktligesider med god informasjon. Det har også vært tilgang til forum hvor brukerne kanskrive eller svare på spørsmål. Appcelerator sin side er den siden som utpekte segsom dårligst med tanke på dokumentasjon. Det var vanskelig å finne informasjonom pris og eksempler på kode. Xamarin, Sencha Touch og PhoneGap har godesider med både kodeeksempler og brukerveiledninger. Support er et annet aspektsom ikke må undervurdes når man skal utvikle med relativt nye teknologier. Xa-marin har 24/7 gratis support for de som har business-versjonen, som inkludererstudenter.

Det er viktig med teknologi som videreutvikler seg og gir støtte for ny funksjon-alitet som kommer i nye mobile enhetene. Sikkerhet er også en viktig faktor når detkommer til levbarhet. Hvis teknologien ikke oppdateres kan applikasjonen væreutsatt for nye sikkerhetshull og feil. De store selskapene som Facebook og Googlehar gått vekk fra kryssplatform web-applikasjoner til native applikasjoner [18]. Iet innlegg fra programvareutvikleren Jonathan Dann som jobber for facebook stårdet: "One of the biggest advantages we’ve gained from building on native iOS hasbeen the ability to make the app fast" [53].

Selv om det viser seg at flere større teknologiselskaper satser mer på native app-likasjoner vil ikke nødvendigvis utvikling av HTML5 baserte applikasjoner kommetil å forsvinne. En grunn til at webbasert applikasjonsutvikling ble populært varblant annet at utviklere ikke ønsket å lage og vedlikeholde flere kodebaser for ulikeplattformer. Dette resulterte ikke nødvendigvis i en bedre brukeropplevelse forbrukeren av applikasjonen, men det sparte utviklere både tid og penger. Xam-arin sin tilnærming til kryssplattformutvikling er spennende da det er mulig å delesvært mye kode over flere plattformer, samtidig som ytelsen og funksjonalitetentil applikasjonen som blir utviklet er native. Flere og flere utviklere har begyntå bruke Xamarin for å utvikle kryssplatform applikasjoner og nylig har Microsoftannonsert at Visual Studio skal bli gratis, samtidig som den skal få støtte ut avboksen for Xamarin Starter Edition [9]. Dette indikerer at Xamarin har en bety-delig 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 ikriteriene beskrevet i kapittel 5.1.

Poeng basert på hvor godt rammeverket oppfyllerer kriteriene:• Høyt: 3• Medium: 2

23

• Lavt: 1

• Ikke: 0

Tabell 4: Resultater av kvalitativ evaluering.

Kriterier Xamarin PhoneGap Sencha Touch Appcelerator/ TitaniumNative funksjonalitet 3 2 2 2Støttede platformer 2 3 3 3Pris 3* 3 1 2Dokumentasjon 3 3 3 1Support 3 1 2 2Levbarhet 3 3 3 3Totalt 17 15 14 13

* Business edition er gratis for studenter.

Native funksjonalitet. Under punktet native funksjonalitet har vi tenkt på bådebrukergrensesnitt og enhetens spesifikke funksjonaliteter som for eksempel kam-era, kompass, GPS osv. Alle teknologiene støtter bruken av enhetenes innebygdesensorer og spesifikasjoner, men kun Xamarin støtter native brukergrensesnitt.

Støttede platformer. Alle rammeverkene/teknologiene støtter de nødvendige plat-tformene som er blitt beskrevet i den kvalitative analysen. Xamarin støtter tilgjengjeld ikke like mange plattformer som de HMLT5-baserte rammeverkene. Dettepå grunn av at HTML5-rammeverkene kan kjøres i nettleseren kontra Xamarin somkjører som en native applikasjon.

Pris. Xamarin er gratis å bruke for studenter ved framvisning av gyldig student-bevis. I tillegg har Xamarin en gratis evalueringsversjon som en kan bruke forå teste ut rammeverket, men denne versjonen kommer med en begrensing somsørger for at en ikke kan kompilere applikasjoner over en viss størrelse. Appceler-ator Titanium har en gratisversjon som har en IDE med begrenset funksjonalitetog et begrenset antall API kall til nettskyen. Med betalingsversjonen får man itillegg en IDE med utvidet funksjonalitet og support. PhoneGap og Sencha kom-mer i gratisversjoner, men man kan også kjøpe versjoner av Sencha med utvidetfunksjonalitet og support.

Dokumentasjon. Alle teknologiene har egne forum hvor man kan legge inn spørsmålog lete etter svar. Dokumentasjonen på hjemmesidene til PhoneGap, Xamarin ogSencha er også godt strukturert og rik på informasjon. Titanium skiller seg ut hermed dårligere informasjon på nettsiden, samt mindre aktivitet på f. eks stackover-flow.

24

Support. Ikke alle teknologiene tilbyr support. Sencha Touch og Appcelera-tor/Titanium tilbyr support ved betaling. Dette betyr at utvikleren må kjøpeen pakkeløsning for å kunne benytte seg av support funksjonen. Xamarin tilbyrsupport for Business, som inkluderer studenter og Enterprise edition. PhoneGaper den eneste teknologien som ikke tilbyr support.

Levbarhet. Det er ingenting som tilsier at noen av rammeverkene vil forsvinne iden nærmeste fremtid.

Basert på evalueringen er det ikke mye som skiller de ulike HTML5 baserteverktøyene fra hverandre. Xamarin stiller særdeles sterkt på bakgrunn av nativefunksjonalitet, pris, support og mange muligheter når det kommer til tilleggs-funksjonalitet. På bakgrunn av den kvalitative evalueringen kan vi konkluderemed at Xamarin er det beste alternativet.

5.5 Kvantitativ evaluering

Gruppen har valgt å teste de aktuelle teknologiene med ytelsesmålinger: Tidenregistreres før en oppgave skal utføres og etter den er ferdig for å se hvor lang tidutføringen tok. Ved slike ytelsesmålinger er det svært viktig med likt testmiljø forde ulike teknologiene. Testene er derfor utført på samme nettverk med følgendeenhet:

• 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 dannerførsteinntrykket. Det finnes flere teknologier som har et så avansert oppsett at deter 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 app-likasjonen hente ut en JSON-fil på 12 MB og prosessere, lagre og skrive ut data fradenne i brukergrensesnittet. JSON-filen blir hentet fra en server som er satt opplokalt. På bakgrunn av at JSON-filen ikke ligger i applikasjonen, men blir hentetfra en server er det viktig å kjøre testen mange ganger for å oppnå et påliteligresultat. Informasjonen som skal velges fra JSON-filen og printes ut på skjermenbestår av 6100 linjer med tekst.

25

Test 2: Oppstartstid med store grafiske elementer. I test to skal applikasjonensoppstartstid testes. Når applikasjonen er lastet inn vil det bli printet ut et bildepå 1 MB 30 ganger etter hverandre. Når alle bildene er printet ut på skjermen blirtidtakingen stoppet.

Testene er valgt ut for å sjekke hvordan teknologiene gjør det på de områdenesom er viktige med tanke på den kommende masteroppgaven: Henting av data fraen webtjeneste, visning av mye informasjon, oppstartstid og bildelasting.

5.5.1 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 Studioinstallert, måtte filstien til de nye komponentene som ble installert eksplisitt blispesifisert. Visual Studio(2012) ->Tools->Xamarin for så å bla opp filstien tilAndroid SDK og Android NDK.

Deretter må det opprettes et Android prosjekt som vil opprette en filstruktur forprosjektet som resulterer i en applikasjon med teksten "Hello World". Oppsettetav Xamarin.iOS var helt likt, men for å kunne utvikle i Visual Studio på Windowsmå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 Studiopå en Windows maskin.

Utvikling og implementering av test 1. Først lages en enkel LinearLayout i XAMLsom kan inneholde mange ulike visninger(se Figur 2). Siden inneholdet skal leggestil 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

Figur 3: Kode for å vise brukergrensesnitt.

På Figuren 3 blir en LinearLayout og en knapp generert ved oppstart som harhendelsen 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 GetRe-sponse() hvor data mottas i JSON-format fra web-tjenesten. Videre velges deninformasjonen JSON-objektene som skal vises. Til slutt lages et TextView somblir lagt til i LinaerLayout objektet for å bli synlig på skjermen. Koden er vist iFigur 4.

Utvikling og implementering av test 2. Ved denne testen skal applikasjonen kunvise 30 bilder. Disse vises ved å lage et ImageView for hvert bilde. Dette må gjørespå alle 30 bildevisningene. For å finne ut hvor lang tid det tar fra oppstart til allebildene er blitt lastet opp til minnet og vist frem til skjermen bruker vi .NET sinProcess klasse som kan hente ut start tiden til prosessen.

27

5.5.2 PhoneGap

Oppsett av PhoneGap. PhoneGap kan lastes ned og installeres ved å bruke NodeJSsin pakkebehandler. NodeJS er et miljø laget i JavaScript som ofte blir brukt tilserver-side og nettverksapplikasjoner. Etter installasjon av NodeJS kan man skrive"npm install -g phonegap" i kommandolinjen. Dette resulterer i at PhoneGap blirlastet ned og installert på datamaskinen. For å lage et nytt prosjekt kan mannå skrive "phonegap create new-app" i kommandolinjen. Da vil det bli laget enprosjektmappe som inneholder alle nødvendige filer for å kjøre applikasjonen.

For å kjøre applikasjonen på en Android enhet må Android sin software devel-opment kit (SDK) lastes ned. Etter installasjon av SDK’en må både "bin" mappentil 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å enMac. Fremgangsmåten er ellers lik, som ved bygging og kjøring av et Androidprosjekt.

Utvikling og implementering av test 1. For å kunne teste PhoneGap ble det lastetned AngularJS. AngularJS ble benyttet for å få en god struktur på applikasjonen,samt ha en god måte å manipulere JSON-objekt. På Figur 5 blir kontrollerentil applikasjonen laget. Funksjonen getContent() blir kalt når en knapp i bruk-ergrensesnittet blir trykket på. Deretter blir det gjort et kall mot serveren etterJSON-filen. Når applikasjonen får en response fra serveren blir objektet lagt i envariabel som heter "events".

Figur 5: Kontrolleren til applikasjonen.

Funksjonen startTimer() blir kalt rett etter at getContent() funksjonen er startet.

28

For å stoppe klokka blir det kalt en funksjon stopTimer() etter at HTML-kodener laget og printet.

Brukergrensesnittet blir enkelt laget ved hjelp av HTML. AngularJS gjør detmulig å skrive ut alle elementene i events variabelen ved hjelp av ng-repeat, seFigur 6 under.

Figur 6: HTML fil for å skrive ut json objektet.

Utvikling og implementering av test 2. Test 2 ble laget for å kunne teste opp-startstiden og hvordan PhoneGap behandler mange store grafiske elementer. Vedå fjerne all unødvendig funksjonalitet kunne vi teste applikasjonen under perfekteforhold.

5.5.3 Appcelerator/Titanium

Oppsett av Appcelerator/Titanium. Tilsvarende som PhoneGap, bare at instal-lasjonsfilen hentes fra Appcelerator sine sider [5]. Kjøringen av installasjonsfilenresulterer i Titanium Studio, hvor man kan opprette prosjekter og begynne åutvikle. For å lage en iOS applikasjon trenger man å installere Titanium Studiopå en Mac.

Utvikling og implementering av test 1. På Figur 7 vises doClick() funksjonen somblir kjørt ved at knappen i brukergrensesnittet blir trykt på. Her blir en HTTP-klient først opprettet ved å bruke Titanium sitt bibliotek. Siden resultatet avwebforespørselen er et JSON-objekt må responsteksten parses. Til slutt kjøres tofor-løkker for å hente ut og vise frem ønsket informasjon fra JSON-objektet.

29

Figur 7: Kode for test 1.

Utvikling og implementering av test 2. Det grafiske i Titanium kan utvikles iAlloy 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.

5.5.4 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øresi nettleseren og er en guide på hvordan Sencha Touch blir installert. For å kunnekjø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 iWindows sin kommandolinje. Ruby må også installeres på maskinen før utviklingav applikasjoner kan starte. Ruby er et dynamisk programmeringspråk som haråpen kildekode. Når Ruby er lastet ned og installert på datamaskinen er SenchaTouch ferdig installert.

Ved kjøring og bygging av applikasjonene i Sencha blir det vist en feilmeldingi kommandolinjen. Denne feilmeldingen sier at Sencha ikke klarer å kjøre en bak-grunnsprosess. Bakgrunnsprosessen som ikke blir kjørt i Sencha Cmd v5.0.3.324er Sass sin kompilator. For å kunne bygge prosjektet må derfor Sass-kompilatorenslå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 FileNot Found Exception". Derfor måtte filen lastes ned fra en annen nettside. Detvar vanskelig å finne en fungerende guide som viste hvordan applikasjonsmappen

30

skulle bli generert til en apk-fil. Etter mye feiling med å integrere Sencha SDKTool 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 somresultat. For å vise innholdet i brukergrensesnittet blir resultatet manipulert ogønsket informasjon hentet ut. Deretter blir informasjonen skrevet ut i en tekstbokspå 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 ibrukergrensesnittet. For å teste applikasjonen under best mulige forhold slettet viunødvendig funksjonalitet.

5.6 Resultat av kvantitativ evaluering

Resultatene av ytelsestestingen er presentert i en graf. Skjermbilder av de forskjel-lige testene er også satt sammen forå vise hvordan testene fungerte og hvor liktdet var på hver plattform.

31

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 skrivesut. I Figur 9 under er resultatet vist i millisekunder. Resultatet ble regnet utved å 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 fikkdårligst resultat med en gjennomsnittlig kjøretid på 15 197,1 ms, mens Sencha fikket resultat på 12 249,2ms og Titanium et resultat på 9 159.4 ms.

Figur 9: Henting og manipulering av store datamengder.

I Figur 10 under er resultatene etter en gjennomføring med de forskjelligeteknologiene.

Figur 10: Gjennomføring av test 1.

32

5.6.2 Test 2: Oppstartstid med store grafiske elementer

I den andre testen er det fokus på hvor godt teknologiene behandler store grafiskeelementer. 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 applikasjon-sstart og stoppet når alle grafiske elementer hadde blitt skrevet ut på skjermen. IFigur 11 under er resultatet vist i millisekunder. Resultatet ble regnet ut ved åkjøre applikasjonen 100 ganger for så å ta gjennomsnittet av kjøretiden. Xamarinkommer også i denne testen best ut med et resultat på 1 512,1 ms. PhoneGap (2324,7 ms), Sencha Touch (2 352 ms) og Titanium (2 361 ms) får alle en kjøretidpå rundt 2 300 ms.

Figur 11: Oppstartstid med store grafiske elementer.

I Figur 12 under er resultatene etter en gjennomføring med de forskjelligeteknologiene.

Figur 12: Gjennomføring av test to.

33

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 ty-delig tendens, spesielt i test en, at Xamarin og Titanium som kompilerer til nativekode er raskere enn hybrid løsningene. Titanium viste seg å ha veldig mye over-head, testapplikasjonene ble store i motsetning til de andre teknologiene. Testap-plikasjonen ble 7.3 MB med Xamarin og hele 22.3 MB med Titanium. Resultateneer entydige på at Xamarin utfører oppgavene raskest. Man merker det også påbrukeropplevelsen, ved å for eksempel skrolle i visninger som inneholder mye tekstat applikasjonene flyter bedre.

Da Xamarin har kommet seirende ut både på den kvalitative og kvantitativeevalueringen 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 kvantiativeevalueringen, var det neste steget å utvikle en applikasjon for å undersøke viktigfunksjonalitet i bibliotekene som følger med Xamarin. Dette for å kvalitetssikre atdet 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 plat-tformene, 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 tilAndroid.

• 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 medkode 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 mas-teroppgave må kunne lagre data på enheten, slik at noe av funksjonalitetenvil fungere uten internett tilgang.

34

• Webforespørsler for kommunikasjon med serveren – For å lese og skrive datatil 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 godpekepinne på hvordan Xamarin håndterer animasjoner, prosessortunge beregningerog flyt i brukergrensesnittet.

6.1.1 Skalering

Ved å lage en ResolutionRenderer klasse med en bestemt virtuelle bredde og høydepå 2560x1440 for så å ta inn enhetens egentlig oppløsing var det mulig å regne utstø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 å brukebilder og animasjoner i forhold til den høyeste oppløsningen, for så å skalere ne-dover for enheter med lavere oppløsning enn motsatt for å unngå et pikslete bruk-ergrensesnitt.

35

(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øs-ninger og aspect ratio.

6.1.2 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 avdata samt skriving av data liggende på serveren, var det lite kode som trengtesfor databehandlingen. Det er PHP-scriptene som tar seg av all funksjonalitetsom er knyttet opp mot databasen, som f. eks å kjøre SQL spørringer. .Net haren HttpWebRequest klasse som innehar all funksjonalitet som trengs for å gjørewebforespø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 hvilkenmetode som skal benyttes. Request.Timeout bestemmer hvor lang tid det maksi-malt kan ta før det kastes en WebException. Vi mottar en respons for så å lukketilkoblingen.

6.1.3 Intern lagring på enheten

Å finne en måte å lagre filer og databaser på som funker på begge plattformene harstore fordeler med tanke på å spare tid og antall kodelinjer. Dette medfører mindre

36

kodebase å vedlikeholde. Gjennom Xamarin har man tilgang til System.IO sominneholder en del klasser som tilsammen utgjør Isolated Storage. IsolatedStorage-File har metoden GetUserStoreForApplication som finner filstien til hvor appenhar 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 etStreamReader objekt.

Ved å benytte seg av Isolated Storage og strømmer er det mulig å lagre bådefiler og databaser. Ved opplastning av mobile applikasjoner til App Store harApple en vurdering av applikasjonen før den slippes ut.

Resultat av anmeldelsen var at applikasjonen ble avvist. Dette på grunn av enfeil ved at applikasjonen kræsjer ved oppstart. Ved disse tilfellene sender applemed en krasjrapport. Krasjrapporten inneholdt veldig mye informasjon som detvar vanskelig å få noe fornuftig ut av. Det som ved første øyekast virket interessantvar en feilmelding som het: “EXC_CRASH (SIGABRT)”. Et raskt søk sa følgendeom en SIGABRT: “SIGABRT errors are caused by your program aborting due toa 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å ikketilgang til en filsti som brukes, og eneste plassen i Wire Loop hvor det kunnevære var FileManageren hvor IsolatedStorage ble brukt. Unntaket ble kastet nårIsolatedStorageFile.GetUserStoreForApplication kjørte. Selv om dette forklartehvor problemet oppsto, var det fortsatt uforståelig hvorfor det skjedde når Appletestet appen. Dette oppstod ikke ved tidligere testing av applikasjonen på reelleenheter(både iOS 7 og iOS 8). IsolatedStorage finnes i mscorlib.dll som kommermed Xamarin og er derfor deres ansvarsområde. Etter en rask mail til Xamarinsupport visste det seg at dette problemet nettopp hadde blitt oppdaget.

I feilrapporten som var opprettet av Xamarin kom det også frem at dette kunskjedde på iOS 8, og på enheter som ikke var blitt brukt til utvikling. Detteforklarte hvorfor probelemet ikke oppstod under testing. Neste spørsmål somdukket opp var hva som var annerledes med filplasseringer på iOS 7 og 8. Applehar lagt ut et teknisk notat om dette med følgende forklaring.

“iOS 8 splits the data of an application from the application bundle. Code whichattempts to derive the path to the Documents or Library directories will return aninvalid path on iOS 8. Attempting to access this path will fail, and may terminateyour app” [6].

Løsningen på problemet kan sees i Figur 16

37

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 applikasjonenoperativsystemet om å få plasseringen til katologen “dokumenter”. Wire Looppasserte så testprosessen og ble tilgjengelig i App Store.

6.1.4 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 Androidog iOS. Applikasjonen lå i stabilt på 60 frames per second. Dette førte til atapplikasjonen kjørtes uten forsinkelser.

6.2 Diskusjon

Testapplikasjonen delte omkring 90% av kodebasen mellom iOS - og Android-plattformen. Håndtering av webforespørsler og skalering viste seg å ikke væreutfordrende i forhold til muligheten for å lagre data internt på enheten. Dettemåtte gjøres på to forskjellige måter grunnet Apple sin nylige oppdatering fra iOS7 til iOS 8. Det ble brukt plattformspesifikke klasser for iOS som NSFileManagerog UIDevice, noe som resulterte i to forskjellige versjoner av klassen FileManager.Denne klassen kunne dermed ikke lengre være lokalisert i PCL prosjektet, men bleistedenfor implementert plattformspesifikt for de to aktuelle plattformene.

Dette er en av ulempene med å utvikle kryssplattformapplikasjoner med Xam-arin. Ved større systemoppdateringer på iOS eller Android er det en mulighet forat noe av funksjonaliteten i Xamarin sine biblioteker ikke fungerer lenger. Dermedmå utviklere vente på at Xamarin oppdaterer de bibliotekene som er berørt, noesom kan føre til forsinkelser. Hadde applikasjonen blitt utviklet i Objective-C foriOS, ville en løsning vært tilgjengelig fra Apple samme dag som lanseringen av op-erativsystemet. Dette problemet ble riktignok løst i dette tilfellet ved at Xamarinraskt svarte på henvendelser og hadde en midlertidig løsning klar.

Gjennom utvikling av testappliksjonen ble det bekreftet at:

38

• Man ender opp med en applikasjon hvor mesteparten av kodebasen kan kjørespå både iOS og Android.

• Applikasjonen som ble uviklet setter høye krav til FPS. Dette kravet bleinnfridd.

• Visual Studio viste seg å være en god IDE for utvikling av mobile app-likasjoner.

• God support. Det fantes både et aktiv forum og en egen supportavdeling somsvarte raskt på eventuelle problemer som oppstod.

7 Utviklingsprosess

Prosess og verktøy som støtter opp under utviklingsprosessen blir beskrevet i dettekapittelet.

7.1 Kildekontroll7.1.1 Github

Github tilbyr tilgang til kode som er lagret eksternt på en server. Det tilbysogså mange egenskaper som gjør det lettere å sammarbeide med andre. Disseegenskapene er wikis, oppgave behandling, feilrapportering og deling av kode [11].Github tilbyr i hovedsak offentlige lagring av kode. Dette betyr at andre kanfå 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 privateoppbevaringssteder på github, se Tabell 5. Github tillater integrasjon av tredjepartprogramvare. Dette gir muligheten til å velge egen programvare til de forskjelligeegenskapene git har. Et eksempel på et slikt tredjeparts program kan være KDiff3som 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 UnlimitedPublic repositories Unlimited Unlimited Unlimited Unlimited UnlimitedPrivate repositories 0 5 10 20 50

7.1.2 Team Foundation Server(TFS)

TFS er hovedsakelig laget for Microsoft Visual Studio. Det er alikevell mulighetertil å implementere TFS i Eclipse ved hjelp av plugins [28]. Github og TFS har

39

mye av den samme funksjonaliteten og gjør det lettere å dele kode i form av opp-gavebehandlig, deling av kode, sammensetting av kode fra forskjellige kilder medmer. TFS tilbyr også testing og administrasjonsfunksjoner for utgivelse av pro-gramvare. Administrasjonsfunksjonene for utgivelse av programvare ble integrerti 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 VisualStudio, 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å utvikleremed programvareutvikling. Den består som regel av en teksteditor, verktøy for åbygge en programvareløsning og en debugger. Nyere IDE’er tilbyr også mulighetenfor kodefullføring. På bakgrunn av den kvalitative og kvantiative evalueringen ikapittel 5, ble det fastslått at verktøyet som skulle brukes under utvikling varXamarin. Dette begrenser alternativene for hvilke IDE’er som kan brukes daXamarin, foruten å komme med sin egen IDE, kun har støtte for å bruke VisualStudio.

7.2.1 Xamarin Studio

Xamarin Studio er en IDE for mobil kryssplattformutvikling som kommer medXamarin, og sørger for at det er mulig å utvikle applikasjoner for iOS, Androidog Mac. Den kommer med kodefullføring, muligheten for å få utvidet informasjonom koden og refaktorering. Videre inkluderer den en designer for utvikling avbrukergrensesnitt, uten å skrive det i XML. Ved hjelp av integrasjon med Xcode,kan en også utvikle brukergrensesnitt for iOS enheter. Noen av funksjonene tilXamarin 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 bib-lioteker direkte i applikasjoner.

• Uvikle brukergrensenitt i Android uten bruk av XML.

• Pakke og distribuere applikasjonene til Google Play, App Store og WindowsStore.

40

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 WindowsPresentation Foundation-applikasjoner, nettsider, webapplikasjoner og webtjen-ester. Visual Studio støtter alle språkene i .NET-plattformen til Microsoft. VisualStudio sørger for å lette på programmeringsbyrden til utviklere ved å tilby in-nebygde 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 tilbyekstra 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 vedbruk 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 somtilslutt ender opp med et ferdig resultat. Hovedpoenget med prosessen er sterktkorrelert med det faktum at alle kravene til programvare som skal utvikles ikkebestandig er kjent på forhånd. Derfor må disse kravene skaffes underveis og sys-temet blir levert i inkrementer, hvor hvert inkrement realiserer en del av systemetsfunksjonalitet. Hvert inkrement vil inneholde en samling av krav, analyse, design,implementasjon og testing. Brukerne får dermed presentert håndfaste resultatertidlig i prosessen og kan gi tilbakemelding om systemet tilfredstiller forventningene.

Et synonym som har blitt brukt for å beskrive denne utviklingsprosessen ersmidig utvikling [19]. Det finnes flere forskjellige prosessrammeverk som tar i brukprinsippene bak smidig utvikling, men det mest populære [32] blir kalt Scrum. Dagruppen har mest erfaring med nettopp Scrum, samt at det er en veldokumentertog utprøvd prosess er det nettopp den valget faller på.

41

7.3.1 Scrum

Scrum er en iterativ, inkrementell utviklingsmodell, som betyr at utvikling foregåri iterasjoner og utvalgte deler av systemet utvikles for hver iterasjon. En slikiterasjon 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å forlang tid før tilbakemelding blir gitt fra brukere og andre interessenter. Er en sprintfor kort, vil ikke teamet rekke å gjøre nyttig arbeid. Derfor er 14 dager den mestvanlige varigheten for en sprint.

Product backlog er en liste over hva som skal gjennomføres i utvikling av pros-jektet og tar utgangspunkt i de sentrale use casene for prosjektet. Product back-logen er inndelt i det som kalles "stories" eller historier, og sorteres etter viktighet,lengde, avhengigheter osv. Alle disse faktorene er med på å gi en verdiestimer-ing, som viser rekkefølgen over hvilke historier som bør prioriteres først i de ulikesprintene.

Sprintkø lages som et utdrag fra product backlogen. Man velger ut noen histo-rier fra product backlogen og bryter disse ned i mindre oppgaver som Scrum-teametskal gjennomføre i løpet av den aktuelle sprinten.

Hver sprint starter med et planleggingsmøte. Møtet brukes for å velge krav ogfunksjonalitet som finnes i product backlogen, som teamet mener de kan omgjøretil leveringsklar funksjonalitet i løpet av sprinten sin varighet.

Et daglig Scrum-møte holdes under hver sprint. På møtet forteller Scrummedlemmene hva de fikk gjort i går, hva skal de gjøre i dag og er det noen hin-dringer som kan oppstå.

I slutten av hver sprint gjennomførers et demonstrasjonsmøte hvor gruppemedlemmenedemonstrerer funksjonalitet som er blitt utviklet under sprinten. Etter endt demon-strasjonsmøte, gjennomføres det et evalueringsmøte. Møtet starter opp med at allemedlemmene besvarer to spørsmål:"Hva fungerer bra i sprinten? Hva kan forbere-des til neste sprint?". Dette for å evaluere hvordan neste sprint kan bli bedre ogta med seg videre hva som gikk bra.

En av fordelene med Scrum er blant annet muligheten for å minimere risikoen iet utviklingsprosjekt og raskt håndtere endringer, ved at det utvikles funksjonaliteti korte sprinter. Dette bidrar med tilbakemeldinger fra brukere og kan forhindrefeil 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 Studioog Visual Studio, er det mulig å benytte seg av innebygde verktøy for å håndtereScrum. For å lage, administrere og endre product backlogen tilbyr Visual Studiofunksjonalitet for dette gjennom TFS [27]]. Andre verktøy som kan benyttes erJIRA. Dette verktøyet gir muligheten for å lage product backlog, fordele arbeid-soppgaver og generere burndown charts [8]

42

8 Valg av driftsarkitektur

Valg av serverløsning er viktig for å sikre god ytelse, lave kostnader og minstmulig vedlikeholding. I dette kapittelet kommer beskrivelser av serverløsningervalgt basert på popularitet.

8.1 Nettsky

Databehandling i nettskyen er i hovedsak lagring og bruk av programmer og datasom ikke ligger lokalt på en datamaskin, men som er tilgjengelig over internett.Skyen er kun en metafor for internett. Med databehandling i nettskyen er detmulig at flere brukere deler ressurser som er tilgjengelig seg imellom. Alle brukerekan benytte seg av en applikasjon og trenger ikke å vite at både applikasjonenog dataene den besitter ligger flere tidssoner unna og at det er hundre - kanskjetusenvis 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 tilutviklere eller systemadminsitratorer.

• Platform as a Service (PaaS): Tilbyr en utviklings - og distribusjonsplattformi 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 underliggendevirtuelle maskinen oppstår. Denne tjenesten er nyttig hvis instansen har enoffentlig IP-adresse.

• Automatisk skalering. En av de viktigste prinsippene med en skytjeneste erat 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 inettskyen hvor applikasjoner kan kjøres. Skytjenesten tilbyr også automatisk ska-lering over virtuelle maskiner basert på kundemengden, automatisk deteksjon avfeil og gjennoppretting, sikkerhet og automatisk oppdatering av operativsystem.

Leverandører som tilbyr PaaS øker stadig. To av de mest kjente leverandørendeav PaaS er:

• Google App Engine tilbyr et utviklingsmiljø for Python, Java, Ruby og GO.Google styrer distribusjonen og kjører koden.

43

• Microsoft Azure tilbyr et operativsystem og en utviklingsplatform for å ak-sessere/utvikle applikasjoner på Microsoft sine datasenter. Azure tilbyr etutviklingsmiljø for applikasjoner som kjøres på Windows med .Net. Azurehar også et databasesenter som automatisk lagrer kopier av din database.

Software as a Service (SaaS). Software as a Service er en distribusjonsmodell derprogrammer er tilbydd av en tjensteleverandør og gjort tilgjengelig for kunden.SaaS bidrar til at organisasjoner kan få tilgang til funksjonalitet til en kostnadsom vanligvis er mindre enn hva lisensierte applikasjoner koster. På bakgrunn avat programvaren ligger eksternt trenger ikke kunden å investere i maskinvare somstøtter applikasjonene som skal brukes.

Fordeler:

• Med databehandling i nettskyen finnes muligheten til å fokusere mer påkjernevirksomheten til bedriften fremfor å fokusere på å administrere ulikedatasentre. På denne måten frigjør en ressurser som kan brukes til blantannet å utvikle programvare som har en forretningsverdi for bedriften. Ved åutnytte IaaS, er man istand til å raskt bygge ut ny infrastruktur for å støttenye applikasjoner. Forutsatt at applikasjonen er bygd på en hensiktsmessigmå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 nyoppstartedebedrifter med begrensede budsjetter. Det benyttes en pay-as-you-go (PAYG)betalingsmodell som innebærer at man betaler for den størrelsen og ytelsendet er behov for til enhver tid.

• Om en av skyserverne skulle bli utilgjengelig på bakgrunn av systemkrasj ellerlignende er det en enkel oppgave å starte opp en ny server instans og fortsettemed å 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 verdifullbedriftsdata være kompromittert. I ly av de nylige NSA avsløringene i USA,så har blant annet Michael Redding, administrerende direktør i AccentureTechnology Labs, uttalt følgende: "Because large cloud computing companieshave more resources, he says, they are often able to offer levels of securityan average small business may not be able to afford implementing on its ownservers" [47].

44

• Det er ikke mulig å endre operativsystem eller selv velge hvilket programmer-ingsspråk som skal benyttes under utvikling av applikasjoner i nettskyen. Vedbehov for et annet operativsystem eller programmeringsspråk må det leies enny instans fra en skytjeneste som støtter det.

8.1.1 Microsoft Azure

Microsoft Azure er en plattform som er utviklet av Microsoft. Den tilbyr bådePaaS - og IaaS-tjenester og støtter en rekke forskjellige programmeringsspråk,rammeverk og verktøy som bidrar til at en kan bygge, distribuere og administreresine applikasjoner og tjenester på Microsoft sine servere.

8.1.2 Google App Engine

Google App Engine er en PaaS for å utvikle og drifte web-applikasjoner på Googlesin 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 belast-ning og med store mengder data. Applikasjoner kjører i et sandboxed miljø som ersikkert og som tillater App Engine å distribuere forespørsler på tvers over mangeservere for å hjelpe til med skalerbarheten når det er behov for det.

8.1.3 Amazon Elastic Compute Cloud (EC2)

Amazon Elastic Compute Cloud er en del av Amazon sin cloud computing plat-tform kalt Amazon web Services. EC2 tillater brukere å kjøre sine applikasjonerpå virtuelle maskiner og bidrar til at det er mulig med en skalerbar distribusjonav applikasjoner ved at brukere kan starte og avslutte nye serverinstanser når deser behov for det.

8.2 Virtuelle private servere

En virtuell privat server, VPS, har mange av de samme egenskapene en dedikertserver har. Det er en plass for å legge kjørbar kode som må være tilgjengelighele 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 serverer en hel server dedikert til ditt nettsted eller din applikasjon. VPS er en isolertpartisjon 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 blirpåvirket av andre servere som kjører på primærserveren.

Fordeler

• Virtuelle private servere er ikke like kostbare som en dedikert server.

45

• Mange VPS pakkeløsninger kan bli tilpasset applikasjonens behov.

• Pakkeløsningene kan oppgraderes ved behov. Det er mulig å starte med enliten pakkeløsning med minimum tilgjengelige ressurser og oppgradere etter-som 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.

8.2.1 GoDaddy

GoDaddy tilbyr mye av de samme funksjonalitetene på VPS som de gjør på dededikerte serverne. Det finnes alikevell forskjeller. Lagringskapasiteten til deforskjellige 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 avspesifikasjonene på de virtuelle private serverne er noe dårligere enn de dedikerteserverne.

8.3 Dedikert server

Selv om nettskytjenester har vokst betydelig de siste par årene, så debatteres detfremdeles hvorvidt en skal benytte seg av det fremfor dedikerte servere. Dedikerteservere er den tradisjonelle måten å hoste på hvor en bruker kjøper eller leier enserver hos en leverandør og betaler for de ressursene serveren har tilgjengelig.

Fordeler

• Har man et scenario hvor ressursbehovet er mer eller mindre konstant, vildet 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 typetjeneste vil være raskere enn en server som kjører flere ulike programmer.Hvor den dedikerte serveren vinner på ytelse, vil den derimot tape terrengnår det kommer til effektivitet.

• Med en dedikert server vil en ha full kontroll på hvordan serveren skal kon-figureres. Valg av operativsystem, lagringsalternativer, CPU, RAM og bånd-bredde bidrar til at en server kan tilpasses i det uendelige i forhold til kravenesom blir stilt av applikasjonen eller tjeneste som skal hostes.

46

Ulemper

• En dedikert server kan koste fra hundre til tusenvis av kroner hver månedavhengig av hvilken konfigurasjon som velges. Disse månedlige avgiftenepå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 utgangspunk-tet ikke har behov for. Dette er den største grunnen til at mange velgervirtualiserte alternativer, da det der vanskelig å få utnyttet alle tilgjengeligeressurser i et dedikert miljø.

• Muligheten for å skalere ressurser på en dedikert server har en sterk kor-relasjon 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, ogkomplisert og tidskrevende å gjennomføre.

• Ved vedlikehold og drift av en dedikert server er det nødvendig med forkunnskapermed tanke på blant annet IP routing og ulike servermekanismer. Om en ikkebesitter 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øresigjen. I slike tilfeller vil en gjennopprettingsplan være nødvendig for å sparetid og penger, men dette kommer selvfølgelig med en betydelig kostnad påden eksisterende løsningen.

8.3.1 GoDaddy

Godaddy tilbyr dedikerte servere hvor man selv kan velge forhåndslagde pakkermed forskjellige spesifikasjoner. Serverne kan bli brukt til en rekke formål ogikke bare hosting for nettsider. Eksempler på dette kan være spilling, virtuellhosting eller delt hosting, back-end server-services m.m. Godaddy gir brukerenadministrasjonstillgang 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 fremtil hvilken serverløsning som skal brukes.

9.1 Kriterier

Oppetid. Det er viktig at tjenesten er tilgjengelig hele tiden. Derfor er det sattet krav til en oppetid på 99%.

47

Skalerbarhet. Det er viktig at arkitekturen tilbyr høy fleksiblitet når det kommertil skalerbarhet. Det må være mulig å skalere antall serverinstanser opp og nedavhengig av ressursbehov.

Pris. På bakgrunn av et begrenset budsjett er pris en viktig faktor i valg avdriftsarkitektur.

Språk. Arkitekturen skal ha støtte for de vanligste programmeringsspråkene, slikat det ikke skal være nødvendig å bruke tid og ressurser på å lære ny teknologi.

9.2 Kvalitativ evaluering9.2.1 Microsoft Azure

Tabell 6: Pakkeløsninger for Microsoft Azure.

Instans Kjerner RAM Lagring Pris [kr/m]A0 0 0.75 GB 19 GB 86,04A1 1 1.75 GB 224 GB 344,15A2 2 3.50 GB 489 GB 682,57A3 4 7 GB 999 GB 1 365,13A4 8 14 GB 2039 GB 2 730,25A5 2 14 GB 489 GB 1 491,31A6 4 28 GB 999 GB 3 028,51A7 8 56 GB 2039 GB 6 016,86A8 8 56 GB 1777 GB 10 456,37A9 16 112 GB 1777 GB 20 912,73

Azure bekrefter på sine sider at de har en oppetid på 99,99% [29], noe som tilsvarerrundt 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 oppgrader-ingsdomener. Når en ønsker å oppdatere en eller flere rolle instanser så vil Azureoppdatere de i forhold til hvilke oppgraderingsdomener de tilhører. Azure stop-per alle instanser i et gitt oppgraderingsdomene, oppdaterer de, bringer de onlineigjen, for deretter å fortsette til neste oppgraderingsdomene. Ved å stoppe kunde instansene som kjører i det gitte oppgraderingsdomenet kan Azure sørge for aten oppdatering har minst mulig innvirkning på tjenesten som driftes. MicrosoftAzure gjør det også mulig å programmere i .Net, Java, Python og Ruby.

Azure tilbyr muligheten for brukere å skalere applikasjonen som ligger i nettskyeni 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 ap-plikasjonen kjører i Azure, kjører rollene som rolleinstanser, hvor en rolleinstans

48

er en virtuell maskin. Brukeren kan selv spesifisere hvor mange rolleinstanser ved-kommende ønsker for hver rolle. Desto flere rolleinstanser, desto mer ytelse harman tilgjengelig, men det vil samtidig koste mer. Dette kalles å skalere ut. Azuretilbyr også muligheten for å skalere opp ved å øke størrelsen på rolleinstansene tilå tilby flere kjerner, RAM og diskstørrelse per rolleinstans istedenfor å legge tilflere små rolleinstanser.

Både størrelsen og antallet instanser per rolle kan man bestemme selv når enførst deployer en applikasjon til Azure. En kan også legge til og fjerne rolleinstansersamtidig som applikasjonen kjører, enten gjennom en web-portal eller gjennomprogrammering. Ved å ha muligheten til å legge til og fjerne rolleinstanser mensapplikasjonen kjører, kan en balansere ytelsen i forhold til driftskostnadene. Enkan legge til instanser når behovet er høyt og fjerne dem når behovet ikke lengerer tilstede.

Microsoft sin skytjeneste Azure har ti ulike løsningspakker som brukerne kanvelge mellom, se Tabell 6. Disse løsningspakkene varierer fra små skytjenester medlite ram og lagring til kraftigere skytjenester for prosessering av store mengder data.

9.2.2 Google App Engine

Google App Engine opererer med en oppetid på 99.95%, noe som tilsvarer rundt4,38 timer i året. Her er det viktig å bemerke seg at Google opererer med spesiellebetingelser i sin Service Level Agreement som sier at all nedetid som ikke over-skrider fem minutter med kontinuerlig nedetid, ikke teller mot den totale nedetidentil applikasjonen. Dermed vil man ikke få økonomisk godtgjørelse på bakgrunn avdenne 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 imple-mentert som en App Engine applikasjon. Verktøyet spør periodisk alle ComputeEngine instanser for status [14]. Avhengig av applikasjonen, så kan denne statusenvære belastning på CPU, minnebruk eller hvor mange oppgaver som venter på å bligjort. Basert på brukerdefinerte kriterier, starter rammeverket opp nye instanserom 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 gjen-nomsittlig 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ærmingeneer 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 ogGO.

Google App Engine tilbyr en omfattende mengde ulike konfigurasjoner og er åfinne på Google sine hjemmesider [16].

49

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%, menfremdeles over 99%. All nedetid under 99% blir gjort opp med 30% godtgjørelsepå den månedlige fakturaen [2].

Som med både Azure og Google App Engine er det mulig å skalere opp ellerned instanser med Amazon ved behov. Med Auto Scaling oppretter en samling avEC2 instanser som kalles Auto Scaling Groups. Disse gruppene kan opprettes frabunnen 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 ellereliminere EC2 instanser innenfor den gruppa [3].

Med Auto Scaling kan applikasjoner bli mer feiltolerante ved at den oppdagernå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 brukeulike subnett og tilgjengelighetssoner. Dermed hvis et subnet eller en sone er util-gjengelig, kan Auto Scaling opprette nye instanser i et annet subnet eller tilgjen-gelighetssone 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 somer laget for både mindre og større applikasjoner. Amazon EC2 tilbyr også mangeandre pakker som er spesiallaget for den enkelte applikasjonen. Dette kan væreapplikasjoner som trenger en rask prosessor, mye lagringsplass eller for eksempelmye RAM.

Tabell 7: Pakkeløsninger for EC2

Instans RAM Lagring Pris [ $/time]t2.micro 1 GB Kun EBS 0.015t2.small 2 GB Kun EBS 0.030t2.medium 4 GB Kun EBS 0.060m3.medium 3.75 GB 1 x 4 GB SSD 0.083m3.large 7.5 GB 1 x 32 GB SSD 0.166m3.xlarge 15 GB 2 x 40 GB SSD 0.332m3.xlarge 30 GB 2 x 80 GB SSD 0.665

9.2.4 GoDaddy Dedikert Server

GoDaddy sine dedikerte servere garanterer en oppetid på 99,9%. Dette tilsvarer8,76 timer i året [12]. Ved bruk av inntrengingsbeskyttelse som beskytter serverenfra DDoS og andre angrep fra eksterne kilder klarer GoDaddy å opprettholdeoppetiden på 99,9%. GoDaddy opererer også med brannmur som sikrer angrep

50

mot serveren. Vedlikehold av sikkerheten blir gjort av fagpersonell som jobber forGodaddy. Det er enkelt å laste opp ny kode til GoDaddy ved bruk av for eksempelFTP, 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ørreløsningspakke hos GoDaddy når som helst. Et problem med dette er at man ikkekan velge helt fritt hva man skal oppgradere. Det er for eksempel ikke mulig å kunoppgradere prosessoren Det er kun mulig å velge mellom en av pakkeløsningene tilGoDaddy, se Tabell 8. Hver pakke inneholder en dedikert server med forskjelligespesifikasjoner. 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,04Deluxe Intel Core i5 - 4 kjerner 8 GB 2 x 1 TB 10 TB 344,15Premium Intel Core i7 - 4 kjerner 16 GB 2 x 2 TB 20 TB 682,57Verditilbud Intel Core i5 - 4 kjerner 4 GB 2 x 300 GB 10 TB 1 365,13Kraftbruker Intel Core i7 - 4 kjerner 8 GB 2 x 1 TB 15 TB 2 730,25Minnemonster Intel Core i5 - 4 kjerner 32 GB 2 x 1 TB 15 TB 1 491,31

9.2.5 GoDaddy Virtuelle Private Server

GoDaddy sine virtuelle private servere har også en oppetid på 99,9%. På grunnlagav at det også her er GoDaddy som eier de virtuelle private serverne er egen-skapene, sikkerheten og vedlikeholdet likt som på de dedikerte serverne til Go-Daddy. En forskjell på de virtuelle private serverne og de dedikerte servernetil GoDaddy er pris og spesifikasjonene på de forhåndslagde løsningspakkene, seTabell 9 for VPS løsningspakker. På grunn av at de virtuelle private serverne erisolerte vil de ikke bli påvirket av andre servere på primærserveren, se kapittel 5.4for mer informasjon om virtuelle private servere. Dette gjør at serveren vil ha enjevn 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,99Verdi 2 TB 2 GB 60 GB 296,99Deluxe 3 TB 3 GB 90 GB 445,99Premium 4 TB 4 GB 120 GB 593,99Ultimat 8 TB 8 GB 240 GB 1 112,99

51

9.3 Kvantiativ evaluering

For å vurdere ytelsen til Microsoft Azure, Amazon EC2 og Google App Engine bledet brukt tester som ble utført av Peter Wayner i februar 2014 [48]. Peter Waynerer en medvirkende redaktør hos InfoWorld, teknolog og forfatter.

Ytelsen ble vurdert ved å bruke en open source testpakke som går under navnetDaCapo [38]. DaCapo inneholder et sett med ulike open source programmer somstresser maskinvare på ulike aspekter. Noen programmer vil stresse CPU, andrevil stresse RAM og enkelte vil stresse begge deler. Dette sørger for allsidighet sidendet 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 Tabell10:

Tabell 10: Beskrivelse av tester i DaCapo.

Avrora Simulerer en rekke programmer som kjøres på et rutenett av AVRmikrokontrollere

Batik Produserer en rekke SVG bilder basert på enhetstestene i ApacheBatik

Eclipse Utfører noen av JDT ytelsestestene for Eclipse IDEFOP Tar utgangspunkt i en XSL-FO-fil, analyserer og formaterer den,

før den genererer en PDF-filH2 Utfører en rekke transaksjoner mot en modell av en bankapp-

likasjonJython Tolker en Python-test kalt pybenchLuindex Bruker Lucene for å indeksere et sett med tekstdokumenterLusearch Foretar et tekstsøk over et sett med dokumenterPMD Analyserer et sett med Java-klasser etter en rekke kidlekodeprob-

lemerSunflow Renderer et sett med bilder ved hjelp av strålesporingTomcat Foretar et sett spørringer mot en Tomcat server, for så å hente og

verifisere de resulterende nettsideneTradebeans Kjører ytelsestesten Daytrader via JavaBeans på en GERONIMO

backend som inneholder en in-memory H2 database.Tradesoap Kjører ytelsestesten Daytrader via SOAP på en GERONIMO

backend som inneholder en in-memory H2 databaseXalan Forvandler XML dokumenter til HTML

Det ble testet tre forskjellige Linux instanser fra hver av de ulike skyene. Disse erikke en perfekt sammenligning, men de er omtrent like i forhold til konfigurasjon ogpris. Den eneste forskjellen fra testen som ble gjort i februar 2014 og til november2014 var at prisene på de ulike maskinvarekonfigurasjonene har blitt endret. Detteer også blitt tatt hensyn til i resultatene når det kommer til kostnader. De ulikeinstansene er beskrevet i Tabell 11:

52

Tabell 11: Priser og konfigurasjoner for Azure [26], App Engine [16] og EC2 [1]

Navn Antall kjerner RAM [GB] Pris [ $/time]Amazon m3.medium 1 3.75 0,070Amazon c3.large 2 3.75 0,105Amazon m3.2xlarge 8 30 0,560Google n1-standard-1 1 3.75 0,049Google n1-highcpu-2 2 1.8 0,061Google n1-standard-8 8 30 0,385Microsoft Azure a1 1 1.75 0,047Microsoft Azure a2 2 3.5 0,094Microsoft Azure a4 8 14 0,376

Det ble samlet sammen to sett av data fra hver instans. Det ene settet inneholdtdata om hvor raskt instansen fullførte benchmarken fra en kaldstart. Dermedmåtte instansen bli startet, koden måtte bli lastet opp for deretter å bli kjørt. Detandre settet inneholdt tall fra en alternativt start, som kjører benchmarken helttil konsistense resultater fremkommer.

Figurene 17, 18 og 19 viser resultatene av de ulike testene. Rød farge viserdårligst tid/kost av samtlige instanser, blå viser hverken dårligst eller best, grønnviser best tid/kost av samtlige instanser. Tiden er målt i sekunder og kosten er icent:

Figur 17: Testresultater for Microsoft Azure sine instanser.

53

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 deter mulig å gjenkjenne når vi sammenligner instanser fra de ulike tilbyderne medhverandre:

54

• På de små instansene var Google raskest på 12 av 13 tester, Azure var ikkeraskest på noen, mens Amazon kun var raskest på Tradesoaptesten.

• På de mellomstore instansene var Amazon raskest på 7 av 13 tester, Googlevar 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 varraskest på Lusearchtesten, mens Azure var raskest på Avroratesten.

• Totalt brukte Google minst tid på å utføre alle testene på de tre ulike in-stansene, 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å, mel-lomstore og store instansene.

• Google sin n1-highcpu 2 fullførte testene mest økonomisk av alle de ulikekonfigurasjonene, mens Azure a4 kostet mest.

En ting som er verdt å bemerke seg er at når en leier en instans hos skytjen-estene, så deler du en liten del av en større maskin med mange andre. Dette betyrat det er en mulighet for at andre brukere kan påvirke ytelsen din og dette kanendre seg fra dag til dag. Andre aspekter som en la merke til er at større ogdyrere maskiner ikke bestandig var raskere. Dette var spesielt tydelig på Avroratesten hvor blant annet Google og Microsoft sine to - og åttekjerne maskiner vartregere til å fullføre testen enn deres minste instans. På mange av de andre testenederimot 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 merenn 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 tilprisnivået var på Sunflow-testen. Der var Google 4, Microsoft 5 og Amazon 6ganger raskere enn deres minste instans som ble testet.

Noen av maskinene kunne oppleve korte tidsperioder med økt ytelse. Dette ernoe skytilbyderne gjør om det er en mulighet til det og tidspunkt og varighet fordisse korte ytelsesøkningene er vanskelig å spå. Dermed kan enkelte av testresul-tatene 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 lig-ger stabilt på over 99% for de alle, samtidig som både Google og Amazon tilbyr

55

ø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 kon-tinuerlig 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 enmå 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åketGO, mens de resterende støtter også .Net. Med tanke på at applikasjonen somskal utvikles vil bli utviklet i et .Netmiljø vil det være en vurderingssak hvorvidtdet er viktig med muligheten for å programmere i .Net på serversiden, selv om detikke vil by på større utfordringer å programmere dette i Java.

Når det kommer til muligheten for å skalerbarhet er de ulike nettsky tilbydernemed henholdsvis Google, Microsoft og Amazon like. Det er mulig å fastsettebrukerdefinerte kriterier for hvor store, hvor mange og under hvilke omstendigheternye instanser skal starte og avslutte. Det er også mulig å bestemme dette manueltved å spå når belastningen på applikasjonen er høy/lav og planlegge hvor mangeinstanser en har behov for utifra det. Dedikerte og private virtuelle servere harikke denne fleksibliteten som nettskyen tilbyr, noe som fører til at om en har behovfor 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 varieregjennom dagen og med en dedikert server, vil denne være inaktiv deler av dagenog ikke gjøre noe annet enn å kaste bort cpu-sykluser. Dette vil være i sterk kon-trast til det fleksible alternativet nettskyene tilbyr, ved å skalere antall instanserbåde i størrelse og antall avhengig av ytelsesbehovet applikasjonen har ved detaktuelle tidspunktet. Utifra dette er det ikke aktuelt å gå videre med GoDaddysine alternativer.

9.5 Diskusjon av kvantiativ evaluering

Når det kommer til ytelses - og kosttestene som ble utført på de ulike nettskyeneer det viktig å ta med i betrakningen at selv om det ble testet tre ulike instanserfra henholdsvis Amazon, Google og Microsoft, er det fremdeles mange ulike konfig-urasjoner med ulik mengde RAM, CPU og lagring som ikke er blitt testet. Derforer det viktig å ta med i betraktningen at det ikke er et fasitsvar på hva det bestealternativet vil være i dette tilfellet, men testene som er blitt gjort kan gi oss engenerell 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 kost-nadene ved å utføre de utvalgte testene, selv om den ikke kom dårligst ut med

56

tanke på tiden den brukte. Derimot var deres to - og åttekjernes konfigurasjonmer konkurransedyktig både med tanke på pris og ytelse, hvor tokjernes konfig-urasjonen hadde den raskeste tiden på 7 av 13 tester. Microsoft Azure sin enkjerneskonfigurasjon 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 somvedvarte med deres to - og åttekjernes konfigurasjoner hvor de var omtrent dedårligste når det kom til kostnader, samtidig som de kun var raskest på Lusearcht-esten. Google sine instanser var overlegne når det kom til ytelse og pris, og dettevar 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 kostetmest. Ser man på prisene på de ulike instansene individuelt derimot blir detplutselig litt mer kompleks. De ulike nettskytilbyderne dobler omtrent prisen omde 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 egneberegninger.

Amazon tilbyr også muligheten for å foreta en engangsbetaling for å reservere eninstans og til gjengjeld få en lavere pris på den instansen om den blir reservert for1 eller 3 år. Google har også flere prisalternativer avhengig av hvor mye instansenblir brukt i løpet av måneden. Kjører instansen på nærmere 100% av hva den erkapabel til i løpet av en måned, vil det bli påført en rabatt på fakturaen. Brukesden 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 somblir regnet ut over alle Compute Engine brukerne. Microsoft og Amazon tilbyrogså 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å dennearkitekturen. Dermed står valget mellom Amazon EC2, Google App Engine ogMicrosoft Azure som alle tilbyr instanser i nettskyen.

I den kvantiative evalueringen kom vi fram til at Google App Engine sineinstanser var raskest med å fullføre de ulike testene som er tilstede i DaCapo-testpakken, med en stor margin. Videre ser vi fra Figur 20 at Amazon og Microsoftvar nogenlunde like på de små instansene, men Azure brukte lengst tid på mediumog store instanser.

57

Figur 20: Testresultater i sekunder.

Når det kommer til kostnadene de ulike nettskytilbyderne var Google sine in-stanser igjen de mest økonomiske gjennom testperioden. Amazon var dyrest påden minste instansen, mens Microsoft var dyrest på både den mellomstore og denstørste instansen som vi ser på Figur 21.

Figur 21: Testresultater i cent.

På bakgrunn av den kvalitative og kvantiative evalueringen er det Google AppEngine som fremstår som det mest åpenbare valget. Både prisen og ytelsen tilGoogle sine instanser har vist seg å være svært konkurransedyktige i forhold tilde andre nettskytilbyderne. Dessverre er det ikke støtte for å leie instanser medWindows fra Google sin nettsky, noe som utelukker muligheten for å programmerei et .Net-miljø på serversiden. Dette vil derimot ikke bli et problem da Google harstø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 operativsys-temer. På bakgrunn av det vil man i dette kapittelet se nærmere på Android ogiOS. Dette inkluderer hvordan Xamarin kompilerer på de ulike plattformene oghvordan kjøretiden fungerer på henholdsvis Android og iOS. Til slutt kommer

58

kapittel 10.4 Webtjeneste, hvor det blir forklart hvordan en slik tjeneste fungererog er bygd opp.

10.1 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ærtforskjellig.

Figur 22: C# kildekoden blir en native applikasjon på ulike måter.

iOS - C# kompileres Ahead Of Time (AOT) til språket ARM assembly somvist i Figur 22. .NET rammeverket er inkludert, men ubrukte klasser blir strippetvekk for å redusere størrelsen til applikasjonen. Siden Apple ikke tillater kjøretidskodegenerering på iOS, er noen språkfunksjoner ikke tilgjengelig.

Android - Her blir C# kompilert til Intermediate Language (IL) og pakketmed Just-In-Time (JIT). IL er et objektorientert programmeringsspråk designetfor å bli brukt av kompilatorer for .NET rammeverket før en statisk/dynamiskkompilering til maskinkode [21]. Ubrukte klasser blir også her strippet vekk underlinking. Applikasjonen kjører sammen med Java/Dalvik og samhandler med denative typene via Java Native Interface (JNI).

10.2 Android

Kjøretid består av programvare instruksjoner som kjøres når et valgt programkjører. Disse instruksjonene oversetter programvarens egen kode om til kode somdatamaskinen klarer å kjøre. Derfor trenger alle programmeringsspråk et typekjø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 APKfilene. Det er to store fordeler med å bruke en virtuell maskin som kjøretidsmiljø.

59

Dette er:

• Applikasjonskoden er isolert fra kjernen av operativsystemet. Hvis en feilskulle oppstå i applikasjonskoden vil det derfor ikke påvirke operativsystemet.Dette isolerte miljøet vil også beskytte systemfilene til operativsystemet vedkjøring av skadelig kode.

• En virtuell maskin gir muligheten for krysskompatibilitet. Krysskompati-bilitet er en stor fordel for utviklere da de kan utvikle applikasjonen på endatamaskin og kjøre samme kode på den mobile plattformen ved å bruke denvirtuelle maskinen.

Det finnes to virtuelle maskiner, Dalvik og ART, som blir brukt på Androidenheter. Fra og med Android 5.0 “Lollipop” som ble gitt ut 3. November 2014har 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 brukerAhead-Of-Time (AOT) kompilering. AOT kompilerer bytekoden ved innstallasjonav applikasjonen. Dette fører til redusert bruk av prosessoren og bedre batter-ilevetid. Dalvik bruker en kompileringsmetode som heter JIT hvor kompileringav bytekode blir kompilert hver gang en applikasjon blir kjørt. ART tilbyr ogsåforbedringer innen ytelse, “garbage collection”, applikasjonsdebugging og profiler-ing.

10.3 iOS

Den moderne versjonen av kjøretidsmiljøet til iOS-applikasjoner ble introdusertmed Objective-C 2.0 og inneholder en del nye funksjoner [7]. Blant annet erinstansvariabler i det moderne kjøretidsmiljøet "non-fragile". Dette betyr at omen endrer layouten til en instansvariabel i en klasse, trenger en ikke å rekompilereandre klasser som arver fra denne klassen.

Programmer skrevet i Objective-C interagerer med kjøretidsmiljøet på tre forskjel-lige nivåer: gjennom Objective-C kode, gjennom metoder definert i NSObjectklassen og gjennom direkte kall til funksjoner i kjøretidsmiljøet. Når kode som in-neholder Objective-C blir kompilert, lager kompilatoren datastrukturer og funksjon-skall som implementerer de dynamiske egenskapene til språket. De fleste objektenei Cocoa-rammeverket er subklasser av NSObjekt klassen og arver de metodenedenne klassen definerer.

Kjøretidsmiljøet er et delt og dynamisk bibliotek med et felles grensesnitt sombestår av en rekke funksjoner og datastrukturer lokalisert i header-filene i kat-alogen usr/include/objc. Mange av disse funksjonene tillater brukeren å skrivei ren C-kode for å gjenskape hva kompilatoren gjør når en skriver Objective-Ckode. Andre funksjoner danner grunnlaget for funksjonalitet eksportert gjennom

60

metoder i NSObject klassen. Disse funksjonene gjør det mulig å endre grensesnit-tet til kjøretidsmiljøet og utvide utviklingsmiljøet, men de er ikke nødvendige nåren programmerer i Objective-C.

For å kompilere Objective-C kode blir det brukt en LLVM kompilator. LLVMbruker Clang [39] på front end for å parse kildekode til et midlertidig format.Deretter overtar kodegenerasjonslaget til LLVM over og gjør dette midlertidigeformatet til maskinkode. Xcode har også støtte for å bruke en LLVM GCC kom-pilator, hvor GCC blir brukt på frontend for å sikre kompabilitet, mens LLVMbrukes på backend.

10.4 Webtjeneste

I kapittel 9.6 ble det konkludert med at Google App Engine var det beste valget avskytjeneste. 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 ogmotta data via HTTP protokollen. Det er altså en forespørsel/svar mekanisme sommuliggjør utveksling av data mellom klient og server som vist i Figur 23. Mens envanlig 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 flesteklientrammeverkene er designet rundt bruk av JSON og XML. I testapplikasjonen,kapittel 6.2, ser man et konkret eksempel på hvordan klienten kommuniserer medwebtjenesten. Applikasjonen kjører en HTTP-forespørsel mot en spesifikk adressehvor backend koden (som f. eks henter ut og returnerer etterspurt data fra endatabase) 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 atapplikasjonen 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 sittkjø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 merutdyping om kjøretidsmiljø og virtuelle maskiner.

61

11 Konklusjon

Et utvalg av mulige kryssplattformverktøy ble valgt ut basert på tidligere under-søkelser. Disse ble vurdert av et sett kriterier som var viktig for prosjektgruppenog brukt til å vurdere teknologiene Xamarin, Sencha Touch, Titanium og Phone-Gap. Etter at et valg ble tatt basert på den kvalitative og kvantiative evalueringen,ble en testapplikasjon utviklet for å bekrefte at den valge teknologien tilfredsstiltekravene til applikasjonen som skal utvikles. Driftsarkitekturen ble også bestemtbasert på et sett kriterier og ytelsen til de ulike serverløsningene.

Forskningsspørsmål: Hvilken teknologi passer best for prosjektgruppen? Xamarinkom best ut av den kvalitative vurdering grunnet native funksjonalitet, pris oggod support. PhoneGap får mindre poeng grunnet manglende support. Sencha pågrunn av at det koster penger for å få alt av funksjonalitet og dårligere support.Titanium får kun høyest mulig poeng på støttede plattformer og levbarhet, ogkommer derfor tapende ut av evalueringen. Forskningsspørsmål: Hvilken teknologihar høyest ytelse?Xamarin er raskest i begge ytelsestestene. Spesielt ved hentingog manipulering av store datamengder skiller den seg ut i positiv forstand. I testenav oppstartstid og visning av grafiske elementer er forskjellen mindre, noe som kanha en sammenheng med at testen i gjennomsnitt tar mindre tid å gjennomføre.

Forskningsspørsmål: Hvilken serverløsning er best egnet for prosjektgruppen? GoogleApp Engine ble valgt som serverløsning basert på den kvantiative og kvalitativeevalueringen.Google App Engine sine instanser var, med stor margin, raskest imed å fullføre testene som var tilstedet i DaCapo-testpakken. App Engine varogså mest økonomisk gjennom testperioden. Amazon var dyrest på den minsteinstansen, mens Microsoft var dyrest på både den mellomstore og den største in-stansen.

62

Kilder

[1] Amazon. Amazon ec2 pricing. Tilgjengelig på http://aws.amazon.com/ec2/pricing/.

[2] Amazon. Amazon ec2 service level agreement. Tilgjengelig på http://aws.amazon.com/ec2/sla/.

[3] Amazon. What is auto scaling? Tilgjengelig på http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/WhatIsAutoScaling.html.

[4] Strategy Analytics. Android captures 84 Tilgjengelig påhttp://blogs.strategyanalytics.com/WSS/post/2014/10/31/Android-Captures-84-Share-of-Global-Smartphone-Shipments-in-Q3-2014.aspx.

[5] Appcelerator. Appcelerator titanium. Tilgjengelig på http://www.appcelerator.com/titanium/download-titanium/.

[6] Apple. Changes to app containers in ios 8. Tilgjengelig påhttps://developer.apple.com/library/ios/technotes/tn2406/_index.html#//apple_ref/doc/uid/DTS40014932-CH1-LOCCOM.

[7] Apple. Runtime versions and platforms. Tilgjengelig på https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtVersionsPlatforms.html#//apple_ref/doc/uid/TP40008048-CH106-SW1.

[8] Atlassian. Plan, track, work – smarter and faster. Tilgjengelig på https://www.atlassian.com/software/jira.

[9] Harald Brombach. Bringer .net til mac og linux. Tilgjengelig på http://www.digi.no/931440/bringer-net-til-mac-og-linux.

[10] Isabelle Dalmasso, Soumya Kanti Datta, Christian Bonnet, and NavidNikaein. Survey, comparison and evaluation of cross platform mobile applica-tion development tools. In Wireless Communications and Mobile ComputingConference (IWCMC), Lecture Notes in Computer Science, page 323–328.IEEE, July 2013.

[11] GitHub. Features. Tilgjengelig på https://github.com/features.

[12] GoDaddy. Godaddy hostingavtale. Tilgjengelig på https://no.godaddy.com/agreements/showdoc.aspx?pageid=hosting_sa&ci=90591#.

[13] Google. App engine service level agreement. Tilgjengelig på https://cloud.google.com/appengine/sla.

63

[14] Google. Compute engine autoscaler. Tilgjengelig på https://www.google.com/url?q=https%3A%2F%2Fcloud.google.com%2Fdevelopers%2Farticles%2Fauto-scaling-on-the-google-cloud-platform%2F.

[15] Google. Java runtime environment. Tilgjengelig på https://cloud.google.com/appengine/docs/java/.

[16] Google. Pricing overview. Tilgjengelig på https://cloud.google.com/pricing/.

[17] Google. What frameworks does google app engine support? Tilgjengelig påhttps://cloud.google.com/appengine/kb/general#frameworks.

[18] John Gruber. Google’s app aesthetic. Tilgjengelig på http://daringfireball.net/2014/11/googles_app_aesthetic.

[19] Tore Berg Hansen. Om prosesser. Tilgjengelig på http://www.aitel.hist.no/fag/oos/lek01/oos-ls01-omprosesser.pdf.

[20] Daniel Jackson. alloy: a language and tool for relational models. Tilgjengeligpå http://alloy.mit.edu/alloy/faq.html.

[21] Cory Janssen. Intermediate language. Tilgjengelig på http://www.techopedia.com/definition/24290/intermediate-language-il-net.

[22] JQuery. jquery support. Tilgjengelig på https://jquery.org/support/.

[23] Kony. Cross-platform mobile development. Tilgjengelig på http://www.kony.com/resources/glossary/cross-platform-mobile-development.

[24] Johannes Stølen Markeng. Cross-platform development - evaluation of avail-able solutions. Tilgjengelig på http://compileit.no/masteroppgave.pdf.

[25] Microsoft. Autoscaling and microsoft azure. Tilgjengelig på http://msdn.microsoft.com/en-us/library/hh680945(v=pandp.50).aspx.

[26] Microsoft. Cloud services pricing. Tilgjengelig på http://azure.microsoft.com/nb-no/pricing/details/cloud-services/.

[27] Microsoft. Create your backlog. Tilgjengelig på http://www.visualstudio.com/en-us/get-started/create-your-backlog-vs.aspx.

[28] Microsoft. Cross-platform development with tfs. Tilgjengelig på http://msdn.microsoft.com/en-us/vstudio/jj158939.

[29] Microsoft. Service level agreements. Tilgjengelig på http://azure.microsoft.com/en-us/support/legal/sla/.

[30] Microsoft. Using intellisense. Tilgjengelig på http://msdn.microsoft.com/en-us/library/hcw1s69b.aspx.

64

[31] Microsoft. Visual studio team foundation server 2013. Tilgjen-gelig på http://www.microsoftstore.com/store/msusa/en_US/pdp/Visual-Studio-Team-Foundation-Server-2013/productID.284831500.

[32] Jason Moccia. Agile requirements definition and management. Tilgjengelig påhttps://www.scrumalliance.org/community/articles/2012/february/agile-requirements-definition-and-management.

[33] None. Appcelerator titanium. Tilgjengelig på http://stackoverflow.com/search?q=Appcelerator+Titanium.

[34] None. Phonegap. Tilgjengelig på http://stackoverflow.com/search?q=phonegap.

[35] None. Sencha. Tilgjengelig på http://stackoverflow.com/search?q=Sencha.

[36] PhoneGap. Phonegap faqs. Tilgjengelig på http://phonegap.com/about/faq/.

[37] PhoneGap. Plugins. Tilgjengelig på https://build.phonegap.com/plugins.

[38] DaCapo Project. The dacapo benchmark suite. Tilgjengelig på http://www.dacapobench.org.

[39] The LLVM Project. The llvm compiler infrastructure. Tilgjengelig på http://llvm.org.

[40] Sencha. Download sencha touch. Tilgjengelig på http://www.sencha.com/products/touch/download/.

[41] Sencha. Html5 app development for desktop and mobile. Tilgjengelig påhttps://www.sencha.com.

[42] Sencha. Sencha touch bundle. Tilgjengelig på https://www.sencha.com/store/sencha-touch-bundle/.

[43] SourceForge. Kdiff3. Tilgjengelig på http://sourceforge.net/projects/kdiff3/.

[44] Dio Synodinos. What are the most important and mature cross plat-form mobile tools? Tilgjengelig på http://www.infoq.com/research/cross-platform-mobile-tools.

[45] Adobe Systems. Adobe announces agreement to acquire nitobi, creator ofphonegap. Tilgjengelig på http://www.adobe.com/aboutadobe/pressroom/pressreleases/201110/AdobeAcquiresNitobi.html.

65

[46] Appcelerator Titanium. Titanium mobile development environment. Tilgjen-gelig på http://www.appcelerator.com/titanium/.

[47] Susan Ward. 5 disadvantages of cloud computing. Tilgjen-gelig på http://sbinfocanada.about.com/od/itmanagement/a/Cloud-Computing-Disadvantages.htm.

[48] Peter Wayner. Ultimate cloud speed tests: Amazonvs. google vs. windows azure. Tilgjengelig på http://www.infoworld.com/article/2610403/cloud-computing/ultimate-cloud-speed-tests--amazon-vs--google-vs--windows-azure.html.

[49] Xamarin. Download xamarin platform. Tilgjengelig på http://xamarin.com/download.

[50] Xamarin. Simple and transparent pricing. Tilgjengelig på https://store.xamarin.com.

[51] Xamarin. Simple and transparent pricing. Tilgjengelig på https://store.xamarin.com.

[52] Xamarin. We’re here to help! Tilgjengelig på http://xamarin.com/support.

[53] Xamarin. Xamarin. Tilgjengelig på http://xamarin.com.

66