Institutionen för datavetenskapDepartment of Computer and Information Science

Examensarbete

Second screen on mobile cross­platformav

Torbjörn Kvist

LIU­IDA/LITH­EX­G­­14/074­­SE

 2014­06­13

Linköpings universitetSE­581 83 Linköping, Sweden

Linköpings universitet581 83 Linköping

Linköpings universitetInstitutionen för datavetenskap

Examensarbete

Second screen on mobile cross­platformav

Torbjörn Kvist

LIU­IDA/LITH­EX­G­­14/074­­SE

2014­06­13

Handledare: Johan Åberg

Examinator: Peter Dalenius

Second screen on mobile cross-platform

Torbjorn Kvisttorbjorn.kvist@gmail.com

SAMMANFATTNINGUtveckling av mobila applikationer ar idag allt svarare for ut-vecklare, eftersom det finns manga olika enheter och opera-tivsystem. Detta examensarbete kommer ga igenom hur mul-tiplattformsramverk kan anvandas for att utveckla och imple-mentera en second screen som komplement till andra enheter.Plattformarna kommer utvarderas med avseende pa hur kom-plext det ar att implementera losningen samt hur de preste-rar under olika forhallanden. De multiplattformsramverk somkommer utvarderas ar OpenFL och PhoneGap.

INLEDNINGMarknaden for smartphones har vuxit kraftigt de senaste aren,bara under 2013 saldes det 1.8 miljoner[17] smartphones i he-la varlden. Det beraknas finnas 1.7 miljarder[18] smartphone-anvandare under 2014.

Eftersom operativsystem och funktionalitet pa smartphoneskan variera fran vilken modell anvandaren valjer, sa blir detett allt storre problem for utvecklare att na ut till sa mangakunder som mojligt med sina applikationer.

For att losa detta problem for utvecklare blir det allt vanligareatt det utvecklas smartphone-anpassade webbsidor, sa kalla-de webbapplikationer. Nackdelen med dessa ar att de oftast arbegransade i vad de kan gora, samt att de lider av prestanda-problem om det ar nagot mer avancerat.

En losningen pa detta problem ar att anvanda sig av sa kal-lade multiplattformsutvecklingsverktyg/ramverk som anpas-sar och omvandlar en kodbas till att fungera pa flera oli-ka smartphones-enheter. Detta examensarbete kommer un-dersoka och utvardera om multiplattformsutveckling ar nagotatt anvanda sig av nar det ska utvecklas second screen tillsmartphones.

En second screen avser anvandning av en annan enhet, ex-empelvis smartphone eller surfplatta, for att komplettera ellerforbattra tittar-upplevelsen for innehallet pa en annan enhet,exempelvis en TV. Second screen kan anvandas till allt franatt visa en EPG (kanalguide), bladdra genom ett filmbibliotekeller speciellt anpassade applikationer for ett TV-program.

SyfteMalet med detta examensarbete ar att utvardera och im-plementera en begransad multiplattformslosning for secondscreen [sv. andra skarm].

Kravet pa losningen ar att den ska kunna visa mindre delarav en storre mangd data for anvandaren. Delar av data sominte syns ska hamtas i fortid, sa att anvandare inte ska behovamarka av eventuella laddningstider nar det hamtas. Figur 1visar ett exempel pa hur en sadan losning skulle kunna se ut.

Figur 1: Exempel pa second screen

Data som ska anvandas ar en filmdatabas som innehaller datafor over 3000 filmer/serier, dar varje serie/film representerasav metadata, samt en bild.

Metadata ar en mangd data som innehaller information omnagon slags data. Det kan vara allt fran struktur till informa-tion om en film. I detta fall syftar det pa den data som finns ifilmdatabasen som anvands som bas.

FragestallningHur fungerar multiplattformsstoden PhoneGap och OpenFLfor att implementera second screen losningen, med avseendepa:

• Prestanda for uppdateringshastighet, allokerad min-nesmangd och hamtningstider av data.

• Komplexitet att implementera losningen: antal arbetstim-mar, rader kod och distribuering till olika plattformer.

AvgransningarAvgransningar som gjorts for examensarbetet ar valet av mul-tiplattformsverktyg som ar begransade till PhoneGap ochOpenFL, eftersom de tacker bada de vanligaste typerna avmultiplattformar (hybrid, native). Enheter som testerna kom-mer utforas pa ar tva Androidenheter, en smartphone och ensurfplatta, bada med Android 4.4.

En enklare webbapplikations-server har satts upp for att han-tera hamtning av data och bilder for second screen-losningensamt for testning av hamtningstider och allokering av min-nesmangd.

TEORI

Vad ar en multiplattform?Mobila applikationer for smartphones har blivit allt viktiga-re som en utvecklingsplattform for produkter och tjanster. Ioch med att segmentet av operativsystem for smartphones arsa blandat, blir det allt vanligare att det anvands multiplatt-formsverktyg for att na en storre kundkrets.

Ett vanligt exempel pa en multiplattform ar Java, somanvander sig av JVM, Java Virtual Machine, dar koden kan

1

koras pa flera olika plattformar utan andring. Det enda somkravs att det finns en JVM implementerad pa den platt-formen. Inom smartphoneutveckling sa finns det tre van-liga tillvagagangssatt for att kunna uppna en multiplatt-formlosning: webb, hybrid och cross-compile[6].

Figur 2: Webbaserad applikation

