TVE 11 007

Examensarbete 15 hpJuni 2011

Applikationsutveckling till mobiltelefoner med operativsystemet Android Beräkning av komplexa skuldsituationer

Alexander SjöbergEmil Larsson

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 application development for Android - Solvingcomplex debt situations

Alexander Sjöberg, Emil Larsson

The goal of the project has been to develop an Android application whose function isto calculate the necessary transactions, minimized in number, to resolve a complexdebt situation within a group of individuals. These types of situations frequently occurin everyday life, for example when a group of friends cook dinner together anddifferent people pay for various expenses such as food and beverages. The workresulted in the application SplitIt, a stylish and easy-to-use application that meets thedesired specifications. Uncertainties exist however, whether the algorithm thatcalculates the transactions is optimized regarding the minimum number oftransactions required. Some measures should be taken before the product is launchedon the Android Market. The development of icons, for example, has been put to theside with the intention to spend more time on other parts of the user interface andalgorithm development. Splitit has been developed by studying similar applications onthe Android Market and by carefully considering usability. Before starting theimplementation of the application, a user study was conducted in which sketches ofthe proposed user interface was designed and a test panel had the opportunity tonavigate through the application. The study clarified unclear as well as appealing partsof the user interface.

ISSN: 1401-5757, TVE 11 007Examinator: Urban LundinÄmnesgranskare: Olle ErikssonHandledare: Tom Smedsaas

Sammanfattning Arbetet har gått ut på att ta fram en Androidapplikation vars funktion är att beräkna vilka

transaktioner som är nödvändiga, minimerat till antalet, för att reda ut en komplex skuldsituation

inom en grupp individer. Den här typen av situationer uppstår ofta i vardagliga sammanhang,

exempelvis då en grupp vänner lagar middag tillsammans och olika personer lägger ut för olika

kostnader som till exempel mat och dryck. Arbetet resulterade i applikationen SplitIt, en stilren och

lättanvänd applikation som uppfyller uppsatta kravspecifikationer. Osäkerhet råder dock om

algoritmen som räknar ut transaktionerna är optimerad i det avseendet att antalet transaktioner

minimeras. En del åtgärder bör vidtas innan produkten lanseras på Android Market, till exempel har

framtagning av ikoner åsidosatts med avsikten att lägga ned mer tid på övriga delar i

användargränssnitt och algoritmframtagning. SplitIt har vuxit fram genom att liknande applikationer

på Android Market har studerats samt genom att noga beakta användarvänlighet. Innan

implementeringen av applikationen påbörjades, gjordes en studie där skisser på det tänkta

användargränssnittet ritades upp och testpersoner fick möjlighet att navigera sig igenom

applikationen. Studien klargjorde vilka delar i användargränssnittet som uppfattades som otydliga

och vilka som var tilltalande.

Innehållsförteckning

1 Introduktion..................................................................................................................................... 1

1.1 Bakgrund ................................................................................................................................. 1

1.2 Syfte ......................................................................................................................................... 1

2 Teori ................................................................................................................................................. 2

2.1 Android .................................................................................................................................... 2

2.2 Applikationsutveckling för Android ......................................................................................... 3

2.3 Folderstruktur .......................................................................................................................... 6

2.4 Applikationskomponenter ....................................................................................................... 6

2.4.1 Aktivitet ........................................................................................................................... 6

2.4.2 Trådar .............................................................................................................................. 7

2.4.3 Android Manifest File ...................................................................................................... 8

2.5 Databaser ................................................................................................................................ 8

2.5.1 ER-modellen .................................................................................................................... 8

2.5.2 Relationsmodellen och BCNF .......................................................................................... 9

3 Metod ............................................................................................................................................ 10

3.1 Förstudie ................................................................................................................................ 10

3.2 Implementering ..................................................................................................................... 13

3.2.1 Användargränssnitt ....................................................................................................... 13

3.2.2 Databas .......................................................................................................................... 13

3.2.3 Beräkningar ................................................................................................................... 15

4 Resultat .......................................................................................................................................... 15

4.1 Slutproduktens struktur ........................................................................................................ 15

4.2 Databasens tabeller ............................................................................................................... 19

4.3 Beräkningsalgoritm ............................................................................................................... 20

5 Diskussion ...................................................................................................................................... 20

5.1 Diskussion av produkt ........................................................................................................... 21

5.2 Lansering på Android Market ................................................................................................ 22

6 Källförteckning ............................................................................................................................... 24

6.1 Litteratur ................................................................................................................................ 24

6.2 Internet .................................................................................................................................. 24

1

1 Introduktion

1.1 Bakgrund

I juli 2005 gav sig Google in i mobilindustrin genom att köpa det nystartade företaget Android Inc

efter att ha noterat en markant ökning av Internetanvändning i mobiltelefoner. Då Apple år 2007

introducerade iPhone, med revolutionerande idéer som multitouch och öppen applikationsmarknad,

var Android snabba att införliva och vidareutveckla dessa. Samma år grundades Open Handset

Alliance, en sammanslutning av totalt 78 företag, däribland Google, med mål att utveckla

gemensamma standarder för mobila enheter. I samband med bildandet presenterade Open Handset

Alliance sin första produkt, operativsystemet Android.

Under de senaste åren har användandet av så kallade smartphones ökat enormt . Då en smartphone

i många avseenden kan ses som en handdator spelar telefonens operativsystem in minst lika mycket

