WEBB ELLER NATIVE APPLIKATION? En jämförelse i prestanda inom vädervisualisering

(1)

WEBB ELLER NATIVE APPLIKATION?

En jämförelse i prestanda inom vädervisualisering

WEB OR NATIVE APPLICATION

A comparison of weather visualization performance

Examensarbete inom huvudområdet Informationsteknologi

Grundnivå 30 högskolepoäng

Vårtermin 2020

Okan Özdes

(2)

Sammanfattning

Problemet med de olika applikations arkitekturer som finns är vilken av de man ska välja för att implementera en ny applikation, då arkitekturerna har både för och nackdelar som kommer med dem. Arbetet fokuserar på arkitekturerna webb och native inom väderprognos domänen. Söktiden är den viktigaste faktorn för en sådan applikation och mätningen som ska utföras för båda applikationerna är hur snabbt det går att göra en sökning för en stad till att all information har visuellt presenterats.

(3)

(4)

Innehållsförteckning

Innehållsförteckning ... 0 1 Introduktion ... 1 2 Bakgrund ... 2 2.1 Android Arkitektur ... 2 2.2 Webbapplikationsarkitektur ... 3 2.3 Kotlin ... 4 2.4 Native applikation ... 7 2.5 Hybridapplikation ... 7 3 Problemformulering ... 8 3.1 Frågeställning ... 8 3.2 Hypotes ... 9 4 Vetenskapliga metod ... 10 4.1 Tillvägagångssätt ...10 4.2 Alternativa Metoder ...10 4.3 Forskningsetik ...11 5 Genomförande ... 12 5.1 Litteraturstudie ...12 5.2 Implementation ...13 5.2.1 Webbapplikation ...13 5.2.2 Native applikation ...17 5.2.3 Insamling av söktider ...18 5.3 Progression ...20 5.3.1 Applikation struktur ...20 5.3.2 Insamling av söktider ...20 5.4 Pilotstudie...21 6 Utvärdering ... 25 6.1 Kodändringar från pilotstudien ...25 6.2 Hård och mjukvaruspecifikationer ...25 6.3 Presentation av undersökning ...26 6.4 Analys ...33 6.5 Slutsatser ...33 7 Avslutande Diskussion ... 35 7.1 Sammanfattning ...35 7.2 Diskussion ...35 7.3 Etik ...36 7.4 Framtida arbete ...37 Referenser/References... 38

(5)

1 Introduktion

Applikationer har blivit en vardaglig aktivitet och har ändrat det mänskliga beteendet genom åren som internet och mobiler har utvecklats. Idag kan det mesta av våra dagliga aktiviteter utföras med applikationer som att läsa tidning, E-Learning, shopping osv Selvarajah, K., Craven, M., Massey, A., Crowe, J., Vedhara, K., Fenning, N (2013). Genom detta har efterfrågan för applikationer har ökats exponentiellt och har fått en stor uppmärksamhet i marknaden. I och med efterfrågan av applikationer har ökats debatteras det om vilken sorts applikations arkitektur av webb, native och hybrid som ska användas.

Problemet ligger i att det är svårt att avgöra om vilken arkitektur som ska användas för att skapa en ny applikation då de olika arkitekturer kommer med för och nackdelar (Charland, A., Leroux, B. 2011). Fokuset har skalats ner till arkitekturerna webb och native eftersom arkitekturers struktur skiljer sig från varandra och det förekommer både för och nackdelar vid val av arkitektur. Tillämpningsområdet för undersökningen hålls till väderprognos domänen för att det är en vardaglig aktivitet som förekommer många gånger varje dag.

I denna studie kommer en webbapplikation som är byggd i HTML, CSS och JavaScript att skapas och en native applikation som är byggd i Kotlin som är det officiella programmeringsspråket för att implementera Android applikationer. Applikationerna som ska byggas är en väderprognosapplikation där man ska kunna söka på en stad i Sverige för att se information om vädret är. För att undersökningen vara bli så bra som möjligt kommer applikationerna att ha identisk utseende och samma funktionalitet.

Då väderprognosapplikationer är en sysselsättning som uppkommer flera gånger om dagen så är användarupplevelse den viktigaste faktorn som måste uppfyllas för en applikation. För att få en applikation att lyckas krävs det att den ger en god användarupplevelse och för en applikation som är gjord för väderprognosdomänen är söktider den allra viktigaste faktorn. Söktiden är en vital faktor för en sådan applikation då om det tar allt för lång tid att utföra en sökning kommer inte applikationen att lyckas.

Studien utför ett experiment som sker i en kontrollerad miljö där två mätpunkter byggs in i applikationerna för att utvinna data för applikationernas söktider. Datan som tas fram kommer att användas för att se vilken av applikationerna som presterar bäst inom väderprognos domänen och om vilken webbläsare som webbapplikationen använder påverkar dess prestanda. Genomförandet av artefakterna går att följa på GitHub och artefakterna ligger i varsin repositories.

(6)

2 Bakgrund

2.1 Android Arkitektur

Android är ett av det största mobila operativsystemet ute som är byggt av en Linux kärna. Som Figur 1 nedan visar består android arkitekturen av 4 lager, applikation (Application), applikation ramverk (Application framework), android mellanvara (Android middleware) och Linux kärnan (Linux kernel) (Ma, Gu & Wang, 2014)

(7)

Applikation är det översta lagret i arkitekturen och som ger en uppsättning av kärnapplikationer för android enheter som E-post, SMS-program, kalender, webbläsare, kontakter etc. (Ganhewar & Sheikh, 2010). Resterande lagren i arkitekturen bygger grunden för utförande av applikationer till Android plattformen.

Applikationsramverket används oftast av applikationsutvecklare då lagret hanterar många grundfunktioner för android applikationer som exempelvis UI komponenter. Utvecklarna får även tillgång till alla API-ramar som kärnprogrammen som nämnes i punkt 1.1.1 som förenklar återanvändningen av komponenter. Innehållsleverantörer gör det möjligt för en applikation att komma åt eller dela data med andra applikationer (Ma, Gu & Wang, 2014)

Det finns två delar i det här lagret och dem är android bibliotek och android exekverings system. I bibliotek delen komponenten definieras Hardware Abstraction Layer (HAL) som är ett standardgränssnitt som sköter kommunikationen mellan applikationer och hårdvara. HAL har hand dom de mesta av hårdvarans specifika implementeringar som API: er för kamera och ljud. Biblioteken är utvecklad med programspråken C eller C++ och kan användas av de olika komponenterna i ett Android system som tillhandhåller en service för utvecklarna.

Android exekveringstid består av ett Java Core-bibliotek och Dalvik virtual machine och som består av Java Core-bibliotek. Dalvik virtuel machine är ett register som gör specifika förbättringar för mobila ramverk (Ma, Gu & Wang, 2014).

Linux lagret är det understa lagret i android arkitekturen. Det här lagret är det som ger de grundläggande funktionerna för operativsystemet som kärndrivrutiner, strömhantering och filsystem. Android baserar sig i princip på Linux version 2.6 för kärnsystemtjänster (Ma, Gu & Wang, 2014).

2.2 Webbapplikationsarkitektur

Det finns flera olika sätt att skapa en webbapplikation på. För det här arbetet kommer det att fokuseras på det traditionella webbapplikationerna. I en traditionell webbapplikation görs alla förfrågningar från en klient som skickar förfrågningarna till en server som tar upp dem och svarar klienten med en HTML sida (Jadhav, Sawant & Deshmukh, 2014). Webbapplikationen laddar om applikationen efter varje användarinteraktion. En traditionell webbapplikation är en så kallad server side applikation eftersom alla förfrågningar som en klient gör hanteras av servern (Jadhav et al. 2014). Figur 2 nedan illustrerar arkitekturen för en traditionell webbapplikation fungerar.

(8)

