Mobil lösning för intern informationsspridning

IT 13 043

Examensarbete 15 hp Juni 2013

Mobil lösning för intern informationsspridning

Jonas Eliasson

Institutionen för informationsteknologi

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 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.

Ämnesgranskare: Olle Eriksson Handledare: Mattias Lyrén

Inneh˚all

1 Introduktion 1

1.1 Uppgiftsbeskrivning . . . . 1

1.2 M˚al och syfte . . . . 2

1.3 Avgr¨ansningar . . . . 2

2 Bakgrund 3 2.1 Vad ¨ar en webbtj¨anst . . . . 3

2.2 Datautbytesformat . . . . 4

2.2.1 XML . . . . 4

2.2.2 JSON . . . . 5

2.3 Aviseringar f¨or mobila enheter . . . . 5

2.4 Principer f¨or objektorienterad design . . . . 7

3 Metodik 8 3.1 Verktyg . . . . 8

3.2 Implementationsplattform - ASP.NET . . . . 8

3.2.1 Web API . . . . 8

3.2.2 MVC . . . . 8

3.2.3 Entity Framework . . . . 9

3.2.4 Windows Phone SDK . . . . 9

3.3 PushSharp . . . . 9

4 Implementation 10 4.1 Principer f¨or objektorienterad design . . . . 10

4.1.1 SRP . . . . 10

4.1.2 DIP . . . . 10

4.2 Grundplattformen . . . . 12

4.2.1 Dom¨anmodeller, databas och dataaccess . . . . 13

4.2.2 Tj¨anster . . . . 14

4.2.3 Aviseringstj¨anst . . . . 14

4.2.4 Exemplifiering av skiktningen . . . . 15

4.3 Mobilapplikationen . . . . 16

4.3.1 Anv¨andargr¨anssnitt . . . . 17

4.3.2 Registrering f¨or aviseringar . . . . 18

4.3.3 Kommunikation med webbtj¨ansten . . . . 19

4.3.4 Inloggning och s¨akerhet . . . . 20

4.4 Webbtj¨ansten . . . . 21

4.4.1 Design av resurser . . . . 22

4.4.2 Datautbytesformat . . . . 22

4.5 Administrationsgr¨anssnittet . . . . 22

5 Resultat 23 5.1 Mobilapplikationen . . . . 23

5.1.1 Vyer och navigation . . . . 23

5.1.2 Aviseringar . . . . 27

5.2 Webbtj¨ansten . . . . 27

5.2.1 Konsumera nyheter och kategorier . . . . 27

5.2.2 Registrering f¨or aviseringar . . . . 28

5.2.3 Datautbytesformat . . . . 29

5.3 Administrationsgr¨anssnittet . . . . 31

5.4 Grundplattformen . . . . 31

6 Slutsats och diskussion 32 6.1 M¨ojliga f¨orb¨attringar . . . . 32

Bilagor 33

A Skisser mobilapplikation 33

B Sk¨armdumpar mobilapplikation 35

C Sk¨armdumpar administrationsgr¨anssnitt 38

Referenser 42

1 Introduktion

Nethouse ¨ar ett It-konsultbolag med kontor p˚a fem orter i Sverige och arbetar med It- och verksamhetsutveckling, med uppdragsgivare b˚ade i n¨aringslivet och den offentliga sektorn.

Idag har Nethouse ett antal anst¨allda som arbetar ute p˚a plats hos deras uppdragsgivare som bland annat resurskonsulter. Att f˚a ut information om interna h¨andelser och ny- heter till dessa, men ¨aven de andra anst¨allda, ¨ar viktigt, dels f¨or att de ska k¨anna sig uppdaterade med vad som h¨ander men ¨aven f¨or att de ska k¨anna tillh¨orighet till sin faktiska arbetsgivare, Nethouse. Idag publiceras och sprids de interna h¨andelserna och nyheterna via f¨oretagets internwebb. Internwebben ¨ar dock inte mobilanpassad och fr˚an vissa uppdragsgivare saknas m¨ojlighet att ¨overhuvudtaget ansluta sig till denna.

1.1 Uppgiftsbeskrivning

F¨or att l¨osa problemet med att sprida information till alla sina anst¨allda vill Nethouse att en mobilapplikation tas fram. Mobilapplikationen beh¨over finnas i en version f¨or Google Android, Apple Ios och Microsoft Windows Phone. Vidare ¨onskas m¨ojligheten att skicka aviseringar till de mobila enheterna n¨ar vissa nyheter av viktigare karakt¨ar publiceras, f¨or att p˚a ett snabbare s¨att uppm¨arksamma alla anst¨allda om dessa nyhe- ter.

Initialt var tanken att mobilapplikationen skulle integreras med den befintliga intern- webben som ¨ar baserad p˚a Microsoft Sharepoint. Integration med Sharepoint valdes dock bort n¨ar det visade sig att nyhetsfl¨odet i mobilapplikationen skiljer sig en hel del fr˚an nyhetsfl¨odet p˚a internwebben. Att ta fram en implementation/integration som omvandlar nyhetsfl¨odet fr˚an internwebbens format till ett format som passar mobil- applikationen skulle i sig bli ett ganska stort arbete. Det finns ¨aven ett viss missn¨oje med den befintliga internwebben och diskussioner p˚ag˚ar om hur informationsfl¨odet p˚a internwebben m¨ojligen ska f¨or¨andras i framtiden, vilket skulle kunna leda till att en eventuell integration ganska fort blir inaktuell. Produkt¨agaren tog d¨arf¨or beslutet att en helt separat l¨osning skulle tas fram och om behov finns i framtiden l¨oser man integration med internwebben d˚a.

Som n¨amnts har Nethouse kontor p˚a flera orter och till en b¨orjan kommer den fram- tagna l¨osning anv¨andas av ¨Orebrokontoret. St¨od f¨or flera kontor m˚aste dock tas i beak- tande n¨ar systemet designas, d¨ar de olika kontorens information ska vara isolerade fr˚an varandra.

1.2 M˚al och syfte

M˚al och syfte med examensarbetet ¨ar att

• Skapa en grundplattform f¨or att skicka aviseringar till olika mobila enheter, s˚a som Google Android, Apple Ios och Microsoft Windows Phone.

• Skapa en nyhets-webbtj¨anst anpassad f¨or konsumtion av mobila enheter.

• Skapa en mobilapplikation f¨or Windows Phone som kan ta emot aviseringar om ny information samt kan h¨amta information f¨or l¨asning vid behov.

• Skapa ett enklare gr¨anssnitt f¨or administration och nyhetspublicering.

1.3 Avgr¨ansningar

