EXAMENSARBETE. Android-applikation för hälsokontroll. Nicklas Pettersson. Högskoleingenjörsexamen Datateknik

Transkript

1 EXAMENSARBETE Android-applikation för hälsokontroll Nicklas Pettersson Högskoleingenjörsexamen Datateknik Luleå tekniska universitet Institutionen för system- och rymdteknik

2 Sammanfattning Denna rapport beskriver planering och utveckling av en Android-applikation och en webbtjänst på uppdrag av Explizit AB. Applikationen och webbtjänsten ska vara knutna till CheckUp Life, en produkt för kontroll och uppföljningar av personers hälsostatus. Kraven är att Android-applikationen visuellt och funktionsmässigt ska likna den webbapplikation som idag existerar för CheckUp Life samt att kommunikation mellan applikation och webbtjänst håller hög säkerhet. Resultatet blev en REST-baserad webbtjänst, med WCF i grunden, säkrad med SSL och basic authentication och en Android-applikationen som kommunicerar med webbtjänsten samt visuellt och användarmässigt liknar webbapplikationen. i

3 Abstract This report describes the planning and development of an Android application and a web service on behalf of Explizit AB. The application and the web service shall be linked to CheckUp Life, a product for supervising and monitoring of people s health status. The requirements are that the Android application shall visually and functionally be similar to the web application that currently exists for CheckUp Life, and that the communication between application and web service is highly secured. The result was a RESTful web service, based on WCF, secured with SSL and basic authentication and an Anrdroid application that communicated with the web service and visually and functionally is similar to the web application. ii

4 Innehåll 1 Inledning Bakgrund Problem Teori Android Applikationer och säkerhet Windows Communication Foundation Kommunikation SOAP Representational State Transfer Meddelandeformat XML JSON Secure Sockets Layer Autentisering Basic access authentication Digest access authentication Metod Utrustning och utvecklingsmiljö Systemöversikt Utveckling av app Inloggning Diagram Kalender Träningsdagbok Detaljer Metoddetaljer Utveckling av webbtjänst Kommunikation WCF Säkerhet Konfidentialitet och integritet Autentisering Resultat Genomgång av funktionalitet Diskussion Fortsatt arbete iii

5 Figurer 1 Systemöversikt Skiss för användargränssnitt Inloggning Diagram som visar mätdata Kalender Träningsdagbok Detaljer Metoddetaljer iv

6 1 Inledning Detta examensarbete består av att skapa en Android-applikation och en webbtjänst till hälsokontrollssystemet CheckUp Life. Arbetet utförs åt Explizit AB i Skellefteå. 1.1 Bakgrund Explizit är ett konsultbolag med ett 40-tal anställda där merparten är placerade i huvudkontoret i Skellefteå och ett fåtal i Göteborg och Malmö. Företagets huvudsakliga inriktningar är inom områdena hälsa, fordonslösningar, industri och telekom. Explizit har en egenutvecklad produkt vid namn CheckUp som används för att på ett enkelt och effektivt sätt göra kontroller och uppföljningar av personers hälsostatus. Produkten består av en väska med olika mätverktyg som används för att kontrollera bland annat vikt, blodtryck, kolesterol m.m. För att registrera mätvärdena får varje person som är ansluten till systemet ett personligt id-kort som gör att värdena registreras på rätt person. Väskan innehåller en trådlös accesspunkt som används för att överföra de uppmätta värdena och slutligen överförs informationen till en databas för uppföljning. På en personlig webbsida är det sedan möjligt att avläsa förändringar och trender på ett grafiskt lättöverskådligt sätt. På webbsidan finns det även möjlighet att få information om de olika mätmetoderna och föra träningsdagbok. 1.2 Problem För att användarna ska få större valfrihet och ökad mobilitet, så att man via sin smartphone kan se sina värden och göra registreringar i sin träningsdagbok, behövs en mobilapp för detta. CheckUp Life består av en databas och en webbapplikation. Idag saknar CheckUp Life en webbtjänst för att kunna kommunicera med mobilappar. I examensarbetet ingår att skapa en webbtjänst för kommunikation med mobilappar samt skapa en Android-app för CheckUp Life. För webbtjänsten ska det avgöras vilken arkitektur eller vilket protokoll som bör användas för kommunikation mellan klient och server. En lämplig metod för att autentisera användarna ska tas fram och även en reflektion om säkerhet och eventuella åtgärder som tagits för att fastställa en hög säkerhet för användarna. Det ska fastställas vad som behövs i webbtjänsten för att en utvecklad app ska kunna hämta och spara information i databasen. Utvecklingen för detta ska göras i C#.NET. Vad gäller appen så ska det analyseras och verifieras att det befintliga grafiska gränssnittet i webbapplikationen fullt ut går att implementera i en app. Om problem uppstår så ska alternativa grafiska lösningar tas fram för att presentera informationen på ett bra och tydligt sätt i appen. I övrigt ska appen ha liknande design och grafisk profil som webbapplikationen för att användarna ska känna igen sig. 1

