IT 13 043

Examensarbete 15 hpJuni 2013

Mobil lösning för intern informationsspridning

Jonas Eliasson

Institutionen för informationsteknologiDepartment of Information Technology

Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala Telefon: 018 – 471 30 03 Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student

Abstract

Mobile Solution for In-house Information Distribution

Jonas Eliasson

Nethouse Sverige AB is an IT consultancy in need of a mobile solution to informparticipants of in-house events and distribute news to their consultants working in thefield. This report describes the planning and development of such a solution. Theresult of this thesis is a three system-solution. A mobile application where it ispossible to view news and information about in-house events, and also receivesuitable notifications, a web service which assists the mobile application by providingthe corresponding information and finally a website to manage the information andnotify mobile clients.

Tryckt av: Reprocentralen ITCIT 13 043Examinator: Olle GällmoÄmnesgranskare: Olle ErikssonHandledare: Mattias Lyrén

Innehall1 Introduktion 1

1.1 Uppgiftsbeskrivning . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Mal och syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Avgransningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Bakgrund 32.1 Vad ar en webbtjanst . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Datautbytesformat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.2 JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 Aviseringar for mobila enheter . . . . . . . . . . . . . . . . . . . . . 52.4 Principer for objektorienterad design . . . . . . . . . . . . . . . . . . 7

3 Metodik 83.1 Verktyg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Implementationsplattform - ASP.NET . . . . . . . . . . . . . . . . . 8

3.2.1 Web API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2.2 MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2.3 Entity Framework . . . . . . . . . . . . . . . . . . . . . . . 93.2.4 Windows Phone SDK . . . . . . . . . . . . . . . . . . . . . 9

3.3 PushSharp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Implementation 104.1 Principer for objektorienterad design . . . . . . . . . . . . . . . . . . 10

4.1.1 SRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.1.2 DIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.2 Grundplattformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2.1 Domanmodeller, databas och dataaccess . . . . . . . . . . . . 134.2.2 Tjanster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2.3 Aviseringstjanst . . . . . . . . . . . . . . . . . . . . . . . . . 144.2.4 Exemplifiering av skiktningen . . . . . . . . . . . . . . . . . 15

4.3 Mobilapplikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.3.1 Anvandargranssnitt . . . . . . . . . . . . . . . . . . . . . . . 174.3.2 Registrering for aviseringar . . . . . . . . . . . . . . . . . . 184.3.3 Kommunikation med webbtjansten . . . . . . . . . . . . . . 194.3.4 Inloggning och sakerhet . . . . . . . . . . . . . . . . . . . . 20

4.4 Webbtjansten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.4.1 Design av resurser . . . . . . . . . . . . . . . . . . . . . . . 224.4.2 Datautbytesformat . . . . . . . . . . . . . . . . . . . . . . . 22

4.5 Administrationsgranssnittet . . . . . . . . . . . . . . . . . . . . . . . 22

5 Resultat 235.1 Mobilapplikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.1 Vyer och navigation . . . . . . . . . . . . . . . . . . . . . . 23

5.1.2 Aviseringar . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.2 Webbtjansten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2.1 Konsumera nyheter och kategorier . . . . . . . . . . . . . . . 275.2.2 Registrering for aviseringar . . . . . . . . . . . . . . . . . . 285.2.3 Datautbytesformat . . . . . . . . . . . . . . . . . . . . . . . 29

5.3 Administrationsgranssnittet . . . . . . . . . . . . . . . . . . . . . . . 315.4 Grundplattformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6 Slutsats och diskussion 326.1 Mojliga forbattringar . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Bilagor 33

A Skisser mobilapplikation 33

B Skarmdumpar mobilapplikation 35

C Skarmdumpar administrationsgranssnitt 38

Referenser 42

1 Introduktion

Nethouse ar ett It-konsultbolag med kontor pa fem orter i Sverige och arbetar med It-och verksamhetsutveckling, med uppdragsgivare bade i naringslivet och den offentligasektorn.

Idag har Nethouse ett antal anstallda som arbetar ute pa plats hos deras uppdragsgivaresom bland annat resurskonsulter. Att fa ut information om interna handelser och ny-heter till dessa, men aven de andra anstallda, ar viktigt, dels for att de ska kanna siguppdaterade med vad som hander men aven for att de ska kanna tillhorighet till sinfaktiska arbetsgivare, Nethouse. Idag publiceras och sprids de interna handelserna ochnyheterna via foretagets internwebb. Internwebben ar dock inte mobilanpassad och franvissa uppdragsgivare saknas mojlighet att overhuvudtaget ansluta sig till denna.

1.1 Uppgiftsbeskrivning

For att losa problemet med att sprida information till alla sina anstallda vill Nethouseatt en mobilapplikation tas fram. Mobilapplikationen behover finnas i en version forGoogle Android, Apple Ios och Microsoft Windows Phone. Vidare onskas mojlighetenatt skicka aviseringar till de mobila enheterna nar vissa nyheter av viktigare karaktarpubliceras, for att pa ett snabbare satt uppmarksamma alla anstallda om dessa nyhe-ter.

Initialt var tanken att mobilapplikationen skulle integreras med den befintliga intern-webben som ar baserad pa Microsoft Sharepoint. Integration med Sharepoint valdesdock bort nar det visade sig att nyhetsflodet i mobilapplikationen skiljer sig en heldel fran nyhetsflodet pa internwebben. Att ta fram en implementation/integration somomvandlar nyhetsflodet fran internwebbens format till ett format som passar mobil-applikationen skulle i sig bli ett ganska stort arbete. Det finns aven ett viss missnojemed den befintliga internwebben och diskussioner pagar om hur informationsflodetpa internwebben mojligen ska forandras i framtiden, vilket skulle kunna leda till atten eventuell integration ganska fort blir inaktuell. Produktagaren tog darfor beslutetatt en helt separat losning skulle tas fram och om behov finns i framtiden loser manintegration med internwebben da.

Som namnts har Nethouse kontor pa flera orter och till en borjan kommer den fram-tagna losning anvandas av Orebrokontoret. Stod for flera kontor maste dock tas i beak-tande nar systemet designas, dar de olika kontorens information ska vara isolerade franvarandra.

1

1.2 Mal och syfte

Mal och syfte med examensarbetet ar att

• Skapa en grundplattform for att skicka aviseringar till olika mobila enheter, sasom Google Android, Apple Ios och Microsoft Windows Phone.

• Skapa en nyhets-webbtjanst anpassad for konsumtion av mobila enheter.

• Skapa en mobilapplikation for Windows Phone som kan ta emot aviseringar omny information samt kan hamta information for lasning vid behov.

• Skapa ett enklare granssnitt for administration och nyhetspublicering.

1.3 Avgransningar

Arbetet innefattar inte att utveckla en version av mobilapplikationen for Google Andro-id eller Apple Ios, utan dessa kommer tas fram vid ett senare skede av Nethouse. Detingar heller inte att utreda vilken typ av sakerhetslosning som ska anvands for mobil-applikationen respektive webbtjansten, detta utreds parallellt av Nethouse, men imple-menteras under arbetets gang av mig. Vidare ska inget bibliotek for att skicka avise-ringar utvecklas, utan tredjepartsbiblioteket PushSharp ska anvandas.

2

2 Bakgrund

2.1 Vad ar en webbtjanst

Webbtjanster (engelska: Web Services) later datorer och andra enheter kommuniceramed varandra via webben [1]. Idag ar det otydligt vilka tjanster pa webben som normaltmenas med ordet webbtjanst. Fokus for detta arbete har varit webbtjanster som baseraspa REST-arkitekturen (REpresentational State Transfer).

