Teknik och samhälle
Datavetenskap
Examensarbete
15 högskolepoäng, grundnivå
Utvecklarens perspektiv på native- och
hybridapplikationer
Developer’s perspective on native- and hybrid
applications
Haris Durakovic
James Lay
Examen: Kandidatexamen 180 hp Huvudområde: Datavetenskap Program: Applikationsutveckling Datum för Slutseminarium: 2017-05-31Handledare: Farid Naisan Examinator: Johan Holmgren
Sammanfattning
Studien handlar om att undersöka native- och hybrid-applikationer från utvecklarens perspektiv. Vilka viktiga skillnader finns det mellan applikationstyperna, och hur resonerar utvecklarna kring dessa två? Dessa två applikationstyper har fördelar och nackdelar som måste övervägas innan utvecklingen börjar, beroende på applikationens uppgifter. Studien upplyser och ger läsaren kunskap om de två applikationstyperna och viktiga aspekter som skiljer dem åt.
Vi har utfört nio intervjuer med applikationsutvecklare från fem olika företag. Dessa respondenter är Androidutvecklare som har olika roller inom respektive företag. Dessa roller är konsult, utvecklare, chef, arkitekt och user experience lead. Med deras hjälp har vi kommit fram till en slutsats där native-applikationer föredras av utvecklare på grund av att slutprodukten blir bättre jämfört med hybrid-applikationer. Utöver att slutprodukten är bättre, är det även lättare att utveckla en native-applikation samtidigt som det finns större kunskap inom detta område.
Nyckelord: Mobilapplikation, Native, Hybrid, Utvecklare, Android, Utveckling
Abstract
This study takes a closer look on native- and hybrid applications from a developer’s perspective. Which important differences are there between these two application types and how do the developers reason between the two? These two application types have advantages and disadvantages that must be considered before the development starts, depending on the application’s tasks. The study enlightens and gives the reader knowledge about the two application types and important aspects that separates them.
We have conducted nine interviews with application developers from five different companies. These respondents are Android developers that have different roles within the respective company. The roles are consultant, developer, superior, architect and user experience lead. With their help, we have come to the conclusion that native applications are preferred by developers because of the final product being better compared to hybrid applications. Other than just the final product being better, it is also easier to develop a native application as well as there is more knowledge within this area.
Keywords: Mobile application, Native, Hybrid, Developer, Android, Development
Innehållsförteckning
1. Inledning ... 1 1.1 Bakgrund ... 1 1.2 Tidigare forskning... 2 1.3 Syfte ... 4 1.4 Forskningsfråga... 4 1.5 Målgrupp ... 4 1.6 Avgränsning ... 4 2 Teori ... 5 2.1 Android ... 5 2.2 Native ... 52.2.1 Fördelar med native ... 5
2.2.2 Nackdelar med native ... 6
2.3 Hybrid ... 6
2.3.1 Fördelar med hybrid ... 7
2.3.2 Nackdelar med hybrid ... 7
2.4 Webbteknologier ... 7 3 Metod ... 9 3.1 Metodbeskrivning ... 9 3.2 Metoddiskussion ... 10 3.3 Informationssamling ... 10 3.3.1 Kvalitativ undersökning ... 10 3.3.2 Urval ... 11 3.3.3 Intervjugenomförande ... 11 3.3.4 Respondenterna ... 11 3.4 Teoretisk insamling ... 13 3.5 Forskningsetik... 14
3.6.1 Källkritik ... 16 4 Resultat ... 17 4.1 Respondent A ... 17 4.2 Respondent B ... 18 4.3 Respondent C ... 20 4.4 Respondent D, E, F ... 22 4.5 Respondent G ... 23 4.6 Respondent H ... 24 4.7 Respondent I ... 26 4.8 Sammanfattning av resultatet ... 27 5 Analys ... 28
5.1 Kriterier och resonemang som övervägs av utvecklarna ... 28
5.2 Aspekter som skiljer sig mellan native och hybrid ... 29
5.3 Utvecklingsmiljöer ... 29
6 Diskussion ... 30
6.1 Kriterier och resonemang som övervägs av utvecklarna ... 30
6.2 Aspekter som skiljer sig mellan native och hybrid ... 31
6.3 Utvecklingsmiljöer ... 32
7 Slutsats och fortsatt forskning... 33
Referenslista ... 34
Bilaga ... 37
Ordlista
Native-applikation: I resten av studien benämns native-applikation som native. En
native-applikation är en applikationstyp för mobila enheter.
Hybrid-applikation: I resten av studien benämns hybrid-applikation som hybrid. En
hybrid-applikation är en applikationstyp för mobila enheter.
Applikation för smartphone: I resten av studien benämns en applikation för
smartphone som applikation.
User experience lead: En person inom programvaruföretag som arbetar med
användarupplevelsen.
SDK: Software Development Kit är en uppsättning utvecklingsverktyg som gör det
möjligt för en utvecklare att bygga en applikation mot en specifik plattform.
IDE: Integrated Development Environment är en mjukvara med grundläggande
verktyg som en utvecklare behöver för att skriva och testa en mjukvara.
Native container: I studien benämns container även som behållare. En native
container kan ses som en tunn behållare som ger åtkomst till native plattformens funktioner.
Offline storage: En term för att beskriva ett lagringsmedium vars data inte kan
kommas åt när den är bortkopplad från en dator. Exempelvis ett USB-minne.
Integrated multimedia: Ett koncept för att kontrollera alla nöjesenheter genom ett
system. Exempelvis att kunna lagra all video och audio i en dator och spela filerna på en enhet.
CSS: Cascading Style Sheets är ett språk som ordnar presentationen på en hemsida,
tillexempel typsnitt och bakgrundsfärg på en hemsida.
Gradient: En webbteknik inom CSS som visar en jämn övergång mellan två eller flera
specifika färger.
Transition: En webbteknik inom CSS som animerar en övergång över en given tid.
Exempelvis att klicka på menyn på en hemsida för att dölja eller visa.
Peer-reviewed: Ett begrepp som innebär att texten har blivit granskad av en
tredjepart som anses vara tillförlitlig.
App store: En online marknadsplats där en användare av mobila enheter kan söka
efter, köpa och ladda ner applikationer för sin smartphone.
API: Application program interface är en lista kommandon som visar hur program
Stand-alone applikation: En applikation som måste installeras på en användares
system. Applikationen behöver inte tillgång till internet för att köras och behöver inte interagera med andra applikationer.
Corner case: är ett problem som endast uppstår i systemet när olika faktorer
inträffar samtidigt.
Profiling: är en form av programanalys för att mäta och stödja programoptimering. Debugging: är en process för att hitta och lösa defekter som förhindrar att program
1
1. Inledning
Inledningen kommer att presentera bakgrund om applikationer. Tidigare forskning om applikationer av typerna native och hybrid kommer också att tas upp. Syfte, forskningsfrågor och målgrupp kommer att redogöras i slutet av avsnittet.
1.1 Bakgrund
Vid användning av applikationer på smartphone-enheter används normalt antingen native eller hybrid. Vanligtvis är applikationer skapade som native. Fördelen med native är att de kan dra nytta utav all tillgänglig funktionalitet som plattformen erbjuder. En native kan dessutom använda sig utav all mjukvara och hårdvara som ingår i enheten [2]. En mobilplattform är ett operativsystem som är skapad för mobila enheter, exempelvis smartphones och surfplattor. Dessa operativsystem liknar de traditionella operativsystem men kan ses som en förenkling som erbjuder en begränsad funktionalitet, som att hantera trådlösa nätverk och multimedia. Den begränsade funktionaliteten hos dessa mobila enheter beror på hårdvaran som de har [2].
Hybrid är HTML5/JavaScript applikationer som ges en native-behållare för att kunna köra applikationen som en stand-alone applikation [2, 4]. Hybrid-applikationer kombinerar native med webbutveckling [1, 9]. Som resultat av detta behöver applikationen inte köras i en webbläsare som en hemsida. Anledningen till att dessa applikationer kallas för hybrid är för att de är en kombination av native och webbteknologi [2]. Till skillnad från native kan en och samma hybrid köras på olika plattformar med hjälp av webbteknologier som HTML5, CSS och JavaScript [6].
Mobila enheter som smartphones är personliga verktyg som hjälper människor i deras vardagsliv [8]. Mobila enheter står för ungefär 34% av alla enheter som används på webben. För ungefär två år sedan låg antalet endast på 15%, vilket visar hur snabbt den mobila marknaden växer [9]. En ökning i användning och fortsatt utveckling av dessa smartphones leder till att allt fler applikationer utvecklas och används [8]. Enligt Google finns det mer än 1,4 miljarder enheter som består av Android som är aktiverade [7] och mer än 43 procent av alla smartphones är Android (iOS 51.4 procent) [9]. En användare kan komma åt dessa applikationer när som helst och var som helst [8].
2
De tre största plattformarna som finns idag är iOS, Android och Windows Mobile, där varje plattform har olika ursprung. Samtliga nämnda plattformar använder sig av olika programmeringsspråk. Skillnad på programmeringsspråk innebär att de applikationer som är designade för en specifik plattform, inte kan användas på andra plattformar [2].
Innan utvecklingen av en applikation börjar, måste utvecklarna ta beslutet gällande vilket plattform som applikationen är avsedd för [2]. Enligt IBM [1] finns det olika kriterier som gör att organisationer eller utvecklare väljer att utveckla olika typer av applikationer. Författarna menar att beroende på vilken applikationen som skall utvecklas, så finns det både fördelar och nackdelar att överväga. Utvecklingsmiljöer för Android och hybrid finns tillgängliga på nätet och är gratis att ladda ner [23], [28]. Det finns många plattformar för att utveckla hybrid och dessa utvecklas ständigt för att underlätta för utvecklarna [29].
Hybrid tillför plattformsoberoende funktionaliteter med hjälp av native-kod och JavaScript. Det görs med hjälp av integrering mellan native-kod och JavaScriptkod. Native-kod kommer åt funktionerna på smartphones och JavaScript hjälper till med användarinteraktionen. Native är däremot plattformsberoende vilket innebär att utvecklarna måste utveckla en ny applikation varje gång de vill nå ut till en ny plattform. Native får tillgång till alla de inbyggda funktionerna som finns tillgängliga medan hybrid är begränsade [28].
1.2 Tidigare forskning
Botella, Escribano och Penalver [3] utförde en undersökning för att jämföra native och hybrid med hjälp av ett ramverk. Funktionalitet, användargränssnitt, versioner (testa hur många operativsystemversioner som ger stöd), utvecklingstid, återanvändning (återanvändning av kod och möjligheten att återanvända den teknik som tidigare utvecklats) och möjligheten att komma åt de inbyggda funktionerna var kriterierna som undersöktes. Undersökningen visade att native fick högst betyg i funktionaliteten, användargränssnittet, versioner och att komma åt de inbyggda funktionerna. Däremot ansåg forskarna att hybrid var bättre eftersom det tog mindre tid att utveckla och återanvändning av kod var möjlig. Trots att native fick
3
högst betyg i flest kriterier, visar undersökningen att hybrid fick högre betyg i genomsnitt.
Enligt Dehlinger och Dixon [5] finns det fyra utmaningar med applikationsutveckling. Dessa är ett universellt användargränssnitt, mjukvara som går att återanvändas på olika operativsystem, att designa kontextmedvetna applikationer och att balansera rörlighet och osäkerhet i kraven. I undersökningen som utfördes av Botella, Escribano och Penalver [3] visade det sig att hybrid var bättre utformad för att hantera dessa utmaningar. Stora företag som IBM och Adobe förespråkar och investerar i hybrid [4]. Trots att hybrid hanterar dessa utmaningar bättre än native, uppstår det andra svårigheter menar Lee, Dolby och Ryu [28]: “While hybrid apps
simplify development efforts, they introduce additional difficulties at the same time.” [28, s.250]
Enligt Lim [6] har hybrid fördelen att inte behöva utveckla samma applikation flera gånger för olika plattformar. Det leder till att kostnaden blir mindre i form av tid och pengar. En nackdel med hybrid är att prestandan inte är lika bra som hos en native och det finns begränsningar på åtkomsten till funktionerna som smartphones har [6]. Lim [6] påstår däremot att prestandan för hybrid kommer att förbättras i framtiden med hjälp av mer avancerade webbteknologier. I en studie som utfördes av Lee, Dolby och Ryu [28], uppstod det problem på grund av att hybrid utvecklas med olika språk. Informationsläckage och buggar upptäcktes i hybrid, och problemen uppstod på grund av integrationen mellan Java och JavaScript.
Native har däremot fördelen att ge en bättre prestanda eftersom det går att nyttja plattformens SDK och resurser [6]. Native går även att användas offline [9]. Nackdelen som kommer med en native är att utvecklarna måste ha enhetens olika hårdvaror och dess begränsningar i åtanke när de utvecklar applikationen [2].
När applikationen är färdigutvecklad, är det vanligt att utvecklarna återskapar applikationen för en annan plattform. Det innebär i några fall att utvecklarna måste lära sig funktionerna den andra plattformen har och programmeringsspråket som kommer med det. Detta medför att utvecklarna går igenom en process där två applikationer utvecklas, testas och underhålls separat. Processen för att utveckla en applikation är kostsam i tid och pengar [2].
4
1.3 Syfte
Denna studie har i avsikt att undersöka skillnader mellan native och hybrid i Android ur en utvecklares perspektiv. Syftet är att finna kunskap om hur utvecklarna resonerar gällande de två olika applikationstyperna och förstå varför utvecklare väljer en applikationstyp över en annan.
1.4 Forskningsfråga
FF1: Vilka är de kriterier och resonemang som övervägs av utvecklare vid val av native eller hybrid som applikationstyp?
FF2: Finns det några viktiga aspekter som skiljer sig mellan native och hybrid ur utvecklarnas perspektiv?
FF3: Vilka synpunkter har utvecklarna om de utvecklingsmiljöer som är tillgängliga vid utveckling av de två applikationstyperna?
1.5 Målgrupp
Studien riktar sig främst till personer som har intresse inom detta fält. Dessa kan vara industrifolk eller forskare som arbetar med utveckling av applikationer. Studien riktar sig också mot personer som har ett intresse för applikationsutveckling och företag som använder applikationer. Småföretag som har mindre kunskaper kan också ha nytta av studien.
1.6 Avgränsning
I denna studie har valet om att avgränsa arbetet till enbart Android som plattform gjorts för att få ett bättre djup och fokuseringspunkt i arbetet. Det arbetas endast utifrån utvecklarens perspektiv. Studien inriktar sig därför endast mot native och hybrid inom Android från utvecklarens perspektiv. Vi väljer att endast fokusera på Android då vi har kunskap inom plattformen. Vi förstår hur Android fungerar och i undersökningen kan vi bidra med relevant information, och data som samlas in kommer att behandlas med hjälp av vår kunskap. Så är inte fallet med iOS eller Windows och därför har vi begränsat oss till Android.
5
2 Teori
I detta avsnitt presenteras de två olika applikationstyperna på ett mer djupgående sätt.
2.1 Android
Android använder Java som sitt programmeringsspråk och applikationerna körs på den virtuella maskinen som kallas för Dalvik. När ett Androidprogram körs så kompileras det till en Dalvik fil som kallas för dex fil. När dex filen kompileras består den av flera Javaklasser, en XML fil och resursfiler som paketeras tillsammans och utgör ett applikationspaket vars förkortning är APK (Android Package Kit) [16].
2.2 Native
Native laddas ner och installeras från plattformens officiella app store som Google Play och har plattformsspecifik funktionalitet, utseende och känsla [20]. API:et i native tillåter direkt tillgång till enhetens inbyggda funktioner vilket underlättar för utvecklarna när de vill utnyttja dessa funktioner vid programmering. Applikationer som inte är native har svårare att komma åt de inbyggda funktionerna [17]. Enligt Corral, Sillitti och Succi [21] kan native utnyttja högsta möjliga prestanda då de är kompilerade och kan exekveras direkt på enheten. Trots att utvecklarna kan använda sig av olika webbteknologier eller ramverk för att skapa en applikation som passar de olika plattformarna, finns det fortfarande en efterfrågan för native som är riktad mot en specifik plattform [19].
2.2.1 Fördelar med native
Enligt James [17] är fördelen med native att de är byggda enligt specifikationer som erbjuds av tillverkarna från operativsystemen. Tillverkarna erbjuder bibliotek som består av kod som är tillgänglig för alla utvecklare och dessa bibliotek leder till att applikationerna upprätthåller en standard. Andra fördelar är att applikationen är snabbare, går att starta upp snabbare och förbrukar mindre data. Det går också att använda applikationen utan att ha tillgång till internet. Med hjälp av ett API kan native få tillgång till information och tjänster på smartphones som inte ingår i applikationen, som kontakter, foton och dylikt. Lee, Dolby och Ryu [28] anser att fördelen med att utveckla i native är att det finns mycket dokumentation och verktygen är välutvecklade.
6
2.2.2 Nackdelar med native
Fan och Wong [19] förklarar behovet av att stödja flera plattformar som ett stort problem för applikationsutvecklare. Inkompatibilitet uppstår när en del funktioner som endast finns tillgängliga för ett specifikt operativsystem, inte finns tillgängliga på andra operativsystem. Inkompatibilitet kan uppstå på grund av skillnader på hårdvara, skärmstorlek och upplösning. Skillnaderna har då en stor påverkan på användargränssnittet. Enligt Corral, Sillitti och Succi [21] har utvecklarna en svår uppgift med underhåll och att stödja både de senaste och alla tidigare versioner som finns installerade på användarnas enheter.
2.3 Hybrid
Hybrid är webbaserade och är inpackade i native-behållare. Detta resulterar i att de blir plattformsoberoende. Verktygen för utveckling av dessa typer av applikationer förbättras ständigt [17]. Utvecklarna använder än idag de webbteknologier som är standard för att utveckla hybrid. Samma webbteknologier används för att utveckla webbapplikationer. Skillnaden är att hybrid har möjligheten att använda specifika API:er som är tillhandhållna av utvecklarplattformen för att få tillgång till den underliggande hårdvaran och mjukvarukomponenter [20].
Facebook är ett utvecklingsdrivet företag och vill uppdatera sina applikationer snabbt. Facebook valde därför att utveckla första applikationen i hybrid då hybrid är lättare att uppdatera samtidigt som de är flexiblare än native. Applikationen var långsam, hade buggar och kunde krascha [17]. Anledningen till att problemen uppstod är fortfarande obesvarade, dock spekuleras det om att hybrid kan vara sämre men även att applikationen kunde ha varit dåligt programmerad. Det beslutades att göra applikationen mer native för att buggarna skulle försvinna och för att den skulle sluta krascha. Det innebär att Facebook-applikationen består mer av native än vad det består av webbtekniker. Applikationen är fortfarande hybrid för att hämta innehåll enklare från webben, och för att kunna uppdatera applikationen utan att det skall uppstå problem [17].
7
2.3.1 Fördelar med hybrid
James [17] skriver att hybrid är flexiblare än native på grund av att de är lättare att uppdatera. Hybrid är också lättare att få ut till allmänheten jämfört med andra typer av applikationer. Vid utveckling av hybrid behöver inte utvecklare tillstånd från Google Store för att uppdatera applikationen. När det gäller native behövs godkännande för att kunna göra ändringar. Eftersom hybrid är plattformsoberoende behöver utvecklarna inte koda till olika plattformar, vilket leder till att utvecklingstiden blir mindre.
2.3.2 Nackdelar med hybrid
Corral, Sillitti och Succi [21] ser på begränsningar som att komma åt enhetens hårdvarufunktioner, svårigheter att integrera applikationen med native-komponenter och variationer i användarupplevelser som nackdelar med hybrid. Även en sämre prestanda anses vara en nackdel trots att det inte finns någon tillgänglig studie som i detalj förklarar anledningen till varför prestandan är sämre.
Enligt Lee, Dolby och Ryu [28] är dokumentationen för hybrid inte lika bra som den är för native. Den specificerar inte interaktionen mellan JavaScript och Java. Detta leder till sårbarheter inom utveckling av hybrid i form av programmeringsfel. Hybrid har inte utvecklingsverktyg som IDE vilket Android har. Det leder till att utvecklarna måste göra omfattande testning av applikationen. Detta gäller även vid underhåll av en hybrid. Testerna leder till att det blir väldigt kostsamt i tid och pengar. Eftersom hybrid vanligtvis inte avslutas när det uppstår buggar i antingen Java eller JavaScript, utan visar endast felmeddelanden, blir det svårt för utvecklarna att veta var problemet ligger.
2.4 Webbteknologier
Eftersom hybrid utvecklas med hjälp av native och webbutveckling så kommer detta avsnitt att beskriva några av de olika tekniker som finns inom webbteknologier. Tekniker som används för att utveckla webbapplikationer är HTML, CSS och JavaScript.
Den senaste HTML5 utvecklingsstandarden är modellerad på ett sätt där ett stort fokus har lagts på smartphoneutveckling. Tjänster som offline storage, integrated
8
multimedia och tillgång till enhetens hårdvara är nya element som kan användas på de olika plattformarna för smartphones. För tillfället finns det en handfull mobila webbläsare som har ett bra stöd för HTML5 [18]. Med hjälp av JavaScriptbibliotek visar plattformen ett specifikt utseende och funktionalitet genom att få tillgång till de inbyggda systemen. Tillgången till de inbyggda systemen är dock begränsade [20].
JavaScript spelar en stor roll när det kommer till applikationens beteende och funktionalitet [18]. JavaScript finns för att ansvara för logiken medan HTML har ansvaret att förse webbsidan med innehåll [31]. Med hjälp av CSS kan utvecklaren bestämma över hur presentationen av innehållet ska se ut, som exempelvis färger och form. Den pågående utvecklingen av CSS-standarden har bland annat gjort det möjligt att skapa gradients, runda kanter och transitions [18]. CSS, HTML och JavaScript integrerar alla med varandra fast de är separerade.
9
3 Metod
I detta avsnitt kommer utgångspunkter och utförande av metoder att redovisas. Resonemang kring vilka metoder som har valts kommer att tas upp och motivering av besluten kommer att diskuteras. Genom att läsa detta avsnitt kan läsaren bilda en uppfattning och ta ställning till resultatet som presenteras.
3.1 Metodbeskrivning
Eftersom syftet med undersökningen är att undersöka en utvecklares perspektiv vid val av applikationstyp måste det väljas en metod som är passande. Metoden som används i denna studie är en kvalitativ undersökning i form av semistrukturerade intervjuer som är öppna eftersom målet är att ha en djupgående undersökning. Med frågeställningarna syftar studien till att få fram utvecklarnas resonemang gällande vilken applikation som är bättre att utveckla och vilken applikationstyp de föredrar. Enligt Bryman [10] är kvalitativ undersökning baserat på ord och tolkningar och det är data som skall samlas in. Då kvalitativ undersökning är baserad på ord och tolkningar, behöver studien utföras med ett tolkande perspektiv. Detta görs enklare om ett interpretativistisk synsätt används. Tidigare forskning i ämnet mellan native och hybrid har utförts kvantitativt. Denna studie skiljer sig från tidigare studier eftersom den är utförd kvalitativt och ger därför ett annat perspektiv.
Bryman och Bell [25] skriver om ett begrepp vid namn epistemologi som behandlar vad som anses vara acceptabel kunskap inom ett ämne. Inom epistemologi urskiljs två olika förhållningssätt, det vill säga positivism och interpretivism. Oates [26] beskriver interpretativismen som ett förhållningssätt som används för att studera helheten och för att ge en mer subjektiv världsuppfattning. Oates [26] menar även att den interpretativistiska forskaren inte behöver bevisa eller motbevisa en hypotes. Forskaren ska istället försöka att identifiera, hitta och förklara hur olika faktorer är sammankopplade till en viss miljö. Det är inte ovanligt att interpretativism också benämns som tolkningsperspektivet. Bryman [27] beskriver tolkningsperspektivet som ett synsätt inom kunskapsteorin vars uppfattning grundar sig på både tolkning och förståelse. Vad gäller positivismen, skriver Bryman [30] att det ligger till grund för den naturvetenskapliga metoden och att användningsområdet för det är främst vid experiment.
10
3.2 Metoddiskussion
Bryman [32] skriver att den kvalitativa undersökningen skiljer sig från den kvantitativa undersökningen. Kvantitativa undersökningar vill få fram några former av siffror genom exempelvis statistik, för att informationen ska bli generaliserande. Bryman [32] skriver också att i en kvantitativ undersökning styr forskaren eftersom det är forskarens frågor som strukturerar hela undersökningen. Det skiljer sig från den kvalitativa undersökningen där det är deltagarens perspektiv som är i fokus. Utgångspunkten är vad de uppfattar som viktigt och betydelsefullt. Bryman [33] menar att med en kvalitativ undersökning strävar forskaren efter en förståelse av beteenden, värderingar och åsikter av kontexten som undersökningen genomförs i.
I vår studie är vi inte ute efter någon form av generaliserande information eller siffror, utan en djupare förståelse för utvecklarens perspektiv gällande native och hybrid. De data som ligger till grund för resultatet innehåller inte några siffror och därför är en kvantitativ undersökning inte passande för studien. På grund av datas natur och studiens ändamål är en kvalitativ undersökning därför bättre lämpad.
3.3 Informationssamling
Datamaterial som forskaren själv införskaffar genom en eller flera utvalda metoder för att få svar på en frågeställning kallas för primärdata. Primärdata kan samlas in genom en rad olika metoder: intervjuer, frågeformulär och observationer är exempel på några av dessa metoder. Data som samlas in är skräddarsydd och meningen är att den ska passa en specifik problemformulering eller frågeställning som forskaren vill få svar på [24].
3.3.1 Kvalitativ undersökning
I denna studie utförs det en kvalitativ undersökning i form av semistrukturerade intervjuer för att samla in all data som behövs. Vid kvalitativa undersökningar är deltagarnas utsagor i fokus. Deras perspektiv av vad de uppfattar som viktigt blir undersökningens utgångspunkt. Forskaren vill i en kvalitativ undersökning försöka förstå och uppfatta världen på samma sätt som deltagarna gör. Den kvalitativa undersökningen strävar efter att förstå värderingar och åsikter. Genom kvalitativa intervjuer kan det skapas en bättre förståelse av det som undersöks [11].
11
För att utföra den kvalitativa undersökningen har valet att använda en semistrukturerad intervju gjorts. Frågor som berör de ämnen som är av intressant karaktär för studien kommer att ställas till deltagarna. Frågorna behöver inte ställas i en bestämd ordning. Istället ska frågorna kunna ställas när det är passande och med hjälp av följdfrågor skapas det en djupare förståelse för svaren som deltagaren ger. Det kan hända att följdfrågor i intervjuer inte ger lika värdefulla data om de inte ställs till alla. Följdfrågor i denna studie syftar till att leda respondenten tillbaka till frågan som ställs om respondenten går utanför ramarna och inte svarar på den ställda frågan. Med hjälp av denna typ av intervju finns det en möjlighet att fördjupa svaren samtidigt som det finns möjlighet att gå in i en dialog med respondenten [12].
3.3.2 Urval
Vid kvalitativa undersökningar rekommenderar Bryman [13] att ett målinriktat urval används. Det innebär att de personer som är relevanta för undersökningen väljs ut som respondenter. I denna studie väljs det ut aktiva utvecklare som arbetar på företag som utvecklar applikationer med inriktning på Android.
3.3.3 Intervjugenomförande
I studien har samtliga intervjuer förutom en utförts genom direktkontakt. Intervjun som inte utfördes genom direktkontakt, utfördes via telefon. Om respondenterna uttryckt att de vill ha frågorna några dagar i förväg, har de fått det eftersom vi inte har tänkt utföra en intervju som kan upplevas eller tyckas vara besvärlig för respondenten. Respondenterna informerades om att intervjuerna kommer att spelas in. De fick bestämma om de ville samtycka till det. I de flesta fall har intervjuerna spelats in. Vid de intervjuer där respondenten givit ett nej gällande tillåtelsen att spela in har anteckningar förts istället.
3.3.4 Respondenterna
Respondenterna som har deltagit i intervjuerna presenteras i Tabell 1 nedan. Tabellen visar respektive respondent, roll i företaget, företag och typ av kontakt.
12
Respondent Roll i företaget Företag Typ av kontakt
A Utvecklare A Intervju, spelades in
B Utvecklare, Arkitekt A Intervju, spelades in
C Konsult A Intervju, spelades in
D Arkitekt B Intervju, spelades in
E User experience lead B Intervju, förde anteckningar
F Chef B Intervju, förde anteckningar
G Utvecklare C Intervju, förde anteckningar
H VD, Utvecklare D Intervju, spelades in
I Konsult E Telefonintervju, spelades in
Tabell 1: Respondenter
Företag A är ett programvaruföretag med specialister inom digital innovation. De
fokuserar på utveckling för smartphones, webben och på molnet. Respondent A är en utvecklare som har arbetat med Androidutveckling sedan 2009. Respondent B med sex till sju års erfarenhet inom Android anser sig själv vara utvecklare och arkitekt med 15 år av generell applikationsutveckling. Respondent C är en Androidkonsult med sju till åtta års erfarenhet inom Android.
Företag B är ett IT-företag som verkar globalt och är innovatörer inom
videoövervakning. Företagets produkter finns installerade på offentliga platser.
Respondent D är en arkitekt med ungefär sju års erfarenhet av Android. Respondent E är user experience lead med fyra års erfarenhet av Android. Respondent F är chef för mobila applikationer men är för tillfället inte en aktiv
utvecklare men har fem–sex års erfarenhet av Android.
13
Företag C är ett innovativt IT-konsultbolag med 20 års erfarenhet inom IT och
kommunikationsteknik. Respondent G är en applikationsutvecklare som har arbetat med Android sedan 2009.
Företag D är ett team med bred kompetens inom mobilindustrin och arbetar med
allt möjligt inom detta område, från koncept och användarupplevelse till att säkra en stabil miljö för slutprodukten. Respondent H är både VD för företaget och en av företagets utvecklare med flera års erfarenhet av applikationsutveckling.
För företag E finns det ingen kort presentation, utav respekt för respondenten som vill hålla sitt företag anonymt.
3.4 Teoretisk insamling
Jacobsen [34] skriver att den information som en forskare använder sig av och som redan har samlats in och blivit presenterad av en annan forskare, är en sekundärkälla. Denna typ av information kallar Jacobsen [34] för den teoretiska insamlingen men även för sekundärdata. Den teoretiska insamlingen som samlas in kommer oftast från andra studier med ändamål som inte är lika men som andra forskare finner intressant att dela med sig av.
I denna studie har relevant litteratur som berör ämnet sökts upp och litteratur som handlar om native och hybrid har hittats och använts. De vetenskapliga artiklar och böcker som ansågs vara relevanta för uppsatsen har hittats med hjälp av sökmotorerna Libsearch, Google Scholar, och databaskatalogerna ACM och IEEE. Alla artiklar som har använts har blivit publicerade och anses därför vara peer-reviewed. Följande nyckelord användes: hybrid native android, hybrid application, native application, comparison, framework, development, mobile, issues, android, native, hybrid, survey, app, store, history, apps, analyzing, introduction, developer, web, applications, developing environment, html5 och javascript. Dessa nyckelord har använts i olika kombinationer tillsammans med citattecken och plustecken för att hitta de artiklar som har använts. Den teoretiska insamlingen har givit förkunskaper om ämnet som studien handlar om, vilket gör att undersökning kan utföras på ett så förberett sätt som möjligt. Med dessa förkunskaper underlättas förståelsen av det som respondenterna har delat med sig av vid utföranden av intervjuerna.
14
3.5 Forskningsetik
Vid intervjuer finns det enligt Kvale [14] fyra osäkerhetsområden som kan användas som ett ramverk för forskningsetik. Dessa fyra områden är enligt följande:
• “Informerat samtycke” vilket innebär att personerna som intervjuas är medvetna om vad syftet för undersökningen är.
• “Konfidentialitet” som handlar om informationstillgänglighet, vilka personer som kan ta del av vilken information.
• “Konsekvenser” som handlar om konsekvenserna som en kvalitativ forskning har. Personerna som intervjuas ska inte behöva lida på något sätt.
• “Forskarens roll” handlar om att det som publiceras av forskaren ska vara så korrekt och så representativt som möjligt.
I denna studie har hänsyn tagits till samtliga nämnda områdena genom att vidta olika åtgärder. Vad gäller området “informerat samtycke” har studiens syfte förklarats på ett tydligt sätt för de involverade.
När det kommer till området “konfidentialitet” informeras det för de involverade att all material och information som samlas in, endast kommer att användas för denna studie, men även att studien kommer att bli tillgänglig på internet för att andra ska kunna ta del av den.
För området “konsekvenser” har valet om att hålla de involverade respondenterna anonyma gjorts eftersom deras namn inte är relevanta samtidigt som det minskar möjligheten att de eventuellt kan bli lidande. Istället refereras de olika respondenterna till A, B, C, D, E, F, G, H och I. Vad gäller de olika företagen, hålls även deras namn anonyma för att minska möjligheten att på något sätt skada dem. Istället för namn finns det korta presentationer om respektive respondent och företag. Motivering till de korta presentationerna är att läsaren ska kunna bilda en uppfattning om vilken typ av respondenter som har varit involverade i studien.
Vad gäller det sista området, “forskarens roll”, har hänsyn tagits genom att upprepade gånger läsa igenom informationen som har samlats in. Motiveringen för detta beslut är att få ett så korrekt och representativ material som möjligt samtidigt som risken för feltolkningar av information minskas.
15
3.6 Validitet & Reliabilitet
Jacobsen [15] ser på validitet som giltighet och relevans. Jacobsen [15] menar att det som forskarna ska mäta faktiskt är det som är avsett att mätas, samtidigt som mätningen är relevant och har en koppling till ämnet. Datainsamlingen som gjorts i studien kan ses som relevant. Endast personer som har en koppling till ämnet eller som kan ge svar på frågeställningar har intervjuats. Av denna anledning kan validiteten i studien anses vara god.
Enligt Jacobsen [15] kan reliabilitet definieras som tillförlitlighet och trovärdighet. Jacobsen [15] menar att det som undersöks ska gå att lita på och det som mäts ska utföras på ett tillförlitligt sätt. För att få ett resultat från en undersökning som ska kunna anses vara tillförlitlig, ska själva utförandet ske på ett korrekt sätt. Det ska inte väckas några frågor eller osäkerheter kring trovärdigheten från exempelvis intervjun. Enligt Bryman [10] handlar reliabilitet om att resultatet från en undersökning ska vara samma för alla som utför undersökningen, förutsatt att undersökningen har skett på ett likadant sätt.
För att hålla en hög kvalité på studien som utförts, var det viktigt att utföra den på ett tillförlitligt sätt. För att säkerställa tillförlitligheten, gjorde vi en noggrann planering och handplockning av respondenter. Detta gjordes genom att först välja ut företag som arbetar med applikationsutveckling, för att inte gå utanför ämnet. Vad gäller information och resultat från intervjuerna, kan de anses vara tillförlitliga eftersom de antingen spelades in eller så fördes det noggranna anteckningar. På så sätt kunde svaren gås igenom upprepande gånger samtidigt som information inte gick förlorad. Ifall den insamlade informationen varit oklar, har respondenten i efterhand kontaktats för att klargöra det. Undersökningen skulle vara så korrekt och så representativt som möjligt. Utöver detta har försök om att vara så tydliga som möjligt gjorts vad gäller beskrivning av hur studien har utförts, om någon skulle vilja upprepa det som har utförts. Även om beskrivningen har varit utförlig, kan det vid en kvalitativ undersökning, framförallt en undersökning likt vår, vara svårt för andra personer att få exakt likadana resultat som denna studie har samlat in. Jämförs detta med en kvantitativ metod där det finns mätbara mått, är det betydligt lättare att uppnå reliabilitet. Samma mätningar och beräkningar kan utföras för att replikera resultaten.
16
3.6.1 Källkritik
Vi har i stora delar av vår studie samlat in data från vetenskapliga artiklar och böcker som varit från 2000-talet. Detta är för att vi vill ha relevant och aktuell information. Vi anser att reliabiliteten i böckerna och artiklarna varit stor eftersom dessa har granskats noggrant av en tredje part. Vi har haft i åtanke att hitta och använda artiklar som har blivit peer-reviewed, för att vi ska kunna säkerställa dess reliabilitet.
17
4 Resultat
I avsnittet nedan presenteras all empiri. Data som har samlats in från de utförda intervjuerna med respondenterna utgör resultatet som sammanställs. Avsnittet ligger även till grund för analysdelen som kommer i nästa avsnitt. Motivering till strukturen av resultatdelen är att det ger läsaren en möjlighet att gå in på djupet gällande hur varje respondent har svarat. Vid ett sammanslaget resultat får läsaren endast en generell bild över vad respondenterna tycker. Kort sammanfattning kommer att presenteras i slutet av resultatet. En större sammanfattning kommer att presenteras under rubriken Analys och jämföras med tidigare forskning och teori.
4.1 Respondent A
Respondent A är en utvecklare som arbetat med utveckling i Android sedan 2009.
4.1.1 Vilka är de kriterier som avgör vilken applikationstyp du väljer
att utveckla och hur resonerar du?
Respondenten berättar att det är kostnaden eller applikationens användningsområde som avgör varför den ena applikationstypen väljs istället för den andra. Av egna erfarenheter rekommenderar respondenten inte en hybrid lösning. Anledningen är att det aldrig har blivit någon tidsvinst genom detta val. I slutändan har det kostat mer tid och krävt specialiserade utvecklare med kunskaper inom native-plattformar och tredje form av plattform eller ramverk. För utveckling inom native behövs det endast utvecklare som kan en enda plattform. Resonemanget till varför en hybrid-lösning används är för att det är billigare, eftersom det endast krävs att applikationen byggs en gång och att kostnaden i tid blir mindre. I praktiken har respondenten inte upplevt att det blivit så. Tvärtom, att det har kostat mer i form av tid och pengar. Generellt får applikationen inte krascha, måste se bra ut och får inte vara långsam. Respondenten föredrar native på grund av det sista kriteriet, hybridlösningar är långsammare, vilket beror på att det har blandats in webbteknologier i applikationerna.
18
4.1.2 Vilka är de viktiga aspekterna som skiljer sig mellan native och
hybrid?
Kunskapsområden skiljer sig ganska mycket. En hybrid-lösning innebär att mycket kunskap inom webbutveckling behövs och mindre inom native-utveckling. Respondenten menar att Hybrid ställer högre krav eftersom mer kunskap behövs. Stort behov på bra hybrid-utvecklare finns. Behovet leder det till att det uppstår mer problem med underhåll av hybrid och mindre med native, eftersom det är ett smalare område. Respondenten påpekar även att kvalitén på kodbasen är mycket viktigt oavsett applikationstyp, för att i framtiden underlätta förståelsen och därmed underhåll för andra utvecklare.
“Hellre att det är lätt att förstå än att man har gjort något klyftigt som kräver mer förståelse när någon annan tittar på det”.
4.1.3 Vad är dina synpunkter om utvecklingsmiljöerna för de olika
applikationstyperna?
För att kunna skriva en hybrid måste utvecklaren ha förståelse för de olika plattformarna som Android och iOS. Om utvecklaren inte förstår plattformarna så går det inte att skriva en vettig applikation. Utöver detta krävs det även förståelse för ett tredje eller fjärde verktyg eller ramverk som applikation byggs för. En del av verktygen för hybrid ger inte tillräcklig noggrann kontroll över plattformen, för att kunna göra allt som verktygen för native kan säger respondenten. Detta kan leda till att hybrid blir sämre, men det beror även på vad applikationen ska utföra. Ska applikation utföra något grafiskt tungt eller visa kartor, kan det snabbt bli problem att göra det i hybrid. Respondenten fortsätter med att berätta att verktygen för hybrid är helt enkelt inte bra nog idag, eftersom utvecklaren måste förstå plattformarna under.
4.2 Respondent B
Respondent B är en utvecklare och arkitekt med 15 år av generell utveckling av
19
4.2.1 Vilka är de kriterier som avgör vilken applikationstyp du väljer
att utveckla och hur resonerar du?
Det viktigaste kriteriet är kunskap. Utvecklaren anser att kunskapen inom native är större än vad det är inom hybrid. Respondenten vill ha en bra upplevelse på sin applikation och att det ska finnas kunskaper för att utveckla applikationen. Då är det ett jättestort kriterium att hitta människor som vet hur applikationen ska utvecklas, för att skapa en så bra upplevelse som möjligt för användaren.
“Ett viktigt kriterium är då att det finns folk som både är grymma mobila utvecklare, som tänker mobil, vet hur man gör det och som kan språket för plattformen som man ska jobba i”
Respondenten menar att detta är ett kriterium som uppfylls på native eftersom det finns många bra native-utvecklare. Däremot är fallet inte samma på hybrid-plattformen.
4.2.2 Vilka är de viktiga aspekterna som skiljer sig mellan native och
hybrid?
Respondenten säger att det är prestandan som skiljer sig men att hybrid är utvecklad för att utföra enklare uppgifter jämfört med native, som utvecklas för att utföra uppgifter som kräver mer prestanda.
“Du fixar nånting, det dyker upp igen, och igen, och igen och det kan ta oerhört mycket tid. Till den graden att du vinner ingenting på det”
Respondenten menar att utvecklaren framförallt får ägna oerhört mycket tid på att rätta till buggar som finns i de olika webbvyerna som telefontillverkare har. Till den grad att det inte görs någon tidsvinst. Respondenten säger även att hybrid inte har tillgång till enhetens många funktioner som native har.
En annan viktig aspekt som respondenten tar upp, gäller underhåll av applikationer. Native är lättare eftersom det finns mer utvecklare med kunskap inom en miljö. Underhåll blir svårare inom hybrid där det saknas utvecklare med kunskap inom hybrid-miljön. Respondenten anser att kunskap är viktig, och att detta är något som bör tänkas på från första början. Det är viktigt att tänka på vilka andra människor
20
som kommer att delta och då måste det vara i en miljö där det går att hitta utvecklare med kunskaper i, vilket inte är ett problem inom native.
“Med native kan du undvika komplexitet och producera i snabb takt utan att få buggar.”
4.2.3 Vad är dina synpunkter om utvecklingsmiljöerna för de olika
applikationstyperna?
När det kommer till utvecklingsmiljön för hybrid, berättar respondenten att verktygen inte alls är närheten av att vara lika bra som verktygen för native. Respondenten går vidare och berättar att när det kommer till mer tekniska uppgifter, som prestandaproblem, minnesläckor, uppritning som är ineffektiv så finns det bra verktyg i de nativa utvecklingsmiljöerna för att hantera problemen. Dessa blir svårare att lösa med utvecklingsmiljöerna i hybrid eftersom det saknas funktioner och det är inte lika stabilt.
“Då får du nöja dig med det som finns där vilket är ganska rudimentärt”
Respondenten säger att när det kommer till slutanvändaren, blir problemet med hybrid att det oftast inte känns fullständigt, vissa saker som navigeringen är inte som den bör vara.
4.3 Respondent C
Respondent C är konsult med sju till åtta års erfarenhet inom Android.
4.3.1 Vilka är de kriterier som avgör vilken applikationstyp du väljer
att utveckla och hur resonerar du?
Prestandan är viktig där respondenten syftar på att animationerna blir mycket sämre på hybrid än native. Testningen är också viktig, då det blir mycket svårare att utföra i hybrid där utvecklaren syftar på att det blir många fler corner cases i integrationstesterna som måste hanteras. I slutändan handlar det om tid och pengar. En generell uppfattning är att hybrid-lösningar sparar tid men oftast är fallet inte så.
21
“Jag skriver en kodbas och så publicerar jag till tre stora plattformar och så sparar jag två tredjedelar av min utvecklingstid. Det är inte så enkelt. Man räknar inte in all den här testbarheten när man testar en hybrid-applikation.”
4.3.2 Vilka är de viktiga aspekterna som skiljer sig mellan native och
hybrid?
Det är UI som är direkt iögonfallande. Respondenten är tydlig med att det inte är fult på hybrid och inte fult på native. Det är just skärningsytan mellan dessa två som användaren kommer att upptäcka först. Även animationer och liknande kommer att märkas. Känslan på hybrid kommer inte att kännas bra. Det blir inte som användaren hade förväntat sig. Utöver detta är native också lättare att utveckla eftersom fokuset endast ligger på en plattform. Det gör att underhåll också är enklare. För varje release du gör med native, måste du testa olika plattformar. Det är tidskrävande och i längden kostar det mer pengar. Inom hybrid har du någon JavaScriptmotor som exekverar JavaScript och som renderar din HTML. Det fungerar på ett sätt i en webbläsare eller webb-vy. Men olika telefoner har olika miljöer som JavaScript och HTML exekverar i, därför måste det finnas kod som tar hänsyn till dessa och som rättar till de specifika buggarna. Respondenten menar att underhåll av native är enklare men dyrare. Native blir en gynnsam investering i längden jämfört med hybrid.
“Native är en långsiktig vinst”
4.3.3 Vad är dina synpunkter om utvecklingsmiljöerna för de olika
applikationstyperna?
Respondenten säger att i början går det snabbt med hybrid eftersom det är lätt, men när utvecklarna efteråt börjar ändra lite så måste det testas på många olika plattformar. Det kommer då att behövas tester som utvecklarna inte tänkt på att testa tidigare. I början är utvecklingen lätt men i slutändan blir det jättesvårt och hela utvecklingsprocessen blir besvärlig, vilket till stor del beror på att utvecklingsmiljön är sämre. Vad gäller utvecklingsmiljön för native, säger respondenten att eftersom fokuset endast ligger på en plattform blir processen lättare men även att verktygen är bättre.
22
4.4 Respondent D, E, F
Respondent D är en arkitekt med ungefär sju års erfarenhet av Android. Respondent E är user experience lead med fyra års erfarenhet av Android. Respondent F är chef för mobila applikationer men är för tillfället inte en aktiv
utvecklare, men har fem till sex års erfarenhet av Android.
4.4.1 Vilka är de kriterier som avgör vilken applikationstyp du väljer
att utveckla och hur resonerar du?
Respondenterna nämner att många kriterier måste tas till hänsyn. Hur tung applikationen är, ska den utföra tunga beräkningar, tekniska svårigheter, hur mycket ska utvecklaren följa plattformens UI, look and feel ska kännas native. Dessa kriterier är viktiga för användarupplevelsen och de tekniska begränsningarna. I en hybrid kan du göra allt i JavaScript men det kan bli komplicerat. Det finns en teknisk begränsning i hybrid som gör att det finns en risk att komma in i en återvändsgränd. Med detta menar respondenterna att utvecklarna kan nå en punkt där de inte kan fortsätta vidareutveckla applikationen på grund av de tekniska begränsningarna.
4.4.2 Vilka är de viktiga aspekterna som skiljer sig mellan native och
hybrid?
Inom hybrid måste det byggas bryggor mellan native-lager och hybrid-lager, vilket görs genom att använda många olika bibliotek. Konsekvensen av detta är att applikationen blir väldigt stor och kan ta mycket plats på lagringsenheten. Med hybrid måste utvecklarna tänka på ramverken också. Det är viktigt att det finns en stabil aktör bakom ramverken som gör dem pålitliga, så att ramverken inte läggs ner under tiden applikationen fortfarande är i drift.
Respondenterna är också eniga om att underhåll av native är lättare. De säger att med hybrid skapar du ett beroende mot ramverken på grund av att det är en viktig del av hybrid. Dessa ramverk kan vara bra och stabila aktörer men kanske inte utvecklas i samma takt som applikation, vilket kan vara en stor nackdel för hybrid.
“Ju fler lager desto mer problem får du, större risk för problem”
23
4.4.3 Vad är dina synpunkter om utvecklingsmiljöerna för de olika
applikationstyperna?
Respondenterna är eniga om att utvecklingsmiljöerna för native är mycket bättre, en bidragande faktor till detta är att dessa utvecklingsmiljöer har mycket mer stöd än hybrida utvecklingsmiljöer. Med native får utvecklarna bra verktyg för hela utvecklingsprocessen, som att kunna arbeta med bakgrundshantering, komma åt alla API:er som finns i plattformarna och integrerade testverktyg. Respondenterna berättar att bra och enkla verktyg för hybrid saknas, utöver detta skapas det ett beroende till ramverk och utvecklare vill ha en stabil aktör bakom sin applikation. Stabila aktörer är något som inte alltid kan garanteras vid hybrid men på native finns det bra och stabila aktörer.
4.5 Respondent G
Respondent G är en applikationsutvecklare som har arbetat med Android sedan
2009.
4.5.1 Vilka är de kriterier som avgör vilken applikationstyp du väljer
att utveckla och hur resonerar du?
Respondenten säger att det beror på om applikationen är teknisk eller inte. Är applikationen teknisk är det bättre att välja native eftersom de tekniska delarna inte går att lösa med en hybrid. Med teknisk menar respondenten att det är enklare att prata med C kod eller ett C++ bibliotek med native. Android har Java native interface som utvecklaren kan nyttja. Är det däremot ett enklare innehåll, mer som en hemsida som ska presentera information kan en hybrid lösning kanske bli enklare och billigare att bygga.
“Med JavaScript kommer du bara åt en begränsad del av telefonen eller plattformen. Jobbar du native så kommer du åt flera API:er och du har även tillgång till lågnivå kod som C++ bibliotek.”
4.5.2 Vilka är de viktiga aspekterna som skiljer sig mellan native och
hybrid?
Respondenten säger att det är lättare att starta utvecklingen av hybrid och snabbare att få ut den till olika plattformar. Däremot stämmer det inte att det tar hälften så mycket arbete och om applikationen blir komplex, kan det ta upp en stor del av
24
budgeten. Respondenten berättar att det kanske är billigare med en hybrid-lösning men att det kanske hade blivit bättre att göra en lösning i native istället, eftersom de är mer naturliga mot plattformen. Respondenten berättar även att inom hybrid-utveckling krävs det oftast kunskap om både Android och iOS och det är svårt att hitta en utvecklare som kan allt. Av den anledningen anser respondenten att underhåll av hybrid är svårare. Respondenten lägger även till att det därför är viktigt att koden skall vara läsbar för andra utvecklare för att underlätta underhåll.
“Att göra för komplexa appar när det gäller hybrid gör att man kan få specialfall och gränsfall som är mycket svårare att lösa till flera plattformar”
4.5.3 Vad är dina synpunkter om utvecklingsmiljöerna för de olika
applikationstyperna?
Respondenten hade ingen särskild synpunkt på detta men nämnde att det kanske kunde vara billigare med en hybrid lösning, men att det hade blivit bättre att utveckla det i native eftersom det är naturligare mot plattformen. I slutändan kanske skillnaden på kostnaden blir så liten att kunden hade kunnat betala lite extra för två eller tre native istället.
4.6 Respondent H
Respondent H är både VD för företaget och en av företagets utvecklare med flera års
erfarenhet av Android.
4.6.1 Vilka är de kriterier som avgör vilken applikationstyp du väljer
att utveckla och hur resonerar du?
Respondenten föredrar native eftersom respondenten inte tycker att hybrid-applikationer och hybrid-miljöerna är tillräckligt bra. Det viktigaste vid applikationsutveckling är att ha rätt flöde, att det går snabbt och att det går att bygga på dem. Respondenten säger att den enda anledningen till att utveckla en applikation i hybrid, är för att göra det till flera olika plattformar samtidigt annars finns det ingen idé med det. Respondenten tycker det är viktigt att generera så bra användarupplevelse för användarna som möjligt, något som inte uppfylls lika bra på hybrid.
25
4.6.2 Vilka är de viktiga aspekterna som skiljer sig mellan native och
hybrid?
Enligt respondenten kan hybrid vara effektiva om applikationen ska utföra en enskild uppgift och målet är att nå ut till flera plattformar samtidigt. Så fort det läggs till flera funktioner så blir hybrid ganska invecklat eftersom det finns funktioner på de olika plattformar som skiljer sig lite åt. Då måste det göras tillämpningar i hybrid, vilket leder till att det inte längre är samma kodbas och syftet försvinner. Respondenten tror inte på att det går snabbare att utveckla i hybrid.
“När man ska göra en app, är det viktigaste att tänka på hur komplex den är. Ju mer komplex desto mer tid bör man lägga på att undersöka saker, då förstår man att hybrid är sämre lämpad. Därför är det bättre att inte göra en hybrid helt enkelt”
Respondenten berättar vidare att på grund av komplexiteten med hybrid, uppstår det mer problem jämfört med native. Komplexiteten kan göra att underhåll av applikationen blir besvärligare jämfört med native också. Eftersom plattformarna rör på sig hela tiden och när en uppdatering måste göras på hybrid-plattformen, måste utvecklare ta hänsyn till både plattformens uppdatering och till ramverket som har använts. Dessa bekymmer finns inte i samma utsträckning hos native.
4.6.3 Vad är dina synpunkter om utvecklingsmiljöerna för de olika
applikationstyperna?
Respondenten anser att hybrid-miljöerna inte är tillräckligt bra och stödet som tillverkarna erbjuder inte är bra, och därmed blir inte hybrid bra. Respondenten säger även att det inte finns verktyg som är bra nog för att hybrid ska kunna fungera lika väl som en native. Inom native får utvecklaren support från tillverkarna av plattformarna samtidigt som det finns fler utvecklare som har stött på samma problem, och därmed gett lösningar på problemen. På det sättet är native mer stabil och pålitlig. Med all support och verktyg som de nativa utvecklingsmiljöerna erbjuder så blir slutprodukten mycket bättre såväl som utvecklingsprocessen.
26
4.7 Respondent I
4.7.1 Vilka är de kriterier som avgör vilken applikationstyp du väljer
att utveckla och hur resonerar du?
Respondenten säger att utvecklare har väldigt liten yta att arbeta på när det gäller applikationer, och att det därför är besvärligt att utveckla ett bra användargränssnitt. Av den anledningen är det viktigt att få till bra och snabba gränssnitt. Det är något som försvåras när det blandas in webbtekniker eftersom de är långsammare. Respondenten väljer nästan alltid att bygga i native på grund av olika faktorer. Respondenten berättar att det finns betydligt bättre verktyg för att utveckla native än vad det finns för hybrid. Dessutom finns det bättre testverktyg och bättre möjligheter för profiling och debugging samtidigt som det inte skapas ett beroende för någon tredje part i form av ramverk.
“Det kan ju vara så att Apple eller Google uppdaterar sina OS, då kanske ramverket inte längre fungerar och då får du vänta tills de får support”
4.7.2 Vilka är de viktiga aspekterna som skiljer sig mellan native och
hybrid?
Respondenten säger att native går att göra mer responsiv, möjligheten att debugga är stor och utvecklingsverktyget är bättre. Respondenten säger även att det är svårare att få till en bra användarupplevelse om tekniken som används är för långsam. Det är inte säkert att alla applikationer fordrar att det går snabbt men oftast gör de det. Fördelen som native har är att det finns knappar och annat reglage som utvecklaren får från tillverkarna och detta gör användaren mindre förvirrad.
“Men ska man göra en app så menar jag att den ska vara snabb och responsiv, då är det bäst att göra en native”
Respondenten går vidare och berättar att generellt är en applikation ganska enkel att underhålla, beroende på hur den är gjord och hur komplex den är. Respondenten tillägger att så fort en utvecklare blandar in någon form av tillbehör, verktyg eller ramverk från något håll, blir det svårare. Respondenten säger att det finns fler människor som kan utveckla webbapplikationer än iOS eller Android men däremot inte många som kan webb, iOS och Android. Därför kan det vara svårare att underhålla en hybrid eftersom det inte finns många som kan hybrid-miljön bra.
27
4.7.3 Vad är dina synpunkter om utvecklingsmiljöerna för de olika
applikationstyperna?
Gällande utvecklingsmiljön för native, berättar respondenten att utvecklare har bättre verktyg för att utveckla native än att utveckla hybrid. Testverktygen är bättre och det är lättare med profiling, debugging och liknande. Det finns en “interface byggare” som gör att det går snabbare att bygga en applikation men framför allt är applikationen inte beroende av någon tredje part. När det kommer till utvecklingsverktyg som kommer från en bra och stabil aktör som Apple, Google eller Microsoft, är chansen stor att de program som utvecklas med dessa verktyg går att fortsätta utvecklas en längre period. Liknande garanti finns inte när en hybrid utvecklingsmiljö väljs, vilket beror på att aktören bakom utvecklingsmiljön kanske inte är bra och stabil.
4.8 Sammanfattning av resultatet
Mer än hälften av respondenterna anser att det ställs högre krav på hybrid eftersom det krävs mer kunskap för att utveckla hybrid än vad det behövs för att utveckla native. De föredrar även native istället för hybrid eftersom hybrid inte tillåter utvecklarna att komma åt alla funktioner. De tekniska begränsningarna minskar också möjligheterna att bygga ut hybrid. En del av respondenterna anser att det finns ett stort beroende av hybrid-utvecklare vilket innebär att problem blir svåra att lösa. Några andra viktiga faktorer som gör att native föredras av dessa respondenter är att native är lättare att underhålla och erbjuder en bättre användarupplevelse och prestanda. Något som samtliga respondenter var överens om var att native har bättre verktyg för att utveckla en applikation. Verktygen ger utvecklarna möjligheten till att testa applikationerna. Verktygen för hybrid erbjuder inte testning.
28
5 Analys
Analysen är sammanfattad utifrån resultaten från de utförda intervjuerna som har gjorts i studien. Dessa resultat kopplas samman med teorier och tidigare forskning som har tagits upp i studien. I nästa avsnitt kommer analysen att diskuteras.
5.1 Kriterier och resonemang som övervägs av utvecklarna
Respondent A och B anser att utvecklingen av hybrid kostar mer i form av tid och pengar än vad hybrid gör, och därför föredrar dessa respondenter native. Det går emot Lim [6] som anser att fördelen med hybrid är att kostnaden blir mindre i form av tid och pengar, eftersom utvecklaren endast behöver utveckla en applikation som är plattformsoberoende. Det går emot Botella, Escribano och Penalver [3], där utvecklingstiden enligt dem var kortare för hybrid än vad det var för native.James [17] teori om att hybrid är plattformsoberoende och går att distribuera till flera plattformar stöds av respondent G och H. De säger att den enda anledningen till att göra en hybrid är för att göra applikationen till flera olika plattformar samtidigt. Respondenterna säger även att hybrid endast är effektiv om den skall göra enskilda uppgifter.
Respondent A, B, G, H och I anser att det ställs högre krav på hybrid eftersom det krävs mer kunskap för att utveckla hybrid än vad det behövs för att utveckla native. Respondent A och B anser att det finns ett stort beroende av hybrid-utvecklare vilket leder till att det blir svårare att lösa problem. Respondent D, E, F anser också att underhåll av native är enklare än vad det är med hybrid. Respondent C och G anser att underhåll av native är lättare eftersom fokuset endast ligger på en plattform. Detta stöds Lee, Dolby och Ryu [28] som även säger att dokumentationen som saknas är en nackdel för hybrid.
Respondent C, I och H anser att det är viktigt att generera en bra användarupplevelse, genom att göra ett bra användargränssnitt samtidigt som det är snabbt. Respondent I tillsammans med respondent A och H betonar betydelsen av snabbheten i en applikation, vilket försvåras när webbtekniker blandas in eftersom webbtekniker gör det långsammare. Detta är något som stöds av Botella, Escribano och Penalver[3]. Deras undersökning tyder på att native har ett bättre användargränssnitt, även James [17] teori om att native är snabbare stöds.
29
5.2 Aspekter som skiljer sig mellan native och hybrid
Corral, Sillitti och Succi [21] och Lim [6] ser på de tekniska begränsningar som att komma åt enhetens hårdvarufunktioner som en nackdel. Dessa tekniska begränsningar gör att respondent B, D, E, F och H föredrar native framför hybrid. Det går inte att komma åt alla funktioner och möjligheten att bygga ut hybrid minskar. Även respondent G föredrar native framför hybrid, men respondenten anser att det beror på hur teknisk applikationen skall vara. Om applikationen är mindre teknisk, kan respondenten föreslå en hybrid med förutsättningarna att det är mer passande än en native.
Respondent C och B föredrar också native istället för hybrid och de anser att prestandan är viktig för att animationerna på en smartphone ska bli bra. Där är hybrid sämre i jämförelse med native. Det stödjer Lim [6], Hale och Hanson [9], Corral, Sillitti och Succi [21], som anser att native utnyttjar prestanda bättre än vad hybrid gör.
5.3 Utvecklingsmiljöer
Samtliga respondenter föredrar verktyg för native istället för hybrid eftersom de anser att det finns bättre verktyg inom native. Anledningen till att de föredrar verktygen för native är på grund av att de ger möjligheten till testning av applikationen. Respondent A anser att hybrid-verktyg inte är tillräckligt bra på grund av att utvecklare inte förstår plattformen under. Detta stöds av Lee, Dolby och Ryu [28] teori om att utvecklare måste göra omfattande tester för hybrid utveckling eftersom det saknas IDE inom området och att support saknas för verktygen i hybrid utveckling.