som själva hårdvaran i konsumenternas val av produkt. De två operativsystem som framför allt har

utmärkt sig på en hårdnande marknad är Apples iOS samt Googles Android OS, där möjligheten för

tredje part att utveckla applikationer är en kraftigt bidragande faktor till deras framgång. Detta

faktum har resulterat i ett enormt utbud av applikationer för vitt skilda syften, vilket ger användaren

möjlighet att helt anpassa sin mobiltelefon utifrån dennes behov och önskemål.1

1.2 Syfte

Syftet med arbetet har varit att utveckla en applikation till mobiltelefoner utrustade med

operativsystemet Android. Applikationen, vars namn valts till SplitIt, har till uppgift att på ett enkelt

och smidigt sätt reda ut komplexa kostnadssituationer inom grupper av individer där utlägg gjorts

och skulder uppkommit. Den här typen av situationer uppstår ofta i vardagliga sammanhang, till

exempel då en grupp vänner lagar middag tillsammans och olika personer lägger ut åt andra för

kostnader som till exempel mat och dryck. Att inse vilka transaktioner som krävs för att på ett så

enkelt och smidigt sätt som möjligt reda ut situationen är en långt ifrån trivial uppgift. Tanken har

därför varit att ta fram ett attraktivt och lättanvänt användargränssnitt i syfte att förenkla detta

vardagliga problem.

1 Steele, To, The Android Developer’s Cookbook, s 17.

2

2 Teori

2.1 Android

Android består av komponenter i flera lager, som kan ses i Figur 2.1.1, där det understa lagret är

grunden i operativsystemet och är baserat på en Linuxkärna. Förutom att utgöra ett

abstraktionslager mellan hårdvaran och resten av mjukvaran, sköter Linuxkärnan bland annat

minneshantering, processhantering och säkerhet. Det andra lagret innehåller en grupp bibliotek

skrivna i C/C++ som används av olika komponenter i Androidsystemet. Detta lager innehåller även

Android Runtime där den virtuella maskinen Dalvik Virtual Machine ingår, som tolkar och utför

kommandon från systemets applikationer. De två översta lagren, som är skrivna i Java, innehåller

färdiga applikationer samt Application Framework som är det ramverk som utvecklare har till sitt

förfogande vid applikationsutveckling. 2

2 What is Android, tillgänglig på http://developer.android.com/guide/basics/what-is-android.html, citerad 16

maj 2011.

Figur 2.1.1 Strukturen hos operativsystemet Android.

3

2.2 Applikationsutveckling för Android

Androidapplikationer skrivs i Java, medan layouten implementeras med hjälp av eXtensible Markup

Languange(XML) som är ett universellt och utbyggbart märkspråk. Vid mjukvaruutveckling för

mobiltelefoner används dock inte hela Javas bibliotek, utan endast en delmängd. Denna delmängd

har fått namnet Dalvik Virtual Machine och skiljer sig från Javas grundbibliotek på så sätt att klasser

som inte passar till mobiltelefoner är exkluderade samt att nya bibliotek har tillkommit.3

Innan man kan börja utveckla applikationer till Android behöver följande program och komponenter

installeras:

Eclipse Java EE IDE

Android Development Tools(ADT)

Android Software Development Kit(SDK)

Eclipse är den integrerade utvecklingsmiljö som är vanligast förekommande vid

applikationsutveckling. Orsaken till detta är att Android har tagit fram Android Development Tool

specifikt för denna miljö. ADT är ett plug-in som är framtaget med syfte att underlätta byggandet av

Androidapplikationer då den bland annat tillhandahåller debuggern Dalvik Debug Monitor

Service(DDMS) speciellt anpassad för applikationsutveckling. DDMS möjliggör att, med hjälp av

funktionen LogCat , se textmeddelanden som användaren själv lägger in i koden. Figur 2.2.1 visar

debuggern inuti utvecklingsmiljön Eclipse.

3 Darcey, Conder, Sams Teach Yourself Android Application Development, s 9f.

4

Figur 2.2.1 Debuggern DDMS i den integrerade utvecklingsmiljön Eclipse.

Android SDK är en uppsättning nödvändiga verktyg utöver de som finns i Java Development Kit. Ett av

verktygen som kommer med paketet är Android Emulator vars funktion är att simulera en

Androidtelefon. Emulatorn, se Figur 2.2.2, är ett bra redskap för att kontrollera att applikationer

fungerar som de ska. Det är bland annat möjligt att inifrån Eclipse simulera ett samtal till emulatorn

för att utvärdera hur koden beter sig i den specifika miljön. Det kommer därmed att framgå om rätt

metoder anropas.

5

Figur 2.2.2 I förgrunden visas simuleringsverktyget Android Emulator. I bakgrunden ses Eclipse.

Ett annat användbart verktyg som SDK tillhandahåller är Graphical Layout, vars syfte är att underlätta

skapandet av applikationers användargränssnitt. Graphical Layout är uppbyggd enligt en så kallad

”drag-and-drop”-metod som går ut på att användaren, med musen som redskap, drar över redan

färdigdefinierade föremål till gränssnitten istället för att definiera dem i ren XML-kod. Figur 2.2.3

visar ett exempel på en layoutfil både i Graphical Layout och i XML.

Figur 2.2.3 Exempel på en layout-fil visandes i Graphical Layout (till vänster) och i XML-kod (till höger).

6

2.3 Folderstruktur