Arbetet innefattar inte att utveckla en version av mobilapplikationen f¨or Google Andro- id eller Apple Ios, utan dessa kommer tas fram vid ett senare skede av Nethouse. Det ing˚ar heller inte att utreda vilken typ av s¨akerhetsl¨osning som ska anv¨ands f¨or mobil- applikationen respektive webbtj¨ansten, detta utreds parallellt av Nethouse, men imple- menteras under arbetets g˚ang av mig. Vidare ska inget bibliotek f¨or att skicka avise- ringar utvecklas, utan tredjepartsbiblioteket PushSharp ska anv¨andas.

2 Bakgrund

2.1 Vad ¨ar en webbtj¨anst

Webbtj¨anster (engelska: Web Services) l˚ater datorer och andra enheter kommunicera med varandra via webben [1]. Idag ¨ar det otydligt vilka tj¨anster p˚a webben som normalt menas med ordet webbtj¨anst. Fokus f¨or detta arbete har varit webbtj¨anster som baseras p˚a REST-arkitekturen (REpresentational State Transfer).

REST-arkitekturen ¨ar en tillst˚andsl¨os (engelska: Stateless) klient-server-arkitektur som kretsar kring resurser. F¨or REST ¨ar resurser f¨orsta klassens objekt och karakt¨ariseras av f¨oljande:

• En resurs identifieras (adresseras) unikt med en Uniform Resource Identifier¹ (URI), exempelvis http://exempel.se/api/produkt/2.

• En resurs manipuleras med hj¨alp av v¨alk¨anda HTTP-metoder, exempelvis GET och POST.

• En f¨orfr˚agan till en resurs och f¨orfr˚agans resultat kan skickas i flera olika repre- sentationsformat, s˚a kallade mime types, exempelvis text/html, application/json och 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

Samling http://exempel.se/resurs

Enskild

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

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

Att REST-arkitekturen ¨ar tillst˚andsl¨os inneb¨ar att inget tillst˚and eller session lagras ˚at anv¨andaren p˚a servern mellan anrop, utan ett eventuellt tillst˚and m˚aste inkluderas av anv¨andare vid n¨astkommande anrop. F¨ordelen med denna tillst˚andsl¨oshet ¨ar att sys- temet blir tidsm¨assigt frikopplat, vilket ofta ¨ar ¨onskv¨art i distribuerade system som webbtj¨anster [1].

1Identifierare eller namn f¨or en resurs

2.2 Datautbytesformat

F¨or att kunna utbyta information ¨over n¨atverk konverteras datastrukturer och objekt till ett s˚a kallat datautbytesformat. Tv˚a vanligt f¨orekommande datautbytesformat f¨or webbtj¨anster ¨ar XML (eXtensible Markup Language) [3] och JSON (JavaScript Object Notation) [4]. REST-arkitekturen har inga krav p˚a vilket format som anv¨ands, men XML och JSON ¨ar b˚ada vanligt f¨orekommande.

F¨oljande Person-klass (listning 1) i programmeringsspr˚ak C# kommer anv¨andas f¨or att exemplifiera hur data kodas i XML respektive JSON i efterf¨oljande 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 m¨arkspr˚ak (engelska: Markup Language) som k¨annetecknas av sina taggar vilka anv¨ands f¨or uppm¨arkning av data. XML ¨ar designat f¨or att vara l¨att att l¨asa och tolka f¨or datorer, men ¨aven f¨or m¨anniskor [3]. XML anv¨ands b˚ade f¨or att lagra data p˚a filer och som ett datautbytesformat. Nedan (listning 2) f¨oljer ett exempel av en instans av 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.

2.2.2 JSON

JSON ¨ar ett textbaserat datautbytesformat som tagits fram f¨or att vara enkelt, minimalt och portabelt [4]. Formatet klarar av att representera primitiva datatyper som str¨angar, nummer, booleska v¨arden samt null, men formatet klarar ¨aven objekt och arrayer. For- matet bygger p˚a nyckel-v¨arde-par, d¨ar nyckeln alltid ¨ar en str¨ang och v¨ardet kan vara n˚agot av de f¨oreg˚aende n¨amna typer. Objekt omringas av { }, medan arrayer omring- as av [ ]. Nedan (listning 3) f¨oljer samma exempel av Person-klassen, men kodad i JSON.