7 2 Teori 2.1 Android Android är ett Linuxbaserat operativsystem skapat för smartphones och läsplattor. Android utvecklas av Open Handset Alliance m.fl. och är dominanta på marknaden med 50.9% av marknadsandelen av sålda smartphones under fjärde kvartalet 2011[1]. Utvecklingen av applikationer sker med hjälp av Android SDK med språket Java Applikationer och säkerhet En Android-app skapas genom att kompilera kod- och resursfiler till ett Android package i form av en.apk-fil som sedan kan installeras i systemet. Varje applikation körs i en sandbox där följande regler gäller: Varje applikation är en egen användare i systemet. Endast användaren associerad med applikationen har access till dess filer. Varje applikation körs på en egen process. Varje process har sin egen virtual machine och är helt isolerad från andra applikationer. 2.2 Windows Communication Foundation Windows Communication Foundation (WCF) är ett API, tillhörande.net-ramverket, för att bygga tjänsteorienterade applikationer[2][3]. WCF är baserat kring Service-Oriented Architecture (SOA) där tjänsteapplikationen exponerar sina funktioner för klienterna. Fundamentala koncept för WCF är: Tjänst En entitet som exponerar ett antal slutpunkter för klienterna. Slutpunkt En entitet där meddelande kan skickas och tas emot. Den består av en adress, bindning och operationskontrakt. Adress En identifierare för kommunikation. Specificeras av en URI. Bindning Definierar hur en slutpunkt ska kommunicera. Här avgörs vilket transportprotokoll som ska användas, hur meddelandet ska kodas och om det ska skyddas på något sätt. 2

8 Kontrakt Operationskontrakt definierar vilka parametrar och vilken returtyp som gäller för den funktion som knyts till en slutpunkt. Datakontrakt beskriver avancerade datatyper som kan användas som en parameter eller returtyp. 2.3 Kommunikation För meddelandehanteringen mellan webbtjänst och klient används vanligtvis protokollet SOAP[4] eller en implementation enligt arkitekturen REST[5] SOAP SOAP är ett protokoll som vanligtvis används inom webbtjänster för utbyte av information. För att skicka SOAP-meddelanden används vanligtvis något av protokollen i applikationslagret, så som HTTP. Som meddelandeformat används XML[4]. SOAP-meddelanden består av ett så kallat SOAP Envelope som innehåller en header (valfritt) och en body. Headern kan innehålla uppgifter om autentisering eller annan sessionsdata, body innehåller den faktiska datan som ska behandlas av den endpoint som det skickas till Representational State Transfer Representational State Transfer (REST) är en arkitektur för distribuerade system beskriven av Roy T. Fielding. Den beskriver ett antal begränsningar för arkitekturen och genom att en service följer dessa (kod på begäran är frivillig) så kan den benämnas som RESTbaserad[5]: Klient-server Genom att helt separera klient och server så ökas klientens portabelitet och serverns skalbarhet samt att delarna kan utvecklas oberoende av varandra. Tillståndslös Varje serveranrop från klienten ska innehålla tillräcklig information för att utföra begäran och servern får inte använda sparad information för att förenkla anropet. Detta gör att servern ökar skalbarheten då den snabbt kan frigöra resurser och den blir pålitligare genom lättare återställning från fel. Cache Serversvar ska kunna sättas som cachebara eller icke cachebara för att öka prestandan och skalbarheten. Enhetligt gränssnitt Varje resurs ska vara adresserbar och resurserna och svaren ska innehålla en representation av resurserna. Om en klient innehar en representation av en resurs kan klienten 3

