Mobil lösning för intern informationsspridning

Transkript

1 IT Examensarbete 15 hp Juni 2013 Mobil lösning för intern informationsspridning Jonas Eliasson Institutionen för informationsteknologi Department of Information Technology

2

3 Abstract Mobile Solution for In-house Information Distribution Jonas Eliasson Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box Uppsala Nethouse Sverige AB is an IT consultancy in need of a mobile solution to inform participants of in-house events and distribute news to their consultants working in the field. This report describes the planning and development of such a solution. The result of this thesis is a three system-solution. A mobile application where it is possible to view news and information about in-house events, and also receive suitable notifications, a web service which assists the mobile application by providing the corresponding information and finally a website to manage the information and notify mobile clients. Telefon: Telefax: Hemsida: Handledare: Mattias Lyrén Ämnesgranskare: Olle Eriksson Examinator: Olle Gällmo IT Tryckt av: Reprocentralen ITC

4

5 Innehåll 1 Introduktion Uppgiftsbeskrivning Mål och syfte Avgränsningar Bakgrund Vad är en webbtjänst Datautbytesformat XML JSON Aviseringar för mobila enheter Principer för objektorienterad design Metodik Verktyg Implementationsplattform - ASP.NET Web API MVC Entity Framework Windows Phone SDK PushSharp Implementation Principer för objektorienterad design SRP DIP Grundplattformen Domänmodeller, databas och dataaccess Tjänster Aviseringstjänst Exemplifiering av skiktningen Mobilapplikationen Användargränssnitt Registrering för aviseringar Kommunikation med webbtjänsten Inloggning och säkerhet Webbtjänsten Design av resurser Datautbytesformat Administrationsgränssnittet Resultat Mobilapplikationen Vyer och navigation

6 5.1.2 Aviseringar Webbtjänsten Konsumera nyheter och kategorier Registrering för aviseringar Datautbytesformat Administrationsgränssnittet Grundplattformen Slutsats och diskussion Möjliga förbättringar Bilagor 33 A Skisser mobilapplikation 33 B Skärmdumpar mobilapplikation 35 C Skärmdumpar administrationsgränssnitt 38 Referenser 42

7 1 Introduktion Nethouse är ett It-konsultbolag med kontor på fem orter i Sverige och arbetar med Itoch verksamhetsutveckling, med uppdragsgivare både i näringslivet och den offentliga sektorn. Idag har Nethouse ett antal anställda som arbetar ute på plats hos deras uppdragsgivare som bland annat resurskonsulter. Att få ut information om interna händelser och nyheter till dessa, men även de andra anställda, är viktigt, dels för att de ska känna sig uppdaterade med vad som händer men även för att de ska känna tillhörighet till sin faktiska arbetsgivare, Nethouse. Idag publiceras och sprids de interna händelserna och nyheterna via företagets internwebb. Internwebben är dock inte mobilanpassad och från vissa uppdragsgivare saknas möjlighet att överhuvudtaget ansluta sig till denna. 1.1 Uppgiftsbeskrivning För att lösa problemet med att sprida information till alla sina anställda vill Nethouse att en mobilapplikation tas fram. Mobilapplikationen behöver finnas i en version för Google Android, Apple Ios och Microsoft Windows Phone. Vidare önskas möjligheten att skicka aviseringar till de mobila enheterna när vissa nyheter av viktigare karaktär publiceras, för att på ett snabbare sätt uppmärksamma alla anställda om dessa nyheter. Initialt var tanken att mobilapplikationen skulle integreras med den befintliga internwebben som är baserad på Microsoft Sharepoint. Integration med Sharepoint valdes dock bort när det visade sig att nyhetsflödet i mobilapplikationen skiljer sig en hel del från nyhetsflödet på internwebben. Att ta fram en implementation/integration som omvandlar nyhetsflödet från internwebbens format till ett format som passar mobilapplikationen skulle i sig bli ett ganska stort arbete. Det finns även ett viss missnöje med den befintliga internwebben och diskussioner pågår om hur informationsflödet på internwebben möjligen ska förändras i framtiden, vilket skulle kunna leda till att en eventuell integration ganska fort blir inaktuell. Produktägaren tog därför beslutet att en helt separat lösning skulle tas fram och om behov finns i framtiden löser man integration med internwebben då. Som nämnts har Nethouse kontor på flera orter och till en början kommer den framtagna lösning användas av Örebrokontoret. Stöd för flera kontor måste dock tas i beaktande när systemet designas, där de olika kontorens information ska vara isolerade från varandra. 1