{

"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 f¨or mobila enheter

F¨or mobila enheter anv¨ands aviseringar (engelska: Push notifications) n¨ar man vill upp- lysa en anv¨andare om att n˚agot har h¨ant, till exempel att ett nytt epostmeddelande har inkommit, utan att kr¨ava ett manuellt ingripande fr˚an anv¨andaren. En naiv l¨osning f¨or att uppn˚a detta vore att l˚ata varje applikation ha en egen implementation av n˚agon typ av tj¨anst som arbetar i bakgrunden och som meddelar n¨ar det finns ny information att tillg˚a. F¨or en mobil enhet skulle denna l¨osning st¨alla till problem. Enheterna har be- gr¨ansat med resurser (som till exempel batterikapacitet) och skulle p˚averkas negativt om alla applikationer med st¨od f¨or aviseringar ska ligga aktiva i bakgrund och k¨oras.

En b¨attre l¨osning ¨ar ist¨allet att man (i) inf¨or en mellanhand, ett slags ombud, som an- svarar f¨or att ta emot och sedan vidarebefordra alla aviseringar (oavsett applikation) som avser en viss mobil enhet och (ii) en bakgrundstj¨anst (f¨or alla applikationer) p˚a den mobila enheten som mottar och visuellt visar de aviseringar som har skickats via ombudet. Denna l¨osning ¨ar vad Microsoft, Apple och Google anv¨ander idag [5] [6]

[7].

Aviserings- ombud Applikationens

webbtjänst

5, * 2, 3 B

A

Mobil enhet

Applikation Aviserings-

tjänst

C 1, 4

Figur 2: Illustrerar principen f¨or aviseringsfl¨odet f¨or mobila plattformar (inspirerad av [5]). Vis- sa detaljer saknas, fr¨amst d¨ar tillverkarna skiljer sig ˚at, till exempel kr¨aver b˚ade Apple och Google att certifikat anv¨ands f¨or all kommunikation med deras aviseringsombud, vilket Microsoft inte g¨or.

F¨oljande exemplifierar registrering f¨or aviseringar (se figur 2):

1 Applikationen beg¨ar en aviseringsadress.

2 Aviseringsklienten skickar vidare f¨orfr˚agan till aviseringsombudet². 3 Aviseringsombudet returnerar en unik adress f¨or aviseringar.

4 Aviseringsklienten returnerar adressen till applikationen.

5 Applikationen registrerar sig hos sin webbtj¨anst. Inkluderar aviseringsadressen som webbtj¨ansten kan anv¨anda vid framtida aviseringar.

F¨oljande exemplifierar hur en avisering skickas (se figur 2):

A Applikations webbtj¨anst skickar en avisering till aviseringsombudet.

B Aviseringsombudet aviserar den mobila enheten.

C Aviseringsklienten visar visuellt aviseringen som inkommit eller vidarebefordrar aviseringen till applikationen³.

* Applikationen h¨amtar den faktiska informationen fr˚an sin webbtj¨anst.

2Exempelvis: Microsoft Push Notification Service, Apple Push Notification Service eller Google Cloud Mes- saging

3Denna hantering skiljer sig ˚at mellan tillverkarna

2.4 Principer f¨or objektorienterad design

Det finns en upps¨attning principer f¨or objektorienterad design som hj¨alper utvecklare att designa bra system. Principerna representerar samlade tankar och id´eer fr˚an ett stort antal mjukvaruutvecklare och forskare med m˚anga ˚ars erfarenhet inom omr˚adet [8]. Dessa principer sammanfattas av [8] som:

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

• The Open/Closed Principle (OCP)

Klasser b¨or vara ¨oppna f¨or utvidgning men st¨angda f¨or modifieringar.

• The Liskov Substitution Principle (LSP) Subtyper b¨or kunna ers¨atta sina bastyper.

• The Dependency-Inversion Principle (DIP)

H¨ogniv˚a-moduler b¨or ej bero av l˚agniv˚a-moduler, b¨agge b¨or bero av abstraktio- ner. Abstraktioner b¨or ej bero av detaljer, detaljer b¨or bero av abstraktioner.

• The Interface Segregation Principle (ISP)

Klienter b¨or inte vara tvingade att bero av metoder som de ej anv¨ander.

3 Metodik

En agil arbetsmetod anv¨andes d˚a en stor del av kraven var ok¨anda i det initiala skedet och snabbt kunde f¨or¨andras under tidens g˚ang. Agila arbetsmetoder k¨annetecknas av att vara flexibla och effektiva p˚a att hantera f¨or¨andringar i kravspecifikationen [9]. Med agila arbetsmetoder bedrivs arbetet iterativt och i inkrementella steg som ¨oppnar upp f¨or en mer kontinuerlig utv¨ardering och m¨ojlighet att styra om projektet n¨ar f¨or¨andrade eller nya krav uppkommer.

Det finns fler olika typer av agila arbetsmetoder och f¨or detta projekt valdes ett urplock av delar fr˚an Scrum [10] som arbetsmetod. Enligt skaparna av Scrum b¨or dock alla delar av metodiken till¨ampas f¨or en lyckad anv¨andning av Scrum [10], vilket dock inte var m¨ojligt i detta projekt fr¨amst av den anledningen att projektet var ett sj¨alvst¨andigt examensarbete och de agila arbetsmetoderna f¨oruts¨atter att man i sj¨alva verket arbe- tar i team, men ¨aven dess tidsbegr¨ansade form och att projektet utf¨ordes p˚a distans f¨orsv˚arade en fullst¨andig korrekt anv¨andning av metodiken. Nethouse tillhandah¨oll en produkt¨agare och en Scrumm¨astare. D˚a projektet var ett sj¨alvst¨andigt examensarbete bestod utvecklingsteamet enbart av mig.

3.1 Verktyg

Nethouse tillhandah¨oll 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¨ansten anv¨andes verktyget Fiddler [11] mycket.

3.2 Implementationsplattform - ASP.NET

ASP.NET ¨ar en samling ramverk anpassade f¨or webben framtaget av Microsoft och anv¨ands f¨or att bygga webbsidor, webbapplikationer och webbtj¨anster [12].

3.2.1 Web API

ASP.NET Web API ¨ar ett av ramverken som ing˚ar i ASP.NET-familjen, framtaget f¨or att hj¨alpa utvecklare att enklare skapa HTTP-tj¨anster (exempelvis REST-tj¨anster), som ska vara n˚abara fr˚an olika typer av klienter [13].

3.2.2 MVC

ASP.NET MVC ¨ar ett annat ramverk som ocks˚a ing˚ar i ASP.NET-familjen. Det anv¨ands f¨or att skapa webbsidor som f¨oljer Model-View-Controller-konceptet [14].

3.2.3 Entity Framework

Entity Framework (EF) ¨ar en s˚a kallad Object-Relationship Mapper (ORM), vilket anv¨ands f¨or att h¨amta och lagra data i en relationsdatabas [15]. EF agerar som ett abstraktionslager f¨or relationsdatabaser och l˚ater utvecklare undg˚a att beh¨ova skriva SQL-fr˚agor och dylikt.

3.2.4 Windows Phone SDK

Microsoft tillhandah˚aller ett s˚a kallat Software Development Kit (SDK) f¨or Windows Phone-utveckling som inneh˚aller allt man beh¨over f¨or att utveckla Windows Phone- applikationer [16]. Det medf¨oljer en kraftfull Windows Phone-emulator som har st¨od f¨or n¨astan alla funktioner som en motsvarande telefon har, exempelvis kan aviseringar skickas till emulatorn.

3.3 PushSharp

Eftersom alla mobila operativsystem idag anv¨ander sig av samma typ av id´e f¨or att skicka aviseringar (se avsnitt 2.3 Aviseringar f¨or mobila enheter), finns det ramverk att tillg˚a som hj¨alper en med att skicka aviseringen till de aviseringsombud man vill st¨odja med webbtj¨ansten. Till detta projekt har ramverket PushSharp (version 2.0) valts efter

¨onskem˚al fr˚an Nethouse.

PushSharp st¨odjer i dagsl¨aget Apple (iPhone, iPad, Mountain Lion), Android, Windows Phone (7, 7.5, 8) och Windows 8 [17]. Viktigt att p˚apeka ¨ar att ramverket fortfarande utvecklas och dess Application Programming Interface (API) kan inte ses som stabilt, utan f¨or¨andringar kan komma att ske, vilket man beh¨over ha i ˚atanke och ta s¨arskilda

˚atg¨arder f¨or n¨ar man implementera ramverket.

4 Implementation

Totalt har fyra olika system implementerats: en grundplattform, en webbtj¨anst, ett ad- ministrationsgr¨anssnitt och en mobilapplikation, d¨ar grundplattformen och mobilapp- likationen har varit av en mer betydande storlek. I detta avsnitt beskrivs ett urplock av de v¨asentligaste bitarna som utvecklingen av systemen inneburit.

4.1 Principer f¨or objektorienterad design

Nethouse kommer troligen i framtiden att ut¨oka system med mer funktionalitet och d¨arf¨or har stor vikt lagts p˚a att efterf¨olja de k¨anda principer f¨or god objektorienterad de- sign som n¨amnts i bakgrunden. Tv˚a av dessa har p˚averkat designen av systemet s¨arskilt mycket, dessa ¨ar The Single-Responsibility Principle (SRP) och The Dependency- Inversion Principle (DIP).

4.1.1 SRP

SRP s¨ager att en klass endast b¨or ha en anledning till att ¨andras [8]. En klass som har alldeles f¨or m˚anga ansvar brukar vara stora och kallas f¨or God classes. En tumregel f¨or att efterf¨olja SRP ¨ar att h˚alla klasserna sm˚a och se till att de har h¨og kohesion.

En liten klass har f˚a instansvariabler och en klass har h¨og kohesion om dess metoder anv¨ander m˚anga av klassens instansvariabler. Maximal kohesion uppn˚as om varje me- tod anv¨ander alla instansvariabler, vilket s¨allan ¨ar m¨ojligt att uppn˚a dock, men man b¨or efterstr¨ava h¨og kohesion [18]. Om man noterar grupperingar av klassens instansvariab- ler, exempelvis att variabler a och b anv¨ands uteslutande i funktionerna f och g, medan variablerna c och d anv¨ands uteslutande i funktionen h, kan det vara ett tecken p˚a att klassen g¨or mer ¨an en sak och eventuellt kan den delas upp efter dessa grupperingar.

De tumregler och tekniker n¨amnda ovan anv¨andes under projektet f¨or att identifiera fall d˚a SRP inte efterf¨oljdes.

4.1.2 DIP

N¨ar man f¨ors¨oker efterf¨olja DIP kan man som tumregel t¨anka att alla beroenden man har b¨or vara p˚a abstraktioner och inte konkreta klasser [8]. Listning 4 illustrerar anv¨and- ningen av DIP i projektet⁴. Klassen NewsController tillh¨or administrationsgr¨anssnittet och tar bland annat emot f¨orfr˚agningar om att skapa eller ¨andra nyheter. Den som ska- par eller ¨andrar en nyhet kan v¨alja att avisera nyheten och om s˚a ¨ar fallet kommer den privata metoden Push att anropas. NewsController k¨anner endast till gr¨anssnittet IPush- Service och att en metod som heter Push finns. Det ¨ar n˚agon annan klass som avg¨or och faktiskt f¨orser (via konstruktorn) NewsController med en konkret implementation av n˚agon IPushService, exempelvis PushSharpFacade.

4

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¨orenklad)