9 modifiera resursen på servern om den har de rättigheterna. Varje anrop innehåller tillräckligt med information för att veta hur det ska hanteras. Lagersystem Klienten ska inte kunna avgöra om den kommunicerar med en slutserver eller mellanliggande servrar som kan användas för exempelvis lastbalansering. Kod på begäran Servrar kan utöka sin funktionalitet genom att överföra exekverbar kod till klienten. REST används vanligtvis genom HTTP för att skicka meddelanden och använder då metoderna GET, POST, PUT, DELETE för accessen till resurserna. Vilket meddelandeformat som används är valfritt men vanligtvis används XML eller JSON. 2.4 Meddelandeformat De meddelandeformat som jag väljer som aktuella för att använda, baserat på vad som ska komma att stödjas, är XML[6] och JSON[7] XML Extensible Markup Language (XML)[6] är ett märkspråk som definierar en dokumentkodning med data i klartext som är enkel även för människor att kunna läsa och förstå. Den syntax som används är <namn>innehåll</namn> där ett exempel på telefonbok kan se ut så här: <telefonbok> <namn>john Doe</namn> <telefonnummer> <typ>hemma</typ> <nummer> </nummer> </telefonnummer> <telefonnummer> <typ>jobb</typ> <nummer> </nummer> </telefonnummer> </telefonbok> JSON JavaScript Object Notation (JSON)[7] är en klartextbaserad standard för datautbyte härlett från JavaScript vars design gör det lätt för människor att läsa. Det stödjer ett antal primitiva typer och syntaxen som används är namn : innehåll där motsvarande telefonbok ovan kan se ut så här: 4

10 { } "namn":"john Doe" "telefonnummer": [ { "typ":"hemma" "nummer":" " }, { "typ":"jobb" "nummer":" " } ] 2.5 Secure Sockets Layer Secure Sockets Layer (SSL)[9] är ett säkerhetsprotokoll som ger möjlighet till krypterad kommunikation över internet. En session initieras genom en handskakning där parterna kommer överens om vilken kryptering som ska användas och de nödvändiga nycklarna skapas och utbytes. Under handskakningen autentiserar sig servern genom att skicka ett certifikat till klienten. För att detta certifikat ska anses som giltigt ska det ha utfärdats av en certificate authority (CA) som garanterar att certifikatet är äkta. Det är även möjligt att skapa självsignerande certifikat vilket innebär att användaren manuellt måste godkänna certifikatet. 2.6 Autentisering Autentisering är en verifikation för att användaren är den som den utger sig för att vara. Detta sker vanligtvis genom att initialt ange användarnamn och lösenord och därefter kan en cookie eller token skapas med information som helt eller delvis kan bifogas meddelandena för att autentisera användaren. HTTP stödjer ett antal olika metoder för autentisering och de som undersöktes vidare var basic authentication och digest authentication[8] Basic access authentication Basic authentication baseras på att en klient måste autentisera sig med användarnamn och lösenord för varje anrop till servern och detta anrop kommer att behandlas endast om servern kan validera dessa uppgifter för det specifika anropet. Användaruppgifterna skickas som en base64-kodad sträng med användarnamn och lösenord skilda av ett kolon. Denna sträng föregås av strängen Basic och placeras tillsammans i Authorization headern i HTTP-anropet. Exempel: 5