En Webbaserad applikation ar en hemsida som ar anpassadfor att fungera pa smartphones, vilket anvander sig av denwebblasare som finns pa enheten. Ett exempel pa en strukturpa hur en applikation som anvander sig av Webb kan ses ifigur 2.

Figur 3: Hybrid-baserad applikation

Hybrid anvander sig oftast av den inbyggda webblasaren paenheten for att visa innehall men har aven tillgang till funk-tioner som annars inte hade varit tillgangliga for till exempelen webb-losning. Detta gors genom att fa tillgang till delarav enhetens formagor genom ett abstraktionslager, API. API(Application Program Interface) ar ett granssnitt som gor detmojligt med andra program och insticksmoduler att utnyttjavissa funktionaliteter fran en annan tjanst, till exempel hamtaTwitter-inlagg via Twitters API. Figur 3 visar ett exempel pahur strukturen for en hybridapplikation kan se ut.

Cross-compile kompilerar kallkod fran ett programsprak tillannat sprak, vilket gor det mojligt att uppna en losning somar native. Detta gor att den far full tillgang till alla delar avenheten. Ett exempel pa hur en sadan struktur kan se ut kanses i Figur 4.

Det ar oftast dyrt att forsoka na ut till sa manga plattfor-mar som mojligt, skulle det skrivas nativekod for varje sadan.

Figur 4: Cross-compile baserad applikation

Det ar darfor multiplattform-ramverk/verktyg ar sa attraktivai dagslaget eftersom det kan spara in pengar pa utvecklingstidoch anda na ut till sa manga kunder som mojligt[6].

Hur paverkas prestanda?Prestanda ar en av de viktigaste hornstenarna nar det pratasom multiplattform[2, 5], eftersom det ar slutanvandare somkommer kanna av detta. Detta gor att det maste fokuseras paatt skapa en sa bra anvandarupplevelse som mojligt.

Eftersom manga multiplattformlosningar begransar utveckla-re pa grund av att de kanske maste koras i webblasare ellerbegransad omgivning sa kanske det inte passar alla typer avapplikationer[7].

Fragan utvecklaren maste stalla sig innan utveckling borjarfor en multiplattformlosning ar om det vart i langden attgora det eller om det skulle vara mindre kostsamt i langdenatt utveckla en native-losning[16]. Eftersom multiplattforms-verktyg fortfarande ar en vaxande del av utvecklingen av mo-bila losningar sa maste det anpassas efter kundens behov[4].

Hur fungerar det med distribuering?Distribuering av multiplattforms-applikationer fungerar pa sasatt att det paketeras till den valda plattformen som stods avmultiplattformverktyget genom att kora ett kommando, tillexempel phonegap build android. Det gor att det ar enkeltatt paketera och distribuera applikationer till respektive platt-form for spridning av applikationer.

MultiplattformarDet finns manga multiplattformar pa dagens marknad. Mangaav dess plattformar ar multifunktionella, dar det gar att badeskapa applikationer och spel. Det finns de som inte kostarnagot att anvanda, men det finns aven de som ar begransadetill funktionalitet tills en summa har betalas for att lasa uppfunktionalitet.

• Corona SDK1 — ar en multiplattformteknik som gor detmojligt att anvanda Lua-skript for applikationsutveckling,som sedan kompileras till native-kod for Android och iOS.

1Corona SDK http://coronalabs.com/products

2

• Marmalade SDK2 — gor det mojligt att utveckla och dis-tribuera kod for flera plattformar och enheter fran en en-da kodbas som antingen skrivs i C++, Lua, HTML ellerObjective-C.

• MoSync3 — ar ett oppet mjukvaruutvecklingsverktyg foratt kunna skapa mobila applikationer for flera av de olikaplattformarna pa marknaden. Det finns mojlighet att ska-pa bade native- och hybrid versioner genom att antingenanvand sig av C++, HTML/JavaScript eller bada for attskapa hybridapplikationer.

• OpenFL[14] — ar en snabb och oppen implementation avindustristandarden Flash API. Till skillnad fran Adobes im-plementation, sa utnyttjar OpenFL hardvarurendering ochkompilerar till C++ for att kunna na manga plattformar.

• PhoneGap[15] — ar ett fritt och oppet mjukvaruramverkdar det gar att skapa applikationer med hjalp av ett standar-diserat webb-API for manga plattformar.

• Rhodes4 — ar ett Ruby-baserat ramverk med oppenkallkod som ar byggt for att gora snabba och native-applikationer. (iPhone, Android, RIM, Windows Mobileand Windows Phone 7)

• Sencha Touch5 – ett HTML5 applikationsramverk for attskapa hog-prestanda-applikationer. Det bygger pa att geanvandare en varldsklass-upplevelse. Sencha Touch goratt utvecklare kan bygga applikationer till iOS, Android,BlackBerry, Windows och manga fler.

• Titanium6 — Skapa nativeapplikationer till flera enhe-ter, hybridapplikationer med hjalp av HTML5 genom attanvanda sig av deras oppna utvecklingsmiljo Titanium.

Valet av multiplattformarFor att kunna avgora vilka tva plattformer som skulleutvarderas och testas i detta examensarbetet, valdes ett antalkriterier som skulle uppfyllas:

• Tva olika multiplattformar, hybrid och native.

• Kunna distribuera till Android och iOS.

• Fri anvandning, det vill saga inte kosta nagot for att kunnautnyttja allt pa plattformen.