Då ett nytt Androidprojekt skapas i Eclipse genereras ett antal mappar och filer med det huvudsakliga

syftet att strukturera upp projektet redan från start. Några av dem är följande:

/src – Här skrivs och hanteras all källkod i form av klasser skrivna i Java.

/gen – En mapp innehållande javafilen R.java vars funktion är att samla alla projektets

resurser på ett ställe. Filen genereras automatiskt från resurser definierade i XML varje gång

man kompilerar, därav ska denna aldrig editeras manuellt.

/res – I res-mappen förvaras samtliga av projektets resurser, såsom animeringar, bilder,

textsträngar, färger och layoutfiler.

Manifest file – En XML-fil som talar om för systemet vad applikationen innehåller och vilka

funktioner den har tillgång till.

2.4 Applikationskomponenter

2.4.1 Aktivitet

En aktivitet är en applikationskomponent som samverkar med användaren genom att visa ett fönster

föreställande exempelvis ett telefonsamtal eller en karta. Fönstret är skrivet i XML och behöver inte

alltid täcka hela mobiltelefonskärmen, utan kan variera i storlek.

De flesta applikationer består av flera olika aktiviteter som på något sätt är kopplade till varandra

med hjälp av så kallade intent. Man kan betrakta dessa intent som budbärare vars uppgift är att

förmedla meddelanden från en aktivitet till en annan. Innehåller meddelandet mycket information

tar intentet hjälp av klassen Bundle och metoden putExtra.

Vid skapandet av nya aktiviteter ska dessa ärva från superklassen Activity och för att applikationen

ska fungera optimalt bör aktiviteterna innehålla de så kallade ”callback”-metoderna onCreate,

onResume, onPause och onDestroy. Om till exempel mobilenheten tar emot ett samtal ska

aktiviteten som visades ögonblicket innan gå in i metoden onPause, och när samtalet är avslutat

anropas onResume för att återuppta tillståndet som rådde innan samtalet uppkom. Det faktum att

en aktivitet går igenom specifika stadier och antar olika tillstånd har gjort att ”Activity Lifecycle” blivit

ett centralt begrepp inom applikationsutveckling, se Figur 2.4.1. Det första som händer i livscykeln är

att aktiviteten går in i onCreate där det deklareras vilken layoutfil som ska användas och vad som

ska hända om användaren utför någon form av handling på mobilenheten. Därefter antas tillstånden

7

onResume och onPause, beroende på vilka händelser som inträffar. Slutligen, när applikationen

stängs av, anropas metoden onDestroy. 4

Figur 2.4.1 Activity Lifecycle som beskriver de olika stadier en aktivitet kan anta.

2.4.2 Trådar

Trådar gör det möjligt att dela upp exekvering av kod i olika delar som sedan kan köras parallellt i

syfte att effektivisera program. Då en ny applikation startas på en mobilenhet behandlas den första

synliga aktiviteten i den så kallade användargränssnittstråden (UI-tråden). Därefter, när

mobilanvändaren klickar sig vidare till nya aktiviteter, läggs även dessa in i samma tråd. Om

applikationen innehåller tidskrävande beräkningar kan det finnas anledning att flytta ut arbetet till en

annan tråd som körs parallellt med användargränssnittstråden. På så sätt kan användaren navigera

mellan aktiviteter utan att applikationen stannar upp. 5

4 Activities, tillgänglig på http://developer.android.com/guide/topics/fundamentals/activities.html, citerad 15

maj 2011. 5 Processes and Threads, tillgänglig på http://developer.android.com/guide/topics/fundamentals/processes-

and-threads.html, citerad 16 maj 2011.

8

2.4.3 Android Manifest File

Manifestfilen är den fil i ett Androidprojekt som håller reda på vilka aktiviteter, services och content

providers som ingår i applikationen. Services och content providers är två applikationskomponenter

som inte berörs vidare i arbetet. Om nya aktiviteter läggs till måste dessa deklareras i manifestfilen

för att bli en del av applikationen. Likaså om applikationen behöver tillgång till specifika funktioner,

till exempel Internetåtkomst eller åtkomst till telefonens kontakter, ska detta anges i manifestfilen.

Filen tilldelar även applikationens Javapaket ett namn som unikt identifierar denna i såväl Android

System som på Android Market. 6

2.5 Databaser

Databaser är en samling data som hör ihop och beskriver en del av världen, till exempel ett företag

och dess verksamhet. För att hantera databaser använder man sig av så kallade databashanterare

och exempel på sådana är Mimer, Oracle och Microsoft Access. Android använder sig av

databashanteraren SQLite vars biblioteks storlek är väl lämpat för utveckling på mobiltelefoner. För

att utvinna information från databasen används frågespråket SQL som matas in i databashanterarens

användargränssnitt. De flesta databashanterare har tillämpningsprogramsgränssnitt, application

program interface(APK), som gör det möjligt att köra SQL-satser direkt från applikationsprogram

skrivna i exempelvis Java, C, C++ och PHP. Det finns olika metoder att komma fram till en lämplig

databasstruktur och det tillvägagångssätt som har tillämpats i detta arbete är framtagning av ett ER-

diagram som sedan har översatts till tabeller med hjälp av relationsmodellen. 7

2.5.1 ER-modellen

Vid skapande av databaser kan man tro att tabeller är det första som ska tas fram. Det visar sig dock

att tabeller fort blir oöverskådliga och att upprepning av information lätt uppkommer om man inte