Resultatet av DIP ¨ar att man f˚ar ett system som ¨ar l¨ost kopplat (engelska: Loosely coupled) [19], d¨ar enskilda moduler eller klasser ¨ar enkla att byta ut. S¨ag att man vill byta ut PushSharp som ramverk f¨or aviseringar. En ny implementation av IPus- hSharp kan skapas och d¨arefter injiceras, helt utan att ¨andra eller ens kompilera om NewsController-klassen, vilket f¨or¨ovrigt ¨ar i enlighet med The Open/Closed Princip- le.

DIP g¨or det ¨aven l¨attare att skapa tester till klasser [19]. Exempelvis vill man inte skicka riktiga aviseringar n¨ar man testar NewsController, utan n¨ar Push i pushService anropas ska helst inget utf¨oras. Man skapar d˚a en s˚a kallad mock-klass som implemen- terar IPushService och d¨ar metoden Push inte g¨or n˚agot (se listning 5). Mock-klassen injiceras ist¨allet f¨or PushServiceFacade-klassen i testfallen f¨or NewsController, vilket resulterar i att inga aviseringar skickas n¨ar testen k¨ors.

public class PushServiceMock : IPushService {

public void Push(NewsItem newsItem) {}

}

Listning 5: En mock-klass av IPushService fr˚an listning 4, som inte utf¨or n˚agot n¨ar metoden Push anropas.

Till hj¨alp f¨or att lyckas med DIP sattes en s˚a kallad Dependency Injection (DI) con- tainer i bruk tidigt i projektet. En DI container hj¨alper till med att injicera r¨att konkret klass f¨or ett visst beroende som en annan klass har. Det ¨ar inte p˚a n˚agot s¨att ett krav att anv¨anda en DI container f¨or att efterf¨olja DIP, men det hj¨alper till en hel del n¨ar

systemen blir st¨orre [19]. Ist¨allet f¨or att manuellt knyta samman alla beroenden vid applikations startpunkt l˚ater man DI container g¨ora det automatiskt. Som DI container f¨or projektet anv¨andes Unity⁵[20] och alla beroenden injicerades via klasserna kon- struktorer.

DIP tillsammans med konstruktorinjektion kan ha en annan positiv p˚averkan och hj¨alpa till med att identifiera n¨ar en klass bryter mot SRP. N¨ar konstruktorn f¨or en klass b¨orjar f˚a m˚anga argument (d¨armed m˚anga beroenden) signalerar det att klassen i fr˚aga kanske har mer ¨an en anledning att ¨andras och d˚a bryter mot SRP [19]. Man kan d˚a unders¨oka vilka beroenden som anv¨ands tillsammans och f¨ors¨oka extrahera dessa till en egen klass.

4.2 Grundplattformen

Grundplattformen (och systemet i helhet) ¨ar uppdelad i ett antal lager. Figur 3 nedan illustrerar vilka lager som finns och deras relationer till varandra. Illustrationen visar

¨aven vilka lager webbtj¨ansten och administrationsgr¨anssnittet 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 anv¨ands i pro- jektet. Alla beroenden ¨ar p˚a abstraktioner, gr¨anssnitt i detta fall, och tre lager visas;

Repositories och Services (grundplattformen) samt Controllers (webbtj¨ansten).

5Framtaget av en grupp m¨anniskor p˚a Microsoft

Webbtjänsten Grundplattformen

Repositories Device Repository

Implementation

<<interface>>

Device Repository

Services

Device Service Implementation

<<interface>>

Device Service

Controllers

Device Controller

Figur 4: Exemplifiering av skiktning och DIP f¨or projektet (i sj¨alva verket ¨ar gr¨anssnitt och konkreta implementationer placerade i separata projekt).

4.2.1 Dom¨anmodeller, databas och dataaccess

F¨or systemet definierades ett antal dom¨anmodeller: NewsItem, Category, Office, Image och Device, som beskriver nyheter, kategorier, kontor, bilder respektive enheter. Dom¨an- modellerna ¨ar placerade i ett eget projekt (lager) och saknar sj¨alva n˚agra beroenden, ist¨allet har i princip alla andra lager ett beroende p˚a dom¨anmodellerna.

Databas ¨ar upptill Nethouse att v¨alja vid produktionss¨attning, vid utveckling har SQL Server Compact anv¨ands. Systemet kr¨aver en databas som ¨ar kompatibel med Micro- soft Entity Framework (EF).