11 Användarnamn: Lösenord: Sträng: Base64-kodad sträng: Authorization: username password username:password dxnlcm5hbwu6cgfzc3dvcmq= Basic dxnlcm5hbwu6cgfzc3dvcmq= Då användarnamn och lösenord skickas i klartext är basic authentication inte ansett som en säker metod för autentisering Digest access authentication Digest authentication skapades som ett alternativ för att undvika de största säkerhetsriskerna med basic authentication, det genom att lösenordet körs genom en hashfunktion innan det skickas. Inledningsvis när klienten gör ett anrop till en sida som kräver autentisering kommer servern att svara med uppgifter som klienten sedan använder, tillsammans med användarnamn och lösenord, för att skapa en hashsumma. Denna hashsumma skickas sedan för autentisering vilket gör att användarnamn och lösenord inte kommer att exponeras i klartext. 3 Metod I detta avsnitt beskrivs först den utrustning och programvara som använts vid arbetet och en översikt över det existerande systemet CheckUp Life och hur mitt arbete förhåller sig till detta. Sedan följer en beskrivning av hur app och webbtjänst har planerats och utvecklats samt beslut som tagits i samband med detta baserat på informationen i teoriavsnittet. Slutligen behandlas aspekter om säkerhet i kommunikationen mellan app och webbtjänst, hur det implementerats och resonemang kring detta. 3.1 Utrustning och utvecklingsmiljö Jag tilldelades en laptop med Windows 7 installerat som användes genom hela arbetet. För utvecklingen av appen så användes Eclipse med Android Development Tools som plugin för att öka produktiviteten i form av att många av verktygen i Android SDK integreras i Eclipse. För utvecklingen av webbtjänsten så användes Microsoft Visual Studio. Vid testning av webbtjänsten hade jag stor hjälp av programmet Fiddler för att generera och ta emot HTTP-anrop. 3.2 Systemöversikt CheckUp Life bestod, innan mitt arbetes början, av en databas, tjänstefunktioner samt en webbapplikation (Figur 1). Databasen innehåller information om användarna, dels deras mätdata men även användarnamn, lösenord och vilka rättigheter de har i systemet. 6

12 Tjänstefunktionerna används huvudsakligen för att hämta och spara information i databasen samt att verifiera användare vid inloggning. Webbtjänsten kommer att använda sig av funktioner i CheckUp Life Service på ungefär samma sätt som webbapplikationen gör för att mobilanvändare ska kunna använda tjänsten på bästa sätt. Figur 1: Systemöversikt 3.3 Utveckling av app Arbetet påbörjades med att planera appens grafiska vyer, beskrivningen av exjobbet anger att appens utseende ska, om möjligt, efterlikna webbapplikationens utseende för att använd-are ska känna igen sig. Enklare skisser (Figur 2) skapades över vad som vid det tillfället ansågs vara ett bra användargränsnitt och sedan implementerades detta för utvärdering. För att skapa enhetlighet för vyerna så skapades ett gemensamt titelfält med texten Checkup Life och en bakgrund som varje vy använder sig av. Titelfältet ger även möjlighet att ange en titel för den aktuella vyn. 7

13 Figur 2: Skiss för användargränssnitt Inloggning Startvyn (Figur 3) som möter användaren ger möjlighet att ange användarnamn och lösenord och logga in med dessa uppgifter. Om användaren väljer att försöka logga in kommer uppgifter att skickas till servern och vid ett godkännande sparas uppgifterna i minnet och kvarstår där tills appen avslutas. Vid en verifierad inloggning mottagen från servern så byts denna vy ut mot diagramvyn. 8

14 Figur 3: Inloggning Diagram Denna vy ska visa ett diagram (Figur 4) som visualiserar användarens mätdata på ett tydligt sätt. Det diagram som används i webbapplikationen är ett radardiagram men det var inledningsvis oklart ifall ett diagram av den typen skulle rymmas på en smartphone och samtidigt ge en klar och tydlig bild av diagram och tillhörande text. 9

15 Figur 4: Diagram som visar mätdata Efter att ha provat kopiera diagrambilden från webbapplikationen och visa den i en telefon så stod det klart att det skulle gå utmärkt att använda denna diagramtyp. I annat fall kunde ett stapeldiagram varit aktuellt. För att skapa diagrammet så fanns det ett flertal alternativ: Servern kan skapa ett diagram utifrån användarens mätdata och returnera resultat i form av en bild, webbapplikationen använder denna lösning. 10

