EXAMENSARBETE Utveckling av en lättförvaltad mobilapplikation Irina Malaya 2015 Filosofie kandidatexamen Systemvetenskap Luleå tekniska universitet Institutionen för system- och rymdteknik
SAMMANFATTNING Mobiltelefoner är idag en het teknologi och det blir fler och fler företag som väljer att presentera sig själva även mobilt för att på så sätt nå fler kunder. På marknaden finns en mängd av olika typer av mobiler vilket kan orsaka svårigheter för ett företag att komma ut med sin mobilapplikation då olika typer av mobiler ställer olika tekniska och kunskapskrav på företaget som utvecklar applikationen. En alternativ lösning kan vara en hybridmobilapplikation som gör det möjligt att ta fram applikationer för olika typer av mobilenheter baserad på samma kod- bas. I denna rapport har jag tagit fram en prototyp av en hybridmobilapplikation för ett BI konsultbolag. Applikationen skapades i enlighet med Kanban metodologi och använde sig av ramverket Ionic. Den skapade mobilapplikationen presenterar ekonomisk data i form av tabeller och diagram och har även interaktiva delar. För att höja kvalitet på koden och underlätta den framtida förvaltningen försågs applikationen med automatiska tester. Nyckelord: mobila applikationer, mobilapplikationsutveckling, hybrida mobilapplikationer, Ionic Ramverk
ABSTRACT Mobile phones are a hot technology today and a lot of companies choose to present themselves in a mobile format in order to reach more customers. On the market there are a variety of different types of mobile phones, which may cause difficulties for the company to come out with its mobile application as different types of phones have different technical and knowledge requirements. An alternative solution may be a hybrid mobile application that makes it possible to produce applications for various types of mobile units based on the same code base. In this report, I have developed a prototype of a hybrid mobile application for a BI consulting company. The application was created in accordance with Kanban methodology and used the Ionic Framework. The created mobile application presents economic data in the form of tables and charts and also has interactive features. To raise the quality of the code and make the future management of the application easier the application was supplied with automatic tests. Keywords: mobile applications, mobile application development, hybrid mobile applications, Ionic Framework
INNEHÅLL 1 INLEDNING... 1 1.1 PROBLEMSTÄLLNING... 1 1.2 SYFTE... 2 1.3 AVGRÄNSNINGAR... 3 1.4 STRUKTUR AV UPPSATSEN... 3 2 TEORI... 5 2.1 NATIVA MOBILA APPLIKATIONER... 5 2.2 MOBILA WEBBAPPLIKATIONER... 6 2.3 HYBRIDA MOBILA APPLIKATIONER... 7 2.4 IONIC... 9 2.4.1 IONIC RAMVERK... 10 2.4.2 ANGULARJS... 10 2.4.3 CORDOVA... 10 2.4.4 IONIC KOMPONENTERS SAMARBETE... 10 2.4.5 KUNSKAPSKRAV... 11 2.4.6 TEKNISKA KRAV... 11 2.4.7 KOSTNADER... 12 2.5 OPEN SOURCE... 12 2.6 TESTNING... 14 2.7 TESTA IONIC... 15 3 METOD... 17 3.1 SYSTEMUTVECKLINGSMETOD... 17 3.2 KANBAN I ARBETET... 18 3.3 UTVECKLA MED IONIC... 19 3.4 SKAPA MOBILAPPLIKATION FÖR IOS MED IONIC... 21 3.5 SKAPA MOBILAPPLIKATION FÖR ANDROID MED IONIC... 22 3.6 ARKITEKTUR... 24 3.7 DIAGRAM... 26 4 RESULTAT... 28 4.1 UPPDRAGSBESKRIVNING... 28 4.2 APPLIKATIONSBESKRIVNING... 29 4.3 TESTNING... 37 5 ANALYS... 42 5.1 FUNKTIONELLA MÅL... 42 5.2 TEKNISKA MÅL... 45
6 DISKUSSION OCH SLUTSATSER... 46 6.1 ALTERNATIVA LÖSNINGAR... 46 6.2 FÖRSLAG PÅ FORTSATT ARBETE... 47 6.3 FÖRSLAG PÅ FORTSATT FORSKNING... 48 REFERENSER... 49
BEGREPP Back- end består av server, applikation och databas. (Long, 2012) Business Intelligence (eller BI) är ett samlingsnamn som hänvisar till en mängd olika program som används för att analysera en organisations data. (Mulcahy, 2007) Front- end är den delen av webbapplikation som användaren kan interagera med. (Long, 2012) jquery är mest populära JavaScript bibliotek. jquery underlättar anrop och modifiering av element på webbsidan (bilder, länkar etc), hantering av händelser (t.ex. klick), modifikationer av CSS och även generering av effekter och animationer. (Webbdesignguiden, u.å.) JSON (JavaScript Object Notation) är en lätt datautbytesformat. Det är lätt för människor och maskiner att läsa och skriva. (Introducing JSON, u.å.) JSON objekt är en oordnad kollektion av namn / värde par. Dess yttre form är en sträng insvept i klammerparenteser med kolon mellan namn och värderingar, och kommatecken mellan värdena och namn. Fördelen med JSON objekt är att det är lättolkat av JavaScript som används i webbläsare. (Introducing JSON, u.å.) Open Source är en mjukvara som kan modifieras. Det ger mer kontroll till användaren då han/hon kan förändra del av koden och kan använda koden till syfte han/hon vill och inte bara den som kod författaren hade tänkt sig. (Discover an open source world, u.å.) Prototyp med andra ord är första exemplar, urtyp, urbild, grundform, mönster, mall, likare, modell, förebild. (Strömberg, 2000) Webbtjänst är en teknik som gör det möjligt att kommunicera mellan olika program och tekniska lösningar. (Service Architecture, u.å.)
1 INLEDNING Mobiltelefoner har kommit att ta en stor del i vårt liv och nuförtiden kan man se människor som surfar/spelar eller använder olika slags mobilapplikationer överallt. Oftast är det de som har lite ledig tid t.ex. på bussar, i kö eller i väntan på någon. Detta på grund av att telefoner blivit mer kraftfulla vilket gör det möjligt att utöka användningsområdet för mobiler. McWherter och Gowell (2012) anser att mobila applikationer är den hetaste teknologin efter att webbsidor blev populära under dot- com eran i slutet av 1990- talet. Det är många företag som har märkt de stora möjligheterna som mobilapplikationer kan ge och det blir fler företag som väljer att etablera sig mobilt. Church (2012) hävdar att mobilapplikationer är här att stanna och det blir viktigare och viktigare att byta från en traditionell skrivbordupplevelse till en mobilenhetsupplevelse. 1.1 PROBLEMSTÄLLNING Wasserman (2010) påstår att utveckling av mobilapplikationer är lik utveckling av traditionella applikationer för bordsdatorer. Vanliga frågor som tas upp vid applikationsutveckling är bland annat integration med enhetens hårdvara, säkerhet, prestanda, tillförlitlighet och diskstorlek. Eftersom mobilenheter har egenskaper som skiljer sig från en vanlig bordsdator ger det fler möjligheter vid utvecklingen men orsakar samtidigt fler problem som måste tas om hand om. Enligt Wasserman (2010) är några av de problem som man borde ta hänsyn till följande: Interaktion med andra applikationer. Mobilenheter har mängder av applikationer från olika källor och dessa applikationer kan interagera med varandra. Hantering av inbyggda sensorer. Mobilenheter inkluderar accelerometer som svarar på enhetens rörelser, pekskärm, riktigt eller virtuellt tangentbord, ett globalt positioneringssystem, en mikrofon som kan användas inte bara för samtal men även av andra applikationer, samt en eller flera kameror. Mobilapplikationer delar gemensamma element i användargränssnittet med andra applikationer och måste följa externt utarbetade riktlinjer för användargränssnitt. Mobilapplikationer kan också vara svårare att testa då man även skall verifiera överföring via telefonnätet. Mobilapplikation använder mobilenhetens batteri och därmed påverkar enhetens batteritid. Traditionell mobilapplikationsutveckling inriktar sig på en specifik mobilplattform. Detta innebär stora svårigheter vid utvecklingen, såsom användning av olika utvecklingsmiljöer, tekniker och APIn (Application Programming Interface) för respektive mobilplattform, vilket leder till oundvikligt slöseri med utvecklingstid och 1
resurser och ökar förvaltningskostnaden om man vill leverera sin mobilapplikation för mer än en plattform. (Xanthopoulos & Xinogalos, 2013) McWherter och Gowell (2012) hävdar att det finns fyra stora utvecklingsplattformar för mobilapplikationer och beskriver grundläggande krav för utveckling för dessa enheter: BlackBerry. BlackBerry används oftast i utbildning och av regering (främst i USA). BlackBerry är skriven i Java och verktyg för att utveckla BlackBerry applikationer kan enbart köras på Windows. iphone. iphone är ett av de mobilmärken som används mest. Deras operativsystem heter ios och är en teknologi som körs på Apples mobiler, bas- språket är Objektiv- C alternativt Swift. ios kan utvecklas bara med Apple s XCode, som enbart kan köras på Mac. Android. Android är det vanligaste mobiloperativsystemet. Androids ramverk är skriven in Java och kan utvecklas i Java verktyg. Android rekommenderar dock Java Eclipse med Android toolkit. Android kan utvecklas på PC, Mac eller Linux. Windows Phone. Windows Phone är en relativ nykomling och används mest av utvecklare och har inte blivit jättepopulär än. För Windows Phone skall C# med.net ramverk användas och Windows Phone verktyg körs bara på Windows. Det stora antalet av mobilplattformar gör mobilapplikationsutveckling svårt för ett företag som då behöver utveckla samma applikation för varje målplattform. Traditionell mobilapplikationsutveckling är det lämpligaste sättet att distribuera mobila applikationer, men har en stor nackdel: det är inte möjligt att återanvända källkoden för en annan plattform. För att göra samma applikation tillgänglig för en annan plattform måste applikationen byggas om från grunden. (Xanthopoulos & Xinogalos, 2013) Om man gör en sammanställning av kraven beskrivna ovan behöver en utvecklare, för att göra en applikation tillgänglig till de flesta användare, kunna flera olika programmeringsspråk, ha flera olika arbetsdatorer (Mac och Windows) och förstå ett flertal olika utvecklingsverktyg. Heitkötter, Hanschke och Majchrzak (2013) säger att ett stort antal mobilplattformar gör mobilapplikationsutveckling utmanande och kostsam. Detta gör det svårt för ett företag att skapa och underhålla mobilapplikationer och skapar ett behov av enklare ramverk för utveckling av dem. Xanthopoulos och Xinogalos (2013) hävdar att det bästa alternativet för ett företag är plattformsoberoende mobilutveckling. Plattformsoberoende utveckling förenklar förvaltning och distributionsprocesser samt sparar utvecklingstid och resurser. 1.2 SYFTE Mitt arbete utförs åt ett företag som jobbar inom Business Intelligence och som vill skapa en BI- applikation som byggs på Open Source programvara. Min uppgift är att skapa en prototyp på en mobilapplikation för ios och Android som integrerar med 2
företagets befintliga BI- system. Eftersom det är tidskrävande att underhålla flera olika mjukvaruprojekt vill företaget ha samma kod- bas för alla. Jag har därför fått i uppgift att undersöka ett plattformsoberoende ramverk som heter Ionic, som kan generera mobilapplikationer för ett flertal plattformar. Syftet med mitt arbete är att med hjälp av Open Source programvara skapa en fungerande och lättförvaltad prototyp på en mobilapplikation inom Business Intelligence som fungerar för ios och Android. I arbetet skall jag även undersöka ett nytt plattformsoberoende verktyg Ionic ramverk och se om det är praktiskt möjligt att skapa den beställda applikationen med hjälp av detta ramverk. Utifrån problemställning och uppsatssyfte kommer jag fram till en generell forskningsfråga som jag kan definiera på följande sätt: hur skapar man en lättförvaltad mobilapplikation? Denna fråga är allmän och kan tolkas på olika sätt av olika individer. För att ange tydliga gränser till fokus i min uppsats vidareutvecklar jag och specificerar denna frågeställning med hjälp av följande frågor: Hur skapar man mobilapplikationer för olika operativsystem med samma kod- bas? Hur skriver man automatiska tester för mobilapplikationer? 1.3 AVGRÄNSNINGAR Eftersom det är iphone och Android mobiltelefoner som används mest begränsar jag mitt arbete till enbart dessa två typer av mobilenheter. Att skapa en mobil applikation är en komplicerad uppgift därför har jag begränsat mig till att enbart utveckla en front- end och bortse från back- end och webbtjänster som skall behöva användas för att länka ihop front- end med back- end. Syftet med detta arbete är att skapa en prototyp och se om det går att utveckla önskad funktionalitet. I uppgiften bortser jag ifrån grafisk design och användbarhet som man skulle behöva ta hänsyn till vid framtagning av en riktig applikation. 1.4 STRUKTUR AV UPPSATSEN Resten av uppsatsen är strukturerad som följer. Kapitel 2 är Teori där jag beskriver olika typer av mobilapplikationer, deras förr- och nackdelar. Därefter beskriver jag närmare ett ramverk Ionic och går igenom dess bestående delar samt teknisk- och kunskapskrav som ställs på utvecklaren som väljer att använda sig av Ionic. Sedan berättar jag om tester och varför det är viktigt att skriva automatiska tester till sin kod. I slutet av teorikapitlet beskriver jag hur man skall testa kod skriven för Ionic. 3
I kapitel 3 Metod beskriver jag vilka alternativ som finns för att gå tillväga med uppsatsen, vilket av dem jag valde och varför. I kapitel 4 Resultat redovisar jag resultatet av mitt arbete, hur jag gjorde och vilka beslut som jag behövde ta för att skapa en mobilapplikation som uppfyller beställarens krav. Sedan presenterar jag den skapade mobilapplikationen med hjälp av skärmbilder. Efter Resultat följer kapitel 5 Analys där jag analyserar resultatet utifrån den analysmetod beskrivet i metoden. Uppsatsen avslutas med kapitel 6 Diskussion och slutsatser var jag besvarar uppsatssyftet, går igenom alternativa lösningar och ger förslag till fortsatt arbete med applikationen och till fortsatt forskning inom området. 4
2 TEORI Enligt definition som finns på PCMag Digital Group (u.å.) är mobila applikationer dataprogram som är skapade för att köras på smarttelefoner, paddor och andra mobil enheter. Det finns flera olika sätt att bygga en applikation för en mobilenhet och Wilken (2014) beskriver tre olika typer av mobila applikationer som delas in beroende på vilken teknik som användes: Nativa mobila applikationer Mobila webbapplikationer Hybrida mobila applikationer Tekniker som används för att skapa olika typer av mobila applikationer skiljer sig mycket ifrån varandra. Skillnader ligger i resurskrav, t.ex. krav på utvecklare, deras antal och kunskap, krav på tid för utveckling och underhåll o.s.v. Användning av olika tekniker för samma applikation ger också en del skillnader i hur de utvecklas, mer om dessa kommer i kapitel som beskriver varje kategori av applikationer. Men det är viktigt att förstå att inget av alternativen är bättre eller sämre än andra utan varje har sina styrkor och svagheter och för att ta ett beslut vad som passar bäst i ett särskilt fall skall en analys av varje alternativ göras. (Church, 2012) 2.1 NATIVA MOBILA APPLIKATIONER Nativa mobil applikationer skrivs i mobilen operativsystems standardspråk vilket är Objektiv C för ios och Java för Android. Dessa applikationer kompileras och körs direkt på enheten och kan kommunicera med plattformens SDK (API) för att få tillgång till enhetsdata och för att hämta data för externa webbsidor genom HTTP begäran. (Wilken, 2014) Det finns verktyg tillgängliga för både ios och Android som möjliggör användning av plattformsfunktioner genom fördefinierade APIer. Det är också vanligt att utvecklare använder sig av ramverk för att underlätta den nativa applikationsutvecklingen.(wilken, 2014) Nativa applikationer har följande fördelar: Nativa API. De kan använda nativa API direkt i applikationen, vilket skapar bättre plattformintegrering. (Wilken, 2014) Prestanda. Om en nativ applikation är väl utformad är dess prestanda hög. (Wilken, 2014) 5
Samma miljö. Nativa applikationer använder samma språk som plattformar de byggs för, vilket är en fördel för utvecklare som kan plattformens språk. (Wilken, 2014) Sådana applikationer är lättare att upptäcka eftersom användaren kan hitta dem genom att söka efter applikationer som passar till ens mobilenhet. (t.ex. genom att söka i App store) (McWherter & Gowell, 2012) Nackdelar av nativa applikationer är följande: Språkkrav. Utvecklingen kräver kunskap i plattformsspråk och i API. (Wilken, 2014) Ingen plattformsoberoende utveckling. Applikationer för olika plattformar skapas var för sig. (Wilken, 2014) Nativa applikationer kräver mycket jobb och kostnader är därför höga. (Wilken, 2014) Har speciella hårdvarukrav för att t.ex. nativa applikationer för ios endast kan skapas på Mac.(McWherter & Gowell, 2012) Uppdatering för varje enhet är tidskrävande och det förväntas att användaren kontrollerar om det finns tillgängliga uppdateringar. (McWherter & Gowell, 2012) För att bestämma om en nativ applikation passar till ett särskilt projekt skall man jämföra sina resurser och krav som ställs på applikationen med styrkor och svagheter av en typ av mobilapplikation. Generellt sett används nativa applikationer främst för att skapa applikationer som har mycket animering, i spel och i alla applikationer som kräver hög prestanda (t.ex. vid behandling av bilder). (Phan, 2014) 2.2 MOBILA WEBBAPPLIKATIONER Mobilwebbapplikation (som även kan kallas för anpassade webbsidor, mobila webbsidor eller webb appar ) är webbsidor som kan visas i mobil browser i mobilenhet och är anpassade till mobilenhet. En anpassad webbsida kan vara en speciell version av en webbsida som skapades speciellt för mobilenhet eller en webbsida anpassad till mobilens skärmstorlek.(wilken, 2014) Mobila applikationer har också fördelar: Lätt att underhålla. Det finns inget behov att installera uppdatering på en mobilenhet. (Wilken, 2014) Ingen installation. Anpassade webbsidor är ingen applikation och behöver därför inte installeras. (Wilken, 2014) Plattformsoberoende. Alla mobilenheter som har en browser kan visa en anpassad webbsida. (Wilken, 2014) 6
Enkelt att uppdatera för alla mobila enheter. (McWherter & Gowell, 2012) Mobilwebbapplikationer är inga riktiga mobilapplikationer utan webbsidor och har därför en del nackdelar i jämförelse med mobila applikationer: Saknar nativt tillgång. Eftersom webbsida körs i browser har utvecklaren enbart tillgång till browsers API (ingen tillgång till mobilenhetens API). (Wilken, 2014) Kräver tangentbord för att navigera till. Användaren måste skriva webbsidans adress för att navigera till webbsida. (Wilken, 2014) Begränsat användargränssnitt. Eftersom det är samma webbsida som visas på mobilenhet och på skrivbordet är det svårt att skapa en användarvänlig touch applikation. (Wilken, 2014) Mobilwebbapplikationers största fördel är att de är billigare och enklare att utveckla och underhålla än alla andra alternativ. Men frånvaron av tillgång till enhetens egna gränssnitt kan störa användarupplevelsen. Dessutom är det inte möjligt att placera applikationen på mobiloperativsystemets affär vilket minskar antal användare som skall hitta applikationen. (Church, 2012) 2.3 HYBRIDA MOBILA APPLIKATIONER Hybrida mobila applikationer består av webb vy som kör en webbapplikation i en nativ applikation och sköter kommunikationen mellan nativ enhetsplattform och webb vy. Detta ger den hybrida mobil applikationen tillgång till enheten (så som kamera och GPS). Vid utveckling av hybrida mobila applikationer används speciella verktyg som inte är skapade av Android eller ios. Hybrid applikationen kompileras och transformeras till en nativ applikation innan den körs. (Wilken, 2014) Hybrida applikationer ger en stabil bas för mobilapplikationsutveckling och kan samtidigt användas som en webbplattform. Hybrid mobilapplikation utvecklas som en vanlig webbsida och använder hybrida applikationers ramverk för att få tillgång till nativ API genom JavaScript. (Wilken, 2014) Hybrida applikationer har egenskaper från både nativa applikationer och mobila webbapplikationer vilket resulterar i följande fördelar: Plattformsoberoende. Hybrid mobil applikations kod kompileras till olika mobilenhets nativa applikationer. (Wilken, 2014) Kräver samma kunskap som webbutveckling. Hybrid mobil applikationsutveckling kräver ingen speciell språkkunskap förutom de som krävs för webbutvecklare. (Wilken, 2014) Tillgång till enhet. Eftersom hybrid applikationen transformeras till en nativ applikation får hybrid applikation tillgång till enheten. (Wilken, 2014) 7
Likt nativa applikationer kan hybrida applikationer bli tillgängliga för användare via mobilens butik. (McWherter & Gowell, 2012) Lätt att utveckla. Hybrida applikationer går enkelt och snabbt att utveckla. (Wilken, 2014) Hybrida mobila applikationer har både nativa och mobila webb applikationers särdrag, men uppfyller ingen av dessa kategorier i sin helhet vilket ger hybrida applikationer följande nackdelar: Begränsningar i webb vy. Applikationens prestanda beror på kvalitet av plattformens browser. (Wilken, 2014) Nativ via pluginer. Det kräver att ramverket för hybrida applikationer har en tillgång till pluginer för att anropa nativa API som behövs för alla de operativsystem som skall stödjas. (Wilken, 2014) Inga nativa användargränssnittkontroller. Utvecklare behöver skapa egna användargränssnittselement, men hybrid mobil applikations ramverk (så som Ionic) har kontroller som liknar nativa kontroller. (Wilken, 2014) Vid uppdatering krävs det att användaren laddar ner uppdatering. (Denna nackdel är samma som för nativa applikationer) (McWherter & Gowell, 2012) Church (2012) hävdar att hybrida applikationer är en bra kompromiss mellan de höga kostnaderna för att utveckla en nativ applikation för varje mobilplattform och bristen på tillgång till enheten som finns vid utveckling av en webb applikation. Detta gör denna kategori av applikationer intressanta för företag. Därför finns det projekt för att ta fram ramverk för att enkelt bygga hybrida mobila applikationer. Det finns ett flertal sådana projekt, några exempel av dessa är: Ionic Ramverk. Ionic ramverk är en av de mest lovande HTML5 baserade mobilapplikationsramverken. Det ger många UI komponenter för att hjälpa till att utveckla rika och interaktiva applikationer. (Raj, 2014) Appcelerator Titanium. Appcelerator Titanium är ett Open Source ramverk som ger en miljö för att skapa nativa applikationer för flera mobila plattformar. För att komma igång med Appcelerator Titanium skall Titanium studio laddas ner. Titanium SDK är utrustad med ett antal mobilplattform API:er och molntjänst för att använda som en applikations back- end. Den levereras med plattformsoberoende API:er som gör det lättare att komma åt telefonens hårdvara. (Raj, 2014) Sencha Touch. Sencha Touch är ett HTML5 baserat mobilapplikationsramverk för att skapa applikationer för flera plattformar inklusive ios, Android och Blackberry. Det har funnits i några år nu och är populär bland hybrida mobilapplikationsutvecklare. (Raj, 2014) 8
Intel XDK. Intel XDK är ett plattformsoberoende verktyg utvecklat av Intel. Intel XDK ger en levande förhandsvisning på den anslutna enheten och använder en dra och släpp utvecklingsmetod, vilket förenklar utvecklingen. (Raj, 2014) Under de senaste åren har Ionic ramverk etablerat sig som ledare inom hybrid mobilapplikationsutveckling. Ramverket ständigt uppdateras med de senaste trenderna och gör det före konkurrenterna. De största konkurrenterna till Ionic kräver kommersiell licens medan Ionic är gratis att använda och är Open Source. (Arora, 2015) 2.4 IONIC Ionic är en Open Source projekt som startade i november 2013. Dess popularitet har vuxit snabbt och Ionic har blivit ett primärt val för att bygga hybrida applikationer i. Idag är det 20 000 applikationer i månaden som skrivs med Ionic. (Wilken, 2014) Ionic är en kombination av verktyg och hjälpmedel och gör det möjligt för en utvecklare att skapa en hybrid mobilapplikation snabbt genom att använda samma teknik som används för att bygga webbplatser och webbapplikationer. Ionic fungerar genom att bädda in en webbapplikation i en nativ applikation med hjälp av Cordova. Den är utformad för att fungera tillsammans med AngularJS (Cordova och AngularJS är beskrivna senare i detta kapitel) för att skapa en webbapplikation i mobil miljö och inkluderar stöd för mobila funktioner och användargränssnitt kontroller som efterliknar nativa applikationer. (Wilken, 2014) Det finns en del andra ramverk för att bygga hybrida applikationer förutom Ionic, men ingen av dem kan jämföras med nativa applikationer i hastighet och användarupplevelse. Ionic gör det möjligt att skapa hybrida applikationer som ser ut och beter sig som nativa applikationer. (Wilken, 2014) Wilken (2014) nämner flera fördelar av Ionic, några av dessa är följande: Ionic är ett Open Source projekt och man behöver därför inte oroa sig för copyright. Ionic gör det möjligt att skapa en applikation snabbt Det är roligt för utvecklaren, vilket ökar utvecklarens produktivitet. Med Ionic man kan bygga applikationer för ios och Android, stöd för Windows 8 och Firefox OS är planerad i framtiden. (Wilken, 2014) Wilken (2014) skriver att i Ionic används det tre primära tekniker: Ionic ramverk, AngularJS och Cordova. 9
2.4.1 IONIC RAMVERK Ionic ramverk tillhandahåller hjälpmedel som underlättar applikationsutveckling. Dessa är användargränssnittskontroller, kommandotolksverktyg och Ionic Creator. Användargränssnittskontroller saknas i HTML, men är vanliga för mobilapplikationer. Dessa komponenter är uppbyggda av CSS, HTML och JavasScript men beter sig som nativkontroller. Exempel av dessa kontroller är: sidomenyer som glider in från sidan, mobilflikar, växlingsknapparna. (Wilken, 2014) Kommandotolksverktyg (CLI) hjälper utvecklaren att starta projekt, förhandsvisa, bygga och köra mobilapplikationen. (Wilken, 2014) Ionic Creator gör det möjligt att använda dra- och- släpp gränssnitt för att designa och exportera applikationen. (Wilken, 2014) 2.4.2 ANGULARJS AngularJS är Open Source projekt ifrån Google som startades 2009 och blev ganska populärt bland utvecklare för att det ger möjlighet att skriva applikation snabbt och det strukturerar kod på ett bra sätt. (Wilken, 2014) AngularJS är grunden till allt man bygger med Ionic och Ionic är beroende av AngularJS. (Phan, 2014) AngularJS är ett webbapplikationsramverk i JavaScript för att främst utveckla applikationer i webbläsaren. (Wilken, 2014) 2.4.3 CORDOVA Cordova (tidigare kallat PhoneGap) är ett Open Source Apache projekt och är ett hybrid applikationsramverk som hanterar kommunikation mellan browser och nativ API. (Wilken, 2014) Enligt Apache Cordova dokumentation (u.å.) gör Cordova det möjligt att använda HTML5, CSS3 och JavaScript för plattformsoberoende utveckling för att undvika nativa plattformspråk. Mobila applikationer paketeras om för varje mobilplattform och förlitar sig på standardbaserade API pluginer för att komma åt varje enhets sensorer, data och nätverksstatus. 2.4.4 IONIC KOMPONENTERS SAMARBETE Bild 1. Ionics komponent (Bilden är återskapad från Wilken, 2014) 10
Om man tittar på bild 1 och går från höger och till vänster, ser man först en mobilenhet. Mobilenheten har ett operativsystem som installerar applikationen som laddas ner från mobilplattformsaffär. Operativsystem har APIer tillgängliga för applikationen för att nå kamera, GPS, kontakter osv. Efter mobilenheten kan man se Cordova och sedan webb vy. Cordova skapar en länk mellan mobilplattform och applikationen genom att skapa en nativ applikation som kan installeras på en mobilenhet och som innehåller en webb vy (isolerad browser) som kör applikationen. Eftersom Cordova utrustar applikationen med ett JavaScript API som används för att kommunicera med nativ mobilenhet kan den genererade nativa applikationen nå både webb applikationen och nativ mobilplattform. Efter Cordova följer AngularJS och Ionic. Inne i webb vyn körs en AngularJS webbapplikation i JavaScript. AngularJS används mest för att hantera applikationslogik och data. Ionic används mest för att skapa ett mobilt användargränssnitt och användarupplevelse och inkluderar flikar, knappar och navigering. (Wilken, 2014) 2.4.5 KUNSKAPSKRAV Enligt Ionic dokumentation (u.å.) bygger användare sina applikationer som vanliga webbsidor och som sedan med hjälp av Cordova körs inuti en nativ applikation. Därför kan man skapa en applikation genom att bara använda HTML, CSS och JavaScript. HTML används för att ge struktur, CSS för design och JavaScript möjliggör den interaktion och logik som applikationen kräver. (Wilken, 2014) I Ionic dokumentation (u.å.) står det att vissa utvecklare gräver sig fram till nativnivå med hjälp av Cordova pluginer eller med nativ kod, men detta är inte nödvändigt för att skapa en bra applikation. Wilken (2014) hävdar att Ionic är byggt för att jobba med AngularJS. För utvecklare som är vana med att använda jquery kan det vara lockande att använda sig av det istället för att lära sig AngularJS, men Phan (2014) uppmuntrar att undvika använda jquery och att fokusera enbart på AngularJS. 2.4.6 TEKNISKA KRAV Enligt Ionic dokumentation (u.å.) riktar sig nuvarande Ionic enbart mot iphone och Android mobiltelefoner och stödjer ios 6+ och Android 4.0+, men eftersom det finns väldigt många olika Android telefoner är det möjligt att applikation skapad med Ionic inte skall fungera på några av dem. I Ionic dokumentation (u.å.) står det också att man kan utveckla Ionic applikation på vilket operativt system som helst och Ionic applikationer har utvecklats på Mac OS X, Windows och Linux, men det operativa systemet som skall användas måste ha en kommandotolk om man vill kunna följa steg beskrivna i Ionic dokumentation. 11
Om tanken är att göra en applikation för bl.a. iphone måste operationssystem vara OS X. Enligt Apache Cordova dokumentation (u.å.) kan de verktyg som krävs för att skapa ios applikationer enbart köras på OS X operativsystem på Intel- baserade Mac- datorer. Xcode 4,5 (minimum version som krävs) körs bara på OS X version 10.7 (Lion) eller större, och inkluderar ios 6 SDK (Software Development Kit). För att skicka in applikationer till Apple App Store krävs de senaste versionerna av Apple- verktyg. Därför rekommenderas det i Ionic dokumentation (u.å.) att utveckla Ionic applikationer på Mac. För att utveckla mobilapplikation för Android krävs det Android SDK (Apache Cordova dokumentation, u.å.) Android SDK är en Software Development Kit som tillåter utvecklare att skapa applikationer för mobilplattformen Android. Android SDK innehåller exempelprojekt med källkod, utvecklingsverktyg, en emulator, och bibliotek som krävs för att bygga Android applikationer. (Agustin, 2011) Wilken (2014) rekommenderar också att ha minst en mobilenhet för varje plattform för att kunna testa. Trots att det finns emulator som kan visa hur en applikation skall se ut på mobilen är dessa inte fullständiga kopior av riktiga mobilenheter. 2.4.7 KOSTNADER Enligt Ionic dokumentation (u.å.) Ionic är ett Open Source ramverk som släpptes under licens MIT, vilket betyder att det är tillåtet att använda Ionic fritt för personligt och kommersiellt bruk. Ionic dokumentation (u.å.) anger att om man bygger en applikation för ios måste utvecklaren registrera sig själv som Apple utvecklare. Bara då blir det möjligt att köra applikationen på iphone och ipad. Att vara Apple utvecklare kostar 99$ per år. 2.5 OPEN SOURCE Ionic Ramverk är en programvara släppt som Open Source. Open Source programvara har blivit en väldigt populär distributionsform och Afshar (2014) hävdar att Open Source har nu en permanent roll i företags IT och att Open Source kommer att ingå i 85% av alla kommersiella mjukvarupaket från 2015 och 95% av traditionella IT- organisationer kommer att utnyttja någon form av öppen källkod mjukvara. Företag väljer att använda Open Source för att den erbjuder betydande fördelar jämfört med vanliga kommersiella produkter. Kommersiella produkter gynnar vanligtvis synliga detaljer (som ger fördel på marknaden) istället för egenskaper som stabilitet, säkerhet och liknande mindre glamorösa attribut. Medan Open Source utvecklare motiveras mycket av andra utvecklares utvärderingar och därför föredrar att bygga mjukvara som 12
är beundrad av andra likasinnade. Mycket uppskattade faktorer av utvecklarna är ren design, tillförlitlighet och förvaltningsbarhet. (GBdirekt, u.å.) Open Source programvaror har flera fördelar, några av dem är följande: Låg kostnad. Köper man en kommersiell programvara kan man förutom inköpspriset för själva programvaran även behöva betala för obligatoriskt virusskydd, stöd och löpande uppgraderingskostnader. Användning av en Open Source drar ner företagskostnader. (Noyes, 2010) Bättre kvalitet på koden. 80% av användare av Open Source valde att använda den baserat på kvalitet. Öppen källkods programvaror har bättre kvalitet för att utvecklingen pågår utanför företagets gränser och det är många utvecklare som deltar i kodskrivningen. Utvecklarna diskuterar, kompromissar och inspirerar varandra vilket bidrar till bra kod kvalitet. (Afshar, 2014) Säkerhet. Säkerheten är hög på grund av att Open Source är transparent och den granskas av användarna. (Afshar, 2014) Kollektivt. Open Source projekt bygger upp ett kollektiv av människor som tror på sin teknologi och brinner för att göra det tillgängligt för andra. (Afshar, 2014) Kollektivet ger även stöd för användare, vanligtvis finns det dokumentation eller forum där man kan ställa frågor osv. (Noyes, 2010) Frihet. Det finns inga begränsningar, utvecklaren har tillgång till koden, kan lägga till funktioner och fixa till koden själv. (Afshar, 2014) Anpassningsförmåga. Det öppna källkods utvecklingsmodell bidrar till att programvara anpassas snabbt till föränderliga tider. (Afshar, 2014) Val. Det finns många lösningar och användaren kan välja den som passar en bäst. Idag finns det över 1 miljoner projekt med öppen källkod och 10 miljoner utvecklare som deltar. (Afshar, 2014) Allt det gör Open Source attraktivt för ett företag att använda och det blir fler och fler som väljer att använda den istället för kommersiella programvaror. Men innan man väljer att använda av Open Source bör man fundera på utmaningar som användning av Open Source kan innebära. Några av dessa är följande: Kvalitet på koden. När projektet blir väldigt stor och det är många utvecklare som deltar i kodskrivning blir det svårt att få hela koden utvärderat av andra utvecklare. (Hurley, 2014) Inlärningskurva. Företaget kan behöva anställa en Open Source expert för att lära upp personalen. (McCafferty, 2013) Förvirrade användare. Eftersom det är flera utvecklare som jobbar med projekt samtidigt kan det vara oklart för en användare vilken version som skulle passa bäst och om den är kompatibel med andra mjukvara företaget använder. (McCafferty, 2013) 13
Föräldralös mjukvara. Vissa Open Source projekt dör för att nyckelutvecklarna inte kommer överens och slutar utveckla eller för att de tappar intresse och startar ett annat projekt istället. (McCafferty, 2013) Lösa problem själv. Open Source ger ingen stöd till användarna som skulle kunna motsvara stöden från kommersiella programvarors distribuerar. All stöd som man kan få i Open Source är ett stöd från dess kollektiv. Dock skall man komma ihåg att kollektiv inte är skyldig att svara på användarens frågor och lösa problem som kan uppstå. Dock så erbjuder många företag supportkontrakt till vissa Open Source projekt för att få garanterat stöd vid behov. (McCafferty, 2013) Innan man bestämmer sig att använda sig av ett Open Source projekt skall man fundera på de risker det skulle innebära och utvärdera både riskens sannolikhet i förhållande till det Open Source projektet man funderar på att använda och sina möjligheter att lösa eventuella svårigheter som kan uppstå. 2.6 TESTNING Många företag tror att det tar tid att testa en produkt och vill få sin produkt på marknaden så fort som möjligt. Det kan vara kostsamt att släppa produkten på marknaden sent, men det blir ännu sämre att släppa en produkt som är defekt. Programvarufel kan vara kostsamt för ett företag och i visa fall har det lett till konkurs. (Hayes, u.å.) För att vara säker på att mjukvara som släpps inte innehåller några allvarliga fel måste produkten testas. Tester kan vara manuella eller automatiska. En anledning att använda automatiska tester istället för manuella är att applikationer förändras under sin livstid och blir mer och mer komplicerade. Därför ökar antalet tester som behöver genomföras med tiden. Även om förändringar bara rör 10% av koden kan hela applikationen behöva testas igenom. Detta gör manuell testning svårt att genomföra på grund av att tiden som krävs för att testa varje systemuppdatering ökar och kräver fler resurser. Med automatiska tester är det möjligt att spara testfall genom applikationens livstid och återanvända tester vid behov. (Hayes, u.å.) Ett annat argument som talar emot manuella tester är att om det är tidsbrist föredrar testare att testa nya tillägg till applikationen istället för att testa gammal funktionalitet. Men största risk för användare ligger i gammal funktionalitet. Om någonting som användaren redan använder slutar att fungera kan det stoppa drift. Däremot om nya funktionaliteter visar sig att inte fungera är det möjligt att det inte leder till lika stora konsekvenser. (Hayes, u.å.) Bra skrivna tester bidrar även till snabbare kodskrivning. Om man tittar vad en programmerare spenderar sin tid på visar det sig att det inte är så mycket tid som går åt att skriva kod. Viss tid går åt att förstå vad som skall pågå, viss tid går åt för design, men 14
mest tid går åt till felsökning. Felrättning tar vanligtvis inte lång tid, men att hitta det kan vara en mardröm. När ett fel är rättat kan det hända att ett annat fel dyker upp någon annanstans med stor chans att utvecklaren inte upptäcker det förrän mycket senare och det kan då ta enorm lång tid att hitta felet. Om man har automatiska tester som är enkelt att köra regelbundet kan man enklare hitta fel. Om man dessutom kör tester regelbundet vet man att det är nyligen skriven kod som orsakat felet och det är enklare att rätta felet eftersom utvecklaren har ett fräscht minne om den. (Fowler, Beck, Brant, Opdyke & Roberts, 1999) Fowler et al. (1999) ger flera råd kring framtagning av automatiska tester, några av dessa är: Skriv helt automatiska tester som kan kontrollerar sitt eget resultat. Kör tester regelbundet, minst dagligen. Glöm inte att testa om undantag körs när det förväntas vara fel. Det är bättre att köra ofullständiga tester än att inte köra tester alls. Låt inte rädslan att tester inte hittar alla fel stanna dig att skriva tester som hittar de flesta av felen. Många systemutvecklarteam har idag erkänt fördelarna med automatiska tester för design och kvalitet av program. Det är därför ofta förväntat att automatiska tester skall skrivas av utvecklaren på vardaglig basis. Testning har förflyttat sig från en separat aktivitet som utförs av personal i motsvarande position till en aktivitet som ingår i systemutveckling och utförs av utvecklaren själv. (Rady & Coffin, 2011) Automatiska tester kan hjälpa till att släppa en pålitlig produkt, höja företagets förtroende, minska risk för misslyckande och hjälpa att undvika kostnader för stöd och omarbetning. Automatiska tester sparar tid och minskar kostnaderna och förbättrar resursproduktivitet. Om testbibliotek är automatiserat, exekvering är snabb och täcker fler fall än vad manuell testning skulle göra. (Hayes, u.å.) 2.7 TESTA IONIC Det är AngularJS som definierar kodningsregler i Ionic och för att testa Ionic applikation behöver kod testas på samma sätt som vanlig AngularJS kod. I grunden till AngularJS ligger JavaScript. JavaScript är ett språk med stor uttryckskraft, men ger nästan ingen hjälp från kompilatorn och därför måste kod som skrivs i JavaScript komma med en uppsättning av tester. Därför har skaparna av AngularJS byggt in flera komponenter i ramverket för att förenkla testning av koden.(angularjs dokumentation, u.å.) Det finns speciella verktyg som gör testning med AngularJS mycket enklare. Dessa verktyg är följande: 15
Karma. Karma är en JavaScript kommandoradsverktyg som kan användas för att kontinuerligt ladda in applikationens källkod och utföra samtliga tester. Karma kan konfigureras mot olika webbläsaren vilket är användbart då det gör det möjligt att kontrollera att applikationen fungerar bra i alla browser som behövs. Karma körs på kommandotolken och visar resultatet av testexekveringen direkt i kommandotolken efter det att testerna har körts i webbläsaren. Jasmine. Jasmine är ett ramverk för testdriven utveckling i JavaScript som har blivit det mest populära valet för testning av AngularJS applikationer. Jasmine tillhandahåller funktioner som hjälper till med strukturering av tester. Jasmine hjälper även till att hålla tester strukturerade och dokumenterade när programmet växer. (AngularJS documentation, u.å.) 16
3 METOD I uppsatsen beskrivs hur man kan gå till väga för att skapa en lättförvaltad mobilapplikation med programvaran Ionic. Arbetet utgår ifrån företagets beskrivning av den önskade mobilapplikationen, Ionics dokumentation samt andra utvecklares erfarenhet av Ionic applikationsutveckling som fanns på nätet. 3.1 SYSTEMUTVECKLINGSMETOD Detta arbete är ett systemutvecklingsprojekt och det var därför viktigt att bestämma vilken systemutvecklingsmetod som skulle användas. Detta behövdes för att få hjälp med strukturering av arbetsgång och formning av riktlinjer för att fullfölja uppsatsens syfte. Tillvägagångssätt vid systemutveckling kan fördelas i två grupper: de traditionella och agila metoder. Till de traditionella metoderna hör vattenfall som tillhandahåller en linjär syn på mjukvaruutveckling. Händelseförloppet i denna metod är: samla och dokumentera krav, gör design, skriv kod och göra enhetstest, utför systemtest, utför användaracceptans tester, åtgärda eventuella problem och slutligen leverera den färdiga produkten. (Lotz, 2013) En nackdel av denna metod är att beställaren kan uppleva svårigheter med visualisering av den färdiga produkten vid projektets början och ha det svårt att specificera krav och ge en bra och detaljerad beställning. Detta kan resultera i att beställaren blir missnöjd med produkten. (Lotz, 2013) Agila metoder är metoder som möjliggör tidig och snabb genomförande av utvecklingen på en inkrementell basis. De ställer mindre krav på behovsanalys och design och är anpassad till behov som förändras. I grunden till agila metoder ligger förståelsen att krav till systemet kommer att förändras under arbetets gång. (Bennet, McRobb & Farmet, 2010) Agila metoder är mindre byråkratiska än traditionella och ställer mindre krav på dokumentation, fokuserar på interaktion med användaren och leverans av ett fungerande system. (Bennet et al., 2010) Det finns en del agila metoder att välja ifrån, det mest populära av de agila metoderna idag är Scrum. (Bennet et al., 2010) Syftet med Scrum är att skapa ett team som är kreativt, entusiastiskt, ger befogenheter och främjar samarbete. (Layton, 2012) Scrumteam är vanligtvis små, perfekt storlek är 5-9 personer. (International Scrum Institute, u.å.) 17
Scrum är en iterativ metod som har i grunden en s.k. sprint. Inom varje sprint utvecklar och testar laget en funktionell del av produkten tills produktens ägare accepterar den och dess funktionalitet. När en sprint avslutas påbörjas nästa. Gruppen levererar produktegenskaper vid slutet av varje sprint. En produktrelease sker i slutet av en sprint eller efter flera sprintar. (Layton, 2012) En annan populär systemutvecklingsmetod är Kanban. Kanban är en metod som används för systemutveckling med betoning på kontinuerlig leverans och utan överbelastning av utvecklingsteamet. Kanban är baserad på tre principer: Visualisering av workflow. Det kan hjälpa till att se en uppgift i kontext av andra uppgifter. Begränsning av antal aktiva uppgifter, vilket hjälper att balansera flödet så team inte startar för mycket arbete på en gång. Förbättra flödet. När något är klart, är det den näst högst prioriterade uppgiften som påbörjas. (McLaughlin, u.å.) Vattenfallsmetoden valdes bort för detta projekt då detta arbete var ett försök att lära sig ett ramverk och leverera produkt skapad med det valda ramverket som uppfyller beställarens krav. Varken uppsatsförfattaren eller beställaren kände till ramverket och därför var det svårt att veta om alla beställarens krav skulle gå att uppfylla i sin helhet. Det kunde också hända att nya möjligheter skulle bli upptäckta under arbetets gång och beställaren skulle välja att lägga till eller förändra krav till produkten. Därför var det viktigt att arbetet skulle utföras i en ständig konversation med beställaren och Agila metoder gav bäst stöd för detta. Scrum skulle kunna hjälpa i detta arbete, men det skulle behövas 5-9 utvecklare. Eftersom uppgiften skulle utföras av en person var det inte möjligt att använda Scrum på ett effektivt sätt. Inga hinder för användning av Kanban kunde hittas och enligt Kanbans beskrivning passade denna metod bra till projektets miljö och villkor. 3.2 KANBAN I ARBETET Kanban är en teknik för att effektivt hantera mjukvaruutvecklingsprocessen. Kanban är väldigt enkel men samtidigt väldigt kraftfull. Systemet i Kanban består av en stor tavla med kort eller klisterlappar som placeras i en kolumn med nummer på topp. Ett kort presenterar arbetsposter som flödar genom utvecklingsprocessen som representeras av kolumnerna. Nummer på topp av varje kolumn begränsar antalet kort som är tillåtna för respektive kolumn. (Peterson, u.å.) For att skapa en Kanban tavla användes ett program som heter Trello. Trello är en gratis online resurs som gör det möjligt att skapa tavlor som innehåller kolumner med kort 18
som innehåller en beskrivning av en uppgift. Tavlor kan delas med andra Trello användare, d.v.s. utvecklingsteam kan jobba med samma tavla. Kort som skapas i Trello har tittalar, beskrivningar, en meddelandelogg för aktiviteter, checklistor, förfallodatum, etiketter, länkar, bilagor och kan även tilldelas till andra Trello användare. (Connell, 2014) Anledningen till att Trello valdes i för denna uppgift var att författaren har erfarenhet av Trello från tidigare projekt och det programmet fungerade väldigt bra och uppfyllde syftet. Utvecklingen pågick i flera iterationer. I början av projektet definierades uppgifter tillsammans med beställaren. När dessa uppgifter var klara presenterades resultatet till beställaren och nya uppgifter definierades. Ett exempel på hur arbetet i Trello pågick kan ses på bild 2. Bild 2. Kanban i Trello 3.3 UTVECKLA MED IONIC Att komma igång att utveckla en mobilapplikation med Ionic var relativt enkelt, men det förutsatte att jag kunde JavaScript och hade erfarenhet av webbutveckling sedan tidigare. Det var också en stor fördel att kunna AngularJS innan jag satte igång med Ionic. För att installera ramverket behövde jag först installera applikationen NodeJS (Ionic dokumentation, u.å). NodeJS är ett ramverk för att skriva server applikationer i JavaScript. Detta ramverk i sig behövs inte för Ionic, däremot behöver man ett medföljande kommandotolksprogram kallat npm. npm är ett verktyg för att installera andra JavaScript verktyg och bibliotek. För att installera Ionic på sin utvecklingsmaskin behövde följande kommando köras: 19
>npm install g cordova ionic Detta satte upp alla kommandotolksprogram som behövdes, både det underliggande Cordova (som är ansvarig för att generera själva mobil applikationerna) och Ionic. Därefter var det möjligt att starta sitt projekt genom att gå till sin projektkatalog där jag ville att filstrukturen skulle genereras. Därefter kördes detta kommando: >ionic start minapp sidemenu Parametern start anger för Ionic att ett nytt projekt skall skapas. Detta följs av själva namnet på projektet och slutligen namnet på den projektmall man vill använda. Det finns en rad färdiga mallar man kan använda sig av, till exempel tabs som skapar en app med tre olika sidor och en meny längst ner där man kan välja vilken sida man vill arbeta i. Alternativt kan man välja sidemenu som skapar en sidomeny till vänster om själva applikationen som går att visa/gömma med en knapp. Mallen blank skapar en minimal tom sida. De viktigaste filerna som genereras för mallen blank för att komma igång är följande: Filstruktur minapp/ config.xml ionic.project bower.json www/ css/ img/ lib/ js/ app.js index.html Förklaring Huvudkatalogen Fil som beskriver för Cordova hur den skall generera själva mobil applikationerna, behöver inte ändras i för enklare program. Projektinställningar för Ionic. Behöver aldrig ändras för enklare program. Fil som innehåller beroenden på externa bibliotek och som behöver inkluderas i byggprocessen. Katalog som innehåller JavaScript och HTML som bygger upp själva applikationen. Innehåller CSS filer för egna anpassningar av layout. Katalog för bilder som skall visas. Innehåller externa JavaScript bibliotek. Skall innehålla JavaScript kod för logiken i applikationen. Huvudfilen för JavaScript som initierar Ionic. Huvudfilen för HTML som laddar in CSS och JavaScript och definierar vyn i applikationen. Filerna i tabellen visar bara de grundläggande som behövs för att komma igång att 20
utveckla, i en större applikation skulle underkataloger skapas. Jag har skapat underkataloger under js för respektive JavaScript fil och en katalog templates som innehåller delar av html fragment för att undvika en enda gigantisk html fil. Under utvecklingens gång finns det i Ionic ett verktyg för att kontinuerligt se slutresultatet av sin applikation i sin browser utan att behöva kompilera och paketera mobilapplikationen varje gång. Det verktyget heter serve och körs genom att gå till huvudkataligen för projektet och köra: >ionic serve När jag körde detta kommando startade en lokal server automatiskt tillsammans med en webbläsare som visade hur applikationen skulle se ut. Sedan uppdaterade jag projektets JavaScript och HTML filer i en texteditor och så fort en fil sparades så laddade ionic serve automatiskt om sidan så jag direkt fick en uppdatering av resultatet. Med ionic serve gick det att utveckla en stor del av funktionaliteten fram tills att jag var redo att testa resultatet i telefonen eller dess emulator. 3.4 SKAPA MOBILAPPLIKATION FÖR IOS MED IONIC För att senare generera själva mobilapplikationen för iphone eller en annan ios enhet behövde jag installera utvecklingsverktygen Xcode ifrån Apple. Detta verktyg finns bara för operativsystemet OS X för Mac. Nästa steg var att konfigurera projektet till att ha stöd för plattformen ios med kommandot: >ionic platform add ios Därefter gick det att starta igång sin applikation i Xcodes IOS emulator som simulerade en iphone eller ipad med kommandot: >ionic emulate ios Det startade upp applikationen i en av Xcodes förvalda iphone enhet. De flesta av Apples mobila enheter går att emulera genom att man anger en parameter target=<namn>. För att se vilka giltiga namn på enheter som går att emulera skall man köra kommandot (ifrån projektets huvudkatalog). >./platforms/ios/cordova/lib/list-emulator-images iphone-4s iphone-5 iphone-5s iphone-6-plus 21