EXAMENSARBETE INOM TEKNIK, GRUNDNIVÅ, 15 HP STOCKHOLM, SVERIGE 2017 Utvärdering av app-ramverk En jämförelse av JavaScript-ramverken React Native och Ionic LUDWIG HÄNDEL GUSTAV LINDSTRÖM KTH SKOLAN FÖR INFORMATIONS- OCH KOMMUNIKATIONSTEKNIK
2
Sammanfattning Denna uppsats beskriver arbetet av att jämföra och utvärdera JavaScript-ramverken React Native och Ionic, med avseende på utveckling av mobila applikationer och kriterierna prestanda, community, plugin och utvecklingsförmåga. Syftet var att jämföra React Native och Ionic för att ge ökad information och underlag vid val av JavaScript-ramverk kopplat till mobil applikationsutveckling. Kriterier na bestämdes genom en förstudie och validerades och rangordnades genom intervjuer med experter. Resultatet av denna uppsats blev väldigt jämnt med enbart ett fåtal poängs skillnad med fördel till Ionic. Båda JavaScript-ramverken är bra alternativ vid utveckling av mobila applikationer och det mest lämpade ramverket beror mycket på vilka kriterier man väljer samt hur man poängsätter kriterierna. För framtida utveckling kan kriterier och scenarier utökas ytterligare för att få ett större underlag och ett mer varierat resultat. 3
4
Abstract This degree project describes the work of comparing and evaluating the JavaScript-frameworks React Native and Ionic, with respect to mobile application development and the criteria performance, community, plugin, and evolvability. The purpose was to compare React Native and Ionic to provide increased information and support for selecting JavaScript-framework associated with mobile application development. Criteria were determined by a feasibility study and validated and ranked by interviews with experts. The result of this degree project became very even with only a few points difference with the benefit of Ionic. Both JavaScript-frameworks are good alternatives in developing mobile applications, and the most appropriate framework depends greatly on which criteria you choose and how you score the criteria. For future development, criteria and scenarios can be further expanded to get a better foundation and a more varied result. 5
6
Innehållsförteckning 1 Introduktion 7 1.1 Bakgrund 7 1.2 Problem 8 1.3 Syfte 8 1.4 Mål 9 1.4.1 Fördelar, etik och hållbarhet 9 1.5 Metod 9 1.6 Avgränsningar 10 1.7 Disposition 10 2 Teoretisk bakgrund 11 2.1 Ramverk 11 2.2 JavaScript 11 2.2.1 JavaScript i mobila applikationer 12 2.3 Native 12 2.4 Hybrid 12 2.5 Databindning 13 2.6 Mjukvaruarkitektur 14 2.7 Ionic 15 2.8 React Native 15 2.9 Relaterat arbete 16 3 Metoder 17 3.1 Översikt 17 3.2 SACAM - The Software Architecture Comparison Analysis Method 17 3.3 Intervju 18 3.4 Prestandatestning 19 3.4.1 Ändra innehåll 20 3.4.2 Databindning 20 3.4.3 Resursallokering 20 3.4.4 Verktyg 20 3.5 Community 21 3.6 Plugin 22 3.7 Utvecklingsförmåga 22 4 Resultat 24 4.1 Resultat av Intervjuer 24 4.2 Resultat av Litteraturstudien 25 4.3 Kriterier slutsats 26 7
5 Jämförelse av ramverk 28 5.1 Prestanda 28 5.2 Community 32 5.3 Plugin 33 5.4 Utvecklingsförmåga 34 5.5 Summering av resultat 35 6 Slutsats 39 7 Diskussion 40 8 Framtida arbete 41 9 Referenser 42 8
Ordlista Objektorienterad: Data som hör ihop på något sätt och de instruktioner som används för att bearbeta just dessa data. Kompilera : Översätta programmeringskod till maskinkod som kan exekveras av en dator. DOM (Document Object Model) : Representation av objekt och struktur inom ett HTML-dokument. Webbvy : Webbvy används för att ladda och visa webbinnehåll samt tillhandahålla grundläggande webbläsarfunktioner som navigationshistorik och en JavaScript-exekveringsmiljö. Experter : Personer som arbetar heltid med mobila applikationsutveckling. Android: Android är ett mobilt operativsystem främst för smartphones som utvecklats av Android Inc. ios: Är ett mobilt operativsystem utvecklat av Apple som används på enheterna iphone, ipad och ipod touch. API (Application Program Interface): Används för att dela med sig av data på ett kontrollerat sätt mellan t.ex en app och en server. Öppen källkod: Datorprogram vars källkod är tillgänglig att använda, läsa och modifiera för den som vill. HTML ( HyperText Markup Language) : HTML ger möjlighet att ange ett dokuments struktur. CSS(Cascading Style Sheets) : CSS är ett språk som beskriver layouten av ett HTML-dokument. Apache Cordova : Apache Cordova är ett ramverk som möjliggör för programmerare att bygga applikationer för mobila enheter som använder CSS3, HTML5 och JavaScript. Rendera: Den beräkning som ett datorprogram utför för att framställa en bild eller beräkna var olika element ska placeras på vyn. 9
10
1 Introduktion Det första kapitlet introducerar bakgrunden till denna uppsats. En beskrivning av problemet, metod, etik, syfte, avgränsning och uppsatsens mål presenteras. 1.1 Bakgrund När detta arbete skrevs fanns det många[1] olika tillvägagångssätt och hjälpmedel för att utveckla mobila applikationer (appar). Ett tillvägagångssätt som är och blivit mer populärt[2] är att utveckla mobila applikationerna i programmeringsspråket JavaScript. En anledning till att JavaScript blivit allt mer populärt är för att de alternativa tillvägagångssätten är väldigt kostsamma att utveckla, det kräver att man utvecklar specifikt för varje enskild plattform[3], exempelvis ios och android. Att utveckla för en specifik plattform gör det ofta svårt att återanvända kod på olika plattformar. En följd av att JavaScript har blivit ett mer populärt tillvägagångssätt vid utveckling av mobila applikationer är att det utvecklats flera olika alternativa JavaScript-ramverk(JS-ramverk), t.ex React Native och Ionic. Ramverket utgör grunden för applikationens struktur och kan ses som en halvfärdig applikation[4] som utvecklaren sedan anpassar och bygger vidare på efter egna önskemål. Det växande[1] antalet JS-ramverk har gjort det svårt för dagens utvecklare att välja det mest lämpliga ramverket för utveckling av mobila applikationer. Val av ett mindre lämpligt ramverk kan resultera i exempelvis dålig prestanda hos mobilapplikationen och risk för bristande underhåll av ramverket i framtiden[57]. Vid tiden för det här arbetet fanns det flera olika alternativ för att utvärdera och jämföra olika mjukvaruarkitekter såsom jämförelsemetoden SACAM[5]. Det existerar för tillfället ingen etablerad metod som är specifikt anpassad med fokus på mobil applikationsutveckling vilket gör en jämförelse av denna typ mer komplex. Under detta arbete används de engelska orden community, native och plugin eftersom det inte fanns några svenska motsvarigheter till dessa ord. 11
1.2 Problem Det fanns år 2017 ett antal[6] olika JS-ramverk anpassade för apputveckling. Det är ofta svårt[7] att utvärdera, jämföra och välja rätt ramverk eftersom JS-ramverk ofta är väldigt komplexa. Det fanns inga tydliga gemensamma nämnare att jämföra[8]. Denna uppsats fokuserar på kriterierna prestanda, community, plugin och utvecklingsförmåga. Dessa kriterier har val ts ut genom en litteraturstudie. Kriterierna evalueras mot JS-ramverken React Native och Ionic, eftersom de är byggda på toppen av de populäraste JS-ramverken när detta skrevs(2017-05-23) [6]. Problem med att i förtid välja ut kriterier kan leda till irrelevanta kriterier och kan bidra till en missvisande bild om ramverkets förmågor. Intervjuer och litteraturstudie bidrog till underlag för att verifiera om de förutbestämda kriterierna var relevanta eller ej. Denna rapport avser att besvara frågeställningen: Hur jämförs JavaScript-ramverken React Native och Ionic mod varandra med avseende på kriterierna prestanda, community, plugin och utvecklingsförmåga? 1.3 Syfte Syftet med arbetet var att jämföra React Native och Ionic för att ge ökad information och underlag vid val av JS-ramverk kopplat till mobil applikationsutveckling. Arbetet lyfter fram kriterierna prestanda, community, plugin och utvecklingsförmåga. Dessa används för att evaluera ramverkets egenskaper. Baserat på resultatet av arbetet, dra en slutsats om vilket ramverk som är bäst lämpa t för det valda syftet. 12
1.4 Mål Målet är att det avslutade arbetet ska kunna användas som underlag vid beslut av vilket JS-ramverk av React Native och Ionic som är lämpligast att använda vid utveckling av mobila applikationer. 1.4.1 Fördelar, etik och hållbarhet Det etiska effekterna av denna uppsats kan vara att studien utformas och kriterier väljs ut med fördel för ett visst ramverk. För att undvika etiska problem under intervjuerna informerades deltagarna om syftet med uppsatsen och hur deras svar skulle användas. Deltagarna fick även information om att svaren skulle hållas anonyma och det säkerställdes genom att inte nämna några enskilda svar eller namn i denna rapport. Resultatet av denna uppsats syftar till att ge ökad information och underlag vid val av JS-ramverk kopplat till mobil applikationsutveckling. Ur ett ekonomiskt perspektiv kan denna uppsats spara tid och resurser för de som vill jämföra React Native och Ionic med hänsyn till samma kriterier. 1.5 Metod Under denna uppsats användes intervjuer och litteraturstudier för att samla in information och data. Den insamlade informationen användes sedan som underlag för att styrka eller motsäga de förutbestämda kriterierna prestanda, community, plugin och utvecklingsförmåga. Litteraturstudien och intervjuerna står för den kvalitativa delen av uppsatsen. Nästa steg var att tillämpa existerande utvärderingsmodeller som utgjorde grundstrukturen i jämförelse av JS-ramverken. Dessa modeller användes för att hitta en gemensam abstraktionsnivå för alla ramverk. Genom en gemensam abstraktionsnivå blev det enklare att evaluera de förutbestämda kriterierna. Praktiska tester utfördes för att demonstrera hur de insamlade kriterierna kunde jämföras mellan React Native och Ionic. 13
När detta skrevs fanns det redan etablerade metoder för att jämföra olika mjukvaruarkitekter såsom Software Architecture Comparison Analysis Method (SACAM). Under denna uppsats utgjorde SACAM grunden för jämförelsen mellan JS-ramverken. 1.6 Avgränsningar Denna uppsats fokuserar enbart på JS-ramverken React Native och Ionic. Mobila applikationer har vanligtvis en klientsida och en serversida där serversidan ansvarar för att leverera data till mobilapplikationen medan klientsidan ansvarar för kommunikationen till användaren. Denna uppsats fokuserar endast på klientsidan av mobila applikationen. Mobila applikationer kan ha olika prioriteringar angående vilka kriterier som är viktigast. Denna uppsats fokuserar på fyra förutbestämda kriterier som validerats genom litteraturstudier och intervjuer med experter. 1.7 Disposition I kapitel 1 introducerar bakgrunden till detta arbete. En grundläggande beskrivning av problemet, metod, etik, syfte, avgränsning och uppsatsens mål presenteras. I kapitel 2 förklaras den teoretiska bakgrunden som ger grundläggande kunskap inom ämnet för att förstå vad som presenteras i fortsättningen. I kapitel 3 presenteras metoder och tillvägagångssätt som använts under examensarbetet. I kapitel 4 presenteras resultatet från litteraturstudien och intervjuerna. Resultatet från kapitel 4 används sedan i kapitel 5 där React Native och Ionic jämförs mot de förutbestämda kriterierna. I kapitel 6 presenteras resultatet och slutsatser dras. Kapitel 7 består av en diskussion och framtida arbeten behandlas i det avslutande kapitel 8. 14
2 Teoretisk bakgrund I detta kapitel presenteras en detaljerad beskrivning av bakgrunden till examensarbetet tillsammans med relaterat arbete. 2.1 Ramverk Med ökande storlek och komplexitet av mjukvaruramverk, är det nödvändigt att använda någon slags grundarkitektur för att definiera och organisera alla komponenter i en applikation [9]. Enligt Dirk Riehle, Ph.D, Swiss Federal Institute of Technology [10] strävar ett ramverk efter att ge högre produktivitet under utvecklingen och för att snabbare kunna lansera sin tjänst genom återanvändning av kod och inbyggd funktionalitet i ramverket. 2.2 JavaScript JavaScript är ett programmeringsspråk som mestadels används på webben[11]. På senare år har det blivit mer och mer populärt att använda JavaScript inom andra användningsområden såsom mobila applikationer[3]. Till skillnad från andra programmeringsspråk såsom C, kompileras JavaScript och exekveras på klientens enhet istället för på webbservern [11]. JavaScript bäddas vanligtvis in i HTML-webbsidor, det kallas då client side JavaScript [11]. Vid tiden för det här arbetet fanns det flera typer av tillägg till JavaScript som utökar funktionaliteten i programmeringsspråket och gör det lättare att skriva och läsa kod. Några etablerade tillägg som fanns år 2017 är JSX[12] och Typescript[13]. JSX gör det möjligt att skapa DOM element med JavaScript genom HTML-liknande syntax[14]. Syftet med JSX är att kunna skapa DOM element som möjliggör att använda välbekant syntax för att definiera trädstrukturer[12] med JavaScript. Typescript syftar till att göra det lättare att utveckla storskaliga JavaScript applikationer[15]. Dagens webbläsare kan inte exekvera kod som är skriven i JSX, Typescript eller i liknande tillägg. Istället måste koden kompileras till vanlig JavaScript. 15
2.2.1 JavaScript i mobila applikationer JS-ramverk anpassade för mobila applikationer erbjuder möjligheten att kommunicera med telefonens hårdvara som t.ex GPS, bluetooth och kamera med mera[3]. Kommunikationen mellan JavaScriptet och telefonens hårdvara sker genom en så kallad Bridge [3] som anropar plattformsspecifik-kod som utför anropet till hårdvaran och sedan returnerar resultatet tillbaka till JavaScriptet[2]. 2.3 Native Native applikationer är applikationer som är utvecklade för en specifik plattform, exempelvis ios och Android. Applikationerna körs direkt på telefonens hårdvara och kan dra nytta av telefonens resurser. Eftersom applikationen har full tillgång till telefonens hårdvara kan den utnyttja operativsystems funktionalitet och utföra flera beräkningar parallellt vilket leder till högre prestanda[3]. Nackdelen med native applikationer är att dem kan vara svåra att utveckla och underhålla[3]. 2.4 Hybrid Hybridapplikationer utvecklas med hjälp av HTML, CSS och JavaScript[2]. Fördelen med att använda HTML, CSS och JavaScript är att det gör applikationen plattformsoberoende[2] och lättare att utveckla och underhålla[3]. Hybridapplikationer använder sig av Webbvy[3] som utgör ett gränssnitt mellan den plattformsspecifika koden och JavaScript-koden och kan med hjälp av JavaScript utföra anrop för att kommunicera med telefonens operativsystem, se figur 1. Till skillnad från native applikationer exekveras hybrida applikationer på samma sätt som en webbsida i webbläsaren. Det innebär att applikationen inte kan utföra beräkningar parallellt utan måste exekvera kod sekventiellt[16]. Detta kan leda till sämre prestanda och att applikationen upplevs långsam. 16
2.5 Databindning Figur 1. JavaScript i mobila applikationer Databindning är en vanlig teknik som de flesta JavaScript ramverk erbjuder i någon form[17]. Databindning innebär att alla datarelaterade förändringar som påverkar en applikationsmodell och dess objekt omedelbart avspeglas i motsvarande vy eller vyer. Det finns två typer av databindningar. Den ena kallas envägs databindning som erbjuder en envägskommunikation mellan modellen och vyn, se figur 2. Denna typ av databindning används på serversidan av webbapplikationer där modellens data sammanfogas med sidans design-mall innan den levereras till användaren[18]. Figur 2. Envägs databindning 17
Den andra databindningen är tvåvägs databindning som gör det möjligt att spåra ändringar i båda riktningarna, se figur 3. Element kan då samla data från användaren för att därefter ändra tillståndet i applikationens modell[19]. Figur 3. Tvåvägs databindning 2.6 Mjukvaruarkitektur Syftet med mjukvaruarkitektur är att skapa en struktur och modell för applikationen och att bryta ner applikationen i mindre, mer överskådliga delar. Målet med mjukvaruarkitektur är att systematiskt föra samman specifikationer från slutanvändaren, företaget och de tekniska riktlinjerna för mjukvaruarkitektur[20]. Figur 4[21] visar sambandet mellan alla intressenters krav. Framförda specifikationer kan till exempel vara säkerhet, prestanda eller modifierbarhet. Figur 4. Användarmål, affärsmål och systemmål 18
Arkitekturen utgör grunden för systemets kvaliteter såsom prestanda, modifierbarhet, och säkerhet. Dessa krav kan inte uppnås utan en förenande syn på syftet med arkitekturen[22]. Det är avgörande att välja en bra mjukvaruarkitektur i början av utvecklingen eftersom det är väldigt svårt att byta arkitektur i efterhand[23]. 2.7 Ionic Ionic är ett öppet källkodsramverk för hybrid apputveckling och är en av de mest använda hybridramverken[24]. Ionic bygger på JS-ramverket Angular 2 och gör det möjligt att utveckla hybrida mobilappar med hjälp av webbtekniker som CSS, HTML5 och JavaScript. Dessa ramverk befinner sig på toppen av Apache Cordova, vilket gör det möjligt för webbapplikationen att utnyttja enhetens inbyggda kapacitet och fungera som en installerad app på telefonen[25]. I och med att Ionic är byggd ovanpå Angular 2 används tillägget Typescript för att strukturera och organisera JavaScript-koden i appen. Eftersom Ionic körs direkt i en Webbvy är det möjligt att använda samma kod på flera olika plattformar. Apache Cordova har stöd för 8 olika plattformar(2017-05-10)[26]. 2.8 React Native React Native är ett JS-ramverk för att skriva JavaScript som sedan renderas till plattformsspecifik-kod för mobila applikationer. Det bygger på React som är ett JavaScript-bibliotek utvecklat av Facebook för att bygga användargränssnitt. I stället för att rikta in sig på webbläsaren riktar sig React Native mot mobila plattformar[27]. React Native har när detta skrevs(2017-05-10) stöd för operativsystemen ios and Android. Med React Native bygger du inte en mobilwebapp, en HTML5-app eller en hybridapp utan en app med native gränssnittskomponenter som styrs med JavaScript[28]. Likt React på webben, skrivs appar i React Native med en blandning av JavaScript och XML-syntax, känd som JSX. React Native anropar sin Bridge som renderar de skrivna komponenterna till plattformsspecifika komponenter. React Native-appar har även ett API för att komma åt plattforms funktioner som telefonkamera eller användarens position[27]. 19
React Native fokuserar på rendering av användargränssnitt[29], vilket innebär att React Native ofta används tillsammans med ytterligare ett ramverk, till exempel Redux [30] eller Flux[31] som har hand om logiken i applikationen. 2.9 Relaterat arbete Denna sektion beskriver relaterade arbeten inom området mobila applikationer och JS-ramverk. Spyros Xanthopoulos och Stelios Xinogalos[32] utvärderar och beskriver ett sätt att jämföra mobila plattformsoberoende appar i arbetet A Comparative Analysis of Cross-platform Development Approaches for Mobile Applications. Gemensamt med denna uppsats är att de utgår från förutbestämda kriterier. Ett av de utvalda kriterierna är prestanda som anses viktigt för en applikation. Ville Ahti, Sami Hyrynsalmi och Olli Nevalainen[33] beskriver i uppsatsen An Evaluation Framework for Cross-Platform Mobile App Development Tools: A case analysis of Adobe PhoneGap framework hur native och hybridapplikationer kan utvärderas och jämföras. Gemensamt med denna uppsats är det valda kriteriet prestanda där RAM-minnet på telefonen analyseras. I uppsatsen Comparison of Single-Page Application Frameworks A method of how to compare Single-Page Application frameworks written in JavaScript beskriver Erik Molin en metod för att jämföra olika JS-ramverk. Metoden SACAM används och gemensamt med denna uppsats analyseras kriterierna prestanda och community. Erik Molin använder intervjuer för att samla in information angående vilka kriterier som är viktiga vid val av ramverk. Federico Botella, Pedro Escribano och Antonio Peñalver utvärderar i uppsatsen Selecting the best mobile framework for developing web and hybrid mobile apps vilket ramverk som är bäst lämpad för mobil apputveckling. Gemensamt med denna uppsats är att de jämför ramverket Ionic, kriteriet Plugin och använder sig av ett poängsystem där de viktar de olika kriterierna. De relaterade arbeten utgjorde ett underlag för att bekräfta de utvalda kriteriernas betydelse och gav oss en bra indikation på dess relevans. Det gav även förslag på möjliga metoder för att testa och utvärdera dessa kriterier. 20
3 Metoder I detta kapitel b eskrivs forskningsmetodiken och metoderna som används i arbetet. 3.1 Översikt I detta arbete användes kvalitativa metoder för att samla in relevant information och data. Intervjuer, litteraturstudier och praktiska tester utgjorde den kvalitativa delen av uppsatsen. Första steget i processen var att undersöka tidigare existerande metoder och jämförelser inom mjukvaruarkitektur för att få en överblick inom ämnet. Resultatet av den första litteraturstudien resulterade i ett antal potentiella jämförelsemetoder att använda i denna uppsats. Nästa steg var att utföra djupare litteraturstudier inom de områden som undersökt under första steget. Litteraturstudier tillsammans med intervjuer med experter utgjorde ett underlag för att bekräfta de utvalda kriterierna. Till varje kriterium togs ett antal scenarier fram för att på ett systematiskt sätt utvinna relevant information som utgjorde underlaget i jämförelsen av React Native och Ionic. 3.2 SACAM - The Software Architecture Comparison Analysis Method Vid tiden för det här arbetet fanns det redan etablerade metoder för att jämföra olika mjukvaruarkitekter. I detta arbete används SACAM som grund för jämförelsen mellan de olika JS-ramverken. Jämförelsemetoden SACAM används när man vill avgöra vilken mjukvaruarkitektur som är bäst lämpad av olika kandidater. Metoden jämför arkitekturer baserat på en rad kriterier som tas fram utifrån affärsmålen i en organisation[34]. SACAM fokuserar på att jämföra arkitekturer av programvarusystem och inte själva implementationen av koden[34]. SEI ( Software Engineering Institute) beskriver tre stora fördelar med SACAM som jämförelsemetod. Den första fördelen är att SACAM erbjuder en kvalitativ metod som ersätter beslut grundade på intuition med ett analytiskt ramverk. Den andra fördelen är att kriterierna som samlas in genom SACAM är strategiskt målinriktade. Likheter och skillnader kring olika arkitekturer samlas in och tolkas mot de 21
insamlade kriterierna. Den tredje fördelen är att SACAM ger möjligheten att jämföra arkitekturkandidater på en mer hanterbar abstraktionsnivå med fokus på organisationens affärsmål. Alternativa metoder jämförelsemetoder undersöktes även, såsom SAAM och ATAM. SAAM (Software Architecture Analysis Method) fokuserar på att utvärdera ett enskilt ramverk och valdes därför bort som potentiell jämförelsemetod[58]. ATAM (Architecture Tradeoff Analysis Method) används för utvärdera ett ramverket genom att fokusera på svagheterna[59]. Även denna metod används för utvärdera ett enskilt ramverk och valdes därför bort. Anledningen till att SACAM användes som den primära jämförelsemetoden var för att det enligt Software Engineering Institute [34] är en etablerad metod som på ett konkret och strukturerat sätt gör det möjligt att jämföra olika mjukvaruarkitekter. En mjukvaruarkitekturjämförelse är nödvändig när organisationer måste välja mjukvaruarkitekter från en uppsättning kandidatarkitekturer enligt Software Engineering Institut [34]. 3.3 Intervju Syftet med intervjuer i detta arbete var att verifiera de förutbestämda kriterierna och rangordna dessa baserat på hur viktiga de är för ett JS-ramverk. Intervjuer kan antingen utföras på ett kvalitativt eller kvantitativ sätt. Intervjuerna i detta arbete är utförda på ett kvalitativt sätt[35] genom öppna frågor till de deltagande och uppmaningar till att tala fritt. Under intervjuerna noterades viktiga nyckelord. Kraven på företagen som kontaktades var att de skulle arbeta med apputveckling professionellt och att den medverkande personerna skulle ha en beslutsfattande roll inom företaget. För att hitta potentiella företag användes sökmotorn Google med sökordet Apputveckling, de 20 första företagen som uppfyllde urvalskriterierna kontaktades med förfrågan om att medverka i en intervju om apputveckling. Av de 20 förfrågningar som skickades ut tackade sju företag ja, sedan valdes fyra olika företag utifrån olika affärsområden för att undvika branschspecifika kriterier. Alla representanter medverkade frivilligt med löfte om att deras svar skulle hållas anonyma. Innan intervjuerna startade informerades deltagarna om syftet med uppsatsen och hur deras svar skulle användas för att undvika etiska problem. Intervjuerna avslutades genom att varje expert ombads att poängsätta vikten av varje kriterium med ett poäng mellan 0-100. 22
Det fanns flera alternativa metoder för att ta fram information för underlag i urvalet av kriterier. I detta arbete valdes intervjuer som metod eftersom det erbjöd en mer personlig kontakt gentemot enkäter och möjligheten att formulera motfrågor som dessutom resulterar i ytterligare information[35]. 3.4 Prestandatestning Prestandatestning utfördes för att bestämma hur ett system presterar vad gäller respons och stabilitet under en viss arbetsbelastning. Det kan också användas för att undersöka, mäta, validera eller verifiera kvalitetsattribut av systemet, såsom skalbarhet, tillförlitlighet och resursanvändning[36]. För att kunna jämföra kriteriet prestanda utformades tre stycken olika scenarier baserat på litteraturstudien, se nedan. Mätpunkter i de tre scenarierna valdes inom ett område där man kunde påvisa en tydlig skillnad mellan ramverken. 625, 1250, 2500, 5000 För att bestämma mätpunkter utgick testerna från startvärdet 5000 från föregående scenario. Vid 5000 noterades en tydlig skillnad mellan ramverkens prestanda. Därefter halverades antalet objekt på grund av den tydliga skillnaden vid mätpunkten 5000. Start värdet resulterade i 625 objekt. Detta arbete använde sig av Microsofts[36] rekommenderade tillvägagångssätt för att genomföra prestandatestning. Denna metod valdes ut eftersom den är framtagen av ett stort etableras företag med hög trovärdighet samt att den bidrog till förenklad struktur genom att dela upp aktiviteter i 7 olika faser. 1. Identifiera testmiljö 2. Identifiera accepterande prestandakriterier 3. Planera och designa test 4. Konfigurera testmiljön 5. Implementera testdesignen 6. Utför testet 7. Analysera resultat, rapportera och testa igen De sju faserna utgör en strukturerad och konkret grund för prestandatestning. Metoden är framtagen för en generell prestandatestning och kan anpassas med egna aspekter beroende på testets syfte. 23
Testerna utförda i sektion 5.1.1 till 5.1.3 är utförda på följande enhet: Modell : iphone 7 Operativsystem : ios 10.3 Processor : Quad-core 2.34 GHz RAM : 2GB 24
3.4.1 Ändra innehåll Tiden det tar för en app att rendera innehållet på en vy är väldigt viktigt och ger känslan av en snabb och responsiv app. Det fanns flera olika tillvägagångssätt att testa detta. Testet i detta arbete utfördes genom att rendera 5 000, 10 000, 15 000 och 20 000 rader. För att bestämma mätpunkter utgick testerna från 1000 objekt och ökade därefter successivt med 1000 objekt tills en skillnad kunde noteras mellan ramverken. Start värdet resulterade i 5000 objekt. Därefter ökade vi intervallerna med 5000 värden. Resultatet mäts i millisekunder för den tid de tar för varje enskilt JS-ramverk att rendera vyn. Scenariot som ska besvaras är: Hur lång tid tar det för ramverket att rendera en stor mängd objekt? 3.4.2 Databindning Tiden det tar för ett ramverk att ändra element på en vy är en viktig faktor i hur snabb och responsiv en app upplevs. I detta arbete testas databindningar genom att ändra 625, 1250, 2500 och 5000 rader och mäta hur snabbt databindningar reflekteras mellan vyn och data-objekten. För att bestämma mätpunkter utgick testerna från startvärdet 5000 från föregående scenario. Vid 5000 noterades en tydlig skillnad mellan ramverkens prestanda. Därefter halverades antalet objekt på grund av den tydliga skillnaden vid mätpunkten 5000. Start värdet resulterade i 625 objekt. Scenariot som ska besvaras är: Hur lång tid tar det för ramverket att ändra en stor mängd objekt? 3.4.3 Resursallokering En mobil enhet har begränsade resurser i form av RAM och processorkapacitet. Därför är det extra viktigt att JS-ramverket drar nytta av mobilens resurser på ett effektivt sätt. Att använda ett ramverk som inte hanterar resurserna varsamt kan leda till en långsammare app och kortare batteritid. I detta arbete testades ramverkets resursallokering genom att utveckla en enkel prototyp som utförde en specifik uppgift. Testet utfördes genom att ändra 625, 1250, 2 500 och 5 000 rader. Mätpunkterna valdes ut på samma sätt som i sektion 3.4.2. Scenariot som ska besvaras är: Hur mycket RAM använder appen för att ändra en stor mängd objekt? 25
3.4.4 Verktyg Prestandatesterna utfördes genom att registrera två tidsstämplar i applikation, starttid och sluttid. Starttid registrerades när uppgiften påbörjades och sluttiden registrerades när uppgiften var slutförd. Resultatet tas fram genom att ta skillnaden mellan sluttiden och starttiden det ger ett snabbt och effektivt sätt att jämföra tiden mellan två händelser. För att undersöka resursallokering i form av RAM-minne användes Apples utvecklarverktyg Xcode[37]. Alla tester har utförts på en iphone 7 med det senaste operativsystemet ios 10.3. Telefonen hade en processor med Quad-core 2.34 GHz och 2GB RAM. 3.5 Community Ett ramverks community är de individer som använder och bidrar med information och material till ramverkets utveckling. Detta påverkar hur lätt du kan hitta information online, svar på dina frågor eller få buggar åtgärdade. För att kunna jämföra kriteriet community utformades tre stycken olika scenarier baserat på litteraturstudien, se nedan. Stjärnor på GitHub GitHub är en av världens ledande mjukvaruutvecklingsplattform[55]. Har ramverket många stjärnor på GitHub betyder det att många använder, följer och engagerar sig kring ramverket. Det kan leda till en högre frekvens av uppdaterade versioner och snabbare buggfixar. Antalet stjärnor lästes av genom att gå in på varje ramverks GitHub-sida och undersöka de aktuella antalet stjärnor. Scenariot som ska besvaras är: Hur många stjärnor har ramverket på GitHub? Frågor på Stack Overflow Problem är sällan unika och chansen är stor att andra personer har haft liknande problem. Stack Overflow är det största online-samhället för programmerare att lära sig, dela sin kunskap och fördjupa sina karriärer[56]. Stack Overflow kan hjälpa till att lösa problem vilket sparar tid. Antalet frågor behöver inte vara positivt men kan ge en indikation på storleken på ramverkets användarbas. Antalet frågor undersöktes genom att läsa av antalet resultat av söksträngarna react native och ionic. Scenariot som ska besvaras är: Hur många frågor fanns det kring ramverket på Stack Overflow? 26
Google-sökningar på ramverket Med hjälp av Google Trends kan man läsa av hur många sökningar det gjorts på ett specifikt ramverk. Det kan ge en indikation om intresset för ramverket är på väg upp eller ner och hur populärt det är för tillfället. Resultatet begränsades till tidsspannet 2015-01-01 till och med 2017-05-09 eftersom det var då React Native presenterades[41]. Google Trends ger ej svar på exakta antal sökningar utan enbart relationen mellan olika sökningar. Antalet google-sökningar undersöktes genom att läsa av resultatet av söksträngarna react native och ionic. Resultatet blir en siffra mellan 0-100. Scenariot som ska besvaras är : Antal Google-sökningar på ramverket? 3.6 Plugin Plugins gör det enkelt för JavaScript-utvecklare att dela kod som de har skapat för att lösa särskilda problem och för andra utvecklare att återanvända den koden i sina egna applikationer[38]. I detta arbete undersökt antalet plugins på plattformen NPM ( Node Package Manager) för respektive JS-ramverk, eftersom NPM är världens största programvaruregister[39]. Antal plugins Antalet plugins undersöks på plattformen NPM ( Node package manager) för respektive JS-ramverk. NPM är världens största programvaruregister[39]. Antalet plugins undersöktes genom att läsa av antalet plugins av söksträngarna react native och ionic. Scenariot som ska besvaras är : Hur många plugins har ramverket? 3.7 Utvecklingsförmåga Utvecklingsförmåga handlar om ramverkets framtida utveckling. Utvecklingsförmåga är relevant eftersom det är viktigt att använda ett ramverk som fortfarande är konkurrenskraftigt och utvecklas kontinuerligt för att ge stöd för de senaste funktionerna och operativsystemen. I detta arbete undersöks utvecklingsförmågan med hänsyn till ramverkets licens genom antal personer som bidrog till ramverkets framtida utveckling på GitHub och antalet arbetstillfällen kopplade till ramverket. Arbetstillfällen jämfördes genom att undersöka antalet jobbannonser på LinkedIn. För att kunna jämföra kriteriet utvecklingsförmåga utformades tre stycken olika scenarier baserat på litteraturstudien, se nedan. 27
Öppen källkod Många utvecklare hjälps åt och driver utvecklingen framåt. Det kan öka framtidsutsikterna för ett ramverk. Öppen källkod har föreslagits av vissa författare som en lösning till ett mindre beroende av andra parter[60]. Scenariot som ska besvaras är : Består ramverket av öppen källkod? Bidragit med kod på GitHub Om många personer bidrar med kod till JS-ramverket minskar risken att ramverket dör ut[61]. Det kan även leda till en högre frekvens av uppdaterade versioner och snabbare buggfixar. Antalet som bidragit med kod lästes av genom att gå in på varje ramverks GitHub-sida och undersöka de aktuella antalet bidragare. Scenariot som ska besvaras är : Antal personer som har bidragit med kod på GitHub? Hur många jobbannonser nämns ramverket i på LinkedIn? Antal jobbannonser relaterade till ett ramverk leder till att fler intresserar sig för ramverket eftersom det finns en tydlig efterfrågan av kompetens inom området. Antalet jobbannonser undersöktes genom att läsa av resultatet av söksträngarna react native och ionic. Scenariot som ska besvaras är : Hur många jobbannonser nämns ramverket i på LinkedIn? 28
29
4 Resultat I detta kapitel presenteras och sammanställs resultatet av litteraturstudien och intervjuerna. 4.1 Resultat av Intervjuer Intervjuer i detta arbete samlade in information och relevanta kriterier kopplade till utveckling av mobila applikationer. En utförlig beskrivning av intervjuprocessen finns i sektion 3.3. Intervjuerna utfördes med experter från Viaplay, MTG, Semcon och Mobile Interaction. Den spridda inriktningen av olika företag och representanternas arbetsuppgifter gjordes med avsikt för att minska effekten av branschspecifika kriterier. Under intervjuprocessen identifierades ett antal olika kriterier som företagens representanter ansåg vara viktiga, nedan presenteras kriterierna utan viktning. Säkerhet Prestanda Kostnad Community Licens Mognad Framtid Modularitet och plugins Lärbarhet Portabilitet Dokumentation 30
4.2 Resultat av Litteraturstudien Efter litteraturstudien valdes SACAM ut som jämförelsemetod. Den gör det möjligt att på ett konkret och strukturerat sätt jämföra olika mjukvaruarkitekter. En utförlig beskrivning av SACAM finns i sektion 3.2 och SACAMS 6 olika utvärderingsfaser är illustrerade i figur 5. Figur 5. Överblick av SACAM Enligt författarna av The Software Architecture Comparison Analysis Method [40] föreslås användningen av affärsmål som en bas för att samla in kriterier. Utan tydliga affärsmål är det svårt att utföra en jämförelse mellan olika ramverk med hjälp av SACAM. Affärsmålen som användes i detta arbete är framtagna genom intervjuer med experter. Scenariobaserad jämförelse används för att kunna jämföra varje enskilt ramverk mot varje specifikt kriterium. Dessa scenarier är specifika och kan variera från projekt till projekt, så de kan inte användas i ett allmänt fall. Poängsystemet utgör en viktig del i SACAM. Formuleringen av poängsystemet och prioriteten av olika kriterier ligger till grund för resultatet av jämförelsen. Därför är det viktigt att i början av jämförelsen tydligt specificera hur varje kriterium ska rangordnas. De förutbestämda kriterier i detta arbete, prestanda, plugin, community och utvecklingsförmåga rangordnades utifrån intervjuer med experter. 31
4.3 Slutsats av Kriterier Detta arbete utgår från fyra förutbestämda kriterier, prestanda, community, plugin och utvecklingsförmåga. De utvalda kriterierna stämde överens med det kriterier som nämndes under intervjuerna, se sektion 4.1. För att kunna jämföra olika ramverk mot varandra med hjälp av ett poängsystem sammanfattades resultatet av intervjuerna. Kriterierna viktades med hjälp av resultatet från intervjuerna och 100 poäng fördelades mellan de fyra kriterierna. Se figur 6 för exakt poängfördelning. Poängen fördelades procentuellt i relation till det vinnande ramverket i varje enskilt scenario. Vid flera mätningar dras ett snittvärde från resultaten. Enligt SACAMs jämförelsemodell[40] är det upp till kunden hur varje kriterium ska fördelas i ett poängsystem. I detta arbete utgjordes kunden av en summering av intervjuer med experter. Till exempel, i ett scenario som representerar 10 poäng får det vinnande ramverket 10 poäng och det förlorade ramverket får en procentuell del i relation till det vinnande ramverket. Prestanda var det kriterium som nämndes som det viktigaste kriteriet av alla företag. Det var viktigt att en app upplevdes snabb och responsiv för att ge en så bra användarupplevelse som möjligt. Kriterierna licens, mognad och framtid nämndes alla som viktiga kriterier för val av ramverk. Det är alla kopplade till ramverkets utvecklingsförmåga och grupperades därför ihop. Utvecklingsförmåga är relevant eftersom det är viktigt att använda ett ramverk som fortfarande är konkurrenskrafti gt och utvecklas kontinuerligt för att ge stöd för de senaste funktionerna och operativsystemen. Säkerhet och kostnad är två kriterier som nämndes som viktiga men som inte bearbetas i detta arbete. Säkerhet tas inte upp i detta arbete eftersom det är ett väldigt stort och omfattande kriterium med många aspekter att ta hänsyn till. Under intervjuerna lyftes community fram som ett viktigt kriterium. Community kan användas som ett hjälpmedel när dokumentationen är bristande eller om man stött på problem. Plugins var ett kriterium som inte nämndes under intervjuerna, men som ändå är relevant vid utveckling av appar med JavaScript. Plugins gör det enkelt för JavaScript-utvecklare att dela kod och för andra utvecklare att återanvända den koden i deras egna applikationer. 32
Figur 6. Poängfördelning Detta är inte ett generellt koncept som kan appliceras på alla jämförelser utan specifikt framtagen mot resultatet av intervjuerna som utfördes i detta arbete. 33
5 Jämförelse av ramverk I detta kapitel jämförs React Native och Ionic mot de kriterier som presenteras i kapitel 4. Se även sektion 2.8 och 2.7 för information om React Native och Ionic. Ramverkens version React Native - Version 0.44. 2017-05-01 Ionic - Version 3.1.1. 2017-04-28 - Apache Cordova version: 7.0 2017-05-04 5.1 Prestanda I detta avsnitt presenteras den praktiska jämförelsen. Detta görs genom att presentera och illustrera resultaten från prestandatesterna. 34
Hur lång tid tar det för ramverket att rendera en stor mängd objekt? Figur 7. Tiden det för att rendera ett visst antal objekt Antal objekt React Native (ms) Ionic (ms) 5 000 54 1 042 10 000 56 2 009 15 000 65 3 473 20 000 76 6 016 Snitt 62.75 3 135 Tabell 1. Resultatet från mätningen av renderingstid 35
Hur lång tid tar det för ramverket att ändra en stor mängd objekt? Antal Objekt Figur 8. Tiden det tar att ändra en stor mängd objekt Antal objekt React Native (ms) Ionic (ms) 625 385 4 1 250 779 7 2 500 1 462 15 5 000 3 005 57 Snitt 1 352 20,5 Tabell 2. Resultatet från mätningen av ändring av objekt 36
Hur mycket RAM använder appen för att ändra en stor mängd objekt? Antal Objekt Figur 9. Mängden RAM en app allokerar vid ändring av en mängd objekt Antal objekt React Native (mb) Ionic (mb) 625 182 209 1 250 299 221 2 500 544 242 5 000 995 283 Snitt 489.75 236 Tabell 3. Resultatet från mätningen av allokerad RAM 37
5.2 Community I denna del presenteras resultatet av jämförelsen av ramverkens community. Varje fråga följs upp av ett resultat. Alla tester är utförda den 9 Maj 2017. Hur många stjärnor har ramverket på GitHub? React: 48 061 [42] Ionic: 29 422 [43] Figur 10. Stjärnor på GitHub Hur många frågor fanns det kring ramverket på Stack Overflow? React: 19 268 [44] Ionic: 39 016 [45] Figur 11. Frågor på Stack Overflow 38
Antal Google-sökningar på ramverket i genomsnitt mellan 2015-01-01 och 2017-05-09 React : 7 [46] Ionic : 65 [46] Ionic React 5.3 Plugin Figur 12. Antal Google-sökningar I denna del presenteras resultatet av antalet plugins kopplade till varje enskilt ramverk. Testet utfördes den 9 Maj 2017. Hur många plugins har ramverket? React : 4973 [47] Ionic : 3630 [48] Figur 13. Antal plugins 39
5.4 Utvecklingsförmåga I denna del presenteras resultatet av utvecklingsförmågan för varje enskilt ramverk. Testerna är utfördes den 9 Maj 2017. Består ramverket av öppen källkod? React: Ja, ramverket har en så kallad BSD license[49] vilket innebär att källkoden är öppen [51]. Ionic : Ja[52], ramverket har en så kallad MIT licens[50]. Antalet personer som bidragit med kod på GitHub? React : 1 288 [42] Ionic : 215 [43] Figur 14. Bidragande personer på GitHub Hur många jobbannonser nämns ramverket i på LinkedIn Sverige? React : 17 [53] Ionic : 8 [54] Figur 15. Jobbannonser på LinkedIn 40
5.5 Summering av resultat Enheter ms = Millisekunder mb = Megabyte R = React Native I = Ionic Prestanda Visa innehåll (15 poäng) R = ( 54+56+65+76 ) 2.75 ms poäng 4 = 6 6 2.75 15 I = ( 1042+2009+3473+6016 ) 135 ms poäng 4 = 3 6 2.75/3135 = 2% 0.02 1 5 = 0.3 Databindning (15 poäng) 385+779+1462+3005 R = ( 407.75 ms 4 ) = 1 20.75/1407.75 1.5% 0.015 15 0.23 poäng I = ( 4+7+15+57 ) 0.75 ms poäng 4 = 2 2 0.75 15 Allokerat RAM-minne (15 poäng) R = ( 182+299+544+995 ) 05 mb poäng 4 = 5 2 38.75/505 47% 0.47 1 5 7.05 I = ( 209+221+242+283 ) 38, 5 mb poäng 4 = 2 7 2 38.75 15 Community Stjärnor GitHub (8 poäng) R = 48 061 48 061 8 poäng I = 29 422 29 422/48 061 61% 0.48 8 4, 89 poäng Frågor Stack Overflow (8 poäng) R = 19 268 19 268/39 016 49.3% 0.493 8 3, 95 poäng I = 39 016 39 016 8 poäng Google-sökningar (8 poäng) R = 7 7 /65 10.7% 0.107 8 0, 86 poäng 41
I = 65 65 8 poäng Plugins Antal plugins (7 poäng) R = 4973 4973 8 poäng I = 3630 3630/4973 73% 0.73 7 5.11 poäng Utvecklingsförmåga Bidragit med kod på GitHub (7 poäng) R = 1 288 1288 8 poäng I = 215 215/1288 16.8% 0.168 8 1, 34 poäng Jobbannonser på LinkedIn (8 poäng) R = 17 17 8 poäng I = 8 8/17 47% 0.47 8 3, 76 poäng 42
Kriterium (vikt) React Ionic Prestanda (45) Visa innehåll (15) 15 0.3 Databindning (15) 0.23 15 Allokerat RAM-minne (15) 7.05 15 Community (24) Stjärnor på GitHub (8) 8 4.89 Frågor på Stack Overflow (8) 3.95 8 Antal Google-sökningar (8) 0.86 8 Plugins (7) Antal plugins (7) 7 5.11 Utvecklingsförmåga (24) Öppen källkod (8) 8 8 Bidragande personer på GitHub (8) 8 1.34 Jobbannonser på LinkedIn (8) 8 3.76 Poäng 66,09 69,4 Tabell 4. Sammanställning av resultatet från jämförelsen 43
Figur 15. XY-plot av resultatet från jämförelsen 44
45
6 Slutsats Genom att använda den teoretiska jämförelsemetoden SACAM för utformning av scenarier kan varje kriterium lättare analyseras och poängsättas. Utifrån resultaten i kapitel 5 och tabell 4 kan en slutsats dras om ramverkets fördelar, nackdelar och vilket som är de vinnande ramverket utifrån de förutbestämda kriterierna. React Native renderade elementen femtio gånger snabbare än Ionic, se sektion 5.1. Det har att göra med att React Native använder operativsystemets inbyggda funktion för list-optimering vilket gör att den inte behöver rendera alla element samtidigt utan bara de som är synliga på skärmen. I testet för databindning presterade Ionic betydligt bättre än React Native. Det fanns metoder för att optimera denna funktion i React Native där man istället för att ändra varje element istället ersätter hela vyn från grunden. Trots React Natives unga ålder har React Native 48 061 stjärnor på GitHub medan Ionic har 29 422. Ionic hade betydligt flera frågor på Stack Overflow än React Native. En trolig anledning till den större mängden frågor på Stack Overflow och det större antal Google-sökningar är att Ionic funnits en längre tid. Många frågor på Stack Overflow behöver nödvändigtvis inte vara positivt. Det kan indikera att ramverket har en hel del brister och felaktigheter. React Native har möjlighet att använda sig av Ionic-plugins. Detta är dock ingenting som tagits hänsyn till i resultatet utan resultatet visar endast antalet plugins på plattformen NPM. Trots det vann React Native antalet plugins. Båda ramverken hade öppen källkodslicens vilket ökar chanserna för ramverkets överlevnad. Ionic hade få som bidrar med kod vilket gör ramverkets utvecklingsförmåga väldigt beroende av de personer som utvecklar ramverket. React Native var det ramverket som hade(2017-05-09) flest arbetsmöjligheter kopplat till sig på LinkedIn. Det kan leda till ökat intresse hos ramverket om det finns möjlighet till arbete. React Native är när detta skrevs(2017-05-09) i ett tidigt stadie och kan upplevas mer obeprövat än Ionic som funnits under en längre period. Det slutgiltiga resultatet i jämförelsen presenteras i sektion 5.5, tabell 4. Det vinnande ramverket i denna jämförelse utsågs utifrån de förutbestämda kriterierna. Resultatet av detta arbete blev väldigt jämnt med enbart 3,31 poängs skillnad med fördel till Ionic. Båda JS-ramverken är bra alternativ vid utveckling av mobila 46
applikationer och det mest lämpade ramverket beror mycket på vilka kriterier man väljer samt hur man poängsätter de förutbestämda kriterierna. 47
7 Diskussion Vid tiden för det här arbetet fanns det få utförliga jämförelser utförda mellan Ionic och React Native. Detta arbete bidrar till mer information och kunskap kring jämförelse av de utvalda JS-ramverken. Metodiken i uppsatsen kan användas av andra som vill göra en liknande jämförelse av olika JS-ramverk inom apputveckling. De utvalda kriterierna var relevanta utifrån resultatet av intervjuerna och litteraturstudien. Säkerhet och kostnad är två kriterier som nämndes som viktiga men som inte bearbetas i detta arbete. Säkerhet tas inte upp i detta arbete eftersom det är ett väldigt stort och omfattande kriterium med många aspekter att ta hänsyn till. Problem med att i förtid välja ut kriterier kan leda till irrelevanta kriterier och bidra till en missvisande bild om ramverkets förmågor. Prestandatesterna i detta arbete utfördes enbart på en ios enhet. I framtida arbeten skulle det vara relevant att utföra prestandatesterna på en Android-enhet för att se om resultatet skiljer sig mellan de olika operativsystemen. I sektion 5.4 undersöktes antalet jobbannonser av varje ramverk på LinkedIn. I detta arbete valdes LinkedIn som rekryteringsplattform då det är ett av världens största professionella nätverk. För bästa resultat bör flera rekryteringsplattformar undersökas. Resultatet av detta arbete är inte en generell bedömning av React Native och Ionic utan det är en specifik bedömning utifrån de på förhand utvalda kriterierna och åsikter från experterna som intervjuades i förstudien. Viktningen av kriterierna hade kunnat gjorts annorlunda vilket eventuellt hade resultera i ett annat resultat. Resultatet gäller endast för nuvarande versioner av ramverken. I framtiden kan resultatet komma att ändras då nya versioner av ramverken släpps och nya uppdateringar av operativsystemen, ios och Android. För att kunna göra en liknande studie behöver man välja ut kriterier som uppfyller jämförelsens syfte. De kan göras exempelvist genom intervjuer eller utifrån en specifik kund. Ett tydlig och konkret poängsystem är viktigt för att kunna utföra en jämförelse mellan olika ramverk. Utan ett poängsystem blir svårt att utse en vinnande kandidat. 48
49
8 Framtida arbete Säkerhet och kostnad är två kriterier som nämndes som viktiga men som inte bearbetas i denna uppsats. Säkerhet blir allt viktigare i och med att det blir allt vanligare med dataintrång och kostnad har stor påverkan på valet av ramverk. Dessa kriterier kan därför vara relevanta att bearbeta i framtida arbeten. En mer utförlig litteraturstudie hade kunnat utföras för att hitta andra mer lämpade jämförelsemetoder. Kriterier och scenarier kan utökas och förbättras ytterligare för att få ett mer varierat resultat. I framtida arbeten kan det vara relevant att utföra prestandatestet på en Android-enhet för att se om resultatet skiljer sig mellan de olika operativsystemen ios och Android. Antalet ramverk ökar och därför skulle en jämförelse med mer fokus på plattforms överskridande kompabilitet som inkluderar ramverk skrivna i andra programmeringsspråk vara intressant. 50
51
9 Källförteckning [1] Holmes, E., & Bray, T. (2015). Getting started with React Native. Birmingham, UK: Packt Publishing. [2] Karadimce, A., & Bogatinoska, D. C. (2014). Using hybrid mobile applications for adaptive multimedia content delivery. 2014 37th International Convention on Information and Communication Technology, Electronics and Microelectronics (MIPRO). http://doi.org/10.1109/mipro.2014.6859654. Sida 1. [3] Yang, L., Cui, X., Wang, C., Guo, S., & Xu, X. (2016). Risk Analysis of Exposed Methods to JavaScript in Hybrid Apps. 2016 IEEE Trustcom/BigDataSE/ISPA. http://doi.org/10.1109/trustcom.2016.0097. Sida 1 [5] Software Engineering Institute. Tools and Methods for Evaluating the Architecture http://www.sei.cmu.edu/architecture/tools/evaluate/ [4] Schmidt, D., & Buschmann, F. (2003). Patterns, frameworks, and middleware: their synergistic relationships. 25th International Conference on Software Engineering, 2003. Proceedings. http://doi.org/10.1109/icse.2003.1201256. Page 4 [6] 262588213843476. (2016, Maj). Front-end JavaScript frameworks. Läst Maj 18, 2017, from https://github.com/showcases/front-end-javascript-frameworks [7] Washizaki, H., Nagai, Y., Yamamoto, R., Kubo, A., Mizumachi, T., Eguchi, K., Sugimoto, N. (2009). Aojs. Proceedings of the 8th Workshop on Aspects, Components, and Patterns for Infrastructure Software - ACP4IS '09. http://doi.org/10.1145/1509276.1509285 [8] Kazman, R., Bass, L., Abowd, G., & Webb, M. SAAM: a method for analyzing the properties of software architectures. Proceedings of 16th International Conference on Software Engineering. http://doi.org/10.1109/icse.1994.296768 [9] Zachman, J. A. (1987). A framework for information systems architecture. IBM Systems Journal, 26 (3), 276 292. http://doi.org/10.1147/sj.263.0276 [10] Dirk Riehle. Framework Design. A Role Modeling Approach. Sida 18 [11] Flanagan, D. (2011). JavaScript: the definitive guide. Sebastopol, Calif: O'Reilly. Sida 52