Visuell representation på en traditionell webbapplikation. (Jadhav et al. 2014)

2.3 Kotlin

Kotlin är ett open-sourceprogramspråk som är utvecklad av programmerare från IDE Jet Brains i Ryssland. Programspråket visade sig först år 2011 och den släpptes officiellt ut år 2016. I maj år 2018 annonserade Google Android team att Kotlin är det officiella programmeringsspråket för Android development. (Subham et al. 2018).

Kotlin är ett statiskt programmeringsspråk som använder Java virtual machine (JVM) att köras på (Subham et al. 2018). Kotlins syntax är inte kompatibel med Java men Kotlin är utformad för att samverka med Java-kod. Kotlin kan användas inom följande områden (Jangid, 2017):

• Server-side applications • Android applications • Desktop applications

(Subham et al. 2018) nämner ytterligare fem punkter till varför Kotlin är det föredragna språket för utveckling av android applikationer:

1. Språk och miljö är mogna

2. Med Kotlin kommer android utvecklingen bli lättare 3. Kotlin hjälper för att reducera buggar i koden

(9)

Kotlin gick igenom många faser innan den slutliga 1.0 versionen släpptes. Det innebär att troliga problem som vanligtvis uppstår för andra programmeringsspråk redan har tagits hand om under utvecklingsfasen (Subham et al. 2018). Programmeringsspråket är även kompatibel med JDK 6 och innebär att äldre versioner inte uteslutas vid utveckling av applikationerna (Obugyei, 2016). Figur 3 nedan visar att antal rader i utvecklandet med Kotlin är betydligt mindre än Java för att åstadkomma samma output. Vid skapandet av en klass behöver Kotlin några enstaka rader medan Java behöver upp till 50 rader kod (Subham et al. 2018).

Kotlin kodexempel (Subham et al. 2018)

Kotlin

publicclassUser (val firstName: String, val lastName: String, val age: Int) { funtoString() = "$firstName, $lastName , age $age"

}

funmain (args : Array<String>) { println(User("Börje", "Lundin", 45)) }

(10)

Kodexempel Java. (Subham et al. 2018)

Java

publicclassUser {

privatefinal String firstName; privatefinal String lasName; privatefinalint age;

publicUser (String firstName, String lastName, int age) { this.firstName = firstName;

this.lastName = lastName; this.age = age;

}

public String getFirstName() { return firstName;

}

public String getLastName() { return lastName;

}

publicintgetAge() { return age; }

public String toString() {

return firstName + " " + lastName " " + " age " + age; }

}