8 1.2 Mål och syfte Mål och syfte med examensarbetet är att Skapa en grundplattform för att skicka aviseringar till olika mobila enheter, så som Google Android, Apple Ios och Microsoft Windows Phone. Skapa en nyhets-webbtjänst anpassad för konsumtion av mobila enheter. Skapa en mobilapplikation för Windows Phone som kan ta emot aviseringar om ny information samt kan hämta information för läsning vid behov. Skapa ett enklare gränssnitt för administration och nyhetspublicering. 1.3 Avgränsningar Arbetet innefattar inte att utveckla en version av mobilapplikationen för Google Android eller Apple Ios, utan dessa kommer tas fram vid ett senare skede av Nethouse. Det ingår heller inte att utreda vilken typ av säkerhetslösning som ska används för mobilapplikationen respektive webbtjänsten, detta utreds parallellt av Nethouse, men implementeras under arbetets gång av mig. Vidare ska inget bibliotek för att skicka aviseringar utvecklas, utan tredjepartsbiblioteket PushSharp ska användas. 2

9 2 Bakgrund 2.1 Vad är en webbtjänst Webbtjänster (engelska: Web Services) låter datorer och andra enheter kommunicera med varandra via webben [1]. Idag är det otydligt vilka tjänster på webben som normalt menas med ordet webbtjänst. Fokus för detta arbete har varit webbtjänster som baseras på REST-arkitekturen (REpresentational State Transfer). REST-arkitekturen är en tillståndslös (engelska: Stateless) klient-server-arkitektur som kretsar kring resurser. För REST är resurser första klassens objekt och karaktäriseras av följande: En resurs identifieras (adresseras) unikt med en Uniform Resource Identifier 1 (URI), exempelvis En resurs manipuleras med hjälp av välkända HTTP-metoder, exempelvis GET och POST. En förfrågan till en resurs och förfrågans resultat kan skickas i flera olika representationsformat, så kallade mime types, exempelvis text/html, application/json och image/png. Figur 1 illustrerar resurser, deras adressering och hur de olika HTTP-metoderna vanligtvis implementeras. Resurs GET PUT POST DELETE Enskild Hämta ett element Uppdatera ett element Används generellt inte Ta bort ett element Samling Hämta samlingen Byta ut samlingen Lägg till ett element till samlingen Ta bort samlingen Figur 1: Typisk implementation av resurser och tillhörande HTTP-metoder (inspirerad av [2]). Att REST-arkitekturen är tillståndslös innebär att inget tillstånd eller session lagras åt användaren på servern mellan anrop, utan ett eventuellt tillstånd måste inkluderas av användare vid nästkommande anrop. Fördelen med denna tillståndslöshet är att systemet blir tidsmässigt frikopplat, vilket ofta är önskvärt i distribuerade system som webbtjänster [1]. 1 Identifierare eller namn för en resurs 3

10 2.2 Datautbytesformat För att kunna utbyta information över nätverk konverteras datastrukturer och objekt till ett så kallat datautbytesformat. Två vanligt förekommande datautbytesformat för webbtjänster är XML (extensible Markup Language) [3] och JSON (JavaScript Object Notation) [4]. REST-arkitekturen har inga krav på vilket format som används, men XML och JSON är båda vanligt förekommande. Följande Person-klass (listning 1) i programmeringsspråk C# kommer användas för att exemplifiera hur data kodas i XML respektive JSON i efterföljande sektioner. public class Person public string Name get; set; public int Age get; set; public List< > s get; set; Listning 1: En Person-klass i C# XML XML är ett märkspråk (engelska: Markup Language) som kännetecknas av sina taggar vilka används för uppmärkning av data. XML är designat för att vara lätt att läsa och tolka för datorer, men även för människor [3]. XML används både för att lagra data på filer och som ett datautbytesformat. Nedan (listning 2) följer ett exempel av en instans av Person-klassen kodad i XML. <Person> <Name>John Doe</Name> <Age>29</Age> < s> < > <Type>Home</Type> <Address>john@doe.se</Address> </ > < > <Type>Work</Type> <Address>john@doe.com</Address> </ > </ s> </Person> Listning 2: En instans av Person-klassen serialiserad till XML. 4