• Utvecklingsmiljo som fungerar pa Linux, OS X och Win-dows.

Utifran dessa kriterier valdes PhoneGap och OpenFL.

PhoneGapPhonegap[15] ar ett hybrid-baserat multiplattforms-verktygsom anvander sig av ramverket Cordova[3] for att en-kelt kunna bygga mobila applikationer. Cordova bygger pa2Marmalade SDK https://www.madewithmarmalade.com/3MoSync http://www.mosync.com/4RhoStudio http://www.rhomobile.com5Sencha Touch http://www.sencha.com/products/touch/6Titanium http://www.appcelerator.com/titanium/

anvandningen av den inbyggda webblasasaren pa operativsy-stemet for att visa HTML/CSS. Genom att anvanda CordovaAPI gar det genom JavaScript att fa tillgang till enhets speci-fika delar som annars inte skulle ha varit tillgangliga.

Figur 5: PhoneGap arbetsflode

Figur 5 representerar hur arbetsflodet ser ut nar for paketeringav en PhoneGap-applikation. Logiken for applikationen ochgranssnitt skrivs med hjalp av HTML/CSS/JavaScript. Detpaketeras sedan till en plattform med hjalp av Cordova, somhanterar hur det ska paketeras till olika plattformar. For attsedan enkelt kunna distribueras till olika plattformer.

Kodexempel 1 och 2 visar hur JavaScript anvands att hamtadata och bilder fran en server i PhoneGap.

Kodexempel 1: Hamtning av metadata fran server

var http = new XMLHttpRequest();http.open("GET", url, false).send();

// Lista med metadata

3

var data = JSON.parse(http.responseText);

Kodexempel 2: Hamtning av bild fran server

var img = new Image()// Bild dataimg.src = url + "cover_small/"

+ data[i][0].asset_file;

OpenFLOpenFL[14] ar ett cross-compile-baserat multiplattforms-ramverk, dar Flash API anvands och programmeringsspraketHaxe[8]. Genom att anvanda dessa ar det mojligt att ska-pa snabba native-losningar for bland annat applikationer ochspel for mobila plattformar.

I figur 6 visar att OpenFL bygger pa tre komponenter: Open-FL, lime och Haxe.

Figur 6: Vad innehaller OpenFL

lime[11] (Lightweight Media Engine) ar ett abstraktionslagersom ar ett enkelt plattformsoberoende ritnings-API for Open-FL. Det hanterar allt fran fonsterhantering, resurs-laddning,ritning av objekt till granssnitt med hjalp av OpenGL7 ochSDL8. Haxe ar ett hogniva multiprogrammeringssprak somgor det mojligt att skriva och kompilera till manga olika platt-formar. Med hjalp av bade lime och Haxe kan OpenFL kom-pilera ner samma kodbas till olika plattformar som exempel-vis Windows, Android och iOS.

Kodexempel 3 och 4 visar hur Haxe anvands for att kunnahamta data och bilder fran en extern server i OpenFL.

Kodexempel 3: Hamtning av metadata fran server

var loader = new Loader ();loader.contentLoaderInfo.addEventListener(

Event.COMPLETE,function(event:Event):Void {// Lista med metadatavar items:Array<Dynamic> = Json.parse(

event.target.data);});loader.load(new URLRequest(URL + path));

Kodexempel 4: Hamtning av bild fran server7OpenGL http://www.opengl.org/8SDL http://www.libsdl.org/

var loader = new Loader ();loader.contentLoaderInfo.addEventListener(

Event.COMPLETE,function(event:Event):Void {// Bild datavar bmp:Bitmap = event.target.content;

});loader.load(new URLRequest(URL + path));

MetodteoriHantera och visa dataFor att kunna hantera stora datamangder i en applikationenfinns det en rad olika alternativ som kan anvandas for att losaproblemet. Det vanligaste sattet ar att anvanda sig av pagi-nation[sv. sidor], det vill saga att mangden delas upp i grup-per for att sedan hantera varje grupp som en sida. Det ar enlosning som fungerar bra och ar val testad. En nackdelen ardock att anvandaren sjalv maste bladdra for att kunna kommatill en ny sida, till exempel klicka pa nasta sida.

Ett annat alternativ ar att anvanda sig av Infinite scroll. Detar ett designmonster som gar ut pa hamta innehall som kom-mer att visas, men annu inte har det, for att sedan lagga tilldet antingen langst ner eller hogst upp i listan. Det anvandsofta om det finns mycket innehall som skulle ta for langtid att ladda fran borjan. Laddning av data brukar oftastske nar anvandare narmar sig botten av sidan. Det gor attanvandaren inte behover trycka nasta sida, utan bara kanfortstatta bladdra igenom innehallet utan att behova stanna.En stor nackdel med detta ar att de flesta implementatio-nerna av Infinite scroll haller kvar sin data, som gor att omanvandaren gar igenom en stor mangd data vaxer bara utrym-met som kravs for att halla kvar all data.

KomplexitetutvarderingEtt alternativ for att kunna utvardera komplexitet ar att mataantal rader kallkod som projektet innehaller. Att rakna antaletrader kod ar nagot som anses daligt[1] i visa sammanhang,eftersom det beror helt pa hur koden ar formaterad.

Kodexempel 5: Tre rader kod

for(var i = 0; i < 10; i++) {console.log(‘‘Hello World’’, i);

}

Kodexempel 6: En rad kod