16 Mätdatat kan skickas till Google via tjänsten Google Charts[10] som i sin tur returnerar en bild på diagrammet. Appen kan skapa diagrammet själv utifrån mätdatat. Första alternativet skulle skapa en onödig arbetsbelastning på servern vid bildskapandet samt att onödiga mängder data skulle skickas vilket jag gärna såg till att undvika då telefonernas hastighet vid dataöverföring kan vara dålig. Alternativ två skulle undvika serverbelastningen men det skulle istället blanda in en tredje part som man skulle behöva förlita sig på vilket kan skapa problem vid uppdateringar från deras sida, nedläggning av tjänsten och annat. Det sista alternativet framstod som det bästa då belastningen läggs på klienten, dataöverföringen blir låg och all information hålls inom server och klient. För att skapa diagrammet sökte jag efter ett diagrambibliotek med stöd för radardiagram som samtidigt skulle ha den typ av licens att appen skulle kunna publiceras utan krav från bibliotekets skapare men det gav ingen framgång. Det enda alternativet var då att själv implementera skapandet av diagrammet, vilket lyckligtvis inte krävde så mycket arbete som befarat och samtidigt gav fullständig kontroll och ett fullständigt dynamiskt diagram baserat på mängden mätdata som kommer in Kalender Kalendern (Figur 5) visar en kalendermånad där man genom att peka på ett datum kommer in i en mer detaljerad vy som kallas träningsdagbok där information om dagens aktiviteter kan föras. Här skiljer sig den slutliga vyn från det som hade planerats i förhand då de två rullistorna med år och månad har ersatts av två kreationer där det endast går att bläddra ett år eller en månad åt gången. Anledningen till detta är att jag anser att rullistor endast har sin plats där det inte är intuitivt vad som kommer före och efter det aktuella valet. Två rullistor gav heller inte, enligt mig, en särskilt estetiskt tilltalande lösning. Vid varje byte av år eller månad anropas servern för att returnera vilka dagar på denna månad som användaren har angivit information för. För att markera dessa i kalendern så syns vita hjärtan angränsande till de aktuella datumen. 11

17 Figur 5: Kalender Träningsdagbok Träningsdagboken (Figur 6) ger en insyn i en specifik dags aktiviteter och initialt hämtas dessa från servern. Vyn ger möjlighet till att lägga till aktiviter av olika slag och också radera befintliga. Denna vy var tvungen att göras scrollbar då det händer att inmatningsfältet och sparaknappen förflyttar sig för långt ner om antalet aktiviter blir för många och därmed upptar för stor plats. 12

18 Figur 6: Träningsdagbok Detaljer Detaljer (Figur 7) visar en lista över de mätmetoder som visades i diagrammet och även det senaste mätvärdet för respektive metod. Genom att peka på en av metoderna så fås ytterligare information om denna. 13

19 Figur 7: Detaljer Metoddetaljer Metoddetaljer (Figur 8) ger en vy av ett diagram och en lista som var för sig visar upp till ett års historik av mätvärden. Linjediagrammet skapades från grunden av samma orsaker som radardigrammet 14

20 3.4 Utveckling av webbtjänst Figur 8: Metoddetaljer Att skapa webbtjänsten blev initialt en betydligt svårare uppgift för mig än skapandet av appen. Jag hade mycket liten erfarenhet av webbtjänster sedan tidigare och hade ingen erfarenhet av C#.NET. Utöver detta så skulle det bli nödvändigt att läsa och förstå den existerande koden i CheckUp Life. Koden grundande sig på WCF och jag utgick från att det även skulle vara fallet för min webbtjänst. 15