REST-arkitekturen ar en tillstandslos (engelska: Stateless) klient-server-arkitektur somkretsar kring resurser. For REST ar resurser forsta klassens objekt och karaktariserasav foljande:

• En resurs identifieras (adresseras) unikt med en Uniform Resource Identifier1

(URI), exempelvis http://exempel.se/api/produkt/2.

• En resurs manipuleras med hjalp av valkanda HTTP-metoder, exempelvis GEToch POST.

• En forfragan till en resurs och forfragans resultat kan skickas i flera olika repre-sentationsformat, sa kallade mime types, exempelvis text/html, application/jsonoch image/png.

Figur 1 illustrerar resurser, deras adressering och hur de olika HTTP-metoderna van-ligtvis implementeras.

Ta bort samlingen

DELETE

Ta bort ett element

POST

Lägg till ett element till samlingen

Används generellt inte

Uppdatera ett element

PUT

Byta ut samlingen

GET

Hämta samlingen

Hämta ett element

Resurs

Samlinghttp://exempel.se/resurs

Enskildhttp://exempel.se/resurs/<id>

Figur 1: Typisk implementation av resurser och tillhorande HTTP-metoder (inspirerad av [2]).

Att REST-arkitekturen ar tillstandslos innebar att inget tillstand eller session lagras atanvandaren pa servern mellan anrop, utan ett eventuellt tillstand maste inkluderas avanvandare vid nastkommande anrop. Fordelen med denna tillstandsloshet ar att sys-temet blir tidsmassigt frikopplat, vilket ofta ar onskvart i distribuerade system somwebbtjanster [1].

1Identifierare eller namn for en resurs

3

2.2 Datautbytesformat

For att kunna utbyta information over natverk konverteras datastrukturer och objekttill ett sa kallat datautbytesformat. Tva vanligt forekommande datautbytesformat forwebbtjanster ar XML (eXtensible Markup Language) [3] och JSON (JavaScript ObjectNotation) [4]. REST-arkitekturen har inga krav pa vilket format som anvands, menXML och JSON ar bada vanligt forekommande.

Foljande Person-klass (listning 1) i programmeringssprak C# kommer anvandas for attexemplifiera hur data kodas i XML respektive JSON i efterfoljande sektioner.

public class Person{

public string Name { get; set; }public int Age { get; set; }public List<Email> Emails { get; set; }

}

Listning 1: En Person-klass i C#.

2.2.1 XML

XML ar ett marksprak (engelska: Markup Language) som kannetecknas av sina taggarvilka anvands for uppmarkning av data. XML ar designat for att vara latt att lasa ochtolka for datorer, men aven for manniskor [3]. XML anvands bade for att lagra data pafiler och som ett datautbytesformat. Nedan (listning 2) foljer ett exempel av en instansav Person-klassen kodad i XML.

<Person><Name>John Doe</Name><Age>29</Age><Emails>

<Email><Type>Home</Type><Address>john@doe.se</Address>

</Email><Email>

<Type>Work</Type><Address>john@doe.com</Address>

</Email></Emails>

</Person>

Listning 2: En instans av Person-klassen serialiserad till XML.

4

2.2.2 JSON

JSON ar ett textbaserat datautbytesformat som tagits fram for att vara enkelt, minimaltoch portabelt [4]. Formatet klarar av att representera primitiva datatyper som strangar,nummer, booleska varden samt null, men formatet klarar aven objekt och arrayer. For-matet bygger pa nyckel-varde-par, dar nyckeln alltid ar en strang och vardet kan varanagot av de foregaende namna typer. Objekt omringas av { }, medan arrayer omring-as av [ ]. Nedan (listning 3) foljer samma exempel av Person-klassen, men kodad iJSON.

