Sportfiskeapplikation till Android
Android sportfishing application
Joakim Wahman & Erik Larsson
Fakulteten för hälsa, natur- och teknikvetenskap Datavetenskap
C-uppsats 15 hp
Denna uppsats är skriven som en del av det arbete som krävs för att erhålla en kandidatexamen i datavetenskap. Allt material i denna rapport, vilket inte är mitt eget, har blivit tydligt iden-tifierat och inget material är inkluderat som tidigare använts för erhållande av annan examen.
Joakim Wahman
Erik Larsson
Godkänd, 2014-06-02
Handledare: Kerstin Andersson
Sportfiskeapplikation till Android
Android sportfishing application
Innehåll
Figurer xiii 1 Introduktion 1 2 Bakgrund 3 2.1 Analys . . . 3 2.2 Tillvägagångssätt . . . 5 2.3 Existerande system . . . 6 2.4 Prototyp . . . 7 2.4.1 Användargränssnitt . . . 7 2.4.2 Databas . . . 9 2.5 Säkerhet . . . 12 2.6 Summering . . . 13x INNEHÅLL 3.2.5 Rapportering av fångst . . . 19 3.2.6 Val av zon . . . 20 3.2.7 Information . . . 21 3.2.8 Statistik . . . 21 3.3 Implementationsdetaljer . . . 22
3.3.1 Introduktion till implementationen . . . 22
3.3.2 Fragment . . . 24 3.3.3 Drawer Menu . . . 29 3.3.4 Lokal databas . . . 31 3.3.5 Val av zon . . . 32 3.3.6 Spara användare . . . 34 3.3.7 Droidnetworking . . . 36
3.4 Application Programming Interface . . . 42
3.5 Avgränsningar . . . 44
3.6 Summering . . . 46
4 Resultat och utvärdering 49 4.1 Introduktion . . . 49
4.2 Visuella ändringar . . . 50
4.2.1 Rapportera fångst . . . 50
4.2.2 Mina fångster . . . 52
4.2.3 Loginvy inklusive registrering . . . 53
INNEHÅLL xi
5 Framtida funktionalitet 61
5.1 Introduktion . . . 61
5.2 Intresse . . . 62
5.2.1 Lägga till alla Sveriges sjöar . . . 62
Figurer
2.1 Överblick över de olika vyerna i applikationen. . . 8
2.2 Överblick över sambandet mellan de olika delarna av projektet. . . 9
2.3 Överblick över databasen. . . 10
3.1 Vy för inloggning, registrering av konto samt glömt lösenord. . . 17
3.2 Mina fångster . . . 18
3.3 Menyvy . . . 19
3.4 Vy för rapportering av fångst, val av zon samt information i rapporteringen. 21 3.5 Vy för information samt statistikvyn . . . 22
3.6 Livscykler för aktiviteter . . . 23
3.7 Livscykler för fragment . . . 25
3.8 Menyvy . . . 29
3.9 De två kartorna som används . . . 33
3.10 Vägen datan tar från databas till Androidapplikation. . . 37
3.11 Översikt över flödet som skapas när data från API:et hämtas för user. . . . 42
3.12 Överblick över tjänsterna som API:et erbjuder. . . 44
4.1 Planerat utseende för rapportering av fångst . . . 51
4.2 Slutgiltiga utseendet för rapportering av fångst . . . 51
4.3 Vår skiss på hur vi tänkt att ”Mina fångster” skulle se ut . . . 52
xiv FIGURER
4.5 Planerat utseende för ”Login”, ”Registrering” samt för ”Glömt lösenord”. . . 54
4.6 Slutgiltiga utseendet för ”Login” och ”Registrering” . . . 54
4.7 Den planerade menyn. . . 55
4.8 Den slutgiltiga menyn. . . 56
4.9 Den planerade vyn för ”Information”. . . 57
4.10 Den slutgiltiga vyn för ”Information”. . . 57
Kapitel 1
Introduktion
Det finns sedan tidigare en hemsida där rapportering av fångst är möjlig, denna heter Fångstdatabanken och finns på Fiskekort.se. Denna sida är Sportfiskarna dock inte helt nöjda med och den har inte gett särskilt många rapporteringar. Därför har vi skapat en helt ny fångstdatabank åt dem i Androidform. Android valdes som plattform för applikationen då det är det mest använda operativsystemet för handhållna enheter[4] men senare kommer troligtvis även en version att skapas till iOS som är Apples motsvarighet.
Då applikationens målgrupp har spridd teknisk kunskap har vi haft hög fokus på använ-darvänlighet. Vi valde därför att arbeta mycket med att designa och planera utseende och funktionalitet genom en process med regelbundna möten med kunden. Dessa möten bestod av uppvisningar av hur långt vi kommit med produkten samt planering inför kommande sprints[15], som vi valde att dela upp arbetet i.
Till applikationen har vi valt att göra en databas som vi skapat i Microsofts moln-tjänst Azure[7], där vi också skapat ett API[11] för att länka samman applikationen med databasen på ett enkelt och säkert sätt som även ger stöd för påbyggnad.
Vår rapport består av 6 kapitel inklusive detta introduktionskapitel. Nästa kapitel he-ter Bakgrund och beskriver bakomliggande orsaker till varför problemet som skall lösas uppstod. Detta kapitel innehåller planeringsfasen av projektet med lösningsförslag samt jämförelser av tidigare produkter. Det tredje kapitlet, som heter Prototypdesign och im-plementation, innehåller en fördjupande beskrivning av olika delar av produkten. Här finns exempelkod från olika delar och även planerade bilder för gränssnittet. Detta gör att den-na del innehåller mycket material. Det fjärde kapitlet innehåller resultatet av vår produkt. Här jämförs bilder från planeringsfasen med färdig produkt med motiveringar till olika förändringar.
Vi valde att i det femte kapitlet skriva om framtida funktionalitet av vår produkt. Detta då det är ett stort och aktuellt ämne. Här skrivs om Fångstdatabankens framtid. Det sista kapitlet innehåller en sammanfattning av hela arbetet.
Kapitel 2
Bakgrund
I detta kapitel beskriver vi bakomliggande orsaker till varför problemet som skall lösas uppstod. Vi går även igenom delar av vårt lösningsförslag som ger en liten bild av hur vår slutprodukt skall se ut.
2.1
Analys
Fiskekort.se är en av Sveriges största hemsidor för sportfiskare. Hemsidan fungerar som en portal för sportfiskarna där de kan hitta information om fiskeområden, köpa fiskekort för valt område eller så kan användaren rapportera sin fångst till fångstdatabanken.
hitta till formuläret på hemsidan så få fiskare tog sig tiden att gå in och rapportera sina fångster. Den andra orsaken var att de som hade hand om webbhotellet med databasen inte har samarbetat alls, så den enda data Fiskekort.se har kommit åt är de rapporter som användarna valt att göra publika, det vill säga den data som visades upp för alla användare på fångstdatabanken.
Om Sportfiskarna inte får in fler fångstrapporter så kan de som forskar med detta inte upptäcka några mönster. Detta leder till att det blir mycket svårare att ta hand om Sveriges fisk. Lösningen måste därför bli mer mobil samt att ha en databas som lätt ger dem tillgång till all data de vill åt.
Sportfiskarna har gjort en undersökning hos sina medlemmar för att se hur många av fiskarna som faktiskt vill rapportera sina fångster. Hela 90 procent var för att rapportera all fångst. Dock var det endast 1 av 8 personer som faktiskt gjorde detta i praktiken. Detta visar tydligt hur viktigt det är att få till en rapportering som går snabbt, enkelt och är mobil.
Förutom den tidigare webbtjänsten så har fiskare kunnat fylla i formulär utskrivna på papper. Trots det utdaterade sättet att rapportera fångster på så togs det ändå in en del sådana rapporter, vilket visar på att intresset finns för att rapportera sin fångst.
Sportfiskarna har nu vänt sig till Sogeti, som i sin tur tar hjälp av oss. De vill ha en lösning på problemet med för få rapporter på fångster i Vänern. Lösningen som ska tas fram skall vara en Androidapplikation där användaren enkelt kan rapportera fångster i Vänern. Vi ska nu arbeta via Sogeti och komma in i deras arbetssätt och lära oss att själva ta hand om alla kundmöten med kunden och tillsammans få fram ett lösningsförslag. Sogeti arbetar med lösningar inom IT och många på företaget arbetar med Androida applikationer.
2.2
Tillvägagångssätt
För att lösa problemet så har vi tillsammans med kunden (Sportfiskarna) kommit fram till att vi ska bygga en Androidapplikation samt en helt ny databas som denna ska vara kopplad mot. Att vi valde att göra just en Androidapplikation var ett gemensamt beslut vi tog med kund då Android har mest användare för tillfället. Applikationen ska vara enkel att använda och rapporteringssteget ska få med all den data som tidigare fanns vid rapporteringen i webbapplikationen. Den ska även ha stöd för offline-läge då det ofta kan vara dålig täckning ute på sjön vilket skulle leda till att användaren inte kan ladda upp sina fångster mot nätet direkt.
Vårt mål är att endast täcka Vänern. Detta beror dels på att det är Sveriges största insjö där flest fiskare håller till, men även för att det är den sjö som kräver mest rapporter av alla just nu. Rapporterna behövs för att få ut mönster så att bättre vård av Sveriges sjöar blir möjlig. Då endast våra rapporter för tillfället kommer att ske från Vänern så kommer detta att skickas med som ett dolt värde varje gång, men då applikationen kommer att byggas på i framtiden så ska vi förbereda databasen genom att bygga en tabell med Sveriges sjöar. Alla rapporter som gjorts kommer att lagras i en lista som är kopplad till användaren. På detta sätt blir rapporterna som en fiskedagbok och lockar förhoppningsvis då fler att använda applikationen.
Vi kommer inte att spara användarna från den förra databasen. Vi fokuserar endast på att bygga en helt ny från början.
2.3
Existerande system
Den mest liknande produkten i nuläget är webbsidan Fiskekort.se som är webbsidan som vår kund har sedan tidigare och är i princip samma sak som vi ska skapa i mobilappli-kationsform. Fiskekort.se har nu en portal för rapportering av fångade fiskar, som heter FångstDataBanken. Systemet fungerar dock inte som kunden vill utan har brister som att databasen inte rapporterar fisketurer korrekt samt att det inte visar mycket relevant information utan ger ointressant data till användaren och ägaren. Det är dock tänkt att rapporterade fisketurer som hamnar i FångstDataBankens databas sedan förs vidare till forskninginstitut i landet för att skapa statistik över fisketurer för att kunna jämföra fångs-ter. Deras system sträcker sig över flertalet sjöar samt Sveriges kuster, medan vår produkt endast ska behandla Vänern. Systemet för rapportering av fångst på denna sida är relativt enkelt och kräver endast en enkel engångsregistrering. Detta medlemsregister är likt det register vi kommer att använda oss av. Processen för rapportering har en mängd olika fält för användaren att fylla i, däribland vilken fiskart som fiskats upp och i denna flik finns i nuläget alla Sveriges fiskar. De egenskaper som Fiskekort.se har i sin nuvarande produkt är: längd, vikt, fiskart, om fisken är fenklippt, antal fiskar, antal fiskade timmar, datum, fiskemetod samt vilken del av Vänern som fisketuren ägt rum i. Webbtjänstens framtid är dock oviss, detta gör vår applikation mer behövlig.
Det finns flertalet fiskeapplikationer till både iOS- och Androidenheter, där användaren kan rapportera sina fångster och gå in i en gemenskap där för att jämföra fångster, men de är i nuläget utan anknytning till forskning och har inte samma intresse av vad som är viktigt i en fångstrapport som Sportfiskarna. De fokuserar istället mer på att ge kunden en chans att skryta om sin fångst. Av dessa är nog FishBrain-applikationen den största konkurrenten, som finns till både Android och iOS. Den är välutvecklad och innehåller ett världsomfattande positionssystem (Global Position System (GPS)) [14], med viktig information kring fisket på platserna där användare rapporterat fångst. FishBrain inriktar sig på sportfiskare som vill jämföra fångst och har även information om vilket bete som
fungerar bäst på olika platser samt olika fiskarters spridning runt i världen. All information är hämtad från användare som använt applikationen och skickat in data.
iFiske är en liknande tjänst som säljer fiskekort i olika zoner, men saknar rapportering av fiskfångster, som är fokus i vår produkt.
Förutom den tjänst som Fiskekort.se erbjuder finns det fångststatiskt från andra håll, Däribland Havs- och Vattenmyndighetens hemsida. Där finns det data över yrkesfiske i Sverige, men den har ingen information om sportfiske.
2.4
Prototyp
Här går vi igenom två delar, användargränssnittet och databasen. Båda delar täcks endast grundligt men ger oss en överblick om hur upplägget ser ut.
2.4.1
Användargränssnitt
Vi valde att efter möte med vår kund skapa ett lösningsförslag och med hjälp av bilder och text förklara våra tankar kring projektet och sedan skicka detta till dem. Detta för att ge kunden en klar bild av vad vi tänkt oss och samtidigt få viktig feedback tillbaka. Detta gav oss bra kommunikation, då båda parter kunde diskutera kring ett dokument.
För att skapa bilderna till lösningsförslaget använde vi oss av WireFrameSketcher Stu-dio [17], där vi enkelt kunde skapa bilder som även är tydliga och lätt visar våra tankar. Vi gjorde om användargränssnittet flera gånger då vi fick feedback av kunden från våra lösningsförslag och även av medarbetare på kontoret, som arbetat mer med användargrän-snittsdesign.
vyer. Den finns inte i inloggningsvyn och vyer som är länkade därifrån, såsom vyer för att registrera konto eller om användaren sitt glömt lösenord. Detta för att inte ta fokus från att användaren behöver vara inloggad för att utföra applikationens funktioner. Menyn saknas även i vyn för att välja zon i Vänern, även detta för att inte ta fokus från faktumet att användarinput krävs för att komma vidare.
Funktionerna som applikationen ska kunna utföra är rapportering av fångst, överblick över användarens rapporterade fångster, viktig information samt en statistikdel. När man startar applikationen hamnar man på loginvyn om man inte är inloggad sedan tidigare och efter att man loggat in hamnar man i vyn ”Mina fångster”, där man sedan kan navigera vidare med hjälp av huvudmenyn som de fyra funktionerna i applikationen kretsar kring.
Relationerna mellan vyerna är skapade med fokus kring menyn och med få val och kan ses i figur 2.1.
Figur 2.1: Överblick över de olika vyerna i applikationen.
2.4.2
Databas
Vi valde att strukturera vår produkt i tre delar: Androidapplikation, databas samt API (Application Programming Interface). Ett API är mellanlagret som skickar och tar emot data från databasen, detta är smidigt och säkert, då man med ett bra och säkert API bara behöver anropa detta och inte vara orolig för att av misstag skapa säkerhetsluckor till databasen. I back-end-delen[13] finns de delar av produkten som inte syns utåt, alltså databasen och API:et. Dessa arbetar mot front-endens Androidapplikation och framtida webbapplikation som innehåller alla vyer samt all kod för de grafiska delarna. Sambandet mellan de olika lagren visas i figur 2.2.
Figur 2.2: Överblick över sambandet mellan de olika delarna av projektet.
Vi valde att använda oss av Microsofts molntjänst Azure[7] för skapandet av databas samt API. Detta verktyg är lätthanterligt och framför allt billigt för kunden då de måste betala för en databastjänst.
API:et används för kommunikation mellan databasen och Androidapplikationen. I Azu-re använder vi MySQL[8] för SQL-anrop samt node.js[9] som skriptspråk i själva API:et.
Figur 2.3: Överblick över databasen. Users
Denna tabell håller all data om användarna. Det är här användaren kopplas vid registre-ring/inloggning av konto. Fälten innehåller all information som vår kund vill ha ut från användarna samt ett unikt ID som kopplar ihop användaren med dess fångstrapporter i
databasen.
Fishing_method
Denna tabell kommer att fungera som en lista med alla möjliga fiskemetoder. Vi kommer att hämta all information från denna tabell vid rapportering av en fångst när vi ska lista upp vilken typ av fiskemetod användaren använt sig av.
Fish
Denna tabell innehåller all information om fiskearterna, namn på arten, en bild för att visa hur den kan se ut, information om den och även ett sant/falskt-värde för att se om en art blir fenklippt eller inte. När användaren valt en fisk i rapporteringen så ska checkboxen för att rapportera om fisken var fenklippt eller inte försvinna om arten inte ska kunna vara fenklippt.
Fish_areas
Information om fiskeområden. Förutom namn id så håller även tabellen kolumnerna ”Nmr_of_zones” och ”Have_Zones” som visar antalet zoner i området, skulle ”Nmr_of_zones vara tom så kommer kolumnen ”Have_Zones” att visa ”false”.
Commune
En enkel tabell som ger varje kommun ett unikt ID.
Fishing_area_commune
Fishing_occasion
Denna tabell håller relevant information gällande fisketillfället så som datum, zon, an-vändarID, fiskemetod och även ID:t för fiskeområdet. Många av de viktigaste delarna i rapporten kommer härifrån.
Fishing_occasion_extra
En tabell som ger extravärden till fisketillfälle. Med denna kan senare projekt lägga till kommentarer och bilder på hela fisketuren men inte på en enskild fångst. Detta kan dock läggas till enkelt i ”Catch”-tabellen nedan.
Catch
Huvudtabellen när det gäller rapportering av en fångst. Denna tabell är kopplad mot många utav de andra tabellerna och sammanställer all data som är nödvändig vid en rapportering. Tabellen håller de kolumner som användaren fyller i vid rapportering. Den innehåller även ett ID så att fångsten kan kopplas samman med användaren som rapporterat.
2.5
Säkerhet
Ur säkerhetssynpunkt kommer vår applikation att uppfylla de säkerhetskrav som var nöd-vändiga för applikationen. Detta då databasen endast kan nås via det API vi ska bygga upp samt att Androidapplikationen i sig får hög säkerhet. Eftersom viss data inte är offentlig kommer vi att lagra denna data dold i databasen, och den ska endast vara nåbar av ett adminkonto som vi skapar åt kunden med hjälp av vårat API och Microsofts tjänst Azure. I databasen kommer även lösenord som lagras att vara hashade med salt [14]. Detta gör att även om någon skulle nå databasen så skulle de inte få ut lösenordsinformation. API:et har många kontroller för att bara skicka och lagra data som den ska och då detta utför all kommunikation mellan databasen och applikationen skapar det säkerhet.
2.6
Summering
Det vårt projekt går ut på är att ge användarna en mobil applikation så att vår kund får in mer rapporter om fångster i Vänern. I dagsläget så är sättet att rapportera fångster på opraktiskt och tappar därmed många användares rapporter. Vår lösning är att bygga både en ny Androidapplikation samt en helt ny databas (den nuvarande har krånglat mycket och Sportfiskarna kan inte nå all data som lagts in). Genom att göra detta så blir det mindre påfrestande för användarna att göra en rapportering samt att vår kund kan hämta ut all data som sparas i databasen. (Förut så kunde de endast nå datan som var publik, det vill säga den som visades upp för alla på hemsidan.) För att locka fler användare att använda sig av applikationen så ska vi visa upp alla tidigare fångster så att det blir som en dagbok med alla fångster som rapporterats.
Om vår applikation får många användare så kommer detta ge ett bättre statistiid om-händertagandet av Vänerns fisk.
Kapitel 3
Prototypdesign och implementation
I detta kapitel går vi in mer fördjupande på delar av koden. Även exempelkod från viktiga delar av applikationen och arbetsmetoder kommer att diskuteras.
3.1
Projektstyrning
Under projektet så har vi arbetat enligt Scrum-metodiken. I Scrum delar vi upp projektet i ett flertal stafettliknande processer, eller sprintar som vi kallar dem. I en sprint så sätter man upp tydliga mål av vad som ska göras under endast denna sprinten, man kollar alltså inte på vad som ska göras under hela projektets period utan fokuserar endast på denna periodens mål. När en sprint är klar så har man ett möte med gruppen för att klarställa vilka punkter som är avklarade och sätter nya mål till nästa sprint.
Vårt projekt har delats upp i 5 sprintar. generellt sett då delades de upp på följande sätt:
Sprint 1: Denna sprinten såg vi som en planeringssprint. Här målade vi upp skisser på hur vi hade tänkt att applikationen skulle se ut och kom överens med kunden om vilka mål som skulle sättas.
börja arbeta i.
Sprint 2-4: Utvecklingssprintarna. Alla dessa sprintar sågs som utvecklingssprintar där vi byggde upp applikationen och fyllde den med funktionerna som krävdes för att nå vårt resultat. Målen för alla sprinter var olika, men alla omfattade utveckling så vi ser dessa som en gemensam grupp.
Sprint 5: Under den sista sprinten så hade vi en fullt fungerande applikation som täckte alla kraven som vi hade satt. Under denna sprinten så lades det fokus kring designen då detta inte varit prioriterat innan.
3.2
Användargränssnitt
Vår applikation har 10 olika vyer, vars samband även visas upp i figur 2.1. Dessa är skapade för att vara så enkla som möjligt att navigera mellan och att på så sätt bredda målgrup-pen av användare. Alla vyer är designade i programmet WireframeSketcher av oss efter önskemål från kunden.
3.2.1
Inloggning
När användaren startar applikationen utan att vara inloggad kommer vyn till vänster i figur 3.1 att visas upp. Det enda den gör är att be användaren om inloggningsuppgifter och den innehåller även två ytterligare knappar för registrering av användarkonto samt en funktion för att återfå ett förlorat lösenord.
Registrering av användarkonto Denna vy nås endast från inloggningsvyn och innehåller ett enkelt formulär för registrering av ett nytt användarkonto. Denna vy kan ses i mitten av figur 3.1.
3.2.2
Glömt lösenord
Denna vy liksom vyn för registrering av användarkonto nås bara från inloggningsvyn och innehåller bara en textruta för e-postadressen som användaren vill få sitt nya lösenord skickat till. Denna vy kan ses till höger i figur 3.1.
Figur 3.1: Vy för inloggning, registrering av konto samt glömt lösenord.
3.2.3
Mina fångster
Figur 3.2: Mina fångster
3.2.4
Meny
Vi har valt att vyerna ska kretsa kring en ”Drawer menu” som gör det lätt och snabbt att navigera runt bland vyerna i applikationen. Klickar användaren på ett föremål, exempelvis ”Mina fångster”, i menyn så öppnas den valda vyn direkt. Denna vy kan ses i figur 3.3.
Figur 3.3: Menyvy
3.2.5
Rapportering av fångst
För rapportering av fångst skapar vi en vy i formulärform, där användaren matar in data som sedan lagras i databasen och även kan publiceras på användarens facebook-konto. Se den vänstra vyn i figur 3.4. Grundtanken med denna är att användaren så lätt som möjligt ska kunna rapportera fångster. Då detta är huvudsyftet med applikationen är det viktigt att ingen användare blir förvirrad.
valde att placera bredvid kartikonen visar användarens val och ska även fungera som en rullgardinsmeny för användare som redan vet vilken zon de befinner sig i och tycker att denna metod är enklare.
Vyn ska även justeras beroende på vilken fiskart användaren väljer, genom att visa eller dölja alternativet för att markera en fångst som fenklippt.
Ordningen på de olika fälten är baserad på kundens önskemål, med de viktigaste fälten överst och med ett icke-obligatoriskt fält för fångstens vikt.
”Rapportera direkt” lägger till fångstdatan direkt i databasen medan ”Spara rapport” mellanlagrar den för att sedan skickas till vyn ”Mina fångster” där den sedan kan skickas vidare till databasen, detta ger ett offline-stöd.
3.2.6
Val av zon
Denna vy nås endast från vyn för rapportering av fångst och innehåller endast en karta över Vänern, indelad i 10 olika zoner. På denna karta kommer en zon alltid att lysas upp svagt. Detta är den zon som användaren befinner sig närmast geografiskt. Tanken är då den att tydligt visa upp i vilken zon användaren befinner sig i, men fortfarande ge fritt val av zon. Detta då användaren ska kunna rapportera in sin fångst i efterhand och kan då ha förflyttat sig från fångststället.
Här ska det även finnas en likadan informationsikon som finns i ”Rapportering av fångst”, denna ger användaren samma informationsruta som där. Vyn kan ses i mitten av figur 3.4.
Figur 3.4: Vy för rapportering av fångst, val av zon samt information i rapporteringen.
3.2.7
Information
Informationsvyn nås från menyvyn och innehåller länkar till olika hemsidor och bilder. Den har 4 olika ikoner att trycka på och kan enkelt byggas ut med mer. Det vi har i nuläget är fiskeregler, fiskar i Vänern, karta över Vänern samt väderinformation. Denna vy kan ses till vänster i figur 3.5.
3.2.8
Statistik
Figur 3.5: Vy för information samt statistikvyn
3.3
Implementationsdetaljer
Här går vi igenom viktiga lösningar som använts i applikationen. En lösning ses som en samling metoder som tillsammans löst en eller flera uppgifter.
3.3.1
Introduktion till implementationen
En Androidapplikation består alltid av en aktivitet[2] som ligger som en process när ap-plikationen är igång. Skulle inte någon aktivitet vara igång så kommer apap-plikationen att stängas av. Vår huvudaktivitet är menyn som ligger aktiv i de flesta vyer. De vyer där menyn inte syns är i de vyer som håller en egen aktivitet (t. ex. inloggningsvyerna). Det kan endast vara en aktivitet igång åt gången. Användaren kan däremot ”pausa” en aktivitet och hoppa till en annan aktivitet vid vissa vyändringar. När den nya aktiviteten körts klart
så kan användaren hoppa tillbaka till den pausade aktiviteten som behållit sitt tillstånd. I figur 3.6 så ser vi en aktivitets livscykel. Det första steget av aktiviteten är onCreate(). Det är här vi börjar med att deklarera allt som ska vara med, som till exempel vilken layout som ska användas. När allt är klart i detta steget så stegar vi igenom onStart() och onResume(). onStart() används egentligen bara om aktiviteten på något sätt skulle ha startats om och allt är deklarerat sen innan. onResume() är metoden som anropas om aktiviteten blivit pausad och om den startas igen. Efter dessa tre så ligger aktiviteten i ”Aktivitet körs” där den ligger och väntar på att den antingen ska pausas, stoppas eller att den blir dödad (processen stängs ner). Grafen i figuren visar till vilket steg som processen återvänder till beroende på vilket steg den har gått ifrån (hur aktiviteten har stoppats).
Förutom aktiviteter så består applikationen av en hel del andra lösningar. Dessa ska vi gå igenom i nästa subsektion.
3.3.2
Fragment
Nästan alla våra klasser är byggda kring fragment[10]. Ett fragment är en klass som är direkt kopplad till en egen layout. Det har ett eget uppförande och en egen livscykel. Alla fragment kan ses som en subaktivitet. De uppför sig som en vanlig aktivitet men ligger alltid under en huvudaktivitet som inte behöver ändras bara för att fragmentet gör det. Detta hjälper oss att navigera runt kring vyerna utan att behöva störa den vitala aktiviteten, det vill säga den aktivitet som är i drift. För att göra detta kallar vi endast på fragmentet som i sin tur hämtar vyer och äger alla metoder kopplade till den. I figur 3.7 så ser vi livscykeln för ett fragment. Det är likt livscykeln hos en aktivitet som vi såg i figur 3.6. Skillnaden mellan dessa cykler är att fragmentet har fler steg. I fragmentet så går vi först till onAttach() innan vi går in i onCreate(). Stegen med samma namn fungerar på samma sätt, så onCreate() används på samma sätt för fragment som för i aktiviteter. De uttonade pilarna i figuren 3.7 visar på att stegen de hoppar över inte behöver användas. Som figur 3.7 visar så hoppar den första pilen över onCreate() där vi sätter vyns layout och deklarerar de föremål som ska vara med. Men då onCreateView() kallas på direkt efter och är näst intill identisk med onCreate() så kan samma operationer som i onCreateView() utföras utan problem.
Figur 3.7: Livscykler för fragment
Fragmenten kan enkelt skicka med data till andra klasser med hjälp av Intent[5]. Intent är en intention till att göra en handling, det vill säga ett meddelande om att något har hänt eller att något ska hända. Ett vanligt användningsområde för detta är när vi vill byta aktivitet. Då skickar vi ett meddelande om att en annan aktivitet ska ta över. Denna aktivitet reagerar på meddelandet och följer instruktionerna. Intent kan lagra ett värde från ett fragment och skicka med detta meddelande till nästa fragment genom enkla metoder. Kodexemplet nedan kommer från ”Rapportera fångst”-vyn, där vi går till kartvyn, väljer en zon och skickar sedan med detta värde till föregående vy igen (”Rapportera fångst”).
Steg 1: När kart-knappen blir klickad så kallar vi på ImageAreasActivity-klasssen med hjälp av Intent. Vi skickar även med getActivity() som en parameter för att visa vilket fragment applikationen ska hoppa till när resultatet har nåtts.
Steg 2: När användaren klickat på en zon så sätts ett värde till variabeln intent och vi säger också att vi ska gå tillbaks till den bestämda vyn med finish();
Intent intent = new Intent(); intent.putExtra("4", "4"); setResult(RESULT_OK, intent); finish();
Steg 3: Metoden OnActivityResults kallas direkt när aktiviteten skickat med ett resul-tat, med super.onActivityResult(requestCode, resultCode, data); hämtar vi ut datan som skickats med, och identifierar den med data.getExtras().containsKey (sökt värde som satts i förra koden, i vårt fall 4).
public void onActivityResult(int requestCode, int resultCode, Intent data) { //Declaring our spinner
Spinner zone = (Spinner) getActivity().findViewById(R.id.spinner1);
super.onActivityResult(requestCode, resultCode, data);
if(data.getExtras().containsKey("4")) {
//Setting the spinner to position 4 zone.setSelection(3);
}
Värdet i variabeln intent sätter vi olika beroende på vilket case vi hamnar i metoden innan, i detta exemplet så valde vi zon 4 på kartan, därför satte vi meddelandet i putExtra till 4.
När vi hoppar från ett fragment till ett annat så använder vi oss av metoden replace(). Metoden replace() beskrivs mer detaljerat nedan i denna sektion. Det den gör är att sätta vilket fragment som skall bli aktivt och för att göra det så skickar vi med klassen som håller fragmentet. Klassen i sin tur håller på allt för vyn och fragmentet byggs då upp efter
detta.
Varje fragment börjar med detta steget:
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
View rootView = inflater.inflate(R.layout.ExempelLayout, container, false); }
När fragmentet skapats och vyn ska väljas så kallas metoden onCreateView där vilken vy som ska visas deklareras. Detta är också första metoden som vi kör i våra fragment så den ses som en Main-metod i våra klasser.
När vi ska byta fragment så får vi först deklarera vilket fragment som ska ta över. Här sätter vi nästa fragment till klassen MinLista:
fragment = new MinLista();
Efter det får vi kalla på replace() som byter ut fragmenten.
if (fragment != null) {
FragmentManager fragmentManager = getSupportFragmentManager();
FragmentTransaction transaction = fragmentManager.beginTransaction() .replace(R.id.frame_container, fragment); if(addToBackStack) { transaction.addToBackStack(null); transaction.commit(); } }
gör att vi håller koll på vilket som var det förra fragmentet som användes.
3.3.3
Drawer Menu
Drawer menu[3] är vår meny som ligger runt alla vyer för att användaren lätt ska kunna navigera sig runt i applikationen. Menyn är en aktivitet som är aktiv hela tiden. Fragmenten läggs in som subaktiviteter till menyn. Det fragment som är aktivt visas med en röd bakgrund inne i menyn. Denna meny kan ses i figur 3.8.
Figur 3.8: Menyvy
ska kallas på. Värdet läggs i en variabel som sedan skickas till replace() som vi gick igenom i fragmentdelen.
private void displayView(int position, boolean addToBackStack) { // update the main content by replacing fragments
Fragment fragment = null;
switch (position) {
case 0:
fragment = new MinLista();
break;
case 1:
fragment = new Report();
break;
case 2:
fragment = new Information();
break;
case 3:
fragment = new Statistik();
break;
case 4:
fragment = new Login();
break; default: break; } replace(); }
”int position” som skickas med som inparameter till switchen är ett heltalsvärde från 0 till 4. Talet som skickas in representerar vilken position i listan föremålet har. Första
föemålet i listan har position 0. Detta leder till att när heltalet skickas in så går switchen till case 0 och sätter fragmentet till MinLista().
3.3.4
Lokal databas
Den lokala databasen är byggd så att den ska matcha den externa databasen. Detta för att underlätta överföringen från den lokala till den externa senare, samt för att få bra struktur på all data. Den lokala databasen lagras direkt i Androidenheten så värdena som sparas i denna försvinner inte när användaren inte har åtkomst till nätverk eller när användaren stänger av Androidenheten. Databasen består av 6 metoder.
Källkoden till den lokala databasen ligger i appendix, bilaga Lokal databas(kod) på sidan 71.
1. onCreate(SQLiteDatabase db)
Denna metod körs direkt då alla lokala databasanrop körs. Finns det ingen databas uppe så bygger den upp den med valda tabeller, skulle databasen redan finnas så gör metoden ingenting.
2. addCatch(catches catches)
Denna metod tar in ett object, i detta fall catches, och hämtar ut den data som söks och lägger in den i fälten på databasen. Ett id för fångstrapporten skapas direkt i metoden.
3. getCatch(int id)
4. getAllCatches()
Denna metod hämtar alla fångster som registrerats i databasen och returnerar dem i en arraylista med Catches-objekt. Inga parametrar tas in.
5. updateCatch(catches catches)
Denna metod skickar in ett objekt som har samma ID som ett i databasen men med nya värden. Metoden läser av objektets ID, hämtar det gamla objektet och sparar undan det med de nya värdena. Objektets ID ändras inte efter att det uppdaterats utan håller samma värde som innan.
6. deleteCatch(catches catches)
Här tas det in valt objekt, Idt tas ut ur objektet och söks upp i databasen där det matchande objektet sedan raderas.
3.3.5
Val av zon
För att välja zon vid rapporteringen så kan användaren antingen välja zon i en enkel lista, eller klicka på en ikon med en karta på alla zoner i Vänern.
När användaren klickat på denna ikon så kallas det på en Intent som skickar en vidare till en ny klass. Det förra fragmentet ligger kvar och väntar på resultat från klassen som användaren kallat på.
Den nya klassen är en aktivitet men en vy som innehåller två bilder som kan ses i figur 3.9, dock är det endast en som är synlig för användaren, och det är standardbilden med text över zonerna. Båda bilderna är en karta över zonerna i Vänern, men områdena i den ”osynliga” bilden är ifyllda med en bestämd färg.
Den ”osynliga” bilden har en lyssnare kopplad till sig, så när användaren klickar någon-stans på bilden så kallas en metod som läser av var vilken zon som blev klickad på kartan.
Figur 3.9: De två kartorna som används
Orsaken till att vi vill veta var användaren har klickat på kartan är för att vi i metoden ska läsa av vilken färg området hör till. Om användaren trycker vid område 6 på kartan, så skickar vi med position från tryckningen, metoden skannar då av den positionen och ser att färgen på den ”osynliga bilden” där är röd. Då kommer vi till nästa steg i metoden. Me-toden innehåller 10 stycken if-satser som har olika händelser beroende på vilken färg som valts. Om vi forstätter på spåret att vi klickat på området med röd bakgrund så hoppar vi in i följande if-sats:
else if (ct.closeMatch (Color.rgb(255, 0, 0), touchColor, tolerance)) {
Intent intent = new Intent(); intent.putExtra("6", "6"); setResult(RESULT_OK, intent); finish();
}
toleransnivå som till exempel tolkar färgen som röd även om någon av färgerna vi klickar på inte matchar med siffrorna exakt. Denna toleransnivå är för tillfället satt till 20, det vill säga att om en if-sats skulle kolla på färgen rgb(50, 50, 50), så skulle följande värden på färgen gå igenom: rgb(30-70, 30-70, 30-70). Skulle toleransvärdet sättas till ett för högt värde så hade färgen på den position man klickat på registrerats som den färgen som den första if-satsen står för.
Intenten avslutar sedan aktiviteten och hoppar tillbaka till det förra fragmentet med resultatet. Resultaten hämtas i metoden onActivityResult(int requestCode, int resultCode, Intent data) som alltid kallas när det skickas ett resultat till fragmentet.
I onActivityResult jämför vi värdet som skickas tillbaka och agerar efter det.
if(data.getExtras().containsKey("6")) {
zone.setSelection(5); }
I detta fall sätter vi värdet på spinnern som visar vald zon till plats 5, vilket motsvarar område 6.
Skulle användaren klicka utanför områdena på kartan (det vill säga på den vita färgen) så visas det endast ett meddelande som säger ”Klicka på en av zonerna”
3.3.6
Spara användare
När användaren startar applikationen för första gången så ska inloggningsvyn visas, häri-från kan användaren antingen logga in direkt med ett konto eller skapa ett nytt konto. När användaren loggat in så sparar applikationen dennes ID med hjälp av SharedPreferences. SharedPreferences är ett interface som ger oss möjligheten att spara undan värden till en XML-fil som inte försvinner när applikationen stängs av. Vi kollar detta genom att kalla på metoden check_if_logged() när applikationen startas. Denna metod kollar om något
värde är sparat i XML-filen:
private void check\_if\_logged() {
SharedPreferences preferences = PreferenceManager .getDefaultSharedPreferences(getBaseContext()); String id = preferences.getString("userid",null);
if (id == null) // If ID==Null, no user has logged in {
Intent i = new Intent(this, Login.class); //The user will be sent to the login-class
startActivity(i); }
}
När vi är i inloggningsklassen och har lyckats logga in så sparar vi även undan värden samtidigt som vi byter klass:
SharedPreferences prefs =
PreferenceManager.getDefaultSharedPreferences(getBaseContext()); SharedPreferences.Editor editor = prefs.edit();
editor.putString("userid", Data.getInstance().getID()); //saving ID for the user that logged in
editor.commit();
Intent i = new Intent(this , MainActivity.class);// Changing class startActivity(i);
När användaren loggar ut så töms värdena som sparats undan i SharedPreferences och skickas åter till inloggningsvyn:
SharedPreferences prefs =
PreferenceManager.getDefaultSharedPreferences(getBaseContext()); SharedPreferences.Editor editor = prefs.edit();
editor.putString("userid", null); editor.commit();
Intent myintent = new Intent(this, MainActivity.class);
startActivity(myintent); //Since the column userid is empty, the method in MainActivity will redirect the user to the login-class again.
3.3.7
Droidnetworking
För att göra API-anrop via internet i vår applikation har vi använt oss av en nätverkstjänst som en Sogetianställd utvecklat som kallas Droidnetworking. Denna består av olika metoder som i slutändan möjliggör internettillgång. Målet med denna del av koden är att få fram data ur API:et, som figur 3.10. visar.
Denna process har sex steg från databasen till att lagras lokalt och kunna nås av metoder. Sammanfattningsvis så ber användaren ifrån Androidapplikationen API:et att utföra en tjänst mot databasen. För att datan som hämtats via Droidnetworking från API:et ska vara användbart så krävs att det får datan som rätt sorts objekt. Från API:et kommer datan som ett JSONObjekt. Denna omvandlas sedan till ett objekt av valfri form och till detta används hjälpmetoder. När väl objektet har den form som valts, så lagras det lämpligast lokalt för att senare kunna användas.
Figur 3.10: Vägen datan tar från databas till Androidapplikation.
private void getUser(String username, String password) {
new LoginOperation(username , password).logIn(new
LoginOperationListener() {
@Override
public void onLogInFinished(User user) { name = Data.getInstance().getName(); if (name != null){ SuccessLogin(); } } @Override
public void onLogInFailed(String error) {
FailedLogin(error); }
}); }
När LoginOperation är klar kommer denna sedan att skicka vidare ett User-objekt till on-LogInFinished eller ett felmeddelande till onLogInFailed. SuccessLogin() och FailedLogin() är de metoder som körs när allt är klart och där den hämtade datan används. Den första raden i getUser() anropar LoginOperation och skapar först själva anropet som ska göras till API:et.
public LoginOperation(String username, String password) {
super(API_USER + paramString(username, password), null, HttpMethod.GET); }
Ovanför sätts API_USER på detta sätt:
private static final String API_USER = Services.API_URL + "/user";
API_URL defineras i klassen Services, och är bara API:ets url, detta är Services enda roll. Denna går sedan in i paramString som anropas ovan.
private static String paramString(String username, String password) {
return "?username=" + username + "&password=" + password; }
Dessa två funktioner resulterar i en färdig API-url som kan se ut på liknande sätt:
”https://våratapinamn.azure-mobile.net/api/user?username=”namn”&password=”lösenord” ” och känt är även att vi vill använda metoden GET.
Nu till den andra delen av det första anropet, logIn(), som anropar Droidnetworking med hjälp av raden:
NetworkEngine.getInstance().enqueueOperation(this);
Denna metod innehåller även den en lyssnare, som anropas av själva droidnetworking när datan hämtats klart från API:et.
public void logIn(final LoginOperationListener listener) {
setListener(new OperationListener() {
@Override
{
try {
JSONObject responseAsJson = new
JSONObject(operation.getResponseString()); JSONObject userAsjson =
responseAsJson.getJSONObject("account"); User user = new User();
user.deserializeJSON(userAsjson); Data.getInstance().setUser(user); listener.onLogInFinished(user); } catch (JSONException e) { listener.onLogInFailed("JSONException"); e.printStackTrace(); } catch (Exception e) { listener.onLogInFailed("Exception"); e.printStackTrace(); } } @Override
public void onError(NetworkOperation operation) {
Denna funktion kommer att fortsätta köras tills enqueueOperation i Droidnetworking är klar, då den går in i onCompletetion och börjar med att lagra användaren som ett User-objekt med hjälp av Json. Json-delen av koden tar helt enkelt in datan som fås som ett Json-objekt och använder sig av metoder i User för att lägga in datan i User-objektet. Detta objekt är enkelt definerat för User, då vi bara vill kunna komma åt id och namn.
I User-klassen lagras då dessa två parametrar och kan nås med hjälp av getmetoder i Data-klassen, där man sedan kan anropa till exempel ”Data.getInstance().getName()” som hämtar namnet för användaren.
I detta skede är det många steg som metoderna behöver gå för att bli klara. Därför måste vi använda oss av lyssnare och på så vis vänta in olika steg i koden. Om vi inte gör detta kommer olika delar av tråden att gå vidare parallellt utan att vänta in datan i andra trådar. I detta fall blir det enQueue som inte väntas in.
Detta gör att vi utan lyssnare skulle hamna i ett stadium där vi nu har onComplete där vi försöker lägga data till JSON som vi inte ännu fått.
Figur 3.11: Översikt över flödet som skapas när data från API:et hämtas för user. Principen för samtliga API-anrop är densamma, förutom att vi för fångst valde att skapa en hjälpklass i onComplete då det blev mycket kod för att lägga in fångster i en arraylista av fångstobjekt istället för att bara ha det i ett enda objekt som för User.
3.4
Application Programming Interface
Vår applikation använder sig mycket av data från både lokal och extern databas och detta skapar ett behov av en bra kommunikation till dessa. Till den externa databasen har vi skapat ett Application Programming Interface, även kallat API, i Microsofts molntjänst Azure. Ett API kan då anropas direkt från vår Androidapplikation med hjälp av en Sogetibyggd nätverkstjänst som heter Droid-Networking, som vi fått använda under pro-jektet. API:et har två olika delar, som vi valt att kalla ”user” och ”fangst” för anropen. Vanligast delas API-anrop upp i olika delar, detta gör även vi. De enda vi kommer att
använda oss av är GET, POST, DELETE och PUT. Dessa funktioner är ganska självför-klarande, då deras funktioner är att hämta, skicka, ta bort respektive byta ut data från databasen. Dock har user endast GET och POST. Detta är till för att det ska vara tydligt vid anrop till dessa. User är det skript som tar hand om alla användare. Genom att anro-pa user med en GET-metod nås informationen kring om en användare har skrivit in rätt användarnamn och lösenord. Den tar då in användarnamn och lösenord som inparametrar och om användaren finns i databasen returneras användarens uppgifter till Androidappli-kationen med hjälp av JSON-objekt[6]. Ett JSON-objekt är ett textobjekt i kompakt form som används vid utbyte av data och ur detta är det lätt att få ut olika delar av datan ur. Denna GET-metod gör att vi enkelt och säkert kan kontrollera användares behörighet, istället för att skriva någon av denna kod i själva Androidapplikationen.
User har även en POST-metod, som används vid registreringen av nya användare. Denna tar in samtlig användardata och lagrar den i databasen. Vi har använt oss av hashade lösenord, vilket innebär att de är krypterade och inte kan nås även om någon skulle få tillgång till databasen.
Den andra delen av API:et är fangst och denna är till för att lagra, hämta och editera fångstdata ur databasen. POSTs uppgift här är att vid en fångst lagra och koppla ihop en fångst med ett fångsttillfälle och sedan koppla ihop denna med användarens ID. GET har som uppgift att hämta data från användarens tidigare fångster. DELETE och PUT används i vyn för editering av fångst.
Figur 3.12: Överblick över tjänsterna som API:et erbjuder.
3.5
Avgränsningar
Under projektets gång har många beslut tagits om hur applikationen ska fungera och se ut. Här nämner vi de viktigaste besluten, vilka alternativ som fanns och vad de resulterade i.
Applikationen ska endast täcka Vänern.
Vänern är Sveriges största insjö och även den mest populära sjön för fiske i Sverige. Detta leder till att det blir ännu viktigare att ta hand om sjön. För att ta hand om sjön så måste forskarna ha tillräckligt med data för att få ut mönster så att de vet exakt hur de ska sköta sjön. Att vi endast valde Vänern beror på att det ligger så mycket tyngd på att man får in data här och kunden ville att vi endast fokuserar på Vänern med extrafunktioner som statistik över användarens fiskfångster och information om sjön. Dessa är dock lågt prioriterade då tyngden ligger på rapportering av fångster.
Sätta ”Mina fångster” till startsida
Den första vyn användaren kommer till är inloggningsvyn. Är användaren inloggad så öpp-nas alltid vyn ”Mina fångster” när applikationen startas. Detta beslut togs för att det är den vy vi förmodar är den användaren oftast vill åt. Till en början hade vi tänkt att ha en meny-vy där användaren fick välja en ikon som motsvarade den vyn som ville nås, men vi ersatte denna med en ”Drawer menu”. Med denna meny så kan man nå alla vyer vart användaren än befinner sig i applikationen. Detta gör att användaren lätt kommer åt rap-porteringen och gör det enkelt för användaren att rapportera sin fångst.
Helt ny databas
Lokal och extern databas
Den externa databasen är ett måste för att kunna rapportera fångsterna, men den lokala databasen var ett beslut som gjordes för att stötta offline-rapportering. Den lokala da-tabasen sparar datan på samma sätt som den externa men behöver inget nät då datan sparas direkt i Androidenheten. Alla fält som lagras i den externa databasen täcks även i den lokala, så när användaren har tillgång till nät så är det bara att ladda upp de lokala rapporterna direkt till den externa databasen.
3.6
Summering
Applikationen består av 5 huvudavdelningar. Den första som användaren kommer till är inloggningsavdelningen. Här kan man välja mellan att logga in, att skapa ett nytt konto eller att få ett nytt lösenord skickat till din mail. denna avdelning når man endast om man inte är inloggad på Androidenheten. Det vill säga om man inte tidigare har loggat in eller om man väljer att logga ut.
Efter inloggningen så kommer användaren till ”Mina fångster”. Här visas det två listor, en som innehåller de fångster som man inte registrerat och en annan lista som visar upp alla fångster som man registrerat i databasen. Klickar användaren på en registrering i listan så kommer visas en sida med detaljerad information om fångsten. Här kan användaren även välja att registrera fångsten eller att ta bort den. ”Mina fångster” har även en knapp där användaren laddar upp alla fångster från den oregistrerade listan till den registrerade listan.
De andra avdelningarna får användaren navigera sig till via vår meny. Dessa 3 är ”Re-gistrera fångst”, ”Statistik” och ”Information”.
”Registrera fångst” håller på alla fält som användaren fyller i för att spara en fångst. Efter att fälten fyllts i, så sparas fångsten och den läggs i ”Oregistrerade fångster”-listan i ”Mina fångster”.
”Statistik”-avdelningen visar upp enkel statistik för fångsterna i den registrerade listan. Denna avdelning är planerad till att byggas ut med grafer i framtiden.
”Information” innehåller information om fiskar, regler och karta över zoner. Det finns även en förklarande text om vad applikationens syfte är.
Kapitel 4
Resultat och utvärdering
4.1
Introduktion
Det här kapitlet presenterar resultatet från vår del av detta projekt. Alla funktioner som vi satte i funktionskraven i början av projektet är täckta, men ett flertal extrafunktioner har diskuterats under projektets gång. Vi kommer i de följande sektionerna att stega igenom hur stor skillnad det är på det visuella samt det funktionella på applikationen jämfört med våra mockups som vi redovisade i början av uppsatsen.
I första sektionen så jämför vi de visuella skillnaderna. Här kommer tydligt bilder på hur applikationen ser ut nu jämfört med bilderna som vi målade upp som skissar att visas. Vi kommer även att förklara orsakerna/tankarna bakom varje ändring.
Den andra sektionen är snarlik den första sektionen. Skillnaden är att vi går från de vi-suella till de funktionella förändringarna. Vi kommer också att diskutera hur applikationen påverkats vid ändringarna.
4.2
Visuella ändringar
Under projektets gång har det blivit en del ändringar i utseendet av applikationen. Änd-ringarna har gjorts för att vi, tillsammans med vår kund, kommit överens om att det blir snyggare och/eller lättare för användarna. Enda undantaget är för Statistik-avsnittet, där vi helt enkelt inte har haft tid att göra klart enligt planen, men detta var från början redan planerat att göras i mån om tid.
4.2.1
Rapportera fångst
Resultatet av rapportera fångst är likt vår planering för vyn. En av de saker som tagits bort är informationsknapparna som skulle vara till för att förklara hur användaren skulle bära sig åt vid de olika delarna av rapporteringen. Dessa valde vi att ta bort då de tog onödig plats och då de inte riktigt gjorde någon nytta då upplägget redan var enkelt nog att förstå vid dessa delar.
Fältet med ”Antal timmar idag” har också tagits bort, då detta inte var något som vår kund ville ha med i rapporten.
Vi valde även att endast ha en rapportera fångst-knapp. Användaren kan alltså inte skicka fångsten till den externa databasen direkt. Utan den sparas först i den lokala listan. Det har även lagts till två fält för om fisken är bukfenklippt eller fettefeneklippt, dessa två dyker endast upp när de fiskar som kan fenklippas är valda i art-listan. Innan så fanns det endast bara ett alternativ, ”Fenklippt”, för alla fiskar. På detta sättet kunde användaren inte specificera just hur den var klippt på något sätt.
I ”Välj zon”-delen av rapporteringen har vi valt att ta bort GPS-spårning då det var en onödigt krånglig funktionalitet att implementera.
Vi tog även bort stöd för facebook som var en av de saker som vi satte som något vi kunde lägga till i mån av tid.
Förutom dessa ändringar så har uppläget i vyn ändrats en hel del.
Figur 4.1: Planerat utseende för rapportering av fångst
Figur 4.2: Slutgiltiga utseendet för rapportering av fångst
4.2.2
Mina fångster
I den första vyn i ”Mina fångster” så är den enda ändringen att värdena som visas upp på föremålen i listan har ändrats. Förut så visades datum, zon, art, vikt och längd. Vi valde att istället endast visa art, längd och datum. Resten av värdena får användaren istället fram genom att gå in klicka på fångsten.
Figur 4.3: Vår skiss på hur vi tänkt att ”Mina fångster” skulle se ut
I figur 4.3 ser vi även hur vi hade tänkt att informationen på fångsten skulle visas upp. Det finns även ett område där bilden på fångsten skulle visas upp. Bilden har vi tagit bort helt så det området är borta. Den information som visas på den slutgiltiga produkten är lite snyggare upplagd, men annars lik den första skissen. Vi har lagt till en del fält förutom de som visas i figur 4.3. Vi har även lagt ”Redigera fångst”-knappen längst ner i vyn och lagt ”Ta bort fångst”-knappen uppe till höger i vyn istället för att lägga den uppe
på aktivitets-fältet.
Figur 4.4 visar hur applikationen ser ut i dagsläget.
Figur 4.4: Hur ”Mina fångster” ser ut i dagsläget
4.2.3
Loginvy inklusive registrering
sitt lösenord så att det inte blir fel. Vi valde även här att på kundens begäran lägga till en informationstext. Registreringsvyn blev längre än planerad, därför fick vi bygga in en scroll-funktion, som i den tredje bilden i figur 4.6. Alla skillnader mellan planerad och slutgiltig loginvy kan ses i figur 4.5, samt 4.6.
Figur 4.5: Planerat utseende för ”Login”, ”Registrering” samt för ”Glömt lösenord”.
Figur 4.6: Slutgiltiga utseendet för ”Login” och ”Registrering”
4.2.4
Meny
I menyvyn är den största skillnaden på den planerade och den slutgiltiga produkten att vi valt att ändra ordning på ”Mina fångster” och ”Rapportera fångst”, då vi vill att applika-tionens startsida ska vara fångstlistan och därför känns det naturligt att ha denna överst. Menyn har även alltid titeln ”Fångstdatabanken” oberoende på var i applikationen man befann dig innan. Menyn fick en snygg layout i vår slutgiltiga produkt, som kan ses i figur 4.8 och kan jämföras med den planerade menyn i 4.7.
Figur 4.8: Den slutgiltiga menyn.
4.2.5
Information
Själva grundvyn för information är lik vår plan, vi har dock valt att där den gamla ikonen hette ”Fiskar i Vänern” ändra till ”Lax och öring” och bara behandla dessa två arter då de är de fiskar som kräver mest infromation då de båda arterna är vanliga i Vänern och är lika varandra till utséendet. Vi hänvisar istället till Sportfiskarnas tidigare applikation ”Fisknyckeln”, där information om alla fiskar finns. Vi ändrade även ifrån ”Väderinforma-tion” till ”Om Fångstdatabanken”, då denna information var mycket viktigare samt att väderinformation skulle ta allt för lång tid att implementera. Ikonen för fiskeregler tar oss direkt till ”svenskafiskeregler.se”. Förutom detta så valde vi att lägga kartan på den sista platsen då denna är minst viktig. De ovan nämnda skillnaderna kan ses i figur 4.9 och figur 4.10.
Figur 4.9: Den planerade vyn för ”Information”.
Figur 4.10: Den slutgiltiga vyn för ”Information”.
4.2.6
Statistik
fiskart som användaren kan välja i en lista. Här finns den valda fångsten representerad i ett stapeldiagram med lämpliga intervall. Ovanför stapeldiagrammet så visas även antal sapporteringar av denna art, meddellängden av dessa samt den längsta av de rapporterade hos just den arten.
Figur 4.11: Den slutgiltiga vyn för statistik.
4.3
Problem
Vi har under projektets gång stött på en mängd mindre problem och ett fåtal något större. Större delen av problemen har blivit lösta snabbt och enkelt med hjälp av internet eller med hjälp av Sogetianställda.
Ett av de stora problemen vi hade var kopplingen mellan API:et och Androidapplika-tionen, där vi inte visste hur vi skulle gå tillväga innan vi fick Droidnetworking förklarat för oss. Denna del har tagit lång tid då vi varit tvungna att använda oss av mycket lyssnare och stega igenom koden, då funktionerna sker i fel ordning annars. Detta var svårt för oss att förstå i början, då vi inte hade någon erfarenhet av detta sedan tidigare.
Vi skapade kopplingen mot API:et för User-objekt först, för att kontrollera om en inloggning var giltig. Därför skapade vi allt kring ett objekt och inte en arraylista av objekt som behövdes för att visa upp fångsterna som också behövdes senare. Denna ändring för fångsterna tog lång tid och här uppstod mycket problem som vi till sist lyckades lösa. Vi hade även problem med att få listan över fångst att uppdateras regelbundet och inte bara när användaren klickade på knappen för att gå in till vyn. Detta löste vi till sist med lyssnare som också kontrollerar ifall användaren tryckt på knappen flera gånger snabbt, som till en början skapade flera rapporteringar. Det sista problemet vi hade var att ibland, till synes slumpmässigt så uppdaterade inte listan det sista objektet efter en rapportering med flera fångster. Detta även fast vår kod skulle vänta på rapporteringen innan listan skulle visas med de nya fångsterna med hjälp av lyssnare. Detta löste vi med hjälp av att få applikationen att vänta ytterligare.
Förutom dessa problem har arbetet gått bra och vi har aldrig suttit fast en längre tid.
4.4
Utvärdering
Under projektets gång har vi skapat en fungerande applikation som täcker de funktionskrav som vi satte från början. Vi har alltså lyckats med våra mål och även lyckats få med en statistikvy vilket inte var en obligatorisk uppgift.
i Androidprogrammering så fastnade vi i problem som vi idag hade löst mycket lättare. Applikationen hade dock inte byggts på något annat sätt bara för att vi varit mer erfarna, utan de komponenter vi använt oss av är val vi fortfarande är nöjda med.
Trots att applikationen ska vidareutvecklas direkt så kommer den ändå att lanseras direkt. Detta sätter mer press på att applikationen inte ska ha några fel när vår del av projektet är klart. Vi har testat applikationen noggrant samt haft många möten med vår kund samt anställda på Sogeti för att vara helt säkra på att vi inte missat något viktigt innan den blir tillgänglig för användarna.
4.5
Summering
Applikationen har ändrats en hel del sedan våra skisser från start. De flesta av ändringarna är alternativ som vi valt att ta bort. Exempel på detta är ”Rapportera fångst” där vi valt att ta bort vissa fält då de inte var nödvändiga för en rapporteringen.
Som slutprodukt så är vi nöjda med resultatet. Applikationen kommer att lanseras till sommaren och allt är förberett inför detta.
Kapitel 5
Framtida funktionalitet
5.1
Introduktion
Intresset för fiske i Sverige har alltid varit stort, men det har nu nått en gräns där många fiskar och nästan inga rapporterar fångsterna. Det är detta problem som vår applikation ska lösa. I nuläget så täcker vår applikation endast Vänern och fungerar endast till Android. Detta har sedan början av vårt arbete planerats att bygga vidare på. Orsaken till att vi valde att börja med en Androidapplikation var för att det är Android som har mest användare på den mobila fronten just nu.
Vi täcker endast Vänern till en början då det är den sjö som är i störst behov av att få in fångstdata. Denna sjö är populär och kräver mycket vård för att hålla sig i samma skick som nu.
Vi har varit på ett möte med Havs- och vattenmyndigheten om applikationen och kom fram till att vi även ska kunna byta språk till engelska på applikationen då många av de som kommer och fiskar i Sverige inte alltid förstår svenska.
I detta kapitel kommer vi att gå igenom de tillägg som är planerade för tillfället och hur stor del som är täckta av vår applikation i dagsläget.
i kapitlet endast spekulationer.
5.2
Intresse
Under projektets gång har vi haft många möten angående behovet av applikationen. De flesta möten har varit med vår kund som jobbar som projektledare för sportfiskarna.se där han jobbar för att öka fångstrapporteringen i Sverige. Vi har även varit på fiskemässan i Kista och träffat relevanta personer från havs- och vattenmyndigheten samt mer anställda från sportfiske.se. Intresset hos dem efter vårt möte har varit riktigt stort och de tyc-ker alla att det är något som Sportfiskarna ska storsatsa på. Då många av de vi pratat med har många kontakter så kommer applikationen att spridas snabbt vid lansering. Det kommer även att tryckas ut mycket reklam så vi förväntar oss många nedladdningar av applikationen.
Om det blir många användare måste vi även täcka fler områden. De tillägg som kan bli aktuella diskuteras nedan.
5.2.1
Lägga till alla Sveriges sjöar
Som vi nämnt tidigare så täcker vår applikation endast Vänern för tillfället. Detta är endast tillfälligt. Vår databas är redan upplagd för att fler sjöar kommer att komma in. Detta medför att när vi rapporterar en fångst i dagsläget så skickar vi även med ett extravärde som säger att fisken fångades i Vänern. Detta ser dock inte användaren utan är bara till för att underlätta vid påbyggnad av applikationen.
Att gå från en sjö till flera är inte ett alltför stort steg. Visuellt så kommer den enda skillnaden vara att man väljer vilken sjö man fiskar i innan man kommer in på rapporte-ringsvyn. I den vyn kommer det att vara samma fält förutom att kartan kommer att bytas ut och det kommer att finnas andra sorters fisk. Resten kommer att vara sig likt.
då visas även i vilken sjö en fångst är gjord.
5.2.2
Fler språk
Det är inte ovanligt att sportfiskare från andra länder kommer och fiskar i Sverige. Då vi vill att så många fångster som möjligt ska rapporteras så kommer vi att lägga till flera språk som gör att alla kan använda sig av applikationen. Vår idé om detta hittills är att i startsidan, där användaren loggar in, ska kunna klicka på flaggor som representerar olika språk. Klickar användaren till exempel på en engelsk flagga så kommer språket att bytas ut till engelska. Det enda som kommer att bytas ut är texten i applikationen. Alla vyer, bilder och funktioner är fortfarande likadana.
När denna funktion finns så tyckte även havs- och vattenmyndigheten att det vore intressant att veta var användaren faktiskt är ifrån när de registrerar sig. Detta skulle betyda att vi även lägger till ett fält när användaren registrerar ett konto där denne väljer i en lista från vilket språk applikationen ska vara på, samt med detta även ge data kring olika nationaliteters fiske.
Applikationen kommer inte att ta med några andra sjöar från andra länder, utan kom-mer alltid endast att täcka Sverige.
5.2.3
Hemsida
För tillfället finns det ingen hemsida som är kopplad till applikationen. Fångsterna visas därför inte upp någonstans förutom i applikationen. I applikationen så ser man endast fångsterna kopplade till användarens konto. Detta betyder att andra användares fångster inte visas för tillfället, då det vi ansåg att det är en funktion som är bättre anpassad till en senare hemsida.
visa upp alla de fångster som inte är registrerade som privata fångster. Det ska även vara möjligt att rapportera fångster via denna hemsida istället för att göra det via applikationen. På Fiskekort.se finns det en hemsida som är direkt kopplad till den gamla databasen som vi har ersatt. Problemet med denna var att den var svår att navigera sig igenom och att den hade för få fångster att visa upp. Våra förhoppningar är att applikationen ska täcka problemet med fångsterna och den nya hemsidan då ska visa upp detta på ett enkelt och snyggt sätt. Som det är sagt ska hemsidan skrivas till hösten.
5.2.4
iOS-applikation
I dagsläget fungerar endast applikationen för produkter som stödjer Android. Då många har iPhones så kommer det även antagligen att utvecklas en applikation för iOS. Både funktionerna och designen kommer att vara likadana i denna applikation. På detta sätt når vi fler användare och får in mer rapporteringar.
Då Android och iOS är olika när det gäller att skapa program så kommer det att dröja ett tag innan iOS-versionen kommer ut. Men då de kommer att använda sig av samma struktur och funktioner så kommer det att förenkla utvecklandet. Här kommer det API vi utvecklat att vara till stor hjälp. Det är fortfarande inte bestämt när iOS-applikationen ska göras, men i ett möte med kunden så kommer de att försöka så fort som möjligt för att inte tappa några användare.
Då vår kund är från en ideell organisation så kan det vara svårt med finansieringen, men kunden har full förståelse för att de inte kan strunta i iOS-applikationen.
5.3
Summering
Planerna för applikationen är stora och tanken är att nå ut till många användare. Vårt projekt kommer därför att föras vidare under en längre tid. Därför har det varit viktigt att lägga upp strukturen för vidareutveckling. Hade vi inte lagt till alla fält i databasen direkt
Kapitel 6
Slutsats
Det finns stora planer på vidareutveckling och allt detta tas upp i kapitel 5. Detta då vi tyckte att det var så mycket information att det behövde ett eget kapitel. Därför tas detta inte upp mycket i slutsatsen.
6.1
Generell summering
Projektet har gått ut på att skapa en Androidapplikation där användaren ska kunna rappor-tera fångster i Vänern. Orsaken till detta är för att de tidigare metoderna för att rapporrappor-tera fångster var för komplicerade och vår kund fick därför inte in nog med rapporteringar för att kunna ta hand om Sveriges fiskvatten.
Vår kund har varit Sportfiskarna, Sveriges Sportfiske- och Fiskevårdsförbund De har varit med under hela projektets gång och det är de som kommer få full äganderätt på applikationen efter projektets slutförande.