for(var i = 0; i < 10; i++) { console.log(‘‘Hello World’’, i);}

Som Kodexempel 5 och 6 visar att det gar det att skriva sam-ma kod pa flera satt. Pa det sattet gar det att fa lagre antal raderav kod, vilket gor att Kodexempel 6 skulle vara battre. For attkunna anvanda antal rader av kod, galler det att projekten somjamfors har hallit en god kod-formatering, som resulterar attkoden inte skrivs som i Kodexempel 6.

For en utvecklare eller foretag ar det viktigt att veta om detar vart att investera sin tid i att anvanda en plattform for ut-veckling. Ett mindre komplext system som kan losa uppgifteninnebar oftast mindre arbetstid och mer ekonomisk vinning.

4

Exempel pa parametrar som kan vara relevanta for detta arhur manga timmar det tog att fa fram ett fardigt projekt ochhur enkelt ar det att na ut till sa manga anvandare som mojligt.

PrestandautvarderingFor att kunna utvardera hur en plattform presterar undervissa omstandigheter kan anvanda sig av Benchmarking[sv.riktmarke]. Det ar ett satt for att skapa ett riktvarde pa hur branagot presterar inom en viss begransad testningsmiljo. Det-ta gors ofta pa flera olika plattformar for att jamfora mellandessa och dar av utvardera om nagot presterar battre pa nagotomrade.

Det finns exempel pa tidigare tester som har gjorts av [5] darde testar de vanligaste operationerna som utfors av olika ap-plikationer. Deras tester gjorde en jamforelse mellan en native(Android) och en hybrid (PhoneGap) losning.

Aven [13] gjorde tester dar de jamforde uppstarten av sammaapplikationen samt hur mycket minne som frigjordes nar denstangdes pa olika plattformar. De anvande sig av USS (uniqueset size) for att avgora hur mycket minne som frigjordes.

For att kunna avgora vilken plattform som presterar bast,maste det avgoras vilka tester som ar mest relevanta for pro-jektet, det vill saga vilka operationer som har mest paverkan.Vi utgar fran det innehallet som presenteras under rubrikenSyfte dar det beskrevs olika krav pa losningen for secondscreen. Utifran det kommer det utforas tre olika tester:

• Allokering av minne — matning av hur mycket minne somkravs for att kunna halla reda pa olika mangder metadatasamt bilder. For att kunna ta reda pa hur mycket minne somanvands av applikationen kommer ADB (Android DebugBridge) att anvands. ADB ar ett verktyg som foljer med iAndroids utvecklingsmiljo, vilket innehaller bade en klientoch serversida for att kunna kommunicera med Androiden-heter via kommandoprompten. Med hjalp av kommandotadb shell dumpsys meminfo far man ut all min-nesinformation fran en Androidenhet vid just det tillfallet.

• Hamtningstider av data – matning av hur lang tid det tar atthamta en mangd data fran server till applikationen.

• Uppdateringshastighet — matning av hur snabbt applika-tionen kan hantera uppdateringar och ut-ritningar av objektpa skarmen. Matningen av uppdateringshastighet gors ge-nom att anvanda av ett redan existerande test AnimationBenchmarking[12], som testar animering av manga objektfor att mata uppdateringshastighet pa olika tekniker. Det re-sultat man far fran Animation Benchmarking ar FPS (fram-es per second), vilket mater hur manga uppdateringar somsker per sekund. Detta vill man halla sa hogt som mojligtmen med sa manga objekt som mojligt.

METOD

ImplementationDemoUnder implementation for varje plattform gjordes det tredemo-applikationer for att kunna testa olika funktionalitetsom behovs for att kunna fardigstalla en second screenlosning.

• Den forsta applikationen hamtar delar av data fran server.Detta inkluderar metadata samt bilder fran servern.

• Den andra ar insticksmoduler/ramverk som loser pagina-tion och infinite scroll.

• Den trejde ar en implementation av ett enklare granssnittfor second screen.

PlattformarnaForsta steget var att undersoka all relevant dokumentation forplattformen, samt undersoka om det finns insticksmoduler/-ramverk som loser pagination och infinite scroll. For att sedanskapa nagra demo-applikationer for att testa olika funktiona-liteter som behovs for second screen.

For att sedan skapa en enklare helhetslosning for se-cond screen med hjalp av demo-applikationer och den un-dersokning som gjorts om varje plattform.

Komplexitet utvarderingMatning av rader kod gjordes genom att rakna antalet raderskriven kod, exklusive kommentarer och externa insticksmo-duler/ramverk. Formateringen av kod foljde kodexempel 5 pabada plattformarna.

Antalet arbetstimmar antecknades allt eftersom arbete gjor-des, varje plattform for sig, med en kort anteckning pa vadsom gjorts. Utvardering av vilka plattformar det kan distri-bueras pa gjordes genom att lasa den officiella dokumentatio-nen.

PrestandautvarderingUtvarderingen skedde pa tva Androidenheter, en surfplattaoch en smartphone, for att fa ett bredare resultat som kanutvarderas.

Allokering av minneAnvanda ADB for att fa ut hur mycket minne som har alloke-ras av applikationer for att halla reda pa metadata samt bilder.Testet kommer upprepas 10 ganger per mangd data, for att faut ett medelvarde for varje mangd. De mangder som kommertestas ar 10/100/1000.

