Rejlers EnergiApp
Utveckling av en energihanteringsapp med Apache Cordova
Developing an energy management app with Apache Cordova
William Gullin Marcus Ekberg
Fakulteten för hälsa, natur- och teknikvetenskap Datavetenskap
C-uppsats 15hp
Handledare: Annika Klockar Examinator: Thijs J. Holleboom Oppositionsdatum: 2016-01-22
Sammanfattning
Mobila enheter används mer och mer för att förenkla och effektivisera redan existerade tjänster på webben. Många storföretags webtjänster som exempelvis Facebook och Google har mobilappar som gör användares erfarenhet av tjänsten bättre och mer tillgänglig än tidigare. Apputveckling blir mer populärt då utvecklingsmjukvara ger mer stöd för många olika programmeringsspråk och tekniker som underlättar utvecklaren att skapa appar för flera operativsystem. Appen som utvecklats för uppdragsgivaren är en energihanteringsapp som visar en användares energianvändning för givet tidsintervall. Appen visar även energianvändningen i olika diagram och kan skapa rapporter.
Abstract
Mobile devices are used more and more to simplify and streamline already existing web services. Many large corporations’ web services e.g. Facebook and Google have created mobile apps that give users a better and more accessible experience than before. App development is becoming more popular as the development software gets more support for different programming languages and techniques that make it easier for the developer to create apps for different operating systems. The app that’s been developed for the employer is an energy management app which shows a user’s energy usage for a given time period. The app also shows energy usage in various diagrams and can create reports.
Förord
Vi vill tacka alla våra handledare som har hjälpt oss med utveckling, avhandling och kommunikation. Det har varit en rolig och lärorik upplevelse att få testa på att utveckla en mobilapp då det är något vi inte har gjort tidigare och så är utvecklingen av appar väldigt aktuellt och vanligt bland företag nuförtiden. Utöver ny teknisk kompetens så har vi fått mer inblick i hur det är att jobba inom ett företag som Rejlers. Vi träffade många trevliga medarbetare, fikade tillsammans och deltog i diverse arbetsrelaterade evenemang.
KAPITEL 1 - INLEDNING ... 1
1.1MÅL ... 1
1.2MOTIVERING ... 1
1.3UPPDRAGSGIVAREN ... 2
1.4RESULTAT ... 2
1.5UPPSATSENS DISPOSITION... 2
KAPITEL 2 - BAKGRUND ... 4
2.1UPPDRAG ... 4
2.2BEHOV AV ENERGIAPPEN? ... 4
2.3LIKNANDE APPLIKATIONER ... 4
2.4TEKNIKER OCH VERKTYG ... 5
2.4.1 Apache Cordova ... 5
2.4.2 HTML5 standarden ... 6
2.4.3 DOM ... 6
2.4.4 Github ... 6
2.4.5 Visual Studio ... 7
2.4.6 Ripple ... 7
2.4.7 CISCO VPN ... 7
2.4.8 OAuth2 ... 7
2.5SAMMANFATTNING ... 8
KAPITEL 3 - DESIGN AV ANVÄNDARGRÄNSSNITT... 9
3.1ALLMÄN DESIGN AV ANVÄNDARGRÄNSSNITT ... 9
3.1.1 Sidor ... 9
3.1.2 Finesser ... 11
3.1.3 Menyknappar ... 12
3.1.4 Stil och CSS ... 12
3.1.5 Designval av canvaselement för huvudsidan ... 13
3.2RAMVERK OCH BIBLIOTEK ... 14
Ionic framework ... 15
AngularJS ... 15
3.2.1 Angularkomponenter ... 15
3.2.2 Tekniska förberedelser ... 17
3.3SAMMANFATTNING ... 18
KAPITEL 4 - IMPLEMENTATION AV APPEN ... 19
4.1ÖVERSIKT ... 19
4.2APPENS KOMPONENTER ... 21
4.2.1 Index.html ... 21
4.2.2 Synliga sidor med controllers ... 22
4.2.3 Skript ... 24
4.3STARTPROCESSEN ... 25
4.4APP REDO FÖR NAVIGERING ... 29
Home.html ... 29
Anl.html ... 29
Dia.html ... 30
Set.html ... 32
4.5AUTENTISERING ... 32
KAPITEL 5 - RESULTAT ... 34
5.1TESTNING ... 34
5.1.1 Testning på olika operativsystem ... 34
5.1.2 Visual Studio Debugger ... 35
5.1.3 Färdig app ... 36
KAPITEL 6 - SLUTSATS ... 40
6.1SLUTSATSER ... 40
6.2TIDSÅTGÅNG ... 40
6.2.1 Vad kunde göras annorlunda? ... 41
6.2.2 Problem ... 41
6.2.3 Framtida arbete ... 42
REFERENSER ... 43
APPENDIX: ... 46
1
Kapitel 1 - Inledning
Detta kapitel förklarar projektets huvudsakliga mål, information om arbetsgivaren och projektets resultat. En motivering till projektet och avhandlingens disposition förklaras.
Fig 1.1: Översiktsbild över systemet.
1.1 Mål
Målet med projektet var att framställa en mobilapplikation som intuitivt visade en användares energianvändning för sina anläggningar, både produktion och konsumtion samt även användarens användning av fjärrvärme. Användaren skulle även kunna se sin nuvarande energianvändning i jämförelse med tidigare värden. Datan till appen skulle hämtas från Rejlers [1] egna databas via ett API framställt av Rejlers Energitjänster [2] i Motala.
1.2 Motivering
Då Rejlers kunder endast kunde se sin energianvändning i Rejlers Energitjänsters webbtjänst var en mobilapplikation eftertraktad för att göra visningen av energitjänster mer tillgänglig
2
och intressant. Tjänsten i appen skulle även kunna visa användaren datan på ett mer underhållande sätt genom grafiska element för att få användaren mer engagerad.
1.3 Uppdragsgivaren
Rejlers är ett svenskt teknik-konsultbolag som erbjuder tekniska tjänster och lösningar inom bygg-, fastighet-, energi-, industri- och infrastruktursektorn. Rejlers innefattar ca. 1800 anställda i Sverige, Finland och Norge med huvudkontor i Stockholm.
Rejlers Energitjänster AB är ett dotterbolag till Rejlers som erbjuder mätningslösningar och värdeinsamlingar för olika former av energianläggningar, såsom villor med solpaneler eller kraftverk. Uppdraget utfördes för Rejlers Energitjänster.
1.4 Resultat
Projektet resulterade i en fungerande prototyp av appen även om den inte blev kopplad till Rejlers Application Programming Interface (API) [3]. Appen kan visa en användares energianvändning för ett antal anläggningar grafiskt i en mätare och i diagram, energianvändningen kan även visas som siffror i en lista. Appen är förberedd för att kunna använda Rejlers API. Appen har fungerande säkerhetsfunktionalitet och kan hantera lokal användarautentisering och implementation av ytterligare autentisering är möjlig.
Det var förväntat att appen skulle bli en fungerande prototyp med koppling till ett fungerande API. Användare skulle kunna logga in med samma uppgifter som de använder för Rejlers tjänster. Sidan som visar användaren om energianvändningen är bra eller inte förväntades vara grafiskt snyggt och intuitivt att läsa av, även då designen inte var bestämd än. Rapporter, sammanställningar av data och fakturavisning skulle vara lättillgängliga för användaren med stöd för exportering till andra medier. Appen skulle fungera på de vanligaste operativsystemen som t. ex Android [7] och iOS [8]. Appen skulle kunna skräddarsys efter användarnas personliga preferenser som att ändra färg och typ på grafer och aktivera nattläge.
1.5 Uppsatsens disposition
Uppsatsen är uppdelad i sex kapitel med avslutande sammanfattningar samt ett appendix och referensförteckning.
3
Kapitel 1 ger en sammanfattning av uppsatsen och en översikt av projektet. Projektets mål och motivering förklaras och allmänna resultat presenteras kortfattat.
Kapitel 2 beskriver projektets bakgrund, varför appen önskades av uppdragsgivaren och dess kunder, vad uppdraget hade för innebörd och alla verktyg som använts. Kapitlet förklarar också Rejlers webtjänst som resultatet ska efterlikna.
Kapitel 3 går igenom appens huvudsakliga designval och utseende. Alla sidor som appen innehåller förklaras och var appens grafiska element är placerade. Här förklaras de bakomliggande ramverk och skriptbibliotek som appen består av.
Kapitel 4 börjar med att översiktligt gå igenom hur appen fungerar från start till navigering.
Appen består av många olika filer som gemensamt utgör appen och hur dessa filer kommunicerar och integrerar med varandra diskuteras. Appen har en extensiv startprocess som förklaras steg-för-steg i kapitel 4.
Kapitel 5 presenterar hur appen slutligen såg ut efter implementationen och hur den testades i emulator och i telefon för olika operativsystem.
Kapitel 6 täcker alla slutsatser för projektet, problem som upptäckts och hur de lösts samt utvärdering av projektet i sin helhet. Kapitlet täcker även vad som finns kvar att implementera i appen då det antingen saknats funktioner för dem eller att det inte hunnits med.
4
Kapitel 2 - Bakgrund
Detta kapitel beskriver tekniker och metoder samt annan information runt projektet och företaget. För- och nackdelar tas upp om utvecklingsverktyg, programspråk och anledningar till att projektet påbörjades. Rejlers Energitjänsters önskemål var att göra det lättare för sina slutkunder att se sin energianvändning och bli mer energismarta. Vid projektets början navigerade användaren in på Rejlers Energitjänsters hemsida och loggade in på ”Mina Sidor”.
Användaren kommer till REM [4] (Rejlers Energy Management) och kan se sina anläggningar och anläggningarnas energiförbrukning/produktion i grafer och tabeller samt aktuell driftinformation etc. Användaren kan exportera data till Microsoft Excel [5] och PDF [6] och visa speciella rapporter. Sidan stödjer också hantering av fakturor som kan tas emot direkt på sidan.
2.1 Uppdrag
Rejlers uppdrag till projektgruppen innefattade att producera en mobilapplikation för kunder.
Denna applikation ska visa slutanvändarens REM-sida i ett snyggt grafiskt gränssnitt (GUI), ska vara nedladdningsbar från olika onlinebutiker och fungera på flera olika plattformar, exempelvis Android/iOS/Windows Phone och Blackberry [7]-[10]. Ytterligare funktioner efterfrågade av Rejlers var ett motivationssystem som uppmuntrar användaren till att vara energismart.
2.2 Behov av Energiappen?
I dagens samhälle har många individer tillgång till någon form av mobila enheter som använder appar. Genom att skapa en app av Rejlers Energitjänsters REM-sida kommer tillgängligheten markant öka för kunderna och det blir mer bekvämt att använda tjänsten. En direkt fördel är att tjänsten kan nås var användaren än befinner sig förutsatt att det finns en uppkoppling till internet.
2.3 Liknande applikationer
En annan applikation som visar energiproduktion och konsumtion som är under utveckling kallas Greenely [11] av Greenely AB har fungerat som en inspirationskälla för Rejlers energiapp. Greenely är en app vilken mäter energianvändning i användarens hushåll via
5
elmätaren. Rejlers app har liknande funktioner men kommer inte hämta data från elmätaren utan istället från REM-sida där användaren har ett registrerat konto.
2.4 Tekniker och verktyg
Detta avsnitt täcker alla verktyg och tekniker som användes under projektets gång.
2.4.1 Apache Cordova
Apache Cordova [12] är en variant av programvaran Phonegap [13] vilket är ett ramverk för att paketera multi-plattform applikationer skrivna i HTML, CSS och JavaScript [14]-[16] så att utvecklaren inte behöver använda plattformsspecifik kod, exempelvis Objective-C [17] för iOS applikationsutveckling. Cordova gick tidigare under namnet Phonegap och skapades av företaget Nitobi, vilket köptes upp av Adobe [18]. Nitobi hade donerat källkoden för Phonegap till Apache vilken bytte namn till Cordova. De båda varianterna, Adobes och Apaches, är i stort sett samma programvara under olika namn.
Cordova tillåter en utvecklare att framställa mobila applikationer till flera plattformar utan att utvecklaren behöver hantera plattformsspecifik kod. Det blir en ”mobil hybridapp” då appen startas och körs som andra appar men är utvecklad med verktyg som vanligtvis används för webben. Cordova ger möjligheten att paketera en kodbas för specifika miljöer, exempelvis paketera kodbasen som en APK-fil för Android. Till Cordova medföljer emulatorn Ripple [19] som tillåter testning av applikationen för olika mobila miljöer direkt i webbläsaren.
Cordova kan läggas till i eller medföljer anpassade utvecklingsmiljöer såsom Visual Studio, Eclipse och Xcode [20]-[22].
För att överhuvudtaget kunna testa en iOS applikation i emulatorn Ripple måste det aktiva operativsystemet vara just ett Mac operativsystem som körs på en Apple Mac [23], annars saknas alternativet för att testa i miljön eller så blir miljön högst begränsad. Risken finns också att appen visar tecken på inkompabilitet beroende på enhetens hårdvara, skärmstorlek eller annan liknande aspekt. Prestandan på applikationen blir lite sämre jämfört med vad den skulle ha varit skriven endast med plattformsspecifik kod istället för att vara en hybrid mobilapp.
6 2.4.2 HTML5 standarden
Webbstandarden HTML5 [14] består av HTML, CSS3 och Javascript, vilka alla används för att bygga upp appar i Apache Cordova. HTML5 är huvudspråket i Rejlers Energiapp och används för att bygga alla sidor.
HTML version 5
HTML är ett märkspråk och en officiell webbstandard. Dokument skrivna i språket består av olika textkoder som instruerar datorprogram hur de ska tolkas. Oftast är textkoder (taggar) osynliga efter att dokumentet har bearbetats.
Cascading Style Sheets version 3 (CSS3)
CSS3 är en stilmall som används för att sätta stil på hur HTML-dokument visas i en webbläsare. CSS3 är en del av webbstandarden HTML5 och består av flera små moduler. I Rejlers Energiapp används CSS3 huvudsakligen för animation av övergångar, placering av objekt och färgsättning av bakgrund och text.
Javascript
Javascript är ett standardiserat skriptspråk och väsentlig del av WWW-arkitekturen [24]
tillsammans med HTML och CSS. Dess exekveringsmiljö är oftast webbläsare. Javascript är inbäddat i HTML-sidor och kan då interagera med sidans dokument-objektsmodell [25]
(DOM). Logiken i Rejlers Energiapp sköts av bakomliggande Javascript.
2.4.3 DOM
Document Object Model (DOM) är ett gränssnitt för att dynamiskt kunna läsa och uppdatera ett dokuments innehåll, struktur och formatering och förekommer främst i HTML- och XML- dokument. DOM är oberoende av språk, plattform och dokumentnoderna, exempelvis taggar, bildar en trädstruktur kallad DOM-träd. Rejlers Energiapps DOM uppdateras dynamiskt med hjälp av Javascript efter många händelser i appen.
2.4.4 Github
Github [26] är en nätverksbaserad hub för delning och versionshantering av programkod mellan utvecklare inom samma projekt, vilket är vad Github används för i utvecklingen av Rejlers
7
Energiapp. Github kan också anslutas med olika programmeringsmiljöer och resulterar i ett versionshanteringssystem. Varje gång en ny version av appen utvecklades så laddades den upp till en privat ”repository” på Github och kunde sen nås online.
2.4.5 Visual Studio
Microsoft Visual Studio [20] 2013 (VS13) uppdatering 5 användes som programmeringsmiljö för utveckling av Rejlers Energiapp till en början. Senare i projektet uppgraderades VS13 till VS15. Appen byggs ihop och signeras i VS15 som har stöd för alla språk och filformat som appen använder sig av.
2.4.6 Ripple
Ripple [19] är en mobilmiljö-emulator som körs genom VS15 och används för att testa Cordova applikationer. Ripple emulerar de olika mobilmiljöerna Android, iOS, Windows Phone, BlackBerry och många fler. I emulatorn så finns många funktioner exempelvis:
• ändra enhetsmodellen. Ripple kan emulera ca. 40 enheter
• simulera knapptryck på enheten
• styra accelerometern, simulera skakning och positionering av enhet
• simulera laddare och batterinivå
2.4.7 CISCO VPN
CISCO VPN [27] är ett program från Cisco Systems Inc. som hanterar en eller flera virtuella privata nätverk [28] (VPN). För att användare ska kunna logga in i appen måste en autentieringsserver vara installerad och kunna nås. För utvecklingssyfte används Cisco VPN Client för att nå en OAuth2-server i Motala.
2.4.8 OAuth2
OAuth2 [29] är ett protokoll för säkra autentiseringsflöden över nätverk. OAuth 2.0 är nästa version av OAuth 1.0 som lanserades 2006. OAuth2 tillåter applikationer att få begränsad tillgång till användarkonton hos olika webbtjänster. Med OAuth2 kan användare logga in på applikationer via ett redan existerande konto hos exempelvis Google, Facebook och Twitter [30]-[32]. Rejlers Energiapp ansluter till en autentiseringsserver i Motala.
8
2.5 Sammanfattning
I kapitlet presenterades Rejlers Energitjänster AB och syftet med uppdraget. Flera verktyg och tekniker togs upp, bland annat programmeringsmiljön Visual studio 2015, multiplattform apputvecklarverktyget Apache Cordova, emulatorn Ripple och HTML5 webbstandarden.
9
Kapitel 3 - Design av användargränssnitt
Den huvudsakliga designen för Rejlers Energiapp kommer att diskuteras i detta kapitel.
Cordovas gränssnitt är utformat så att appar ska kunna konstrueras med webbstandarden HTML5. Dessa appar kallas för hybrida mobilappar, eftersom de byggs upp liknande sätt som en hemsida inom ett plattformsspecifikt skal. Appen består av flera sidor som visar olika data om användarens ägda anläggningar, en flikmeny för navigering samt startsida och loginsida. I kapitlet förklaras också hur appen kommer användea sig av ett bakomliggande API som tillhandahålls av Rejlers. Kapitlet är uppdelat i två avsnitt, Allmän design förklaras i 3.1 och en översikt av de ramverk och bibliotek som används tas upp i 3.2. Allmän design fokuserar på utseendet av appen medan ingående design fokuserar på hur bakomliggande funktioner och dylikt är sammankopplade.
3.1 Allmän design av användargränssnitt
Rejlers Energiapp är utformad så att användaren snabbt och enkelt ska kunna lära sig hur appen används utan större genomgång. Genom att ha ett och samma sidhuvud med menyknappar som alltid visas i applikationen, kan användaren nå alla sidor med få knapptryck. En enda meny för navigation genom appens olika sidor är en vanlig design i dagens appar, exempelvis i Facebook [31], Skype [33] eller Viber [34].
3.1.1 Sidor
Applikationen planerades först att byggas upp med ett antal sidor och efter diskussion slutade det med totalt fem sidor. Tre sidor som visar datan från Rejlers via diagram, mätare och listor samt två sidor för inloggning och inställningar. Alla sidor visas i fig 3.1. De sidor som är tänkta att användas för data är en huvudsida i fig 3.1b, en sida som täcker anläggningar i fig 3.1c och en för grafer i fig 3.1d. Ytterligare sidor som läggs till utöver visningssidorna är en sida för inloggning i fig 3.1a och en annan för inställningar i fig 3.1e. Inloggningssidan kan endast nås när appen slås på för första gången, genom att logga ut via inställningssidan eller när appen slås på och ingen användare är sparad i nuvarande session.
10
Fig. 3.1: Konceptutseende av de fem olika sidorna.
Inloggningssida
Inloggningssidan, i fig 3.1a, är det första användaren ser av appen. Användaren loggar in med uppgifter från Rejlers, appen autentisierar med inloggningsservern och sedan är användaren inloggad och kan börja använda appen. Efter att användaren har loggat in kommer appen visa och behandla data så länge som användaren är inloggad.
Inloggningssidan består av appens logotyp, fält för användarnamn och lösenord, knapp för inloggning och en länk för att få tillbaka lösenordet ifall användaren glömt bort det.
Användaren kan logga ut från appens huvudsidor och komma tillbaka till inloggningssidan.
Huvudsida
Huvudsidan, i fig 1.1b, är det första användaren ska se efter att ha loggat in till appen. I sidans mitt finns ett designelement som visar hur bra det går för användaren i sitt energianvändande.
Detta element emulerar en analog mätare som visar användaren hur mycket energi som konsumeras repektive genereras av ägda anläggningar i jämförelse med en tidigare tidsperiod, exempelvis veckan innan. Under mätaren finns statistik som visar hur mycket bättre eller sämre det har gått.
Anläggningssida
I fig 1.1c illustreras sidan för anläggningar som visar en lista över användarens anläggningar, vilka kan markeras och väljas för att få en anläggnings data uppvisad i grafen och på huvudsidan. En sökruta är placerad i toppen av sidan för att underlätta sökandet efter specifika anläggningar om användaren skulle tänkas ha ett flertal i sin ägo. Användaren kan markera
11
individuella anläggningar eller få alla markerade eller avmarkerade samtidigt genom en knapp.
Grafsida
På sidan för grafer i fig 1.1d visas användarens energianvändning för valda anläggningar i valbara graftyper över valbara tidsperioder från timmar till år. På sidan finns knappar för inställning av tidsperioder och grafer såsom stapel- och linjegraf. Denna sida finns för att visa användaren hur energianvändandet går i helhet för alla eller utvalda anläggningar. Graferna ger en statistisk översikt, men visar också nivån av energisparande likt huvudsidan.
Inställningssida
I inställningssidan, i fig 1.1e, ska användaren kunna ställa in diverse preferenser för utseende av appen, exempelvis färger, standardgraf, tidsperioder för mätning och språk. Inställningar ska kunna återställas till ursprungsinställningarna. Det är här användaren loggar ut från appen genom en lite större knapp på sidan.
3.1.2 Finesser
Detta avsnitt täcker diverse finesser som tänkts användas och används i appen.
Feedback vid tryck
Element som ofta finns tillgängliga i appar är knappar och andra tryckbara objekt. Det är viktigt att visa användaren att ett objekt har nåtts genom att spela upp en grafisk effekt på objektet. I vissa fall kan vibration vara en vettig form av feedback vid tryck, men detta har valts att inte användas, utan istället har grafiska effekter använts.
Orienteringsanpassning
Orienteringsanpassning innebär att en app anpassar sig efter enhetens orientering utan att förlora eller förstöra elementens ursprungliga positionering. Om användaren vänder på telefonen så ska sidhuvudet fortfarande ligga i toppen av skärmen och mätaren på huvudsidan ska ligga centrerat, grafer ska anpassa sig etc.
12 Animationer och övergångar
En design med snygga övergångar ger appen ett professionellt intryck. Appen har inte animerade övergångar mellan flikarna eftersom användaren navigerar mellan dem mycket och att animera varje övergång då är onödig. Mätaren på huvudsidan är animerad där dess visare ska röra sig till sin korrekta position. Visaren är ett HTML5 canvaselement.
3.1.3 Menyknappar
Detta avsnitt täcker de knappar som används för att skifta mellan sidorna. I sidhuvudet finns en list med fyra stycken knappar som används för att navigera mellan huvud-, graf-, anläggnings- och inställningssidan. Knapparna tilldelas Ionicons, ikoner i Ionic-biblioteket [35], som stämmer överens med den tilldelade sidas innehåll för att användaren lätt ska kunna veta vilken knapp som hör till vilken sida. Knapparna lyser upp när användaren markerat en av dem och ett navigationsstreck visar vilken som är markerad.
3.1.4 Stil och CSS
Detta avsnitt täcker stilmallar som övervägts användas i appen.
Tecken- och bakgrundsfärger
Bakgrundsfärgen i sidhuvudet valdes baserat på Rejlers logotyp och hemsida där signaturfärgerna var två varianter av blå. De har färgkoderna #0070BA och #4AA6DD.
Textfärgen på blåa områden är vit för att lättare kunna läsas av användaren.
Typsnitt
Appens typsnitt är det standardiserade typsnittet Microsoft Sans Serif.
Placering av element
Appen består av ett sidhuvud i toppen av sidan som innehåller menyknappar och en dynamisk sidöverskrift som ändras beroende på vilken sida användaren är på för tillfället. Ett canvaselement på huvudsidan täcker hela skärmen utom sidhuvudet, scrollningsbar lista över anläggningar på sidan för anläggningar, element för grafer på grafsidan med knappar för att kunna ställa in olika tidsintervall. På ett innehållsområde under sidhuvudet visas innehållet på de olika visningssidorna, graf på grafsidan, rullningsbar checklista på anläggningssidan och annat grafiskt canvas element på huvudsidan.
13
Fig. 3.2: Koncept av elementplacering
3.1.5 Designval av canvaselement för huvudsidan
I detta avsnitt beskrivs alternativa designelement som övervägts för uppvisning av anläggningarnas energianvändning på huvudsidan. Mitt på huvudsidan ska ett canvaselement finnas som fungerar likt ett rit- och bildhanteringsverktyg och används för att visa användarens nuvarande energianvändning i jämförelse med tidigare mätningar och används även för att inspirera användaren att vara sparsam med energin. Ett antal olika alternativ på designelement har övervägts:
Mätare
Ett av designvalen för uppvisning av användarens energianvändning var en simpel rund analog mätare eller halvrund med en indikatorarm som visar var användarens energianvändning för innevarande tidsperioden ligger gentemot den föregående tidsperioden.
Denna design ansågs vara den mest passande eftersom den inte verkade svår att implementera, passade energitemat och ger användaren en tydlig och överskådlig bild om hur det går med energianvändandet.
Fig 3.3: Konceptbild för mätaren.
14 Träd eller ekosystem
Ett träd som blir större och grönare allteftersom det går bättre eller mindre och kalare ju sämre det går med energianvändandet. Träd är ett vanligt designval i andra liknande applikationer, exempelvis Greenely, men för att undvika att efterlikna dessa för mycket användes inte träd som huvudsakligt designval. Ett annat designval var ett ekosystem som blev grönare och där element som en flod, träd och annat dyker upp allteftersom det går bättre i jämförelse med föregående tidsperiod. Ekosystemet ansågs vara för komplicerat för implementering.
Fig 3.4: Konceptbild för ekosystem.
Smiley, lampa eller en kombination
Ett ansikte som blir gladare ju bättre det går med energianvändningen och vice versa.
Färgändring av ansiktet var en tanke för att tydligare se hur det går med energianvändningen.
En annan design var en glödlampa som går från att vara släckt till att gradvis skina upp. Ju mer användaren sparar och producerar energi desto ljusare ska lampan bli. Smileyn och lampan skulle kunna kombineras genom att sätta ett ansikte på lampan och utnyttja energivisualiserings idéerna från båda elementen.
Fig 3.5: Konceptbild för smiley-lampa kombination.
3.2 Ramverk och bibliotek
Detta avsnitt täcker mer ingående och bakomliggande design för appen. Hur de implementerade komponenterna samarbetar och interagerar med varandra förklaras här.
15
Rejlers Energiapp är skapad med två huvudsakliga ramverk, Ionic och AngularJS, som ligger över grundramverket Cordova. De lägger till fler designrelaterade val samt allmänna funktioner till appen. Ytterligare mindre ramverk för graf och mätare tas upp.
Ionic framework
Ionic [35] är ett Software Development Kit [36] (SDK) för HTML5. Ionic kompletterar Cordovas grundläggande utvecklingsmöjligheter genom att vara ett front-end ramverk med fokus på designmönster och enkelhet. Istället för att bygga applikationen från grunden med HTML5 så hjälper Ionic till med rekommenderade designalternativ, färdiga CSS stilar, övergångar och skript. Ionic har öppen källkod och släppt under en MIT licens vilket betyder att Ionic kan användas helt fritt. För att använda Ionic och dess moduler krävs AngularJS.
AngularJS
AngularJS [37] (förkortat Angular) är ett javaskript-ramverk med öppen källkod som underhålls av bland annat Google och tillhandahåller Angular-funktioner, vilka används för att förlänga HTML attribut med direktiv och att binda data till HTML. En viktig komponent som inkluderas i Angular är möjligheten att skapa moduler. Rejlers Energiapp är en stor modul med flera undermoduler. Moduler definerar separata Angularapplikationer och dessa moduler innehåller också ”controllers” som bestämmer sidor uppbyggnad.
3.2.1 Angularkomponenter
I detta avsnitt beskrivs Angularkomponenter som gör att objekt inom appen kan kommunicera med olika tjänster eller andra objekt. Hur dessa komponenter kommunicerar med varandra tas upp mer ingående i kapitel 4.
Moduler
Moduler kan definieras som applikationer inom appen. Moduler är virtuella behållare i Angularkod och kan jämföras med direktiven ”using” i Java [38] eller ”import” i C# [39].
Modulerna i Rejlers Energiapp innehåller controllers och services och bildar virtuella appar som kan kommunicera med varandra.
16 Controllers
Controllers hämtar och använder data för att bygga upp de olika sidorna i appen och en controller måste vara en del av en modul. En controller skapar allt som behövs för en sida och används till att initiera och manipulera objekt och variablers scope. När en controller är kopplad till ett DOM element, som t.ex body, div, etc., skapas ett scopeobjekt för det elementet. En controller är aktiv så länge sidan är aktiv.
Scope
I programspråk hänvisar ”scope” eller ”tillämpningsområdet” till ett område i programmet där ett visst objekt eller variabel kan tillämpas eller manipuleras. Programmets område är en del i program- eller källkoden och varje variabel har sitt eget scope. Variabler med lexical scope definieras inom kodblock i programkoden och känns igen och kan användas av hela det kodblocket som det har definerats i.
I Angular fungerar scope annorlunda. Ett scope är ett javascriptobjekt som kopplar en sidas DOM element till en controller och varje controller har ett separat scope. Både controllern och tillhörande DOM elementet har tillgång till scopeobjektet och används för kommunikationen mellan dem, datalagring och funktionskörning. Detta kan jämföras med lexical scoping eftersom varje sida har en egen controller med ett eget scope och kan då liknas vid funktioner i något programspråk.
Services
Services (tjänster) är utbytbara objekt i Angular som används för att organisera och dela kod i appen. Det är i en service de flesta av de logiska funktionerna finns. Det finns services för behandling av data, för att öppna menyer och inloggningsfunktioner. En controller kan ha en service som ett beroende vid instansiering och har då möjligheten att anropa denna service och använda dess funktioner när de behövs.
Angular UIRouter och interagering
AngularUI Router är ett ramverk för Angular som organiserar delar i appen till en sk. ruttkarta (route map) som fungerar som en tillståndsmaskin där appens sidor är alla tillstånd som automaten kan ha samt definierar övergångarna mellan dem. Tillstånden är kopplade till
17
sidornas namn och innehåller allt som ska visas och användas av sidan vid givet anrop.
Processen förklaras ingående i avsnitt 4.3.
3.2.2 Tekniska förberedelser
I detta avsnitt tas det upp vad som behövde förberedas innan design och implementering.
Visual Studio 2013/2015
VS13 laddades ned, uppdaterades till version 5 och fick alla nödvändiga insticksmoduler och bibliotek installerade. Senare blev VS13 utbytt till VS15 på grund av att Angular fick konflikter med den tidigare Cordovaversionen på VS13. VS15 innehöll också en mer komplett version av Cordova och Ripple.
Cordova och Ripple
Cordova installerades i VS13 som en del av version 5 för att kunna skapa Cordovaapplikationer. Cordova finns inbyggt i Visual Studio 2015. Med Cordova följer emulatorn Ripple som är en mobilemulator.
REM
REM [4], hemsidan för energitjänster, observerades för inspiration. Majoriteten av funktionerna i REM ska fungera i appen.
Hårdvara
• laptops med VS 2015 installerade
• nätverk-switch för koppling till Rejlers fasta nät
• smartphones med utvecklarläge aktiverat och tillåtelse att installera okända appar för att kunna testa appen på en riktig telefon och inte endast i emulator
Android SDK
Utvecklingsprogrampaketet Android SDK [40] används för att kunna bygga och testa Android-applikationer. Det tillhandahålls av Google och är fritt att använda under deras egen licens. Androids SDK måste vara installerat på datorn som appen utvecklas på. För att vidare felsöka Androidapplikationer användes utvecklarläge för Android smartphones. Det aktiveras genom att gå genom inställningar till ”om mobilen” och trycka på versionsnumret 7 gånger.
18
Utvecklarläget kan användas för att visa aktuella beröringar, CPU-åtgång, skärmuppdateringar och visa hur layoutgränser blir för element i appen på telefonen.
Bibliotek, stylesheets och skript
• Ionic, ramverk med fokus på design och simplicitet.
• Angular, ett bibliotek med tillför extra funktionalitet till Javascript.
• Chartistjs [41], ett bibliotek som skapar grafer utifrån arrayer
• Gaugejs [42], ett bibliotek som skapar circulära mätare likt hastighetsmätare.
3.3 Sammanfattning
I detta kapitel har det tagits upp hur appen ska designas och allmänna tekniska förberedelser.
Användargränssnittet har bestämts hur det ska se ut och det tekniska har lagts upp ramverket och bibliotek som ska utforma appen.
19
Kapitel 4 - Implementation av appen
Detta kapitel går igenom implementationsprocessen av Rejlers EnergiApp och all mjukvara som emulatorer och annan programvara. Kapitlet är uppdelat i fem avsnitt. 4.1, Översikt, ger en överskådlig förklaring av hur appen är implementerad. Avsnitt 4.2, Förklaringar av appens komponenter, visar och förklarar hur appens alla filer och delar fungerar. Avsnitt 4.3, Appens startprocess, går kronologiskt igenom vad som händer i bakgrunden då användaren startat appen. Avsnitt 4.4, App redo för navigering, visar vad som händer på varje sida efter användaren navigerar dit. Detta är efter startprocessen då användaren kan börja använda appen. Slutligen förklaras autentiseringsprotokollet Oauth2 i avsnitt 4.5, Autentisering.
4.1 Översikt
Fig 4.1: Översikt över appens uppbyggnad.
Efter att appen installerats på enheten är den redo för start. Efter att användaren startar applikationen startar Cordovas WebView wrapper, som visas i fig 4.1, som bildar appfönstret där själva appen finns. I wrappern finns index.html som är appens startpunkt. Index.html hämtar alla beroenden och sidor som behövs för att bygga upp appen. En Angularapp skapas
20
som laddar in fler skript och skapar en ruttkarta som behövs för att navigera mellan appens sidor. Appen är sen redo för navigering.
Fig 4.2: Menyn som navigerar mellan olika tillstånd i appen. Varje sida har en controller.
Hur de huvudsakliga komponenterna interagerar med varandra visas i fig 4.3 och beskrivs i nedanstående exempel för inloggning till appen:
1. Användaren loggar in i applikationen via inloggningssidan, i fig 4.4a, som är den första sidan en användare ser när appen startas. Efter att användaren skrivit in användarnamn och lösenord så körs en service som hanterar kommunikation med autentieringsservern för att neka eller ge användaren tillträde.
2. Efter att autentiseringen lyckats instansieras en controller som startar flera services som börjar hämta den data från Rejlers servrar (Rejlers API) som behövs för att denna controller ska kunna bygga upp huvudsidan.
3. Huvudsidan byggs upp med den data som har tagits emot och visas nu för användaren.
När användaren navigerar till andra sidor startas dessa sidors controllers. Dessa controllers anropar olika services för att bygga upp sidan i förväg med hjälp av data från Rejlers servrar.
21
Fig 4.3: Översikt över appens inloggningsprocess.
4.2 Appens komponenter
Projektet består av många olika filer som används av Apache Cordova för att appen ska fungera. Avsnittet går igenom de mest väsentliga filerna som appen behöver. Appens sidor är skrivna i HTML och de visas när användaren navigerar genom appens flikar.
4.2.1 Index.html
Index.html är ett simpelt HTML-dokument och är appens startpunkt där alla olika beroenden importeras och görs redo för användning. Index.html är en sida som innehåller appens komponenter och är inte synlig för användaren. Bland beroenden finns Ionic Framework, Angularbiblioteken och appens egna skriptfiler och Style Sheets. Information om hur data ska visas och hanteras av appen, sk. metadata, fastställs i index.html. Nedan finns ett urval av beroenden i index.html:
Metaelementet viewport visar hur mycket av skärmen som ska tas upp av appen och dess innehåll. Möjligheten att kunna zooma eller på annat sätt kunna ändra storleken eller skalan kan ställas in i viewport. För appens ändamål är denna inställd på standardinställningarna, vilket betyder att ingen zoom är tillämpad och att appen ska ta upp 100 % av skärmen.
Content Security är metataggar styr vilka anrop som får göras från WebView. Det finns redan nätverksfilter i det flesta mobiloperativsystem som filtrerar vilka anrop som får göras, men äldre enheter kan behöva Content Security som komplement. Metataggarna säkerställer mest att appen bara gör anrop till de nätverkskällor den ska göra anrop till och blockerar allt annat.
Cordova.js är Apache Cordovas bibliotek och används för att appen ska kunna nå enhetens hårdvara som exempelvis kameror eller den inbyggda accelerometern.
22
Fig 4.4: a) loginsidan, b) huvudsidan, c) grafsidan, d) anläggningssidan, e) inställningssidan.
4.2.2 Synliga sidor med controllers
Login.html och LoginCtrl
Inloggningssidan som visas i fig. 4.4a, login.html, visas alltid om användaren inte är inloggad. Sidan består av två inputformulär där användaren kan skriva in sitt användarnamn och lösenord för att bli autentiserad i appen. Autentiseringsfunktioner och dylikt förklaras ingående i avsnitt 4.3 och 4.5. Sidans huvudsakliga funktion är att blockera ej autentiserade användare från tillgång till appen. LoginCtrl sköter inloggningsprocessen via diverse autentiseringstjänster i services.js. Efter att användaren har tryckt på loginknappen börjar LoginCtrl att anropa tjänster och beroende på vilket svar den får från dem loggar den in användaren eller inte.
Tabs.html
Tabs.html är en sida med fyra flikar som bildar appens header och visas i fig 4.2 och 4.4.
Denna sida laddas in som förälder till alla andra sidor utom loginsidan. Innehållet under tabs.html aktiveras när användaren trycker på en flik och då visas den tillhörande sidan i innehållsområdet under headern. I ruttkartan agerar sidan som en mellanhand för navigering.
Anl.html och AnlCtrl
Sidan anl.html laddar in REM-anläggningsdatan från en JSON-fil [43] och lägger den i ett kryssliste-form där de kryssade får sin data visad i huvud- och grafsidan. En lista skapas på sidan med hjälp av HTML-, Ionic- och Angular-direktiv. Alla anläggningar hämtas från en JSON-fil som skrivs ut i listan med hjälp av iterationsfunktioner. Då ett listobjekt markeras eller avmarkeras läggs det till respektive tas bort från en aktiv lista av anläggningar genom
23
kontroll av direktivet ng-model= ”checkStatus” vilket binder input till scope och blir tillgänglig för controllern. Förändring av checkStatus tillstånd kontrolleras av direktivet ng- change, vilket används för att upptäcka förändringar i ng-modeller (angularmodeller).
Direktivet anropar uppdateringsfunktioner vilken uppdaterar aktiva anläggningslistan genom att lägga till respektive ta bort anläggningen i listobjektet beroende på checkStatus tillstånd.
En anläggning i varje listobjekt innehåller ett namn, ett id, en beskrivning och en lista av värden för produktion och konsumtion samt en hash-key som läggs till av ng-repeat vilken gör varje objekt unikt i listan. AnlCtrl sköter hämtning av anläggningsdata för anläggningssidan.
Den anropar tjänster som hämtar data från en server. Beroende på vad som markeras i anläggningslistan så uppdaterar AnlCtrl en lista med valda anläggningar som används av andra komponenter.
Home.html och HomeCtrl
Home.html är en startsida där en animerad mätare i ett canvas-element visar aktuell energianvändning för timme/dag/vecka/månad/år i jämförelse med tidigare respektive tidsenhet. Sidan delas in i tre områden, ett huvudområde där mätaren placeras och två underområden där en driftinformation respektive sammanställning av energianvändningen visas. I huvudområdet läggs det in en canvastagg i vilken det skapas en mätare med biblioteket Gauge.js i vilken nuvarande värden jämförs med tidigare värden av de anläggningar som finns i den aktiva anläggningslistan. HomeCtrl körs när användaren är inne på huvudsidan. Det är denna controllers jobb att använda tjänster till mätaren som hämtar data och skapar den.
Dia.html och DiaCtrl
Sidan dia.html visar valda anläggningars enegianvändning i grafer. Biblioteket Chartist används för att skapa grafer av användardatan. Grafen läggs in i en div-tagg genom att tilldela klassen ct-chart vilken tar emot tre parametrar som bestämmer hur grafen ska se ut. DiaCtrl körs medan användaren är inne på sidan för grafer. Controllern hämtar och ordnar listvärden från anläggningarnas JSON-filer. DiaCtrl anropar sedan en tjänst som bygger upp en graf utifrån värdena med hjälp av Chartist.
24 Set.html och SetCtrl
Inställningssidan är Set.html. Den innehåller knappar som visar mer information om appen, en utloggningsknapp och visar alla inställningsalternativ som användaren kan tänkas ändra.
Alla preferenser styrs av SetCtrl och dess services. När utloggsknappen aktiveras rensas cachen, navigationshistoriken, sessionstorage, aktiva anläggningslistan och all användardata bort så att inga rester lämnas kvar från tidigare användare. SetCtrl körs medan användaren är inne på inställningssidan. Denna controller reagerar när användaren trycker på utloggningsknappen. SetCtrl anropar då tjänster som kommer rensa alla spår av den nuvarande användarens session och ta fram inloggningsrutan igen. Controllern hanterar också hur olika fönster som visar data visas och hur de stängs på sidan.
4.2.3 Skript
App.js
I App.js definieras tillstånd för de olika sidorna, vilket innebär att här kopplas en sida ihop med sin respektive controller och en ruttkarta skapas. En rutt är en länk från en URL [44] till sidor med tillhörande controllers. URL-länkarna är simpla, interna länkar som exempelvis
”pages/home.html”.
Ett tillstånd beskriver hur användargränssnitten ser ut och vad användargränssnitten gör. När ett tillstånd har blivit aktiverat sätts alla templates (sidor) in i ion-view i föräldertillståndets template (exempelvis tabs.html). Tillstånd aktiveras genom att navigera till en URL associerad med det tillståndet. Vid vissa tillfällen körs koden state.go(tillstånd) för att aktivera ett tillstånd direkt. När användaren navigerar till ett tillstånd via en URL så laddar stateprovidern den korrekta templaten in i appens huvudområde för visning av sidor och kopplar controllern till templatens scope. Denna process förklaras mer i steg 4 av startprocessen.
Controllers.js
I Controllers.js skrivs alla controllers vilka definierar de scope och funktioner som ska användas i de sidor controllern är sammanlänkad med.
25 Services.js
I Services.js finns alla services samt factories som appen använder. Services returnerar funktioner medan factories returnerar värden. Exempel på en tjänst är ”MeterCanvas” som ritar mätaren på huvudsidan och en av de factories som används i appen är goFetch som hämtar JSON-filer och returnerar innehållet.
4.3 Startprocessen
Detta avsnitt förklarar initieringsprocessen vid appens start och vad som sker i bakgrunden vid navigering för att visa sidor och liknande.
1. Startup-initiering av Cordova
Användaren startar applikationen på enheten. Cordova bildar en wrapper (omslag) och initierar appens startsida vilket bildar själva appen. Cordova är ett omslag till en intern webbläsare (WebView) som innehåller startsidan index.html som i sin tur innehåller alla sidor och funktioner som bildar appen. Wrappern bildar ett appskal som gör att index.html och alla undersidor kan nå enhetens funktioner som exempelvis kamera eller accelerometer om de behövs.
2. Ladda beroenden, bootstrappa Angular
Efter att wrappern skapats så börjar index.html att ladda alla beroenden som appen behöver för att fungera. Det viktigaste beroendet för appen är Angular som skapar appens ruttkarta förklarad i steg 4 i detta avsnitt. Angular initieras inom head-taggen likt alla andra beroenden.
Angular letar per automatik upp ng-app direktivet vilket blir grunden för Angularapplikationen. Om den hittas så förebereder Angular att ladda associerade moduler och controllers. Energiappens ng-app finns i body-taggen med associerad modul
”EnergyApp” och controller ”AppCtrl”.
Angular skapar en injektor som hanterar olika bakgrundsaktiviteter för modulen och kopplar den till WebViewens DOM. Detta gör appens DOM dynamisk och kan ändras i realtid genom Angular. I Rejlers EnergiApp kan nästan allting ändras dynamiskt då ng-app direktivet finns i body-taggen. Denna process som initierar Angular kallas populärt för automatisk "bootstrap".
26
Fig 4.4: Cordovas wrapper som omsluter index.html + beroenden och bildar en WebView.
Det är viktigt att lägga märke till är ng-controller direktivet inom bodyelementet. Controllern AppCtrl skapar ett nytt scopeobjekt som endast kan nås och manipuleras inom just denna bodytagg samt alla underelement i taggen med samma controller.
3. Initiera tillämpade skript, alla moduler kör .config och .run block
App.js är nästa skript som initieras och det är det första skriptet som inte är ett bibliotek- eller ramverksskript. I skriptet finns en modul kallad EnergyApp. Denna modul länkar ihop alla moduler i alla egenskrivna skriptfiler så för ordningens skull är de uppdelade i app.js, controllers.js och services.js.
Moduler kör sina .config och .run kodblock i ordning. Configs körs som ett komplement till modulen, skapar variabler och dylikt, medan .run block kan jämföras med main-funktioner som körs vid appens start och när de blir anropade av någon annan funktion.
4. .config block körs
App.js börjar med ett .configblock som innehåller en ”stateprovider”. Blocket .config stateprovider sätter upp alla möjliga rutter till de olika sidorna så att navigering i appen kan jämföras med en finit automat (state machine). Alla HTML-sidor motsvarar tillstånd som appen kan ha. Om appen försöker nå en odefinierad rutt så omdirigeras appen till loginsidan som standard. Appen har en meny med fyra knappar, tabs.html, och den är abstrakt i ruttkartan eftersom den endast är mellanhand i navigeringen och visar vilken sida som är
27
aktiv. Efter att alla rutter har kartlagts så laddas standardrutten, dvs. loginsidan in i HTML- sidans bodytagg.
fig 4.5: Ruttkarta över appen. Vid varje tillståndsbyte körs en autentiseringskoll.
Services.js har också ett configblock som körs direkt vid appstart, .config AuthInterceptor.
Den används för att initiera interceptorn i applikationen. En HTTP-Interceptor, genskjutare, genskjuter HTTP-anrop innan de lämnas över till en server och genskjuter också svaren från servern. En token är ett objekt för autentiseringssyften och HTTP-anrop. När något gör en förfrågan om att hämta data från en server och använder en felaktig eller utgången token så kommer genskjutaren svara beroende på felmeddelandet den får från servern. Detta hindrar datan från att nå programkoden om fallet var ett felmeddelande. När användaren försöker logga in så skickas en unik token via URL från autentiseringservern som används för den användaren.
5. .run block körs
Blocket .run statechange körs vid appens start samt varje gång användaren byter mellan tillstånd. Den kollar om användaren fortfarande är autentiserad medan bytet äger rum. Om användaren av någon anledning inte skulle vara autentiserad så hindrar den appen att byta till nästa tillstånd utan visar loginrutan. Den är mycket viktig för appens säkerhet.
Blocket .run backbutton körs varje gång tillbakaknappen trycks ned på telefonen eller surfplattan. Om nuvarande tillstånd är loginrutan så avslutas appen när man trycker på den. I andra tillstånd gör inte backknappen någonting.
28
6. Startsidan login.html
När alla .config och .run kodblock har körts fortsätter Angular med att initiera ngcontroller=”AppCtrl” direktivet i bodytaggen. AppCtrl ligger över appens alla tillstånd och reagerar på när användaren inte längre är inloggad av någon anledning. Då visas en popupruta och byter tillstånd till loginsidan.
Efter att alla automatiska funktioner och tjänster har startats och ruttkartan har initierats är användaren på appens loginsida, login.html, genom .run Statechange. Loginsidan har den redan nämnda associerade controllern, LoginCtrl. Den hanterar vad som händer när användaren försöker logga in. När ett giltigt lösenord och användarnamn har skrivits in trycker användaren på loginknappen. Bakgrundstjänsterna returnerar att allt är ok, loginrutan tas bort och controllern dirigerar om tillståndet till huvudsidan, home.html. Om uppgifterna är felaktiga visas en popup som säger att inloggningen misslyckades.
7. Autentisering och säkerhet
När användaren försöker logga in sker mycket i bakgrunden gällande autentisering och säkerhet. När användaren tryckt på loginknappen startas en loginfunktion inom LoginCtrl som förväntar sig en respons från en så kallad promisetjänst [46] innan den loggar in användaren eller ej. Loginfunktionen tar användarnamnet och lösenordet som användaren skrivit in och anropar en promiseservice.
Promiseservicen hjälper till att köra funktioner asynkront och använda dessa funktioners returvärden, oberoende av vad controllern som anlitade promiseservicen eller funktionen håller på med under den tiden. En controller som väntar på något från en promiseservice kan fortsätta att styra logik och anropa andra tjänster. När controllern fått svar från en promiseservice så fortsätter anropsfunktionen som vanligt. Ett vanligt svar från en promiseservice är ”resolve”, om funktionen lyckades, eller ”reject”, om funktionen misslyckades och controllern agerar då beroende på svaret.
8. Promisefunktion VAR LOGIN (username, password)
Promisefunktionen returnerar en resolve(Login success) eller reject(login failed) beroende på om användarnamnet och lösenordet som användaren har skrivit in stämmer överens med Rejlers databas. Om uppgifterna stämmer, levereras en access token från inloggningsservern
29
som används för att identifiera användaren. Denna token lagras i appen och läggs till i alla HTTP-headers framöver för att verifiera att rätt användare hämtar data. LoginCtrl får nu tillbaks ett svar från promiseservicen om att allt är ok och användaren är autentiserad.
LoginCtrl tar bort loginrutan och laddar appens huvudsida genom byte av tillstånd, home.html.
4.4 App redo för navigering
Användaren har nu möjligheten att använda sidhuvudets flikmeny för navigering, tabs.html.
Den har automatiskt byggts upp av stateprovider och är alla andra tillståndens förälder i ruttkartan. Detta betyder att det är denna sida som styr vad som ska visas i appens huvudområde. Anl.html, home.html, dia.html och set.html kan alla nås genom tabs.html.
Gemensamt för alla tillstånd är att innan deras sida visas så körs den tillhörande controllern.
Home.html
I och med att home.html är den första sidan som visas efter autentisering, körs sidans tillhörande controller först, HomeCtrl. Denna controller sköter visningen av mätaren som reflekterar användarens energihantering. Den hämtar också aktuell driftinfo från Rejlers servrar samt visar en sammanfattad rapport om total produktion och total förbrukning i kilowatt-timmar (kWh). Varje gång användaren byter tillstånd till denna sida kollar controllern om användaren ändrat listan av anläggningar. Vid ändring av listan ritas mätaren om för att reflektera detta, annars är den kvar i ursprungligt tillstånd. Mätaren ritas ut med hjälp av gauge.js-biblioteket och listan av anläggningar.
Anl.html
AnlCtrl anropar flera services och factories som hämtar och uppdaterar olika listor med JSON-objekt som är alla anläggningar. Första anropet är till en factory, goFetch, som hämtar en hel JSON-fil till en controllers scope beroende på vilken controller som anropade goFetch.
GoFetch använder sig av promisefunktionen $http för att kunna hämta filen.
Efter detta visas Anl.html som skriver ut anläggningarna i en Ionic-checkbox lista där alla listobjekt är ikryssade första gången sidan visas. Listan är responsiv och kommer köra en funktion i controllern, updateAnl, varje gång användaren markerar/avmarkerar ett listobjekt.
Denna funktion anropar servicen ActiveAnl som hanterar en bakomliggande array som
30
innehåller de listobjekt som har blivit markerade av användaren. Följande funktioner är tillgängliga i ActiveAnl:
• AddAnl lägger till ett element till den aktiva listan och anropas när något markeras i listan.
• remAnl tar bort ett element från den aktiva listan och anropas när något avmarkeras i listan.
• destroyAnl rensar listan från värden och används vid utloggning.
• getAnl hämtar nuvarande aktiva listan. Denna funktion anropas från huvudsidan och grafsidans controllers, eftersom de behöver listan för att kunna visa data.
Med alla listobjekt genereras också en infoikon som användaren kan trycka på. Controllern skickar fram en popupruta som hämtar anläggningsdata för anläggningen som användaren vill se.
Dia.html
DiaCtrls uppgift är att skapa flera listor som används vid grafgenereringen samt skapa grafen på sidan. Controllern hämtar markerade anläggningar från service ActiveAnl med hjälp av funktionen getAnl och itererar igenom dessa för att skapa listor som är kompatibla med Chartist. Efter att alla listor har skapats så anropas service graphFunc för att börja skapa grafen. GraphFunc innehåller en funktion kallad drawGraph som ritar grafen och den innehåller ett antal parametrar:
Första parametern bestämmer var grafen ska ritas med hjälp av namn, klass eller id på divtaggen där den ska vara.
Andra parametern, data, tar emot en array av x-axelsetiketter och en array av y-värden nästlade i ytterligare en array. Arrayen med y-värden nästlas inom en array för annars behöver den även ta emot placering i x-led men när den nästlas känner Chartist av att värdena ska skrivas ut sekventiellt på grafen. Parametern ser ut som följande i kodform:
var data = {labels: [x-axelsetiketter], series: [[y-värden]]};
31
Fig 4.6: Kommando för grafskapande och dess tillhörande graf
Tredje parametern, options, tar emot olika standardalternativ för att bestämma önskat utseende och storlek på grafen oavsett nuvarande upplösning. Av de options som tas emot är bland annat fullWidth: true vilket gör att grafen alltid tar upp hela skärmbredden och behöver inte laddas om vid ändring av skärmorienteringen. Grafen är naturligt något förskjuten åt höger så alternativet padding: { right: 40 } används för att flytta tillbaka grafen 40 pixlar, vilket passar bra för alla testade upplösningar.
Fjärde parametern, responsiveoptions, gör samma sak som options men gör det mer responsivt genom att kolla efter förändringar i skärmstorlek och uppdatera grafen därefter.
Om skärmstorleken faller inom ett visst bestämt intervall kan responsiveoptions kicka in och uppdatera options med alternativ gällande för nuvarande skärmstorleken. Datan och alternativen processeras sedan av Chartist och skriver ut grafen på önskat vis i en div-tagg i dia.html. Dia.html är den enda sidan som inte lagrar en egen cache dvs. den kommer alltid laddas om varje gång användaren navigerar till den. Alla andra sidor behåller sin navigeringshistorik. Det finns knappar för att byta graftyp, visa en rapport och byta tidsintervall där den sistnämnda inte har någon funktion. ”Byta graftyp” knappen fungerar så att om grafen är i antingen linje- eller stapelgraf så byter den till den andra typen av graf och ritar om grafen direkt med samma listor och värden som innan. ”Visa rapport” knappen visar en popupruta med information hämtat från graflistorna. Det är en lista med listobjekt som blivit itererade likt anläggningssidans lista.
32 Set.html
SetCtrls uppgift är att hantera olika modaler i appen som finns exklusivt i set.html. Modaler är Ionic-exklusiva direktiv som används för att skapa HTML-sidor som läggs över andra sidor tillfälligt. SetCtrl definierar tre modaler, manual.html, pref.html och about.html. De får olika id-nummer, eget scope, egen animering och egen sida. Efter att modalerna är redo för visning så visas set.html.
På sidan finns tre knappar som öppnar modalerna samt en knapp som loggar ut användaren.
När en användare trycker på en modalknapp så öppnas och visas modalen. Varje modal kommer ihåg det användaren har ändrat på dem så länge som appen är igång eller om användaren loggar ut. Controllern innehåller olika funktioner som stänger och öppnar modalerna samt rensar alla modaler vid utloggning. Utloggningsknappen använder en logoutfunktion i controllern som i sin tur anropar autentiseringsservicen AuthService logoutfunktion. Denna funktion förstör och rensar alla spår efter användaren. Den gör följande:
• tar bort ActiveAnl-listan över anläggningar
• rensar Autentiseringstokensvariabeln, tar bort den lokalt sparade token samt tar bort token från alla http-headers
• rensar användarnamnet för den inloggade användaren
• rensar historik och cache för alla sidor i appen
Sedan blir användaren skickad till inloggningssidan och får skriva in uppgifterna för inloggning igen.
4.5 Autentisering
Protokollet OAuth2.0 [29] fungerar som så att användaren anger sitt användarnamn och lösenord i ett par formulär som sedan skickas till autentiseringsservern genom HTTP metoden POST. Autentiseringsservern verifierar användarnamnet och lösenordet och om det är korrekt skickas ett 200 OK samt en access_token som användaren sedan kan använda för att efterfråga data från servern. Om användarnamn och/eller löserord är inkorrekt skickas ett 401 NotAutenthicated och användaren får en varning om att något är fel och hålls utloggad.
33
Denna autentiseringsmetod var tänkt att användas vid kommunikation med Rejlers autentiseringsservrar men pga. inkomplett API behövde det aldrig implementeras under projektets gång. Istället användes lokala testfiler som representerade dataservern och egna tokens som inte är från någon server. I fig 4.6 beskrivs autentiseringsprocessen med Oauth2.0
Fig.4.6 Autentiseringsprocessen
34
Kapitel 5 - Resultat
5.1 Testning
Emulatorn Ripple klarar av det mesta som en mobil enhet kan göra. Det finns exempelvis funktionalitet för att ställa om skärmorienteringen, skaka enheten, enhetsmodell, ställa in batterinivå, geolokalisering och annat. Utan att gå genom några menyer kan swipe och touch funktioner testas genom att endast klicka och dra på den emulerade skärmen.
5.1.1 Testning på olika operativsystem
Android
Det är i Androidmiljön [7] som majoriteten av tester har körts. Appen byggs normalt och körs i Ripple i Androidläge där den testas genom inputs som knapptryck, ifyllnad av formulär, svep, simulerade skakningar och inbyggda event. Testning skedde på Androidenheter genom att överföra APK-filen via USB till telefonen och installera dem genom olika filhanterare, exempelvis File Commander. Filen installerades därigenom och öppnades sedan för att testas normalt.
iOS
Appar för iOS [8] går att bygga i VS15 och testas i Ripple med endast några knapptryck.
Appen byggs normalt och Ripple startas upp i iOS-läge, därefter kan appen testas normalt.
Även om Android och iOS skiljer sig mycket lite i emulatorn så måste en Apple Mac användas som utvecklingsenhet för att vara säker på att emuleringen sker korrekt.
Chrome DevTools
Debugverktyget, Chrome Developer Tools [45], användes för att testa programvara och programkod exklusivt för Androidenheter. Genom att koppla en Androidenhet till en dator med Google Chrome installerat så kan man nå verktyget och inspektera appar som körs på enheten direkt i Chrome. Det kan användas som en utökning av VS15 debugverktyg och kan ibland upptäcka fel som kanske inte ses direkt på mobilen eller VS15 debugverktyget inte hittar.
35 Blackberry & Windows Phone
Blackberry [10] behöver specifika förutsättningar för att emulera enheter med Blackberry WebWorks och Blackberrys emulatorer och verktyg är inte kompatibla med senaste versionen av Ripple. Windows Phone [9] emuleras inte genom Ripple utan den emuleras genom Microsofts egen Windows Phone emulator. Windows Phone kräver Hyper-V [47] stöd från processorn för att kunna emuleras och senare versioner av Windows. Varken Blackberry eller Windows Phone användes för testning under projektets gång.
5.1.2 Visual Studio Debugger
Visual Studio har en inbyggd debugger som bygger och förbereder testmiljön Ripple, kopplar konsoller och andra komponenter till testmiljön för att utvecklaren ska kunna avlusa sitt projekt. Debuggern kopplar dessa komponenter till emulatorn:
Javascript Console
Javascript Console visar outputs från debug loggar, javascript felmeddelanden, varningar och andra meddelanden.
DOM explorer
DOM explorer är en del av Visual Studio Debugger som visar hela DOM-strukturen [25] och
tillåter utvecklare att observera och manipulera det under debugprocessen.