Utvecklingen av databasen har skett med arbetsfl¨odet Code-First development f¨or EF.

Code-First development l˚ater anv¨andaren definiera dom¨anmodeller med vanliga POCO- klasser⁶och d¨arefter generera databasen utefter dessa modeller. Listning 6 visar dom¨an- modellen som beskriver enheter i systemet.

6Plain Old CLR Object - vanligt .NET objekt

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

F¨or att isolera beroenden samt anv¨andningen av EF, skapades s˚a kallade repository- klasser f¨or alla dom¨anmodeller. Tj¨ansterna i tj¨anstelagret (eller andra klasser f¨or den delen) g¨or aldrig n˚agra direkta anrop till EF, utan deras anrop ¨ar alltid till n˚agon av repository-klasserna.

4.2.2 Tj¨anster

All interaktion med grundplattformen fr˚an webbtj¨ansten och administrationsgr¨anssnit- tet sker via n˚agon av de tj¨anster som skapats. Tj¨ansterna tar emot f¨orfr˚agningar fr˚an webbtj¨ansten och administrationsgr¨anssnittet som de validerar och exekverar. Det kan handla om att validera att anv¨andaren har r¨attigheter till en viss resurs eller att injicera anv¨andarens kontor i fr˚agan till dataaccesslagret f¨or att exempelvis endast h¨amta alla nyheter tillh¨orande anv¨andarens kontor.

4.2.3 Aviseringstj¨anst

F¨or aviseringar implementerades ramverket PushSharp. N¨ar man anv¨ander sig av tredje- parts bibliotek m˚aste man ta i beaktande hur stor risk det ¨ar att dess API kan komma att f¨or¨andras eller att man kommer vilja byta till ett annat bibliotek i framtiden. Finns en risk f¨or detta b¨or man se till att isolera anv¨andningen av biblioteket s˚a att en framtida

¨andring ¨ar enkel att utf¨ora och inte kr¨aver ¨andringar runt om i hela kodbasen. D˚a Push- Sharp fortfarande utvecklas kraftigt och dess API kan komma att ¨andras vid framtida uppdateringar var det viktigt att ramverket separerades fr˚an projektet i ¨ovrigt.

L¨osningen var att isolera all kod r¨orande PushSharp i ett separat projekt och definiera ett gr¨anssnitt (engelska: Interface) f¨or aviseringar som den egna kodbasen kunde bero av (se listning 7).

public interface IPushService {

void Push(NewsItem newsItem, Device device);

}

Listning 7: Gr¨anssnitt f¨or att skicka aviseringar.

Gr¨anssnittet ovan implementerades sedan i det separata PushSharp-projektet. Sker i framtiden f¨or¨andringar i PushSharps API ¨ar de ¨andringarna som man beh¨over g¨ora isolerade till det projektet. Vill man vid ett senare skede byta till n˚agot annat ramverk f¨or aviseringar kan man p˚a nytt implementera gr¨anssnittet ovan med det nya ramverket och anv¨anda den implementationen i st¨allet.

4.2.4 Exemplifiering av skiktningen

F¨oljande kod-listningar visar vilka metoder som ¨ar 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¨orfr˚agan i webbtj¨ansten och vidarebeford- rar den till tj¨anstelagret d¨ar UpdateDevice som syns i listning 9 tar ¨over och utf¨or aff¨arslogiken kring uppdateringen. D¨arefter anropas Update i dataaccesslagret (listning 10) som l˚ater dess basklass utf¨ora sj¨alva 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˚an DeviceController i webbtj¨ansten) som hanterar registreringsuppdateringar via PUT-f¨orfr˚agningar fr˚an mobila klienter.

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˚an DeviceService i grundplattformens tj¨anstelager) som utf¨or aff¨arslogiken g¨allande registreringsuppdateringar.

public void Update(Device device) {

UpdateOnCommit(device);

}

Listning 10: Metoden Update (fr˚an 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˚an EFRepository i grundplattformens dataaccesslager) som

¨ar basklassen till alla repositories.

4.3 Mobilapplikationen

I f¨oljande sektion beskrivs n˚agra av de v¨asentligaste delarna fr˚an utvecklingen och im- plementationen av mobilapplikationen. F¨or att referera till mobilapplikationen kommer

¨aven mobilappen samt appen att anv¨andas.

4.3.1 Anv¨andargr¨anssnitt

F¨or att ta fram en design samt f¨or att v¨alja f¨arger till mobilappen fanns tv˚a val, an- tingen kunde Nethouse grafiska profil efterf¨oljas eller s˚a kunde det temakoncept som Microsoft tillhandah˚aller f¨or Windows Phone anv¨andas. Efter diskussion f¨oll valet p˚a temakonceptet ist¨allet f¨or den grafiska profilen, dels d˚a vissa anv¨andare f¨oredrar ljus text mot m¨ork bakgrund och andra tv¨artom vilket d˚a automatiskt anpassar sig efter anv¨andarens preferenser och dels f¨or att det ger appen en k¨ansla av att vara en ur- sprungsapplikation (engelska: Native application).

Skisser togs fram f¨or anv¨andargr¨anssnittet (se bilaga A Skisser mobilapplikation p˚a si- dan 33) som med avsikt f¨ors¨oker utnyttja n˚agra av plattformens k¨annetecken f¨or att skapa k¨anslan av en nativ applikation. Tanken var inte att skapa en design som ¨aven var applicerbar f¨or de ¨ovriga plattformarna, utan tanken var att varje mobilapplikation skulle utnyttja den egna plattformens styrkor. Ett tydligt exempel ¨ar valet av kompo- nenten som anv¨ands f¨or att v¨axla mellan senaste nytt och de olika kategorierna, kallad Pivot control. En pivot control ger ett enkelt och snabbt s¨att att v¨axla mellan olika vyer och anv¨ands flitigt i appar f¨or att visa samma inneh˚alla men filtrerat efter olika kriterier, vilket ¨ar passande h¨ar, d¨ar man filtrerar antingen efter senaste nytt eller efter en kate- gori. F¨or att byta vy sveper (engelska: Swipe) man horisontellt p˚a valfri del av ytan.

Forts¨atter man att svepa i samma riktning cirkulerar man runt alla vyer, som figur 5 illustrerar.

Figur 5: Anv¨andaren kan navigera mellan senaste nytt och de olika kategorierna genom att svepa horisontellt ¨over sk¨armen. Nyheterna h¨amtas dynamiskt n¨ar de beh¨ovs.

Normalt skapar man pivot-kontrollen statiskt vid kompilering, detta ¨ar dock inte m¨ojligt f¨or mobilappen, d˚a det saknas f¨ordefinierade kategorier. Vad som beh¨ovs ¨ar ist¨allet att dynamiskt skapa de pivot-vyer som beh¨ovs under k¨orning. Efter att anv¨andaren loggat