21 3.4.1 Kommunikation Vad gäller frågan om SOAP eller REST skulle användas så var jag i kontakt med Elias Nyström[11] på Explizit som året innan hade gjort ett examensarbete där en Android-app kommunicerade mot en webbtjänst med hjälp av SOAP. Hans uppfattning var att stödet för SOAP inte var särskilt bra inom Android och detta hade orsakat honom problem. Jag hade tidigare under året, i kursen D0016E Projekt i datateknik, varit involverad i skapandet av en REST-baserad webbtjänst med tillhörande Android-app och hade bara goda erfarenheter av det. Fördelar med REST ansåg jag vara att det använder sig av HTML-anrop vilket är väldigt enkelt att åstadkomma via Android. Samtidigt är man fri att välja meddelandeformat medan SOAP låser sig till XML samt att data måste skickas i ett SOAP Envelope vilket leder till ökad datamängd. Mina tidigare goda erfarenheter av REST och Elias dåliga erfarenheter av SOAP gjorde att jag valde att gå vidare med REST med JSON som meddelandeformat vilket ger liten overhead för meddelanden WCF För att kunna komma åt alla de resurser som skulle vara nödvändiga definierades följande slutpunkter: Endpoint Metod Beskrivning login GET Verifierar att användarnamn och lösenord är korrekta. chart GET Hämtar uppgifter om användarens mätdata. traininglog GET Hämtar uppgifter om vilka datum som innehåller detaljerade aktiviteter. traininglog/details/{date} GET Hämtar detaljerade uppgifter om aktiviteterna för det specifika datumet. traininglog/details POST Skapar en ny aktivitet. traininglog/details/{id} DELETE Tar bort aktiviteten med det aktuella id:t. 3.5 Säkerhet Konfidentialitet och integritet För att användare ska kunna känna sig trygga när de kommunicerar med webbtjänsten krävs det att det inte finns risk för att deras uppgifter kan läsas av obehöriga eller att den data som skickas och tas emot inte har förändrats av en tredje part mellan klient 16

22 och server. SSL valdes som en lösning på detta då det är ett välanvänt säkerhetsprotokoll som bidrar med konfidentialitet och integritet. Konfidentialiteten genom att kryptera all applikationslagerdata så det blir oläsbart för alla som inte har rätt nycklar för dekryptering. Integritet genom att autentisera varje meddelande så att det inte kan förändras på vägen från sändare till mottagare. Implementationen av SSL var väldigt lättsam då WCF har fullt stöd för detta och det gick att åstadkomma med endast ett fåtal rader i config-filen. För att kunna använda sig av den skyddade tjänsten så var ett certifikat tvunget att skapas. Då ett riktigt certifikat innebär en kostnad till de som utfärdar det så var det bara aktuellt med ett självsignerat certifikat som används så länge som webbtjänsten körs lokalt. Problem uppstod här då klienten inte accepterade självsignerande certifikat utan det skulle vara nödvändigt att göra en lösning så att klienten accepterade samtliga certifikat oavsett härkomst. Då detta inte heller fungerade så testade jag att kommunicera med webbtjänsten via programmet Fiddler som jag generade anrop via och verifierade att webbtjänsten fungerande tillsammans med SSL. Vad som bör tas i beaktande är att om man väljer att klienten ska acceptera samtliga certifikat så försvinner en del av syftet med SSL, nämligen att säkerställa att servern som klienten kommunicerar med är den som den utger sig för att vara. Vid fall av felaktiga, utgångna eller självsignerande certifikat så har användaren, vid användandet av exemplevis webbläsare, möjlighet att manuellt acceptera eller neka certifikatet. Detta är en möjlighet som, mig veterligen, inte finns hos Android-appar och genom att acceptera alla certifikat kommer man vid olyckliga fall att kommunicera med någon annan än den tänkta servern utan vetskap om detta Autentisering Vid autentisering utan någon form av kryptering så framstår digest authentication som överlägsen basic authentication. Detta baserat på att användarnamn och lösenord inte skrivs ut i klartext vilket gör att någon som avlyssnar kommunikationen inte genast kan avläsa vilket användarnamn och lösenord som används. Digest authentication har även möjlighet att använda sig av en aktuell tidsstämpel inbakad i det hashvärde som skickas vilket skapar ett skydd mot återuppspelningsattacker genom att göra att ett svar endast är giltigt under en viss tid. Då jag bestämde mig för att använda SSL så gör detta att de fördelar som digest authentication har går förlorade. Säkerheten hos SSL överstiger vida den som finns hos digest authentication och genom krypteringen så kommer basic authentications användarnamn och lösenord inte längre att vara i klartext. En fördel som fortfarande kvarstår är att då användare i regel väljer betydligt kortare och mindre slumpartade lösenord än ett hashvärde så gör det digest authentication mindre sårbart för brute-force-attacker. Vad gäller många system, bland annat CheckUp Life, så låses en användare efter ett antal misslyckade inloggningar vilket gör att detta inte har någon betydelse. Med tanke på att basic authentication är väldigt enkelt att implementera och att det tillsammans med SSL ger ett, enligt mitt tyckte, fullgott skydd så beslutade jag mig för att välja det. 17

