Christine Björemo
En kvalitativ studie om Flutter
Apputveckling inom crossplattform
A qualitative study about Flutter App development in cross-platform
Informatik C-uppsats
Termin: VT-2020
Handledare: Monika Magnusson
2
Sammanfattning
Syftet med denna kandidatuppsats i informatik är att undersöka på vilket sätt ramverket Flutter underlättar för dagens apputvecklare i cross-plattformmiljöer. Uppsatsen belyser för- och nackdelar med Flutter utifrån apputvecklare-perspektiv.
Det största problemområde från tidigare studier och forskningar inom cross- plattformutveckling är främst den undermåttliga dokumentation samt långa utvecklingstider.
Denna kvalitativa studie är fokuserad på dessa problemområden och resultatet presenteras under kapitel 4 ”Resultat”.
En analysmodell har utformats och använts i syfte att, för respondenter, svara på relevanta frågor där ramverket Flutter hanterar dessa viktiga problemområden.
Slutsatsen av denna studie visar att det finns ett tydligt mönster där ramverktyget Flutter har satsat på att hantera dessa problemområden genom följande styrkor:
Verktyget ”Hot Reload” (hjälpmedel som uppdaterar koden för att snabbt se ändringar direkt i simulatorn)
Dart (ett programmeringsspråk)
Dokumentation (tydlig, alltid i tid och flera olika kommunikationskanaler)
Parallellt med kandidatuppsatsen har författaren utvecklat en egen app via Flutter. Syftet med denna app är att underlätta semesterplaneringen åt en avdelning på företaget AFRY.
I denna kandidatuppstats används ej författarens egna upplevelser med Flutter som empiri men avslutar uppsatsen med egna reflektioner.
Nyckelord: Cross-plattform, Dart, dokumentation, Flutter, Hot Reload, utvecklingsmiljö och utvecklingstider.
3
Abstract
The purpose of this bachelor's thesis in informatics is to investigate in what way the framework Flutter facilitates for today's app developers in cross-platform environments.
The essay highlights the pros and cons of Flutter from an app developer's perspective.
The biggest problem area from previous studies and research in cross-platform development is mainly the substandard documentation and long development times.
This qualitative study is focused on these problem areas and the results are presented in Chapter 4 "Results".
An analysis model has been designed and used to, for respondents, answer relevant questions where the Flutter framework deals with these important problem areas.
The conclusion of this study shows that there is a clear pattern where the framework tool Flutter has invested in dealing with these problem areas through the following strengths:
The tool "Hot Reload" (tool that updates the code to quickly see changes directly in the simulator)
Dart (a programming language)
Documentation (clear, always on time and several different communication channels)
In parallel with the bachelor's thesis, the author has developed his own app via Flutter. The purpose of this app is to facilitate vacation planning for a department at the company AFRY.
In this master's essay, the author's own experiences with Flutter as empirical data are not used but conclude the essay with his own reflections.
Keywords: Cross-platform, Darts, documentation, Flutter, Hot Reload, development environment and development times.
4
Förord
Jag vill först tacka min fantastiska handledare från Karlstad universitet för all support och stöttning du givit mig. Tack för att du har stått ut med mig under hela processen och svarat på mina frågor. Min handledningsgrupp från universitetet har varit fantastisk, vi har stöttat och hjälpt varandra som har lett till att denna upplevelse i examineringsarbetet rullat på bra.
Jag vill rikta ett tack till examinator John-Sören som hjälpt mig med upplägg och språk av uppsatsen.
Min handledare från AFRY vill jag också tacka för all hjälp med att komma igång med projektet av appen och att jag fick dela denna upplevelse med er, även om den har varit ganska speciellt med tanke på Corona-tider.
Ett stort tack vill jag också rikta till pappa som hjälpt till med korrekturläsning, språk, samt hjälp under våren.
Sist men inte minst tacka min bror med fru som hjälpt mig med korrekturläsning och stöd under alla läsår på Karlstad universitet.
Tusen tack till alla!
Karlstad, augusti 2020
Christine Björemo
5
Innehållsförteckning
1. Inledning ... 8
1.1 Bakgrund ... 8
1.2 Syfte ... 10
1.3 Undersökningsfrågor ... 10
1.4 Målgrupp ... 10
1.5 Avgränsning ... 10
2. Teoretiska utgångspunkter och perspektiv ... 11
2.1 Källkritik ... 11
2.2 Mobila operativsystem... 11
2.3 Native apputveckling ... 12
2.4 Hybrid ... 12
2.5 Cross-plattform ... 13
2.5.1 Säkerheten inom appar ... 14
2.6 Flutter och Dart ... 14
2.7 Tidigare studier och forskningar ... 17
2.8 För- och nackdelar med Flutter ... 19
2.8.1 Fördelar med Flutter ... 19
2.8.2 Nackdelar med Flutter ... 20
2.9 Analysmodell ... 20
3. Metod ... 22
3.1 Kvalitativ forskning ... 22
3.2 Validitet och reliabilitet ... 23
3.3 Intervju ... 23
3.4 Urval av respondenter ... 24
3.5 Etiska överväganden ... 25
3.6 Dataanalys ... 25
4. Resultat ... 27
4.1 P1 Utvecklingstakt och P2 Dokumentation ... 27
4.2 P3 Blandning av olika programmeringsspråk och P4 Filstorlek av utvecklad app ... 29
4.3 P5 Animationer ... 31
4.4 P6 Utvecklingstid ... 32
6
4.5 P7 Saknad av Hot Reload ... 33
4.6 Fördelar med Flutter ... 33
4.7 Nackdelar med Flutter ... 34
4.8 Semesterplanerings-appen... 34
4.8.1 Calendar ... 35
4.8.2 Home ... 36
4.8.3 Overview ... 37
4.8.4 Menu ... 38
5. Analys ... 39
5.1 P1 Utvecklingstakt och P2 Dokumentation ... 39
5.2 P3 Kodblandning och P4 Filstorlek av färdigutvecklad app ... 39
5.3 P5 Animationer ... 40
5.4 P6 Utvecklingstid ... 40
5.5 P7 Hot Reload ... 41
5.6 Flutter – ett ramverk som passar alla? ... 41
5.7 Modifierad analysmodell ... 43
6. Slutsats ... 45
6.1 På vilket sätt har Flutter underlättat för apputvecklare inom cross-plattform? ... 45
6.2 Är Flutter anpassat för nybörjare inom apputveckling? ... 46
6.3 Fördelar och nackdelar om Flutter ... 46
6.4 Semesterplanerings-appen... 47
Källförteckning ... 48
Muntliga källor ... 51
Bilagor ... 52
Bilaga 1: Samtyckesblankett... 52
Bilaga 2: Intervjuguide utifrån erfarenhetperspektiv ... 53
Bilaga 3: Intervjuguide utifrån nybörjarperspektiv ... 54
7
Terminologi
API (Application Programming Interface) - gränssnitt som utvecklare kan programmera mot.
Cross-plattform - multiplattform, kompileras till att appen kan köras på olika operativsystem.
Hot Reload – ett hjälpmedel som gör det möjligt att snabbt se resultat av kodändringar under tiden utvecklaren skriver kod utan att appen startas om.
IDE (Integrated Development Environment) – utvecklingsmiljö-program som utvecklare använder för att skriva kod.
JDK (Java Development Kit) - utvecklingsverktyg för att kunna utveckla appar med hjälp av Java.
Maskinkod - (programmeringsspråk som datorns hjärna, CPU, förstår och klarar att exekvera).
Native - programvara/app avsedd att köras endast i ett specifikt operativsystem med dess specifika programspråk. Exempelvis en native iOS-app kan inte köras i en androidmiljö.
Objective-C - objektorienterad påbyggnad av programmeringsspråket C som används av iOS.
Open Source - öppen källkod, där du själv som utvecklare dela med sig av mjukvara samt att utvecklare/privatperson blir leverantörsoberoende.
Plugin – ett program i programmet, som installeras som en del av ett annat program. Plugin- programmet tillför det andra programmet med nya egenskaper.
Ramverk – Programpaket som läggs ovanpå programmeringsspråket för att påskynda och underlätta utvecklingen.
SDK (Software Development Kit) - uppsättning utvecklingsverktyg, kodramverk, kodexempel på en utvecklingsavdelning. Är ett ofta ett bibliotek av API:er.
Skia – 2d grafiskt bibliotek och fungerar som grafisk motor för bland annat Google Chrome, Andorid och Firefox.
UI (User Interface) - Användargränssnitt.
Xcode - är Apples IDE. Det grafiska gränssnittet för att utveckla iOS appar.
8
1. Inledning
Inledningskapitlet beskriver bakgrunden till appars (applikationer) tillkomst. Från kapitlet får läsaren en uppfattning om kandidatuppsatsens syfte. Här presenteras även
undersökningsfrågorna som kommer att besvaras i kandidatuppsatsen, avgränsningar som anses vara nödvändiga av författaren och avslutas med målgruppen som uppsatsen främst inriktar sig mot.
1.1 Bakgrund
Apputvecklingen och användningen av appar i mobiltelefoner fick sitt första uppsving 2007, direkt efter att Apple lanserat sin första version av iPhone (Nordström 2019a). Till en början fanns det förinstallerade appar som endast gick att använda på Apples produkter,
exempelvis mejl och kalender. Dessa förinstallerade appar var “låsta” (ej tillgängliga) för andra utvecklare och därmed ej tillgängliga för andra utvecklingsföretag. Det dröjde inte länge förrän en så kallade hackare (hacker), som kallar sig för “Nightwatch”, hade låst upp Apples skydd mot andra utvecklare. Nightwatch lyckades installera den allra första
egenutvecklade appen i sin iPhone. Kort därefter, ganska exakt ett år efter lanseringen av första iPhonen, släppte Apple den första appbutiken “Apple App Store” (idag Apple Store).
Där fanns ungefär 500st appar som var skrivna i Apples egna programmeringsspråk Objective-C (Nordström 2019a).
Konkurrenten Google lanserade 2008 sin första telefon som då också hade redan
förinstallerade appar. En av dessa förinställda apparna var Android Market (Google Play) som motsvarar Apple Store. Googles apputveckling är inte utvecklad i samma
programmeringsspråk som Apple använder. Google använder programmeringsspråket Java.
Det är konstaterat att användning av smartphone och andra liknande plattformar ökar stadigt i dagens samhälle (Anderson och Gestwicki 2011, s32). En konsekvens av detta är att det sätter press på utvecklingsmiljöerna som utvecklarna använder. Dessutom ställer dagens smartphones-användare högre krav.
Vid utveckling av appar finns det två olika typer av appar, webbaserad applikation och mobila applikationer (mobilappar). Denna kandidatuppsats fokuserar på mobilappar. Inom mobilappar finns även där olika val och de två största valen är att skapa en native-
applikation (native-app) eller cross-plattform-applikation. Skillnaden mellan native och cross-plattform är att en native-app är plattformsberoende, vilket innebär att de är
utvecklade till en specifik plattform och plattformens operativsystem. Cross-plattform är ej beroende av specifik plattform eller plattformens operativsystem.
Operativsystemen Android och iOS har både för- och nackdelar med att de är skrivna i olika språk enligt Nordström (2019a).
De två största utmaningarna för utvecklare av appar har varit att de måste hantera två olika språk, två separata uppsättningar hårdvara och två olika appar att underhålla samt
vidareutveckla (Nordström 2019a). Det kräver inte bara tid utan också en hel del resurser och många utvecklingsproblem kan stötas på under utvecklingens gång.
9 En utav de allra största fördelarna med cross-plattform är att gör det möjligt att köra en app på bland annat iPhone och Android trots att de har olika operativsystem. Nordström
(2019b) anser att cross-plattform har under de senaste åren blivit mer och mer populär, vilket bekräftas av forskning gjord av Harsh et al. (2019). Nordström (2019b) skriver i sitt blogginlägg även att cross-plattform löser många av de största utmaningarna som
utvecklare fram tills nu har fått möta. När utvecklare använder sig av cross-plattform behövs inte längre två separata uppsättningar av hårdvara, en för Android-plattformar och en för iPhone-plattformar (Grzmil et al. 2017). Utvecklarna behöver inte heller längre hantera olika språk samtidigt.
Vid utveckling av appar med hjälp av cross-plattform så finns det även här
problemområden. Utvecklaren Ermakov och marknadsundersökaren Horbenko (u.å.) har uppmärksammat bland annat följande problemområden:
1. Dokumentation
2. Hantering av blandning av programmeringsspråk
3. Saknaden av Hot Reload (hjälpmedel som uppdaterar koden för att snabbt se ändringar direkt i simulatorn)
Hartmann et al. (2011) har även de uppmärksammat vissa problemområden med
apputveckling i cross-plattform. De problemområden som upptäcks sammanställs i avsnitt 2.7.
Inom apputveckling i cross-plattform finns det olika ramverk att välja mellan och denna kandidatuppsats inriktar sig på ett specifikt ramverk för cross-plattform, FlutterTM.
Det finns väldigt få forskningar kring Flutter, vilket är en utav anledningarna till denna kandidatuppsats. Det finns dock några tidigare studier och uppsatser om jämförelser mellan Flutter och ett annat (cross-plattform) ramverk som React Native eller Xamarin. Till exempel Duvanå och Svenssons (2019) som är en begränsad studie men som har i slutsatsen fördel till Flutter, behövs därför fler djupgående studier om Flutter. Vilket stärker till varför denna kandidatuppsats är viktigt och intressant. Duvanå och Svensson (2019) prövade att använda ramverken React Native, Xamarin och Flutter i sin studie genom att skapa enkla funktioner som avochpå-knappar, dragreglage och vanliga klick knappar. Från ett nybörjarperspektiv beskriver de bland annat att Flutter var enkelt att använda och hämta information om hur de skulle starta upp projekt.
Denna kandidatuppsats skapades också efter en idé från författaren efter praktik på företaget AFRY. Idén uppstod efter de uttryckt sig vara i behov av uppdatering vid semesterplanering, i dagsläget använder de sig av Excelblad. Efter framlagt förslag blev författaren tipsad av sin tilldelade handledare från AFRY att utveckla appen i Flutter.
Handledaren tipsade om just Flutter för det är något som de är nyfikna på och vill veta mer om. Utvecklingen av den interna semesterplanerings-app sker parallellt med
kandidatuppsatsen och resultatet presenteras i Resultatkapitel. Utvecklingen av appen och tillkommande lärdomar har räknats in i slutsatser där författaren beskriver sina upplevelser med Flutter.
10
1.2 Syfte
Syftet med denna kandidatuppsats i informatik är att undersöka på vilket sätt cross- plattform ramverket Flutter underlättar för dagens apputvecklare och blivande apputvecklare. Uppsatsen ska också belysa för- och nackdelar med Flutter.
1.3 Undersökningsfrågor
Flutter är intressant ramverk inom cross-plattform som är fortfarande nytt på marknaden och allt fler som företag och privatpersoner är nyfikna på ämnet. Därför har denna
kandidatuppsats fördjupat sig i Flutter och upptäcker vad det finns för problemområden inom cross-plattform. Följande undersökningsfrågor (UF) har utformats:
UF1. Har Flutter löst de problem som tidigare påverkat apputveckling inom cross- plattform utifrån utvecklarperspektiv och i så fall på vilket sätt?
UF2. Fungerar Flutter som ett första ramverk för de som är nybörjare eller är Flutter främst riktat mot de erfarna inom apputveckling?
UF3. Vilka är för- och nackdelarna med Flutter?
1.4 Målgrupp
Målgruppen för kandidatuppsatsen är för tidigare erfarna apputvecklare, blivande apputvecklare, studenter inom informatik och AFRY.
1.5 Avgränsning
Eftersom kandidatuppsatsen har en tidsbegränsning har författaren gjort avgränsningen med semesterplanerings-appen att endast utforma den som en prototyp som är uppbyggd med möjlighet till vidareutvecklingar och fokuserar på Android-perspektivet. Tiden anses inte räcka till för att testa iOS-perspektivet. Med vidare utvecklingar innebär det att prototypen innehåller endast grafiska användargränssnitt och ingen bakomliggande logik.
Uppsatsens syfte är inte att studera färdiga appar från användarperspektiv, utan fokuserar mer på för- och nackdelar under apputvecklingen från utvecklarperspektiv. Vid avslut presenteras prototyp-appen för AFRY och författaren berättar själv om sin upplevelse med Flutter och avslutande rekommendationer.
11
2. Teoretiska utgångspunkter och perspektiv
Kapitlet inleder med källkritik där författaren beskriver hur information hämtats med olika sökmotorer. Därefter beskrivs kort de två största mobila operativsystem som konkurrerar mest idag. Kapitlet fortsätter sedan med dokumentation om native, cross-plattform, Hybrid, Flutter och Dart. Här belyses för- och nackdelar med Flutter. Avslutningsvis ges en
analysmodell avsedd för UF1 som är framtagen av författaren och är baserad på de insamlade studier och forskning om cross-plattform.
2.1 Källkritik
För uppsatsen har hämtats information med hjälp av Karlstads universitetsbiblioteks sökmotor Onesearch samt Google Scholar. Där användes svenska söktermer som ”cross- plattformutveckling”, ”apputveckling” och ”Flutter”, och engelska sökord som ”cross- platform development”, ”Flutter”, ”native development”, ”ReactJS”, ”React native”,
”Xamarin” och ”software engineering”. Det resulterade i akademiska artiklar som bidragit till denna litteraturgenomgång. Akademiska forskningsartiklar om just Flutter var förstås få, men sökningarna resulterade även i andra intressanta artiklar och relevant information som kan bedömas som pålitlig eftersom de använts i tidigare studier.
För kandidatuppsatsen har förutom intervjuer också samlats in information från andra utvecklare, som dessa har lagt upp på bland annat programmerings- och IT-bloggar. Dessa data redovisas också i detta kapitel, bland övriga publicerade källor. Författaren är
medveten om att denna information kan anses som tendensiös och har därför
referensgranskat dessa bloggartiklar. Referensgranskningen genomfördes genom att noga följa upp bloggarnas referenser som de själva använder för att på så sätt kunna bedöma tillförlitligheten hos deras egna bidrag. Artiklar och utdrag från webbtidskrifter har också använts för att samla in relevant och aktuell information om ämnet.
2.2 Mobila operativsystem
Under studiens gång används Android Studio för att kunna använda deras simulator och all kod är skriven i Visual Studio Code, utvecklingsmiljö (IDE) valt av författaren. Detta val baserades på att författaren föredrar Visual Studio Code och är mindre välbekant med Android Studio.
Android-appar är byggt på öppen källkod och deras mjukvara är Linux-baserad (Android, 2019). Android-appar kan skrivas i Java, Kotlin eller C++ (Monus, 2019). Androids
utvecklingsmiljö (IDE) är Android Studio. Vid skapande av ett nytt projekt i Android Studio följer det med en eller flera moduler med källkodsfiler och resursfiler för att hjälpa
utvecklaren (Android, 2020).
iOS är operativsystem som körs på för Apples produkter som bland annat iPhone, iPad och iPod Touch. Från start skrevs iOS-appar i programmeringsspråket Objective-C men har för det mesta övergått till Swift. För att kunna utveckla en iOS-app måste utvecklaren ha tillgång till en Apple-dator, Mac, och måste då ha den senaste versionen av Xcode (Apples utvecklingsmiljö för det grafiska gränssnittet). Amazon (AWS, Amazon 2020) tillägger att det
12 tillkommer olika ramverk som har unika egenskaper som ger utvecklaren tillgång till
exempelvis iPhone- eller iPad-kameran, utforska musik och så vidare.
2.3 Native apputveckling
Native apputveckling är en app av mjukvaruprogram som utformas enbart för en specifik plattform och dess språk (Harsh et al. 2019). Det innebär att en app som är skapad för att användas på Androids mobila enheter kan inte appen hämtas på en till exempel iPad eller iPhone. Harsh et al. (2019) nämner att native-appar är ett bra val när det kommer till prestationsparametrar som; enkel uppdatering, rendering av gränssnitt och
användaruppleveser. Native-appar är dock mer kostsamma än cross-plattform eftersom de är plattformsberoende och kräver två uppsättningar av hårdvara vid utveckling av flera operativsystem (Harsh et al. 2019). Native utveckling behöver inte vara appar till
smartphones (även om det är den mest populäraste enheten), det kan även användas till SmartTv eller andra liknande enheter (Monus, 2019).
Till skillnad från webbsidor och webbapplikationer så kan inte mobila native-appar köras på webben. Native-appar måste laddas ner med hjälp av sin mobila enhet eller liknande.
Nedladdningen hämtas från Apple Store eller Google Play beroende på vilket operativsystem som används (Monus, 2019).
Det skiljer sig lite åt vid native apputveckling mellan iOS och Android. Det kan utvecklas en native Android app på vanlig PC, som har operativsystemet Microsoft eller Linux, eller på en Mac som har Mac OS (Apples operativsystem). Men inte tvärtom, vilket menas att det inte kan utvecklas en native iOS app på något annan enhet än Apples enheter (Monus, 2019).
När en native app (även cross-plattform) är färdigutvecklad ska den läggas ut till
offentligheten genom att ladda upp sin app på Apple Store eller Google Play. Även här skiljer det sig åt, på Apple Store granskas alla appar som läggs upp och appen kan bli nekad om den inte håller måttet. Monus (2019) menar att om iOS appen anses; inte hålla måttet på
prestandan, innehåller säkerhetsfel eller att appen inte genererar något värde raderas appen från Apple Store. Detta sker inte i Google Play, för Android-appar.
2.4 Hybrid
Denna kandidatuppsats fördjupar sig inte på hybridappar men är bra att känna till att det finns fler alternativ till apputveckling.
Hybrid apputveckling är en blandning mellan native och cross-plattform (Harsh et al. 2019).
Det som kännetecknar en hybridapp är att de använder samma programmeringsspråk som webappar. Det innebär programmeringsspråk som HTML, CSS och JavaScript. Harsh et al.
(2019) beskriver att det som skiljer en webapp och hybridapp åt är att utvecklaren injicerar en eller några rader av HTML kod i en så kallad ”native-container”. Harsh et al. (2019) menar att en native-container är en bit kod som gör att appens utseende (grafiska gränssnittet) liknar en native-app.
13
2.5 Cross-plattform
Sedan en tid tillbaka har allt fler utvecklare och företag fått upp ögonen för cross-plattform.
Som beskrivet tidigare i denna kandidatuppsats kan en app som är utvecklad i cross- plattform användas på både Android-enheter och iOS-enheter. Manchandas (2019) uttrycker sig att cross-plattform är framtidens metod inom apputveckling.
För att på ett tydligt sätt belysa skillnaderna mellan native-appar och cross-plattform-appar ur ett utvecklarperspektiv belyser följande tabell några av de mest kritiska skillnaderna.
Tabell 1.Visar de mest kritiska skillnaderna mellan native-appar och cross-plattform-appar.
Parameter Native-Appar Cross-plattform-Appar
Kostnad Nästan ingen återanvändning av kod, endast grafik kan (delvis) återanvändas. Varje plattform blir ett eget parallellt projekt. Kostnaden ökar
i takt med antalet operativsystem eftersom bland annat två uppsättningar av hårdvara krävs
(Freberg, 2012).
Cross-plattform erbjuder stor grad av återanvändning av kod. Låg kostnad att
lägga till stöd för ytterligare operativsystem och endast en uppsättning av hårdvara krävs (Freberg,
2012).
Kod:
Användbarhet Fungerar för en specifik plattform
(Freberg, 2012). Kod kan användas för flera plattformar (Freberg, 2012).
UI (User Interface) Konsekvent
Konsekvent med enhetens UI-
komponenter (Freberg, 2012). Begränsad konsekvens med enhetens UI-komponenter
Prestanda “Sömlös” prestanda, med tanke på att appen är utvecklad för enhetens
operativsystem
Hög på prestanda, men problem med förseningar och hårdvarukompatibilitet
är inte ovanligt Enhets
Åtkomst Plattform SDK (utvecklingsverktyg) garanterar åtkomst till enhetens API
utan hinder
Inget säkert för alla API:er (applikationsprogrammeringsgränssnitt)
för enheten (Freberg, 2012).
Kostnad – innebär driftkostnaderna vid utveckling av appen. Kund vill förstås betala så lite som möjligt men ändå ha en fungerande app som uppfyller de krav som ställts och tid är pengar. Kortare utvecklingstider innebär också lägre kostnad.
Kod: Användbarhet – innebär om koden kan användas på en plattform eller flera.
UI Konsekvent – innebär hur väl det grafiska gränssnittet fungerar på den utvecklade appen.
Som till exempel i tabellen ovan ses det att cross-plattform ramverken har begränsat med gränssnitt komponenter som resulterar i mindre valmöjligheter gällande gränssnittet.
Prestanda – innebär om prestandan är bra eller dålig för den utvecklade appen.
Enhets Åtkomst – innebär ifall ramverket har tillträde till SDK:er eller inte.
14 2.5.1 Säkerheten inom appar
Informationssäkerhet är ett mycket viktigt område gällande appar som hanterar känslig information. Syftet med denna uppsats är inte att fokusera på säkerheten i appar men belyser några viktiga skillnader i säkerhetshantering mellan native respektive cross-
plattform-appar. Generellt gäller att cross-plattform-appar har brister gällande hantering av informationssäkerheten jämfört med utveckling via native-app (Day1Tech, 2019).
Stora mängder med viktig information (kund data, finansiella data, affärs data, privat data med mera) skickas mellan appar (Lin och Lee, 2015), därför ställs höga krav på
säkerhetshanteringen av informationen som skickas mellan apparna.
En native-app har tillgång till enhetens hårdvara och dess säkerhetshantering (Lin och Lee, 2015).
Enligt ett inlägg på ”Day1Tech” (2019) beskrivs att uppdateringarna tillsammans med tillgången av enhetens säkerhetshantering gör att dessa appars säkerhetsfunktionalitet är relativt säkra. Native appar har även möjligheten att bygga ”lager på lager” av
säkerhetshantering, vilket också bidrar till säkrare informationssäkerhet i dessa appar.
Cross-plattform kan inte dra nytta av den inbyggda säkerhetsfunktionen som en native-app kan för att den inte har tillgång till enhetens hårdvara eller säkerhet.
En cross-plattform-app använder mer avancerade ramverk och verktyg vilket har medfört att dessa appar kommer därmed inte upp i samma nivå av säkerhetshantering som i en native-app (Lin och Lee, 2015).
Cross-plattformar, som ofta inkluderar en tredje part, utgör dessutom ytterligare en risk i säkerhetshanteringen. I situationer där flera plattformar är sammankopplade så ökar också komplexiteten i att säkerställa säkerheten av appen (Day1Tech, 2019).
Med anledning av ovanstående konstateras att cross-plattform appar utgör fler säkerhetsrisker än vad native appar gör (Lin och Lee, 2015).
2.6 Flutter och Dart
Tidigt i uppsatsen framgick det att Flutter är ett cross-plattform ramverk och lanserades i maj 2017 (Harsh et al. 2019) vilket är fortfarande ungt och de levererar ständigt nya uppdateringar. Enligt Harsh et al. (2019) ökar användare av Flutter alltmer. Flutter ägs och har skapats av Google, där deras vision är att utvecklare kan skapa appar som fungerar på mobila enheter och surfplattor med mera. Flutter kan även utveckla webbsidor (Flutter, u.å.). Programmeringsspråket Dart Native (förkortat till Dart) används vid mobila appar, servrar med mera och för webben är programmeringsspråket Dart Web. Både Dart och Dart Web är också framtaget av Google. Detta illustreras bäst med inspiration från Flutters egna modell:
15 Figur 1. Illustration över Dart Native och Dart Web
Källa: Modifierad av Flutter (u.å.)
Flutter är gratis att använda och har öppen källkod, det används idag av utvecklare och organisationer i hela världen (Flutter, u.å.). Flutter är dock mest inriktad mot företag men som privatperson är det fullt möjligt att koda själv och skapa appar eller webbsidor (Flutter, u.å.c). Google och Google Ads använder Flutter idag men för att nämna några andra som numera också använder Flutter är Alibaba.com, Abbey Road Studios och The New York Times (mobil och webb) (Flutter, u.å). En utav de kanske mest kända företagen idag är eBay som även de använder Flutter (Flutter, u.å). Det är en stor variation mellan företagen där till och med banker förlitar sig på Flutter, exempelvis Nubank som är stationerad i Brasilien. En bit över en miljon utvecklare använder redan Flutter för utveckling av appar (Google, 2019).
Dart har blivit rankad om etta för snabbast växande språk och Flutter som tvåa för öppet källkodprojekt under 2019. Flutter är numera en utav de 10 mest så kallade “stjärnmärkta”
programvaru-repos på GitHub enligt företaget GitHub (2019). Programvaru-repo, eller bara förkortat till repo, är där utvecklare kan förvara sin kod samtidigt kan andra utvecklare ta del utav koden, det vill säga ett offentligt förvar för öppet källkodsprojekt.
Enligt en analys gjord av LinkedIn beskriver de Flutter som “the fastest-growing skill among software engineers” (Petrone, 2019). Flutter levererar som tidigare nämnts ständiga uppdateringar och har ofta diskussioner om nästkommande versioner.
Dart
Dart är programmeringsspråk som skapats av Google bland annat för att de ville ha ett
16 enklare språk vid frontend- och server-kod (Byö, u.å.). Där det vanligaste
programmeringsspråket är då JavaScript, men Dart kan kompilera till JavaScript eftersom det är semantiskt med varandra enligt Byö (u.å.). När en app ska utvecklas är det då viktigt att programmeringsspråket ska vara både produktivt och enkelt vilket Byö (u.å.) anser att egenskaperna finns i Dart.
Flutter har inspirerats av Reacts JavaScripts-bibliotek för att bygga användargränssnitt (Flutter, u.å.), och har utvecklat helt unika komponenter för gränssnittet. Detta gör att alla gränssnittskomponenter (meny, rutor, fält med mera) är en slags ”typ” av widget där de huvudsakligen antingen är en Stateless Widget eller Stateful Widget, se nedan i figur 2.
Flutters widgets ger utvecklaren kontroll över systemet (Flutter, u.å.c). Enligt Flutter själva är det bland annat dessa widgets som gör Flutter unikt (Flutter, u.å.c).
Stateless Widget
En Stateless widget är oföränderlig, vilket menas att en Stateless widget inte kan ändra sin
“status” under tiden appen körs (Biswas, 2019). Det Biswas (2019) menar på är att widgeten inte ritas om på nytt samtidigt som appen används. Biswas (2019) beskriver att om så önskas ändå måste en ny Stateless widget byggas.
Exempel på Stateless widgets kan vara text, meny, ikoner eller bilder.
Stateful Widget
Stateful widget kan, motsatsen till Stateless, ritas om flera gånger under tiden appen körs.
Den är föränderlig (Biswas, 2019). Kodmässigt sett som skiljer dessa två widgets åt är den
“build”-metod som anropas i widgeten. Build-metod är den metoden som ritar upp
gränssnittet (Flutter, u.å.b). I Stateless kan build-metoden endast anropas en gång medan i Stateful så kan den anropas flera gånger.
Exempel på Stateful widgets kan vara checkboxar, radio-knappar eller textfält.
Figur 2. Illustration över widgets i Flutter Källa: författaren
Enligt Flutter (u.å.) är detta arbetssätt en utav Flutters stora framgångar. De menar på att det sparar tid vid utveckling av appen samtidigt som appen ska prestera bättre än andra cross-plattforms ramverk.
17 Flutter (u.å.) använder sig också av Hot Reload som underlättar apputvecklingen.
Funktionen Hot Reload är ett hjälpmedel som används av utvecklaren för att exempelvis rätta till buggar (fel i koden) (Flutter, u.å). Hot Reload är även ett hjälpmedel till att i realtid se sina ändringar och uppdateringar i simulatorn.
2.7 Tidigare studier och forskningar
Detta avsnitt presenterar tidigare forskning och studier om ämnet Flutter samt problemområden inom cross-plattform.
Studier
I en tidigare studie utförd av Duvanå och Svensson (2019) inriktar de sig på ett specifikt ramverks användbarhet inom cross-plattform ramverk. Deras uppsatssyfte var att jämföra prestandan mellan Xamarin, Xamarin.Forms och Flutter ramverken och om det är tekniskt möjligt för ett företag med deras specifika applikationer att byta ramverk från exempelvis Xamarin till Flutter. Studien avslutas med en slutsats som rekommenderar att använda eller alternativt byta till Flutter vid mobilapplikationsutveckling (Duvanå och Svensson, 2019).
Deras rekommendationer baseras bland annat på egna upptäckter vid testning av
ramverken. Slutsatsen från deras studie stärker ytterligare varför denna kandidatuppsats om fördjupning av Flutter behövs och är nödvändig eftersom det finns fler aspekter att titta närmare på än endast prestandan.
En studie på mastersnivå utförd av Wu (2019) är ”React Native vs Flutter, cross-platform mobile application frameworks” där han beskriver att de två största konkurrenterna inom cross-plattform är just React Native och Flutter. Wu (2019) har även han använt båda ramverken för att testa skillnaden på att utveckla en enkel app i respektive ramverk. Först skapade han en app i React Native för att sedan återskapa appen i Flutter. Uppsatsen avslutas med att Wu (2019, s 25) beskriver, enligt hans eget tycke, att Flutter har en ljus framtid.
Forskning
Harsh et al. (2019) beskriver att native-utveckling har sina fördelar men det är ändå att föredra apputveckling i cross-plattform ramverk trots att cross-plattform är fortfarande ungt. Harsh et al. (2019) menar att cross-plattform har knappt funnits på marknaden i ett decennium. Nya ramverk inom cross-plattform som Flutter fortsätter att utveckla hela konceptet inom cross-plattform (Harsh et al. 2019). De nämner att Flutter är långt före andra ramverk med att ligga i tiden för cross-plattformutveckling.
Ermakov är Android-utvecklare och Horbenko är marknadsundersökare, tillsammans skriver de ett blogginlägg där de jämför olika cross-plattform ramverk (Ermakov och Horbenko, u.å.). Ramverken som jämförs i undersökningen är Xamarin, React Native och Flutter.
Ermakov och Horbenko (u.å.) skriver att de ramverken är de tre mest populäraste som utvecklare använder i skrivande stund. Egenskaperna som jämförs mellan ramverken är deras struktur, verktyg och vilken typ av applikationer som kan utvecklas (Erkmakov och Horbenko, u.å.). Under undersökningen framställdes problemområden inom cross-
18 plattform, som presenteras nedan i ”Problemområden” tillsammans med andra upptäckta problem.
Hartmann et al (2011) beskriver att utveckla appar i cross-plattform kan uppnås på flera sätt. Deras forskning fokuserar på ramverken med öppen källkod. De upptäcker under forskningens gång olika problemområden som komplexitet vid utvecklingen (Hartmann et al. 2011): ”The big disadvantage is complexity since cross-compilers can be difficult to write and need to be kept consistent with the fragmented mobile platforms and operating systems available”
.
Problemområden
Alla problemområden från de tidgare studierna från Duvanå och Svensson (2019) och Wu (2019) och forskning från Harsh et al. (2019), Ermakov och Horbenko, (u.å.) och Hartmann et al. (2011) har sammanfattats av författaren och listas nedan, där P är förkortning av
problemområde och siffran är numerisk. Tillsammans bildar de ett unikt ID som är spårbart genom hela uppsatsen:
P1. Hög utvecklingstakt, miljön ändras ständigt och utvecklarna måste regelbundet lära sig om de nya sätten att göra saker på.
P2. Bristande dokumentation, detta problemområde har samhörighet med föregående problem. Utvecklare får skriva sin egen dokumentation för specifika verktyg som de använder i nuvarande projekt.
P3. Användning av JSX (JSX = syntaxförlängning av JavaScript), vilket resulterar i att utvecklare blandar HTML med JavaScript. Utvecklare och designer klagar över JSX komplexitet.
P4. Blandad kod, detta problemområde har likheter med problemområde innan.
Kombinationen mellan olika programmeringsspråk är inte bara ”bråkigt” det resulterar även i stora filstorlekar och kan därmed skada applikationsprestanda.
P5. Fungerar mindre bra vid komplexa animationer.
P6. Tidskrävande, vissa komponenter måste utvecklas individuellt för varje plattform. Vilket leder till att utvecklingsprocessen blir tidskrävande.
P7. Saknaden av hjälpverktyget Hot Reload.
Varje problemområde kommer att fördjupas mer som kan ses i analysen i senare kapitel.
Tabellen nedan visar om problemområde (P1-P7) är befintlig i de tidigare ramverken inom cross-plattform. Där varje bockad (✓) ruta betyder att problemet finns och tom ruta betyder att problemet inte finns, eller är ett mindre problem, i det tillhörande ramverket.
19 Tabell 2. Tabell över problemområde i tidigare ramverk inom cross-plattform
ID ReactJS React Native Xamarin
P1 ✓ ✓
P2 ✓ ✓
P3 ✓ ✓
P4 ✓
P5 ✓
P6 ✓
P7 ✓ ✓
Som kan ses i tabellen ovan så har React Native ingen saknad av Hot Reload. I deras IDE kallas det för ett annat namn, Fast Refresh (Kuprenko, 2020). Detta är en annan variant av Hot Reload och är relativt nylanserad.
2.8 För- och nackdelar med Flutter
Här presenteras för- och nackdelar med Flutter har hämtats från erfarna apputvecklare. Här har utvecklarna erfarenhet och de har förståelse om vad som är viktigt och mindre viktigt vid apputveckling. Därför är denna metod av insamling av för- och nackdelar tillförlitlig.
2.8.1 Fördelar med Flutter
Google är ett stort företag som är känt över hela världen. Eftersom de är giganter inom IT- världen och (med fördel) har över 100 000 anställda (Statista 2020) har de alla möjligheter till att lyckas. Fler fördelar med Flutter är, sammanfattat av författaren, enligt Byö (u.å.), Ermakov och Horbenko (u.å.), Feoktistov (u.å.) och iteo (2019):
Kortare utvecklingstider, Hot Reload är till stor hjälp och gör det enkelt att arbeta eftersom Hot Reload inte bara är snabbt verktyg vid att lösa buggar utan ett enkelt sätt att arbeta med gränsnittet, lägga till funktioner med mera.
Applikationsprestanda, eftersom programmeringsspråket Dart är ett AOT (Ahead Over Time) språk, blir det möjligt för utvecklare att bygga komplexa appar utan att påverka prestandan eller starttider.
Komplett uppsättning av unika widgets. Allt i Flutter är uppbyggt på widgets. Detta innebär även återanvändning av kod, vilket sparar mycket tid för utvecklaren.
Flutter berör inte inbyggda plattformswidget, vilket innebär att om Google eller Apple lanserar en ny widget förstörs inte den redan byggda koden.
Flutter har egenskapen att anpassa allt som ses på skärmen oavsett hur komplext det kan vara. Detta innebär att Flutter gör utvecklingsprocessen flexibel utan att påverka arbetsbelastningen.
20
För att apparna som är utvecklade i Flutter ska klara belastningen som beskrivs ovan behövs ett stöd för detta, SKIA (2D grafikbibliotek).
Öppen källkod.
Som kan ses är fördelarna många och de flesta punkter är återkommande för de alla fyra skribenterna, men en punkt som är unik och som de alla fyra trycker extra mycket på är den återkommande egenskapen Hot Reload som kortar ner utvecklingsprocessen och sparar därmed tid.
2.8.2 Nackdelar med Flutter
Nackdelarna är inte lika många som det finns fördelar. Enligt Ermakov och Horbenko (u.å.) och iteo (2019) är nackdelarna:
Flutter är nytt och fortfarande ungt, vilket resulterar i osäkerhet om ramverkets framtid. Kommer det att lyckas eller blir det ett fiasko?
Vid skrivandets stund kan inte en Flutter-app bli mindre än 4MB eftersom ramverket använder sig av inbyggda widgets. Men detta är något som är under utveckling enligt iteo (u.å.).
Trots att programmeringsspråket Dart är enkelt att lära sig måste ändå utvecklaren lära sig ett nytt språk. Iteo (u.å.) menar att de första stegen då kan bli svårt för de som behöver hjälp och support.
Något som är Flutters största fördelar kan även vara en nackdel för andra. Ska en app utvecklas för plattformspecifika projekt är Flutter inte det bästa valet. Detta eftersom Flutter är utformat för att vara ett universellt ramverk.
Den största nackdelen enligt de två skribenterna är att Flutter fortfarande är ungt. Iteo (u.å.) nämner dock att det är ett spännande ramverk och anser att Flutter har en ljus framtid.
Rekommendationer om ramverket kan vara extra intressant för (iteo, u.å.): ”… startups, e- handel och alla teknikrelaterade företag som vill bygga 2D-app snabbare, effektivare och släppa den på alla tillgängliga plattformar samtidigt.” Översättning gjord av författaren.
2.9 Analysmodell
Analysmodellen ger läsaren en tydlig bild över den insamlade empiriska data som samlats in och vad som ligger i fokus (Fredriksson, 2019). Fredriksson (2019) menar på att analysmodell hjälper till att strukturera primära och sekundära empiriska data. Syftet med
analysmodellen i denna kandidatuppsats är att i nästkommande kapitel, analys, bryta ner varje beståndsdel (problemområde) mer detaljerat. Där kan författaren gå ner på djupet avseende varje problemområde i analysmodellen.
Sammanfattningsvis är analysmodellen är ett stöd för att analysera, det visar i bild om vad analyskapitlet handlar om (Fredriksson, 2019). Här belyser de problemområden som uppsatsen fördjupar sig i.
Analysmodellen har utformats av författaren och bygger på tidigare insamlade studier och forskning om ämnet. Den täcker problemområden inom cross-plattform för att kunna besvara UF1 samt syftet med kandidatuppsatsen. Det unika ID från avsnitt 2.7 är den
samma i analysmodellen, exempelvis P1 är den samma P1 i analysmodellen. (En modifiering av analysmodellen sker efter insamlad empiri från erfarna apputvecklare och student.)
21 Figur 3. Analysmodell över UF1 problemområden inom cross-plattform.
Källa: modifiering av Duvanå och Svensson (2019), Erkmakov och Horbenko (u.å.), Harsh et al. (2019), Hartmann et al. (2011) och Wu (2019).
22
3. Metod
I metodkapitlet redogör för vilken typ av studie och hur datainsamling har skett.
I denna studie har författaren valt en kvalitativ metod, detta eftersom kvalitativ metod innebär att forskaren beskriver sin tolkning av verkligheten, upptäcka nya problem och möjligheter etcetera.
Här beskrivs även hur insamlad empiri gått till och varför intervjuer valdes samt att dagbok användes av författaren vid egen utveckling av semesterplanerings-appen.
3.1 Kvalitativ forskning
Kvalitativ metod menas med att forskaren beskriver sin tolkning av verkligheten, att
forskarens bakgrund och kunskap blir ett viktigt verktyg i tolkningsprocessen enligt Fejes och Thornberg (2019).
Patel och Davidson (2019, s53) skriver “Kvalitativ forskning innebär att upptäcka nya problem och möjligheter samt att forskaren eftersträvar en djupare helhetsbeskrivning av en studerad situation, en företeelse eller fenomen” och denna kandidatuppsats syfte är just att på ett djupgående sätt studera Flutter. Uppsatsen har fördjupat sig inom området av cross-plattform där studieobjektet är att undersöka nya ramverket Flutter. Studieobjekt inom kvalitativ forskning kan innebära interaktioner, sociala system med mera. I denna kandidatuppsats är studieobjektet mer vad Patel och Davidson (2011, s150) kallar ”en människas upplevelser”. Kvalitativa studier lägger inte vikten på siffror som kvantitativa metoder, utan mer på ord och språk (Patel och Davidson, 2019). Patel och Davidson (2011, s150) beskriver att det textmaterial som arbetas med är ganska omfattande, exempelvis vid ett begränsat antal intervjuer ger stort textmaterial. Vilket resulterar i att kvalitativ
undersökning eller forskning är mer tids- och arbetskrävande.
Enligt Holme och Solvang (1997, s.92) kännetecknas den kvalitativa metoden av en närhet till studieobjektet. De menar på att forskaren ska kunna möta ansikte mot ansikte den situationen som objektet befinner sig i, att förstå problemet eller problemen som individer, grupper eller organisationer upplever. I denna uppsats blir studieobjektet Flutter och för att författaren ska komma så nära inpå som möjligt resulterar det i att författaren själv ska koda i ramverket Flutter. Det är syftet med kvalitativa tillvägagångssätt (Holme och Solvang, 1997 s.92). Att forskaren ska se det som studeras inifrån. På så sätt skapas en djupare förståelse och mer fullständig uppfattning om ämnet. Efter denna uppsats kommer inte bara
författaren utan även läsaren ha en grundlig förståelse om Flutter och även generella kunskaper om cross-plattform.
Fördelar med kvalitativ metod är att den visar den hela totalsituationen. Det resulterar i en ökad förståelse inom sociala processer och systemperspektivet, eftersom forskaren går in på djupet och arbetar nära sitt studieobjekt (Holme och Solvang, 1997 s.95). Metoden har även egenskapen att vara flexibelt. Forskaren kan bland annat själv utforma sina frågor och har möjlighet att kunna ändra, ta bort eller lägga till. Eftersom denna uppsats om Flutter som fortfarande är ungt passar den kvalitativa metoden bra. Det genererar en motivering till
23 varför intervjuer användes vid insamling av empiri, som kan läsas i avsnitt 1.6.3. Här kan författaren utforma frågor som passar respondenten och ställa utformade följdfrågor.
Författaren vill belysa att parallellt med studierna tillhörande denna kandidatuppsats råder en världsomfattande Corona-pandemi. Intervjuer genomfördes då på distans via Zoom. Två intervjuer spelades in så att författaren kunde utvärdera intervjuerna grundligt. Författaren anser inte att svaren blir berörda av pandemin.
3.2 Validitet och reliabilitet
Patel och Davidson (2019) förklarar validitet och reliabilitet genom ett exempel; att om man vill mäta intelligens så kan man inte mäta omkretsen runt ett huvud och avgöra om
personen är smart eller inte. De menar på att forskaren måste veta vad det är som
undersöks, validitet, och det måste vara tillförlitligt, reliabilitet. Reliabilitet menas med att det ges samma resultat vid olika tillfällen (Bell och Waters, 2016).
Att uppnå validitet i denna kandidatuppsats utförs genom att forskaren själv upptäcker, tolkar och beskriver uppfattningar om Flutter (Patel och Davidson, 2019). Flutter är fortfarande ungt och relativt nytt vilket gör det svårare att få tag i reliabilitetinformation.
Det finns ett få antal tidigare forskningslitteratur. De studier som författaren har hittat beskriver mest om att jämföra Flutter med andra cross-plattform ramverk samt att de har fördjupat sig mer i den kvantitativa metoden. De tidigare studierna har däremot gett inspiration till denna uppsats och anses vara tillförlitlig nog för att kunna dras nytta av.
Patel och Davidson (2019) anser att validitet och reliabilitet har ett visst förhållande till varandra och står varandra ganska nära. De menar att ifall det är låg reliabilitet är det också låg validitet, men inte ta för givet att hög reliabilitet innebär hög validitet.
Från analysmodellen som kan ses i kapitel 2, Teoretiska utgångspunkter och perspektiv, har format intervjuguiderna, se bilaga 2 och 3, som användes vid intervju av respondenterna.
Det reflekterar validitet i kandidatuppsatsen. Intervjuguiderna har olika innehåll beroende vilket perspektiv som intervjuats. Det reflekterar i reliabilitet i kandidatuppsatsen.
3.3 Intervju
Insamling av data sker via distansintervjuer med erfarna utvecklare av olika bakgrund för att kunna besvara ena delen av UF2 och den andra delen besvaras av en IT-student på Karlstads universitet.
Distansintervjuer ansågs vara bästa tillvägagångssättet eftersom det under studiens gång pågår Corona-pandemi och de flesta har satts i karantän. För att skapa såpass lik personlig intervju sker därför med hjälp av en videolänk via Zoom. Zoom är ett e-mötesverktyg där personer kan i realtid föra en konversation med bild och ljud. Det finns funktioner som gör det möjligt att spela in samtal, vilket användes i denna uppsats. Alla inspelade samtal raderas direkt när uppsatsen har blivit godkänd.
24 Vid intervjuer via Zoom ställs frågor om respondenternas uppfattning om Flutter samt att det bland annat ska framgå vad de arbetar med, hur länge de har integrerat med Flutter och cross-plattform.
Att intervjua valdes för att kunna ha möjligheten att gå in på djupet om ämnet. Vid intervjuerna kunde även följdfrågor ställas för att intervjuaren ska få större förståelse om något känns oklart. Som beskrivet ovan behöver författaren vara nära ämnet. Det var anledning till att intervjuer valdes istället för enkäter som är en annan typ av
tillvägagångssätt vid insamling av data. Intervjuer är personliga och författaren får en syn inifrån ämnet eftersom följdfrågor kan ställas. Med enkäter däremot kan inte författaren ställa följdfrågor och svaren blir mer kortfattade.
För intervjuerna skapades en intervjuguide för erfarna apputvecklare (bilaga 2) och en intervjuguide för nybörjare (bilaga 3).
3.4 Urval av respondenter
En IT-student från Karlstads universitet som blir intervjuad representerar
nybörjarperspektivet och arbetstitel ”utvecklare” representerar erfarenperspektivet.
Arbetstitel som senior eller juniorutvecklare är också intressant för att få olika synvinklar om Flutter från olika perspektiv. En juniorutvecklare och en seniorutvecklare delar kanske inte samma uppfattning, däremot spelar det ingen roll om kön eller ålder. Det enda som är intressant är från vilken arbetes- eller studiebakgrund de intervjuade respondenterna kommer ifrån. Det blir även intressant om erfaren utvecklare och nybörjare delar samma uppfattning om Flutter.
Tabellen nedan visar vilken titel respondenten har, hur länge respondenten har utvecklat i Flutter, när intervjun skedde och längd.
Författaren vill förtydliga om att det var svårt att få tag i respondenter som hade tid att ställa upp eftersom Corona-pandemin påverkar alla, även i IT-branschen.
Tabell 3. Beskrivning av respondenterna Titel Arbetserfarenhet
(år) Utvecklat i Flutter (år &
mån)
Datum Längd på
intervju (minuter) Seniorutvecklare
(fullstack- utvecklare)
20, varav 3 år med
apputveckling 2 år 2020-04-14 47
IT-Student (Karlstad universitet)
2 1 mån 2020-05-06 42
Juniorutvecklare 1,5 4 mån 2020-05-27 mejlintervju
Mejlintervju valdes för juniorutvecklaren eftersom denna respondent är döv, därför valdes en skriftlig konversation där intervjufrågorna delades upp i omgångar för att sedan
sammanställas i ett samlat dokument av författaren. Följdfrågor som skapades skrevs
25 omgående till respondenten via mejl. Strukturen med uppdelning av intervjufrågorna valdes med hjälp av kommunikation med handledare och kursansvarig. Detta för att svaren blir mer utförliga om inte för många frågor ställs samtidigt.
3.5 Etiska överväganden
Målet med forskningsarbete inom projektarbete vid utbildningssyfte är att den kunskap som tas fram är så trovärdig som möjligt att den blir viktig för individer och utvecklingen för samhället (Patel och Davidson, 2019). Det har ingen betydelse om storleken på
projektarbetet eller forskningen som utförs. Forskaren bör alltid ta hänsyn till de
forskningsetiska aspekterna. Det finns fyra övergripande etikregler som Vetenskapsrådet (2002) har formulerat, och som även Patel och Davidson (2019, s.84) nämner i deras bok, Forskningsmetodikens grunder. Dessa fyra etikregler sammanfattas:
Informationskrav - innebär att forskaren ska informera alla respondenter om vad forskningens syfte är, vad som förväntas av dom och att de när som helst kan välja att avbryta.
Samtyckeskrav - innebär att de som deltar i forskningen har rätt att själv bestämma om han/hon vill delta eller inte.
Konfidentialitetskrav - innebär att känsliga uppgifter som kan skada eller identifiera respondenterna ska behandlas på ett konfidentiellt sätt, så att ingen utomstående kan ta del av dem.
Nyttjandekrav - innebär att insamlade uppgifter om enskilda personer ska endast användas till forskningsändamål.
De respondenter som deltar i denna kandidatuppsats har alla fått skriva på
samtyckesblankett, se bilaga 1, och varje enskild intervju följer GDPRs riktlinjer för hantering av personuppgifter. Karlstad universitet är med och ansvarar för att behandling av
personuppgifter följs korrekt (Karlstads universitet, 2019). Alla respondenter är anonyma, med endast tillhörande arbetstitel beskriver deltagaren.
Innan intervjuerna fick respondenterna också en sammanfattning om kandidatuppsatsens syfte och eventuella frågor som kom att ställas.
3.6 Dataanalys
Olsson och Sörensen (2011, s.131) nämner att i deras bok ”Forskningsprocessen: kvalitativa och kvantitativa perspektiv” att det är mer eller mindre ett måste att forskaren ska arbeta med nedskriven text när det gäller kvalitativ bearbetning av data. De menar på att all data som samlas in ska alltid transkriberas oavsett vilken metod om hur data samlades in (personberättelser eller inspelade intervjuer). Deras metod om transkribering användes i denna kandidatuppsats, trots att intervjuerna är inspelade skrevs det ändå ner noteringar under tiden intervjun pågick samt att hela intervjun renskrevs direkt efteråt. Alla
respondenter blev erbjudna att ta del av den renskriva versionen för att göra en avstämning om att svaren är densamma som sades.
26 Patel och Davidson (2019, s.151) rekommenderar även att föra dagbok och noteringar löpande under hela studiens gång. Dagboken eller andra noteringar är ett bra sätt för
forskaren att skriva ner sina egna tankar om vissa problem som uppstått (Patel och Davidson 2019, s.151). Genom denna metod blir det enkelt för forskaren att ”gå tillbaka” för att kunna se hur forskarens kunskap om ämnet har utvecklats.
Författaren av denna kandidatuppsats följer rekommendationerna från Olsson och Sörensen (2011) samt Patel och Davidson (2019). Det vill säga att dagbok och ständiga noteringar görs för att det kan snabbt dyka upp många tankegångar runt problemområdet. Det är då viktigt att dokumentera alla de tankar och frågor som dykt upp för att senare användas i analysen.
Patel och Davidson (2011, s152) beskriver också att bearbeta sin textmatreal genom att läsa det många gånger och bearbeta sina noteringar med fysiska papper och penna, samt skapa kopior för att inte utesluta någon viktig notis som lätt kan raderas bort om de görs på originalet.
27
4. Resultat
Här presenteras den insamlade empirin från gjorda intervjuer.
Resultatkapitlet är uppdelat i avsnitt motsvarande varje problemområde som hittats under kapitel 2. Strukturen i detta kapitel är upplagd i en viss ordning, i syfte att underlätta för läsaren att identifiera spårbarhet.
Strukturen är upplagd enligt följande:
Tabell som innehåller citat från respondenterna ”Seniorutvecklaren”, ”IT-studenten” samt
”Juniorutvecklaren”.
Fördjupningar och förtydningar av respektive svar är angivna under respektive tabell.
Avslutningsvis i detta kapitel presenteras resultaten av den egenutvecklade semesterplanerings-appen som beskrivs i kapitel 1, Introduktion.
4.1 P1 Utvecklingstakt och P2 Dokumentation
Hög utvecklingstakt innebär att utvecklingsmiljön (IDE) ändras frekvent som resulterar i att utvecklarna måste ständigt lära sig om de nya ändringarna.
Bristande dokumentation, detta problemområde har samhörighet med problemområdet innan ”hög utvecklingstakt”. Utvecklare skriver sin egen dokumentation för specifika verktyg som de använder i nuvarande projekt.
Tabell 4. Insamlad empiri om problemområde P1-P2
ID Seniorutvecklaren IT-studenten Juniorutvecklaren
P1.
Utvecklingstakt ”Utvecklingsmiljön är ingen begränsning, att de uppdateringar som görs löser snarare än skapar problem.”
”Flutter kommer ofta med uppdateringar som går fort att installera och använder man IDE som Visual Studio Code säger de ofta till när det finns en ny uppdatering och länkar till
uppdateringen. Har inte upplevt problem hittills.”
”Flutter uppdateras väldigt frekvent, de har fyra olika kanaler.
På mitt arbete kör vi med stable channel och då vill vi självklart ha stabila grejer.
Med Flutter kan även köras på Visual Studio Code, Android Studio och IntelliJ vilket är fantastiskt. Lätt att köra i simulatorn också.”
P2.
Dokumentation ”Det finns mycket information och den är välskriven. Kod-
dokumentationen är extremt bra.”
”Den bästa
dokumentationen jag har läst faktiskt. Bra val av Flutter att använda olika typer av dokumentation. Gillar när det är skriftligt
”I början fick jag höra att Flutter hur dåligt dokumenterat Flutter skulle vara, vilket visade sig vara helt fel.
Deras officiella
dokumentation är bra,
28 men hade nog inte
förstått den skriftliga dokumentationen utan Youtube.”
sedan finns det massa med videos (även från Google själva) på YouTube och dessa videos har
undertexter så att även döva kan ta del av dem.”
Att Flutter har hög utvecklingstakt och ofta uppdaterad dokumentation är ingen nackdel, anser seniorutvecklaren. Seniorutvecklaren nämner också att Flutter är Googles stora satsning inom apputveckling och cross-plattform. Trots den höga utvecklingen hänger ändå Flutter med när det gäller bland annat dokumentation beskriver seniorutvecklaren.
Flutter använder olika ”informationskanaler” och den skriftliga dokumentationen är enkel att ta del av, anser IT-studenten. Flutter använder metoder som skriftligt, i ord och bild eller livekodning. IT-studenten beskriver att utvecklaren kan enkelt välja den metod som passar utvecklarens egen inlärningsmetod bäst.
Utvecklare vill ofta skapa egna forum i sociala medier, vilket innebär möjligheter att föra diskussioner om Flutter av utvecklare med olika bakgrund, berättar seniorutvecklaren.
Dessa forum ger också möjligheter för utvecklarna till att få hjälp med kodproblem eller liknande.
Från nybörjarperspektivet anses dokumentationen vara lätt att läsa och förstå innehållet, detta anser både IT-studenten och juniorutvecklaren. Juniorutvecklaren är inte heller sen med att nämna Flutters informationskanal på YouTube som ett alternativ. Trots att
respondenten är döv, utnyttjas dessa videofilmer eftersom filmerna innehåller undertexter.
Med anledning av att Flutter satsar på olika typer av kanaler för dokumentationen så anses detta positivt av IT-studenten. IT-studenten betonar även att alla utvecklare har olika inlärningsmetoder. Att flera utvecklare tar på sig rollen att skapa forum där Flutter kan diskuteras anses ha bara positiv verkan enligt juniorutvecklaren. Juniorutvecklaren nämner även att Flutter uppdateras frekvent men upplever inget negativt med dessa frekventa uppdateringar.
Seniorutvecklaren anser sig sakna mer tillgängliga och testade exempelkod, samt att dessa borde finnas till alla plattformar. Vid implementation av en färdigutvecklad app till exempel anser seniorutvecklaren sakna exempelkod om hur de ska tillväga. IT-studenten instämmer och anser att det är största problemet som upplevts med Flutter. Att komma runt
problemet (med brist på exempelkod) så anser IT-studenten att kommunikation med andra utvecklare i någon utav forumen är bästa metoden, vilket även juniorutvecklaren instämmer med.
29 Sammanfattning av den insamlade empirin gällande utvecklingstakt och dokumentation:
Hög utvecklingstakt är inget hinder då dokumentationen uppdateras samtidigt och är tydlig samt instruerande
Uppdateringar löser faktiskt problem snarare än att skapa nya problem
IDE föraviserar i god tid alla uppdateringar samtidigt sker installationen mycket snabbt
Flutter satsar på olika informationskanaler gällande dokumentationen, vilket syftar till att alla ska kunna ta del av dessa
4.2 P3 Blandning av olika programmeringsspråk och P4 Filstorlek av utvecklad app Användningen av JSX resulterar i att utvecklare blandar programmeringsspråk, HTML med JavaScript. Det skapar klagomål om komplexiteten från både designer och utvecklare.
Blandning av olika programmeringsspråk resulterar även i stora filstorlekar vid färdigutvecklade appar.
Tabell 5. Insamlad empiri om problemområde P3-P4
ID Seniorutvecklaren IT-studenten Juniorutvecklaren
P3.
Blandad kod (JSX)
”Problemområde finns inte i Dart.”
”Har ingen erfarenhet av JSX, men skönt att det inte är blandning av olika
programmeringsspråk och Dart var lätt att lära sig. ”
”Dart är ett enda programmeringsspråk som Flutter använder sig av och det hela handlar mest om att det är widgets i widgets i widgets. Allt i Flutter är widets, på så sätt blir det ganska rakt på sak.”
P4.
Kodblandning som
resulterar i stora filstorlekar
”I Flutter genereras det mer prestanda eftersom koden kompileras ner till maskinkod direkt, vilket inte exempelvis Xamarin gör. Tekniskt sett är Flutter mer
’rapp’ och har i botten Skia som Chrome använder.”
”Har inte tänkt på filstorleken, det är generellt något jag aldrig gör vid
programmering […], men med tanke på hur mycket utrymme spel tar så tror jag inte folk bryr sig särskilt mycket så länge de har
användning av appen.”
”Flutter-appar har generellt större filstorlek än normalt, det är dock inget som stört mig ännu.”
30 Den gemensamma koden för både grafiska gränssnittet och logiken är något Flutter har unikt anser seniorutvecklaren. Seniorutvecklaren menar att vid implementation innebär detta en enkelhet som medför en snabb och smidig utveckling, samt mindre förvirring. IT- studenten upprepar seniorutvecklarens svar (utan att känna till varandra) och tillägger att det är lättare att ha koll på bara ett programmeringsspråk.
Apputvecklaren behöver därmed lära sig endast ett språk istället för att kombinera två eller flera språk samtidigt, instämmer juniorutvecklaren. Seniorutvecklaren beskriver
svårigheterna och därmed risk för komplexitet vid användning av flera
programmeringsspråk, men påpekar att programmeringsspråket Dart löser problemet eftersom det används till både den grafiska delen och logiska delen. IT-studenten och seniorutvecklaren anser att Dart är en genialisk lösning.
Juniorutvecklaren berättar att Dart ett programmeringsspråk som är lätt att lära sig.
Juniorutvecklaren har förkunskaper inom andra programmeringsspråk såsom Java,
JavaScript och C#. Vilket underlättar eftersom Dart som en blandning mellan dessa språk.
Seniorutvecklaren nämner inte mycket om filstorleken av appen, men menar på att appar utvecklade i Flutter har bättre prestanda än jämförelselik med Xamarin. Seniorutvecklaren anser att appar utvecklade med Flutter har högre prestanda och menar på att koden som körs kompileras direkt ner till maskinkod. Juniorutvecklaren nämner att filstorleken av en färdigutvecklad app i Flutter är generellt större än normalt, men inget som påverkat negativt.
Juniorutvecklaren beskriver också att slutanvändaren troligtvis inte känner sig manad att ladda ner en app i stor storlek och anser att Flutter borde utveckla denna punkt mer.
IT-studenten har ingen tidigare erfarenhet gällande utveckla appar inom cross-plattform, så kan inte uttala sig om filstorlekens betydelse.
Sammanfattning av den insamlade empirin gällande blandad kod och filstorlekens roll:
Flutter använder enbart ett programmeringsspråk, Dart, vilket undviker blandad kod
Eftersom Dart är det enda programmeringsspråket och kompileras direkt till maskinkod så ökar detta prestandan på appen
Filstorlek på en utvecklad app i Flutter är generellt större än andra appar som är utvecklade i cross-plattform ramverk, men anses inte ha någon negativ påverkan
Det rekommenderas dock att Flutter ser över detta i framtiden
31
4.3 P5 Animationer
Andra cross-plattform ramverk fungerar mindre bra vid komplexa animationer.
Tabell 6. Insamlad empiri om problemområde P5
ID Seniorutvecklaren IT-studenten Juniorutvecklaren
P5.
Animationer ”Animationer fungerar hur bra som helst. Det är kraftfullt och lätt.”
”Jag gillar animationer i Flutter, dock har jag inte hunnit testa på så mycket än men än sålänge kan jag säga att det är låg
inlärningskurva. Det är lätt att lära sig och det finns väldigt bra tutorials på YouTube.
Jag har inte upplevt något negativt än med de animationer jag har hunnit testa.”
”För att vara helt ärligt har jag inte kommit riktigt dit än. Eftersom på arbetet kräver inte den appen som vi utvecklar just nu några animationer, så
behovet har inte funnits, men på mitt fritidsprojekt har jag testat runt lite, till exempelt när en vy ska
’animeras iväg’ till en annan skärm och det var otroligt lätt att implementera.”
Seniorutvecklaren är den mest erfarna apputvecklaren utav samtliga respondenter och beskriver att animationer i Flutter är kraftfulla och lätta att hantera. Enligt seniorutvecklaren är det till exempel enkelt att hantera toning, storlek, lägga till klick etcetera. Även avancerad programmering förekommer, anser seniorutvecklaren, och förklarar att vid programmering av pixel för pixel och mer ”filmaktiga” animationer av figurer är exempel på animationer som kan bli svårare men inte omöjligt att utföra.
IT-studenten har mindre erfarenhet gällande animationer i Flutter, men har hunnit testa några funktioner av dem. IT-student anser de enkla animationer som testats har låg inlärningskurva och är bra beskrivna om hur de ska användas i koden. De funktioner som testas är de mest enkla som exempelvis ikoner i form av hjärtan. Enligt IT-studenten har inte animationerna sänkt prestandan på något sätt.
Juniorutvecklaren har inte nått dit ännu. Projektet juniorutvecklaren arbetar med idag är inte behov av större avancerade animationer. Däremot har juniorutvecklaren liksom från IT- studenten testat Flutter på fritiden. Där har juniorutvecklaren testat funktionen toning och ansåg att denna funktion är enkel att använda. Juniorutvecklaren har tidigare erfarenheter inom animation i Android native och anser sig vara duktig. Juniorutvecklaren nämner att Flutter har bra filmklipp i deras kanal på YouTube och kan föreställa sig att animationerna är lätta att hantera, även de mer avancerade.
