Komparativ studie mellan
React-Native och Flutter med avseende
på utvecklarens produktivitet
HUVUDOMRÅDE: Datateknik
FÖRFATTARE: Milad Ziai och Robin Sauma
HANDLEDARE: Linus Rudbeck (huvudhandledare) Rickard Nilsson (extern handledare) JÖNKÖPING 2020 05
Detta examensarbete är utfört vid Tekniska Högskolan i Jönköping inom [se huvudområde på föregående sida]. Författarna svarar själva för framförda åsikter, slutsatser och resultat. Examinator: Johannes Schmidt
Handledare: Linus Rudbeck Omfattning: 15 hp (grundnivå)
Abstract
The development of hybrid mobile applications has increased rapidly in the last decade. Considering the diversity in how big companies starts to invest in frameworks that supports hybrid application development (cross-platform framework), the necessity of contemporary
studies in this subject increase. Facebook and Google are two well-known companies that have developed React-Native and Flutter, respectively. These cross-platform frameworks are continuously developing, and differences occur in their technologies which makes new studies even more appropriate. The purpose of this study is to investigate which of these two frameworks contribute the most for the developer’s productivity considering the lack of studies in this specific subject. Specifically, a case study has been conducted where the research questions were answered.
The two research questions were divided into three sub questions, respectively where each question was given criteria to follow in the case study and each framework were assigned points if the associated criterion for each question were met. In the end of the study a mean value was assigned to each framework. The results showed that there are small differences in terms of its contribution for the developer’s productivity.
Keywords: React-Native, Flutter, cross platform development, developer’s productivity, productivity in software development, hybrid application, native application
Sammanfattning
Utvecklingen av mobila hybrid applikationer har ökat drastiskt under det senaste årtiondet. Med tanke på mångfalden i hur stora företag börjar investera i ramverk med support för utveckling av mobila hybrid applikationer (multiplattforms ramverk), ökar nödvändigheten av aktuella studier inom detta ämnesområde. Facebook och Google är två välkända företag som har utvecklat React-Native respektive Flutter. Dessa multiplattforms ramverk utvecklas kontinuerligt och skillnader uppstår inom teknologierna hos ramverken vilket gör nya studier mer lämpliga. Syftet med denna studie är att undersöka vilket ramverk som bidrar med bäst produktivitet för utvecklaren med tanke på bristen av studier inom ämnet. Specifikt har en fallstudie utförts där studiens frågeställningar har besvarats.
Respektive frågeställningarna blev uppdelade i tre delfrågeställningar där varje fråga fick angivna kriterier att följa i fallstudien och båda ramverken blev tilldelade poäng om
tillhörande kriterium för varje fråga var uppfylld. I slutet av studien räknades ett medelvärde ut som tilldelades till båda ramverken. Resultaten visade att det finns små skillnader i form av dess bidrag med bäst produktivitet för utvecklaren.
Nyckelord: React-Native, Flutter, Multiplattformsutveckling, utvecklarens produktivitet, produktivitet inom mjukvaruutveckling, hybrid applikation, originell applikation.
Förord
Enligt tradition vill vi börja vårt examensarbete med tacka alla som har varit involverade i arbetet, från lärare till opponenter. Ett stort tack vill vi rikta till vår handledare Linus Rudbeck som har handlett och motiverat oss från början.
Som en förberedelse till läsarna kommer vissa engelska definitioner att hållas kvar med tanke på att det inte finns någon klar definition på svenska men dessa har lagts till i akronymlistan till exempel widget och vissa sektioner i texten har grå bakgrundsfärg för bättre visibilitet som ska simulera kod/kommando block.
Innehållsförteckning
Abstract ... i
Sammanfattning ... ii
Förord ... iii
1. Introduktion ... 8
1.1BAKGRUND ...8 1.2PROBLEMBESKRIVNING ...91.3SYFTE OCH FRÅGESTÄLLNINGAR ...9
1.4OMFÅNG OCH AVGRÄNSNINGAR ...10
1.5DISPOSITION ...11
2 Metod ... 11
2.1KOPPLING MELLAN FRÅGESTÄLLNINGAR OCH METOD ...11
2.1.1 Återanvändning av kod ...12
2.1.2 Support av enhetens funktionaliteter ...14
2.1.3 Start av projekt ...15
2.1.4 Popularitet bland intressegrupper ...16
2.1.5 Dokumentation ...16
2.1.6 Tredje parts bibliotek ...17
2.2ARBETSPROCESSEN ...17
2.3ANSATS ...18
2.4DATAINSAMLING ...18
2.5TROVÄRDIGHET ...18
3 Teoretiskt ramverk ... 19
3.1KOPPLING MELLAN FRÅGESTÄLLNINGAR OCH TEORI ...19
3.2STUDIENS KOMPONENTER ...19 3.2.1 Flutter ...19 3.2.2 React-Native ...21 3.3PRODUKTIVITET...23
4 Empiri ... 23
4.1ÅTERANVÄNDNING AV KOD ...234.1.2 Kvalitetsfaktor två (anpassningsbarhet) testas med hjälp av en metrik RCC. ...24
4.1.3 Kvalitetsfaktor tre (pålitlighet) testas med hjälp av en metrik ACDD. ...25
4.2SUPPORT AV ENHETENS FUNKTIONER ...26
4.3START AV PROJEKT ...27
4.4POPULARITET BLAND INTRESSEGRUPPER ...28
4.4.1 Github ...28 4.4.2 StackOverflow ...28 4.4.3 Google Trends ...29 4.5DOKUMENTATION ...30 4.5.1 Kraftfull navigering ...30 4.5.2 Video dokumentation ...31 4.5.3 Interaktiv dokumentation ...31 4.6TREDJEPARTSBIBLIOTEK ...31
5 Analys ... 34
5.1FRÅGESTÄLLNING 1-KVALITET OCH SIMPLICITET ...34
5.1.1 Återanvändning av kod ...34
5.1.2 Support av enhetens funktionaliteter ...36
5.1.3 Start av projekt ...37
5.2FRÅGESTÄLLNING 2-RAMVERK OCH DESS COMMUNITY ...37
5.2.1 Popularitet bland intressegrupper ...37
5.2.2 Dokumentation ...39
5.2.3 Tredjepartsbibliotek ...40
5.3SAMMANFATTNING AV ANALYS ...41
5.3.1 Sammanfattning av kriterier på frågeställning 1 ...41
5.3.2 Sammanfattning av kriterier på frågeställning 2 ...41
5.3.3 Sammanfattning av delfrågeställningar ...42
6 Diskussion och slutsatser ... 43
6.1RESULTAT ...43
6.2IMPLIKATIONER ...43
6.3BEGRÄNSNINGAR ...44
6.4SLUTSATSER OCH REKOMMENDATIONER ...44
6.5VIDARE FORSKNING ...45
Begreppsdefinitioner och akronymer
State En komponents tillfälliga status
Commit Bekräftelse av ändring i ett projekt i en versionshanterare Metainformation Beskrivning av en komponent eller widgets syfte
plugins Plugins är paket av kodrader som utför ett syfte efter namn eller beskrivning för Dart utveckling
NPM Node Package Manager är en tjänst för ett register av paket för JavaScript utveckling.
community Intressegrupp av ramverket
AOT Ahead-Of-Time, metod för att kompilera koden under kompileringstid till maskinkod
JIT Just-In-Time, metod som kompilerar koden under exekvering av programmet
cross-platform development
Multiplattformsutveckling
Ut-faktorn Värdet av produkten
In-faktorn Arbetet som krävs av utvecklaren
API Application Programming Interface
CMD En terminal där en användare kan skriva kommando som exekverar en fil vid en specifik plats i datorn
SDK Software Development Kit är ett paket av verktyg för mjukvaruutveckling
Extension En förlängning som används av Visual studio code för att hantera vissa system eller ramverk
1. Introduktion
I föreliggande studie kommer ramverken Flutter som ägs av Google och React-Native som ägs av Facebook att jämföras. Dessa två ramverk stödjer hybrid mobil applikationsutveckling, det vill säga multiplattformsutveckling (cross-platform development). Ett multiplattformsverktyg använder ett programmeringsspråk för att skapa en applikation som kan exekveras på olika plattformar.
Det finns olika varianter av ramverk som stödjer hybrid mobil applikationsutveckling men React-Native har visat sig vara väldigt populärt under sin tid och på senare tid har Google lanserat Flutter som är mycket omtalat inom dess community för mobil applikationsutveckling. Mellan dessa två ramverk skall studien handla om hur utvecklarens produktivitet skiljer sig åt eftersom utvecklingsprocessen baseras på olika aspekter, nämligen kod-arkitektur, tjänster, community och dokumentation. Flutter och React-Native förekommer med ett flertal olika faktorer som kan hjälpa utvecklaren att skapa en applikation. Till exempel är React-Native känt från React.js där den använder ett liknande koncept av webbutveckling gällande design och uppbyggnad. Däremot har Flutter från Google valt att välja en annan väg där man som utvecklare kan bygga upp hela applikationen med hjälp av widgets för ett flertal fördelar som minimal rendering och simplicitet [1].
1.1 Bakgrund
Under det senaste årtiondet har utveckling av mobila plattformar och applikationer ökat i stor utsträckning. Android och IOS är de mest förekommande plattformarna att utveckla applikationer på numera och dessa två plattformar dominerar även marknaden i mobil applikationsutveckling. När man bygger en originalapplikation innebär det att man använder samma programmeringsspråk som plattformen kan exekvera. Om man till exempel bygger en applikation för IOS kommer man att använda programmeringsspråken Objective-C eller Swift för utveckling av mobila applikationer till IOS och resterande Apple plattformarna [2][3]. Traditionellt sätt utvecklas applikationer genom att utveckla en originalapplikation på ena plattformen och därefter utveckla en identisk applikation på den andra plattformen. Genom detta sätt tillkommer det utvecklings- och underhållningskostnader. På senare tid har multiplattformsutveckling framträtt och ökar i attraktionskraft för allt fler utvecklare. Tanken med multiplattformsutveckling var att minska utvecklings- och underhållningskostnader eftersom det ger möjligheten att utveckla en applikation som är kompatibel med flera plattformar, alltså en hybrid applikation [4]. Detta har medfört att många stora företag har investerat i nya ramverk för multiplattformsutveckling, till exempel React-Native som tillhör Facebook och Flutter som tillhör Google. Det finns många alternativa ramverk att välja bland men stora delar mellan olika ramverk kan skilja för utvecklaren. Detta medför att utvecklarens produktivitet i sin tur skiljer sig hos de olika ramverken, då utvecklarens produktivitet har en stor betydelse för projektets process.
Det är en utmaning att mäta produktiviteten i ett ramverk inom mjukvaruutveckling. Många inom området har definierat produktivitet på olika sätt vilket har gjort definitionen vagt, därav finns det inte någon klar definition på vad produktivitet är i samband med mjukvaruutveckling. Det man har kommit fram med enligt Caitlin Sadowski och Thomas Zimmermann är att det finns två faktorer som kan användas för att förklara produktiviteten inom mjukvaruutveckling, även om ingen idag är överens om definitionen [5]. Dessa två faktorer är in och ut: In faktorn är arbetet som krävs för arbetaren samtidigt som ut faktorn är värdet av mjukvaran för användaren. Även ifall dessa två faktorer beskriver produktiviteten väldigt väl så är det fortfarande ingen klar definition [5]. Dock kommer denna studie att referera till dessa två faktorer.
1.2 Problembeskrivning
Det traditionella sättet att utveckla applikationer på är mer funktionell i form av bättre utnyttjande av enhetens hårdvara som är mycket effektivare än hybrid utveckling, därför kommer det alltid att vara väsentligt.
Eftersom smarta telefoner används dagligen, arbetar IT företagen mycket på mobil applikationsutveckling för att nyttja dessa användare med nya teknologier. Med tanke på att det kontinuerligt förekommer nya teknologier som ramverken måste uppdateras för, kan det resultera stora i skillnader på uppbyggnaden och arkitekturen av ramverken. Om ett ramverk då är komplicerat att använda kan en av projektets huvudfaktorer (till exempel budget) inte fullföljas vilket leder till att företaget som äger projektet kan hamna i en dålig position. Det är då viktigt att hålla produktiviteten uppe så att företaget inte hamnar i en dålig situation, en dålig situation kan vara att kunderna till slut anser att företaget inte erbjuder lika bra produkter som andra företag och därmed rör sig till en konkurrent. Logiskt sätt söker sig kunderna/användarna till de produkterna med bäst erbjudanden för att underlätta deras vardagliga liv.
Problemet är att då välja ett ramverk som erbjuder bäst produktivitet men det är svårt att veta vilken som passar eftersom ett ramverk kan anses vara stabil, säker och effektiv. Dock skall det inte tolkas som att det är idealiskt.
Motivet till att utföra denna studie är betydelsefullt för intressenter inom all sorts applikationsutveckling med avsikten att använda ett av dessa två ramverk med tanke på att det är brist på forskning specifikt för utvecklarens produktivitet. På grund av bristen av antalet studier kommer genomförandet av denna studie bidra med djupare kännedom och utökad kunskap inom det specifika området. Det är även intressant för nya organisationer och företag inom applikationsutveckling som väljer att använda ett av dessa två ramverk, för att de skall kunna lyfta fram fördelar och nackdelar som lägger grunden för organisationens val baserat på deras krav.
1.3 Syfte och frågeställningar
Syftet med denna studie är att bidra med extra kunskap inom multiplattformsutveckling med fokus på utvecklarens produktivitet inom ramverken React-Native och Flutter, eftersom det är brist på studier som berör detta särskilda område. Med tanke på att ramverkens teknologier ändras kontinuerligt och därmed blir befintliga studier utdaterade, är det väsentligt att nya och aktuella studier finns. Resultatet av arbetet skall ge en utförlig och beskrivande grund för att gynna nya utvecklare eller organisationer inom multiplattformsutveckling med mål att arbeta med något av dessa ramverk. Studien skall utföras i samarbete med Evry och därmed blir arbetet också en passande studie för de, eftersom React-Native redan används i företaget.
Multiplattformsutvecklingen träder fram alltmer och därför investerar företag i att utveckla ramverk som kan användas för utveckling av mobilapplikationer. Detta gör att det finns en hel del varianter av ramverk att använda såsom Ionic, Phone gap, JQuery-mobile, React-Native och Flutter men denna studie kommer att fokusera på de två ramverken med störst community räknat efter antalet Github-stars [6][7][8][9][10]. Detta gör att denna studie kan vara attraktivt för fler läsare genom att utgå från de mest populära ramverken baserat på antalet intressenter/entusiaster (React-Native & Flutter).
För att jämföra vilket ramverk som kommer att bidra mest gällande utvecklarens produktivitet kommer studien att brytas ned i två huvudfaktorer, nämligen kvalitét och simplicitet, eftersom dessa två huvudfaktorer måste tas hänsyn till vid utveckling av mobila applikationer. Bäst “in- och utfaktor” är alltså eftersträvansvärt. Anledningen till detta är för att upprätthålla produktiviteten, när ett projekt har utförts måste den för nyare versioner uppdateras. Saknas det
då kvalitet i koden kan detta resultera i stora förvirringar för utvecklaren att applicera nya funktionaliteter till koden vilket gör att tidskostnad kan ökas. Simplicitet i en grad stödjer kvalitén för produkten. Ju lättare ett ramverk är att hantera desto mer kommer ramverket att bidra med när det gäller ökad produktivitet för utvecklaren, då utvecklaren inte behöver lägga ned tid på att hitta egna lösningar till problemen.
För att kunna besvara syftet och jämföra produktiviteten mellan respektive ramverk har arbetet delats upp i två frågeställningar.
Frågeställningar
1. Hur bra blir ett arbete med avseende på kvalitet och simplicitet i form av: a. återanvändning av kod
b. support av enhetens funktionaliteter c. start av projekt
2. Hur bidrar ramverken och deras community till att förenkla utvecklandet av en ny applikation baserat på:
1. popularitet bland intressegrupper 2. dokumentationen
3. tredjepartsbibliotek
För att därmed besvara frågeställningarna skall en fallstudie genomföras där alla punkter studeras noggrant genom dels teoretisk dels praktisk beprövad undersökning.
1.4 Omfång och avgränsningar
Studien omfattar huvudsakligen en jämförelse mellan ramverken React-Native och Flutter med avseende på utvecklarens produktivitet.
Specifikt ska kvalitet och simplicitet hos respektive ramverk undersökas. För att erhålla samma förutsättningar för båda ramverken ska studien ske likvärdigt för respektive ramverk.
Med tanke på att respektive ramverk är uppbyggda på olika sätt medför detta stora skillnader i både kommunikation mellan trådarna och kompilering av källkod. Därför kommer denna studie att bortse från den interna prestandan hos de olika ramverken vilket vanligtvis adresseras inom utveckling överlag.
En studie där produktiviteten mäts riskerar att bli subjektiv och är därmed inte optimal eftersom det finns olika definitioner av produktivitet. Genom att utgå från frågeställningarna och bilda kriterier med en anslutning till frågeställningen vilket kommer fånga upp in och ut faktorn, kan undersökningarna bidra med objektiva resultat för att bedöma denna studie rättvist.
Eftersom studien följer en kvalitativ ansats så brukar det optimala vara att intervjua (i detta fall) utvecklare som är bekanta med vartdera ramverk. Problemet är att man behöver hitta ett flertal grupper av utvecklare för att få ett realistiskt resultat vilket inte är möjligt baserat på tidsbristen av detta arbete.
1.5 Disposition
Studiens upplägg är indelat i följande kapitel:
Kapitel 2 – Metod och genomförande: Beskrivningen av studiens metod och arbetsprocess. Kapitel 3 – Teoretiskt Ramverk: Tidigare relevant forskning redogörs och genomgång av multiplattformsutveckling där React-Native och Flutter ingår.
Kapitel 4 – Empiri: Här ska fallstudien ske för alla delfrågeställningar för att besvara dessa samt resultat kommer tilldelas efter modell på motsvarande del i metod
Kapitel 5 – Analys: All data som samlats från fallstudien och använts under studiens gång diskuteras och frågeställningarna besvaras
Kapitel 6 – Diskussion och Slutsatser: Diskussion och slutsats av studien presenteras.
2 Metod
2.1 Koppling mellan frågeställningar och metod
Med tanke på att utvecklarens produktivitet inte har definierats enligt Caitlin Sadowski och Thomas Zimmermann [5]. Hittades ingen bra experimentell metod att jämföra utvecklarens produktivitet hos respektive ramverk. Därför utförs en fallstudie för att uppfylla kraven och besvara frågeställningarna genom dels teoretisk dels praktisk beprövad undersökning. De specifika metoderna som användes i studien beskrivs nedan.Eftersom en fallstudie blir relativt subjektivt på grund av att studien baseras mestadels på författarnas argumentation, måste arbetet justeras lite vilket ska resultera i att denna studie ska bli så saklig och opartisk som möjligt. För att göra detta möjligt ska arbetet utföras baserat på specifika kriterier för respektive frågeställning. Vissa av kriterierna är inspirerade av Washizaki och Yoshiaka Fukazawa som har utfört en studie på återanvändning av två komponenter där de jämför vilken som bidrar till mest återanvändbarhet [11]. I studien har de använt kriterier för att bedöma resultatet utifrån, två av dessa har då valts att refereras till i denna studie med tanke på att dessa kriterier uppfyller de krav som finns i studien. Utöver dessa används andra konstruerade kriterier av författarna för denna studie till de andra delfrågeställningarna som kommer att bidra med objektivitet i resultaten. Detta gör att bedömandet av resultaten från fallstudien avgränsas från att vara allmän och istället mer specifik för respektive kriterium i varje delfråga. Vilket senare kan användas för att bedöma de slutgiltiga resultaten bättre och anslutningsvist till studiens huvudsyfte (utvecklarens produktivitet).
Efter att alla poäng är tilldelade enligt samtliga kriterier kommer en generell bedömning ske där medelvärdet av alla poäng räknas ut. Denna generella bedömning skall avgöra vilket ramverk som bidrar med bäst produktivitet för utvecklaren. För att värderingen skall bli så praktisk som möjligt kommer värdet av kriterierna att standardiseras till ett värde i intervallet mellan 0 och 1. Om det då finns en chans att värderingen efter deras matematiska modell tilldelas ett värde som är större eller ekvivalent med 1 kommer ramverken för detta kriterium att ställas mot varandra och tilldelas poäng i decimaltal efter procentsatsen. Detta kommer inte ske ifall ett av värdena (för ett ramverk) från kriteriet tilldelas 0, då tilldelas andra ramverket 1. Alltså kommer bedömningen för varje kriterium att ske enligt följande fall:
2. Om ena ramverket har tilldelats 0 ska andra ramverket tilldelas 1 ifall andra ramverket har ett värde större eller ekvivalent med 1.
3. Ifall båda ramverken har tilldelats större eller ekvivalent med 1 ska ramverken ställas mot varandra och en procentsats ska tilldelas till respektive ramverk i decimal.
Detta gör att alla kriterier sammanhåller inom samma intervall och får samma förutsättningar för den slutgiltiga bedömningen.
För frågeställningarna tillsätts följande kriterier där alla delfrågeställningar i både frågeställningarna behandlas.
2.1.1 Återanvändning av kod
Denna undersökning är skapad för att jämföra hur enkelt det är för utvecklaren att återanvända samma kodblock och har möjligheten att ändra dess utseende eller andra delar utan att behöva ändra stora delar av koden.
Genom att använda delar av GRASP designmönster (High-Cohesion och Low-Coupling) som beskriver att hålla objekten fokuserade, hanterlig, förståelig och hur lågt ett objekt är beroende av andra så blir detta en bra grund för denna undersökning [12]. En liknande studie har utförts av Hironori Washizaki och Yoshiaka Fukazawa där de använde “Black-box component reusability model” som tre kvalitets-faktorer användes från ISO standarden ISO-9126 [11]. Dessa tre faktorer är begriplighet, anpassningsbarhet och bärbarhet. Detta arbete refererar delvis till Hironori Washizaki och Yoshiaka Fukazawa’s metod där är en av kvalitetsfaktorerna utbytt till pålitlighet med tanke på att den passar detta arbete mer på grund av att bärbarhet redan är en del av anpassningsbarhet. Detta resulterar i att denna studie får med pålitlighet som har en stor påverkan i utvecklarens produktivitet eftersom nya teknologier kontinuerligt skapas och ramverken behöver uppdateras för dessa teknologier. Modellen som används i arbetet visas på
figur 1:
Figur 1 modell för 2.1.1 Återanvändning av kod
Dessa kvalitets-faktorer påverkar utvecklarens produktivitet hos respektive ramverk, tanken är att använda denna modell för att jämföra allmänna komponenter från ramverken med samma syfte baserat på dess tre metriker som beskrivs i modellen (EMI, RCC och ACDD) där ACDD är egengjord [11]. Faktorerna är uppdelade i kriterier med respektive metrik och definitioner för dessa anges nedan.
2.1.1.1 EMI: Existens av meta-information (Existence of
Meta-Information)
Förekomsten av meta-information fastställer om information om en viss komponent förses av utvecklaren. Om det finns meta-information om komponenten kan användaren enkelt lära sig om komponentens användningsområden. Förekomsten av meta-information kan fastställas genom att kontrollera om varje komponent har en tillhörande meta-information.
EMI(r) påvisar om ett specifikt ramverk r har tillhörande meta-information för givna
komponenter:
Figur 2 Matematisk modell för kriterium 2.1.1.1 EMI
Om värdet av 𝐸𝑀𝐼(𝑟) blir 1 betyder det att meta-information till de givna komponenterna existerar och därmed blir användningen av komponenterna enkla att förstå.
2.1.1.2 RCC: Anpassningsbarhet (Rate of Component Customizability)
Anpassningsbarhet indikerar den inbyggda förmågan för stöd av konfiguration och anpassning av interna funktioner i en komponent.För komponentanpassning och konfigurering kommer egenskaperna för respektive komponent att användas för att verifiera att en komponent har maximal återanvändning och har support för anpassningar [13]. Därmed måste komponenterna tillåta ändring av värdena hos sina egenskaper för konfigurering. Man kan verifiera anpassningsbarhet genom att mäta antalet skriv-metoder och parametrar (som justerar komponenten) som är försedd för varje komponent då detta påverkar anpassningsbarheten [11].
RCC(k) är en procentsats av antalet skriv-metoder och parametrar i alla områden för den
specifika komponenten k.
Figur 3 Matematisk modell för kriterium 2.1.1.2 RCC
Med hjälp av RCC kan graden av anpassningsbarhet anges för användarna av komponent k. Anpassningsbarheten av k borde vara hög för att kunna anpassa inställningarna.
RCC ska omfatta hur enkelt det är för utvecklaren att anpassa sin komponent vilket refererar till anpassningsbarhet. En komponent ska inte bara vara återanvändbar men också tillräckligt enkel att justera utseendet eller funktionalitet på när behovet finns.
När en komponent byggs upp kan man skicka in parametrar som kallas för “props” vilket kan både justera utseendet men också användas för att hantera funktionaliteten hos komponenten. Vanligtvis sker detta via state på respektive ramverk men bortsett från detta finns det också
möjlighet för hantering av en komponent/widget via dess metoder. Dess metoder måste däremot vara publika, en metod i en klass kan utses som publika, privata eller skyddade. Det är endast publika metoder som en utvecklare kan komma åt utanför, via objekten av klassen [12].
2.1.1.3 ACDD: Mognad (Amount of Commits per Development Days)
Mognad av ett ramverk påvisar hur uppdaterad och aktuell det är. När ett ramverk är kontinuerligt uppdaterat innebär det att ramverket är väsentligt och därmed vet användarna att ramverket är stabil för tillfället.Detta kan bedömas genom att ta reda på antalet commits för respektive ramverk hos tillhörande förvaringsplats på Github.com.
Med detta förväntas komponenterna vara uppdaterade för till exempel ett nytt system. Detta gör att risken för att behöva hitta en lösning för det nya systemet minskar vilket medför en minskning på produktionstiden som i sin tur ökar produktiviteten.
ACDD(r) är en procentsats av antalet commits för respektive ramverk (r) av utvecklaren.
Figur 4 Matematisk modell för kriterium 2.1.1.3 ACDD
ACDD är graden av mognad för ett ramverk. När graden av mognad är hög medför det att komponenten är aktuell och detta leder till att pålitligheten blir högre av användaren.
2.1.2 Support av enhetens funktionaliteter
Bland nya applikationer är det väldigt populärt att använda enhetens funktionaliteter för en bättre användarupplevelse. Det finns ett flertal av hårdvarukomponenter att använda, varav några är vanligare att använda till en applikation än andra. Denna undersökning kommer att ske genom en fallstudie på vilka samt hur man har tillgång till enhetens funktionaliteter av respektive ramverk. Fallstudien kommer att fokusera främst på sju olika typer av tjänster, vilket finns på enheten: Bluetooth, kamera, NFC, sensorer, biometri, Wifi och GPS. Detta kan bedömas genom att ta reda på antalet hårdvaru funktionaliteter ett ramverk har support för. Olika ramverk har olika metoder för att använda enhetens funktionaliteter och support av enhetens funktionaliteter fastställer om ramverket har support för en specifik funktionalitet. Nedan redovisas kriteriet:
1. Ja - ramverket har support för funktionaliteten
2. Ja fast med tredjepartsbibliotek - ramverket har support för funktionaliteten fast med ett tredjepartsbibliotek.
SEF(r) är en procentsats av totalt antal hårdvaru funktionaliteter av ramverket.
Figur 5 Matematisk modell för kriterium 2.1.2 SEF
2.1.3 Start av projekt
Att starta ett projekt kan vara en utmaning för vissa utvecklare eftersom det är en ny miljö som aldrig tidigare använts vilket kan resultera i utökad produktionstid. För att bedöma denna faktor ska undersökningen omfatta ett test för att jämföra hur enkelt det är för en utvecklare att starta ett nytt projekt. Detta kan bedömas genom att mäta antalet steg en utvecklare behöver ta i en CMD för att starta ett projekt i respektive ramverk.
När en utvecklare initierar ett projekt i något ramverk krävs det ibland olika program som utvecklaren behöver ha på sin maskin för att kunna initiera projektet. Därefter finns det andra steg som utvecklaren behöver utföra innan projektet är initierat.
Testet skall värderas efter ett kriterium:
SAP(r) är antalet steg som krävs för att starta ett projekt för respektive ramverk r
Figur 6 Matematisk modell för kriterium 2.1.3 SAP
Denna undersökning ska bedömas efter minst antal steg som krävs för start av projekt. Det vill säga om n(React-Native) är större än n(Flutter) kommer Flutter tilldelas det högst angivna poänget efter att ramverken har ställts mot varandra. Under denna undersökning försäkras det om att ramverken tilldelas mer än ett poäng eftersom start av projekt räknar antalet steg och därmed ställs de mot varandra.
2.1.4 Popularitet bland intressegrupper
Nästan alla ramverk och programmeringsspråk har sina intressenter och dessa kan utnyttjas för att jämföra hur populära ramverken är inom dess community. Denna undersökning kommer att ske genom att samla data från två stora webbplatser som finns tillgängliga för utvecklare (Stackoverflow.com och Github.com). För att göra detta lite mer intressant kommer studien att kontrollera hur många sökningar som görs på respektive ramverk med hjälp av Google trends. Detta kan bedömas genom att ta reda på hur känt ett ramverk är bland respektive community. Ett ramverk kan anses vara känt med avseende på hur stor community ramverket har. Storleken på dess community kan mätas enligt följande kriterier som redovisas nedan.
1. Github: antalet stjärnor på respektive ramverk som beskriver hur många som har gillat denna förvaringsplats av kod.
2. StackOverflow: hur många trådar som skapats för respektive ramverk på senaste tiden.
3. Jämförelse på Google trends om vilken term som har sökts mest på, React-Native eller Flutter.
PBI(r) sammanfattning av populariteten baserat på antalet trådar, github stjärnor och sökta
termer för respektive ramverk r.
Figur 7 Matematisk modell för kriterium 2.1.4
2.1.5 Dokumentation
När en utvecklare påbörjar ett projekt där den använder ett nytt ramverk är det väsentligt att en bra tillhörande dokumentation är given. Detta är för att handleda utvecklaren om hur alla komponenter/widgets fungerar och hur man använder de inom respektive ramverk för implementering. Teknisk dokumentation har på senare tid blivit mer avancerade och tagit steget mot interaktiva och uppkopplade versioner. Utvecklingen av detta har medfört nya möjligheter för att jämföra dokumentationen i denna studie. Därmed går det i denna undersökning att använda dessa kriterier för att bedöma vilken av ramverken som bidrar med bäst dokumentation för utvecklaren.
Dokumentationen bidrar med simplicitet i utvecklingsprocessen för att få ut ett så bra värde av produkten som möjligt. Som Anna Wingkvist, Rüdiger Lincke, Morgan Ericsson och Welf Löwe citerar: “The quality of technical documentation and user manuals is an important part
of the perceived quality of a product” [14]. Det beskriver att dokumentationen bidrar med
ut-faktorn som omfattar värdet av produkten och för att då få en bra produkt måste dokumentationen också hjälpa utvecklaren, det vill säga in-faktorn vilket omfattar arbetet som krävs måste minimeras för att öka produktiviteten. Därför ska dessa tre faktorer testas på givna
komponenter med liknande syfte vilket ska resultera i att hjälpa utvecklaren navigera, begripa och testa lösningar.
Kriterierna:
1. Innehåller kraftfull navigering 2. Innehåller videodokumentation 3. Innehåller interaktiv dokumentation [14].
DOK(r) är en modell som besvarar ifall kriterierna uppfylls för respektive ramverk r.
DOK-N(r) gäller endast för första kriteriet eftersom inga komponenter undersöks i kriterium 1.
Figur 8 Matematisk modell för kriterium 2.1.5 DOK & DOK-N
2.1.6 Tredje parts bibliotek
Det finns inte mycket att jämföra på denna undersökning bortsett från att mäta vilken av ramverken som har tillgång till flest tredjepartsbibliotek. Ju fler bibliotek desto större chans för att implementationen skall bli lättare och därmed dra ned på produktionstiden eftersom man kan utnyttja färdigbyggda komponenter. Det enda kriteriet som finns för denna undersökning är antalet paket hos respektive ramverk.
TPB(r) är sammanfattningen av vilket ramverk r som har mest tredjepartsbibliotek
Figur 9 Matematisk modell för kriterium 2.1.6 TPB
2.2 Arbetsprocessen
Eftersom frågeställningarna kommer att besvaras med hjälp av genomförandet av en
fallstudie så kommer arbetsprocessen bestå mycket av litteraturstudier inom alla delar
i de olika områdena. En fallstudie består av två processer, nämligen förberedelsen och
utförandet. Inom förberedelsen kommer författarna forska inom ämnet, finna all
relevant information som krävs via litteraturstudier och vad de egentligen bidrar med.
Efter att tillräckligt med information har samlats och studieförfattarna ansåg sig vara
tillräckligt kunniga inom respektive områden kommer utförandet att påbörjas. Då
kommer studien beskriva vad området handlar om, vad den kan användas till och hur
det skiljer mellan ramverken.
Figur 10 Modell för arbetsprocess
2.3 Ansats
Studien har en kvalitativ ansats och består av en fallstudie tillsammans med en litteraturstudie. För att ringa in tidigare forskning i de aktuella områdena genomfördes en litteraturstudie. De genererade resultaten från fallstudien undersöks och uttrycks i ord och beskrivning.
2.4 Datainsamling
Från 2.1 koppling mellan frågeställningar och metod har varje del i frågeställningen tilldelats kriterier för att få fallstudiens genererade resultat så objektiva som möjligt. Det som då krävdes var att utföra en fallstudie där motsvarande komponenter från respektive ramverk studerades och blev bedömda baserat på kriteriernas krav. Detta gjorde att studien kunde bedömas efter respektive frågeställning och till slut räkna ut ett medelvärde på antal poäng som blev tilldelade till respektive ramverks kriterium som senare kunde bedöma det ramverk som bidrar med bäst produktivitet för utvecklaren i helhet.
2.5 Trovärdighet
Refererat till tidigare 1.1 Bakgrund finns det ingen klar definition på vad produktivitet är, vilket gör att experimentella undersökningar blir svåra och tidskrävande att utföra vilket kan resultera i en slarvig studie. En fallstudie däremot, baseras på fakta och genom att använda pålitliga källor blir det därför optimalt för denna studie. Resultaten härstammar mycket från respektive ramverks originalkällor som ska bidra med pålitlighet och därmed höjs trovärdighetsnivån för denna studie.
Fallstudier kan oftast anses som väldigt subjektiva studier eftersom resultaten är mestadels baserade på författarnas argumentation [15]. Denna studie är försedd med kriterier för att bortse från författarnas egna argumentationer och istället följa dess krav för att besvara frågeställningarna som gör att studien blir mer objektiv, vilket är beskrivet i 2.4 Datainsamling. Frågeställningarna rör sig brett kring kvalitet och simplicitet där ett flertal kriterier kommer bedömas efter sex olika delfrågor i frågeställningarna. Därmed ökar validiteten i arbetet
eftersom fler områden undersöks i studien så varken React-Native eller Flutter kan anses som det bättre ramverket baserat på en faktor utan det blir en allmän bedömning på utvecklarens produktivitet.
3 Teoretiskt ramverk
I och med att multiplattformsutveckling har ökat i popularitet sedan React-Native lanserades i mars 2015, finns det inte lika mycket forskning om detta område jämfört med traditionell utveckling. De äldre studierna har mestadels varit fokuserade på teknologier som inte har mycket gemensamt med multiplattformsutveckling. Studier inom prestandaförmågan för olika ramverk existerar men med tanke på att teknologierna ändras kontinuerligt blir därför en stor del av studierna inte lika precis.
Det finns liknande komparativa studier som är publicerade men dessa är främst riktade mot prestandan av ramverken. Prestandan är oftast det mer populära alternativet att jämföra inom ramverk, system eller programmeringsspråk eftersom det alltid finns metoder och möjligheter att använda för att utföra studier på. Denna studie fokuserar på produktiviteten från utvecklarens perspektiv men problemet är att produktiviteten är svår att mäta. Det finns inte en klar definition om vad produktiviteten är eftersom ingen är överens om definitionen [5]. Detta kan vara anledningen till att det är brist på studier inom utvecklarens produktivitet i detta område. Därmed är det lämpligt att en ny typ av studie publiceras.
3.1 Koppling mellan frågeställningar och teori
För frågeställning 1: Hur bra blir ett arbete med avseende på kvalitet och simplicitet. Efter litteraturstudien som genomfördes av författarna bland olika trådar, community, tidigare skapade applikationer och populariteten i sig, så leder till hypotes 1: Flutter från Google förväntas ha en större chans att bidra med ökad produktivitet för utvecklaren i denna komparativa studie [16][17][18][7][8]. Detta kan anses främst för att Flutter är yngre och har haft fördelen med att lära av misstagen och anpassat sig till de hinder som bland annat React-Native och andra multiplattforms ramverk har stött på.
För frågeställning 2: Hur bidrar ramverken och deras community till att förenkla utvecklandet
av en ny applikation. I och med att community och dokumentationen för respektive ramverk
hjälper utvecklaren under implementeringen medverkar detta utvecklarens produktivitet. Enligt statistik har Flutter en större community än React-Native vilket bidrar med större hjälp för utvecklare [18][7][8]. Detta leder till hypotes 2: Flutters community har en större chans att bidra med lösningar för de problem som en utvecklare kanske stöter på under implementering vilket underlättar utvecklingen. Däremot kan det skilja för tredjepartsbibliotek och dokumentation mellan ramverken baserat på att React-Native är äldre och har därmed haft mer erfarenhet.
3.2 Studiens komponenter
3.2.1 Flutter
Flutter är ett ramverk utvecklat av Google, maj 2017. Flutters vision är att skapa
mobila applikationer på olika plattformar med originella grafiska komponenter även kallade widgets, med hög kvalitet. En widget beskriver hur något ska se ut beroende på deras tillstånd och värden.
void main() { runApp( Center( Child: Text( ’Hello, world!’,
text Direction: Text Direction.ltr ),
), ); }
Kodblock 1 kodexempel på hur en widget byggs upp
Allt i Flutter är uppbyggt med widgets och i detta fall på kodblock 1 visas att “runApp()” tar den första widget (Center) som roten till trädet som ska byggas upp och lägger alla barn kopplade till roten [1]. Detta träd kommer då visualisera hur koden är uppbyggd och kan sträcka sig i långa sträckor beroende på hur många barn varje widget har. I detta fall har följande träd (figur 11) byggts upp:
Figur 11 exempel på hur ”kodblock 1” har byggts upp i trädform i Flutter
Även om Flutter är en konkurrent mot Facebooks React-Native har Google Flutter tagit inspiration av React. Själva tanken är att bygga upp applikationens användargränssnitt enbart med widgets. När tillståndet hos en widget ändras så skiljer den biten från föregående tillstånd ifall den behöver uppdatera sig. Detta gör att man kan minimera renderingen genom att undvika rendera om hela trädet utan bara dess delar som behöver renderas, vilket i sin tur bidrar till bättre prestanda för användaren [1].
Något som Flutter också har siktat på var att använda en annan arkitektur för utvecklaren att implementera i, vilket skulle hjälpa utvecklaren skapa en applikation på ett så simpelt sätt som möjligt. Enligt Google ska ingen erfarenhet inom utveckling hos mobilapplikationer behövas utan bara vara bekant med något programmeringsspråk för att starta ett projekt med Flutter [19].
3.2.1.1 Ramverkets språk och uppbyggnad
Utvecklarna av ramverket Flutter valde att använda programmeringsspråken Dart, C och C++ som byggstenarna för detta ramverk. Detta gjorde att de kunde utnyttja en metod kallad AOT vilket står för Ahead Of Time, själva konceptet med AOT är att den kompilerar koden till originell maskinkod under byggnadstiden så att den kan exekveras direkt på systemet baserat på faktum att alla system hanterar maskinkod [20]. Detta gör i sin tur att applikationen kommer renderas mycket snabbare med tanke på att koden i princip redan är färdig för rendering.
Denna metod hjälper dock inte utvecklaren något utan mestadels användaren av applikationen, i själva verket gör detta bara arbetet för utvecklaren segare vilket försämrar utvecklarens produktivitet. Det Flutter då experimenterade med var att inskaffa “stateful hot reload”, som är en fördel för utvecklarna vilket kan använda metoden JIT (Just In Time). Denna metod ska då vara motsatsen av AOT då den kompilerar koden medan programmet körs, det vill säga kompilerar på plats. Detta gör att utvecklaren får möjlighet att implementera med JIT metoden vilket gör att man kan ändra koden och ladda om allt utan att bygga om applikationen helt. Medan användaren får möjlighet att använda applikationen med metoden AOT som gör att känslan för applikationen blir bättre baserat på prestanda och kompileringstid [20][21][22].
3.2.1.2 Flutter paket och plugin
Så som React-Native har tillgång till NPM paket så har Flutter tillgång till paket via ”pub.dev”. Denna webbplats tillåter dartutvecklare att dela sina paket av lösningar till utvecklare för Dart eller Flutter, genom att använda kommandet pub publish [23]. Det speciella med Flutters paket är att de har ett poängsättningssystem som baseras på tre delar: popularitet, hälsa och underhållning. Dessa tre delar sammanfogas senare till ett helhetsbetyg som beskriver hur bra detta paket är för utvecklarna som sedan ska använda det. De tre delarna har tilldelats olika styrkor som ska påverka det allmänna betyget som paketet får:
● 50% popularitet ● 30% hälsa
● 20% underhållning [23].
Det speciella med Flutter paket är att man som utvecklare också kan göra originella lösningar genom att ändra mallen för paketet man ska skapa:
Flutter create --template=package packageName -- Skapar paket Flutter create --template=plugin pluginName -- Skapar plugin
Med detta kan man utveckla lösningar i traditionella programmeringsspråk vilket kan använda sig av specifika API:er för dess plattformar. Dessa plugins blev introducerade till Flutter 1.12 för en möjlighet att använda lösningar för olika plattformar, så en plugin kan ha ett paket för IOS, en för Android, web eller till och med bil [24].
Som en extra del för detta har man också möjlighet att kombinera en plugin för både Android och IOS men där krävs det fortfarande separata kodrader för vartdera plattform [24].
3.2.2 React-Native
React-Native är ett ramverk utvecklat av Facebook som introducerades först på React.js konferensen 2015. React-Native ramverket är gjort för att skapa mobila applikationer med ett gemensamt programmeringsspråk som idag är känt som JavaScript och XML [25]. React-Native har en vision som de har strävat efter från start av skapandet av detta ramverk: “write once, run anywhere” vilket står för skriv en gång, kör överallt. Baserat på att olika plattformar skiljer i design, känsla och i förmågor blir det svårt för utvecklarna att skapa en likadan applikation på olika plattformar. Samma typer av ingenjörer borde kunna skapa något på vilken plattform de än vill utan att behöva lära sig olika sorters teknologier eller arkitekturer för de olika plattformarna [26]. Från början var React-Native byggt för att endast kunna skapa mobila applikationer till IOS, men Android lades till senare vilket gjorde ramverket till ett utvecklingsverktyg för flera plattformar [25].
3.2.2.1 Ramverkets språk och uppbyggnad
Till skillnad från Flutter använder React-Native en blandning av programmeringsspråken JavaScript, Java, C++, Objective-C och Python med komponenter som byggmaterial baserad
på JSX element. Det som händer då bakom skynket är att den skrivna JSX koden går igenom en bro kallad “React-Native bridge” som anropar den originella renderingen via API:er till Objective-C (för IOS) och Java (för Android) så att den kan renderas på olika plattformar vilket gör detta ramverk till ett multiplattforms verktyg för mobila applikationer [27].
function helloWorldComponent() {
return ( <Text> Hello World </Text> ) }
Kodblock 2 kod bit på en funktion som returnerar ett JSX element
Detta är då en funktion (kodblock 2) som ska skicka tillbaka ett JSX element och det är på detta sätt React-Natives kodarkitektur är byggt på. Vanligtvis används klasskomponenter, så att varje komponent i gränssnittet ska ha sitt eget syfte att uppnå. Med detta blandar man in designmönster som DRY (Don’t repeat yourself) och SRP (Single responsibility principle) vilket hjälper utvecklingsprocessen samt gör applikationen framtidssäker [12].
class HelloWorldClassComponent extends React.Component { render() { return ( <View style={styles.container}> <Text>Hello World</Text> </View> ); }; }
//define your styles
const styles = StyleSheet.create({ container: { flex: 1, justifyContent: ‘center’, alignItems: ‘center’ }, });
Kodblock 3 kod bit exempel på hur en klasskomponent är uppbyggd
Följande kod i kodblock 3 är ett exempel på hur en klasskomponent kan se ut i React-Native. React-Native har också tillgång till något som heter “StyleSheet.create” vilket påminner väldigt mycket om CSS (Cascading Style Sheet). Med React-Native kan varje komponent acceptera en variabel som heter “style” vilket används för att placera in designvariabler liknande till CSS som används för webbdesign vilket ändra utseendet på delkomponenterna [28][29].
3.2.2.2 NPM paket
NPM är en pakethanterare för Node.js som tillåter JavaScript utvecklare enkelt att dela paket av lösningar på problem efter syfte [30]. Denna tjänst har ett stort utbud av paket vilket sträcker sig till alla möjliga lösningar som väntas på att användas av andra utvecklare, i sin tur resulterar i en mindre utvecklingsprocess eftersom stora delar av koden i princip redan är klar. NPM registret har idag över 1 miljon paket som är användbara enligt figur 15 därav är många av de inte säkra, enkel att hantera eller underhållna vilket man som utvecklare har fått uppleva under användning av vissa paket.
Så som Flutter paketen kan man använda kommandot npm publish för att publicera egen skapade paket. Något som NPM har tillgängligt är statistik på veckovisa nedladdningar som på
sätt och vis beskriver hur populärt ett paket är. Detta kan då verifiera att paketet är säkert att använda för utvecklingsprocessen.
3.3 Produktivitet
Enligt Caitlin Sadowski och Thomas Zimmermann finns det än idag ingen klar definition på vad produktivitet är eftersom ingen egentligen är överens om definitionen [5]. Det gäller att hitta ett koncept mellan olika faktorer som kan bestämma produktiviteten. Produktiviteten i denna studie kommer delas upp i två faktorer [5]. Dessa två faktorer är in och ut. Infaktorn är arbetet som krävs för arbetaren samtidigt som utfaktorn är värdet av mjukvaran för användaren. Detta kan omformuleras till att infaktorn agerar som kostnaden samtidigt som utfaktorn blir kvalitet och kvantitet av arbetet. Eftersom framgångsrika system ständigt behöver uppdateras och ändras kontinuerligt baserat på dess nya teknologier som idag framställs, gör detta att infaktorn (kostnaden) måste minimeras för att inte påverka produktägaren negativt eftersom uppdateringen av stora system kostar tid och pengar [5]. Ut faktorn är den som påverkar infaktorn för nästa uppdatering, det vill säga om en utfaktor (kvalitet och kvantitet) är låg så blir nästa uppdatering av produkten påverkad av den föregående. Ju mer detta sker desto värre blir det för produkten i slutet.
4 Empiri
4.1 Återanvändning av kod
Återanvändning av kod är en del inom utvecklingen av mjukvaror som dagligen övervägs för att erhålla simplicitet och kvalitet till projektet. Den mest uppenbara fördelen med detta är att utvecklaren inte behöver skriva lika mycket kod. Likväl finns det fler fördelar:
● Det gör koden enklare att läsa, hantera extraktion av klasser och metoder vilket har en effekt av att reducera storleken av en metod eller antalet av kodblock.
● Att använda klasser och metoder för att överväga återanvändningen av kod förbättrar strukturen av koden, håller en undan från dupliceringar och det viktigaste av allt gör koden lättare att underhålla för framtidens avsikt. Eftersom nya teknologier
kontinuerligt skapas måste företagen vara med i dessa steg för att attrahera kunder, detta gör att företagen som äger mjukvarorna vill hålla sin applikation uppdaterade och skickar då in arbetare för att uppdatera applikationen.
● Testning är en relativt stor del för stora mjukvaror idag, en populär metod för att implementera tester för sin kod/komponent är "unit testing". Återanvändning av kodblock som redan har blivit testade eller har färdig implementerad testning sparar tid och arbete.
[31].
Återanvändning är inte bara en faktor att överväga men också en regel att följa för alla utvecklare. Inom mjukvaruutveckling är förkortningen för denna regel "DRY" vilket står för "Don't Repeat Yourself" som refererar till att repetera inte dig själv på svenska. Det vill säga återanvänd kod när du behöver det [32].
Dessa två ramverk som ska jämföras är byggda på komponenter respektive widgets vilket gör att båda ramverken kan räknas som komponentbaserad utveckling. Med komponentbaserad utveckling har man möjlighet att använda färdigbyggda eller egenbyggda komponenter för att visualisera eller anpassa sitt program efter sitt syfte.
Med tanke på att antalet komponenter ute i marknaden ökar dagligen är det viktigt att hålla komponenterna lättförståeligt för utvecklarna. Genom att följa modellen i figur 1 kommer denna undersökning att omfatta tre kvalitet faktorer: begriplighet, anpassningsbarhet och pålitlighet som är beskrivet i 2.1 Koppling mellan frågeställningar och metod.
På respektive kvalitetsfaktor kommer metriker att testas genom att utföra en fallstudie på respektive ramverks bibliotek av specifika komponenter som vanligtvis används när en mobilapplikation utvecklas. De komponenter som har valts ska ha samma syfte på respektive ramverk och därmed jämföras via dessa metriker. Jämförelsen kommer ske via fallstudier på dessa metriker och betygsättas efter tillhörande matematiska modell.
Komponenterna som valts för respektive ramverk är:
Komponenter/widgets Flutter React-Native
Lista (genererar en lista)
ListView FlatList
Bild
(är en widget som visar en bild på en yta efter önskat mål.)
Image Image
Tabell 1 Lista av komponenter som ska undersökas
4.1.1 Kvalitetsfaktor ett (begriplighet) testas med hjälp av en
metrik EMI
EMI (Existence of Meta information)
Alla komponenter/widgets innehåller en så kallad metainformation som beskriver vad elementet gör [33][34][35][36].
Poängsättning efter figur 2:
Alla komponenter har tillgång till metainformation vilket leder till att EMI(r) = 1 på respektive ramverk och medelvärdet på detta blir därmed 1.
4.1.2 Kvalitetsfaktor två (anpassningsbarhet) testas med hjälp av
en metrik RCC.
RCC (Rate of Component Customizability) ListView
Flutters ListView har tillgång till 17 parametrar varav 14 av dessa kan användas av utvecklaren för att justera komponenten via variabler eller fasta värden. Utöver detta förekommer det också 14 metoder att utnyttja under exekvering varav en av de kan användas för att justera widgeten [35]. Poängsättning efter figur 3:
𝑂(𝑘) = 17 + 14 = 31 𝑆𝑚= 14 + 1 = 15 𝑅𝐶𝐶(𝑘) = 15/31 ≈ 0.48
FlatList
React-Native FlatList har 27 tillhörande parametrar som kan ändra på komponentens status. Av 27 är det 7 som inte har möjlighet till justering. Det finns 4 av 9 metoder som går att konfigurera komponenten med (skriv-metod) [33].
Poängsättning efter figur 3: 𝑂(𝑘) = 27 + 9 = 36 𝑆𝑚 = 20 + 4 = 24 𝑅𝐶𝐶(𝑘) = 24/36 ≈ 0.67
Image
Flutters Image har tillgång till 19 parametrar varav 16 av dessa kan användas av utvecklare för att justera komponenten via variabler eller fasta värden. Utöver detta förekommer det också 10 metoder att utnyttja under exekvering varav en metod kan användas för att justera widgeten (skriv-metod) [36].
Poängsättning efter figur 3: 𝑂(𝑘) = 19 + 10 = 29 𝑆𝑚 = 16 + 1 = 17
𝑅𝐶𝐶(𝑘) = 17/29 ≈ 0.59
Image
React-Native Image har 20 tillhörande parametrar som kan ändra på komponents status. Av 20 är det 7 som inte har möjlighet till justering. Det finns 0 av 6 metoder som går att konfigurera komponenten med (skriv-metod) [34].
Poängsättning efter figur 3: 𝑂(𝑘) = 20 + 6 = 26 𝑆𝑚 = 7 + 0 = 7
𝑅𝐶𝐶(𝑘) = 7/26 ≈ 0.27
4.1.3 Kvalitetsfaktor tre (pålitlighet) testas med hjälp av en metrik
ACDD.
ACDD (Amount of Commits per Development Days)
För att mäta graden av mognad för respektive ramverk används modellen ACDD(r) där antalet commits mäts med avseende på antalet utvecklingsdagar sedan första utgåvan av ramverket. För att hitta första commiten för respektive ramverk manipulerades adressfältet för att komma till sista sidan som innehåller den första commiten. På adressfältet lades det märke till att den ändras efter en commit-id på variabeln “after”. Där kunde man addera på antalet commits som sidan ska hoppa över för att generera nästa mängd. I detta fall har det lagts på 18 230 som visas i slutet av adressfältet på figur 12.
Figur 12 bild på länken som användes för att ta reda på första commiten som skedde för Flutter respektive
React-Native
Flutter React-Native
Första commit (23/10/2014) (01/30/2015)
Ålder (i dagar) 1999 1900
Totalt antal commits 18 407 19 847
Tabell 2 visualiserar resultatet av ACDD [7][8][37][38].
Poängsättning efter figur 4: ● React-Native 𝐶(𝑟) = 19 847 𝑈𝑑(𝑟) = 1900 𝐴𝐶𝐷𝐷(𝑟) = 19 847/1900 = 10.45 ● Flutter 𝐶(𝑟) = 18 407 𝑈𝑑(𝑟) = 1999
𝐴𝐶𝐷𝐷(𝑟) = 18 407/1999 = 9.21
4.2 Support av enhetens funktioner
Att skapa en mobilapplikation kan vara svårare än vad man tror, speciellt om man ska implementera en likadan på två olika plattformar. Multiplattforms teknologin slog till hårt på detta då den underlättar implementeringen för utvecklarna och sparade tid för företagen. Med denna teknologi förekommer det också nackdelar. Ett exempel på en nackdel är att man inte har tillgång till all originell kod eller funktionaliteter som traditionell utveckling medför på plattformarna.
I detta fall kommer respektive plattforms hårdvarufunktionaliteter att jämföras med tanke på att multiplattforms verktyget i sig kanske inte har support av dessa funktionaliteter vilket kan påverka produktiviteten baserat på att man blir begränsad.
Det existerar massor av funktionaliteter som kan göra mobilapplikationen "smartare" och mer användbar för användaren. Det är en kvalitetsaspekt av användargränssnitt, enkel att använda, effektiv, behaglig och mer [39].
Sådana funktionaliteter gör det enklare för användaren som till exempel användning av kamera till att skanna QR: koder istället för att skriva hela numret manuellt på applikationer som Swish, bara denna funktionalitet har ökat användningen av kameran med 236% i november [40]. Det finns ett flertal av hårdvarans funktionaliteter som originell Android/IOS utveckling stödjer, men som besvarat ovanför finns inte alla möjligheter inom multiplattformsutveckling vilket gör att utvecklingen kan bli begränsad.
Funktionaliteter från hårdvaran som valts att undersökas är Bluetooth, kamera, NFC, sensorer, Wi-Fi, GPS och biometri.
Funktionalitet React-Native Flutter
Bluetooth Ja (tredjepartsbibliotek) Ja (plugin)
Kamera Ja (react-native-community) Ja (plugin)
NFC Ja (tredjepartsbibliotek) Ja (plugin)
Sensorer Ja (tredjepartsbibliotek) Ja (plugin)
Biometri Ja (tredjepartsbibliotek) Ja (plugin)
Wi-Fi Ja (tredjepartsbibliotek) Ja (plugin)
GPS Ja (react-native-community) Ja (plugin)
Tabell 3 visualiserar hur respektive ramverk har tillgång till givna funktionaliteter
React-Native har tillgång till alla hårdvarufunktionaliteter listade i kraven men dessa sker via tredjepartsbibliotek. Enligt figur 5 ska dessa poäng tilldelas efter dess metrik (d.v.s. 0.5 per tjänst) men två av dessa tjänster (Kamera & GPS) finns tillgängliga via tredjepartsbibliotek som skapats av react-native-community. React-native-community är en organisation på Github som drivs av en community där de samarbetar med den ansvarige utvecklargruppen av ramverket React-Native för underhållning av dess paket och bibliotek [41]. Därför bestäms det i denna
undersökning att dessa tredjepartsbibliotek räknas in som ramverkets egna bibliotek eftersom de undviker nackdelarna.
Flutter har tillgång till alla hårdvarufunktionaliteter listade i kraven men dessa kommer man åt via plugins. Plugins är väldigt lik tredjepartsbibliotek men Flutter har stora krav för paketets rankning vilket kan användas för att verifiera att paketet är pålitligt som då tar bort en av de stora nackdelarna för tredjepartsbibliotek som nämnts i 4.6 Tredjepartsbibliotek [23]. Därför tilldelas delarna 1 poäng istället för 0.5 som ett tredjepartsbibliotek egentligen skulle få baserat på deras pålitlighet.
Poängsättning efter figur 5:
Efter att ha undersökt källorna och där studien har inkluderat dokumentationen av Flutter och React-Native kan tilldelningen av poäng ske efter figur 5. Med detta har React-Native tilldelats 𝑛(𝑅𝑒𝑎𝑐𝑡 − 𝑁𝑎𝑡𝑖𝑣𝑒) = 4.5 / 6 = 0.75 respektive Flutter tilldelats 𝑛(𝐹𝑙𝑢𝑡𝑡𝑒𝑟) = 6 / 6 = 1 poäng.
4.3 Start av projekt
För att använda ett ramverk krävs oftast ett flertal installationer för att initiera ett projekt. Syftet med detta är att undersöka hur många steg som krävs för respektive ramverk eftersom dessa steg kan påverka utvecklingstiden om en utvecklare är ny för användning av detta ramverk. Antalet steg kommer att räknas från antalet kommando och installering som krävs för att initiera projektet hos vartdera ramverk. Dessa initieringar kommer att ske på Windows eftersom Flutter kan skilja för Mac eller Linux användare. Denna undersökning kommer därmed att ske på utvecklingsmiljön Visual studio code där denna undersökning utgår från att Visual studio code redan är installerat. Alla texter med grå fält är i detta fall kommando i en terminal.
React-Native
För React-Native behöver man tillgång till NPM tjänsten för att initiera ett projekt. Sedan har man som React-Native utvecklare två vägar för att initiera ett projekt, nämligen EXPO CLI Quickstart eller React-Native CLI Quickstart. Denna undersökning kommer att utgå efter vägen med minst antal steg för initiering av ett projekt som i detta fall blir EXPO CLI Quickstart.
1. Installera Node.js
2. npm install -g expo-cli
3. expo init projectName - React-Native projekt med namnet: projectName [42].
Poängsättning efter figur 6: 𝑛(𝑅𝑒𝑎𝑐𝑡 − 𝑁𝑎𝑡𝑖𝑣𝑒) = 3
Flutter
För Flutter finns det två vägar att ladda ner SDK paketet som krävs för att initiera ett Flutter projekt. Man kan antingen manuellt ladda ner en zip fil och extrahera den på en specifik plats. Men undersökningen kommer att utgå efter vägen med minst antal steg för initiering av ett projekt.
I terminalen ska följande kommando anges: 1. cd C:\src
2. git clone https://github.com/flutter/flutter.git -b
Du kan sedan använda kommandot flutter doctor för att visa allt som behövs för att initiera ett projekt.
3. installera android studio
4. installera SDK paketet Android SDK tools via Android Studio 5. installera extension Flutter i Visual studio code
6. flutter create projectName - flutter projekt med namnet: projectName
[43].
Poängsättning efter figur 6: 𝑛(𝐹𝑙𝑢𝑡𝑡𝑒𝑟) = 6
4.4 Popularitet bland intressegrupper
Syftet med intressegrupper (community) är för utvecklare runt om i världen att ha möjligheten för att kunna hjälpa varandra lösa problem som man kanske ha stött på tidigare eller bara har allmän erfarenhet kring. Detta gör att utvecklare enklare kan ge sig in i andra miljöer, system eller programmeringsspråk. Google har nuförtiden blivit en stor faktor inom utvecklingen. Det har blivit som en självklarhet för en utvecklare idag att kunna googla fram en lösning.
Dagens generation av utvecklare använder internet för att samarbeta med att lösa vanliga problem, hantera felmeddelanden och lära sig metoder kring specifika system [44].
Med tanke på att programmering idag har blivit så populär och att det finns en hel mängd av olika programmeringsspråk och system så blir det svårt för en utvecklare att kunna anpassa sig till alla. Det är här intressegrupperna slår till som störst, med hjälp av intressegrupperna och dokumentationen kan utvecklare utöka sin kompetens bland olika system.
Det finns många intressegrupper tillgängliga men från erfarenhet är de två största StackExchange (även känd som StackOverflow) och Github.
4.4.1 Github
Enligt Github har Flutter 3748 fler stjärnor än React-Native:
Flutter har 89 882 Github stjärnor och React-Native har 86 134 Github stjärnor [7][8]. Poängsättning efter figur 7 för Github:
𝑛(𝐹𝑙𝑢𝑡𝑡𝑒𝑟) = 89 882
𝑛(𝑅𝑒𝑎𝑐𝑡 − 𝑁𝑎𝑡𝑖𝑣𝑒) = 86 134
4.4.2 StackOverflow
Stackoverflow erbjuder statistik som visar procentuellt hur många frågor som skapas per månad för respektive ramverk:
Figur 13 visualiserar statistik på StackOverflow frågor för respektive ramverk
På figuren ovanför kan man se hur Flutter och React-Native under tidigare år konkurrerat om vilket ramverk som trender mest med avseende på antal frågor som procentuellt har skapats per månad [18]. Detta har i sin tur bevisat att ramverken är aktuella eftersom många utvecklare dagligen använder det, vilket gör att denna statistik beskriver skillnaden i popularitet mellan ramverken under en kortare period. En ökad i popularitet innebär att dess community växer vilket i sin tur kan hjälpa utvecklarna att hitta lösningar tillsammans.
Poängsättning efter figur 7 för StackOverflow: 𝑛(𝐹𝑙𝑢𝑡𝑡𝑒𝑟) = 1.5%
𝑛(𝑅𝑒𝑎𝑐𝑡 − 𝑁𝑎𝑡𝑖𝑣𝑒) = 1.35%
4.4.3 Google Trends
Eftersom Google har en så stor betydelse för att lösa problem inom programmering och utveckling i sig så vore det absurt att inte ta med statistik från Google. Problemet är att de flesta som söker efter en lösning skriver oftast in felmeddelandet, förkortningar på ramverket eller vad problemet är. Detta gör att trenden ej kan bedömas lika enkelt som trenderna på Github eller Stackoverflow som använder taggar. För att det skall förbli rättvist jämförs endast två söktermer, alltså React-Native respektive Flutter. Enligt Googles statistik så har React-Native fler antal sökningar över tid vilket visas i figur 14.
𝑛(𝐹𝑙𝑢𝑡𝑡𝑒𝑟) = 81
Figur 14 visualiserar statistik på givna termer som blivit sökta under senaste 5 åren på Google
4.5 Dokumentation
Från 2.1.5 Dokumentation citerade Anna Wingkvist, Rüdiger Lincke, Morgan Ericsson och Welf Löwe: “The quality of technical documentation and user manuals is an important part of the perceived quality of a product” [14]. Detta citat beskriver hur viktigt det är att dokumentationen framställer informationen på ett bra sätt för utvecklaren så att kvalitén av produkten optimeras. Genom att utgå från figur 8 kommer tre kriterier från i 2.1.5
Dokumentation att undersökas varav tilldelas poäng efter Ja/Nej - har tillgång till/har ej tillgång
till. Två av tre kriterier kommer att undersökas på komponenter/widgets från respektive ramverk med samma syfte för att båda ramverken ska ha samma förutsättningar. Det tredje kriteriet överväger navigering vilket ingår i hela dokumentations webbplats. De komponenter/widgets som har valts att undersökas visualiseras på tabell 4:
Komponenter/widgets Flutter React-Native
Lista (genererar en lista)
ListView FlatList
Bild
(är en widget som visar en bild på en yta efter önskat mål.)
Image Image
Tabell 4 Lista på komponenter som ska undersökas under 4.5 Dokumentation
4.5.1 Kraftfull navigering
Båda ramverken bidrar med navigering genom länkar, sökfält och träd av komponenter/widgets. Enligt figur 8 tilldelas då dessa ramverk ett poäng var baserat på faktum att man som utvecklare har tillgång till dessa via deras dokumentations- och API webbplatser.