11 2.2.2 JSON JSON är ett textbaserat datautbytesformat som tagits fram för att vara enkelt, minimalt och portabelt [4]. Formatet klarar av att representera primitiva datatyper som strängar, nummer, booleska värden samt null, men formatet klarar även objekt och arrayer. Formatet bygger på nyckel-värde-par, där nyckeln alltid är en sträng och värdet kan vara något av de föregående nämna typer. Objekt omringas av, medan arrayer omringas av []. Nedan (listning 3) följer samma exempel av Person-klassen, men kodad i JSON. "Name" : "John Doe", "Age" : 29, " s" : [ "Type" : "Home", "Address" : "john@doe.se", "Type" : "Work", "Address" : "john@doe.com" ] Listning 3: En instans av Person-klassen serialiserad till JSON. 2.3 Aviseringar för mobila enheter För mobila enheter används aviseringar (engelska: Push notifications) när man vill upplysa en användare om att något har hänt, till exempel att ett nytt epostmeddelande har inkommit, utan att kräva ett manuellt ingripande från användaren. En naiv lösning för att uppnå detta vore att låta varje applikation ha en egen implementation av någon typ av tjänst som arbetar i bakgrunden och som meddelar när det finns ny information att tillgå. För en mobil enhet skulle denna lösning ställa till problem. Enheterna har begränsat med resurser (som till exempel batterikapacitet) och skulle påverkas negativt om alla applikationer med stöd för aviseringar ska ligga aktiva i bakgrund och köras. En bättre lösning är istället att man (i) inför en mellanhand, ett slags ombud, som ansvarar för att ta emot och sedan vidarebefordra alla aviseringar (oavsett applikation) som avser en viss mobil enhet och (ii) en bakgrundstjänst (för alla applikationer) på den mobila enheten som mottar och visuellt visar de aviseringar som har skickats via ombudet. Denna lösning är vad Microsoft, Apple och Google använder idag [5] [6] [7]. 5

12 Applikationens webbtjänst A 5, * 2, 3 B Applikation Mobil enhet C 1, 4 Aviseringsombud Aviseringstjänst Figur 2: Illustrerar principen för aviseringsflödet för mobila plattformar (inspirerad av [5]). Vissa detaljer saknas, främst där tillverkarna skiljer sig åt, till exempel kräver både Apple och Google att certifikat används för all kommunikation med deras aviseringsombud, vilket Microsoft inte gör. Följande exemplifierar registrering för aviseringar (se figur 2): 1 Applikationen begär en aviseringsadress. 2 Aviseringsklienten skickar vidare förfrågan till aviseringsombudet 2. 3 Aviseringsombudet returnerar en unik adress för aviseringar. 4 Aviseringsklienten returnerar adressen till applikationen. 5 Applikationen registrerar sig hos sin webbtjänst. Inkluderar aviseringsadressen som webbtjänsten kan använda vid framtida aviseringar. Följande exemplifierar hur en avisering skickas (se figur 2): A Applikations webbtjänst skickar en avisering till aviseringsombudet. B Aviseringsombudet aviserar den mobila enheten. C Aviseringsklienten visar visuellt aviseringen som inkommit eller vidarebefordrar aviseringen till applikationen 3. * Applikationen hämtar den faktiska informationen från sin webbtjänst. 2 Exempelvis: Microsoft Push Notification Service, Apple Push Notification Service eller Google Cloud Messaging 3 Denna hantering skiljer sig åt mellan tillverkarna 6

13 2.4 Principer för objektorienterad design Det finns en uppsättning principer för objektorienterad design som hjälper utvecklare att designa bra system. Principerna representerar samlade tankar och idéer från ett stort antal mjukvaruutvecklare och forskare med många års erfarenhet inom området [8]. Dessa principer sammanfattas av [8] som: The Single-Responsibility Principle (SRP) En klass bör endast ha en anledning att ändras. The Open/Closed Principle (OCP) Klasser bör vara öppna för utvidgning men stängda för modifieringar. The Liskov Substitution Principle (LSP) Subtyper bör kunna ersätta sina bastyper. The Dependency-Inversion Principle (DIP) Högnivå-moduler bör ej bero av lågnivå-moduler, bägge bör bero av abstraktioner. Abstraktioner bör ej bero av detaljer, detaljer bör bero av abstraktioner. The Interface Segregation Principle (ISP) Klienter bör inte vara tvingade att bero av metoder som de ej använder. 7

