. Fakulteten för teknik och samhälle Datavetenskap
Examensarbete
15 högskolepoäng, grundnivåApplikationsutveckling i Xamarin - en jämförelse
med native applikation
Application development in Xamarin - a comparison with native
application
Fejza, Egzon
Kacaniku, Ylli
Examen: Kandidatexamen 180 hp Handledare: Mia Persson
Huvudområde: Datavetenskap Andrabedömare: Olle Lindeberg Program: Datavetenskap & applikationsutveckling
Sammanfattning
I denna studie kommer vi att undersöka det populära ramverket Xamarin. Xamarin är ett cross-platform ramverk som använder programmeringsspråket C# för att ut-veckla samma applikation för iOS, Android och Windows Phone. Studiens huvud-syfte är att genomföra en inledande explorativ studie där vi försöker att identifiera ett antal särskiljande aspekter mellan native- och Xamarin utveckling och dess slutprodukter.
För att göra denna jämförelse har vi utvecklat tre applikationer: en native android applikation, en Windows Phone applikation i Xamarin, och en Android app-likation i Xamarin. Med hjälp av en litteraturstudie och utvecklingen av de ovan-nämnda applikationerna har de särskiljande aspekter observerats och identifieras.
Resultatet av vår studie visar att native Android applikationen tar upp mindre plats i telefonen jämfört med Xamarin Android applikationen, medan Xamarin Win-dows Phone applikationen tar 1/6 mindre utrymme i telefonen jämfört med Xama-rin Android applikationen. Ytterligare tester visar också att XamaXama-rin Android appli-kationen tar längre tid att starta jämfört med native Android och Xamarin Winows Phone applikationen.
Nyckelord
Abstract
In this study, we will examine the popular framework Xamarin. Xamarin is a cross-platform framework that uses the C# programming language to develop the same application for iOS, Android and Windows Phone. The study's main purpose is to conduct an initial exploratory study in which we try to identify a number of distin-guishing aspects between native- and Xamarin development and its products.
In order to make this comparison we developed three applications: one native android application, one Windows Phone application in Xamarin, and one Android application in Xamarin. With the help of a literature study and the development of the aforementioned applications, the distinctive aspects have been observed and identified.
The result of our study shows that the native android application takes up less space in the phone compared to the Xamarin android application, whereas the Xamarin Windows Phone app takes 1/6 less space in the phone compared to the Xamarin android application. Further tests also show that the Xamarin android ap-plication takes longer time to start-up than with the native Android and Xamarin Winows Phone applications.
Keywords
Innehållsförteckning
Innehåll
1 Inledning
1 1.1 Bakgrund ... 1 1.2 Syfte ... 2 1.3 Forskningsfrågor ... 2 1.4 Avgränsningar ... 22
Metod
3 2.1 Litteraturstudie ... 3 2.2 Action research ... 3 2.3 Datainsamling ... 4 2.4 Metoddiskussion ... 53 Resultat
6 3.1 Resultatet av vår litteraturstudie ... 6 3.2 Implementation ... 73.2.1 Xamarin Studio/Visual Studio ... 7
3.2.2 Eclipse ... 7
3.2.3 Android ... 7
3.2.4 iOS ... 8
3.2.5 Windows Phone ... 9
3.3 Tillvägagångsätt ... 10
3.4 Redovisning av utvecklade applikationer ... 12
3.4.1 Android applikation i native ... 12
3.4.2 Xamarin applikation i Android ... 14
3.4.3 Xamarin applikation i Windows Phone ... 16
3.4.4 Diskussion ... 18
3.5 Resultat av tester ... 19
4 Analys och diskussion
215 Slutsats och vidare forskning
236 Referenser
247 Bilagor
277.1 Bilaga 1 ... 27
Ordlista
Native En native applikation som har utvecklats för användning på en viss platt-form eller enhet.
API (Application Program Interface) är en uppsättning av rutiner, protokoll och verktyg för att bygga program. Ett API anger hur programvarukomponenter bör samverka och API:er används vid programmering av grafiska användargränssnitt (GUI) komponenter.
Cocoa Touch är ett ramverk för att bygga program för att köras på iOS enheter.
Dreamspark är ett Microsoft-program som stödjer teknisk utbildning genom att ge tillgång till Microsofts programvara för lärande, undervisning och forskning.
1
1 Inledning
1.1 Bakgrund
Bakgrunden till detta examensarbete bygger på att utföra en studie för ett Malmö-företag som heter DigitasLBi, där DigitasLBi är ett konsultMalmö-företag och jobbar med att få in andra företag in i den digitala världen. De arbetar just nu med ett ramverk som heter Xamarin [29]. Xamarin är ett ramverk som används för att ta fram samma applikation till tre olika plattformar med hjälp av programmeringsspråket C#. Företaget vill ha reda på vilka fördelar Xamarin har jämfört med native app-likationer. Native applikationer är när en applikation utvecklas endast för en typ av operativsystem, Android, iOS eller Windows Phone [6].
Idag finns det nästan 2 biljoner användare av smartphones runt om i världen. Detta betyder att ungefär 27% använder sig av en smartphone av den totala befolk-ningen i världen. Dessa används idag inte bara för att ringa och sända sms utan till mycket mer än så [24].
En smartphone kan göra allt som en persondator kan göra. Det som talar för en smartphone jämfört med en persondator är dess mobilitet det vill säga att det är möjligt att ta med sig telefonen var som helst utan några större problem. Fördelen med en smartphone är att den kombinerar mobiltelefonen med e-post, webb, mu-sik, film, kamera, GPS med mera. Hårdvaran i en smartphone är inget om mjukva-ran inte finns. Det är mjukvamjukva-ran som ger liv åt hårdvamjukva-ran i telefonen och det är här applikationerna spelar en viktig roll. Applikationerna har öppnat möjligheter för an-vändare med t.ex. sociala medier att kunna kommunicera med varandra runt om i världen [22].
Utveckling av applikationer har öppnat dörren för tredje parts utvecklare för att tjäna pengar på sina idéer och det finns många olika plattformar för smart-phones där det ställer krav på utvecklare att kunna programmeringsspråken. För att underlätta för utvecklare och företag att snabbt få ut sina applikationer i mark-naden finns idag ramverk som hjälper till att nå en så bred målgrupp som möjligt. Det är här ramverket Xamarin kommer in eftersom Xamarin är ett cross-platform ramverk som syftar till att med samma källkod få ut samma applikation till iOS, Android och Windows Phone [29].
2
1.2 Syfte
Företaget DigitasLBi i Malmö är intresserade av att få reda på om det finns några fördelar med att utveckla applikationer i Xamarin.
Det huvudsakliga syftet med vår studie blir därmed att utföra en initial under-sökande studie där vi försöker identifiera några särskiljande aspekter vid utveckling av en mindre applikation i native och ramverket Xamarin. Dessa särskiljande aspekter kommer sedan att ligga till grund för en diskussion där eventuella fördelar samt nackdelar identifieras.
1.3 Forskningsfrågor
För att uppnå det huvudsakliga syftet med vår studie så behöver vi besvara följande forskningsfrågor:
1. Går det att identifiera några särskiljande aspekter vid utveckling i native re-spektive Xamarin ifrån tidigare forskningsresultat inom området?
2. Går det att identifiera några särskiljande aspekter vid en faktisk utvecklings-situation av en applikation i native respektive Xamarin?
3. Utifrån de identifierade särskiljande aspekterna, finns det några fördelar samt nackdelar att utveckla i native och Xamarin, respektive?
1.4 Avgränsningar
I denna studie kommer vi endast att undersöka ramverket Xamarin. Vi kommer vi-dare endast att studera C# som programmeringsspråk i Xamarin för att utveckla en mindre applikation för Android och Windows Phone. Vid native utveckling kommer vi endast att undersöka utveckling i programmeringsspråket java för Android. Dessa avgränsningar har varit nödvändiga eftersom ett examensarbete är begränsat i den tid som man har till sitt förfogande.
På grund av att vi inte har haft tillgång till en mac-dator har vi endast lagts fokus på Android i native och Xamarin implementationerna i Windows Phone och Android [28].
3
2 Metod
2.1 Litteraturstudie
Uppsatsen inleds med en litteraturstudie där syftet är att hitta relevant sekundär-data [20] för att kunna besvara våra uppställda forskningsfrågor. Notera att vår första ovan nämnda forskningsfråga kommer att kunna besvaras direkt efter vår litteraturstudie. Fokuseringen kommer främst att ligga på att identifiera aktuella relaterade forskningsresultat inom forskningsområdet native utveckling samt cross-platform utveckling i Xamarin. ACM och IEEE är exempel på databaser som har använts för att söka vetenskapliga artiklar för vår studie. Vi har även använt oss av relevanta hemsidor som har visat sig användbara för att skapa sig en överblick över detta för vårt nya forskningsområde. Denna litteraturstudie anses också vara nöd-vändigt eftersom ramverket Xamarin inte är välkänt för oss sedan tidigare.
Notera att vår ovan nämnda insamlade sekundärdata även kommer att an-vändas för att hitta särskiljande aspekter, vilka sedan kommer att ligga till grund för vår reflekterande diskussion om eventuella fördelar och nackdelar med att ut-veckla i native respektive Xamarin.
Se avsnitt 3.1 för en mer detaljerad beskrivning av resultatet av vår litteratur-studie. Notera att Xamarin är relativt nytt så därför har det endast hittats ett fåtal vetenskapliga artiklar som berör ämnet [1][8][21][26].
2.2 Action research
Action research tillämpas tillsammans med en kvantitativ metod för den praktiska delen av uppsatsarbetet. Den kvantitativa metoden utgörs av att mätdata samlas in under utvecklingsarbetet i native och Xamarin, respektive.
Vid tillämpningen av action research [12] (se figur 1 nedan) planerades arbete först med avseende på hur det ska läggas upp. Här kommer vi samtidigt påbörja vår litteraturstudie. Andra och tredje steget blir sedan att utföra vår praktiska studie, d v s utveckla en mindre applikation både i native och i ramverket Xamarin, och sam-tidigt som vi bedriver detta utvecklingsarbete kommer vi att observera och doku-mentera särskiljande aspekter i native och Xamarin utvecklingen respektive; detta kommer att göras genom insamling av mätdata ifrån testkörningar på de framtagna applikationerna. Slutligen kommer vi att analysera erhållen observationsdata (d v s kvantitativ primärdata [20]) utifrån tidigare kända forskningsresultat inom områ-det, och utifrån denna analys kommer vi sedan att kunna reflektera över några eventuella fördelar och nackdelar med native respektive och Xamarin utveckling.
Anledningen till att just action research valdes är för att vi som forskare kom-mer att ta en aktiv del i forskningsprocessen i och med att vi även intar rollen som faktiska utvecklare i vår praktiska studie, vilken syftar till att identifiera några sär-skiljande aspekter i native respektive Xamarin utveckling. Notera att vi därmed, bland annat genom vår kompetens som utvecklare, i högsta grad påverkar utfallet av vår studie, och detta motiverar valet av forskningsmetoden action research.
Denscombe [27, s.6] diskuterar att action research syftar till att lösa ett sär-skilt problem och ta fram riktlinjer för bästa praxis i en organisation, även detta
4
lämpar sig väl med studiens syfte som ju är att diskutera eventuella fördelar samt nackdelar med native och Xamarin utveckling respektive. Detta motiverar vårt val av action research.
Figur 1: En övergripande summerande beskrivning av metoden action research [12].
2.3 Datainsamling
Vid sökning på tidigare forskning och vetenskapliga artiklar togs det hjälp av sök-motorerna ACM och IEEE för att hitta relevant information (d v s för insamling av sekundärdata) som kan vara användbart för att driva examensarbetet framåt. Fo-kus har lagts på att hitta artiklar från konferenser och tidskrifter. Detta har gjorts med hjälp av de inbyggda filter funktionerna som respektive databas tillhanda-håller. Vetenskapliga artiklarna som använts är publicerade mellan åren 2011 - 2016.
Namnen på de olika mobila plattformarna användes för att hitta vetenskapliga artiklar. Området för de olika mobila plattformarna är stort och för att undvika att det resulterar i för mycket sökresultat från respektive databas, användes t.ex. sökordet Android i kombination med cross-platform. För att förfina sökresultaten ytterligare som genereras av respektive databaser togs det till hjälp av att använda frassökningar. På IEEE och ACM söks en fras genom att sätta citationstecken runt frasen, “Android” detta resulterar i att endast sökresultat med den sökningen tas fram. Jämförs sökresultaten från IEEE och ACM finns det betydligt mindre antal träffar på databasen IEEE än på ACM.
De artiklar som hade antal träffar mindre än 100 undersöktes genom att titeln lästes och om den var relaterad till arbetet lästes även abstrakten. Var abstrakten intressant och relaterat till arbetet djuplästes artikeln dvs. inledning, sammanfatt-ning och resultat lästes. För att artikeln ska bli vald krävs det att den ska innehålla litteratur från tidigare forskning som styrker forskarnas påståenden för artikeln. Detta styrks ytterligare om artikeln granskats genom peer-review.
Resultatet av datainsamlingen blev att det endast valdes vetenskapliga artiklar från databasen IEEE eftersom det viktigaste nyckelordet hade minst antal träffar i IEEE jämfört med databasen ACM. Detta resulterade i att det var enklare att gå igenom färre antal träffar och hitta lämpligare artiklar som behövdes för arbetet.
5
I bilaga 7.1 finns tabeller där det kan utläsas vilken databas som har använts, sökord och antal träffar.
2.4 Metoddiskussion
Om vi ska vara kritiska till valet av litteraturstudie som forskningsmetod är nack-delen enligt [9], att det kan vara väldigt tidskrävande att söka och samla in littera-tur. Det händer ofta att just den litteratur du behöver låna på ett bibliotek kanske inte finns tillgänglig eller så är den utlånad av en annan individ. En annan kritiskt punkt med att använda litteraturstudie är att när all information har samlats in och fakta som behövs, krävs det att lägga ner extra tid på att granska och gå ige-nom all material som har hittats [9], dock är denna forskningsmetod nödvändig för att vi ska kunna besvara våra uppställda forskningsfrågor.
Notera att metoden action research diskuterades och motiverades samtidigt som den presenterades och diskuterades i avsnitt 2.2.
6
3 Resultat
3.1 Resultatet av vår litteraturstudie
Litteraturstudien som utfördes medförde att vetenskapliga artiklar, böcker och rele-vanta hemsidor hittades för att driva studien framåt.
De vetenskapliga artiklarna som har samlats in från IEEE databasen har an-vänts för att besvara forskningsfrågorna för studien. En kvantitativ analys har kunnat genomföras på två av artiklarna som tar upp prestandan för applikationer vilket har tagits fram med hjälp av Xamarin. I artikeln presenteras tabeller där en native applikation startar mycket snabbare än applikationen som skrevs i Xamarin. Forskarna i artikeln går vidare med att visa tabeller på applikationens storlek i mb, där Xamarin är större än i native. Resultat av all data som tagits fram visar att app-likationen i Xamarin tar mer plats i telefonen än native appapp-likationen[1][8].
På de två resterande artiklarna som berör Xamarin har en kvalitativ analys kunnat genomföras där ena artikeln har tittat på fördelar och nackdelar med att utveckla i Xamarin. Artikeln nämner att fördelen med Xamarin är att logiken av ko-den kan återanvändas men att nackdelen är behovet av att kod för gränssnitt måste kodas individuellt för varje plattform[8][21]. En annan artikel är också lite negativ eftersom de menar att Xamarin är inkonsekvent på det sätt som Xamarin översätter mellan Windows Phone och Android API:er[26].
Ett flertal artiklar hittades som inte berörde Xamarin men där ämnet var rele-vant för studien. För dessa artiklar har en kvalitativ analys genomförts. Xamarin har konkurrens i form av andra ramverk. Ett mindre antal artiklar har gått igenom olika ramverk och föreslagit att ramverk som använder sig av HTML, CSS och JavaScript som programmeringsspråk är lättare att lära sig, jämfört med andra programmeringsspråk vid utveckling av applikationer[10].
Det finns även hybrid lösningar av applikationer som uppträder som webb-sidor i operativsystemets gränssnitt. Författarna för artikeln har valt att ta sin na-tive applikation och göra den till en hybrid lösning så att den kan köras på olika mobila plattformar[23].
Att utveckla och underhålla cross-platform applikationer är dyrt därför före-slår författarna AXIOM ramverket som enligt författarna ska minska utvecklingsti-den och kostnautvecklingsti-den samtidigt öka kvaliteten på applikationerna[25].
När det gäller utveckling av cross-platform spel föreslår författarna att ram-verket XMLVM är bäst lämpad för det ändamålet[4].
Ett få antal artiklar har gått igenom olika ramverk och undersökt fördelar och nackdelar mellan dessa. Författarna skriver att den stora fördelen med att använda sig av ett ramverk resulterar i att företag får ut sin applikation till olika plattformar snabbt med hjälp av samma källkod. Nackdelar som har hittats och stött på är att det finns begränsningar i olika API-plattformar och prestandan påverkas i applikat-ioner som tagits fram med hjälp av ramverk jämfört med native applikation-er[2][19][5].
7
3.2 Implementation
Vid framtagning av applikationerna behövdes olika utvecklingsverktyg för respek-tive plattform. Nedan beskrivs utvecklingsverktygen och de olika mobila platt-formarna.
3.2.1 Xamarin Studio/Visual Studio
Xamarin Studio och Visual Studio är en utvecklingsmiljö som gör det möjligt att utveckla applikationer för iOS, Android och Windows Phone. Xamarin utvecklings-miljö erbjuder plattformar med möjligheten att dela kod. Dock måste gränssnittet programmeras separat eftersom gränssnitten varierar för varje plattform. Android och Windows Phone har till exempel navigationsknapparna på skärmen eller utan-för. iOS skiljs åt med att den bara har en hemknapp och navigationsknapparna på skärmen.
Fördelen med att använda Xamarin är att med programmeringsspråket C#, använda API.er och datastrukturer för att dela ett genomsnitt på 75% av app-likationens kod över iOS, Android och Windows Phone. Byggs användargränssnitt med hjälp av Xamarin.Forms kan nästan 100% av koden återanvändas för respek-tive plattform[30].
3.2.2 Eclipse
Eclipse är en integrerad utvecklingsmiljö som togs fram med hjälp av programme-ringsspråket Java. Java är det primära programmeprogramme-ringsspråket som utvecklare an-vänder för att ta fram java program i Eclipse. Eclipse är framtagen för att vara flexi-bel, plugin program kan installeras i Eclipse för att till exempel stödja ett annat programmeringsspråk än Java.
Programmeringsspråket java används för att utveckla Android applikationer. För att ställa in en arbetsmiljö och börja utveckla Android applikationer i Eclipse krävs det att Android SDK installeras som tillhandahålls av Google. Slutligen be-hövs det installera ADT (Android Development Tool) som är ett plugin som integre-rar Android SDK med Eclipse[7].
3.2.3 Android
Android är ett öppet operativsystem som används i smartphones och surfplattor av OEM(Original Ecuipment Manufacturer)-tillverkare. För att komma igång med Android behövs Android SDK(Software Development Kit) installeras i datorn. Android SDK innehåller allt som behövs för att börja utveckla, testa och debugga en Android applikation. När utveckling av applikation sker behövs en integrerad ut-vecklingsmiljö installeras i datorn. I detta arbete användes Eclipse som utvecklings-verktyg. Android SDK läggs till i Eclipse för att få tillgång till allt som SDKn tillhan-dahåller.
8
Programmeringsspråket som används för att utveckla en android applikation är Java och XML. XML står för Extensibel Markup Language och i Android finns flera XML filer som används för flera olika ändamål i applikationen. Ett använd-ningsområde som XML har i Android kan t.ex. vara att det används för att definiera det verkliga användargränssnittet av applikationen. XML kan kodas direkt av an-vändaren i XML-filerna eller med hjälp av Androids grafiska layoutverktyg som tillå-ter att t.ex. dra in en knapp i layouten. Görs detta genereras även koden för knap-pen automatiskt i XML filen.
En Android applikation är uppbyggt av vyer som innehåller olika objekt. Varje vy i applikationen har en egen klass som innehåller representanter för objekt i vyn. Denna klass kallas för en activity. I Android används en “listener” för varje objekt för att ett objekt ska veta när det ska användas. När en knapp i Android app-likationen används och vill få reda på om den knappen har tryckts eller inte, an-vänds en så kallad “ButtonListener”.
En applikation kan innehålla en eller flera vyer och därmed flera activities. För att användaren ska kunna hoppa mellan olika vyer skapar klassen en intent. En intent är den nuvarande vyn som är aktiv och som användaren ser på telefonen[3].
3.2.4 iOS
IOS är ett operativsystem som används för flera Apple enheter, en av deras viktig-aste enhet är deras telefon som heter Iphone. Den första Iphone modellen släpptes år 2007 av Apples tidigare VD Steve Jobs och denna smartphone tog marknaden med storm.
En skillnad mellan iOS och Android är att iOS endast körs på Apples telefoner och surfplattor medan Android körs av OEM (Original Equipment Manufacturer) tillverkare dvs. ett företag som tillverkar den slutliga produkten som kan säljas på den öppna marknaden. När utvecklare programmerar i iOS används språket Objective-C och detta med hjälp av Cocoa programmeringsmiljön. Objective-C är ett tillägg av det så kallade C-språket och Cocoa miljön är en samling av klasser. Objective-C som själva namnet antyder, stöder objektorienterad programmering. I cocoa miljön programmerar och definieras funktioner, verktyg, koncept, design och programmeringsgränssnitt.
För utveckling i iOS krävs det en dator som kör Mac OS. För att skapa app-likationer i iOS används Xcode. Xcode är utvecklingsverktyg som används för att skapa iOS applikationer. Det som gör xcode till ett effektivt utvecklingsverktyg är att den är integrerad med Cocoa och cocoa touch ramverket. Om allt är väl integre-rade blir xcode en effektiv produktiv miljö där applikationer byggs för de olika en-heterna t.ex. Iphone, Mac, Ipad m.m [13].
9
3.2.5 Windows Phone
Under år 2007 bestämdes sig Microsoft att byta namn på sitt operativsystem ef-tersom att Android och iOS fick allt mer marknadsandelar. För att svara på kon-kurrensen valde Microsoft att bytta namn från Windows mobile till Windows Phone. Programmen som används av Windows Phone är skrivna i .NET managed code. Managed code är en kod som kompilerats för att köras i .NET ramverket som i sin tur används av C# språket. Det som är bra med managed code är att dess körtids-miljö automatiskt vet när den t.ex. ska frigöra minne. Med hjälp av detta är det mycket lättare att skriva bra kod och mindre buggar uppstår.
Windows Phone har två stycken programmerings plattformar, den ena är Sil-verlight och den andra är XNA. SilSil-verlight ger utvecklare möjligheten att förfina an-vändargränssnitt och XNA är Microsoft spelplattform. När det utvecklas i Windows Phone används Visual Studio som utvecklingsverktyg[16][18].
10
3.3 Tillvägagångsätt
Vid utveckling av Xamarin applikationerna valdes tillvägagångssättet Xama-rin.Forms. En Xamarin.Forms applikation är tre separata projekt för Android, iOS och Windows Phone, med ett fjärde projekt som innehåller gemensam kod som de-las mellan plattformarna. Anledningen till att just Xamarin.Forms valdes är att app-likationerna som man får ut kräver lite plattformsspecifik funktionalitet, samt att koddelning här är viktigare än anpassade UI. Detta tillvägagångssätt valdes ef-tersom applikationen som utvecklades inte var särskilt avancerad. Xamarin imple-mentationerna för Windows Phone och Android har inte samma kod. Det som skil-jer projekten åt är bibliotek som innehåller klasser som kallas ”renders” som om-vandlar Xamrin.Forms användargränssnitts objekt till den specifika plattforms an-vändargränssnitt[30].
När Xamarin.Forms applikationen skapades med utvecklingsverktyget Visual Studio och programmeringsspråket C#, skapades också automatiskt en mapp spe-cifikt för Android och Windows Phone. Det skapades även en till mapp som innehåll kod som delades till Android och Windows Phone applikationen. Den delade koden som används av Xamarin implementationerna i Android och Windows Phone är tre klasser. Eventuella ändringar i den delade koden kommer att delas till Android och Windows Phone applikationerna.
Klassen TodoitemPage ser till att initiera textrutan för inmatning av strängar och knapparna för att spara och radera en sträng där dessa kommunicerar med SQLite databasen (se figur 7 och 11). Klassen TodoitemCell används för att lagra strängar som läggs till av användaren (se figur 8 och 12) och som lagras i instans-variabeln label. Klassen TodolistPage skapar en listview och kommunicerar med klasserna TodoitemCell och TodoitemPage. Detta innebär att allt som redigeras eller tas bort både i todoitemCell och TodoitemPage kommer att visas i TodolistPage. En skillnad, och även nackdel, som märktes av vid utveckling av klassen TodolistPage var att plusknappen för Windows Phone och Android var lite annorlunda. Vi var alltså tvungna att skriva separat kod för både Windows Phone och Android eftersom denna kod inte delades med varandra.
Kod som används av applikationerna, men som inte delas gemensamt, är MainActivity och MainPage. MainActivity är för Android vad MainPage är för Win-dowsPhone. För att starta den första Xamarin.Forms layouten på Android omfattar Todo projektet kod som skapar en aktivitet med MainLauncher attributet, med akti-viteten som ärver från FormsApplicationActivity klassen. OnCreate override meto-den initierar Xamarin.Forms ramverket som anropar init() metometo-den. Detta gör att Android-specifik implementation laddas i applikationen först innan hela Xama-rin.forms applikationen laddas. Samma anrop som sker i Mainactivity sker även i MainPage. Todo.WinPhone projektet innehåller kod som ärver från FormsApplicat-ionPage för att starta den första layouten i Xamarin.Forms applikationen. Kon-struktor i MainPage initialiserar Xamarin.Forms ramverket genom att anropa init() metoden. Detta gör att Windows Phone specifik implementation av Xamarin.Forms laddas in först innan hela Xamarin.Forms Windows Phone applikationen laddas in. När tester utfördes för att testa databasen så användes klassen TodoItemPage. En stop watch metod användes för att mäta tiden[17]. Mätningen för att lägga till en sträng görs efter att användaren klickar på spara knappen (se figur 7 och 11).
Mät-11
ningen för att ta bort en sträng görs när användaren klickar på radera knappen (se figur 9 och figur 13).
När Xamarin applikationens uppstartstid skulle testas användes Xamarin pro-filer som är ett verktyg för att analysera en utvecklad applikation som till exempel uppstartstid[31]. Xamarin profiler finns i utvecklingsverktyget Xamarin studio. Med hjälp av Xamarin profiler kunde vi, utifrån grafen som vi fick upp, utläsa uppstarts-tiden. För att testa Xamarin Windows Phone applikationen användes App monito-ring för Windows phone 8 [14]. App monitomonito-ring användes med hjälp av Visual Stu-dio. Det som händer är att App monitoring kontinuerligt analyserar applikationen tills man själv väljer att den ska sluta. Det vi gjorde var att starta App monitoring för att börja analysera och därefter starta applikationen så att App monitoring kunde räkna ut uppstartstiden.
Utvecklandet av native applikationen för Android gjordes med utvecklingsverktyget Eclipse där programmeringsspråket är java. Det som gjordes först var att det skapades ett nytt android projekt. När det skapades så skapades även en MainActivity klass av utvecklingsverktyget automatiskt. I MainActivity klassen finns det kod som skapar en inputdialog (se figur 3) där användaren kan lägga till en sträng eller avbryta om användaren inte vill lägga till en sträng. Om användaren väljer att lägga till en sträng (se figur 4) så sparas strängen i den inbyggda SQLite databasen i Android. Men för att spara och hämta något så behöver databasen först en tabell där det lagras uppgifter i denna, och därför skapades klassen TaskTable. TaskTable klassen definierar konstanter som används för att komma åt data i databasen. Men för att öppna databasen och komma åt data, behövs en hjälpklass som heter TaskDbHelper.
För att testa databasen i native användes Microbenchmarks [11]. Testet valdes att utföras när användaren väljer att lägga till en sträng (se figur 3) och när UI uppdateras. Det valdes också att utföra testet när användaren väljer att ta bort en sträng (se figur 4 och 5) och när UI uppdateras.
För att testa uppstartstiden i android native så installerades android applikat-ionen i telefonen med hjälp av utvecklingsverktyget Eclipse. Det som utförs då är att applikationen installeras och startas upp automatiskt. Det som testas är hur lång tid det tar för applikationen att få upp aktiviteten. Resultatet av testet kan man utläsa från konsol-fönstret i Eclipse:
I/ActivityManager: Displayed com.example.todo/.MainActivity: +461ms.
Därmed kan vi sluta oss till att det tog 461 ms för native applikation att få upp den aktuella aktiviteten.
12
3.4 Redovisning av utvecklade applikationer
I detta avsnitt kommer vi först att redovisa våra utvecklade applikationer i native och Xamarin. Avslutningsvis kommer vi att diskutera utseendemässiga identifie-rade särskiljande aspekter.
3.4.1 Android applikation i native
Figur 2: Visar en blank lista. Figur 3: Visar en input dialog där det kan läggas till något eller avbryta.
Applikationerna som har utvecklats i native och Xamarin är en att göra lista. Me-ningen med dessa applikationer var att hjälpa människor att komma ihåg vad dem ska göra under dagen så att de inte glömmer bort det.
Bilderna som visas ovan är Android applikationen som togs fram med hjälp av native utveckling. Programmeringsspråket som användes vid utvecklingen av app-likationen är Java och här uppstod inte så mycket problem för oss eftersom vi hade kunskap om hur man gör en applikation i Android sedan tidigare. Nedan i punktlis-tan förklaras hur användare interagerar med applikationen.
13
Figur 2 visar en blank lista när applikationen startas från första början. Ska listan fyllas med något värde eller sträng klickas plusknappen längst upp till höger.
I figur 3 kommer det upp en input dialog efter att plusknappen har klickats. Input dialogen ger användaren möjlighet att lägga till något värde eller en sträng men om användaren inte vill lägga till något finns möjligheten att av-bryta detta.
Figur 4: Visar strängen som lagts till. Figur 5: Visar borttagning av strängen.
Figur 4 visar en sträng som har lagts till via input dialogen från figur 3 där användaren fick möjlighet att lägga till något. Väljer användaren att ta bort strängen som har lagts till klickar användaren på knappen klar så försvinner strängen som har lagts till tidigare.
I figur 5 visas en tom lista eftersom användaren valde att klicka på knappen klar i figur 4.14
3.4.2 Xamarin applikation i Android
Figur 6: Visar en blank lista. Figur 7: Visar knappar för spara och raderas.
Bilderna som visas ovan är Xamarin applikationen av android som togs fram med hjälp av ramverket Xamarin. Programmeringsspråket som användes vid utveckling-en av applikationutveckling-en är C#.
Nedan i punktlistan förklaras hur användare interagerar med applikationen.
Figur 6 visar en blank lista när applikationen startats från första början. Väljs det att fylla listan med något värde eller sträng klickas plusknappen längst upp till höger.
I figur 7 visas en ny layout där användaren får möjlighet via textrutan att lägga till ett värde eller en sträng.15
Figur 8: Visar strängen som lagts till. Figur 9: Visar borttagning av strängen.
Figur 8 visar en sträng som har lagts till via layouten från figur 7 där använ-daren fick möjligheten att lägga till något.
Väljer användaren att ta bort strängen som har lagts till trycker användaren på strängen för att kunna få upp layouten som visas i figur 9. Trycker an-vändaren på spara knappen igen händer ingenting med strängen i listan om inte användaren väljer att ändra text strängen och sedan klicka på att spara. Väljs strängen att tas bort från listan klickar användaren radera knappen och då försvinner strängen.
16
3.4.3 Xamarin applikation i Windows Phone
Figur 10: Visar en blank lista. Figur 11: Visar knappar för spara och rade-ras
Figur 10 visar en blank lista när applikationen startats från första början. Väljer användaren att fylla listan med något värde eller sträng klickar an-vändaren på plusknappen längst ner på applikationen.
I figur 11 visas en ny layout där användaren får möjlighet via textrutan att lägga till ett värde eller en sträng.17
Figur 12: Visar strängen som lagts till. Figur 13: Visar borttagning av strängen.
Figur 12 visar en sträng som användaren har lagt till via layouten från figur 11.
Väljer användaren att ta bort strängen som har lagts till trycker användaren på strängen för att kunna få upp layouten som visas i figur 13. Trycker an-vändaren på spara knappen igen händer ingenting med strängen i listan om inte användaren väljer att ändra text strängen och sedan klicka på att spara. Väljer användaren att strängen tas bort från listan klickar användaren på radera knappen försvinner strängen.
18
3.4.4 Design skillnader i applikationerna
Som nämnt tidigare i detta avsnitt finns det några få skillnader mellan applikation-erna. Den mest märkbara skillnaden i native Android och Xamarin Android är att i native Android får användaren upp en dialogruta. Detta ska ställas i kontrast till Xamarin Android applikationen där en ny layout kommer upp. Detta sker när an-vändaren klickar på plus-knappen (se figur 14 och figur 15 nedan).
Figur 14: Native Android Figur 15: Xamarin Android
Figur 16: Xamarin Windows phone Figur 17: Xamarin Android
Ytterligare en skillnad mellan Xamarin Windows Phone och Xamarin Android är att plus-knappen i Windows Phone är placerad längst ner i applikationen. Detta ska ställas i kontrast till Xamarin Android där denna är placerad längst upp till höger (se figur 16 och figur 17 ovan).
Orsaken till att det kommer upp en layout i Xamarin istället för dialogruta i native Android beror på standard användargränssnittet för dessa två plattformarna. Skillnaden är att i native Android, när vi ska ta bort en sträng räcker det med att klicka på klar knappen men för att ta bort en sträng i Xamarin applikationen måste
19
vi klicka på strängen och sen radera den i layouten som kommer upp. I slutändan utför applikationerna samma sak.
3.5 Resultat av tester
Med hjälp av vår praktiska studie som resulterade i tre framtagna applikationer kan vi nu göra den utvärdering av särskiljande aspekter som formulerades i forsknings-frågorna. Bland annat har prestandan vid uppstart av applikationerna och app-likationsstorleken kunnat utvärderas. Det har även gjorts tester för den inbyggda SQLite databasen för att se om det här finns någon skillnad mellan native i Android jämfört med Xamarin. För android har Sony Xperia Z med Android version 5.1.1 använts. För Windows Phone har Nokia Lumia 920 med Windows Phone version 8.1 använts vid utveckling och utvärdering av applikationerna.
Tid för uppstart av applikation Xamarin android
applikat-ion Android native applikation Xamarin Windows Phone applikat-ion Ca 3,298 sekunder Ca 0,461
se-kunder Ca 0,73 sekunder
Tabell 1: Visar tiden för uppstart
Testerna för uppstartstiden gjordes med hjälp av utvecklingsverktygen; för Android användes Eclipse och för Xamarin användes Xamarin Studio. Tabell 1 ovan visar att Xamarin i android tar längre tid att starta än native applikationen. Windows ap-plikationen i Xamarin är dock nästan lika snabb som native android apap-plikationen.
Storlek i MegaByte (MB) Xamarin android
applikat-ion Android native applikation Xamarin Windows Phone applikat-ion
63,80 MB 4,68 MB 9,45 MB
Tabell 2: Visar applikationsstorleken
För att hitta en applikations storlek i Android går man först in i Inställningar -> Ap-par -> Välj den applikationen som man vill undersöka i listan. I Windows Phone väljer man Inställningar -> Storage sense -> Telefon -> appar + spel -> Välj den app-likation som man vill undersöka i listan. Testerna för appapp-likationsstorleken gjordes i Release mode dvs. när applikationerna installerades med utvecklingsverktyget Eclipse för native Android och för Xamarin Visual/Xamarin Studio. Tabell 2 ovan visar att Xamarin applikationen i Android tar mer plats i megabyte jämfört med na-tive applikationen. Windows Phone applikationen i Xamarin är 1/6 mindre än Xamarin Android applikationen men dubbelt så stor som native Android applikat-ionen som är ca 5 MB.
20
Prestandamätning för databasen i (ms)
Plattform Android native Xamarin
Lägg till en sträng 31 29
Lägg till tre strängar 65 66
Ta bort en sträng 27 40
Ta bort 3 tre strängar 87 89
Total lägga till 96 95
Total ta bort 114 129
Tabell 3: Visar Prestandamätningen i ms för databasen
Tabell 3 ovan visar resultatet från våra tester som har gjorts på den inbyggda SQLite databasen. Det som testades med applikationerna var att lägga till en sträng för att se hur lång tid det tar för respektive applikation att utföra kommandot. Re-sultatet ovan säger oss att det inte skiljer sig så mycket åt när det läggs till strängar. Xamarin halkar dock efter när man tar bort en sträng, men kommer ikapp när man tar bort 3 strängar.
21
4 Analys och diskussion
Examensarbetet började med att vi tog kontakt med ett konsultföretag i Malmö. Hos konsultföretaget fick vi i uppgift att identifiera om det finns fördelar att utveckla applikationer i Xamarin jämfört med att utveckla i native. Vi skulle snabbt få pro-blem med företaget eftersom vi inte kom överens om vilka applikationer vi skulle utveckla på grund av tidsmässiga och kunskapsmässiga brister inom det för oss helt nya området Xamarin. Till slut kom vi överens om att utveckla mindre app-likationer och det är dessa som ligger till grund för att identifiera särskiljande aspekter och fördelar respektive nackdelar med Xamarin.
Vi kom snabbt igång med att utveckla Android applikationen i native eftersom vi sedan tidigare har kunskap inom detta område från tidigare kurser i utbildning-en. Utvecklingsmiljön för att utveckla i Java hade vi installerat sedan tidigare. In-nan vi kunde börja utveckla i Xamarin behövdes utvecklingsverktyget installeras. Här uppstod det lite problem eftersom utvecklingsverktyget kostade pengar och var dyrt så istället fick vi nöja oss med en 30 dagars testversion. Innan det gick att in-stallera testversionen från Xamarins hemsida var man tvungen att uppge sin e-post-adress. Efter att vi installerat testversionen fick vi ett mejl från en person som jobbade för Xamarin. Den här personen skrev i mejlet att om det är något som vi undrade över, var det bara att mejla tillbaka. Vi valde att kontakta den här perso-nen och berätta att vi är två studenter som håller på att skriva ett examensarbete och att vi gärna vill använda Xamarin i mer än 30 dagar, eftersom detta inte kom-mer räcka för oss. Han svarade att vi skulle gå via Dreamspark och ladda ner det därifrån. Men eftersom den inte fanns i Sverige var vi tvungna att gå via Dreamspark i USA där vår inloggning från Malmö högskola inte fungerade. Istället bad den här personen oss att skicka in ett intyg till dem i USA så att de kunde be-kräfta att vi är studenter på Malmö högskola. När detta var löst fick vi ett mejl där vi kunde ladda ner fullversionen av Xamarin.
När vi skulle börja utveckla i Xamarin tog det lite tid tills vi kom igång. Som tidigare nämnts så var ramverket och programmeringsspråket här nytt för oss. Där-för gick vi ut på nätet Där-för att samla in information och bekanta oss med Xamarin. Lyckligtvis tillhandahåller Xamarin en pdf för nybörjare för att komma igång med utvecklingsverktyget [15]. Applikationerna som utvecklades i Xamarin upplevde vi som svårutvecklade, på grund av att det var ett nytt programmeringsspråk för oss och det var även svårt att förstå hur allt hänger ihop i Xamarin.
Med hjälp av Android applikationen i native och Xamarin applikationen i Android och Windows Phone, har vi gjort tester som visar att det finns skillnader mellan dem. Det första vi testade på applikationerna var uppstartstiden och tittar man på tabell 1 kan man snabbt utläsa att native android applikationen startar mycket snabbare jämfört med Xamarin android applikationen. Windows Phone app-likationen är 0,269 ms slöare i uppstart jämfört med native Android appapp-likationen. Uppstartstiden är självklart till native applikationens fördel då den är skriven i Java vilket är vad Android är byggt på. C# kod kan inte användas i Java samma gäller för Java som inte kan användas i C#. Därför kräver Xamarin mer för att kunna köra applikationen i Android med C# än vad Java kräver i native. Våra erhållna re-sultat med avseende på uppstartstiden kan vi nu jämföra med tidigare forskningen, vilken också kommit fram till att uppstartstiden är till natives fördel [1][8].
22
När det kommer till applikationsstorleken så kan man också se likheter med vad som gällde för uppstartstiden. Enligt Tabell 2 så ser vi att native android app-likationen endast har en storlek på 4,68 Mb, detta ska ställas i kontrast till hela 63,80 MB för Xamarin Android versionen. Vidare så gäller det att Windows Phone applikationen är dubbelt så stor som native Android applikationen, dock är den mindre än Xamarin Android applikationen. Det vi alltså kan utläsa är att Xamarin Windows applikationen inte är långt ifrån native Android applikationen när det gäl-ler applikationsstorlek och uppstartstid. Orsaken till detta är att Xamarin använder sig av C# som programmeringsspråk, vilket ju är Windows Phone native språk. Re-sultatet från applikationsstorleken kan vi också jämföra med tidigare forskning där även denna har visat sig vara till natives fördel [8].
De två första testerna visade att det finns skillnader mellan native Android och Xamarin. Därför valde vi att utföra en tredje test där vi ville testa om det finns lik-heter. Tester utfördes på den inbyggda SQLite databasen som operativsystemen an-vänder. När vi utförde testerna så startade vi om telefonerna och undersökte så att det inte fanns andra körande program i telefonen eftersom detta hade kunnat på-verka resultatet. Från Tabell 3 kan vi utläsa att operationerna att lägga till en sträng i native och i Xamarin respektive är nästan identiska med avseende på tidsaspekten. Samma gäller när vi lägger till tre strängar; då blir resultatet i stort sett identiskt med bara 1 ms som skiljer dem åt. Det enda resultatet som särskiljer Android i native och Xamarin är när vi väljer att utföra operationen ta bort en sträng i databasen. Där är native hela 13 ms snabbare än Xamarin. Men väljer man att ta bort tre strängar från databasen får vi återigen nästan identiska resultat, där native har övertaget med endast 2 ms. Tittar vi på det totala värdet att lägga till i native Android och Xamarin får vi ett resultat som skiljer sig med endast 1 ms. Det totala resultatet att ta bort blev till natives fördel med 15 ms övertag, dock är det värt att notera att detta beror på att Xamarin tappade när man tog bort en sträng.
De här resultaten säger oss mycket, nämligen att prestandan och app-likationsstorleken påverkas om man väljer att utveckla med ramverket Xamarin. Men tittar man på att utföra något i applikationen, som i vårt fall när vi testade op-erationerna att lägga till och ta bort i databasen, så ser vi att resultatet är så när som identiska med bara några millisekunders skillnad.
Nu i efterhand när vi har utvecklat applikationer i ramverket Xamarin under projektets gång är den generella uppfattningen att med hjälp av Xamarin sparas både tid och resurser. I början av projektet när vi läste om Xamarin fick vi känslan av att all kod som skrivs i C# kommer översättas till plattformarna men så var inte fallet. Visst, mer än 95% av vår kod översattes men det var fortfarande lite kod som man var tvungen att skriva för respektive plattform för att applikationen skulle fun-gera. Till exempel, i klassen TodoListPage var vi tvungna att skriva kod för att verk-tygsfältet (Toolbar) i applikationen skulle visas. Att dra alltför generella slutsatser om Xamarin är inte heller rätt för Xamarin har både för- och nackdelar. Vi känner att fördelarna nog kan uppväga nackdelarna. I slutändan handlar allt om vad för slags applikation man ska ta fram. Är man intresserad att fokusera på en plattform är självklara valet native. Men vill man nå ut till de tre största mobila plattformarna är Xamarin det bättre valet för då kan man med samma källkod nå ut till alla tre.
23
5 Slutsats och vidare forskning
Med hjälp av vår första forskningsfråga och den tidigare forskningen inom området kan vi nu dra slutsatsen att resultaten från testerna visar att utveckla applikationer med hjälp av ramverket Xamarin påverkar prestandan vid uppstart och app-likationsstorleken jämfört med att utveckla i native. När exekveringstiden testades för att lägga till en och tre strängar i databasen så visade resultatet att dessa var nästintill identiska med bara 1 ms skillnad, med undantag av när det togs bort en sträng för då var Android native snabbare än Xamarin. Detta besvarar även vår andra forskningsfråga där vi nu har identifierat några särskiljande aspekter.
Vår studie visar att om ett företag väljer att utveckla specifikt för exempelvis Android så är det en fördel att använda native vid utvecklingsprocessen eftersom man då får ut en applikation som utnyttjar operativsystemets fulla potential. Har företaget istället ambitionen att få ut sin applikation till flera plattformar, men har tidsbrist och vill täcka så stor målgrupp som möjligt så är det en fördel att utveckla i Xamarin. Detta besvara vår tredje och sista forskningsfråga där fördelar och nackdelar skulle identifieras.
Vi känner att de avgränsningar vi gjort i vårt arbete, och som vi efter pro-jektets gång kommit att revidera, ledde till en lagom omfattande implementation för vår studie. Vi har med denna erhållit resultat som på ett tydligt sätt visar skillnader mellan prestanda och mellan vad man får ur de olika utvecklingsmiljöerna. Vår undersökning skulle egentligen endast fokusera på Android utveckling, men i verk-tyget Xamarin fick vi också möjligheten att testa samma kod under Windows Phone.
Sammanfattningsvis upplever vi att våra erhållna resultat tydligt avspeglar det vi hade som avsikt att undersöka. Våra erhållna resultat pekar inte på att någon plattform är den bästa, utan mer att de istället har sina respektive fördelar.
Vi tycker att i framtida forskning så bör en mac dator finnas tillgänglig för att utveckla i native iOS och testa Xamarin implementationen i iOS. Vi tycker även att man borde utföra tester i native Windows Phone för att få fram fler jämförelser mel-lan operativsystemen. Det hade också varit mycket intressant att utföra intervjuer på specialister som arbetar på företag inom applikationsutveckling. Det hade varit intressant att här undersöka vad de tycker är bäst att utveckla i.
24
6 Referenser
[1] Willocx M, Vossaert J, Naessens V.
A Quantitative Assessment of Perfor-mance in Mobile App Development Tools. IEEE Software. 2015;32(3):3-6.[2] Palmieri M, Singh I, Cicchetti A.
Comparison of Cross-Platform Mobile De-velopment Tools. 2012 16th International Conference on Intelligence in Next Gener-ation Networks, ICIN 2012. 2012:179-186.[3] Android Developers. Introduction to Android [Internet]. 2016 [Citerad 2016 Feb 12]. Hämtad från: http://developer.android.com/guide/index.html
[4] Hui N, Chieng L, Ting W, Mohamed H, Hj Mohd Arshad M. Cross-platform mo-bile applications for android and iOS. Proceedings of 2013 6th Joint IFIP Wireless and Mobile Networking Conference, WMNC 2013. 2013:2-5.
[5] Charkaoui S, Adraoui Z, Habib Benlahmar E. Cross-platform mobile develop-ment approaches. IEEE. 2014:188-191.
[6] DigitasLBi. En digital kommunikatonsbyrå [Internet]. 2014 [Citerad 2016 Feb 09]. Hämtad från: http://www.digitaslbi.com/se/
[7] Eclipse. Eclipse – The Eclipse Foundation open source community website [In-ternet]. 2016 [Citerad 2016 Feb 13]. Hämtad från: https://eclipse.org/
[8] El-Kassas W, Abdullah B, Yousef A, Wahba A. Enhanced Code Conversion Ap-proach for the Integrated Cross-Platform Mobile Development (ICPMD). IEEE Transactions on Software Engineering. 2016;5589(c):1-20.
[9] Patel R, Davidson B. Forskningsmetodikens grunder: Att planera, genomföra och rapporterna en undersökning. 4 rev. Uppl. Lund: Studentliteratur; 2011.
[10] Sambasivan D, John N, Udayakumar S, Gupta R. Generic framework for mo-bile application development. 2011 Second Asian Himalayas International Confer-ence on Internet (AH-ICI). 2011:1-5.
[11] Oaks S. Java Performance: The Definitive Guide [Internet]. 2016 [Citerad 2016 Jul 11]. Hämtad från:
http://185.49.84.138/ebooks/Java-Performance_The-Definitive-Guide.pdf
[12] Insight Africa UK. Action Research Challenges. [Internet]. 2015 [Citerad 2016 Apr 14]. Hämtad från:
http://www.insightafricauk.co.uk/action-research-challenges/
[13] Mac Developer Library. About Objective-C [Internet]. 2016 [Citerad 2016 Feb 18]. Hämtad från:
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Prog rammingWithObjectiveC/Introduction/Introduction.html
[14] Microsoft. App monitoring for Windows Phone 8 [Internet]. 2016 [Citerad 2016 Jul 11]. Hämtad från:
25
[15] Microsoft. Creating Mobile Apps with Xamarin.Forms [Internet]. 2016 [Citerad 2016 Mar 14]. Hämtad från:
https://blogs.msdn.microsoft.com/microsoft_press/2016/03/31/free-ebook-creating-mobile-apps-with-xamarin-forms/
[16] Microsoft. .NET – Powerful Open Source Cross Platform Development [Internet]. 2016 [Citerad 2016 Feb 24]. Hämtad från: https://www.microsoft.com/net/
[17] Microsoft. Stopwatch Class (System.Diagnostic) [Internet]. 2016 [Citerad 2016 Jul 11]. Hämtad från:
https://msdn.microsoft.com/en-us/library/system.diagnostics.stopwatch(v=vs.110).aspx
[18] Microsoft. What Is Managed Code? [Internet]. 2016 [Citerad 2016 Feb 25]. Hämtad från:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb318664(v=vs.85).aspx
[19] Smutny P. Mobile development tools and cross-platform solutions. Proceedings of the 2012 13th International Carpathian Control Conference, ICCC 2012. 2012:653-656.
[20] Mälardalens Högskola Eskilstuna Västerås. Primär och sekundär data [Inter-net]. 2016 [Citerad 2016 Apr 25]. Hämtad från:
http://www.mdh.se/student/minastudier/examensarbete/omraden/metoddoktorn /soka-information/primara-och-sekundara-data-1.27203
[21] Delia L, Galdamez N, Thomas P, Corbalan L, Pesado P. Multi-Platform Mobile Application Development Analysis. IEEE Software. 2015:0-5.
[22] PC MAGAZINE. Smartphone definition from PC Magazine Encyclopedia [Inter-net]. 2016 [Citerad 2016 Feb 18]. Hämtad från:
http://www.pcmag.com/encyclopedia/term/51537/smartphone
[23] Ahuja H, Johari R. Optimization of the issues in the migration from Android Native to Hybrid Application: Case study of Student's Portal application. Proceed-ings of the 2014 International Conference on Advances in Computing, Communica-tions and Informatics, ICACCI 2014. 2014:245-249.
[24] Statista. The Statistics Portal [Internet]. 2016 [Citerad 2016 Feb 20]. Hämtad från: http://www.statista.com/statistics/330695/number-of-smartphone-users-worldwide/
[25] Jones C, Jia X. The AXIOM model framework: Transforming requirements to native code for cross-platform mobile applications. IEEE. 2014:26-37.
[26] Boushehrinejadmoradi N, Ganapathy V, Nagarakatte S, Iftode L. Testing Cross-Platform Mobile App Development Frameworks. Ase. 2015:441-451.
[27] Wikipedia. Action research [Internet]. 2016 [Citerad 2016 Feb 18]. Hämtad från: https://en.wikipedia.org/wiki/Action_research
[28] Xamarin Inc. Installing Xamarin.iOS on Windows [Internet]. 2016 [Citerad 2016 Feb 10]. Hämtad från:
https://developer.xamarin.com/guides/ios/getting_started/installation/windows/ [29] Xamarin Inc. Mobile App Development & App Creation Software - Xamarin [Internet]. 2016 [Citerad 2016 Feb 10]. Hämtad från: https://www.xamarin.com/
26
[30] Xamarin Inc. Mobile Application Development to Build Apps in C# - Xamarin [Internet]. 2016 [Citerad 2016 Feb 10]. Hämtad från:
https://www.xamarin.com/platform
[31] Xamarin Inc. Xamarin Profiler - Analyze and polish your C# mobile apps - Xamarin [Internet]. 2016 [Citerad 2016 Jul 11]. Hämtad från:
27
7 Bilagor
7.1 Bilaga 1
Databas Sökord Antal träffar
IEEE Android 5132
IEEE ”Android” 4639
IEEE ”Android” cross-platform 72
IEEE ”Android” ”cross-platform” 51
IEEE iOS 855
IEEE ”iOS” 855
IEEE ”iOS” cross-platform 27
IEEE ”iOS” ”cross-platform” 25
IEEE windows phone 444
IEEE ”windows phone” 91
IEEE ”windows phone” cross-platform 6 IEEE ”windows phone” ”cross-platform” 6
IEEE Framework 158,301
IEEE ”framework” 154,107
IEEE ”framework” Android 612
IEEE ”framework” ”Android” 561
IEEE ”framework” ”Android” cross-platform 14 IEEE ”framework” ”Android” ”cross-platform” 12
28
Data-bas Sökord Antal träf-far
ACM Android 1766
ACM ”Android” 1766
ACM ”Android” cross-platform 45,075 ACM ”Android” ”cross-platform” 2047
ACM iOS 3624
ACM ”iOS” 3624
ACM ”iOS” cross-platform 46,642
ACM ”iOS” ”cross-platform” 3909
ACM windows phone 10,135
ACM ”windows phone” 56
ACM ”windows phone”
cross-platform 44,029
ACM ”windows phone”
”cross-platform” 348
ACM Framework 38,311
ACM ”framework” 38,311
ACM ”framework” Android 39,748
ACM ”framework” ”Android” 39,748
ACM ”framework” ”Android” cross-platform
77,601
ACM ”framework” ”Android”
”cross-platform” 40,018
29
Databas Sökord Antal
träffar
IEEE Native application 1754
IEEE ”Native application” 24
IEEE ”Native application” Android 6
IEEE ”Native application” ”Android” 6
IEEE ”Native application” framework 5
IEEE ”Native application” ”framework” 5
IEEE Native application” ”framework” android 2
IEEE Native application” ”framework” ”android” 2 IEEE Native application” ”framework” ”android” ios 1 IEEE Native application” ”framework” ”android” “ios” windows
phone 72
IEEE Native application” ”framework” ”android” “ios” “windows
phone” 58
IEEE ”Multiplatform””android””ios””Windows phone” 267 IEEE Native application” ”framework” ”android” “ios” “windows
phone” “cross-platform” 61
30
Databas Sökord Antal
träf-far
ACM Native application 138,239
ACM ”Native application” 43
ACM ”Native application” Android 1803
ACM ”Native application” ”Android” 1803
ACM ”Native application” framework 38,409
ACM ”Native application” ”framework” 38,409
ACM “Native application” ”framework” android 39,841 ACM “Native application” ”framework” ”android” 39,841 ACM “Native application” ”framework” ”android” ios 42,946 ACM “Native application” ”framework” ”android” “ios” windows
phone 51,598
ACM “Native application” ”framework” ”android” “ios” “windows
phone” 42,946
ACM ”Multiplatform” ”android” ”ios” ”Windows phone” 5305 ACM Native application” ”framework” ”android” “ios” “windows
phone” “cross-platform” 43,170
31
32
7.2 Bilaga 2
33
Figur 19: Bild som visar klassen TodoItemPage första delen.
34
35
36
Figur 23: Bild som visar klassen MainPage.
![Figur 1: En övergripande summerande beskrivning av metoden action research [12].](https://thumb-eu.123doks.com/thumbv2/5dokorg/4020286.81801/11.892.130.367.200.426/figur-övergripande-summerande-beskrivning-metoden-action-research.webp)