in h¨amtas alla kategorier fr˚an webbtj¨ansten och pivot-kontrollen skapas och d¨arefter h¨amtas de senaste nyheterna. F¨or att begr¨ansa den ¨overf¨orda datam¨angden h¨amtas ny- heterna f¨or varje kategori f¨orst n¨ar anv¨andaren navigerar till dem.

F¨or att ytterligare begr¨ansa den ¨overf¨orda datam¨angden implementerades s˚a kallad pa- ginering f¨or webbtj¨ansten vilket m¨ojligg¨or h¨amtning av endast ett delresultat av ny- heter. F¨or mobilapplikationen h¨amtas tio nyheter i taget. ¨Aldre nyheter h¨amtas au- tomatiskt n¨ar anv¨andaren rullar (engelska: Scroll) ned˚at vilket skapar en illusion av en o¨andlig str¨om av nyheter. Denna funktionalitet saknas i de list-komponenter som finns f¨or Windows Phone och m˚aste implementeras p˚a egen hand. F¨or nyhetslistningen anv¨ands list-komponenten LongListSelector, denna komponent har en h¨andelse kal- lad Link som h¨ojs varje g˚ang ett objekt i listan blir synligt f¨or anv¨andaren. F¨or att bed¨oma var i listan anv¨andaren ¨ar implementerades en funktion som lyssnar efter Link- h¨andelsen och som varje g˚ang h¨andelsen h¨ojs ber¨aknar:

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

N¨ar avst˚andet fr˚an listans sista objekt och det sista synliga objektet ¨ar mindre eller lika med ett konfigurerbart offset, d˚a h¨amtas fler nyheter.

4.3.2 Registrering f¨or aviseringar

F¨or att f˚a aviseringar kr¨avs det dels att mobilapplikationen (enheten) registrerar sig hos Microsoft Push Notification Service (h¨arefter MPNS) och dels att den registrerar sig hos den egna webbtj¨ansten. Microsoft rekommenderar att detta sker varje g˚ang mobilapplikationen startas [21].

N¨ar anv¨andaren aktiverar aviseringar under inst¨allningar s˚a kommer registreringspro- ceduren att utf¨oras och d¨arefter kommer den att utf¨oras efter inloggning vid varje upp- start av appen. Nedan f¨oljer beskrivning av hur registreringen sker hos b˚ade MPNS och webbtj¨ansten.

Registrering hos MPNS

Innan mobilappen kan registrera sig hos webbtj¨ansten kr¨avs det att den har f˚att en Channel Uri fr˚an MPNS-tj¨ansten. Det ¨ar denna adress webbtj¨ansten sen anv¨ander sig av f¨or att skicka aviseringar till mobilappen.

Mobilappen b¨orjar med att kolla om det redan finns en ¨oppen kanal mellan telefo- nen och MPNS. Appen registrerar sig direkt hos webbtj¨ansten om s˚a ¨ar fallet annars f¨ors¨oker den f¨orst att skapa en ny kanal till MPNS-tj¨ansten. N¨ar en lyckad kanal v¨al har skapats kommer MPNS meddela mobilappen via h¨andelsen ChannelUriUpdated om detta och d˚a kommer mobilappen i sin tur att registrera sig hos webbtj¨ansten.

Registrering hos webbtj¨ansten

Det finns tv˚a typer av registreringar hos webbtj¨ansten. Den ena ¨ar en nyregistrering som sker f¨orsta g˚angen mobilappen registrerar sig hos webbtj¨ansten och den andra ¨ar en uppdatering av en redan befintlig registrering som sker varje g˚ang appen startar efter sin f¨orsta registrering. Nyregistreringar och uppdateringar sker genom att appen skickar en POST-f¨orfr˚agan respektive PUT-f¨orfr˚agan till webbtj¨ansten (se 5.2.2 Registrering f¨or aviseringar f¨or detaljer). N¨ar en nyregistrering har lyckats lagras det enhets-id som returneras av webbtj¨ansten i telefonens permanenta lagringsutrymme.

4.3.3 Kommunikation med webbtj¨ansten

All n¨atverkskommunikation som sker i en Windows Phone-app m˚aste utf¨oras asyn- kront, det saknas helt bibliotek som till˚ater synkrona anrop. Microsoft har gjort detta val f¨or att f¨ors¨akra sig om att anv¨andargr¨anssnittet alltid svarar p˚a anv¨andaren interaktion och inte l˚aser sig i v¨antan p˚a ober¨akneliga n¨atverksanrop som kan ta l˚ang tid.

Nyligen sl¨appte Microsoft ett bibliotek f¨or Windows Phone 7 som g¨or det l¨attare att skriva asynkrona funktioner. Med biblioteket markerar man asynkrona funktioner med ordet async i funktionshuvudet och anv¨ander await som prefix vid de anrop som ska ske asynkront i funktionskroppen. Se listning 12 nedan f¨or 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.

F¨or all kommunikation med webbtj¨ansten anv¨ands async-await p˚a liknande s¨att, ett ex- empel visas i listning 13, som ¨ar koden f¨or att h¨amta senaste nytt fr˚an webbtj¨ansten. H¨ar ser vi att async-await kan kedjas vid flera funktionsanrop och att await kan anv¨andas flera g˚anger i samma funktion.

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 f¨or att h¨amta senaste nytt fr˚an webbtj¨ansten (vissa detaljer utel¨amnade).

4.3.4 Inloggning och s¨akerhet

Som tidigare n¨amnts omfattades inte projektet av att unders¨oka och ta fram en s¨akerhets- l¨osning f¨or de olika systemen, detta skulle Nethouse utf¨ora parallellt. Nethouse hann ta fram s¨akerhetsl¨osningar f¨or webbtj¨ansten och administrationsgr¨anssnittet, vilka ¨ar implementerade. Dock finns ¨annu ingen l¨osning f¨or mobilapplikationen. Det mesta av logiken f¨or inloggningen ¨ar dock p˚a plats, den funktion som beh¨over kompletteras ¨ar tryToAuthenticate som faktiskt utf¨or sj¨alva autentiseringen mot deras autentiserings- tj¨anst.

Ett av kraven fr˚an Nethouse var att anv¨andarnamn och l¨osenord skulle kunna lagras i appen, s˚a att anv¨andaren slipper tillhandah˚alla dessa manuellt varje g˚ang appen star- tas. Vidare kommer man n¨ar l¨osningen ¨ar f¨ardig att f˚a ett token vid autentiseringen som anv¨ands vid alla anrop till webbtj¨ansten. Denna token kommer att ha ett visst utg˚angsdatum, s˚a l¨ange detta datum inte passerat beh¨over ingen ny inloggning ske vid start av appen. Denna token beh¨over s˚aledes ocks˚a lagras.