14 3 Metodik En agil arbetsmetod användes då en stor del av kraven var okända i det initiala skedet och snabbt kunde förändras under tidens gång. Agila arbetsmetoder kännetecknas av att vara flexibla och effektiva på att hantera förändringar i kravspecifikationen [9]. Med agila arbetsmetoder bedrivs arbetet iterativt och i inkrementella steg som öppnar upp för en mer kontinuerlig utvärdering och möjlighet att styra om projektet när förändrade eller nya krav uppkommer. Det finns fler olika typer av agila arbetsmetoder och för detta projekt valdes ett urplock av delar från Scrum [10] som arbetsmetod. Enligt skaparna av Scrum bör dock alla delar av metodiken tillämpas för en lyckad användning av Scrum [10], vilket dock inte var möjligt i detta projekt främst av den anledningen att projektet var ett självständigt examensarbete och de agila arbetsmetoderna förutsätter att man i själva verket arbetar i team, men även dess tidsbegränsade form och att projektet utfördes på distans försvårade en fullständig korrekt användning av metodiken. Nethouse tillhandahöll en produktägare och en Scrummästare. Då projektet var ett självständigt examensarbete bestod utvecklingsteamet enbart av mig. 3.1 Verktyg Nethouse tillhandahöll en HP-dator med Windows 8 Pro, en Samsung-mobiltelefon med Windows Phone 7.5 samt programvaran Visual Studio 2012 Professional. Under utvecklingen av webbtjänsten användes verktyget Fiddler [11] mycket. 3.2 Implementationsplattform - ASP.NET ASP.NET är en samling ramverk anpassade för webben framtaget av Microsoft och används för att bygga webbsidor, webbapplikationer och webbtjänster [12] Web API ASP.NET Web API är ett av ramverken som ingår i ASP.NET-familjen, framtaget för att hjälpa utvecklare att enklare skapa HTTP-tjänster (exempelvis REST-tjänster), som ska vara nåbara från olika typer av klienter [13] MVC ASP.NET MVC är ett annat ramverk som också ingår i ASP.NET-familjen. Det används för att skapa webbsidor som följer Model-View-Controller-konceptet [14]. 8

15 3.2.3 Entity Framework Entity Framework (EF) är en så kallad Object-Relationship Mapper (ORM), vilket används för att hämta och lagra data i en relationsdatabas [15]. EF agerar som ett abstraktionslager för relationsdatabaser och låter utvecklare undgå att behöva skriva SQL-frågor och dylikt Windows Phone SDK Microsoft tillhandahåller ett så kallat Software Development Kit (SDK) för Windows Phone-utveckling som innehåller allt man behöver för att utveckla Windows Phoneapplikationer [16]. Det medföljer en kraftfull Windows Phone-emulator som har stöd för nästan alla funktioner som en motsvarande telefon har, exempelvis kan aviseringar skickas till emulatorn. 3.3 PushSharp Eftersom alla mobila operativsystem idag använder sig av samma typ av idé för att skicka aviseringar (se avsnitt 2.3 Aviseringar för mobila enheter), finns det ramverk att tillgå som hjälper en med att skicka aviseringen till de aviseringsombud man vill stödja med webbtjänsten. Till detta projekt har ramverket PushSharp (version 2.0) valts efter önskemål från Nethouse. PushSharp stödjer i dagsläget Apple (iphone, ipad, Mountain Lion), Android, Windows Phone (7, 7.5, 8) och Windows 8 [17]. Viktigt att påpeka är att ramverket fortfarande utvecklas och dess Application Programming Interface (API) kan inte ses som stabilt, utan förändringar kan komma att ske, vilket man behöver ha i åtanke och ta särskilda åtgärder för när man implementera ramverket. 9