har helt klart för sig hur databasen ska struktureras. Ett praktiskt verktyg för att undgå problemet är

att använda sig av ER-modellering.

Tillvägagångssättet för att skapa ett så kallat ER-diagram är att rita upp de komponenter som ska

finnas i databasen. Man skiljer på

saker/entiteter – Till exempel hus, person, djur. Ritas som fyrkantiga lådor.

samband – Till exempel bor i, tillhör, äger. Ritas som diamanter.

6 The AndroidManifest.xml File, tillgänglig på http://developer.android.com/guide/topics/manifest/manifest-

intro.html, citerad 16 maj 2011. 7 Padron-McCarthy, Risch, Databasteknik, s 8.

9

attribut – Egenskaper hos entiteter och samband. Ritas som ringar.

Sambandstyperna ritas mellan entitetstyperna för att beskriva hur saker hänger ihop. Beroende på

hur entitetstyperna är kopplade till varandra används olika samband.

Figur 2.5.1 ER-diagram med två entitetstyper och ett N:M-samband.

Figur 2.5.1 visar ett exempel på ett så kallat N:M-samband, även kallat många-till-många-samband,

vilket innebär att flera personer kan bo i samma hus, samtidigt som en person kan bo i flera hus. De

understrukna attributen personnummer och adress är primärnycklar till entitetstyperna Person

respektive Hus. En primärnyckel är det attribut, eller den uppsättning attribut, som unikt identifierar

en specifik instans ur en entitetstyp. Om ER-diagrammet i Figur 2.5.1 hade varit av typen 1:1 skulle

endast en person kunna bo i ett hus och personen skulle endast kunna bo i detta specifika hus.

Vidare om typen N:1 hade tillämpats skulle flera personer kunna bo i samma hus, men enskilda

personer skulle endast kunna bo i just detta hus. 8

2.5.2 Relationsmodellen och BCNF

Relationsmodellen är en datamodell där man beskriver verkligheten genom att lagra data i tabeller.

Det finns en uppsättning regler för hur ER-modellen med hjälp av relationsmodellen ska översättas

till tabeller. De regler som har tillämpats i detta arbete är följande:

varje entitetstyp blir en tabell

varje N:M-samband blir en tabell

varje sambandstyp med tillhörande attribut blir en tabell

För att implementera en databas på ett så effektivt sätt som möjligt använder man sig av olika typer

av normalformer. Normalformer är villkor som en tabell ska uppfylla och den normalform som har

tillämpats på den databas som detta arbete berör är Boyce-Codds normalform(BCNF). En tabell som

uppfyller BCNF säger två saker:

8 Padron-McCarthy, Risch, a a s 29ff .

10

1. Tabellens attribut innehåller endast atomära värden. Det får alltså högst finnas ett värde i en

tabellruta.

2. Varje determinant ska vara en kandidatnyckel, där en determinant är det eller den

uppsättning attribut som pekar ut värdet av ett eller flera andra attribut. En kandidatnyckel

är samma sak som en primärnyckel, men kandidatnyckel används då det förekommer fler än

en uppsättning primärnycklar.

Med utnyttjande av relationsmodellen samt BCNF översätts diagrammet i Figur 2.5.1 till tabellerna

som presenteras i Figur 2.5.2.

Figur 2.5.2 Med hjälp av relationsmodellen översattes ER-diagrammet i Figur 2.5.1 till dessa tabeller. Varje attribut

resulterar i en ny kolumn i tabellen.

Attributen som pilarna utgår från är determinanter och understrukna attribut är primärnycklar. Som

synes är samtliga tre tabeller i BCNF. Figur 2.5.2 9

3 Metod

3.1 Förstudie

Efter att först ha studerat flertalet befintliga applikationer och på så sätt fått en känsla för hur dessa

var uppbyggda, gjordes ett första utkast över den övergripande strukturen på applikationen. Detta

första utkast, som kan ses i Figur 3.1.1, innehöll en redogörelse för de aktiviteter applikationen skulle

innehålla, hur dessa är relaterade till varandra samt vilken information som skulle presenteras för

användaren.

Grundtanken var att varje kostnadshändelse, till exempelvis en middag, definieras som ett projekt

där användaren har möjlighet att ange de personer som deltagit och de kostnader som uppstått. För

varje kostnad anges förutom summa och beskrivning även vem som betalade och vilka som ska dela

på den. Då samtliga kostnader har angivits beräknar applikationen de transaktioner som är

nödvändiga för att reda ut skuldsituationen och presenterar detta för användaren som därefter har

möjlighet att vidarebefordra informationen till de berörda individerna.

9 Padron-McCarthy, Risch, a a s 85ff.

11

Figur 3.1.1 Ett första utkast över applikationens struktur. Boxarna symboliserar applikationens aktiviteter och pilarna emellan illustrerar hur användaren kan navigera sig mellan aktiviteterna.

PROJECT SCREEN

Visas automatiskt då applikationen startar och låter användaren välja befintligt eller skapa nytt

projekt. Om användaren väljer ett befintligt projekt kommer denne att skickas till fliken PERSON

SCREEN. Väljer användaren istället att skapa ett nytt projekt öppnas PROJECT EDIT SCREEN.

NEW/EDIT PROJECT SCREEN

Denna aktivitet ger användaren möjlighet att skapa, alternativt redigera ett projekt genom att fylla i

dess namn.

TAB SCREEN

Denna aktivitet innehåller förutom tre flikar en action bar med knappar för att navigera till NEW/EDIT