Hamtningstider av dataHamta data fran server och mat hur lang tid det tar for enviss mangd metadata samt bilder att ladda. Matningen kom-mer ske fran nar den borjade hamta tills all data har laddatklart. Testet kommer upprepas 10 ganger per mangd data,for att fa ett medelvarde. De mangder som kommer testas ar10/100/1000.

UppdateringshastighetMata resultatet fran Animation Benchmarking, dar antalet ob-jekt kommer oka med 50 for varje test omgang. Testet kom-mer borja med 100 objekt och sluta med 1000 objekt. Ef-ter varje test kommer den aktuella FPS sparas och samman-stallas.

RESULTAT

Implementation

5

Implementation av second screen pa PhoneGap anvander sigav IScroll[10], vilket gor att den uppfyller kravet att anvandasig av Infinite scroll.

Implementation av second screen pa OpenFL anvander sig avramverket HaxeUI[9] for att kunna skapa ett granssnitt ochimplementera funktionaliteten for Infinite scroll.

Ett exemepel pa bada losningarna pa en surfplatta kan ses iBilaga 1.

DatahanterareFor att kunna hanterare metadata och bilder pa ett effektivtsatt implementerades en datahanterare, se figur 7.

Figur 7: Data hanterare

Datahanteraren fungerar genom att endast ha den data sombehovs. En viss mangd data i bade riktningarna, sa att det all-tid finns data som kan anvandas om anvandare skulle scrolla inagon riktning. Data plockas bort och laggs till nar olika vill-kor har uppfylls, sa att det alltid finns ny data som kommer inoch att anvandare kan fortsatta scrolla.

Komplexitet att implementera losningenRader kodAntal rader kod som det tog for att implementera secondscreen pa bada plattformerna kan ses i figur 8. Dar OpenFLhar 409 rader kod skriven i Haxe och PhoneGap har 140 raderi CSS, 36 rader i HTML och 133 rader i JavaScript.

ArbetstimmarAntal arbetstimmar det tog for att undersoka samt implemen-tera second screen for varje plattform kan ses i figur 9. DarOpenFL tog 98 timmar och PhoneGap tog 61 timmar.

DistribueringOpenFL kan distruberas9 till foljande plattformar: iOS,Android, Windows, Blackberry, Firefox OS, Tizen, HTML5,Linux, Mac, Flash.9OpenFL plattforms http://www.openfl.org/documentation/setup/platforms/

Figur 8: Rader kod per plattform och sprak, se Bilagor forstorre figur

Figur 9: Antalet arbetstimmar per plattform, se Bilagor forstorre figur

PhoneGap kan distruberas10 till foljande plattformar: iOS,Android, Windows Phone, Blackberry 5/6/7, Firefox OS, Ti-zen, Ubuntu, Windows 8 och webOS.

PrestandatestningTestning av olika prestanda-aspekter for jamforelse mellanplattformarna.

Allokering av minneMangden minne som blivit allokerat av applikationen paplattformarna. Se Figur 10 for resultat. Graferna visar skill-naden mellan plattformarna samt hur det ser ut pa de enhetersom det har testat pa.

Hamtningstider av dataTiden det tog att hamta en mangd data pa de olika plattformar-na. Se figur 11 for resultat. Graferna visar skillnaden mellanplattformarna samt hur det ser ut pa de enheter som det hartestat pa.

10PhoneGap plattforms http://docs.phonegap.com/en/edge/guide_platforms_index.md.html

6

Figur 10: Jamforelse av allokering av minne pa surfplatta ochsmartphone, se Bilagor for storre figur

Figur 11: Jamforelse av hamtningstider pa surfplatta ochsmartphone, se Bilagor for storre figur

UppdateringshastighetUppdateringshastighet pa de olika plattformarna mattes medhjalp av ManInBlue - Animation benchmark[12], se Figur 12.Graferna visar skillnaden mellan plattformarna samt hur detser ut pa de enheter som det har testat pa.

Figur 12: Jamforelse av uppdateringshastighets pa surfplattaoch smartphone, se Bilagor for storre figur

DISKUSSION

Resultat - Komplexitet att implementera losningResultatet fran testningen av komplexitet kan vara missvi-sande beroende pa vilken person det ar som implementerar.Malet var att halla nere koden sa mycket som mojligt for attfa en enklare losning som det ar mojligt att bygga vidare pa.Externa bibliotek ar inte med raknade som rader av kod, baraskriven kod.

PhoneGapEftersom PhoneGap bygger pa anvandning av den inbyggdawebblasaren i operativsystemet finns det en uppsjo med bib-liotek och insticksmoduler att valja mellan for bland annatJavaScript. Eftersom den anvander HTML/CSS for att skapagranssnitt, kan det ateranvandas till andra plattformar[6][7]eftersom det ar baserat pa relativt standardiserade webbasera-de anvandargranssnittet. Det gjorde att det gick at mindre tidatt implementera sjalva losningen och mer tid pa att hitta oli-ka komponenter som skulle fungera bra och losa problemet.Hade det varit ett krav att inte anvanda sig av nagot externtbibliotek eller insticksmodul hade antalet rader kod okat.

OpenFLEftersom OpenFL har mer fokus pa att bygga spel, har de fles-ta ramverk/verktyg fokus pa att gora det enklare att utvecklaspel. Att gora applikationer gar, men ar besvarligt eftersomdet inte riktigt finns officellt stod for det, men det finns exter-na bibliotek som loser detta problem. Detta paverkade arbets-tiden for att kunna gora en fungerande losning.