23 4 Resultat I detta examensarbete har en webbtjänst och en Android-app skapats till systemet Check- Up Life. De specifika problemen som formulerades har lösts på följande sätt: Bestämma protokoll/arkitektur för webbtjänsten REST valdes med anledning av att det är en arkitektur som ger stor valfrihet vad gäller sätt att kommunicera. Det lämpar sig bra för Android-appar då HTML-anrop sköts på ett enkelt sätt och meddelanden kan hållas så små som möjliga vilket är positivt då jag anser att mängden data som överförs bör hållas liten på smartphones. Ta fram en metod för autentisering Basic authentication används då det är enkelt att implementera och snabbt för klient och server att hantera. Tillsammans med SSL ger det dessutom ett fullgott skydd. Fastställa hög säkerhet för användarna SSL togs i bruk för att kryptera all den data som överförs till och från databasen. Detta gör att den inte är möjlig att avlyssna. Meddelandena autentiseras så att användarna kan vara säkra på att de inte har manipulerats av tredje part. Dessutom autentiseras klient och server för varandra så det hela tiden är klart att kommunikationen inte sker med någon okänd. Fastställa vad som behövs i webbtjänsten för att hämta och spara information i databasen Endpoints skapades för att ge tillgång till en representation av de resurser i databasen som skulle komma att hämtas och förändras. Funktioner länkades till dessa endpoints som sedan använde funktioner i CheckUp Life Service för att hämta, skapa eller modifiera resurserna i databasen. Verifiera att det givna gränssnittet kan implementeras i appen Samtliga av de funktioner från webbapplikation som skulle stödjas i appen gick att implementera på ett sätt som var närmast identiskt. Det som var tveksamt på förhand var framförallt radardiagrammet men det visade sig gå att implementera på ett dynamiskt sätt som gav en utmärkt visualisering av datat. 4.1 Genomgång av funktionalitet För att beskriva hur appen används följer här ett scenario som går igenom appens alla funktioner och vyer. Daniel tränar på ett gym som använder sig av CheckUp för att mäta de förändringar som sker allt eftersom hans träning fortskrider. Han använder sig av appen för att kunna följa sina, förhoppningsvis förbättrade, värden. Daniel startar appen och anger inledningsvis (Figur 3) sitt användarnamn och lösenord för att sedan trycka Logga in. Väl inloggad så syns ett diagram (Figur 4) som visar all mätdata som tagits. Daniel kan genom att se på de vita punkterna, som representerar mätdatat, märka om något av värdena hamnar 18