16 4 Implementation Totalt har fyra olika system implementerats: en grundplattform, en webbtjänst, ett administrationsgränssnitt och en mobilapplikation, där grundplattformen och mobilapplikationen har varit av en mer betydande storlek. I detta avsnitt beskrivs ett urplock av de väsentligaste bitarna som utvecklingen av systemen inneburit. 4.1 Principer för objektorienterad design Nethouse kommer troligen i framtiden att utöka system med mer funktionalitet och därför har stor vikt lagts på att efterfölja de kända principer för god objektorienterad design som nämnts i bakgrunden. Två av dessa har påverkat designen av systemet särskilt mycket, dessa är The Single-Responsibility Principle (SRP) och The Dependency- Inversion Principle (DIP) SRP SRP säger att en klass endast bör ha en anledning till att ändras [8]. En klass som har alldeles för många ansvar brukar vara stora och kallas för God classes. En tumregel för att efterfölja SRP är att hålla klasserna små och se till att de har hög kohesion. En liten klass har få instansvariabler och en klass har hög kohesion om dess metoder använder många av klassens instansvariabler. Maximal kohesion uppnås om varje metod använder alla instansvariabler, vilket sällan är möjligt att uppnå dock, men man bör eftersträva hög kohesion [18]. Om man noterar grupperingar av klassens instansvariabler, exempelvis att variabler a och b används uteslutande i funktionerna f och g, medan variablerna c och d används uteslutande i funktionen h, kan det vara ett tecken på att klassen gör mer än en sak och eventuellt kan den delas upp efter dessa grupperingar. De tumregler och tekniker nämnda ovan användes under projektet för att identifiera fall då SRP inte efterföljdes DIP När man försöker efterfölja DIP kan man som tumregel tänka att alla beroenden man har bör vara på abstraktioner och inte konkreta klasser [8]. Listning 4 illustrerar användningen av DIP i projektet 4. Klassen NewsController tillhör administrationsgränssnittet och tar bland annat emot förfrågningar om att skapa eller ändra nyheter. Den som skapar eller ändrar en nyhet kan välja att avisera nyheten och om så är fallet kommer den privata metoden Push att anropas. NewsController känner endast till gränssnittet IPush- Service och att en metod som heter Push finns. Det är någon annan klass som avgör och faktiskt förser (via konstruktorn) NewsController med en konkret implementation av någon IPushService, exempelvis PushSharpFacade. 4 Vissa justeringar och många detaljer borttagna 10

17 public interface IPushService void Push(NewsItem newsitem); public class PushSharpFacade : IPushService public void Push(NewsItem newsitem) //... public class NewsController private readonly IPushService pushservice; public NewsController(IPushService pushservice) this.pushservice = pushservice; private void Push(NewsItem newsitem) pushservice.push(newsitem); Listning 4: Exemplifiering av DIP i projektet (förenklad) Resultatet av DIP är att man får ett system som är löst kopplat (engelska: Loosely coupled) [19], där enskilda moduler eller klasser är enkla att byta ut. Säg att man vill byta ut PushSharp som ramverk för aviseringar. En ny implementation av IPushSharp kan skapas och därefter injiceras, helt utan att ändra eller ens kompilera om NewsController-klassen, vilket förövrigt är i enlighet med The Open/Closed Principle. DIP gör det även lättare att skapa tester till klasser [19]. Exempelvis vill man inte skicka riktiga aviseringar när man testar NewsController, utan när Push i pushservice anropas ska helst inget utföras. Man skapar då en så kallad mock-klass som implementerar IPushService och där metoden Push inte gör något (se listning 5). Mock-klassen injiceras istället för PushServiceFacade-klassen i testfallen för NewsController, vilket resulterar i att inga aviseringar skickas när testen körs. public class PushServiceMock : IPushService public void Push(NewsItem newsitem) Listning 5: En mock-klass av IPushService från listning 4, som inte utför något när metoden Push anropas. Till hjälp för att lyckas med DIP sattes en så kallad Dependency Injection (DI) container i bruk tidigt i projektet. En DI container hjälper till med att injicera rätt konkret klass för ett visst beroende som en annan klass har. Det är inte på något sätt ett krav att använda en DI container för att efterfölja DIP, men det hjälper till en hel del när 11

