TVE 11 007
Examensarbete 15 hp Juni 2011
Applikationsutveckling till
mobiltelefoner med operativsystemet Android
Beräkning av komplexa skuldsituationer Alexander Sjöberg
Emil 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 - Solving complex debt situations
Alexander Sjöberg, Emil Larsson
The goal of the project has been to develop an Android application whose function is to calculate the necessary transactions, minimized in number, to resolve a complex debt situation within a group of individuals. These types of situations frequently occur in everyday life, for example when a group of friends cook dinner together and different people pay for various expenses such as food and beverages. The work resulted in the application SplitIt, a stylish and easy-to-use application that meets the desired specifications. Uncertainties exist however, whether the algorithm that calculates the transactions is optimized regarding the minimum number of
transactions required. Some measures should be taken before the product is launched on the Android Market. The development of icons, for example, has been put to the side with the intention to spend more time on other parts of the user interface and algorithm development. Splitit has been developed by studying similar applications on the Android Market and by carefully considering usability. Before starting the implementation of the application, a user study was conducted in which sketches of the proposed user interface was designed and a test panel had the opportunity to navigate through the application. The study clarified unclear as well as appealing parts of the user interface.
ISSN: 1401-5757, TVE 11 007 Examinator: Urban Lundin Ämnesgranskare: Olle Eriksson Handledare: 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.