Antalet rader kod blev mindre an forvantat. Detta mest pagrund av att manga av de externa biblioteken saknar funktio-nalitet eller inte ar riktigt fardiga.

Resultat - PrestandatestningDet har med att hybrid-applikationer skulle vara samre anatt anvanda en native-applikation[6] stammer bra i mangafall. Det beror dock helt pa vilka operationer som skautforas. Som marktes pa resultatet for hamtningstider, fickhybrid-applikationenen mycket battre resultat an vad native-applikation fick. Men det beror mest pa att just hybrid-applikation kors i en webblasarmiljo, dar det ar gjort for atthamta data fran en server ofta.

Allokering av minneMed avseende pa minne presterade PhoneGap valdigt bra, alltfor bra, med tanke pa att det kor i en begransad miljo. Mendet visade sig att bilder cachas i den inbyggda webblasaren padisk eller i en separat del av minne som inte gar att undersokapa ett bra satt. Detta medfor troligen att att kurvorna skullevara mycket narmare varandra an vad de ar vid tillfallet formatningen.

OpenFL presterade samre pa testet, men kommer troligen va-ra snabbare pa att visa bilder, eftersom det kommer plockasdirekt ut minne.

Ett normalfall av mangden data ligger nagonstans mel-lan 100-200 metadata och bilder. Detta beror pa hur storupplosning det ar pa skarmen samt hur mycket som ska varaladdat i fortid.

I [13] kom de fram till att PhoneGap allokerade 3.5 gangermer minne an en native-losning gjord i Android. Dar Pho-neGap presterade som femte bast av 10 olika plattformar paminne testningen och var battre an manga andra som ar nati-ve/hybridramverk. Detta ar valdigt intressant, varfor tar dessamycket mer minne for samma slags applikation?

Hamtningstider for data

7

Aven i avseendet hamtning av data presterade PhoneGapbattre an OpenFL. Eftersom utveckling med PhoneGap gorsmed hjalp av JavaScript, som aven anvands for att bygga uppwebbplatser ar stod for just hamtning effektivt. I OpenFL vardet lite svarare, eftersom det var tvungen att implementerabade hamtning av metadata och bilder fran en extern server.

Eftersom PhoneGap anvander sig av en webblasare skerhamtningen av data parallellt, nar OpenFL troligen inte gordet parallellt. Dock ar bada losningarna asynkrona, sa det bor-de inte spela nagon storre roll for resultatet.

UppdateringshastighetI uppdateringshastighet var OpenFL mer jamn, eftersom denar last vid 60 fps(Frame per second) och eftersom denanvander sig av native-kod presterar den bra mycket battrean bade Canvas/SVG-losningen i PhoneGap. Det fanns enHTML-version ocksa, men den gav for undermaliga resultatatt den inte skulle tillfora nagot resultat som var anvandbart.

ManInBlue har en Flashimplementation som kunde anvandasfor att testa pa OpenFL. Nagot som inte testades var attanvanda OpenGL, det skulle kunna gora att OpenFL skulleprestera annu battre an vad det gjorde nu.

Om ManInBlue ar ett tillforlitligt test att anvandas for att matauppdateringshastighet ar nagot som borde undersoka battre,men det uppfyllde de kraven som behovdes for att testa upp-dateringshastigheten pa de olika plattformarna.

MetodImplementationImplementation gick ut pa att fa en battre bild pa varje platt-form samt undersoka eventuella losningar som redan fannsfor varje plattform. For att sedan implementera tre demo-applikationer som skulle vara till for att testa olika funktio-naliteter for plattformen samt insticksmoduler/ramverk.

Detta gjordes for att underlatta utveckling samt hitta be-gransningar i plattformen for att se om det var mojligt attimplementera en second screen.

Vad som kunde ha forbattras med implementation ar att haanvant en utvecklingsmetodik som till exempel Scrum. For attfa en battre struktur pa implementationsprocessen, eftersomdet blev ostrukturerat mot slutet av implementationen.

Komplexitet att implementera losningenRakna rader kod som ett satt att mata komplexitet for skrivenkod kan vara ratt missvisande eftersom det beror pa hur kodenhar formateras av utvecklaren. I kodexemplen som gavs underrubriken Metodteori, var det samma kod, men tva helt olikatotalsummor pa antal rader. For att detta ska vara mer palitigtborde det satts upp en formateringsmall som ska foljas.

Tva andra satt att mata komplexitet ar:

• Halstead complexity11 ett satt att faststalla ett kvantitativtmatt for komplexitet av kod, genom att anvanda operatoreroch operanderna for att mata programmets komplexitet.

11Halstead complexity http://en.wikipedia.org/wiki/Halstead_complexity_measures

• Cyclomatic complexity12, mater den strukturella komplex-itet som finns i koden. Dar den beraknar antalet olikavagar/floden koden kan ta i programmet.

Dessa matt anvandes tyvarr inte i detta examensarbetet pagrund av att det inte finns nagon implementation for mattenfor att kunna anvanda i samband med programmeringsspraketHaxe.

Att mata antalet timmar det tar att komma fram till en losningar inte det lattaste eftersom det kan vara valdigt subjektivt.Det beror helt pa vem som gor det, har utvecklaren latt attlara sig, laser snabbt eller nagra andra kunskaper sen tidigaresom kan paverka resultatet. Det finns manga variabler sompaverkar resultatet for detta, om det ar ett matt som ar bra attanvanda for att mata komplexitet for en implementation, arnagot som borde undersokas mer noga. Hade det varit flerasom utvecklade samma losning dar tiden skrevs ner, skulledet nog ge en battre bild om antalet timmar, men i detta fallvar det bara en person.