L¨osenord och andra identifieringsobjekt (s˚a som en token) b¨or aldrig lagras i klartext utan ska krypteras innan lagring. Till hj¨alp f¨or krypteringen anv¨ands det medf¨oljande biblioteket ProtectedData. ProtectedData har tv˚a funktioner: Protect och Unprotect, som krypterar respektive dekrypterar byte-arrayer. F¨or att kryptera en str¨ang av tecken beh¨over man s˚aledes f¨orst konvertera str¨angen till en byte-array och d¨arefter anropa Protect-funktionen som d˚a returnerar en krypterad byte-array. F¨or dekryptering utf¨ors stegen bakv¨ant och med Unprotect ist¨allet f¨or Protect.

dows Phone-applikation har ett s˚adant utrymme kallat IsolatedStorage, som endast ¨ar synligt f¨or den app utrymmet tillh¨or. Kryptering och lagring implementerades som en generell hj¨alpklass vilken anv¨ands f¨or s¨aker lagring av b˚ade l¨osenordet och det token som autentiseringen returnerar. Listning 14 visar hur krypteringen utf¨ors (lagringen sker i funktionen W riteToFile).

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 f¨or att kryptera och lagra en str¨ang av tecken.

4.4 Webbtj¨ansten

Webbtj¨ansten f¨oljer REST-principen beskriven i bakgrunden (se avsnitt 2.1 Vad ¨ar en webbtj¨anst) och ¨ar implementerad med Microsoft ASP.NET Web API. Webbtj¨ansten best˚ar av fyra resurser; nyheter, kategorier, kontor och enheter vilka implementerads som Controllers i Web API-ramverket. En resurs i REST-arkitekturen har ett antal me- toder, bland andra GET, POST, PUT och DELETE. F¨or Web API implementeras dessa som vanliga metoder i Controller-klasserna. Som konvention namnges dessa metoder med HTTP-metodernas namn som prefix.

Tack vare grundplattformens tj¨anstelager inneh˚aller dessa Controllers knappt n˚agon logik. Listning 15 visar funktionen som h¨amtar en nyhet, som synes ¨ar den v¨aldigt kort, d¨ar den viktiga logiken ¨ar dold i tj¨anstelagret. Det ¨ar tj¨ansten newsSerivce som h¨amtar nyheten via dataaccesslagret och validerar att anv¨andaren faktiskt har r¨att att h¨amta nyheten ifr˚aga.

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 f¨or att h¨amta en nyhet via webbtj¨ansten.

4.4.1 Design av resurser

Systemets resurser: nyheter, kategorier och enheter var enkla att identifiera och imple- mentera. Tv˚a av resurserna; nyheter och kategorier, beh¨ovde endast funktionalitet f¨or att h¨amta nyheter respektive kategorier. Den tredje resursen enheter, beh¨ovde tre opera- tioner: skapa, uppdatera och ta bort en enhet, vilka kan mappades till HTTP-metoderna POST, PUT respektive DELETE. F¨or en komplett och detaljerad samling av alla resur- ser och deras operation, se avsnitt 5.2 Webbtj¨ansten.

4.4.2 Datautbytesformat

JSON valdes som databytesformat tack vare dess minimala overhead [1], d¨ar under- s¨okningar [22] visar att JSON producerar data som ¨ar signifikant mindre ¨an XML, vilket ¨ar viktigt n¨ar begr¨ansade resurser ¨ar involverade, s˚a som mobila enheter och internetanslutningar. Fr¨amsta anledning till att JSON har mindre overhead ¨an XML

¨ar f¨or att JSON inte anv¨ander sig av sluttaggar som XML g¨or. Anv¨ands kompression s˚a blir storlekarna f¨or JSON och XML relativt j¨amf¨orbara, men d˚a tillkommer ist¨allet processer som komprimerar och dekomprimerar data, vilket stj¨al resurser som cpu-tid ist¨allet.

4.5 Administrationsgr¨anssnittet

Med hj¨alp av Microsoft ASP.NET MVC togs ett enklare administrationsgr¨anssnitt fram. Precis som f¨or webbtj¨ansten best˚ar administrationsgr¨anssnittet fr¨amst av en upp- s¨attning Controllers som h¨amtar och lagrar data via tj¨anstelagret i grundplattformen.

Tv˚a Controllers implementerades; News- och CategoryController. Dessa st¨odjer stan- dard CRUD-operationer⁷, d¨ar varje operation implementeras som en metod i sin till- h¨orande Controller. F¨or varje operation finns en tillh¨orande vy.

5 Resultat

Projektet har resulterat i fyra delsystem (se figure 6); en grundplattform inneh˚allande databasen samt aff¨arslogiken, en webbtj¨anst f¨or att st¨odja de mobila klienterna, ett gr¨anssnitt f¨or 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: H¨ogniv˚a

5.1 Mobilapplikationen

Motivet bakom projektet var att skapa en m¨ojlighet f¨or Nethouse att enklare sprida in- formation till alla deras konsulter och mobilapplikationen ¨ar ut˚at sett resultatet av detta.

Funktionsm¨assigt ¨ar den komplett s˚a n¨ar som p˚a autentiseringen (vilket ligger utanf¨or examensarbetets omfattning). De funktioner som efterfr˚agades var st¨od f¨or avisering- ar och m¨ojlighet att l¨asa nyheter direkt i appen, listade efter senaste nytt samt efter kategori.

5.1.1 Vyer och navigation

I f¨oljande sektion beskrivs de olika vyer som mobilapplikationen best˚ar av samt hur navigationen sker mellan dessa. F¨arger och textstorlekar styrs av telefonens tema, vilket medf¨or att om anv¨andaren till exempel f¨oredrar ljus text mot m¨ork bakgrund har denna troligtvis st¨allt in ett m¨orkt tema p˚a telefonen och som d˚a mobilapplikationen efter- f¨oljer. F¨or sk¨armdumparna nedan anv¨ands ett ljust tema med turkos accentf¨arg.

Inloggnings-vy

F¨orsta g˚angen anv¨andaren startar mobilapplikationen m¨ots denne av en inloggning (se figur 7). Applikationen krypterar och lagra anv¨andaruppgifterna lokalt p˚a telefonen f¨or att vid n¨astkommande start automatiskt logga in anv¨andaren. Inloggningsuppgifter- na f¨orsvinner f¨orst n¨ar anv¨andaren antingen v¨aljer att logga ut alternativt avinstallerar applikationen. Efter en viss tid kommer ¨aven autentiseringen l¨opa ut och d˚a kommer anv¨andaren uppmanas att uppge inloggningsuppgifterna p˚a nytt vid start av applikatio- nen.