18 DIP tillsammans med konstruktorinjektion kan ha en annan positiv påverkan och hjälpa till med att identifiera när en klass bryter mot SRP. När konstruktorn för en klass börjar få många argument (därmed många beroenden) signalerar det att klassen i fråga kanske har mer än en anledning att ändras och då bryter mot SRP [19]. Man kan då undersöka vilka beroenden som används tillsammans och försöka extrahera dessa till en egen klass. 4.2 Grundplattformen Grundplattformen (och systemet i helhet) är uppdelad i ett antal lager. Figur 3 nedan illustrerar vilka lager som finns och deras relationer till varandra. Illustrationen visar även vilka lager webbtjänsten och administrationsgränssnittet interagerar med. Domänmodeller Dataaccess DB Tjänster Aviseringstjänst Webbtjänsten systemen blir större [19]. Istället för att manuellt knyta samman alla beroenden vid applikations startpunkt låter man DI container göra det automatiskt. Som DI container för projektet användes Unity 5 [20] och alla beroenden injicerades via klasserna konstruktorer. Administrationsgränssnittet Figur 3: Grundplattformens skiktning Figur 4 exemplifierar mer i detalj hur skiktning tillsammans med DIP används i projektet. Alla beroenden är på abstraktioner, gränssnitt i detta fall, och tre lager visas; Repositories och Services (grundplattformen) samt Controllers (webbtjänsten). 5 Framtaget av en grupp människor på Microsoft 12

19 Grundplattformen Repositories Device Repository Implementation <<interface>> Device Repository Services Device Service Implementation <<interface>> Device Service Webbtjänsten Controllers Device Controller Figur 4: Exemplifiering av skiktning och DIP för projektet (i själva verket är gränssnitt och konkreta implementationer placerade i separata projekt) Domänmodeller, databas och dataaccess För systemet definierades ett antal domänmodeller: NewsItem, Category, Office, Image och Device, som beskriver nyheter, kategorier, kontor, bilder respektive enheter. Domänmodellerna är placerade i ett eget projekt (lager) och saknar själva några beroenden, istället har i princip alla andra lager ett beroende på domänmodellerna. Databas är upptill Nethouse att välja vid produktionssättning, vid utveckling har SQL Server Compact används. Systemet kräver en databas som är kompatibel med Microsoft Entity Framework (EF). Utvecklingen av databasen har skett med arbetsflödet Code-First development för EF. Code-First development låter användaren definiera domänmodeller med vanliga POCOklasser 6 och därefter generera databasen utefter dessa modeller. Listning 6 visar domänmodellen som beskriver enheter i systemet. 6 Plain Old CLR Object - vanligt.net objekt 13

20 public abstract class Device public Guid DeviceId get; set; public string PushId get; set; public DateTime LastSyncedAt get; set; public int PushedNewsCounter get; set; public void ResetPushedNewsCounter() PushedNewsCounter = 0; //... Listning 6: Domänmodellen Device som beskriver enheter i system (vissa detaljer borttagna). För att isolera beroenden samt användningen av EF, skapades så kallade repositoryklasser för alla domänmodeller. Tjänsterna i tjänstelagret (eller andra klasser för den delen) gör aldrig några direkta anrop till EF, utan deras anrop är alltid till någon av repository-klasserna Tjänster All interaktion med grundplattformen från webbtjänsten och administrationsgränssnittet sker via någon av de tjänster som skapats. Tjänsterna tar emot förfrågningar från webbtjänsten och administrationsgränssnittet som de validerar och exekverar. Det kan handla om att validera att användaren har rättigheter till en viss resurs eller att injicera användarens kontor i frågan till dataaccesslagret för att exempelvis endast hämta alla nyheter tillhörande användarens kontor Aviseringstjänst För aviseringar implementerades ramverket PushSharp. När man använder sig av tredjeparts bibliotek måste man ta i beaktande hur stor risk det är att dess API kan komma att förändras eller att man kommer vilja byta till ett annat bibliotek i framtiden. Finns en risk för detta bör man se till att isolera användningen av biblioteket så att en framtida ändring är enkel att utföra och inte kräver ändringar runt om i hela kodbasen. Då Push- Sharp fortfarande utvecklas kraftigt och dess API kan komma att ändras vid framtida uppdateringar var det viktigt att ramverket separerades från projektet i övrigt. Lösningen var att isolera all kod rörande PushSharp i ett separat projekt och definiera ett gränssnitt (engelska: Interface) för aviseringar som den egna kodbasen kunde bero av (se listning 7). 14