{"Name" : "John Doe","Age" : 29,"Emails" : [

{"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 for mobila enheter

For mobila enheter anvands aviseringar (engelska: Push notifications) nar man vill upp-lysa en anvandare om att nagot har hant, till exempel att ett nytt epostmeddelande harinkommit, utan att krava ett manuellt ingripande fran anvandaren. En naiv losning foratt uppna detta vore att lata varje applikation ha en egen implementation av nagon typav tjanst som arbetar i bakgrunden och som meddelar nar det finns ny information atttillga. For en mobil enhet skulle denna losning stalla till problem. Enheterna har be-gransat med resurser (som till exempel batterikapacitet) och skulle paverkas negativtom alla applikationer med stod for aviseringar ska ligga aktiva i bakgrund och koras.En battre losning ar istallet att man (i) infor en mellanhand, ett slags ombud, som an-svarar for att ta emot och sedan vidarebefordra alla aviseringar (oavsett applikation)som avser en viss mobil enhet och (ii) en bakgrundstjanst (for alla applikationer) paden mobila enheten som mottar och visuellt visar de aviseringar som har skickats viaombudet. Denna losning ar vad Microsoft, Apple och Google anvander idag [5] [6][7].

5

Aviserings-ombud

Applikationenswebbtjänst

B5, * 2, 3

A

Mobil enhet

Applikation Aviserings-tjänst

C1, 4

Figur 2: Illustrerar principen for aviseringsflodet for mobila plattformar (inspirerad av [5]). Vis-sa detaljer saknas, framst dar tillverkarna skiljer sig at, till exempel kraver bade Appleoch Google att certifikat anvands for all kommunikation med deras aviseringsombud,vilket Microsoft inte gor.

Foljande exemplifierar registrering for aviseringar (se figur 2):

1 Applikationen begar en aviseringsadress.

2 Aviseringsklienten skickar vidare forfragan till aviseringsombudet2.

3 Aviseringsombudet returnerar en unik adress for aviseringar.

4 Aviseringsklienten returnerar adressen till applikationen.

5 Applikationen registrerar sig hos sin webbtjanst. Inkluderar aviseringsadressensom webbtjansten kan anvanda vid framtida aviseringar.

Foljande exemplifierar hur en avisering skickas (se figur 2):

A Applikations webbtjanst skickar en avisering till aviseringsombudet.

B Aviseringsombudet aviserar den mobila enheten.

C Aviseringsklienten visar visuellt aviseringen som inkommit eller vidarebefordraraviseringen till applikationen3.

* Applikationen hamtar den faktiska informationen fran sin webbtjanst.2Exempelvis: Microsoft Push Notification Service, Apple Push Notification Service eller Google Cloud Mes-saging

3Denna hantering skiljer sig at mellan tillverkarna

6

2.4 Principer for objektorienterad design

Det finns en uppsattning principer for objektorienterad design som hjalper utvecklareatt designa bra system. Principerna representerar samlade tankar och ideer fran ettstort antal mjukvaruutvecklare och forskare med manga ars erfarenhet inom omradet[8]. Dessa principer sammanfattas av [8] som:

• The Single-Responsibility Principle (SRP)En klass bor endast ha en anledning att andras.

• The Open/Closed Principle (OCP)Klasser bor vara oppna for utvidgning men stangda for modifieringar.

• The Liskov Substitution Principle (LSP)Subtyper bor kunna ersatta sina bastyper.

• The Dependency-Inversion Principle (DIP)Hogniva-moduler bor ej bero av lagniva-moduler, bagge bor bero av abstraktio-ner. Abstraktioner bor ej bero av detaljer, detaljer bor bero av abstraktioner.

• The Interface Segregation Principle (ISP)Klienter bor inte vara tvingade att bero av metoder som de ej anvander.

7

3 Metodik

En agil arbetsmetod anvandes da en stor del av kraven var okanda i det initiala skedetoch snabbt kunde forandras under tidens gang. Agila arbetsmetoder kannetecknas avatt vara flexibla och effektiva pa att hantera forandringar i kravspecifikationen [9]. Medagila arbetsmetoder bedrivs arbetet iterativt och i inkrementella steg som oppnar uppfor en mer kontinuerlig utvardering och mojlighet att styra om projektet nar forandradeeller nya krav uppkommer.

Det finns fler olika typer av agila arbetsmetoder och for detta projekt valdes ett urplockav delar fran Scrum [10] som arbetsmetod. Enligt skaparna av Scrum bor dock alladelar av metodiken tillampas for en lyckad anvandning av Scrum [10], vilket dock intevar mojligt i detta projekt framst av den anledningen att projektet var ett sjalvstandigtexamensarbete och de agila arbetsmetoderna forutsatter att man i sjalva verket arbe-tar i team, men aven dess tidsbegransade form och att projektet utfordes pa distansforsvarade en fullstandig korrekt anvandning av metodiken. Nethouse tillhandaholl enproduktagare och en Scrummastare. Da projektet var ett sjalvstandigt examensarbetebestod utvecklingsteamet enbart av mig.

3.1 Verktyg

Nethouse tillhandaholl en HP-dator med Windows 8 Pro, en Samsung-mobiltelefonmed Windows Phone 7.5 samt programvaran Visual Studio 2012 Professional. Underutvecklingen av webbtjansten anvandes verktyget Fiddler [11] mycket.

3.2 Implementationsplattform - ASP.NET

ASP.NET ar en samling ramverk anpassade for webben framtaget av Microsoft ochanvands for att bygga webbsidor, webbapplikationer och webbtjanster [12].

3.2.1 Web API

ASP.NET Web API ar ett av ramverken som ingar i ASP.NET-familjen, framtaget foratt hjalpa utvecklare att enklare skapa HTTP-tjanster (exempelvis REST-tjanster), somska vara nabara fran olika typer av klienter [13].

3.2.2 MVC

ASP.NET MVC ar ett annat ramverk som ocksa ingar i ASP.NET-familjen. Det anvandsfor att skapa webbsidor som foljer Model-View-Controller-konceptet [14].

8

3.2.3 Entity Framework

Entity Framework (EF) ar en sa kallad Object-Relationship Mapper (ORM), vilketanvands for att hamta och lagra data i en relationsdatabas [15]. EF agerar som ettabstraktionslager for relationsdatabaser och later utvecklare undga att behova skrivaSQL-fragor och dylikt.

3.2.4 Windows Phone SDK

Microsoft tillhandahaller ett sa kallat Software Development Kit (SDK) for WindowsPhone-utveckling som innehaller allt man behover for att utveckla Windows Phone-applikationer [16]. Det medfoljer en kraftfull Windows Phone-emulator som har stodfor nastan alla funktioner som en motsvarande telefon har, exempelvis kan aviseringarskickas till emulatorn.

3.3 PushSharp

Eftersom alla mobila operativsystem idag anvander sig av samma typ av ide for attskicka aviseringar (se avsnitt 2.3 Aviseringar for mobila enheter), finns det ramverk atttillga som hjalper en med att skicka aviseringen till de aviseringsombud man vill stodjamed webbtjansten. Till detta projekt har ramverket PushSharp (version 2.0) valts efteronskemal fran Nethouse.

PushSharp stodjer i dagslaget Apple (iPhone, iPad, Mountain Lion), Android, WindowsPhone (7, 7.5, 8) och Windows 8 [17]. Viktigt att papeka ar att ramverket fortfarandeutvecklas och dess Application Programming Interface (API) kan inte ses som stabilt,utan forandringar kan komma att ske, vilket man behover ha i atanke och ta sarskildaatgarder for nar man implementera ramverket.

9

4 Implementation

Totalt har fyra olika system implementerats: en grundplattform, en webbtjanst, ett ad-ministrationsgranssnitt och en mobilapplikation, dar grundplattformen och mobilapp-likationen har varit av en mer betydande storlek. I detta avsnitt beskrivs ett urplock avde vasentligaste bitarna som utvecklingen av systemen inneburit.

4.1 Principer for objektorienterad design

Nethouse kommer troligen i framtiden att utoka system med mer funktionalitet ochdarfor har stor vikt lagts pa att efterfolja de kanda principer for god objektorienterad de-sign som namnts i bakgrunden. Tva av dessa har paverkat designen av systemet sarskiltmycket, dessa ar The Single-Responsibility Principle (SRP) och The Dependency-Inversion Principle (DIP).

4.1.1 SRP

SRP sager att en klass endast bor ha en anledning till att andras [8]. En klass som haralldeles for manga ansvar brukar vara stora och kallas for God classes. En tumregelfor att efterfolja SRP ar att halla klasserna sma och se till att de har hog kohesion.En liten klass har fa instansvariabler och en klass har hog kohesion om dess metoderanvander manga av klassens instansvariabler. Maximal kohesion uppnas om varje me-tod anvander alla instansvariabler, vilket sallan ar mojligt att uppna dock, men man borefterstrava hog kohesion [18]. Om man noterar grupperingar av klassens instansvariab-ler, exempelvis att variabler a och b anvands uteslutande i funktionerna f och g, medanvariablerna c och d anvands uteslutande i funktionen h, kan det vara ett tecken pa attklassen gor mer an en sak och eventuellt kan den delas upp efter dessa grupperingar.De tumregler och tekniker namnda ovan anvandes under projektet for att identifiera fallda SRP inte efterfoljdes.

4.1.2 DIP

Nar man forsoker efterfolja DIP kan man som tumregel tanka att alla beroenden manhar bor vara pa abstraktioner och inte konkreta klasser [8]. Listning 4 illustrerar anvand-ningen av DIP i projektet4. Klassen NewsController tillhor administrationsgranssnittetoch tar bland annat emot forfragningar om att skapa eller andra nyheter. Den som ska-par eller andrar en nyhet kan valja att avisera nyheten och om sa ar fallet kommer denprivata metoden Push att anropas. NewsController kanner endast till granssnittet IPush-Service och att en metod som heter Push finns. Det ar nagon annan klass som avgoroch faktiskt forser (via konstruktorn) NewsController med en konkret implementationav nagon IPushService, exempelvis PushSharpFacade.4Vissa justeringar och manga detaljer borttagna

10

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 (forenklad)

Resultatet av DIP ar att man far ett system som ar lost kopplat (engelska: Looselycoupled) [19], dar enskilda moduler eller klasser ar enkla att byta ut. Sag att manvill byta ut PushSharp som ramverk for aviseringar. En ny implementation av IPus-hSharp kan skapas och darefter injiceras, helt utan att andra eller ens kompilera omNewsController-klassen, vilket forovrigt ar i enlighet med The Open/Closed Princip-le.

DIP gor det aven lattare att skapa tester till klasser [19]. Exempelvis vill man inteskicka riktiga aviseringar nar man testar NewsController, utan nar Push i pushServiceanropas ska helst inget utforas. Man skapar da en sa kallad mock-klass som implemen-terar IPushService och dar metoden Push inte gor nagot (se listning 5). Mock-klasseninjiceras istallet for PushServiceFacade-klassen i testfallen for NewsController, vilketresulterar i att inga aviseringar skickas nar testen kors.

public class PushServiceMock : IPushService{

public void Push(NewsItem newsItem) {}}

Listning 5: En mock-klass av IPushService fran listning 4, som inte utfor nagot nar metodenPush anropas.

Till hjalp for att lyckas med DIP sattes en sa kallad Dependency Injection (DI) con-tainer i bruk tidigt i projektet. En DI container hjalper till med att injicera ratt konkretklass for ett visst beroende som en annan klass har. Det ar inte pa nagot satt ett kravatt anvanda en DI container for att efterfolja DIP, men det hjalper till en hel del nar

11

systemen blir storre [19]. Istallet for att manuellt knyta samman alla beroenden vidapplikations startpunkt later man DI container gora det automatiskt. Som DI containerfor projektet anvandes Unity5 [20] och alla beroenden injicerades via klasserna kon-struktorer.

DIP tillsammans med konstruktorinjektion kan ha en annan positiv paverkan och hjalpatill med att identifiera nar en klass bryter mot SRP. Nar konstruktorn for en klass borjarfa manga argument (darmed manga beroenden) signalerar det att klassen i fraga kanskehar mer an en anledning att andras och da bryter mot SRP [19]. Man kan da undersokavilka beroenden som anvands tillsammans och forsoka extrahera dessa till en egenklass.

4.2 Grundplattformen

Grundplattformen (och systemet i helhet) ar uppdelad i ett antal lager. Figur 3 nedanillustrerar vilka lager som finns och deras relationer till varandra. Illustrationen visaraven vilka lager webbtjansten och administrationsgranssnittet interagerar med.

Domänmodeller

Dataaccess

Tjänster Aviseringstjänst

Webbtjänsten Administrations-gränssnittet

DB

Figur 3: Grundplattformens skiktning

Figur 4 exemplifierar mer i detalj hur skiktning tillsammans med DIP anvands i pro-jektet. Alla beroenden ar pa abstraktioner, granssnitt i detta fall, och tre lager visas;Repositories och Services (grundplattformen) samt Controllers (webbtjansten).5Framtaget av en grupp manniskor pa Microsoft

12

Webbtjänsten

GrundplattformenRepositories

Device RepositoryImplementation

<<interface>>Device Repository

Services

Device ServiceImplementation

<<interface>>Device Service

Controllers

Device Controller

Figur 4: Exemplifiering av skiktning och DIP for projektet (i sjalva verket ar granssnitt ochkonkreta implementationer placerade i separata projekt).

4.2.1 Domanmodeller, databas och dataaccess

For systemet definierades ett antal domanmodeller: NewsItem, Category, Office, Imageoch Device, som beskriver nyheter, kategorier, kontor, bilder respektive enheter. Doman-modellerna ar placerade i ett eget projekt (lager) och saknar sjalva nagra beroenden,istallet har i princip alla andra lager ett beroende pa domanmodellerna.

Databas ar upptill Nethouse att valja vid produktionssattning, vid utveckling har SQLServer Compact anvands. Systemet kraver en databas som ar kompatibel med Micro-soft Entity Framework (EF).

Utvecklingen av databasen har skett med arbetsflodet Code-First development for EF.Code-First development later anvandaren definiera domanmodeller med vanliga POCO-klasser6 och darefter generera databasen utefter dessa modeller. Listning 6 visar doman-modellen som beskriver enheter i systemet.6Plain Old CLR Object - vanligt .NET objekt

13

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: Domanmodellen Device som beskriver enheter i system (vissa detaljer borttagna).

For att isolera beroenden samt anvandningen av EF, skapades sa kallade repository-klasser for alla domanmodeller. Tjansterna i tjanstelagret (eller andra klasser for dendelen) gor aldrig nagra direkta anrop till EF, utan deras anrop ar alltid till nagon avrepository-klasserna.

4.2.2 Tjanster

All interaktion med grundplattformen fran webbtjansten och administrationsgranssnit-tet sker via nagon av de tjanster som skapats. Tjansterna tar emot forfragningar franwebbtjansten och administrationsgranssnittet som de validerar och exekverar. Det kanhandla om att validera att anvandaren har rattigheter till en viss resurs eller att injiceraanvandarens kontor i fragan till dataaccesslagret for att exempelvis endast hamta allanyheter tillhorande anvandarens kontor.

4.2.3 Aviseringstjanst

For aviseringar implementerades ramverket PushSharp. Nar man anvander sig av tredje-parts bibliotek maste man ta i beaktande hur stor risk det ar att dess API kan komma attforandras eller att man kommer vilja byta till ett annat bibliotek i framtiden. Finns enrisk for detta bor man se till att isolera anvandningen av biblioteket sa att en framtidaandring ar enkel att utfora och inte kraver andringar runt om i hela kodbasen. Da Push-Sharp fortfarande utvecklas kraftigt och dess API kan komma att andras vid framtidauppdateringar var det viktigt att ramverket separerades fran projektet i ovrigt.

Losningen var att isolera all kod rorande PushSharp i ett separat projekt och definieraett granssnitt (engelska: Interface) for aviseringar som den egna kodbasen kunde beroav (se listning 7).

14

public interface IPushService{

void Push(NewsItem newsItem, Device device);}

Listning 7: Granssnitt for att skicka aviseringar.

Granssnittet ovan implementerades sedan i det separata PushSharp-projektet. Sker iframtiden forandringar i PushSharps API ar de andringarna som man behover goraisolerade till det projektet. Vill man vid ett senare skede byta till nagot annat ramverkfor aviseringar kan man pa nytt implementera granssnittet ovan med det nya ramverketoch anvanda den implementationen i stallet.

4.2.4 Exemplifiering av skiktningen

Foljande kod-listningar visar vilka metoder som ar involverade med att uppdatera enregistrering av en befintlig enhet samt i vilka lager dessa metoder finns. Listning 8visar metoden som tar emot uppdateringsforfragan i webbtjansten och vidarebeford-rar den till tjanstelagret dar UpdateDevice som syns i listning 9 tar over och utforaffarslogiken kring uppdateringen. Darefter anropas Update i dataaccesslagret (listning10) som later dess basklass utfora sjalva uppdateringen i UpdateOnCommit som syns ilistning 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 (fran DeviceController i webbtjansten) som hanterarregistreringsuppdateringar via PUT-forfragningar fran mobila klienter.

15

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 (fran DeviceService i grundplattformens tjanstelager) somutfor affarslogiken gallande registreringsuppdateringar.

public void Update(Device device){

UpdateOnCommit(device);}

Listning 10: Metoden Update (fran DeviceRepository i grundplattformens dataaccesslager) somanropar 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: MetodenUpdateOnCommit (fran EFRepository i grundplattformens dataaccesslager) somar basklassen till alla repositories.

4.3 Mobilapplikationen

I foljande sektion beskrivs nagra av de vasentligaste delarna fran utvecklingen och im-plementationen av mobilapplikationen. For att referera till mobilapplikationen kommeraven mobilappen samt appen att anvandas.

16

4.3.1 Anvandargranssnitt

For att ta fram en design samt for att valja farger till mobilappen fanns tva val, an-tingen kunde Nethouse grafiska profil efterfoljas eller sa kunde det temakoncept somMicrosoft tillhandahaller for Windows Phone anvandas. Efter diskussion foll valet patemakonceptet istallet for den grafiska profilen, dels da vissa anvandare foredrar ljustext mot mork bakgrund och andra tvartom vilket da automatiskt anpassar sig efteranvandarens preferenser och dels for att det ger appen en kansla av att vara en ur-sprungsapplikation (engelska: Native application).

Skisser togs fram for anvandargranssnittet (se bilaga A Skisser mobilapplikation pa si-dan 33) som med avsikt forsoker utnyttja nagra av plattformens kannetecken for attskapa kanslan av en nativ applikation. Tanken var inte att skapa en design som avenvar applicerbar for de ovriga plattformarna, utan tanken var att varje mobilapplikationskulle utnyttja den egna plattformens styrkor. Ett tydligt exempel ar valet av kompo-nenten som anvands for att vaxla mellan senaste nytt och de olika kategorierna, kalladPivot control. En pivot control ger ett enkelt och snabbt satt att vaxla mellan olika vyeroch anvands flitigt i appar for att visa samma innehalla men filtrerat efter olika kriterier,vilket ar passande har, dar man filtrerar antingen efter senaste nytt eller efter en kate-gori. For att byta vy sveper (engelska: Swipe) man horisontellt pa valfri del av ytan.Fortsatter man att svepa i samma riktning cirkulerar man runt alla vyer, som figur 5illustrerar.

Figur 5: Anvandaren kan navigera mellan senaste nytt och de olika kategorierna genom att svepahorisontellt over skarmen. Nyheterna hamtas dynamiskt nar de behovs.

Normalt skapar man pivot-kontrollen statiskt vid kompilering, detta ar dock inte mojligtfor mobilappen, da det saknas fordefinierade kategorier. Vad som behovs ar istallet attdynamiskt skapa de pivot-vyer som behovs under korning. Efter att anvandaren loggat

17

in hamtas alla kategorier fran webbtjansten och pivot-kontrollen skapas och darefterhamtas de senaste nyheterna. For att begransa den overforda datamangden hamtas ny-heterna for varje kategori forst nar anvandaren navigerar till dem.

For att ytterligare begransa den overforda datamangden implementerades sa kallad pa-ginering for webbtjansten vilket mojliggor hamtning av endast ett delresultat av ny-heter. For mobilapplikationen hamtas tio nyheter i taget. Aldre nyheter hamtas au-tomatiskt nar anvandaren rullar (engelska: Scroll) nedat vilket skapar en illusion aven oandlig strom av nyheter. Denna funktionalitet saknas i de list-komponenter somfinns for Windows Phone och maste implementeras pa egen hand. For nyhetslistningenanvands list-komponenten LongListSelector, denna komponent har en handelse kal-lad Link som hojs varje gang ett objekt i listan blir synligt for anvandaren. For attbedoma var i listan anvandaren ar implementerades en funktion som lyssnar efter Link-handelsen och som varje gang handelsen hojs beraknar:

indexOf(LastItem) - indexOf(LastVisibleItem) <= Offset

Nar avstandet fran listans sista objekt och det sista synliga objektet ar mindre eller likamed ett konfigurerbart offset, da hamtas fler nyheter.

4.3.2 Registrering for aviseringar

For att fa aviseringar kravs det dels att mobilapplikationen (enheten) registrerar sighos Microsoft Push Notification Service (harefter MPNS) och dels att den registrerarsig hos den egna webbtjansten. Microsoft rekommenderar att detta sker varje gangmobilapplikationen startas [21].

Nar anvandaren aktiverar aviseringar under installningar sa kommer registreringspro-ceduren att utforas och darefter kommer den att utforas efter inloggning vid varje upp-start av appen. Nedan foljer beskrivning av hur registreringen sker hos bade MPNS ochwebbtjansten.

Registrering hos MPNS

Innan mobilappen kan registrera sig hos webbtjansten kravs det att den har fatt enChannel Uri fran MPNS-tjansten. Det ar denna adress webbtjansten sen anvander sigav for att skicka aviseringar till mobilappen.

Mobilappen borjar med att kolla om det redan finns en oppen kanal mellan telefo-nen och MPNS. Appen registrerar sig direkt hos webbtjansten om sa ar fallet annarsforsoker den forst att skapa en ny kanal till MPNS-tjansten. Nar en lyckad kanal val harskapats kommer MPNS meddela mobilappen via handelsen ChannelUriUpdated omdetta och da kommer mobilappen i sin tur att registrera sig hos webbtjansten.

18

Registrering hos webbtjansten

Det finns tva typer av registreringar hos webbtjansten. Den ena ar en nyregistreringsom sker forsta gangen mobilappen registrerar sig hos webbtjansten och den andra aren uppdatering av en redan befintlig registrering som sker varje gang appen startar eftersin forsta registrering. Nyregistreringar och uppdateringar sker genom att appen skickaren POST-forfragan respektive PUT-forfragan till webbtjansten (se 5.2.2 Registreringfor aviseringar for detaljer). Nar en nyregistrering har lyckats lagras det enhets-id somreturneras av webbtjansten i telefonens permanenta lagringsutrymme.

4.3.3 Kommunikation med webbtjansten

All natverkskommunikation som sker i en Windows Phone-app maste utforas asyn-kront, det saknas helt bibliotek som tillater synkrona anrop. Microsoft har gjort detta valfor att forsakra sig om att anvandargranssnittet alltid svarar pa anvandaren interaktionoch inte laser sig i vantan pa oberakneliga natverksanrop som kan ta lang tid.

Nyligen slappte Microsoft ett bibliotek for Windows Phone 7 som gor det lattare attskriva asynkrona funktioner. Med biblioteket markerar man asynkrona funktioner medordet async i funktionshuvudet och anvander await som prefix vid de anrop som skaske asynkront i funktionskroppen. Se listning 12 nedan for ett exempel.

public async Task<string> AsyncOperation(){

using (var client = new HttpClient()){

Task<string> task = client.GetStringAsync(some_uri);DoSomeIndependentWork();string dataString = await task;return dataString;

}}

Listning 12: Asynkrona anrop med async-await i Windows Phone.

For all kommunikation med webbtjansten anvands async-await pa liknande satt, ett ex-empel visas i listning 13, som ar koden for att hamta senaste nytt fran webbtjansten. Harser vi att async-await kan kedjas vid flera funktionsanrop och att await kan anvandasflera ganger i samma funktion.

19

public async Task<PagedList<NewsItem>> GetLatest(int page = 1){

var uri = BaseUri + "/news?pageNumber=" + page;return await GetForUri<PagedList<NewsItem>>(uri);

}

private async Task<T> GetForUri<T>(Uri uri){

using (var client = new HttpClient()){

var response = await client.GetAsync(uri);if (response.StatusCode == HttpStatusCode.OK){

var content = await response.Content.ReadAsStringAsync();var result = DeserializeObject<T>(content);return result;

}}return default(T);

}

Listning 13: Asynkrona anrop for att hamta senaste nytt fran webbtjansten (vissa detaljerutelamnade).

4.3.4 Inloggning och sakerhet

Som tidigare namnts omfattades inte projektet av att undersoka och ta fram en sakerhets-losning for de olika systemen, detta skulle Nethouse utfora parallellt. Nethouse hannta fram sakerhetslosningar for webbtjansten och administrationsgranssnittet, vilka arimplementerade. Dock finns annu ingen losning for mobilapplikationen. Det mesta avlogiken for inloggningen ar dock pa plats, den funktion som behover kompletteras artryToAuthenticate som faktiskt utfor sjalva autentiseringen mot deras autentiserings-tjanst.

Ett av kraven fran Nethouse var att anvandarnamn och losenord skulle kunna lagras iappen, sa att anvandaren slipper tillhandahalla dessa manuellt varje gang appen star-tas. Vidare kommer man nar losningen ar fardig att fa ett token vid autentiseringensom anvands vid alla anrop till webbtjansten. Denna token kommer att ha ett visstutgangsdatum, sa lange detta datum inte passerat behover ingen ny inloggning ske vidstart av appen. Denna token behover saledes ocksa lagras.

Losenord och andra identifieringsobjekt (sa som en token) bor aldrig lagras i klartextutan ska krypteras innan lagring. Till hjalp for krypteringen anvands det medfoljandebiblioteket ProtectedData. ProtectedData har tva funktioner: Protect och Unprotect,som krypterar respektive dekrypterar byte-arrayer. For att kryptera en strang av teckenbehover man saledes forst konvertera strangen till en byte-array och darefter anropaProtect-funktionen som da returnerar en krypterad byte-array. For dekryptering utforsstegen bakvant och med Unprotect istallet for Protect.

Krypteringen behover kompletteras med nagot permanent lagringsutrymme. Varje Win-

20

dows Phone-applikation har ett sadant utrymme kallat IsolatedStorage, som endast arsynligt for den app utrymmet tillhor. Kryptering och lagring implementerades som engenerell hjalpklass vilken anvands for saker lagring av bade losenordet och det tokensom autentiseringen returnerar. Listning 14 visar hur krypteringen utfors (lagringensker i funktionen WriteToFile).

public static void EncryptAndStore(string value, string path){

byte[] valueAsByte = Encoding.UTF8.GetBytes(value);byte[] valueEncrypted = ProtectedData.Protect(valueAsByte, null);WriteToFile(valueEncrypted, path);

}

Listning 14: Funktionen for att kryptera och lagra en strang av tecken.

4.4 Webbtjansten

Webbtjansten foljer REST-principen beskriven i bakgrunden (se avsnitt 2.1 Vad ar enwebbtjanst) och ar implementerad med Microsoft ASP.NET Web API. Webbtjanstenbestar av fyra resurser; nyheter, kategorier, kontor och enheter vilka implementeradssom Controllers i Web API-ramverket. En resurs i REST-arkitekturen har ett antal me-toder, bland andra GET, POST, PUT och DELETE. For Web API implementeras dessasom vanliga metoder i Controller-klasserna. Som konvention namnges dessa metodermed HTTP-metodernas namn som prefix.

Tack vare grundplattformens tjanstelager innehaller dessa Controllers knappt nagonlogik. Listning 15 visar funktionen som hamtar en nyhet, som synes ar den valdigtkort, dar den viktiga logiken ar dold i tjanstelagret. Det ar tjansten newsSerivce somhamtar nyheten via dataaccesslagret och validerar att anvandaren faktiskt har ratt atthamta nyheten ifraga.

public NewsItem GetNewsItem(int id){

NewsItem newsitem = newsService.GetNewsItemById(id);if (newsitem == null){

throw new HttpResponseException(Request.CreateResponse(HttpStatusCode.NotFound));

}return newsitem;

}

Listning 15: GET-metod for att hamta en nyhet via webbtjansten.

21

4.4.1 Design av resurser

Systemets resurser: nyheter, kategorier och enheter var enkla att identifiera och imple-mentera. Tva av resurserna; nyheter och kategorier, behovde endast funktionalitet foratt hamta nyheter respektive kategorier. Den tredje resursen enheter, behovde tre opera-tioner: skapa, uppdatera och ta bort en enhet, vilka kan mappades till HTTP-metodernaPOST, PUT respektive DELETE. For en komplett och detaljerad samling av alla resur-ser och deras operation, se avsnitt 5.2 Webbtjansten.

4.4.2 Datautbytesformat

JSON valdes som databytesformat tack vare dess minimala overhead [1], dar under-sokningar [22] visar att JSON producerar data som ar signifikant mindre an XML,vilket ar viktigt nar begransade resurser ar involverade, sa som mobila enheter ochinternetanslutningar. Framsta anledning till att JSON har mindre overhead an XMLar for att JSON inte anvander sig av sluttaggar som XML gor. Anvands kompressionsa blir storlekarna for JSON och XML relativt jamforbara, men da tillkommer istalletprocesser som komprimerar och dekomprimerar data, vilket stjal resurser som cpu-tidistallet.

4.5 Administrationsgranssnittet

Med hjalp av Microsoft ASP.NET MVC togs ett enklare administrationsgranssnittfram. Precis som for webbtjansten bestar administrationsgranssnittet framst av en upp-sattning Controllers som hamtar och lagrar data via tjanstelagret i grundplattformen.Tva Controllers implementerades; News- och CategoryController. Dessa stodjer stan-dard CRUD-operationer7, dar varje operation implementeras som en metod i sin till-horande Controller. For varje operation finns en tillhorande vy.

7Create/Read/Update/Delete: Skapa, Lasa, Uppdatera och Ta bort

22

5 Resultat

Projektet har resulterat i fyra delsystem (se figure 6); en grundplattform innehallandedatabasen samt affarslogiken, en webbtjanst for att stodja de mobila klienterna, ettgranssnitt for administration samt en Windows Phone-mobilapplikation.

Grundplattform- Databas

- Service-lager - PushSharp

Windows Phone Mobilapplikation

Webb-Api- Registrering för avisering

- Konsumera nyheter

Administration- Hantera och publicera nyheter

- Hantera kategorier

Figur 6: Hogniva

5.1 Mobilapplikationen

Motivet bakom projektet var att skapa en mojlighet for Nethouse att enklare sprida in-formation till alla deras konsulter och mobilapplikationen ar utat sett resultatet av detta.Funktionsmassigt ar den komplett sa nar som pa autentiseringen (vilket ligger utanforexamensarbetets omfattning). De funktioner som efterfragades var stod for avisering-ar och mojlighet att lasa nyheter direkt i appen, listade efter senaste nytt samt efterkategori.

5.1.1 Vyer och navigation

I foljande sektion beskrivs de olika vyer som mobilapplikationen bestar av samt hurnavigationen sker mellan dessa. Farger och textstorlekar styrs av telefonens tema, vilketmedfor att om anvandaren till exempel foredrar ljus text mot mork bakgrund har dennatroligtvis stallt in ett morkt tema pa telefonen och som da mobilapplikationen efter-foljer. For skarmdumparna nedan anvands ett ljust tema med turkos accentfarg.

23

Inloggnings-vy

Forsta gangen anvandaren startar mobilapplikationen mots denne av en inloggning (sefigur 7). Applikationen krypterar och lagra anvandaruppgifterna lokalt pa telefonenfor att vid nastkommande start automatiskt logga in anvandaren. Inloggningsuppgifter-na forsvinner forst nar anvandaren antingen valjer att logga ut alternativt avinstallerarapplikationen. Efter en viss tid kommer aven autentiseringen lopa ut och da kommeranvandaren uppmanas att uppge inloggningsuppgifterna pa nytt vid start av applikatio-nen.

Figur 7: Skarmdumpar av inloggning

Nyhetslistnings-vy

Nar applikationen har autentiserat anvandare forflyttas denna automatiskt till listanmed de senaste nyheterna (se figur 8). Varje nyhet presenteras med en mindre bild,en nyhetsrubrik samt ett publiceringsdatum. Fran denna vy har anvandaren foljandeval:

• Trycka pa en av de synliga nyheterna och forflyttas till en vy som visar alladetaljer om den valda nyheten.

• Rulla (engelska: Scroll) nedat for att se aldre nyheter. Nar anvandaren borjarnarma sig slutet pa listan laddas automatiskt annu aldre nyheter in och skapar enillusion av en oandlig lista.

• Svepa till hoger alternativt vanster byter mellan de olika kategorierna samt se-naste nytt.

24

• Trycka pa listen langst ner exponerar en meny med alternativen uppdatera nyheter ochinstallningar. Uppdatera nyheter anvands for att ladda in nya publicerade nyheter somkan ha uppkommit efter att applikationen startades. Installningar tar anvandaren tillinstallnings-vyn.

Figur 8: Skarmdumpar av nyhetslistningar

Nyhets-vy

Nar anvandaren navigerat till en specifik nyhet mots denne av all tillganglig infor-mation tillhorande nyheten (se figur 9). Overst ar nyhetsrubriken som foljs av kategori,forfattare och publiceringsdatum. Darefter visas en storre variant av bilden som syntes inyhetslistningen. Efter bilden kommer en sammanfattning och sjalva nyhetsinnehallet.Nyhetsinnehallet stodjer enklare formatering sa som fet, kursiv, och understruken stil,det finns aven stod for listor samt externa lankar. Om anvandaren trycker pa en lankoppnas mobilens webblasaren och lanken laddas.

25

Figur 9: Skarmdump av en nyhet

Installnings-vy

Installnings-vy (se figur 10) har i dagslaget endast tva val. Anvandare kan logga ut(vilket aven tar bort sparade inloggningsuppgifter) eller aktivera/inaktivera avisering-ar.

Figur 10: Skarmdump av installningar

26

5.1.2 Aviseringar

Nar en nyhetspublicist valjer att avisera en viss nyhet kommer detta visa sig pa tvasatt for mobilanvandaren (se figur 11). Dels visas en kort stund ett sa kallat Toast-meddelande8 bestaende av nyhetens rubrik och dels uppdateras mobilappliktionens sakallade Tile9 med antalet aviserade nyheter, publicerade efter det att anvandaren senastanvande mobilapplikationen.

Figur 11: Skarmdumpar av aviseringar

5.2 Webbtjansten

Webbtjanstens syfte ar att stotta de mobila klienterna (i dagslaget endast WindowsPhone-mobilapplikationen) genom att forse dessa med nyheter samt tillata dem att re-gistrera sig for att fa framtida nyhetsaviseringar.

5.2.1 Konsumera nyheter och kategorier

De mobila enheterna ar i behov av att atminstone kunna hamta alla tillgangliga katego-rier, de senaste publicerade nyheterna och publicerade nyheter tillhorande en specifikkategori. Foljande API mojliggor detta:8Den blaa rektangeln i overkant (pa den hogra skarmdumpen) i figur 119De blaa kvadraterna i figur 11

27

Hamta publicerade nyheter

URI: api/news?pageNumber=X&pageSize=YHTTP-metod: GETRespons: Se 5.2.3 Datautbytesformat

(Respons - Nyheter)Kommentar: Parametrarna pageNumber och pageSize ar valfria och

far X = 1 och Y = 10 som standard. Anvands for att endastge ett delresultat av alla nyheter.

Hamta nyhet med id = ID

URI: api/news/IDHTTP-metod: GETRespons: Se 5.2.3 Datautbytesformat

(Respons - En nyhet)

Hamta alla kategorier

URI: api/categoryHTTP-metod: GETRespons: Se 5.2.3 Datautbytesformat

(Respons - Kategorier)

Hamta publicerade nyheter i kategorin med id = ID

URI: api/category/ID/news?pageNumber=X&pageSize=YHTTP-metod: GETRespons: Se 5.2.3 Datautbytesformat

(Respons - Nyheter)Kommentar: Parametrarna pageNumber och pageSize ar valfria och

far X = 1 och Y = 10 som standard. Anvands for att endastge ett delresultat av alla nyheter.

5.2.2 Registrering for aviseringar

For att en mobil enhet ska fa nyhetsaviseringar kravs det att denna registrerar sig hoswebbtjansten. PushId som namns ska vara det id10 som plattformens aviseringsombudtilldelar enheten. Foljande API mojliggor registrering och avregistrering samt uppda-tering av befintlig registrering.10Kallas for Channel uri av Microsoft, Device token av Apple och Device registration id av Google

28

Registrering av en ny enhet

URI: api/deviceForfragan: Se 5.2.3 Datautbytesformat

(Begaran - Registrering av enhet)HTTP-metod: POSTRespons: Enhetens nya id (av typen Guid)Kommentar: DeviceType kan i dagslaget vara WindowsPhone, Apple

eller Android

Uppdatera registreringen for enheten med id = GUID

URI: api/deviceHTTP-metod: PUTBegaran: Se 5.2.3 Datautbytesformat

(Begaran - Uppdatering av en enhets registrering)

Avregistrerar enheten med id = GUID

URI: api/device/GUIDHTTP-metod: DELETE

5.2.3 Datautbytesformat

Som datautbytesformat anvands JSON. Nedan beskrivs de forfragan- och respons-meddelanden (engelska: request and response) som tas emot av eller skickas fran webb-tjansten.

Respons - Nyheter

{"TotalCount" : <TOTAL_COUNT : int>,"PageNumber" : <PAGE_NUMBER : int>,"PageSize" : <PAGE_SIZE : int>,"PageCount" : <PAGE_COUNT : int>,"HasPrevious" : <HAS_PREVIOUS : bool>,"HasNext" : <HAS_NEXT : bool>,"SourceList" :

[<LIST_OF_NEWS_ITEMS : List<NewsItem>>

]}

29

Respons - Kategorier

[{

"CategoryId" : <CATEGORY_ID : int>,"Name" : <NAME : string>

},...

]

Respons - En nyhet

{"NewsItemId" : <NEWS_ITEM_ID : int>,"Heading" : <HEADING : string>,"Summary" : <SUMMARY : string>,"Body" : <BODY : string>,"Author" : <AUTHOR : string>,"PublishedAt" : <PUBLISHED_AT : datetime>,"Category" :

{"CategoryId" : <CATEGORY_ID : int>,"Name" : <NAME : string>

},"ImageSmall" :

{"ImageId" : <IMAGE_ID : int>,"Content" : <CONTENT : byte[]>

},"ImageLarge" :

{"ImageId" : <IMAGE_ID : int>,"Content" : <CONTENT : byte[]>

}}

Forfragan - Registrering av enhet

{"PushId" : <PUSH_ID : string>,"DeviceType" : <DEVICE_TYPE : string>

}

30

Forfragan - Uppdatering av en enhets registrering

{"DeviceId" : <DEVICE_ID : string>,"PushId" : <PUSH_ID : string>

}

5.3 Administrationsgranssnittet

Administrationsgranssnittet tillater nyhetspublicister att lista, skapa, andra, publicerasamt avisera nyheter. Vidare tillats administratorer att lista, skapa och andra namn pakategorier samt valja vilket standardbeteende for aviseringar (att avisera eller ej) somska galla for publicerade nyheter tillhorande kategorin.

Vid skapandet av en nyhet ges mojligheten att endast spara eller att spara och publicera.En publicerad nyhet forblir publicerad och kan inte aterkallas. Nar en nyhet publicerasfinns mojligheten att skicka en avisering till alla konsulter. En avisering kan skickasvid ett senare tillfalle om sa onskas, men kan skickas endast en gang. Standardbeteen-det for att avisera en nyhet eller ej bestams av den valda kategorin nar nyheten skapas,detta val kan dock andras for varje enskild nyhet. Nyhetspublicistens namn fylls i auto-matiskt vid skapandet, men kan andras om sa onskas. Brodtexten har stod for enklareformatering som fet, kursiv och understruken stil samt styckeindelning, det gar aven attskapa punktlistor och internetlankar.

Se skarmdumpar for administrationsgranssnittet i bilaga C Skarmdumpar administra-tionsgranssnitt pa sida 38.

5.4 Grundplattformen

Stommen i systemet utgors av grundplattformen som har till uppgift att assistera webb-tjansten och administrationstjansten, men aven nya tjanster i framtiden, med vad debehover. Det finns inbyggt stod for flera kontor vilket var ett av kraven. Webbtjanstenoch administrationsgranssnittet skoter endast autentiseringen av anvandaren, darefteransvarar grundplattformen for att halla reda pa anvandaren och endast hamta och lagraden data som tillhor den autentiserade anvandarens kontor, saledes en konsult i Orebrokommer aldrig se en nyhet publicerade av Stockholms-kontoret.

All interaktion med grundplattformen gors via olika tjanster. Det finns en uppsattningdatatjanster som ansvarar for att hamta och lagra data via dataaccesslagret. Dessatjanster ser till att endast data avsett for den autentiserade anvandaren nyttjas. Det finnsaven en aviseringstjanst som utfor nyhetsaviseringar. Aviseringstjansten ser till att baraskicka ut aviseringar till aktiva enheter11, de inaktiva enheter tas bort.

11I dagslaget specificerat till enheter som anvant mobilapplikationen under de senaste 14 dagarna

31

6 Slutsats och diskussion

Projektet har varit bade intressant och larorikt. Microsofts utvecklingsplattform ar val-digt popular idag bland foretag och projektet har anvant sig av flera aktuella tekniker,som exempelvis ASP.NET Web API for att skapandet av webbtjansten.

For mig har en del av projektet varit extra intressant, vilket har varit att designa syste-met efter goda objektorienterade principer vilka visade sig vara valdigt utmanande mengivande. Alla konsulter pa Nethouse anvander boken Clean Code [18] som handbok forhur man skriver bra kod och den har verkligen gett mig en ny syn pa vad bra kod ar.Mycket energi har lagts pa att efterfolja principerna for god objektorienterad designoch att anvanda designmonster, dar mitt fokus har legat pa att skapa ett system somNethouse kan bygga vidare pa och utoka med ny funktionalitet i framtiden. Nar jag nuefterat utvarderar systemet som projektet resulterat i, genom att se over vilka klassersom finns, vad de gor och hur de relaterar till varandra, marker jag stor skillnad frantidigare projekt som utforts under skoltiden. Trots att koden knappt har nagra kommen-terar (vilket boken foresprakar) ar den enligt mig anda beskrivande och lattforstaeligtack vara att sma klasser som endast har ett ansvar och korta metoder med beskrivandenamn.

Vissa problem har funnits da projektet utforts pa distans. Dels blev projektet forsenati borjan och dels hade fler avstamningar behovts eftersom vissa krav var okanda. Pro-blem som troligtvis kunna forminskats om arbetet utforts pa plats, atminstone nagongang i veckan.

6.1 Mojliga forbattringar

• Identifiera och upplysa anvandaren om aviseringar som inkommit medan mobil-applikation korts, vilket det finns en handelse for. Dock behover man funderapa om endast ett visuellt meddelande ska visas eller om listan ska uppdaterasautomatiskt.

• Kunna valja vilka kategorier som ska visas i mobilapplikationen fran installnings-vyn.

• Koda nyhetsbilderna i ett effektivt format for binar data, exempelvis BSON [23],innan de skickas till de mobila klienterna. I dagslaget anvands Base64 [24] foratt koda bilderna, vilket har ett relativt stort overhead.

• SSL behover implementeras innan systemet produktionssatts.

• Visa nyhetsbilder i administrationsgranssnittet. Idag hamtas all information bort-sett fran bilderna till administrationsgranssnittet, granssnittet indikerar endast atten befintlig bild finns om sa ar fallet.

32

Bilagor

A Skisser mobilapplikation

Figur 12: Fran vanster till hoger: (1) Anvandaren loggar in om tidigare autentisering saknas ellerutgatt, (2) senaste nytt hamtas och visas for anvandaren och (3) en nyhet valjs utifranlistan och visas i fullstandig form.

33

Figur 13: Anvandaren kan navigera mellan senaste nytt och de olika kategorierna genom attsvepa horisontellt over skarmen. Nyheterna hamtas dynamiskt nar de behovs.

Figur 14: Fran nyhetslistningen kan anvandaren fa fram en dold meny genom att trycka pamenyraden langst ner. Da visas tva alternativ; (1) uppdatera nyheter som endast forden aktuella vyn hamtar hem nyheterna pa nytt och (2) installningar som tar anvandaretill installnings-vyn dar denne kan logga ut eller aktivera/inaktivera aviseringar.

34

B Skarmdumpar mobilapplikation

Figur 15: Skarmdumpar av nyhetslistningar samt meny

Figur 16: Skarmdump av en nyhet

35

Figur 17: Skarmdumpar av inloggning

Figur 18: Skarmdump av installningar

36

Figur 19: Skarmdumpar av aviseringar

37

C Skarmdumpar administrationsgranssnitt

Figur 20: Skarmdumpar av nyhetslistning

38

Figur 21: Skarmdumpar av nyhetsredigering

39

Figur 22: Skarmdumpar av nyhetsvisning

40

Figur 23: Skarmdumpar av kategorilistning

41

Referenser

[1] D. Fensel, F. M. Facca, E. Simperl, and I. Toma, Semantic Web Services. Berlin:Springer Berlin Heidelberg, 2011.

[2] “Representational state transfer (wikipedia).” http://en.wikipedia.org/wiki/Representational_State_Transfer, 2013. Tillganglig2013-05-31.

[3] “Extensible markup language (xml) 1.0 (fifth edition).” http://www.w3.org/TR/REC-xml, 2013. Tillganglig 2013-05-31.

[4] “Introducing json.” http://json.org. Tillganglig 2013-05-31.

[5] “Push notifications for windows phone.” http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff402558(v=vs.105).aspx, 2013. Tillganglig 2013-05-20.

[6] “Apple push notification service.” http://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html, 2013. Tillganglig 2013-05-20.

[7] “Google cloud messaging for android.” http://developer.android.com/google/gcm/gcm.html, 2013. Tillganglig 2013-05-20.

[8] M. C. Robert and M. Micah, Agile Principles, Patterns, and Practices in C#.Boston: Prentice Hall, 2006.

[9] A. I. Khan, R. J. Qurashi, and U. A. Khan, “A comprehensive study of commonlypracticed heavy and light weight software methodologies,” International Journalof Computer Sciencee Issues, Vol. 8, Issue 4, No 2, 2011. Tillganglig 2013-05-20fran http://arxiv.org/pdf/1111.3001.pdf.

[10] “Scrumguiden.” http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%20-%20SE.pdf, 2011. Tillganglig2013-05-20.

[11] “Fiddler.” http://fiddler2.com/. Tillganglig 2013-06-12.

[12] “Microsoft asp.net.” http://www.asp.net/, 2013. Tillganglig 2013-05-25.

[13] “Microsoft asp.net web api.” http://www.asp.net/web-api, 2013.Tillganglig 2013-05-25.

[14] “Microsoft asp.net mvc.” http://www.asp.net/mvc, 2013. Tillganglig2013-05-25.

[15] “Microsoft entity framework.” http://msdn.microsoft.com/en-us/data/ef.aspx, 2013. Tillganglig 2013-05-25.

[16] “Windows phone dev center.” http://dev.windowsphone.com/en-us/develop, 2013. Tillganglig 2013-05-25.

42

[17] “Pushsharp.” https://github.com/Redth/PushSharp, 2013.Tillganglig 2013-05-25.

[18] M. C. Robert, Clean Code: A Handbook of Agile Software Craftsmanship. Bo-ston: Prentice Hall, 2008.

[19] M. Seemann, Dependency Injection in .NET. Shelter Island: Manning Publica-tions Co., 2012.

[20] “Unity.” http://unity.codeplex.com/, 2013. Tillganglig 2013-06-12.

[21] “Setting up your app to receive push notifications for windows phone.”http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh202940(v=vs.105).aspx, 2013. Tillganglig 2013-05-31.

[22] C. Rodrigues, J. Afonso, and P. Tome, ENTERprise Information Systems, ch. Mo-bile Application Webservice Performance Analysis: Restful Services with JSONand XML. Springer Berlin Heidelberg, 2011.

[23] “Bson.” http://en.wikipedia.org/wiki/BSON, 2013. Tillganglig2013-06-12.

[24] “Base64.” http://en.wikipedia.org/wiki/Base64. Tillganglig2013-06-12.

43