PERSON SCREEN och NEW/EDIT EXPENSE SCREEN för att där kunna lägga till en person respektive

kostnad till projektet.

PERSON SCREEN TAB

Aktiviteten listar de personer som ingår i projektet och användaren har här möjlighet att ta bort eller

redigera personer. Om användaren väljer att redigera en befintlig person öppnas NEW/EDIT PERSON

SCREEN där ny information om personen kan fyllas i.

12

EXPENSE SCREEN TAB

Aktiviteten listar de kostnader som ingår i projektet och användaren har här möjlighet att ta bort

eller redigera kostnader. Om användaren väljer att redigera en befintlig kostnad öppnas EXPENSE

EDIT SCREEN där ny information om kostnaden kan fyllas i.

SUMMARY SCREEN TAB

Aktiviteten presenterar en lista med de transaktioner som krävs för att reda ut kostnadssituationen.

Användaren har här möjlighet att runda av resultatet till lämpligare siffror och därefter informera de

berörda personerna via e-mail eller sms.

Från detta första utkast kan ses att applikationens huvuddel var tänkt att bestå av en meny med

flikar där användaren snabbt skulle kunna växla mellan personer, kostnader och resultat för ett

specifikt projekt. Trots att många förändringar gjorts under utvecklingens gång har denna

huvudmeny i stort behållits intakt med endast små förändringar då den har uppfattats som ett tydligt

och effektivt sätt att växla mellan de olika delarna av applikationen.

Efter att ha fastställt applikationens huvuddelar tillverkades för hand preliminära skisser över

samtliga aktiviteter på vanligt papper. Detta gjordes för att få en konkret bild av

användargränssnittets utformning samt få klarhet i användarens möjlighet att navigera igenom den.

För att därefter få beslutsunderlag för eventuella ändringar hos gränssnittet valdes att göra en tidig

användarstudie där skisserna presenterades för testpersoner som sedan ombads navigera igenom

applikationen och därefter ge synpunkter på förbättringsåtgärder. Denna förstudie var oerhört

givande för det fortsatta utvecklingsarbetet då testpersonerna bidrog med nya idéer och

infallsvinklar som lätt förbises av utvecklare.

Den avslutande delen i förarbetet bestod i att sammanställa samtliga synpunkter från

användarstudien och utifrån dessa revidera den ursprungliga applikationsstrukturen och layouten.

Denna fas innebar dessutom att på ett mer konkret sätt definiera de olika grafiska komponenterna

som behövde implementeras i XML för att erhålla den önskade layouten. För att erhålla en estetiskt

tilltalande applikation som känns enkel och tydlig redan efter kort användning valdes en

minimalistisk och avskalad design, något som starkt uppmuntrades av testpersonerna i förstudien.

13

3.2 Implementering

3.2.1 Användargränssnitt

Applikationen implementerades genom att använda en iterativ utvecklingsmodell som innebär att ett

projekt delas upp i mindre delprojekt som löses separat och därefter sammanfogas. Naturligt var att

börja med startaktiviteten ProjectActivity och därefter successivt utöka applikationen med

ytterligare aktiviteter och funktioner. Detta medförde att körbar kod erhölls efter varje iteration

vilket framför allt förenklade felsökning av koden avsevärt. Allt eftersom användargränssnittet hos de

olika aktiviteterna tog form modifierades och utökades applikationens databasklass

SplitDbAdapter med metoder för att kunna extrahera och lagra information. Denna parallella

utveckling förhindrar att överflödiga metoder skapas i databasklassen och ger möjligheten att enkelt

modifiera de tabeller som databasen innehåller.

För att erbjuda användaren ett tydligt och intuitivt sätt att interagera med applikationen valdes att

genomgående implementera ett användargränssnittsmönster som Android har valt att kalla Action

Bar.10 I applikationens Action Bar, som finns belägen som ett sidhuvud, presenteras information om

var i programmet användaren befinner sig samt knappar för att dels navigera till startaktiviteten

ProjectActivity men också knappar för att lägga till nya projekt, personer eller kostnader.

Mönstret med en Action Bar är något som Google förespråkar och är vanligt förekommande i många

applikationer vilket medför att användaren av Splitit sannolikt redan är van vid detta sätt att

navigera.

För att vidare effektivisera implementeringen skapades en så kallad repository som innebär att

applikationens källkod laddas upp på en server då ändringar gjorts. Detta medförde att projektets

utvecklare gavs möjligheten att samtidigt arbeta på olika delar av koden som därefter laddades upp

och sammanställdes. Källkod som lagras i en repository är dessutom versionssäkrad vilket innebär att

utvecklaren när som helst kan återgå till en gammal version av koden om detta skulle behövas, till

exempel då en ändring har medfört en applikation som inte är körbar.

3.2.2 Databas

SplitIt är utrustad med en klass vid namn SplitDbAdapter, innehållande ett SQLite-

databasobjekt, vars funktion är att i en databas spara ner och hantera information om projekt,

personer och kostnader som mobilanvändaren skapar. Innan databasen implementerades i Java

10

Using the Action Bar, tillgänglig på http://developer.android.com/guide/topics/ui/actionbar.html, citerad 9 maj 2011.

14

gjordes en analys av vilka tabeller med tillhörande attribut som skulle behövas. ER-modellen

tillämpades i enlighet med metoden beskriven i avsnitt 2.5.1 och resulterade i ett ER-diagram som