Distribuering ar en viktigt punkt med multiplattformsutveck-ling, eftersom det avgor hur manga kunder som kan nas. Detar inte ett matt som ar bra att mata komplexitet, pa grund avatt det har ingen med sjalva losningen att gora, eftersom detar plattformen som avgor vilka det kan distrbueras till.

PrestandatestningAtt mata prestanda ar nagot som kan goras pa manga olikasatt. Just i detta examensarbetet var det mer fokus pa testersom var relevanta for just de operationer som kommer utforasofta. Dar minnet, uppdateringshastighet och hamtning av dataar valdigt viktiga parametrar.

Till exempel matte bade [6] och [13] kortiden pa en applika-tionen, dar de jamforde med en eller flera plattformar.

PhoneGapPhoneGap var en uppskattad plattform att arbeta pa, eftersomdet paminner mycket om webbutveckling och webbdesign.En av de storre nackdelarna ar att det ar begransad av vad somgar att gora med endast HTML/CSS och JavaScript i Phone-Gap, ska tanka pa vad for applikation man tankt utveckla[19].Det finns mojlighet att bygga native-moduler, for att fa uppprestanda. Att bygga just native-moduler ar nagot som gorssallan och ar oftast special fall, sa det tas inte upp i detta exa-mensarbete.

AnvandbarhetDet var enkelt att komma igang med utvecklingen och avenlatt att prova pa olika plattformar. Eftersom det ar en webb-sida som skapas, sa gar det att prova direkt i en vanligwebblasare utan att behova vanta pa att det ska kompileras,vilket gor att arbetssattet blir snabbare.

En ytterligare nackdel ar att dokumentation ar rorig och att detfinns manga versioner av PhoneGap/Cordova. Manga guiderpa natet anvander sig av nagon aldre versioner som inte stodslangre.

12Cyclomatic complexity http://en.wikipedia.org/wiki/Cyclomatic_complexity

8

GranssnittAtt skapa granssnitt med PhoneGap ar enkelt, genom attanvanda sig av HTML/CSS. Man maste tanka pa att skapaen responsiv design, eftersom skarmupplosning ar olika paolika enheter.

IScroll loser scrolling och infinite scrolling pa ett bra satt,dock var det gjort for att endast ha ett element per rad. Detblev en mindre andring pa hanteringen av metadata och bil-der. Det finns manga fler bibliotek som gor liknande funktio-nalitet men var inte lika latt att hantera och anvanda sig av foratt losa problemet.

OpenFLEftersom OpenFL ar en cross-compile-plattform, sa gar detatt gora manga saker som inte skulle kunna gora i till exempeli PhoneGap. Det bygger pa Flash-API, sa det gar att anvandasig av ActionScript-losningar och verktyg, eftersom det mastekompileras for att kunna testas tar det langre tid.

Den officiella dokumentationen ar valdigt kortfattad. Detfinns gott om exempelprojekt for spelutveckling men fa forutveckling av applikationer. Det kan gora applikationsutveck-ling svar men det finns ramverk som underlattar genom atttillhandahalla granssnitt-komponenter.

AnvandbarhetOpenFL var relativt enkelt att komma in i, dock sa fanns detinget officiellt utvecklingsverktyg. Det rekommenderades attanvanda Flash Developer, som just nu endast finns tillgangligfor Windows. Detta stanger ute manga utvecklare. Det finnsinsticksmoduler for andra utvecklingsverktyg, men de hallstyvarr inte uppdaterade till senaste versionen av OpenFL.

GranssnittHaxeUI gor att det blir mojligt att enkelt gora granssnitt, denstorsta nackdelen ar att det knappt finns nagon dokumenta-tion for ramverket. Den dokumentation som fanns var anting-en inaktuell eller fel pa grund av en uppdatering som andraderamverket. Men det fanns nagra kodexempel, och man kun-de komma at koden och se hur det fungerade, vilket gjordeatt det gick att anvanda komponenter som inte an hade blivitdokumenterade an.

Det fanns fler ramverk, men det var inte lika uppdaterade ellersaknade storre funktionalitet som inte gjorde de anvandbara.

Arbetet i ett vidare sammanhangMultiplattformsutveckling ar ett omrade som vaxer allt merpa grund av att det slapps nyare enheter och nya versionerav operativsystem av mobila enheter. Det underlattar for ut-vecklaren att implementera sina applikationer, men en saksom inte tas upp allt for ofta ar vilka nackdelar det medforfor anvandaren av applikationen. Kan utvecklare verkligenlita pa att alla anvandare far samma upplevelse av applika-tionen nar det utvecklas med hjalp av multiplattformsverktygnar anvandarna ar spridda over nyare och aldre modeller avenheter? Multiplattformsverktyg ar bra for att komma igangoch na manga anvandare direkt men i langden sa kanske detskulle vara vart att gora en native-applikation for att forbattraanvandarens upplevelse.

SLUTSATSERMultiplattforms-utveckling ar ett valdigt intressant omradeinom mjukvaruutveckling, eftersom det gar att gora mycketolika saker med det, allt fran enklare applikationer till spel,med samma kodbas och anda na ut till manga anvandare.