21 public interface IPushService void Push(NewsItem newsitem, Device device); Listning 7: Gränssnitt för att skicka aviseringar. Gränssnittet ovan implementerades sedan i det separata PushSharp-projektet. Sker i framtiden förändringar i PushSharps API är de ändringarna som man behöver göra isolerade till det projektet. Vill man vid ett senare skede byta till något annat ramverk för aviseringar kan man på nytt implementera gränssnittet ovan med det nya ramverket och använda den implementationen i stället Exemplifiering av skiktningen Följande kod-listningar visar vilka metoder som är involverade med att uppdatera en registrering av en befintlig enhet samt i vilka lager dessa metoder finns. Listning 8 visar metoden som tar emot uppdateringsförfrågan i webbtjänsten och vidarebefordrar den till tjänstelagret där UpdateDevice som syns i listning 9 tar över och utför affärslogiken kring uppdateringen. Därefter anropas Update i dataaccesslagret (listning 10) som låter dess basklass utföra själva uppdateringen i UpdateOnCommit som syns i listning 11. public HttpResponseMessage PutDevice(DeviceDto devicedto) if (ModelState.IsValid) deviceservice.updatedevice(devicedto); return Request.CreateResponse(HttpStatusCode.OK); else return Request.CreateResponse(HttpStatusCode.BadRequest); Listning 8: Metoden PutDevice (från DeviceController i webbtjänsten) som hanterar registreringsuppdateringar via PUT-förfrågningar från mobila klienter. 15

22 public void UpdateDevice(DeviceDto devicedto) var device = GetDeviceById(deviceDto.DeviceId); if (device!= null) device.pushid = devicedto.pushid; device.resetpushednewscounter(); device.lastsyncedat = DateTime.Now; devicerepository.update(device); unitofwork.savechanges(); Listning 9: Metoden UpdateDevice (från DeviceService i grundplattformens tjänstelager) som utför affärslogiken gällande registreringsuppdateringar. public void Update(Device device) UpdateOnCommit(device); Listning 10: Metoden Update (från DeviceRepository i grundplattformens dataaccesslager) som anropar basklassens uppdateringsmetod. protected virtual void UpdateOnCommit(T entity) if (entity == null) throw new ArgumentNullException("entity"); if (context.entry(entity).state == EntityState.Detached) set.attach(entity); context.entry(entity).state = EntityState.Modified; Listning 11: Metoden UpdateOnCommit (från EFRepository i grundplattformens dataaccesslager) som är basklassen till alla repositories. 4.3 Mobilapplikationen Iföljande sektion beskrivs några av de väsentligaste delarna från utvecklingen och implementationen av mobilapplikationen. För att referera till mobilapplikationen kommer även mobilappen samt appen att användas. 16

23 4.3.1 Användargränssnitt För att ta fram en design samt för att välja färger till mobilappen fanns två val, antingen kunde Nethouse grafiska profil efterföljas eller så kunde det temakoncept som Microsoft tillhandahåller för Windows Phone användas. Efter diskussion föll valet på temakonceptet istället för den grafiska profilen, dels då vissa användare föredrar ljus text mot mörk bakgrund och andra tvärtom vilket då automatiskt anpassar sig efter användarens preferenser och dels för att det ger appen en känsla av att vara en ursprungsapplikation (engelska: Native application). Skisser togs fram för användargränssnittet (se bilaga A Skisser mobilapplikation på sidan 33) som med avsikt försöker utnyttja några av plattformens kännetecken för att skapa känslan av en nativ applikation. Tanken var inte att skapa en design som även var applicerbar för de övriga plattformarna, utan tanken var att varje mobilapplikation skulle utnyttja den egna plattformens styrkor. Ett tydligt exempel är valet av komponenten som används för att växla mellan senaste nytt och de olika kategorierna, kallad Pivot control. En pivot control ger ett enkelt och snabbt sätt att växla mellan olika vyer och används flitigt i appar för att visa samma innehålla men filtrerat efter olika kriterier, vilket är passande här, där man filtrerar antingen efter senaste nytt eller efter en kategori. För att byta vy sveper (engelska: Swipe) man horisontellt på valfri del av ytan. Fortsätter man att svepa i samma riktning cirkulerar man runt alla vyer, som figur 5 illustrerar. Figur 5: Användaren kan navigera mellan senaste nytt och de olika kategorierna genom att svepa horisontellt över skärmen. Nyheterna hämtas dynamiskt när de behövs. Normalt skapar man pivot-kontrollen statiskt vid kompilering, detta är dock inte möjligt för mobilappen, då det saknas fördefinierade kategorier. Vad som behövs är istället att dynamiskt skapa de pivot-vyer som behövs under körning. Efter att användaren loggat 17