visas i Figur 3.2.1, där primärnycklarna är understrukna.

Figur 3.2.1 ER-diagram över den databas SplitIt använder sig av.

Som framgår av Figur 3.2.1 resulterade analysen i tre entitetstyper, Project, Person och Expense,

samt fem sambandstyper, consist_of, part_of, paid_by, consume och resolve. Figuren säger att flera

personer kan vara med i flera olika projekt, och i varje projekt kan det förekomma flera olika

kostnader. Vidare kan enskilda kostnader endast läggas ut av en person, medan samma person kan

lägga ut för flera kostnader. Consume-sambandet ger information om att flera personer kan vara

inblandade i en och samma kostnad, samtidigt som en person kan vara inblandad i flera kostnader.

Inblandade, i detta sammanhang, syftar på att berörda personer ska betala lika stor del var av aktuell

kostnad. Resolve-sambandet ger information om att en person är skyldig en annan person en viss

summa. ER-modellen översattes sedan med hjälp av de villkor som beskrivs i avsnitt 2.5.2 och

resulterande tabeller visas i avsnitt 0.

Så som SplitIt är uppbyggd idag går det inte att importera personer från ett projekt till ett annat.

Därav kan det verka överflödigt att ha en N:M-sambandstyp mellan Project och Person, men syftet

var att underlätta implementering av kommande versioner av applikationen då denna funktion kan

tänkas vara önskvärd.

15

De framtagna tabellerna implementerades sedan i en databas i Mimer med avsikt att testa SQL-

kommandon innan de implementeras i SplitDbAdapter för att på så vis undvika fel i syntax samt

underlätta framtagning av önskad information.

För att användargränssnittet och övriga delar av applikationen ska kunna pressentera, ta fram

information från och ändra i databasen är SplitDbAdapter utrustad med en uppsättning

metoder vars funktion är att:

lägga till en ny rad i en tabell

uppdatera en rad eller enstaka attribut i en tabell

hämta rader ur en tabell

ta bort rader från en tabell

Då en ny person läggs till i databasen antar attributet amount värdet noll. Värdet på detta attribut

ändras med hjälp av metoden updateAmount då berörd person blir inblandad i en ny kostnad.

Amount fungerar som ett konto som håller reda på om personen i fråga är skyldig pengar eller har

pengar att inkassera. Om personen i fråga är skyldig pengar visas detta med ett positivt värde hos

amount, och tvärt om ett negativt värde då personen har pengar att inkassera.

3.2.3 Beräkningar

Som bekant har applikationen till uppgift att räkna ut och minimera antalet transaktioner vid

specifika kostnadsförlopp. Undersökningar gjordes med förhoppning att problemet med att

minimera antalet transaktioner kunde generaliseras till en vedertagen algoritm. Dock hittades inga

algoritmer som var direkt tillämpbara för ändamålet och därför togs beslutet att utveckla en egen.

Grundidén med den algoritm som togs fram är att hitta en kombination av skuldsatta personer och

matcha deras värde på amount med personer vars amount har ett positivt värde. Om till exempel en

person har exakt lika stor skuld som en annan person har en tillgång så registreras motsvarande

transaktion i databasen.

4 Resultat

4.1 Slutproduktens struktur

Då applikationen startas öppnas aktiviteten ProjectActivity, som kan ses i Figur 4.1.1, där en

lista över samtliga befintliga projekt presenteras. Användaren har här möjlighet att lägga till ett nytt

16

projekt genom att trycka på knappen i Action Bar, alternativt redigera ett befintligt projekt genom att

hålla fingret nedtryckt på denna rad i listan. Båda dessa handlingar resulterar i att användaren skickas

till ProjectEditActivity, som kan ses i Figur 4.1.1, där projektets namn kan anges eller

redigeras.

Då ett projekt väljs i ProjectActivity eller skapas i ProjectEditActivity skickas

användaren till aktiviteten TabHostActivity som, förutom en Action Bar, består av tre flikar för

personer (People), kostnader (Expenses), och summering (Summary). I Figur 4.1.2 presenteras

aktiviteten TabHostActivity visandes de tre flikarna.

Figur 4.1.1 Aktiviteterna ProjectActivity till vänster och ProjectEditActivity till höger.

17

Under fliken People, som representeras av aktiviteten PeopleActivity, listas samtliga personer

som deltar i det aktuella projektet. Under fliken Expenses, som representeras av aktiviteten

ExpensesActivity, listas de kostnader som projektet innehåller där information om kostnadens

typ, pris, vem som betalade samt vilka som ska dela på kostnaden presenteras. Under fliken

Summary presenteras de transaktioner som krävs för att reda ut den aktuella kostnadssituationen. I

Action Bar presenteras här, i likhet med i ProjectActivity, knappar för att lägga till nya

personer och kostnader. Analogt finns även här möjligheten att hålla fingret nedtryckt på en befintlig

person eller kostnad för att förflyttas till en ny aktivitet där denna kan redigeras. Personer och

kostnader skapas eller redigeras i aktiviteten PersonEditActivity respektive

ExpenseEditActivity som båda kan ses i Figur 4.1.3. Då sannolikheten är stor att en person

som ska läggas till i ett projekt redan existerar i användarens adressbok, ges dessa som förslag då

användaren börjar mata in ett namn. Om person från adressboken väljs och denne har en tillhörande

e-mailadress fylls även den i automatiskt.