Figur 7: Sk¨armdumpar av inloggning

Nyhetslistnings-vy

N¨ar applikationen har autentiserat anv¨andare f¨orflyttas denna automatiskt till listan med de senaste nyheterna (se figur 8). Varje nyhet presenteras med en mindre bild, en nyhetsrubrik samt ett publiceringsdatum. Fr˚an denna vy har anv¨andaren f¨oljande val:

• Trycka p˚a en av de synliga nyheterna och f¨orflyttas till en vy som visar alla detaljer om den valda nyheten.

• Rulla (engelska: Scroll) ned˚at f¨or att se ¨aldre nyheter. N¨ar anv¨andaren b¨orjar n¨arma sig slutet p˚a listan laddas automatiskt ¨annu ¨aldre nyheter in och skapar en illusion av en o¨andlig lista.

• Svepa till h¨oger alternativt v¨anster byter mellan de olika kategorierna samt se- naste nytt.

• Trycka p˚a listen l¨angst ner exponerar en meny med alternativen uppdatera nyheter och inst¨allningar. Uppdatera nyheter anv¨ands f¨or att ladda in nya publicerade nyheter som kan ha uppkommit efter att applikationen startades. Inst¨allningar tar anv¨andaren till inst¨allnings-vyn.

Figur 8: Sk¨armdumpar av nyhetslistningar

Nyhets-vy

N¨ar anv¨andaren navigerat till en specifik nyhet m¨ots denne av all tillg¨anglig infor- mation tillh¨orande nyheten (se figur 9). ¨Overst ¨ar nyhetsrubriken som f¨oljs av kategori, f¨orfattare och publiceringsdatum. D¨arefter visas en st¨orre variant av bilden som syntes i nyhetslistningen. Efter bilden kommer en sammanfattning och sj¨alva nyhetsinneh˚allet.

Nyhetsinneh˚allet st¨odjer enklare formatering s˚a som fet, kursiv, och understruken stil, det finns ¨aven st¨od f¨or listor samt externa l¨ankar. Om anv¨andaren trycker p˚a en l¨ank

¨oppnas mobilens webbl¨asaren och l¨anken laddas.

Figur 9: Sk¨armdump av en nyhet

Inst¨allnings-vy

Inst¨allnings-vy (se figur 10) har i dagsl¨aget endast tv˚a val. Anv¨andare kan logga ut (vilket ¨aven tar bort sparade inloggningsuppgifter) eller aktivera/inaktivera avisering- ar.

Figur 10: Sk¨armdump av inst¨allningar

5.1.2 Aviseringar

N¨ar en nyhetspublicist v¨aljer att avisera en viss nyhet kommer detta visa sig p˚a tv˚a s¨att f¨or mobilanv¨andaren (se figur 11). Dels visas en kort stund ett s˚a kallat Toast- meddelande⁸best˚aende av nyhetens rubrik och dels uppdateras mobilappliktionens s˚a kallade Tile⁹med antalet aviserade nyheter, publicerade efter det att anv¨andaren senast anv¨ande mobilapplikationen.

Figur 11: Sk¨armdumpar av aviseringar

5.2 Webbtj¨ansten

Webbtj¨anstens syfte ¨ar att st¨otta de mobila klienterna (i dagsl¨aget endast Windows Phone-mobilapplikationen) genom att f¨orse dessa med nyheter samt till˚ata dem att re- gistrera sig f¨or att f˚a framtida nyhetsaviseringar.

5.2.1 Konsumera nyheter och kategorier

De mobila enheterna ¨ar i behov av att ˚atminstone kunna h¨amta alla tillg¨angliga katego- rier, de senaste publicerade nyheterna och publicerade nyheter tillh¨orande en specifik kategori. F¨oljande API m¨ojligg¨or detta:

8Den bl˚aa rektangeln i ¨overkant (p˚a den h¨ogra sk¨armdumpen) i figur 11

9De bl˚aa kvadraterna i figur 11

H¨amta publicerade nyheter

URI: api/news?pageNumber=X&pageSize=Y

HTTP-metod: GET

Respons: Se 5.2.3 Datautbytesformat (Respons - Nyheter)

Kommentar: Parametrarna pageNumber och pageSize ¨ar valfria och f˚ar X = 1 och Y = 10 som standard. Anv¨ands f¨or att endast ge ett delresultat av alla nyheter.

H¨amta nyhet med id = ID

URI: api/news/ID

HTTP-metod: GET

Respons: Se 5.2.3 Datautbytesformat (Respons - En nyhet)

H¨amta alla kategorier

URI: api/category

HTTP-metod: GET

Respons: Se 5.2.3 Datautbytesformat (Respons - Kategorier)

H¨amta publicerade nyheter i kategorin med id = ID

URI: api/category/ID/news?pageNumber=X&pageSize=Y

HTTP-metod: GET

Respons: Se 5.2.3 Datautbytesformat (Respons - Nyheter)

Kommentar: Parametrarna pageNumber och pageSize ¨ar valfria och f˚ar X = 1 och Y = 10 som standard. Anv¨ands f¨or att endast ge ett delresultat av alla nyheter.

5.2.2 Registrering f¨or aviseringar

F¨or att en mobil enhet ska f˚a nyhetsaviseringar kr¨avs det att denna registrerar sig hos webbtj¨ansten. PushId som n¨amns ska vara det id¹⁰som plattformens aviseringsombud tilldelar enheten. F¨oljande API m¨ojligg¨or registrering och avregistrering samt uppda- tering av befintlig registrering.

10Kallas f¨or Channel uri av Microsoft, Device token av Apple och Device registration id av Google

Registrering av en ny enhet

URI: api/device

F¨orfr˚agan: Se 5.2.3 Datautbytesformat (Beg¨aran - Registrering av enhet)

HTTP-metod: POST

Respons: Enhetens nya id (av typen Guid)

Kommentar: DeviceType kan i dagsl¨aget vara WindowsPhone, Apple eller Android

Uppdatera registreringen f¨or enheten med id = GUID

URI: api/device

HTTP-metod: PUT

Beg¨aran: Se 5.2.3 Datautbytesformat

(Beg¨aran - Uppdatering av en enhets registrering)

Avregistrerar enheten med id = GUID

URI: api/device/GUID

HTTP-metod: DELETE

5.2.3 Datautbytesformat

Som datautbytesformat anv¨ands JSON. Nedan beskrivs de f¨orfr˚agan- och respons- meddelanden (engelska: request and response) som tas emot av eller skickas fr˚an webb- tj¨ansten.

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>>

] }

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[]>

} }

F¨orfr˚agan - Registrering av enhet

{

"PushId" : <PUSH_ID : string>,

"DeviceType" : <DEVICE_TYPE : string>

}