24 i den rödaktiga farozonen. Han trycker sedan Detaljer och ser en lista (Figur 7) med samtliga mätmetoder. Då Daniels största mening med träningen är att gå ner i vikt så bläddrar han till raden för vikt och trycker på denna. Ett diagram (Figur 8) över det senaste årets viktmätningar och en tabell över dessa visas och ger en bra överblick över hur Daniel lyckas med sitt mål. Han återgår till vyn med radardiagrammet och trycker denna gång Träningsdagbok. En kalender (Figur 5) med den aktuella månaden uppenbarar sig och hjärtan bredvid dagarna visar om det finns en aktivitet registrerad denna dag. Daniel trycker på en av dagarna och kommer då till ett formulär (Figur 6) för att registrera träningsaktiviteter han utfört. Han väljer Löpning i rullistan och anger sträckan 10 km och tiden 45 minuter, slutligen trycker han på Spara. Daniel är nu klar och stänger ner appen. 5 Diskussion Webbtjänster som använder REST för kommunikation med smartphones har, enligt min uppfattning, nått stor popularitet bland utvecklare jämfört med SOAP. Detta på grund av ett lättviktigt system som ger stor frihet för utvecklaren. Jag känner att det var ett mycket bra beslut att designa webbtjänsten på det sättet då implementation gick lätt och resultatet blev väl fungerande med bra prestanda. Webbtjänsten anser jag dessutom vara mycket lätt att utveckla vidare även för personer som inte har någon större kunskap om ämnet. Tveksamheter som uppstod under arbetet är att gärna hade sett något alternativ till WCF. Jag har inte arbetat med webbtjänster i någon stor utsträckning men beteendekonfigurationen i WCF upplevde jag som väl omfattande för min relativt okomplicerade tjänst. Detta gjorde att vad som var en enkel konfiguration krävde mycket läsande i dokumentation och testning innan det fungerade tillfredsställande. Det har varit intressant att ge sig in på okända områden då WCF samt C#.NET inte var något jag arbetat med tidigare. Detta skapade viss frustration initialt men känns nu som en berikande erfarenhet. Vad gäller Android-appen så var jag bekant med Androidutveckling sedan innan och det underlättade utvecklingen väldigt mycket främst med avseende på tidsaspekten. Användargränssnittet anser jag skulle kunna bli bättre på men min gebit är trots allt främst programmering. Då alla de uppsatta kraven uppfyllts så jag jag avslutningsvis inte vara annat än nöjd med vad som producerats under dessa 10 veckor som examensarbetet bestått av. 5.1 Fortsatt arbete För att arbetet ska uppnå en högre standard så finns det ett antal förbättringar som skulle kunna utföras: Möjlighet att spara användaruppgifter För tillfället så måste en användare ange sina uppgifter varje gång applikationen körs 19

25 utan möjligt att spara dessa för automatisk inloggning. Detta kan uppfattas som onödigt tidskrävande och skulle enkelt kunna ändras genom att spara uppgifterna i appens lagringsutrymme. Säkerheten för dessa uppgifter kan behöva ses över så att inte obehöriga kan komma åt dem. Stöd för olika skärmstorlekar Appen har för närvarande bara testats på en skärm av mediumstorlek och korrigeringar måste med all sannolikhet tas för att det ska se bra ut på smartphones med andra skärmstorlekar. Detta är till största delen en fråga om att ändra storleken på de bilder som används i appen. Snabbare generering av diagrammet Det är något för tidskrävande att hämta mätdatan för diagrammet i dagsläget. Flaskhalsen har identifierats hos webbtjänsten när den hämtar och filtrerar ut alla information från databasen. Detta skulle behöva optimeras så att det programflödet blir något smidigare. Stresstest av webbtjänst Det är ännu oklart hur väl webbtjänsten skulle klara en större mängd användare. Som det är för närvarande har jag enbart testat lokalt på min dator så hur resultatet ser ut i produktionsmiljö är jag ovetandes om. Troligtvis skulle tiden för diagramgenereringen bli ännu värre så det är något som absolut måste korrigeras. 20

26 Referenser [1] Gartner, Gartner Says Worldwide Smartphone Sales Soared in Fourth Quarter of 2011 With 47 Percent Growth, (Hämtad 22 maj 2012). [2] Microsoft, What Is Windows Communication Foundation, microsoft.com/en-us/library/ms aspx, (Hämtad 11 maj 2012). [3] Microsoft, Fundamental Windows Communication Foundation Concepts, msdn.microsoft.com/en-us/library/ms731079, (Hämtad 11 maj 2012). [4] W3C, SOAP Version 1.2 Part 1: Messaging Framework (Second Edition), April 2007 (Hämtad 22 maj 2012). [5] Roy T. Fielding, Architectural Styles and the Design of Network-based Software Architectures, Diss. University of California, Irvine, [6] W3C, Extensible Markup Language (XML) 1.0 (Fifth Edition), TR/REC-xml/, November (Hämtad 17 maj 2012). [7] D. Crockford, The application/json Media Type for JavaScript Object Notation (JSON), IETF RFC 4627, Juli [8] J. Franks et al, HTTP Authentication: Basic and Digest Access Authentication, IETF RFC 2617, Juni [9] A. Freier, P. Karlton, P. Kocher, The Secure Sockets Layer (SSL) Protocol Version 3.0, IETF RFC 6101, augusti [10] Google Charts, (Hämtad 22 maj 2012). [11] E. Nyström, Systemutvecklare, Explizit AB i Skellefteå. 21