Figur 4.1.2 Aktiviteten TabHostActivity med flikarna innehållande PeopleActivity till vänster, ExpensesActivity i mitten och SummaryActivity till höger.

18

Då användaren lägger till eller ändrar befintlig kostnad uppdateras resolve-tabellen i databasen för

att information om nödvändiga transaktioner ska kunna presenteras under fliken Summary. De

beräkningar som krävs för att fastställa de nödvändiga transaktionerna utförs i en separat klass

SplitAsyncTask som i sin tur skapar en ny tråd. Detta görs för att användaren ska ha möjlighet

att kunna fortsätta att navigera genom applikationen medan de nödvändiga beräkningarna utförs.

För att enkelt kunna meddela samtliga personer i ett projekt om vilka transaktioner som krävs har

användaren möjlighet att från Action Bar navigera till telefonens e-mailapplikation. Väl inne i e-

mailapplikationen visas information om projektets summering som kan ses i Figur 4.1.4.

Figur 4.1.3 Aktiviteterna PersonEditActivity till vänster och ExpenseEditActivity till höger.

19

4.2 Databasens tabeller

Som kan utläsas ur Figur 4.2.1 är samtliga tabeller, med undantag för resolve-tabellen, på formen

BCNF. Anledningen till att tabellen resolve är utformat på ett annorlunda sätt än övriga är att detta

underlättar presentationen av nödvändiga transaktioner i SummaryActivity.

Figur 4.2.1 Databasens tabeller. Tabellerna togs fram från Figur 3.2.1 och översattes med hjälp av relationsmodellen.

Figur 4.1.4 E-mailapplikationen visandes transaktionsinformation.

20

4.3 Beräkningsalgoritm

För att avlasta användargränssnittstråden skapas en ny tråd i klassen SplitAsyncTask, där

beräkningarna utförs. Detta får som effekt att när mobilanvändaren trycker på ”Save” i

ExpenseEditActivity kommer den direkt vidare till ExpensesActivity och har därmed

möjlighet att navigera sig vidare i applikationen. Utan SplitAsyncTask skulle användaren vara

tvungen att vänta tills beräkningarna var utförda innan nästa aktivitet presenteras.

Algoritmen som SplitIt använder kan beskrivas på följande sätt:

1. Hämta från databasen de personer som har skulder och spara ner deras id och värde på amount

i arrayerna skuldPerson[] respektive skuldAmount[].

2. Hämta från databasen de personer som har pengar att inkassera och spara ner deras id och

värde på amount i arrayerna tillgångPerson[] respektive tillgångAmount[].

3. Låt i = j = 0 och k = 1.

4. Undersök om skuldAmount[j] + skuldAmount[k] = - tillgångAmount[i].

4.1. Om detta gäller, anropa metoden createResolve i SplitDbAdapter och registrera

att skuldPerson[j] och skuldPerson[k] ska betala skuldAmount[j]

respektive skuldAmount[k] till tillgångPerson[i].

4.2. Uppdatera saldo tillgångAmount[i] = 0 Sätt sedan skuldAmount[j] =

skuldAmount[k] = 0.

5. Låt k = k +1 och gör om steg 4 så länge som k < längden av skuldAmount[].

6. Undersök om skuldAmount[j] <abs(tillgångAmount[i]).

6.1. Om detta gäller, anropa metoden createResolve i SplitDbAdapter och registrera

att skuldPerson[j] ska betala skuldAmount[j] till tillgångPerson[i].

6.2. Uppdatera saldo tillgångAmount[i] = tillgångAmount[i] +

skuldAmount[j]. Sätt sedan skuldAmount[j] = 0.

7. Låt j = j +1 och gör om steg 4 - 6 så länge som j < längden av skuldAmount[].

8. Låt j = 0.

9. Undersök om skuldAmount[j] != 0 och om skuldAmount[j] > -

tillgångAmount[i] och om tillgångAmount[i] != 0.

9.1. Om detta gäller, anropa metoden createResolve i SplitDbAdapter och registrera

att skuldPerson[j] ska betala skuldAmount[j] till tillgångPerson[i].

9.2. Uppdatera saldo skuldAmount[j] = skuldAmount[j] +

tillgångAmount[i]. Sätt sedan tillgångAmount[i] = 0.

10. Låt j = j +1 och gör om steg 9 så länge som j < längden av skuldAmount[].

21

11. Låt i = i + 1 och gör om steg 3 - 10 så länge som i < längden av

tillgångAmount[].

Det bör observeras att amount i tabellen Person aldrig uppdateras i databasen SplitDbAdapter,

utan endast värdena i skuldAmount[] och tillgångAmount[] ändras. Metoden

createResolve lägger in i SplitDbAdapter information om vilka transaktioner som ska

genomföras.

5 Diskussion

5.1 Diskussion av produkt

Under hela utvecklingsarbetet har hänsyn tagits till detaljer hos användargränssnittet, vilket har

resulterat i en stilren och lättanvänd applikation. Det framkommer bland annat genom att textfältet

är markerat och att skrivbordet visas direkt med stor begynnelsebokstav när vissa aktiviteter startas.

Vidare är textfältet Amount i ExpenseEditActivity implementerat så att det visar ett

numeriskt skrivbord med avseende att uppmärksamma användaren på att endast decimaltal kan

matas in. I ett tidigt stadium av utvecklingsarbetet uppmärksammades problem med layouten av

ExpenseEditActivity. Svårigheten var att presentera den väsentliga informationen på ett