Second screenEn fungerade enkel second screen implementerades pa badaplattformerna, dar bada uppfyllde kravet som fanns under ru-briken Syfte. Aven om det finns mycket mer kunde gora foratt forbattra och implementera en fullstanding second screen,har malet uppfyllts pa bada plattformerna.

Den rekommenderade plattformen blev PhoneGap, mest pagrund av att den gav tillrackligt bra resultat under prestan-datestningen och var enkel att arbeta med. OpenFL ar enstark kandidat, men fortfarande mycket som skulle behovasforbattras for att det skulle kunna anvandas for att implemen-tera en riktigt second screen.

OpenFL ar byggt for att gora spel, det marks valdigt tydligt paall dokumentation som finns, darav finns det inget storre in-tresse av att implementera ett val fungerande granssnitts han-tering. HaxeUI kan bli valdigt intressant, dock sker uppdate-ringarna allt for sallan av utvecklaren i dagslaget.

Darav rekommenderas PhoneGap, eftersom det finns mangainsticksmoduler/ramverk/verktyg for att utveckla webbappli-kationer i dagslaget, vilket kan ateranvanda i PhoneGap. Detfinns manga versioner av Cordova, dar det anvands olika te-kiner for att fa upp prestandan och gora det lattare att byggagranssnitt.

Framtida arbetenMultplattformarDet ar flera multiplattformar som namns under rubrikenMultiplattformar. Manga av dessa skulle vara intressantaoch undersoka om de ar ett alternativ for att kunna skapamultiplattform-applikationer. Eftersom det blir allt mer ut-brett bland de alternativ som anvandaren har att valja mellanpa plattformer. Vilket gor det allt svarare for utvecklare att naut till alla anvandare.

Mata prestandaFinns det battre alternativ for att kunna mata hur bra en mul-tiplattform presterar an de som anvands i detta examensarbe-te? Vilka parametrar skulle det vara och hur utvarderar dessapa ett bra satt?

KomplexitetUndersoka mojligheten om att standardiserat ett satt att matakomplexitet for en applikation/system. Just nu finns det oli-ka matt som kan anvandas for att mata just detta, men ingenstandard som avgor om nagot av dessa ar battre an det andra.Det skulle vara intressant att ta fram ett satt att avgora vilkaav dessa som ger bast resultat for hur komplext ett system ar.

REFERENSER1. Armour, P. G. Beware of Counting LOC.

Communications of the ACM - Homeland security 47, 3(2004), 21–24.

9

2. Charland, A., and Leroux, B. Mobile applicationdevelopment: web vs native. Communications of theACM 54, 5 (2011), 49–53.

3. Apache Cordova. http://cordova.apache.org/.

4. Corral, L., Janes, A., and Remencius, T. PotentialAdvantages and Disadvantages of MultiplatformDevelopment Frameworks–A Vision on MobileEnvironments. Procedia Computer Science 10 (2012),1202–1207.

5. Corral, L., Sillitti, A., and Succi, G. MobileMultiplatform Development: An Experiment forPerformance Analysis. Procedia Computer Science 10(2012), 736–743.

6. C.P, R. R., and Tolety, S. B. A study on approaches tobuild cross-platform mobile applications and criteria toselect appropriate approach. India Conference(INDICON), 2012 Annual IEEE (2012), 625–629.

7. Hartmann, G., Stead, G., and DeGani, A. Cross-platfrommobile development. Tribal (2011).

8. haxe. http://www.haxe.org/.

9. HaxeUI. http://haxeui.org/.

10. IScroll, smooth scrolling for the web.http://iscrolljs.com/.

11. Lime (Light Media Engine).https://github.com/openfl/lime.

12. ”HTML5”versus Flash: Animation Benchmarking.http://www.themaninblue.com/writing/perspective/2010/03/22/.

13. Ohrt, J., and Turau, V. Cross-Platform DevelopmentTools for Smartphone Applications. Computer 45, 9(2012), 72–79.

14. OpenFL. http://www.openfl.org/.

15. PhoneGap. http://phonegap.com/.

16. Smutny, P. Mobile development tools and cross-platformsolutions. Carpathian Control Conference (ICCC), 201213th International (2012), 653–656.

17. Annual Smartphone Sales Surpassed Sales of FeaturePhones for the Fist Time in 2013.http://www.gartner.com/newsroom/id/2665715.

18. Smartphone Users Worldwide Will Total 1.75 Billion in2014. http://www.emarketer.com/Article/Smartphone-Users-Worldwide-Will-Total-175-Billion-2014/1010536.

19. Weinberger, I. iOS SDK och PhoneGap: En jamforandeanalys av utvecklingen for en mobil app med iOS SDKoch PhoneGap. Kandidatarbete, KTH - School ofInformation and Communication Technology (ICT),2012.

10

BILAGOR

Bilaga 1: Exempel pa second screen-utseende.

Bilaga 2: Antalet rader kallkod som ar skriven for varje plattform i olika sprak.

Bilaga 3: Antal arbetstimmar for varje plattform.

Bilaga 4: Jamforelse av allokering av minne pa tablet och smartphone.

Bilaga 5: Jamforelse av hamtningstider pa tablet och smartphone.

Bilaga 6: Jamforelse av uppdateringshastighets pa tablet och smartphone.

På svenska

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under en längre tid från publiceringsdatum under förutsättning att inga extra-ordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/

In English

The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances.

The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/

© Torbjörn Kvist