classMain {

publicstaticvoidmain (String[] args) {

(11)

2.4 Native applikation

En native applikation är applikationer som är specifikt skriven och uppbyggd för ett specifikt operativsystem för mobila enheter. De ledande mobila operativsystem som är just nu är Googles Android och Apples iOS (Jobe, 2013). För att utveckla en applikation för de olika mobila operativsystemen används olika programmeringsspråk. För att utveckla en Android applikation används programmeringsspråket Java eller Kotlin och för iOS används programmeringsspråket Objective C (Charland et al. 2011). Det som skiljer sig mellan en native applikation med en webbapplikation är att en webbapplikation har brist på direkt åtkomst till enhetens hårdvara (Jobe, 2013).

2.5 Hybridapplikation

En hybridapplikation är en mjukvaruapplikation som kombinerar delar från både webb och native applikationer. En hybridapplikation är i huvudsak en webbapplikation som har lagts in i en native applikations skal. Vid utvecklingen av en hybridapplikation används teknikerna för att utveckla en webbapplikation, HTML5, JavaScript, CSS, API: er och som har tillgång till enhetens hårdvara som en native applikation har (Jobe 2013). Likt en native applikation laddas en hybridapplikation ner från en applikations butik som Google Play eller App Store och installeras lokalt. Enheten kan sen anslutas till alla funktioner som mobilplattformen tillhandhåller genom en webbläsare som finns inne i applikationen. Webbläsaren och dess plug-ins körs i bakgrunden och är osynlig för användaren.

(12)

3 Problemformulering

Problemet ligger i att det är svårt att avgöra om en applikation ska byggas som en webbapplikation eller en native applikation. Webbapplikationer har fördelen att utvecklas bara en gång för varje olika mobila operativsystem, vilket resulterar i billigare utveckling. Native applikationer tenderar att vara snabba, men kräver mer utvecklingsinsatser, tid och pengar då en och samma applikation behöver utvecklas flera gånger för varje operativsystem. I vissa fall kan en applikation som är skriven för ett operativsystem behövas en fullständig omförändring. Eftersom operativsystemen inte har samma hostsystem som ger olika tillgångar och begränsningar till enhetens hårdvara och mjukvarufunktioner (Selvarajah et al. 2013).

Väderapplikationer förlitar sig på visualiseringar, och kräver därför att applikationen uppfyller prestandanormer. Problemet är att det är oklart om webbapplikationer kan fungera såväl som native applikationer inom väderapplikation domänen. Användarna förväntar sig är en tillfredsställande och snabb användarupplevelse vid användning av applikationen, då svarstider för applikationer är det viktigaste attributet. Om en applikation är långsam kan det inträffa att användare slutar att använda applikationen och byter till en liknande (Liu et al. 2016). Därför är målet med detta arbete att jämföra prestandan mellan en native och webbapplikation.

3.1 Frågeställning

RQ1: Hur ska native applikationen och webbapplikationen byggas för att de ska kunna jämföras mot varandra?

RQ2: Går det att bygga en artefakt för webb och native som är identiska? RQ3: Hur ska data om responstiden mätas för applikationerna?

För att besvara dessa frågor har en uppsättning av mål utformats. Dessa mål kommer att ligga som en grund för implementeringen av applikationerna och som är följande:

1. Skapa två olika applikationer, en webbapplikation och en native applikation. Applikationerna ska bestå av en sökruta, en sökknapp och ett fält där resultatet ska presenteras. Applikationernas utseende ska vara identiskt utseendemässigt.

2. Skapa script i Tampermonkey och Greasemonkey för att samla in söktider för webbapplikationen och en funktion som samlar in söktider för den nativa applikationen. 3. Samla in söktiderna för båda applikationerna när en genererad sökning har gjorts.

(13)

3.2 Hypotes

• H0: Det kommer inte att finnas någon statistiskt signifikant skillnad mellan webbapplikationen och native applikationens prestanda och att det inte finns en signifikant skillnad på vilken sorts webbläsare webbapplikationen kommer att köras på som påverkar webbapplikationens prestanda.

• H1: Det kommer att finnas någon statistiskt signifikant skillnad mellan webbapplikationen och native applikationens prestanda och att det finns en signifikant skillnad på vilken sorts webbläsare webbapplikationen kommer att köras på som påverkar webbapplikationens prestanda.

(14)

4 Vetenskapliga metod

(Wohlin et al. 2012) beskriver de fyra olika undersökningsmetoder som man har att välja mellan och dessa är, fallstudier (Case study), enkät (Survey), experiment och quasi-experiment. Metoden som kommer att användas för det här arbetet är experiment som är en empirisk undersökningsmetod. Metoden experiment valdes för att experimentet ska utföras i en kontrolleras miljö för att resultatet ska bli så bra som möjligt. Att utföra ett experiment är väldigt tidskrävande och det kräver mycket bra planering för att experimentet ska vara bra. Annars finns det en risk att data som har samlats in inte är användbart. Ett experiment kan antingen vara människorelaterat eller teknikorienterat. I ett människorelaterat experiment kan det medföra att man har mindre kontroll då människor agerar sig olika vid tillfällen, medan ett teknikorienterat experiment tillämpas olika tekniker och verktyg. Metoden experiment passar bra för arbetet då arbetets fokus är att samla in och jämföra söktider mellan två applikationer. (Wohlin et al. 2012).

4.1 Tillvägagångssätt

För experimentets utförande kommer två applikationer att skapas. Arbetet är likt experimentet som (Selvarajah et al. 2013) utförde när de jämförde vilken av en webbapplikation och en native applikation var mest lämpad för en sjukvårdsapplikation. För det här experimentet kommer applikationerna att vara en väderapplikation, som användarna kan se hur många grader det är ute i specifika städer runt om i världen och både kommer att ha liknande utseende. Det API som kommer att användas för både artefakterna är Open Weather Map som genererar data om hur vädret är runt om i världen. Efter att applikationerna är skapade kommer ett script att skapas för webbapplikationen som kommer att simulera inladdning av webbapplikationen x antal gånger och logga data om hur lång tid det tar för webbapplikationen att laddas in. Scriptet kommer att köras med hjälp av Greasemonkey som är ett tillägg för webbläsare för att kunna köra script i bakgrunden. För Android applikationen finns det ett verktyg i Android Studio om heter Play Console som tar fram data gällande renderingstid och applikationens starttid (support.google.com/googleplay/android-developrer).

4.2 Alternativa Metoder

Enkäter en metod som kan användas för arbetet. Vid användning av enkäter för det här sammanhanget är att låta användare använda artefakten i en period, genom att användarna fyller i en enkät efter användning av applikationerna som ger en bild till utvecklaren om användarnas användarupplevelse (Wohlin et al. 2012). Enkäter kommer inte att användas för det här arbetet då intressenters användarupplevelse har inget med mätningen att göra.

(15)

Fallstudier är den metod som hade kunnat används för arbetet. Metoden kan användas inom forskningsprojekt, aktiviteter eller uppgifter. Data som samlas in med metoden är till för ett specifikt syfte och baserad på insamlingen av data kan då statistiska analyser att genomföras. Det som skiljer sig mellan fallstudier och experiment är att fallstudie är en observationsstudie som efterliknar en riktig installation, medan ett experiment utförs i en kontrollerad miljö (Wohlin et al. 2012).

4.3 Forskningsetik

Då ett experiment ska genomföras är det viktigt att resonera om de etiska aspekterna. För att experimentet ska vara replikerbart i framtiden ska vilken sorts mjukvara och hårdvara som har använts för experimentet ska beskrivas och koden som skrivs för applikationerna kommer att sparas på GitHub. Det är för att experimentet ska kunna utföras i framtiden och få samma resultat eller förbättra resultatet med nyare verktyg som uppkommer i framtiden. I kapitel 5 ”Genomförande” kommer arbetet att beskrivas på ett noggrant sätt att projektet kan upprepas i framtiden och få samma resultat. Det här är för att försäkra att arbetet inte har manipulerats för att få ut ett resultat (Cai et al. 1998).

Ett experiment kan göras för samma objekt flera gånger vid olika tillfällen och det är viktigt att tänka på vart och vilken tid på dygnet experimentet kommer att genomföras, då omständigheterna inte är detsamma för experimenttillfällena. Det finns en risk att omständigheterna som inträffar kan påverka resultaten som att eventuellalla spikar förekommer i resultatet. Spikarna som inte är periodisk återkommande ska noteras innan det tas bort från resultatet (Wholin et al. 2012).

Den sortens data som kommer att användas för experimentet är data om hur vädret är runt om i världen då artefakterna kommer att vara en väderprognosapplikation. Data som har upphovsrättskyddat innehåll och känslig information som personuppgifter eller sjukhusregister vill man gärna undvika, för att inte behöva dölja informationen i slutändan (El-Hajj, Brahim, Hajj, Safa & Adaimy, 2016). Bilder samt annat upphovsrättsskyddat innehåll som kommer att användas under arbetet ska vara av creative commons licenserna CC BY, CC SA, CC BY-ND, CC BY-NC, CC BY-NC-SA och CC BY-NC-ND tillåter användning och förändring av resurserna så länge som upphovsmannen blir nämnd.

(16)

5 Genomförande

5.1 Litteraturstudie

En litteraturstudie behöver genomföras för att samla in information och kunskap för arbetet. Det används även till att samla in inspiration och tillvägagångssätt för studien. Vid implementation av artefakterna användes webbsidor och guider för få kunskap om programmeringsspråket Kotlin som källor som en komplettering till de forskningsartiklarna från bakgrundsdelen.

Inspirationen för att implementera en native och en webapplikation som ska utföra samma uppgift hittades från artikeln som är skriven av (Selvarajah et al.2013) Native Apps versus Web

Apps: Which Is Best for Healthcare Applications. I artikeln beskrivs vilka verktyg som

användes för att skapa applikationerna med. Dem beskriver även vilka för och nackdelar det finns med att implementera en native applikation mot en webapplikation.

Av urvalet kurser som Högskolan i Skövde har att erbjuda gav Programmering av mobila applikationer och Webbprogrammering mycket inspiration till detta arbete. I kursen Programmering av mobila applikationer implementerades en android applikation med användning av Android Studio. I kursen Webbprogrammering implementerades en webbapplikation som har single-page format som ska replikera ett bokningssystem med hjälp av AJAX anrop. API delen gavs till uppgiften och det var endast front-end delarna som skulle implementeras, dock gick kursen mer djupare in på JavaScript.

Developer.android (developer.android.com 2020) har använts för att få kunskap för programmeringsspråket Kotlin och hur syntaxen för språket ser ut. På hemsidan finns det en uppstartsguide till programmet Android Studio som visar hur man ska göra för att skapa ett projekt med språket Kotlin istället för Java. Developer.android har en väldigt bra dokumentation som ger en bra kunskap för syntaxen.

För att få ytterligare kunskap om programmeringsspråket Kotlin användes böckerna ”Kotlin / Android Studio 3.0 Development Essentials – Android 8 Edition (2017)” och ”Programming Kotlin (2017)”. Böckerna går igenom mer detaljerad syntax och funktionalitetmässigt ger en bredare förståelse för hur språket fungerar.

Stack Overflow (Stack Overflow 2020) har även använts som komplettering för developer.android även för implementationen av webapplikationen för att hitta lösningar till problem som uppstod.

Vid implementering av mätskript som webbapplikationen användes Tampermonkey som är ett lätt användbart Userscriptmanager (Biniok 2018) och den kunskapen har erfarits sedan tidigare kursinnehåll.

(17)

5.2 Implementation

Innan en pilotstudie kan genomföras måste först två applikationer att implementeras. En av applikationerna kommer att implementeras som en webbapplikation och den andra kommer att vara en native applikation för det mobila operativsystemet Android. Det är tänkt att applikationerna ska se exakt likadana ut och ha samma funktionalitet för att göra experimentet så exakt som möjligt. För de båda applikationerna bör det inte finnas något som kan orsaka störningar när pilotstudien och experimentet ska genomföras.

För att göra det möjligt att replikera experimentet för framtiden kan hela källkoden och saker som är relaterad till arbetet hittas i ett GitHub-arkiv. Det är också möjlig att följa implementeringstegen genom att kolla på de commits som finns Github-arkivet. För detta arbete har två GitHub-arkiv skapats, ett för webbapplikationen och ett för native applikationen. GitHub-arkivet för webbapplikationen kan hittas på arkivet https://github.com/a17okaoz/Examensarbete och för native applikationen https://github.com/a17okaoz/Androidapplication. Källkoden för webbapplikationen kan även hittas i källkoden i (Appendix A-C).

5.2.1 Webbapplikation

Plattformen Atom användes för att implementera webbapplikationen och för den här applikationen skapades en HTML-fil som innehåller applikationens struktur, en CSS-fil som innehåller stylingen och två JavaScript-filer. Den ena JavaScripts-filen är för webbsidans funktionalitet och den andra är skapad med tillägget Tampermonkey som används för att samla in svarstiderna för sökningar som både pilotstudien och experimentet kommer att använda. Webbapplikationen är implementerad för att vara mobilanpassad och den fungerar även till andra enheter.

Webbapplikationens struktur är relativt enkel då den består av två sektioner. Den första sektionen består av en sökruta och en knapp och detta är vad användaren kommer att se när applikationen har laddats in. Den andra sektionen kommer att presentera väderdata för staden sökningen gjordes för och det som presenteras på applikationen är: stad, datum när sökningen gjordes, ikon, temperatur och väderbeskrivning.

(18)

Applikationens struktur.

För att kunna visuellt presentera data om vädret för en stad användes open weather maps API som genererar data om vädret för alla städer i världen. För att få tillgång till open weather maps API måste man först göra ett konto på deras hemsida (https://openweathermap.org/) för att få en unik API nyckel som används i JavaScript-filen. Nyckeln hittas under fliken ”API-keys” efter man har loggat in. Man kan välja mellan olika versioner på konton, gratis version eller betald version. Med gratisversionen får man bara tillgång till API: et och det är den versionen som detta arbete kommer att använda sig av. Det finns en sample url med en sample nyckel som man kan testa för att få ut data för staden London och se hur JSON-filen är uppbyggd innan man registrerar sig på sidan. Figur 5 visar hur JSON-filen är API: et är uppbyggd.

(19)

JSON-filens struktur

Funktionen getWeatherResult() som illustreras i figur 6 använder sig av fetch() för att hämta API: et som en JSON-fil. Fetch() fungerar att det tar ett argument som i detta läge är sökvägen till API: et och returnerar ett Promise på den begäran oavsett om det lyckas eller inte. I figur 6 visar hur API: et hämtas i funktionen getWeatherResult() funktionen och hur API nyckeln används.

Hämtning av API

För att en sökning ska kunna ske implementerades en addEventListener till sökknappen. Funktionen kallar sedan på getWeatherResult() och använder variabeln searchbox.value för att ta värdet som finns i sökrutan och använder det som input. I figur 7 ser man att sökvariabel London som finns i figur 5 har bytts ut mot variabeln searchbox.value som visas i figur 6 för att en sökning kan ske. Funktionen setQuery implementerades enbart för när applikationen skulle testas då en sökning genomfördes via tangentbodsknappen enter.

function getWeatherResult(query){

fetch('https://api.openweathermap.org/data/2.5/weather?q= '+searchbox.value+'&appid=00d7209b7ffda34cbe6e05e6f6746448') then(weather =>{ return weather.json(); }).then(displayResults); }

(20)

EventListener för sökknappen

För att visuellt presenteras data som efter en sökning skapades funktionen displayResults(), som använder sig av variabeln ”weather” för att komma åt delar i JSON-filen. QuerySelector används för att komma åt den DIV taggen i HTML filen där den specifika data ska skrivas ut och som sparas i en variabel. I Figur 9 visas det hur querySelector används. Eftersom div klassen ”. city” ligger inuti div klassen ”. location” måste båda klasserna deklareras.

Lagrar vart data ska representeras

Variabeln som skapades för att hålla informationen för vilken DIV tagg den är riktad till kommer sedan att använda innerHTML funktionen som används för att ange eller returnera HTML innehåll som kommer att visas på skärmen. Med hjälp av JSON-filen som illustrerades i figur 5 ovan kan man sedan plocka ut rätt data ur kolumnerna i JSON-filen, se figur 10.

Datautskrift från JSON-filen

Ikonen som visar vilken typ av väder det är för en stad hämtades ifrån open weather maps hemsida. Att få rätt ikon och beskrivning för vädret har varje vädertyp ett unikt ID som kan ses i JSON-filen under kolumnen ”weather och på open weathers hemsida https://openweathermap.org/weather-conditions kan man även se vad som är kopplat till vilket id. Processen för att hämta ikonerna till applikationen är väldigt likt den för API: et då man använder sig av en URL och figur 9 illustrerar hur det går till.

Hämtning av ikoner

var button = document.querySelector(".button"); button.addEventListener("click", function(){ getWeatherResult(searchbox.value);

})

var city = document.querySelector('.location .city');

city.innerHTML = `${weather.name}, ${weather.sys.country}`;

temp.innerHTML = `<img

src="http://openweathermap.org/img/wn/${weather.weather[0].icon}.png" height="100" width="100"/>

(21)

5.2.2 Native applikation

Vid implementeringen för den nativa applikationen användes webbapplikationen som en mall, därför att applikationernas utseende ska vara identisk med varandra. Plattformen som användes vid implementeringen är Android Studio, för att den har support för programmeringsspråket Kotlin. Det första steget vid implementationen är att med android studios verktyg få utseendet för applikationen att vara identiskt som webbapplikationen och det är i filen activity_main.xml all det grafiska sköts. Koden för filen activity_main.xml visas i Appendix () och på GitHub. Filen MainActivity kommer att innehålla all funktionalitet som applikationen har. Filen innehåller en klassen weatherTask() som hanterar funktionen för att hämta API: et och för att generera data till interfacet. WeatherTask() klassen använder sig av AsyncTask som är en thread som körs i bakgrunden och den är utformad för att vara en hjälpklass kring Threads och Handlers. AsyncTask funktionen startas via execute() som i detta fall exekveras i onClick() funktionen och när AsyncTask exekveras går den igenom fyra olika steg: onPreExecute(), InBackground(Params..), onProgressUpdate(Progress..) och onPostExecute(Result). Applikationen använder sig av funktionerna doInBackground() och onPostExecute().

I figur 13 illustrerar doInBackgrund() funktionen som har hand om hämtningen av API: et. API: et deklareras in i variabeln weather som kommer att vara parametern för onPostExecute().

Hämtning av API: et

Funktionen onPostExecute() hand om att hämta data ur JSON-filen och presentera det på skärmen. Som nämnd tidigare tar funktionen variabeln weather som parameter från funktionen doInBackground() då den håller API: et. Innan data kan hämtas måste först API: et konverteras till en JSON-fil. Figur 14 visar konverteringen till JSON fungerar och hur JSON-filen ser ut

inner class weatherTask() : AsyncTask<String, Void, String>() {

private val searchbox = findViewById<TextView>(R.id.searchBox).text override

fun doInBackground(vararg params: String?): String? {

var weather:String?

try{

weather = URL("https://api.openweathermap.org/data/2.5/weather?q= $searchbox&appid=00d7209b7ffda34cbe6e05e6f6746448") readText(Charsets.UTF_8)

}catch (e: Exception){ weather = null }

return weather }

(22)

Konvertering till JSON

För att göra det lättare vid hämtning av data från kolumnerna i JSON-filen deklarerades delarna som behövs till separata variabler. Den data som ska presenteras på skärmen ligger i kolumnerna ”main”, ”sys” och ”weather” och för att få tag på dessa används getJSONObject och getJSONArray. Figur 15 illustrerar till vilka variabler getJSONObject eller getJSONArray används till.

Variabler som håller delar från JSON-filen

Figur 15 visar processen för att presentera data så att det visas på skärmen i rätt stycke. Processen är likt webbapplikationens då variabler används för att lagra undan data, men det enda som skiljer dem åt är att här har kolumnerna som data finns på lagrats i variabler som används för att hitta till dem. FindViewById används för att deklarera variablerna med data och presentera dem till rätt stycke.

Hämtning och utskrift av data

5.2.3 Insamling av söktider

För att kunna mäta söktiden för webbapplikationen användes tillägget Tampermonkey för Google Chrome och Greasemonkey för FireFox som används för att köra userscripts. Figur 16 visar scriptets funktionalitet är att den ska generera ett x antal sökningar för en specifik stad och spara undan tiden det tog till localstorage.

https://github.com/a17okaoz/Androidapplication/commit/8ea8e946de58b9f364f8c8fc6aad 2c48d2dee375

val jsonObj = JSONObject(weather)

val main = jsonObj.getJSONObject("main") val sys = jsonObj.getJSONObject("sys")

val weather = jsonObj.getJSONArray("weather").getJSONObject(0)

/* Extrating City and Country name fom API*/

val address = jsonObj.getString("name")+", "+sys.getString("country") findViewById<TextView>(R.id.cityName).text = address

(23)

Insamlingsscript för Chrome och FireFox.

Insamlingen av söktider för den nativa applikationen sker i onClick() funktionen som är kopplad till sökknappen. Figur 17 visar att med elapsedrealtimeNanos() sparas en tid undan i variabeln start som börjar när sökknappen trycks ner. Sedan exekveras funktionen weatherTask() och efter funktionen har exekverats sparas en sluttid till variabeln end. Eftersom exekveringstiden visas som nanosekunder så konverteras det till millisekunder.

Insamling av söktider för den nativa applikationen

https://github.com/a17okaoz/Androidapplication/commit/288e2638b5283271121944b0b59 67520912dde51

for(var i = 0; i < 100; i++){

document.getElementsByClassName("search-box")[0].value = "Skövde"; var t0 = performance.now()

document.getElementsByClassName("button")[0].click(); var t1 = performance.now()

var logData = "Call to do something #" + i + " took " + (t1 - t0) + " milliseconds. \n";

window.localStorage.setItem('loggedData', logData); console.log(i);

ajaxCall(logData); }

private fun onClick(){

searchButton.setOnClickListener { for (x in 0..100) {

val start = elapsedRealtimeNanos() weatherTask().execute()

val end = elapsedRealtimeNanos()

Log.d(x.toString(), "${(end - start) / 1000000.0} ") }

} }

(24)

5.3 Progression

5.3.1 Applikation struktur

Experimentets syfte från start var att jämföra hur tiden för att göra en sökning för en stad i en väderprognosapplikation utifrån applikationerna webb och native. Under implementationens gång har både applikationernas genomgått förändringar för att applikationens struktur på ska passa både webb och nativa, för att implementeringstiden inte ska ta för lång tid. I början var det tänkt att det skulle finnas ytterligare en sida som skulle visa en väderprognos för 5 dagar framåt och per timmeprognos. Detta ändrades under tiden för att göra implementationen simplare och det skulle ta alldeles för lång tid att implementera den nativa applikationen då programmeringsspråket Kotlin lärdes samtidigt under implementeringens gång.

En annan ändring som gjordes som är främst för webbapplikationen är för vilken enhet den ska vara anpassad för. I början var det tänkt att webbapplikationen skulle vara anpassad för både datorer och mobiltelefoner. Men i slutändan anpassades applikationen till för den mobila enheten eftersom webbapplikationen skulle vara en mall när den nativa applikationen skulle implementeras.

5.3.2 Insamling av söktider

Problem som uppstod under implementeringens gång var insamling av söktider för den nativa applikationen. I början användes System.currentTimeMillis() för att få start och slut tiden för en iteration, dock gav detta inget mätbart resultat eftersom resultatet visade exempelvis 0.0 och 1.0. Istället användes System.nanoTime, detta gjorde att resultatet visades i nano sekunder och sedan konvertera resultatet till milli sekunder med att dela resultatet med 100000.0. Detta gav ett mer användbart resultat för att kunna göra mätningarna med.

Ett annat problem som uppstod var när insamlingen av söktider för webbläsaren FireFox skulle genomföras. Problemet var att FireFox avrundade sökresultaten som var mindre än en millisekund till 0 eller 1 ms (MDN Web Docs 2019f). Det som gjords för att arbeta sig runt detta problem och få mätbara resultat var ändra privacy.reduceTimerPrecision till false i about:config.

https://github.com/a17okaoz/Androidapplication/commit/56eb4fc77b1968600a9cf66267c2 515a5949f5f6

https://github.com/a17okaoz/Examensarbete/commit/cb236cdd0b28ee26b5d2695a253b3c aa63776508

(25)

5.4 Pilotstudie

Innan de riktiga mätningarna körs har först en pilotstudie utförts för att avgöra om faktorerna i experimentet är jämförbara med varandra. Pilotstudien för vardera applikationen utförs genom att med tampermonkey scriptet för webbapplikationen och native applikationens insamlings funktion kommer dessa applikationen att generera 100 sökningar för en specifik stad och spara undan tiden för de 100 sökningar. För att undersöka genomförbarheten av experimentet utförs testning med nativa applikationen med webbapplikationen och I ett senare stadie kommer experimentet att utföras med fler antal sökningar för att skapa en uppfattning om antal sökningar påverkar sökningstiden. Figur 18 presenterar information om vare mätserie gällande insamling av söktider.

Klarhet över samtliga mätserier

I figur 19 presenteras söktider som skildrar mätserier gällande söktiden för webb och native applikationen. Resultatet indikerar att den nativa applikationen är stabil och webbapplikationen en aning ostabil och båda applikationerna har avvikande värden. Avvikande värdena behölls då de inte förekom allt för ofta. Värdena har kontrollerats för att utesluta att det kunde ha förekommit störningar under mätningens gång då båda applikationerna använder sig av samma Open weather maps API.

(26)

Söktider för webb (Google Chrome) och native applikationen (100 sökningar)

För att klargöra värdenas avvikelse från medelvärdet inom respektive mätserie med webb och native applikationen visualiseras mätserierna i ett stapeldiagram med medelvärde och standardavvikelse. I figur 19 presenteras resultatet för mätserierna där det går att urskilja medelvärdet för båda mätserierna vid mätningen av söktiden för applikationerna. Native applikationen har en lägre standardavvikelse än webbapplikationen, eftersom webbapplikationen har ett fåtal avvikande värden mer än den nativa applikationen.

(27)

Medelvärde med standardavvikelse vid 100 sökningar med webbläsaren Google Chrome

I figur 21 presenteras resultatet mellan webbapplikationen som nu har laddats in med webbläsaren Mozilla FireFox mot nativa applikationen. Resultatet indikerar att den nativa applikationen är stabil då avvikande värden inte förekommer allt för ofta. Webbapplikationen som nu har laddats in i med webbläsaren FireFox är en aning ostabil då avvikande värden förekommer oftare. Båda applikationernas avvikande värden behölls då värdena är närliggande och värdena har kontrollerats för att utesluta att det kunde ha förekommit störningar under mätningens gång.

(28)

Söktider för webb (FireFox) och native applikationen (100 sökningar).

I figur 22 presenteras resultatet av mätserierna med medelvärde och standardavvikelse. Där den nativa applikationen har en lägre standardavvikelse än webbapplikationen när webbläsaren FireFox används, eftersom nativa applikationen har ett fåtal avvikande värden.

(29)

6 Utvärdering

6.1 Kodändringar från pilotstudien

Inför experimentet har ett par ändringar skett för att få mer korrekta mätningar då resultatet från pilotstudien gav ut värden som ligger mellan 0 och 1 mikrosekund och det är alldeles för låga värden att kunna göra en jämförelse på. I pilotstudien mättes det hur snabbt det gick för att utföra 100 knapptryckningar på sökknappen för vardera och den faktorn inte det som arbetet går ut på.

Den första ändringen som skedde kan ses i Appendix C var att skapa en funktion som genererar en slumpmässig stad i Sverige kommer att sättas som sökinput varje gång applikationen laddas om. Detta gjordes för att mätningarna mer komplex och för att undvika att data cacheas. Nästa ändring var att sätta ut mätpunkterna på rätt plats för att faktorn för mätningarna blir korrekt. Mätningarna för webbapplikationen kommer att börja när sökknappen trycks och avslutas när all data om vädret för en stad har visuellt presenterats på skärmen. För den nativa applikationen kommer mätningen att börja när applikationen laddas in, då det inte gick att generera en automatisk knapptryckning och mätningen avslutas på samma sätt som webbapplikationen. För webbapplikationen behövde även Tampermonkey scriptet för Google Chrome och Greasemonkey scriptet för Mozilla FireFox ändras. Scriptens funktionalitet när pilotstudien genomfördes var att generera automatiska knapptryckningar och samla in data till en php fil. Eftersom mätpunkterna sker nu i JavaScripts-filen kommer då även datainsamlingen att ske där. Därmed kommer Tampermonkey och Greasemonkey scripten enbart att iterera automatiska knapptryckningar som utförs med hjälp av en if-sats.

6.2 Hård och mjukvaruspecifikationer

I figur 24 och 25 presenteras specifikationerna för den hård och mjukvara som har använts under experimentets gång. Experimentet utfördes på en ASUS ZenBook UX430UQ 14 tums från 2017.

(30)

Specifikation av hårdvara

Specifikation av mjukvara

6.3 Presentation av undersökning

Totalt genomfördes 6 testfall i undersökningen Totalt resulterade undersökningen till 6 mätserier av söktider. Varje mätserie består av 1000 mätpunkter, och det menas att applikationerna kommer att göra en sökning för en slumpgenerarad stad och sedan laddas om 1000 gånger i rad. Under mätningarna som genomfördes påträffades det ett fåtal avvikande värden och dessa värden kommer att sparas då det inte fanns ett speciellt mönster för hur dessa påträffades.

Specifikation av testfall

Först utfördes test 1 som innefattar mätning av söktider för webbapplikationen som använder webbläsaren Google Chrome och den native applikationen. En sammanställning av test 1 innefattade testfall 1.1, 1.2 och 1.3 utfört av båda applikationerna presenteras i figur 26, 27, 28, 29, 30 och 31. En sammanställning presenterar applikationernas medelvärde med standardavvikelse som är det svarta strecket som finns på vardera stapeln för respektive testfall. Resultatet skapat en tydlig bild gällande applikationernas söktider då webbapplikationen söktid ät med än tre gånger så snabbare än den nativa applikationen.

(31)

(32)

injediagram för testfall 1.2 och 1.3 med 1000 mätpunkter

Medelvärde med standardavvikelse från mätning av testfall 1.2 och 1.3 med 1000 mätpunkter

(33)

Linjediagram för testfall 1.1 och 1.2 med 1000 mätpunkter

(34)

Resultatet indikerar det samma som test 1 att webbapplikationen har snabbare söktider än den nativa applikationen och att söktiden inte försämras vid en längre körperiod.

Linjediagram med 1500 mätpunkter för webb (Chrome) och native

(35)

Linjediagram med 1500 mätpunkter för webb (Firefox) och native

(36)

Linjediagram med 1500 mätpunkter för webb (Chrome) och webb(Firefox)

(37)

Linjediagram för samtliga serier

6.4 Analys

En analys av resultatet som presenteras i föregående kapitel kommer härmed genomföras för att finnas som grund för att besvara frågeställningarna. Det som kan konstateras utifrån resultaten är att det går att urskilja en skillnad mellan webbapplikationen mot den nativa applikationen inom samtliga testfallen. I diagrammen ser man att det inte illustreras någon överlappande standardavvikelse. Detta garanterar att det finns en signifikant skillnad mellan applikationerna och ytterligare tester behövs inte göras. I figur 26 och 28 som illustrerar resultatet ifrån testfall 1 visar att webbapplikationen presterar bättre än den nativa applikationen vid utförande av en sökning. I figur 30 kan man även se att det skiljer sig lite på prestandan gällande vilken webbläsare som webbapplikationen använder, dock är detta ingen stor skillnad då det ligger på ca 5 ms i mellan dem. En ytterligare utvärdering gjordes och det var att se om applikationernas prestanda under en längre period än i test 1. I figur 32, 34 och 36, illustreras det att ökningen av längden inte påverkade applikationernas prestanda gällande söktider. Figur 38 visar att det inte finns någon brytpunkt mellan applikationerna och att webbapplikationen med webbläsaren Google Chrome har snabbast söktider. De spikar som visas på Appendix I för applikationerna påvisade ett mönster som upplevs återkommande då varje testfall utfördes två gånger för att vara säker om spikarna inte var spontana. Dessa spikar kan bero på att nätverksstörningar eller att det är en process på hårdvaran som testerna utfördes på som drog ner på processorkraften.

(38)

söktider än de nativa applikationer i de två testfallen 1 och 2 där applikationerna jämförs mot varandra. För webbapplikationen när den körs på olika webbläsare kan man se att det skiljer dem åt, men det skillnaden är inte så stor. Varför den nativa applikationen har längre söktider än webbapplikationen beror på vilken sorts hårdvara applikationen körs på då det som påverkar dess prestanda.

Under studiens gång besvarades frågeställningarna som ställdes i kapitel 3 och den första frågeställningen för studien är ”Hur ska webbapplikationen och native applikationen byggas

för att de ska kunna jämföras mot varandra?”. Målet var att applikationerna skulle vara

identiska både utseende och funktionalitetmässigt med de olika programmeringsspråken och tekniker som användes. En enkel design skapades till applikationerna för att de ska kunna utföra det de skulle. Detta besvarar även den andra frågeställningen som är ”Går det att bygga en

artefalt som för webb och native som är identiska?”.

Den tredje frågeställningen är ”Hur ska data om responstiden mätas för applikationerna? För att få ut korrekta sökresultat laddades applikationerna om efter varje sökning. Detta gjordes för att undvika att data inte skulle cacheas. Mätningarna kunde dock inte utföras på samma sätt för applikationerna då för den nativa applikationen kunde inte en automatisk knapptryckning för sökknappen implementeras. Den enda skillnaden blir att för den nativa applikationen börjar mätningen när sidan har laddats om och för webbapplikationen börjas det när sökknappen trycks. Mätningen slutas på samma sätt för båda applikationerna då all data om vädret för en stad har visuellt presenterats avslutas mätningen.

(39)

7 Avslutande Diskussion

7.1 Sammanfattning

Målet med undersökningen var att undersöka vilken applikation av webb och native som är baserad på Android som presterar bäst inom väderapplikation domänen då snabba söktider är en faktor som tillfredsställer användaren att fortsätta använda applikationen. Två välanvända applikationer som är webbapplikation och native applikation som för detta arbete är gjord för det mobila operativsystemet Android användes.

I denna studie utförs ett experiment med en empirisk mätning på söktider från applikationerna webb och native. Applikationerna hämtar data från ett API som är framkallad från Openweathermaps hemsida som lagar väderdata i för alla städer i världen. Mätningen för applikationerna sker på tiden det tar för applikationerna att hämta data för en specifik stad och sedan visuellt presentera det på skärmen och efter en sökning har gjorts laddas applikationerna om för en ny sökning.

Under processens gång slutfördes samtliga delmål som presenterades i kapitel 3. Resultatet som presenterades i kapitel 7 indikerar på att webbapplikationen har en snabbare söktid än den nativa applikationen i alla fallen för studien. Resultatet av analysen bekräftar hypoteserna som löd att det finns en signifikant skillnad mellan webb och nativa applikationens prestanda vid söktider, dock är det ingen signifikant skillnad på webbläsarna Google Chrome och Mozilla Firefox som påverkar webbapplikationens prestanda. Mätningarna för söktiderna mättes i millisekunder.

7.2 Diskussion

Resultatet av studien visade att det fanns en stor skillnad mellan de olika applikationer som användes för att utföra studien. Resultatet visade att inom väderapplikation domänen hade webbapplikationen mer än tre gånger så snabbare söktider än den nativa applikationen inom. Båda applikationerna har en söktid på mindre än 1 sekund och det är en viktig faktor att applikationer har för att kunna ge användaren en god användarupplevelse.

Eftersom båda applikationernas söktider är väldigt snabba gör då att valet av applikation är helt upp till hur mycket pengar och resurser man har att lägga ut på en applikation. Vill man skapa en enkel applikation, inte vill lägga ut för mycket resurser och att den ska fungera på alla enheter rekommenderas då en webbapplikation, då det inte tar mycket resurser för att skapa en sådan. Har man istället mer tid och resurser att lägga ut på en applikation så rekommenderas en native applikation. Då det tar mer resurser att utveckla en sådan då applikationen måste utvecklas för varje mobila operativsystem och de använder olika programspråk.

(40)

Det hade även varit intressant att genomföra experimentet med en annan hårdvara än en laptop som användes för det är experiment. Det som skulle vara passande är en stationär dator med mer RAM minne och snabbare processor och detta kan ha gett olika resultat jämfört med laptop. Det hade även minskat sannolikheten för hårdvaruproblem som gör processen långsammare och påverkar experimentets resultat.

Resultatet från undersökningen har inte i efterhand modifierats på något sätt som påverkar resultatet. Hanteringen av data som utvanns från mätningarna gjordes på ett väldigt noggrant sätt för att säkerställa att datan var den korrekta datan för respektive mätning. Varje mätning namngavs, även tid och datum sattes på varje mätning för att inte blanda ihop dem när framtagningen av grafer skulle ske.

Det studien bidrar med till samhällsnyttan är att ge kunskap för applikationsutvecklare om vilken applikation som är mer pålitlig när det kommer till väderprognos domänen. Då att kolla upp hur vädret är har blivit allt mer en daglig aktivitet är då målet att ge användarna en pålitlig applikation som ska utföra den uppgiften så bra som möjligt. Som nämnt tidigare väljs webbapplikationen som arkitektur när projektet inte är så resurskrävande och med det kan det förekomma risker. Ett exempel på risk som kan förekomma är att webbapplikationen blir hackad av ett oönskat script som körs i bakgrunden. Applikationernas hållbarhet är en annan aspekt som är viktigt att kolla på och båda arkitekturerna bidrar med någon form utav hållbarhet. Webbapplikationens hållbarhet att den inte tar mycket ström vid användning då söktiderna är snabbast. Tidseffektiviteten och kostnadseffektiviteten är också mest hållbart för webbapplikationen då ett företag inte behöver lägga ut mycket resurser för att utveckla en sådan applikation. Det som är hållbart för den nativa applikationen är att slutprodukten som innebär funktionalitet, användarupplevelse och prestanda är mycket bättre än en webbapplikation.

7.3 Etik

Att experimentet skulle vara replikerbart var något som sattes upp för att sträva mot. Detta genomfördes genom att bifoga samtlig källkod som skrivits och använts i Appendix med aktuell kod vid genomförande av experimentet med de exakta filnamn som användes var ett steg till att experimentet skulle vara möjligt att replikera. I Github sattes även upp två repository, en för vardera applikationen där samtlig källkod lades upp med samma status på kod och filnamn som det i Appendixen. Ytterligare aspekter som underlättar replikation av experimentet är dokumentation av stegen som har genomgåtts för att utföra experimentet och en specifikation på vilken hård och mjukvara som i implementationsdelen i kapitel 5.2 existerar tydlig förklaring av kod och att verktygen som använts för att utföra experimentet är helt gratis att använda. En viktig faktor för arbetet var att välja vilken sorts data som ska användas för att utföra experimentet, då känsliga data inte får användas. Då experimentet använder väderdata för städer över hela världen behöver inte data exkluderas.

(41)

svarstider som skiljer sig ifrån det som detta experiment gav. Om experimentet ska replikeras i framtiden bör då samma programkod användas i största grad för att få ett likvärdigt resultat.

7.4 Framtida arbete

Resultatet av undersökningen kan användas som hjälpmedel till framtida arbeten inom det här området. I framtiden skulle det vara intressant att undersöka om hur andra nativa applikationer jämförs emot webbapplikationer då det här arbete baserade sig för det mobila operativsystemet Android.

För arbetet sker mätningarna för webbapplikationen med webbläsarna Google Chrome och Mozilla FireFox i experimentet vore det intressant att inkludera flera webbläsare i framtiden. Detta är intressant då olika webbläsare kan påverka svarstiderna olika mycket. Inkluderat till det här är att för den nativa applikationen utför mätningarna på en riktig mobil telefon och inte den som finns i Android Studio då söktiderna kan variera sig från telefon till telefon då prestandan för en nativ applikation kommer ifrån telefonens hårdvara.

I ett kortsiktigt perspektiv kan framtida replektioner visuellt presentera mer data än vad som görs i denna studie. Artefakterna byggdes för att enbart visa information om antal grader, stad, land, när sökningen gjordes och väderbeskrivning. Det skulle vara intressant i framtiden att vid en sökning presentera mer data som ska visas och undersöka om det kan vara en faktor som påverkar artefakternas söktider som exempelvis en ny vy som visar en prognos på vädret som sträcker sig över en vecka för staden som sökningen skedde för.

Ett långsiktigt perspektiv för framtiden är att försöka förbättra söktiderna för applikationerna med nya tekniker än vad som användes för studien. En start kan vara att sätta upp en Apache server med XAMPP för att undersöka om det är en faktor som kan reducera söktiden genom att minska nätverkstrafiken. Ytterligare ett långsiktigt perspektiv är att inkludera hybridapplikation och se hur den skiljer sig ifrån webb och native.

(42)

Referenser/References

Biniok, J. (2018). Tampermonkey. https://tampermonkey.net/ [2020-04-01]

Bose, Subham., Kundu, A., Mukherjee., M, Banerjee, M. (2018) A comparative study: Java vs kotlin programming in android application development. International journal of advanced

research in computer science, Vol.9, No.3, pp 41-45

Cia, J-Y., Nerurkar, A. & Wu, M, M.Y. (1998). Making benchmark uncheatable. Computer

Performance and Dependability, 1998. IPDS´98.Proceedings, pp. 216-227.

Charland, A., Leroux, B. (2011) Web apps are cheaper to develop and deploy than native apps, but they match the native user experience?: Mobile Application Development Web vs Native,. Issue 54, pp 49-53.

developer.android.com (2020) Meet Android Studio [online] Available at:

https://developer.android.com/studio/intro [Accessed 21 Jan.2020]

educba.com.. Java-vs-kotlin [online] Available at: https://www.educba.com/java-vs-kotlin/

[Accessed 1 Feb.2020]

E. Obugyei, (2016), “Kotlin for Android: An Introduction”, viewed on 25th April 2018 from

https://www.raywenderlich.com/132381/kotlin-for-androidan-introduction.

El-Hajj, W., Brahim, G., Hajj, H., Safa, H., Adaimy, R. (2016) Security-by-construction in web application development via database, Vol.59, pp 151-165

Flauzino, M., Veríssimo, J.,Terra, R., Cirilo, E., Durelli, V,. Durelli, R (2018) Are you still smelling it? A comparative study between Java and Kotlin language, pp 11- 18

GOOGLE INC. (Hrsg.): Android Software Development Kit (SDK). Google Inc., http://developer.android.com/sdk/index.html. – Android 2.2, Release 2

Iqbal, H, Apu, K. (2014). MVC Architecture Driven Design and Implementation of Java Framework for Developing Desktop Application. International Journal of Hybrid Information Technology, Vol.7, Issue.5, pp 317 – 322.

Jadhav, M. A., Sawant, B. R., & Deshmukh, A. (2015). Single page application using angularjs. In: International Journal of Computer Science and Information Technologies, 6(3), 2876-2879. Jangid, M. (2017) Kotlin – The unrivalled android programming language lineage. Imperial Journal of Interdisciplinary Research, Vol.3, Issue.8

(43)

Leff, A. and Rayfield, J. (2001). Web-Application Development Using the Model/View/Controller Design Pattern. 5th IEEE International Enterprise Distributed Object Computing Conference, pp.118-127.

Liu, D., Zhao, Y., Sui, K., Zou, L., Pei, D., Tao, Q., Chen, X., Tan, D., (2016). FOCUS: Shedding light in the search response time in the wild. Presented at the 35th Annual IEEE International Conference on Computer Communications, IEEE. pp. 1-9

Ma, L., Gu, L & Wang, J. (2014). Research and Development of Mobile Application for Android Platform. International Journal of Multimedia and Ubiquitous Engineering Vol.9, No.4 pp.187-198

Maryam Ahmed and Rosziati Ibrahim, (2015) “A Comparative Study of Web Application Testing and Mobile Application Testing,”

MDN Web Docs (2020). Confidentiality, Integrity, and Availability.

https://developer.mozilla.org/enUS/docs/Web/Security/Information_Security_Basics/Conf identiality,_Integrity,_and_A vailability [Viewed 2019-04-20]

Nisarg Gandhewar and Rahila Sheikh. “Google Android: An emerging software platform for mobile devices”. In: International Journal on Computer Science and Engineering 1.1 (2010), pp. 12–17.Kirusnapillai Selvarajah

Samuel, S., Bocutiu, S (2017) Programming Kotlin. Published by Packt Publishing Ltd.

Selvarajah, K., Craven, M., Massey, A., Crowe, J., Vedhara, K., Fenning, N (2013) Native Apps versus Web Apps: Which Is Best for Healthcare Applications?. Faculty of Engineering, University Park, Nottingham NG7 2RD, United Kingdom pp 189-196

Smyth, N. (2017). Kotlin / Android Studio 3.0 Development Essentials – Android 8 Edition Stack Overflow. (2020). Stack Overflow - Where Developers Learn, Share, & Build Careers. URL https://stackoverflow.com/ (åtkomstdatum 2020.04.02.).

Wasserman, I, A. (2010) Software engineering issues for mobile application development Wei J., Xu C-Z., (2011), Measuring Client-Perceived Pageview Response Time of Internet Services. IEEE Transactions on Parallel and Distributed Systems, Vol.22, Issue.5, pp. 773- 785. Wohlin, C et al., (2012) ‘Experimentation in software engineering’. Berlin: Spring, pp 175 - 200

(44)

Appendix A – weatherapplication.html

<title> Examensarbete </title> </head>

<body>

<div class="text"><h3>Weather application Artefakt</h3></div> <header>

<main>

</main> </div>

(45)

Appendix B – script.js (Pilotstudie)

var searchbox = document.querySelector(".search-box"); searchbox.addEventListener('keypress', setQuery); function setQuery(evt) {

if(evt.keyCode == 13) {

getWeatherResult(searchbox.value); }

}

var button = document.querySelector(".button"); button.addEventListener("click", function(){ getWeatherResult(searchbox.value);

})

fetch('https://api.openweathermap.org/data/2.5/weather?q='+searchbox.val ue+'&appid=00d7209b7ffda34cbe6e05e6f6746448')

.then(weather =>{

return weather.json(); }).then(displayResults); }

function displayResults(weather) { console.log(weather);

var city = document.querySelector('.location .city');

city.innerHTML = `${weather.name}, ${weather.sys.country}`; var today = new Date();

var date = document.querySelector(".location .date"); date.innerText = dateBuilder(today);

var temp = document.querySelector(".currentTemp .temp"); temp.innerHTML = `<img

src="http://openweathermap.org/img/wn/${weather.weather[0].icon}.png" height="100" width="100"/> ${Math.round(weather.main.temp

(46)

var type = document.querySelector(".currentTemp .weatherType"); type.innerHTML = `${weather.weather[0].description}`;

}

function dateBuilder(todayDate) {

var month = ["January", "February", "March", "April", "May", "June", "July", "August","September", "October", "November", "December"]; var days = ["Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"];

var day = days[todayDate.getDay()]; var date = todayDate.getDate();

var month = month[todayDate.getMonth()]; var year = todayDate.getFullYear(); var today = new Date();

var time = today.getHours() + ":" + today.getMinutes(); return `${day} ${date} ${month} ${year} ${time}`;

(47)

Appendix C – script.js (Efter ändringar)

var t0; var t1; const jsonData = { "1": "Alingsås", "2": "Arboga", "3": "Arvika", "4": "Askersund", "5": "Boden", "6": "Bollnäs", "7": "Borgholm", "8": "Borlänge", "9": "Borås", "10": "Djursholm", "11": "Eksjö", "12": "Enköping", "13": "Eskilstuna", "14": "Eslöv", "15": "Fagersta", "16": "Falkenberg", "17": "Falköping", "18": "Falun", "19": "Filipstad", "20": "Flen", "21": "Gränna", "22": "Gävle", "23": "Göteborg", "24": "Hagfors", "25": "Halmstad", "26": "Haparanda", "27": "Hedemora", "28": "Helsingborg", "29": "Hjo", "30": "Hudiksvall", "31": "Huskvarna", "32": "Härnösand", "33": "Hässleholm", "34": "Jönköping", "35": "Kalmar", "36": "Karlshamn", "37": "Karlskoga", "38": "Karlskrona", "39": "Karlstad", "40": "Katrineholm", "41": "Kiruna", "42": "Kramfors", "43": "Kristianstad",

(48)

"48": "Köping", "49": "Laholm", "50": "Landskrona", "51": "Lidingö", "52": "Lidköping", "53": "Lindesberg", "54": "Linköping", "55": "Ljungby", "56": "Ludvika", "57": "Luleå", "58": "Lund", "59": "Lycksele", "60": "Lysekil", "61": "Malmö", "62": "Mariefred", "63": "Mariestad", "64": "Marstrand", "65": "Mjölby", "66": "Motala", "67": "Mölndal", "68": "Nacka", "69": "Nora", "70": "Norrköping", "71": "Nybro", "72": "Nyköping", "73": "Nynäshamn", "74": "Nässjö", "75": "Oskarshamn", "76": "Oxelösund", "77": "Piteå", "78": "Ronneby", "79": "Sala ", "80": "Sandviken", "81": "Sigtuna", "82": "Simrishamn", "83": "Skara", "84": "Skellefteå", "85": "Skänninge", "86": "Skövde", "87": "Sollefteå", "88": "Solna", "89": "Stockholm", "90": "Strängnäs", "91": "Strömstad", "92": "Sundbyberg", "93": "Sundsvall", "94": "Säffle", "95": "Säter", "96": "Sävsjö", "97": "Söderhamn",

(49)

"98": "Söderköping", "99": "Södertälje", "100": "Sölvesborg", "101": "Tidaholm", "102": "Torshälla", "103": "Tranås", "104": "Trelleborg", "105": "Trollhättan", "106": "Trosa", "107": "Uddevalla", "108": "Ulricehamn", "109": "Umeå", "110": "Uppsala", "111": "Vadstena", "112": "Varberg", "113": "Vaxholm", "114": "Vetlanda", "115": "Vimmerby", "116": "Visby", "117": "Vänersborg", "118": "Värnamo", "119": "Västervik", "120": "Västerås", "121": "Växjö", "122": "Ystad", "123": "Åmål", "124": "Ängelholm", "125": "Örebro", "126": "Öregrund", "127": "Örnsköldsvik", "128": "Östersund", "129": "Östhammar", }

const values = Object.values(jsonData)

var randomValue = values[parseInt(Math.random() * values.length)] document.getElementById("test").value = randomValue;

var button = document.querySelector(".button"); button.addEventListener("click", function(){ t0 = performance.now()

getWeatherResult(randomValue); })

fetch('https://api.openweathermap.org/data/2.5/weather?q='+randomValue+'&appid=00d7209b7 ffda34cbe6e05e6f6746448')