överskådligt sätt utan att dela upp processen i för många steg. Problemet behandlades genom att ta

fram olika förslag till denna del av användargränssnittet som sedan presenterades för testpersonerna

i förstudien. I de övriga förslagen som presenterades var momentet uppdelad i två respektive tre

olika aktiviteter, något som testpersonerna upplevde som både oöverskådligt och omständigt då

många kostnader skulle läggas till.

Även om applikationen i stora drag innehåller de funktioner som var tänkt, finns det många tänkbara

utvecklingsmöjligheter. Två möjliga tillägg är att flera personer kan dela på en kostnad samt att

personer kan bära olika stor del av en kostnad. Att ge möjlighet till avrundning, med syfte att minska

antalet transaktioner, är ytterligare ett tillägg som kan utvecklas. Anledningen till att dessa

funktioner inte har implementerats i denna version är den begränsade tiden samt den ökade

komplexiteten hos användargränssnittet som dessa förändringar skulle innebära.

Det kan verka onödigt kostsamt att kasta hela resolve-tabellen varje gång en ny kostnad skapas eller

då en befintlig kostnad redigeras. Så som SplitIt är uppbyggt kommer dock samtliga transaktioner att

22

kunna påverkas av att en kostnad ändras eller läggs till. Det som kan ifrågasättas är dock om

algoritmen i SplitAsyncTask är optimal. Följande brister har uppmärksammats:

Tre eller fler element från skuldAmount[] kan inte tillsammans täcka ett element i

tillgångAmount[].

Det undersöks endast om det j:te elementet går att para ihop med något k:te element från

skuldAmount[] för att tillsammans täcka det i:te elementet i tillgångAmount[]. Om

det inte går hoppar algoritmen till steg 5 i avsnitt 4.3 istället för att undersöka om något

element, vilket som helst, går att para ihop med något k:te element i skuldAmount[] för

att tillsammans täcka det i:te elementet i tillgångAmount[].

Alla element, inklusive sådana med värde noll loopas igenom trots att dessa redan har

behandlats färdigt.

Första och andra punkten kan resultera i att antalet transaktioner blir fler än nödvändigt. Dock har

man resonerat att situationer där summan av en mängd skuldkonton exakt släcker ut ett

tillgångskonto sällan uppstår. Tanken är att hitta en lösning på problemet innan applikationen

lanseras på Android Market. Vad gäller den tredje och sista punkten rör det sig om ett rent

allokeringsproblem. Anledningen till att inga åtgärder har vidtagits är att andra saker har prioriterats.

Då allokering är en viktig aspekt när det kommer till mjukvaruprogrammering till mobiltelefoner

kommer även detta tas om hand innan lansering.

Det har även uppmärksammats att problem uppstår då mobilanvändaren väljer att ta bort befintliga

projekt från listan i ProjectActivity. Problemet avser den tid det tar för applikationen att ta

bort projektet och dess personer samt kostnader ur databasen. Tiden kan upplevas lång vilket kan

resultera i minskat förtroende hos användaren. En lösning till problemet skulle kunna vara att flytta

det arbete som denna förfrågan innebär från UI-tråden till en tråd som körs i bakgrunden och under

tiden i användargränssnittet visa en så kallad progress indicator som gör mobilanvändaren

uppmärksammad på att applikationen utför ett arbete.

5.2 Lansering på Android Market

Målet med arbetet har redan från början varit att lansera applikationen på Android Market, men

innan detta genomförs krävs en rad åtgärder. Bland annat ska ikoner och knappar tas fram, då

nuvarande knappar i Action Bar är missvisande. Standard hos Androidtelefoner är att de är utrustade

med en menyknapp och när den trycks ned förväntas en meny presenteras i applikationens nederdel,

där alternativ för applikationen och den aktuella aktiviteten visas. Eftersom att användaren förväntar

sig kunna utnyttja denna standardiserade form av navigering i applikationer för Androidtelefoner

23

kommer den ännu inte implementerade menyknappen att implementeras. Förutom att innehålla

knappar för aktivitetsspecifika funktioner, som till exempel att lägga till person i

PersonActivity, ska menyn också innehålla en knapp som skickar användaren till en aktivitet

innehållande information om applikationen och hur den är tänkt att användas. Även om en del

ändringar krävs är en lansering inte långt borta.

24

6 Källförteckning

6.1 Litteratur

Steele, James och To, Nelson, The Android Developer’s Cookbook, Pearson Education, Indiana 2010.

Darcey, Lauren och Conder, Shane, Sams Teach Yourself Android Application Development in 24

Hours, Pearson Education, USA 2010.

Risch, Tore och Padron-McCarthy, Thomas, Databasteknik, Studentlitteratur AB, Lund 2005.

6.2 Internet

Activities, tillgänglig på http://developer.android.com/guide/topics/fundamentals/activities.html,

citerad 15 maj 2011.

Processes and Threads, tillgänglig på

http://developer.android.com/guide/topics/fundamentals/processes-and-threads.html, citerad 16

maj 2011.

The AndroidManifest.xml File, tillgänglig på

http://developer.android.com/guide/topics/manifest/manifest-intro.html, citerad 16 maj 2011.

Using the Action Bar, tillgänglig på http://developer.android.com/guide/topics/ui/actionbar.html,

citerad 9 maj 2011.

What is Android, tillgänglig på http://developer.android.com/guide/basics/what-is-android.html,

citerad 16 maj 2011.