Android app for aktivering av jakt- og fiskekortstudent.cs.hioa.no/hovedprosjekter/data/2014/06/Sluttrapport.pdf · Side 5 av 103 Til produktet er det ikke laget noen brukerveiledning,

Hovedprosjekt 2014

Android app for aktivering

av jakt- og fiskekort

Høgskolen i Oslo og Akershus

Nanna Mjørud

Anette Molund

Charlotte Sjøthun

Side 1 av 103

Side 2 av 103

Side 3 av 103

Side 4 av 103

Forord

Dette dokumentet er en endelig rapport for vårt hovedprosjekt på Høgskolen i Oslo og

Akershus våren 2014. Prosjektet er gjennomført i samarbeid med BEKK, heretter kalt

«oppdragsgiver», for Inatur, heretter kalt «kunde».

Oppgaven gikk ut på å lage en mobilapplikasjon som skulle kunne brukes av jegere og

fiskere, heretter kalt «brukere», for aktivering av jakt- og fiskekort.

For å teste applikasjonen ved sensur kan sensor logge seg inn med følgende:

Brukernavn: [email protected]

Passord: sensor1

Grunnet stadige endringer i testmiljøet blir ofte test-brukerkontoer slettet. Dersom man

får beskjed om feil brukernavn eller passord ta kontakt med oss via mail:

[email protected].

Leserveiledning

Dokumentasjonen består av følgende deler:

Kapittel 1 «Presentasjon» her er det en innledende tekst der man raskt kan sette

seg inn i prosjektets kontekst og alle partene som har vært involvert.

Kapittel 2 «Produktbeskrivelse» her presenteres produktet. Dette tilsvarer det

som før var en egen rapport kalt «Produktrapport».

Kapittel 3 «Valg og utfordringer» her beskrives hvilke valg vi har tatt underveis,

og hvilke utfordringer vi har hatt.

Kapittel 4 «Prosessbeskrivelse» her presenteres prosessen underveis i

prosjektet. Dette tilsvarer det som før var en egen rapport kalt «Prosessrapport».

Kapittel 5 «Testbeskrivelse» her tar vi for oss testingen av produktet.

Kapittel 6 «Avslutning» her oppsummeres prosjektets essens og til slutt følger en

konklusjon.

mailto:[email protected]

mailto:[email protected]

Side 5 av 103

Til produktet er det ikke laget noen brukerveiledning, men applikasjonens bruk blir

gjennomgått i sin helhet i kapittel 2.1.

Det forutsettes at leseren har noe teknisk kompetanse innen programmering. Likevel er

det brukt fotnoter med forklaring ved første forekomst av tekniske ord. I tillegg er det lagt

ved en ordliste med forklaringer på alle tekniske begreper innen programmering og

jakt/fiske.

For en fullverdig leseropplevelse anbefales det å lese hele dokumentet slik det er bygget

opp. Dersom dette ikke er ønskelig er det forslått leserveiledning for forskjellige

lesergrupper nedenfor.

For sensor For sensor anbefales det spesielt å lese kapittel 1 «Presentasjon», herunder kapittel 1.1

«Innledning », kapittel 2 «Produktbeskrivelse», herunder kapittel 2.1 «Applikasjonen i

skjermbilder», kapittel 3 «Valg og utfordringer» og kapittel 6 «Avslutning». I tillegg kan det

være lurt å lese gjennom «Kravspesifikasjon» som ligger vedlagt på side 94.

For videreutviklere For videreutviklere eller andre som har behov for å sette seg inn i det tekniske, anbefales

det spesielt å lese kapittel 2 «Produktbeskrivelse», kapittel 3 «Valg og utfordringer» med

unntak av kapittel 3.1-3.7. I tillegg kan det være lurt å lese gjennom «Kravspesifikasjon»

som ligger vedlagt på side 94.

For andre interesserte For å få en god innsikt i produktet vil vi for andre interesserte spesielt anbefale kapittel 1

«Presentasjon», kapittel 2.1 «Applikasjonen i skjermbilder» og kapittel 6 «Avslutning».

Ellers står man fritt til å lese de kapitlene man ønsker.

Side 6 av 103

Innholdsfortegnelse

Forord .......................................................................................................................................... 4

Leserveiledning ....................................................................................................................... 4

For sensor .......................................................................................................................................................................... 5

For videreutviklere ........................................................................................................................................................ 5

For andre interesserte .................................................................................................................................................. 5

1 Presentasjon ................................................................................................................... 12

1.1 Innledning ............................................................................................................................................................. 12

1.2 Prosjektets deltakere ....................................................................................................................................... 13

1.2.1 Studentgruppen ............................................................................................................................................................. 13

1.2.2 Bekk Consulting AS ...................................................................................................................................................... 14

1.2.3 Inatur Norge AS ............................................................................................................................................................. 14

1.3 Om bakgrunnen .................................................................................................................................................. 15

1.4 Kort presentasjon av sluttproduktet ......................................................................................................... 15

2 Produktbeskrivelse ...................................................................................................... 17

2.1 Applikasjonen i skjermbilder ........................................................................................................................ 17

2.1.1 Innlogging ......................................................................................................................................................................... 17

2.1.2 Kortaktivering ................................................................................................................................................................ 18

2.1.3 Kortinformasjon ............................................................................................................................................................ 19

2.1.4 Aktivering ......................................................................................................................................................................... 19

2.1.5 Utførte aktiveringer ..................................................................................................................................................... 22

2.1.6 Bevis .................................................................................................................................................................................... 23

2.1.7 Meny ................................................................................................................................................................................... 24

2.2 Kommunikasjon med brukeren ................................................................................................................... 27

2.2.1 Meldinger som krever interaksjon ........................................................................................................................ 27

Side 7 av 103

2.2.2 Meldinger som ikke krever interaksjon .............................................................................................................. 28

2.2.3 Meldinger som er informasjon ................................................................................................................................ 28

2.3 Applikasjonens komponenter....................................................................................................................... 28

2.3.1 Java-klasser ...................................................................................................................................................................... 29

2.3.2 XML-filer ........................................................................................................................................................................... 31

2.4 Teknisk beskrivelse av klassene .................................................................................................................. 35

2.4.1 Innlogging ......................................................................................................................................................................... 36

2.4.2 Kortlister ........................................................................................................................................................................... 36

2.4.3 Kortaktivering ................................................................................................................................................................ 37

2.4.4 Utførte aktiveringer ..................................................................................................................................................... 37

2.4.5 Aktivering ......................................................................................................................................................................... 37

2.4.6 Bevis .................................................................................................................................................................................... 38

2.4.7 Kortinformasjon ............................................................................................................................................................ 38

2.4.8 Hjelp .................................................................................................................................................................................... 38

2.4.9 Kontakt .............................................................................................................................................................................. 38

2.4.10 Om Inatur ......................................................................................................................................................................... 38

2.4.11 Innstillinger ..................................................................................................................................................................... 38

2.4.12 KortaktiveringArrayAdapter og UtforteAktiveringerArrayAdapter ...................................................... 39

2.4.13 DatabaseHaandterer .................................................................................................................................................... 39

2.4.14 APIHaandterer ............................................................................................................................................................... 39

2.4.15 Aktiveringsdata .............................................................................................................................................................. 40

2.4.16 Innloggingsparametere .............................................................................................................................................. 40

2.4.17 DagsAktivering ............................................................................................................................................................... 40

2.4.18 Delomraade ..................................................................................................................................................................... 40

2.4.19 Kort ...................................................................................................................................................................................... 40

2.4.20 Person ................................................................................................................................................................................ 40

2.4.21 SettPeriodiskService .................................................................................................................................................... 41

2.4.22 SjekkUtlopteKortService ............................................................................................................................................ 41

2.4.23 StartServiceBroadcastReceiver .............................................................................................................................. 41

Side 8 av 103

3 Valg og utfordringer ..................................................................................................... 42

3.1 AndroidAnnotations ......................................................................................................................................... 42

3.2 JDK 7 fremfor JDK 6 .......................................................................................................................................... 42

3.3 Retrofit fremfor Jersey ..................................................................................................................................... 42

3.4 IntelliJ fremfor Android Studio .................................................................................................................... 43

3.5 Behandling av dato og tid ............................................................................................................................... 43

3.6 Service og BroadcastReceiver ....................................................................................................................... 43

3.7 Utfordringer med APIet ................................................................................................................................... 43

3.7.1 Nettverkstrafikk ............................................................................................................................................................ 44

3.8 AccountManager ................................................................................................................................................ 47

3.9 Sikkerhet ............................................................................................................................................................... 47

3.9.1 Bevaring av cookie ....................................................................................................................................................... 47

3.9.2 JSON escaping ................................................................................................................................................................. 48

3.10 Retningslinjer for design ................................................................................................................................ 48

3.11 Kravspesifikasjonens rolle ............................................................................................................................. 49

3.11.1 Norsk kode ....................................................................................................................................................................... 49

3.11.2 Tilleggsfunksjonalitet .................................................................................................................................................. 50

3.11.2.1 Synliggjøring av manglende fangstrapport ................................................................................................................... 50

3.11.2.2 Bytte språk til engelsk ............................................................................................................................................................ 50

3.11.2.3 Forstørre skriften ..................................................................................................................................................................... 50

3.11.3 Designkrav ....................................................................................................................................................................... 50

3.11.3.1 Faner .............................................................................................................................................................................................. 50

3.11.3.2 Bevis ............................................................................................................................................................................................... 51

3.11.3.3 Visning av kalender ................................................................................................................................................................. 52

3.11.3.4 Status i kalender ved aktivering av kort ......................................................................................................................... 53

3.11.4 Lansering i Google Play .............................................................................................................................................. 55

3.11.5 Testdreven utvikling ................................................................................................................................................... 55

4 Prosessbeskrivelse ....................................................................................................... 57

Side 9 av 103

4.1 Inatur som domene ........................................................................................................................................... 57

4.2 Planleggingsfasen .............................................................................................................................................. 57

4.2.1 UML ..................................................................................................................................................................................... 57

4.2.1.1 Use case diagram ...................................................................................................................................................................... 58

4.2.1.2 Aktivitetsdiagram ..................................................................................................................................................................... 59

4.2.1.3 Tilstandsdiagram ...................................................................................................................................................................... 60

4.2.2 Design ................................................................................................................................................................................. 60

4.2.2.1 Første utkast av skisser ......................................................................................................................................................... 61

4.2.2.2 Andre utkast av skisser .......................................................................................................................................................... 64

4.3 Implementasjonsfasen ..................................................................................................................................... 67

4.4 Arbeidsforhold .................................................................................................................................................... 67

4.4.1 Prosjektdagbok .............................................................................................................................................................. 67

4.5 Kommunikasjon ................................................................................................................................................. 67

4.5.1 Kommunikasjon i gruppen ....................................................................................................................................... 68

4.5.2 Kommunikasjon med kunden ................................................................................................................................. 68

4.5.3 Kommunikasjon med oppdragsgiver ................................................................................................................... 68

4.6 Smidig utvikling .................................................................................................................................................. 68

4.7 Verktøy ................................................................................................................................................................... 69

4.7.1 Prosessverktøy ............................................................................................................................................................... 70

4.7.1.1 Git .................................................................................................................................................................................................... 70

4.7.1.2 Trello ............................................................................................................................................................................................. 70

4.7.1.3 Microsoft Word ......................................................................................................................................................................... 71

4.7.1.4 Dropbox ........................................................................................................................................................................................ 71

4.7.1.5 Facebook ...................................................................................................................................................................................... 71

4.7.1.6 Skype ............................................................................................................................................................................................. 71

4.7.2 Utviklingsverktøy .......................................................................................................................................................... 71

4.7.2.1 IntelliJ ............................................................................................................................................................................................ 71

4.7.2.2 Java Development Kit (JDK) ................................................................................................................................................. 72

4.7.2.3 Android Software Development Kit (Android SDK) .................................................................................................. 72

4.7.2.4 Genymotion ................................................................................................................................................................................. 72

Side 10 av 103

4.7.2.5 Maven ............................................................................................................................................................................................ 72

4.7.2.6 JSON ................................................................................................................................................................................................ 73

4.7.2.7 Joda Time ..................................................................................................................................................................................... 73

5 Testbeskrivelse .............................................................................................................. 74

5.1 Verktøy og enheter benyttet ved testing .................................................................................................. 74

5.2 Testing .................................................................................................................................................................... 74

5.2.1 Testing underveis ......................................................................................................................................................... 74

5.2.2 Brukertesting .................................................................................................................................................................. 75

5.2.3 Testing på forskjellige Android API versjoner ................................................................................................. 76

5.2.4 Testing på forskjellige skjermstørrelser ............................................................................................................. 76

5.2.5 Testing av fargekontrast ............................................................................................................................................ 77

5.2.6 Alfa-testing ....................................................................................................................................................................... 77

6 Avslutning ........................................................................................................................ 78

6.1 Verdien av produktet ....................................................................................................................................... 78

6.1.1 Verdien for brukere ..................................................................................................................................................... 78

6.1.2 Verdien for kunden ...................................................................................................................................................... 78

6.1.3 Verdien for oppdragsgiver ........................................................................................................................................ 78

6.1.4 Verdien for oss ............................................................................................................................................................... 79

6.2 Læringsbytte ........................................................................................................................................................ 79

6.3 Tilbakemeldinger ............................................................................................................................................... 79

6.4 Konklusjon ............................................................................................................................................................ 82

7 Kilder ................................................................................................................................. 83

8 Vedlegg .............................................................................................................................. 85

8.1 Vedlegg A: Figurliste ......................................................................................................................................... 86

8.2 Vedlegg B: Ordbok ............................................................................................................................................. 89

8.2.1 Kodebegreper ................................................................................................................................................................. 89

Side 11 av 103

8.2.2 Jakt- og fiskebegreper ................................................................................................................................................. 92

8.3 Vedlegg C: Kravspesifikasjon ........................................................................................................................ 94

Side 12 av 103

1 Presentasjon

I dette kapittelet finner man aller først en innledning, hvor man raskt kan sette seg inn i

hva oppgaven går ut på. Deretter følger en presentasjon av prosjektets deltagere, og til

slutt et underkapittel om bakgrunnen for oppgaven og en kort presentasjon av

sluttproduktet.

1.1 Innledning Naturen er en stor del av mange nordmenns liv, og mange setter pris på å bruke fritiden på

både jakt og fiske. Inatur er Norges største markedsplass på nett for salg av jakt, fiske og

hytter i norsk natur. I 2013 hadde inatur.no 1,2 millioner besøkende og 6,5 millioner

sidevisninger. Fra 2012 til 2013 hadde de i snitt en økning på 49,5 % for jakt- og fiskekort

(Inatur Norge AS, 2014). Bakgrunnen for dette prosjektet var at Inatur ønsket en

mobilapplikasjon for aktivering av jakt- og fiskekort.

På inatur.no kan alle som forvalter jakt- eller fiskerettigheter selge jakt- og fiskekort. Noen

av disse kortene krever aktivering for et spesielt delområde, før man benytter seg av disse.

Grunnen til dette er at de som forvalter områdene ønsker rasjonering og kontroll på antall

mennesker i marka.

Vår oppgave har derfor gått ut på å lage en Android

applikasjon der brukerne kan laste inn og aktivere kort

som er kjøpt på inatur.no. Kundens krav fra starten har

vært veldefinerte og klare, der funksjonalitet og

brukervennlighet var viktig. Den viktigste

funksjonaliteten for dem var at brukeren skulle kunne

fremvise bevis for gyldig aktivering uten å ha nett-

tilgang. For å implementere denne funksjonaliteten var

det avgjørende at all annen ønskelig funksjonalitet også ble implementert. Resultatet av

prosjektet er en velfungerende applikasjon der brukerne kan vise alle kort der aktivering

Figur 1: Android logo

Side 13 av 103

er nødvendig, aktivere disse kortene og medbringe gyldig bevis i naturen. Det anbefales å

se applikasjonen i skjermbilder i kapittel 2.1 for en enklere forståelse av produktet.

Applikasjonens brukere er ment å være jegere og fiskere, og målgruppen er alle mennesker

i alderen 14 år og oppover. Et av de viktigste punktene har derfor vært å gjøre det intuitivt

og brukervennlig for folk i alle aldersgrupper.

1.2 Prosjektets deltakere I dette kapittelet blir først studentgruppen presentert. Deretter er det en presentasjon av

oppdragsgiver. Til slutt blir kunden presentert.

Figur 2: Oversikt over prosjektets deltakere

1.2.1 Studentgruppen

Gruppen består av Charlotte Sjøthun, Nanna Mjørud og Anette Molund. Charlotte og Nanna

studerer informasjonsteknologi, og Anette studerer dataingeniør. Vi har tidligere jobbet

sammen på flere prosjekter, og kjenner derfor hverandres styrker og svakheter. Dessuten

passer våre interesser godt sammen i en prosjektgruppe fordi vi har noe ulike preferanser

angående arbeidsområde. Vi har også likt ambisjonsnivå, og har samme tanker om hvor

mye arbeidsmengde vi ønsker å legge ned i prosjektet.

Side 14 av 103

Nanna og Charlotte har stor interesse for back-end programmering, med hovedvekt på Java

og .NET. I tillegg synes Nanna at JavaScript er spennende, mens Charlotte liker godt å

programmere Android-applikasjoner. Anette trives best med front-end, med blant annet

HTML og CSS, men synes også databaser er interessant å jobbe med. I tillegg er hun glad i å

skrive dokumentasjon.

1.2.2 Bekk Consulting AS

Bekk Consulting AS er et norsk konsulentselskap. De

gjennomfører prosjekter for store private og

offentlige virksomheter innen strategisk rådgivning,

utvikling av IT-systemer og design av digitale

tjenester. De er i dag omkring 320 ansatte, og har kontorer i Oslo og Trondheim (Bekk

Consulting AS).

Vår veileder hos BEKK er Christoffer Marcussen og ansvarlig for oppgaven er Christian

Schwarz. Christoffer er med i BEKKs faggruppe for mobilutvikling, og har erfaring med

Android i forbindelse med dette. Han har derfor gode forutsetninger for å bistå faglig der

det er behov for det.

1.2.3 Inatur Norge AS

Inatur Norge AS har hovedkontor i Namsos og drifter

Inatur.no, som er Norges største markedsplass på nett

for jakt, fiske og hytter i villmarka. Tilbudene på

inatur.no dekker 70 % av Norges areal på jakt og fiske.

På inatur.no finner du tilbud om jakt, fiske og overnatting i hele Norge.

Inatur Norge AS eies av Statskog SF, Norges fjellstyresamband, Norges Jeger og

Fiskerforbund, Norges Skogeierforbund og Norske Lakseelver (Inatur Norge AS).

BEKK jobber tett med Inatur, blant annet har de utviklet og videreutvikler inatur.no. Dette

gjør at BEKK kjenner godt til Inatur og deres behov.

Figur 3: BEKK logo

Figur 4: Inatur logo

Side 15 av 103

1.3 Om bakgrunnen Inatur har i dag kun en løsning for web, slik at brukerne må bruke en nettleser for å få

tilgang til websiden på en mobiltelefon. Dette er tregere enn en mobilapplikasjon og man

er avhengig av internett. Websiden er dessuten ikke optimalisert for en mobil plattform,

selv om den er gjort responsiv. Dette gjør at brukeropplevelsen blir dårligere. For å

fremvise bevis på aktivert kort må man i dag hente frem kvitteringsmail eller ha skrevet ut

beviset på papir i forkant.

Inatur ønsker å tilby brukerne en effektiv og brukervennlig måte å kunne aktivere tidligere

kjøpte jakt- og fiskekort når de er ute i naturen for å jakte/fiske. De ønsker også at

brukerne skal kunne fremvise bevis på aktivert kort enkelt på mobilen uten å ha internett-

tilgang.

1.4 Kort presentasjon av sluttproduktet Hovedformålet med applikasjonen er at brukerne skal kunne vise bevis for utførte

aktiveringer uavhengig av nett-tilgang. De skal også enkelt kunne utføre en aktivering når

de er ute i jaktfeltene, hvis de har nett-tilgang.

Hovedfunksjonene i applikasjonen er:

Logge inn

Vise kjøpte kort som krever aktivering

Utføre aktiveringer

Vise aktiveringer

Vise bevis

Endre aktiveringer

Slette aktiveringer

I applikasjonen må man først logge inn med en brukerkonto som er opprettet på inatur.no.

Deretter kan man se kort man har kjøpt som trenger aktivering, og man kan se utførte

Figur 5: Innloggingsskjerm

Side 16 av 103

aktiveringer. Brukeren kan blant annet velge å utføre en ny aktivering eller vise bevis for

en aktivering. For en full gjennomgang av applikasjonen i skjermbilder se kapittel 2.1.

Figur 6: Skjermbilde av kortliste

Figur 7: Skjermbilde av aktivering

Figur 8: Skjermbilde av utførte aktiveringer

Side 17 av 103

2 Produktbeskrivelse

Under dette kapittelet vil produktet av prosjektet bli beskrevet. Først blir applikasjonen

presentert med skjermbilder og forklarende tekst. Deretter påfølger et underkapittel hvor

det blir beskrevet hvordan kommunikasjon med brukeren foregår. Til slutt følger en

oversikt over alle komponentene i applikasjonen og en teknisk beskrivelse av klassene.

2.1 Applikasjonen i skjermbilder Nedenfor er en forklarende tekst til skjermbildene i applikasjonen. I tillegg til

skjermbildene som er beskrevet under har vi en BroadcastReceiver1 og to Servicer2. Disse

skal sjekke en gang om dagen om det er noen utløpte kort eller aktiveringer som ligger

lagret lokalt i databasen og slette disse.

2.1.1 Innlogging

Her logger brukeren seg inn med et brukernavn

og passord som er opprettet på inatur.no. Dersom

man skriver inn feil brukernavn eller passord vil

man få beskjed om dette. Det er lagt inn en lenke

man kan trykke på dersom man har glemt

passord og en lenke for å registrere seg som

bruker. Trykker man på disse lenkene blir man

sendt til «glemt passord» eller «registrer deg»-

siden på inatur.no

Figur 9: Innlogging

1 En komponent som registrerer systemhendelser, f.eks. at enheten blir slått på eller at det er lavt batterinivå.

2 En komponent som kjøres i bakgrunnen, og således ikke nødvendigvis blir lagt merke til av brukerne.

Side 18 av 103

2.1.2 Kortaktivering Dette er skjermbildet for kortaktivering.

Her vises kortene brukeren har kjøpt på inatur.no

som krever aktivering. Her kan man velge å

aktivere et kort, oppdatere listen eller velge et

menyvalg (se Figur 21). Om man trykker på et

kort i listen vil man få opp detaljert

kortinformasjon (se Figur 11). Om et kort i listen

ikke har dager som kan aktiveres innenfor 14

dager frem i tid, inkludert dagens dato, vises ikke

aktiver-knappen. Kortene som blir hentet fra

APIet blir lagret lokalt i databasen. Dersom det

ikke er internettforbindelse eller en feil oppstod

ved henting fra APIet, vil man få beskjed om dette

og kortene som vises hentes lokalt fra databasen.

Figur 10: Kortaktivering

Side 19 av 103

2.1.3 Kortinformasjon Her vises detaljert informasjon om kortet man

trykket på i kortaktivering. Her kan man velge å

utføre en aktivering direkte. Dersom kortet ikke

har dager som kan aktiveres innenfor 14 dager

frem i tid, inkludert dagens dato, blir aktiver-

knappen deaktivert. Det vil si at teksten blir grået

ut og man vil ikke få noen respons når det trykkes

på knappen.

Figur 11: Kortinformasjon

2.1.4 Aktivering Her vises en kalender hvor dager som kan velges

er hvite, dager som er stengt eller er fulle for et

delområde er røde (se Figur 13) og dager som

ikke er gyldige for kortet er grå. Om det allerede

er utført aktiveringer på kortet som er innenfor

den gyldige tidsperioden på 14 dager, vises disse

rett over kalenderen (se Figur 16). Aktiver-

knappen blir først aktivert (teksten blir hvit og

man kan trykke på den) etter at det er valgt

delområde og minst én dag for aktivering. Dersom

brukeren prøver å velge en dag uten å velge

delområde først, vil det dukke opp en melding på

skjermen om at delområde må velges først. Man

har også tilgang til menyen i dette skjermbildet.

Figur 12: Aktivering

Side 20 av 103

Her er det trykket på spinneren3 for å velge nytt

delområde. Det delområdet som er valgt er det

som står i selve spinneren, og har grønn

tekstfarge. Balvatnet har her dager som er stengt,

de vises som røde og det skjer ikke noe om man

trykker på dem. Fulle dager på området vises på

samme måte som stengt, men med teksten

«Fullt!». Om det valgte delområdet har en

kommentar, vises denne under kalenderen slik

som vises på bildet. Om det ikke er noen

kommentar vises ikke det tekstfeltet.


Når dager i kalenderen velges blir disse markert

med grønn farge. Man kan velge bort dager ved å

klikke på dem igjen, da vil grønnfargen forsvinne.

I dette skjermbildet er lørdag 3. og søndag 4.

valgt.

Det kan kun aktiveres for ett delområde av

gangen, men man kan velge flere dager samtidig.

Dersom man har valgt noen dager på et

delområde, for så å velge nytt delområde, vil de

valgte dagene bli glemt.


3 Androids innebygde dropdown liste, ved berøring blir alle tilgjengelige valg synlig (Android Inc.).

Side 21 av 103

Her vises dialogboksen4 som dukker opp om man

må levere fangstrapport for å kunne utføre en

aktivering. Dersom man velger «Avbryt» blir man

sendt tilbake til kortaktivering. Om man velger

«Lever fangstrapport» blir det åpnet en nettleser

der man kan logge inn og deretter kommer man

til fangstrapporteringen hos inatur.no. Når

fangstrapportering er utført og man går tilbake til

applikasjonen vil man komme tilbake til

aktiviteten for aktivering, og tilstanden med valgt

delområde og valgte datoer er blitt bevart.

Figur 15: Dialogboks fangstrapport

Tidligere utførte aktiveringer vises i grønne

bokser over kalenderen. Når man velger et

delområde som har tidligere utførte aktiveringer,

som i dette skjermbildet, blir de dagene som

allerede er aktiverte vist på samme måte som

dager man velger, men disse kan ikke trykkes på.

Om man velger et annet delområde fjernes

markeringen av disse dagene, og velger man en av

disse på et annet delområde, vil den tidligere

utførte aktiveringen bli endret.


4 En dialog er et lite vindu som ber brukeren om å ta en beslutning eller angi tilleggsinformasjon.

Side 22 av 103

2.1.5 Utførte aktiveringer Her vises én og én aktivert dag. Det samme kortet

kan stå flere ganger i lista, men da med de

forskjellige dagene som er aktivert. Her kan man

vise bevis for en utført aktivering, slette en

aktivering, endre en aktivering eller velge et

menyvalg. Om man trykker på en utført aktivering

i listen vil man få opp en dialogboks (se Figur 18).

Det samme gjelder her som i Kortaktivering, altså

at aktiveringene som blir hentet fra APIet blir

lagret lokalt i databasen, og dersom telefonen

ikke har internettforbindelse eller en feil oppstod

ved henting fra APIet, vil informasjonen hentes

lokalt fra databasen.

Figur 17: Utførte aktiveringer

Her vises dialogboksen som dukker opp når det

trykkes på et element i listen. Som tittel på

dialogboksen står datoen og delområde for

aktiveringen. Om man velger bevis, blir man sendt

videre til bevis (se Figur 20) velger man å endre

blir man sendt til aktivering (se Figur 12) og

velger man å slette aktiveringen vil det dukke opp

en dialogboks hvor man må bekrefte dette (se

Figur 19).

Figur 18: Utførte aktiveringer liste meny

Side 23 av 103

Her vises dialogboksen som dukker opp når man

velger å slette en aktivering. Denne vises for å

hindre at brukeren sletter en aktivering ved en

feiltagelse. Velger man å bekrefte slettingen vil

den valgte aktiveringen fjernes fra listen

umiddelbart .

Figur 19: Dialogboks bekreft sletting

2.1.6 Bevis Dette er skjermbildet for bevis.

Beviset er en bekreftelse på en utført aktivering

og her vises alle detaljer om en aktivering. Ved

eventuell kontroll må denne fremvises.

Såfremt aktiveringen er lagret lokalt i databasen,

vil man kunne vise beviset uten å ha internett-

tilgang.

Figur 20: Bevis

Side 24 av 103

2.1.7 Meny Her vises menyvalgene. De kommer til syne når

man trykker på de tre vertikale prikkene eller

menytasten på mobilen. Her kan man velge

«Hjelp» (se Figur 22) «Om Inatur» (se Figur 23),

«Kontakt» (se Figur 24), «Innstillinger» (se Figur

25) og «Logg ut» (se Figur 27).

Figur 21: Meny

Dette er skjermbildet for hjelp.

Her finner man brukerveiledning for

hovedfunksjonene i applikasjonen:

Aktivering av kort

Vise bevis for aktivering

Slette aktivering

Endre aktivering

Vise kortdetaljer

Figur 22: Hjelp

Side 25 av 103

Dette er skjermbildet for om Inatur.

Her kan brukerne lese informasjon om Inatur.

Denne informasjonen er hentet fra inatur.no.

Figur 23: Om Inatur

Dette er skjermbildet for kontakt.

Her vises kontaktinformasjonen til Inatur. Denne

informasjonen er hentet fra inatur.no.

Figur 24: Kontakt

Side 26 av 103

Dette er skjermbildet for innstillinger.

Her kan man endre skriftstørrelsen om man

ønsker denne større eller mindre. Trykker man på

dette innstillingsvalget vil det vises en dialogboks

der man kan velge forskjellige skriftstørrelser (se

Figur 26).

Figur 25: Innstillinger

Her vises dialogboksen for å velge skriftstørrelse.

Når man endrer skriftstørrelsen her så vil teksten

i applikasjonen bli endret til den valgte størrelsen.

Dersom man ikke endrer skriftstørrelsen er det

«Vanlig» skriftstørrelse som er gjeldende.

Figur 26: Dialogboks - endre skriftstørrelse

Side 27 av 103

Her vises dialogboksen som dukker opp når man

velger å logge ut. Man må her bekrefte at man vil

logge ut. Dette er for å forhindre at man logger ut

ved et uhell.

Figur 27: Dialogboks - bekreft utlogging

2.2 Kommunikasjon med brukeren Applikasjonen kommuniserer med brukeren på ulike måter avhengig av meldingens

viktighet og hvilket behov det er for interaksjon. Nedenfor har vi beskrevet de tre ulike

måtene vi gir tilbakemelding til brukeren på.

2.2.1 Meldinger som krever interaksjon

Meldinger der det kreves at brukeren tar et aktivt

valg, vises som en dialogboks. Eksempler på dette er

når bruker forsøker å slette en aktivering og når

bruker forsøker å gjennomføre en aktivering.

Noen av disse meldingene er det mulig å lukke ved å

trykke utenfor dialogboksen. Da vil boksen forsvinne,

slik det gjør ved å velge avbryt. Andre steder er det

ikke mulig å trykke utenfor dialogboksen for å lukke den. Dette har vi bevisst gjort de

steder hvor det ikke gir mening å lukke dialogboksen. Et eksempel på dette er der noen

Figur 28: Dialog

Side 28 av 103

aktiveringer ble utført, mens det gikk galt med noen andre. Da vil det ikke være naturlig at

brukeren ønsker å lukke dialogboksen for å fortsette i aktiveringsbildet.

2.2.2 Meldinger som ikke krever interaksjon

Meldinger som ikke krever interaksjon med bruker, men

som er nyttig informasjon for brukeren, blir vist som en

Toast5. Det kan for eksempel være feilmeldinger til bruker

eller informasjon om at en ønsket handling er utført.

Ved API-kall vil det bli vist en ProgressDialog6, for å vise

brukeren at applikasjonen jobber. Denne dialogen

er det ikke mulig å lukke, og brukeren kan ikke

foreta seg noe annet i applikasjonen når denne

vises.

2.2.3 Meldinger som er informasjon

Der det er nyttig informasjon til bruker, men

som ikke krever interaksjon, blir meldingen

vist i form av et TextView7. Dette brukes i

Kortaktivering og Utførte Aktiveringer hvis det

ikke er noen kort som kan aktiveres eller det

ikke er noen utførte aktiveringer.

2.3 Applikasjonens komponenter Under dette kapittelet er det to underkapitler som viser Java- og XML filene som tilhører

prosjektet.

5 Et liten popup med tilbakemelding til brukeren. 6 En dialogboks som viser en fremdriftsindikator og en valgfri tekst (Android Inc., 2014). 7 Ett tekstfelt som viser tekst til brukeren, men er ikke mulig å redigere (Android Inc.).

Figur 30: Toast

Figur 29: ProgressDialog

Figur 31: TextView med informasjon

Side 29 av 103

2.3.1 Java-klasser

Nedenfor er en liste over applikasjonens Java-filer logisk oppdelt og sortert alfabetisk.

Ni aktiviteter

o Aktivering.java

o Bevis.java

o Hjelp.java

o Innlogging.java

o Innstillinger.java

o Kontakt.java

o Kortinformasjon.java

o Kortlister.java

o OmInatur.java

To fragmenter8

o Kortaktivering.java

o UtforteAktiveringer.java

To ArrayAdapter-klasser som er tilknyttet fragmentene

o KortaktiveringArrayAdapter.java

o UtforteAktiveringerArrayAdapter.java

Seks objekt-klasser

o Aktiveringsdata.java

o DagsAktivering.java

o Delomraade.java

o Innloggingsparametere.java

o Kort.java

o Person.java

Ett interface som kommuniserer med Inaturs API

o APIHaandterer.java

Én database-klasse

8 Representerer en oppførsel eller en del av brukergrensesnittet i en aktivitet. Se ordboken for mer detaljert

forklaring.

Side 30 av 103

o DatabaseHaandterer.java

To Service-klasser

o SettPeriodiskService.java

o SjekkUtlopteKortService.java

Én BroadcastReceiver

o StartServiceBroadcastReceiver

I tillegg finnes det syv test-klasser

o AktiveringTest.java

o CustomRobolectricTestRunner.java

o DatabaseTest.java

o InnloggingTest.java

o KortaktiveringArrayAdaperTest.java

o KortaktiveringTest.java

o KortlisterTest.java

Figur 32: Oversikt over aktivitetene og fragmentene

Side 31 av 103

2.3.2 XML-filer

Vi har tilpasset designet til forskjellige skjermstørrelser ved hjelp av mappene «layout»

som er default layout-mappe, «layout-small» som er tilpasset små skjermer, «layout-large»

som er tilpasset større skjermer, og «layout-xlarge» som er tilpasset store skjermer som

tablets. Når man benytter mapper med disse navnene vil layout-fil bli valgt automatisk

basert på telefonens skjermstørrelse. I tillegg har vi tilpasset designet liggende for de

skjermstørrelser vi syntes det var nødvendig. For å kunne tilby brukeren å øke

tekststørrelse i applikasjonen har vi valgt å legge inn ekstra filer for dette i hver av

mappene, og disse har vi kalt for eksempel «bevis_liten.xml», «bevis_stor.xml» og

«bevis_xstor.xml». Der vi ikke har lagt inn slike filer i forskjellige mapper, blir filene hentet

fra default-mappen. Dette valgte vi å gjøre der det var forsvarlig, for å unngå unødvendige

filer.

Nedenfor er en liste over applikasjonens XML-filer logisk oppdelt i mapper og sortert

alfabetisk.

AndroidManifest.xml

drawable

o button_default.xml

o button_warning.xml

o fane_indikator.xml

o kalender_delomraade_infoboble.xml

o kalender_full.xml

o kalender_normal.xml

o kalender_utilgjengelig.xml

o kalender_valgt.xml

o ramme.xml

layout

o aktivering.xml

o aktivering_liten.xml

o aktivering_spinner.xml

Side 32 av 103

o aktivering_stor.xml

o aktivering_xstor.xml

o bevis.xml

o bevis_liten.xml

o bevis_stor.xml

o bevis_xstor.xml

o hjelp.xml

o innlogging.xml

o kontakt.xml

o kortaktivering.xml

o kortaktivering_rad.xml

o kortaktivering_rad_liten.xml

o kortaktivering_rad_stor.xml

o kortaktivering_rad_xstor.xml

o kortinformasjon.xml

o kortinformasjon_liten.xml

o kortinformasjon_stor.xml

o kortinformasjon_xstor.xml

o om_inatur.xml

o utforte_aktiveringer.xml

o utforte_aktiveringer_rad.xml

o utforte_aktiveringer_rad_liten.xml

o utforte_aktiveringer_rad_stor.xml

o utforte_aktiveringer_rad_xstor.xml

layout-land

o aktivering.xml



o bevis.xml

o innlogging.xml


Side 33 av 103



layout-large

o aktivering.xml

o bevis.xml

o bevis_liten.xml

o bevis_stor.xml

o bevis_xstor.xml

o innlogging.xml









layout-small

o aktivering.xml

o bevis.xml

o bevis_liten.xml

o bevis_stor.xml

o bevis_xstor.xml

o innlogging.xml






o kortinformasjon_liten.xml

Side 34 av 103







layout-small-land

o bevis.xml




layout-xlarge

o aktivering.xml



o bevis.xml

o bevis_liten.xml

o bevis_stor.xml

o bevis_xstor.xml

o innlogging.xml











Side 35 av 103


menu

o meny.xml

o meny_aktivering.xml

o meny_kortinformasjon.xml

o meny_kortlister.xml

values

o arrays.xml

o colors.xml

o strings.xml

o styles.xml

o themes.xml

values-en

o arrays.xml

o strings.xml

xml

o innstillinger.xml

2.4 Teknisk beskrivelse av klassene I de påfølgende underkapitlene kommer en teknisk beskrivelse av oppbyggingen av

klassene. Rekkefølgen på beskrivelsene er organisert etter den logiske gangen i

applikasjonen, bortsett fra de to fragmentene, da de hører sammen i samme aktivitet.

Side 36 av 103

Figur 33: Klasseoversikt

2.4.1 Innlogging

Aktiviteten Innlogging består av et ImageView9 med Inaturs logo, to EditText10, ett for

brukernavn og ett for passord, ett TextView for feilmeldinger ved innlogging, én knapp for

innlogging og to TextView med hyperlenke til inatur.no. Lenkene dirigerer til sider hvor

man kan få tilsendt nytt passord og for å registrere seg.

2.4.2 Kortlister

Aktiviteten Kortlister inneholder ikke brukergrensesnitt i seg selv, men består av de to

fragmentene Kortaktivering.java og UtforteAktiveringer.java. Fragmentene er i stor grad

bygget opp på samme måte, med et ListView11 som inneholder tekst og en eller to knapper

9 Bildevisning i Android 10 Ett tekstfelt som brukeren kan skrive tekst inn i (Android Inc.). 11 En visningsgruppe som viser en liste med rullbare elementer. Se ordboken for mer detaljert forklaring.

Side 37 av 103

per element. Hvilket innhold som skal vises avhenger av hvilken fane man velger.

Kortaktivering viser alle kort som det er mulig å aktivere, mens UtforteAktiveringer viser

alle aktiveringer som er utført for frem i tid.

2.4.3 Kortaktivering

Kortaktivering er et fragment, som inneholder et ListView. ListViewet består av flere

TextView for hvert kjøpte kort. Ett felt for tilbudstittel (navn på område), ett felt for

korttittel (type kort), ett felt for gyldighet og et felt for navn på eier av kortet. I tillegg er det

en Aktiver-knapp som vil være synlig hvis gyldighetsdatoene er innenfor en tidsperiode på

14 dager frem i tid, inkludert dagens dato.

2.4.4 Utførte aktiveringer

Utførte aktiveringer er et fragment, og fragmentet består i likhet med Kortaktivering av et

ListView med flere TextView for hver utførte aktivering. I tillegg til informasjonsfeltene i

Kortaktivering, er det også et felt for valgt delområde for aktiveringen. Gyldigheten for en

aktivering vil alltid kun være én dato.

2.4.5 Aktivering

Det er i aktiviteten Aktivering at en aktivering blir gjennomført. Aktiviteten er komplekst

oppbygd med mange LinearLayout12, RelativeLayout13 og en del TextView som inneholder

informasjon til brukeren. I tillegg er det en spinner som inneholder alle delområdene for

det valgte kortet. Hvis det allerede er noen utførte aktiveringer på kortet vil det bli

opprettet ett eller flere views dynamisk for å vise disse aktiveringene. Deretter er det 14

LinearLayouter som vises i form av en kalender, og beskriver antall jegere/fiskere som har

aktivert kort for valgt delområde i forhold til trykkreguleringen. Til slutt er det et TextView

som kun vil være synlig dersom det er kommentarer knyttet til valgt delområde.

12 En oppdeling der de indre elementene er organisert i en enkelt kolonne eller rad (Android Inc., 2014). 13 En oppdeling der posisjonen til de indre elementene kan beskrives i forhold til hverandre (Android Inc.,

2014).

Side 38 av 103

2.4.6 Bevis

Hovedfunksjonen med aktiviteten Bevis er å fremvise gyldig bevis på utført aktivering ved

kontroll. Aktiviteten består av ett TextView med melding om at aktiveringen er gyldig.

Deretter påfølger flere TextView med informasjon om aktiveringen, samme informasjon

som vises i fanen Utførte Aktiveringer, i tillegg til telefonnummeret til personen og

kortnummer som aktiveringen er knyttet til.

2.4.7 Kortinformasjon

Aktiviteten Kortinformasjon består av flere TextView med kortinformasjon og informasjon

om eier av kortet. I tillegg til informasjonen som vises i Kortaktivering, vises også

kortnummer og telefonnummer til personen.

2.4.8 Hjelp

Aktiviteten Hjelp består kun av ett TextView med statisk tekst. Teksten er en kortfattet

veiledning for bruk av applikasjonen.

2.4.9 Kontakt

Aktiviteten Kontakt består kun av ett TextView med statisk tekst. Teksten inneholder

kontaktinformasjon til kunden.

2.4.10 Om Inatur

Aktiviteten OmInatur består kun av ett TextView med statisk tekst. Teksten inneholder en

generell beskrivelse av kunden.

2.4.11 Innstillinger

Aktiviteten Innstillinger består av et PreferenceFragment, det vil si en liste av innstillinger.

Disse innstillingene vil automatisk bli lagret i SharedPreferences14, og kan enkelt hentes ut

andre steder i applikasjonen.

14 Brukes til å lagre innstillinger for en applikasjon og vil bevares også når applikasjonen blir avsluttet.

Side 39 av 103

2.4.12 KortaktiveringArrayAdapter og UtforteAktiveringerArrayAdapter

De to klassene KortaktiveringArrayAdapter og UtforteAktiveringerArrayAdapter arver fra

klassen ArrayAdapter med type Kort. Disse to klassene fyller viewet til listene i de

respektive fragmentene Kortaktivering og UtforteAktiveringer.

2.4.13 DatabaseHaandterer

Klassen DatabaseHaandterer arver fra klassen SQLiteOpenHelper, og oppretter en

database med navn Inatur. Den har metoder for å sette inn, hente ut, endre og slette

nødvendige data. Databasen er av typen SQLite15, og inneholder tabellene «Kort»,

«Person», «Kortgyldighet», «Dato», «Delomraade» og «Aktivering».

Figur 34: Databasemodell

2.4.14 APIHaandterer

Interfacet APIHaandterer blir brukt for å kunne kommunisere med APIet til Inatur.

Annotations over metodene og deres parameter indikerer hvordan forespørslene vil bli

15 En åpen kildekode relasjonsdatabase. SQLite er innebygd i enhver Android-enhet.

Side 40 av 103

håndtert. APIHaandterer inneholder også konstanter for URLene som brukes i

applikasjonen.

2.4.15 Aktiveringsdata

Klassen Aktiveringsdata blir brukt for å kunne sende data til APIet for å utføre eller endre

en aktivering, og består av variablene «kjopId», «kortnummer», «telefonnummer»,

valgtOmrådeId» og «valgtDato». Disse variabelnavnene må være de samme som brukes i

APIet.

2.4.16 Innloggingsparametere

Klassen Aktiveringsdata blir brukt for å kunne sende data til APIet for å logge inn i

applikasjonen, og består av variablene «brukernavn» og «passord». Disse variabelnavnene

må være de samme som brukes i APIet.

2.4.17 DagsAktivering

Klassen DagsAktivering er et objekt som simulerer en utført aktivering, og består av

variablene «aktiveringsId», «dato» og «delomraade».

2.4.18 Delomraade

Klassen Delomraade er et objekt som simulerer et delområde, og består av variablene «id»,

«navn», «kommentar», «makstrykk», «dagstrykk» og «alleredeAktiverteDager».

2.4.19 Kort

Klassen Kort er et objekt som simulerer et jakt- eller fiskekort, og består av variablene

«kortnummer», «kjopID», «tilbudstittel», «korttittel», «gyldighet», «aktiverteDager» og

«person».

2.4.20 Person

Klassen Person er et objekt som simulerer en jeger eller fisker, og består av variablene

«navn» og «telefonnummer».

Side 41 av 103

2.4.21 SettPeriodiskService

Klassen SettPeriodiskService arver klassen Service, og oppretter en AlarmManager16 som

starter SjekkUtlopteKortService hvert døgn ved midnatt.

2.4.22 SjekkUtlopteKortService

Klassen SjekkUtlopteKortService sjekker om det er lagret noen kort og aktiveringer i

databasen som ikke lenger er gyldig, og sletter disse.

2.4.23 StartServiceBroadcastReceiver

Klassen StartServiceBroadcastReceiver blir startet med kommandoen

«RECEIVE_BOOT_COMPLETED», det vil si at den starter når telefonen blir skrudd på.

Klassen starter klassen SettPeriodiskService.

16 En klasse som gir tilgang til systemalarmtjenester.

Side 42 av 103

3 Valg og utfordringer

I dette kapittelet er det beskrevet hvilke valg vi har tatt underveis i prosjektet, og hvilke

utfordringer vi har møtt på. Vi tar også for oss kravspesifikasjonens rolle, og hvordan vi har

løst de krav som har blitt satt.

3.1 AndroidAnnotations I begynnelsen av prosjektet ble det planlagt å bruke rammeverket AndroidAnnotations17.

Dette skulle gjøre kodingen mer effektiv, og vi var spente på å prøve ut noe nytt. Vi brukte

tid på å sette oss inn i dette, men det fungerte ikke som det skulle. Blant annet var vi nødt

til å gå inn i prosjektstrukturen (Project Structure) for å fjerne en mappe fra Source hver

gang prosjektet skulle bygges, kjøres eller debugges. Vi hadde også problemer med

rammeverket i forbindelse med testing ved hjelp av JUnit18 og Robolectric19. Problemene

løste seg da vi fortsatte kodingen uten AndroidAnnotations.

3.2 JDK 7 fremfor JDK 6 I planleggingsfasen valgte vi å programmere i JDK 6 grunnet kompabilitetsproblemer med

AndroidAnnotations, men siden vi besluttet å gå vekk fra AndroidAnnotations ble ikke

lenger dette noe hinder. Vi valgte derfor heller JDK 7.

3.3 Retrofit fremfor Jersey I utgangspunktet hadde vi planer om å benytte oss av Jersey for API-kall. Etter litt

diskusjon valgte vi heller å benytte Retrofit20, fordi det da ikke er nødvendig å bruke

klassen AsyncTask21 og dens metoder. Dette medførte færre kodelinjer, og virket som et

bedre rammeverk.

17 Et rammeverk med åpen kildekode for å gjøre Android utvikling raskere. 18 Et rammeverk for enhetstesting. 19 Et rammeverk for enhetstesting. 20 En REST-klient for Android og Java. 21 Gjør riktig og enkel bruk av UI tråden.

Side 43 av 103

3.4 IntelliJ fremfor Android Studio Vi ønsket å benytte oss av et annet utviklingsverktøy enn vi tidligere hadde benyttet.

Årsaken til dette var at det kan være nyttig å kjenne til flere forskjellige verktøy i

arbeidslivet. Siden Android Studio er Androids nye storsatsning ønsket vi å bruke dette,

men da dette er en betaversjon, medførte det problemer ved bruk av de rammeverkene vi

ønsket. Av den grunn valgte vi heller å bruke IntelliJ, siden Android Studio er basert på

dette.

3.5 Behandling av dato og tid Vi valgte midtveis i prosjektet å benytte oss av det eksterne biblioteket JodaTime for

behandling av datoer, i stedet for å bruke Javas egen datatype Calendar. Årsaken til dette

var at vi har hørt mye positivt om JodaTime tidligere og at det finnes mange nyttige

metoder som forenkler koden.

3.6 Service og BroadcastReceiver I applikasjonen blir det ikke bevart historikk. Dette er kundens eget ønske, og vi har derfor

tatt hensyn til dette når vi har programmert. Ved oppstart av telefonen blir

StartServiceBroadcastReceiver kjørt. Denne starter SettPeriodiskService, som ved hjelp av

PendingIntent22 setter i gang SjekkUtlopteKortService, som blir kjørt én gang om dagen,

ved midnatt. Hvis telefonen har vært avslått ved midnatt, blir denne Servicen kjørt med en

gang telefonen blir skrudd på, og deretter kjørt igjen neste midnatt. Da en

BroadcastReceiver ikke kan programmeres til å kjøre når en applikasjon blir installert, har

vi også valgt at SettPeriodiskService starter også ved innlogging.

3.7 Utfordringer med APIet Underveis i prosjektet støtte vi på utfordringer i forhold til leveranser fra kunden. Dette

handlet i hovedsak om APIet. Ved oppstart av prosjektet var ikke dette ferdig

implementert, og vi var nødt til å vente litt før vi fikk tatt det i bruk. Da vi fikk klarsignal om

22 Ved å gi en PendingIntent til en annen applikasjon, gir du retten til å utføre operasjoner med samme

rettigheter som den selv.

Side 44 av 103

at dette var klart, var det fortsatt noen nødvendige deler som manglet. Manglene gjorde at

vi i en liten periode ikke fikk utviklet i den farten vi hadde planlagt. Vi var derfor nødt til å

jobbe med andre mindre viktige ting, som for eksempel å finpusse på GUI. Dette var også

en utfordring, da vi ikke var helt sikre på hvilken informasjon vi skulle få fra APIet, og

dermed hva som skulle vises på skjermen. I tillegg hadde vi tidvis problemer med å tolke

noen av responsene fra API-kallene, da strukturene var noe ulogisk. Dette tok vi opp med

oppdragsgiver, og det tok noen uker før vi fikk oppklaring, noe som forsinket arbeidet vårt

med prosjektet. Selv om vi møtte på disse utfordringene, klarte vi å innhente dette ved å

endre prioriteringer underveis i prosjektet.

Begrensinger i APIet forårsaket dessuten at mye av tilleggsfunksjonaliteten som kunden

ønsket, ikke var mulig å implementere. APIet er skrevet av oppdragsgiver for kunden i

forbindelse med prosjektet, og årsaken til begrensingene har derfor handlet om kostnader

knyttet til utvidelse av APIet.

3.7.1 Nettverkstrafikk

Applikasjonen sender og mottar data ved API-kall, og vi ønsket at det skulle være så lite

nettverkstrafikk som mulig. Årsaken til dette er at brukeren sannsynligvis som oftest er ute

i marka med dårlig nettverksforbindelse ved bruk av applikasjonen. Derfor blir det kun

brukt API-kall der det er nødvendig, og all unødvendig nettverkstrafikk blir unngått. For

oppdatering av innhold i applikasjonen har vi lagt inn en oppdaterings-knapp i menylinjen

der det er naturlig, slik at brukeren aktivt må ta dette valget hvis det er ønskelig.

Ved disse hendelsene brukes det nettverkstrafikk for å sende og motta data:

Ved innlogging

Henting av kort som kan aktiveres

Henting av utførte aktiveringer

Henting av data for utførsel av en aktivering

Utføring av en aktivering for et spesifikt kort

Sletting/annullering av en aktivering

Endring av en aktivering, altså å skifte område for en dato

Side 45 av 103

Ved noen av responsene opplever vi at det mottas unødvendig mye data. For eksempel

mottas alle utførte aktiveringer tilbake i tid, inkludert utgåtte aktiveringer. Kunden ønsket

ikke å bevare historikk, og derfor mener vi det ikke er nødvendig å få informasjon om alle

utgåtte aktiveringer. Dette kunne redusert mengden data som brukeren må laste inn via

internett.

Figur 35: Utdrag av JSON-array ved henting av utførte aktiveringer

Et annet eksempel på unødvendig informasjon i responsen er ved henting av data for

utførsel av aktivering. Her får vi inn informasjon om alle delområdene for kortet hver

eneste gang. Disse delområdene endres veldig sjeldent, og derfor mener vi denne

informasjonen burde vært hentet på en annen måte. For eksempel kunne informasjon om

[

{

"id":"533177b4e4b01a06ae438c7a",

"kjopId":"532fd17ce4b0e531d09df934",

"tilbudstittel":"Småviltjakt i Nordland –

Nordlandskortet",

"korttittel":"Nordlands- og

bostedskommunekort

- sesong",

"kortnummer":"1103630",

"dato":"26.03.2014",

"område":"Beiarn Vest",

"kvitteringslenke":"https://inatur-dev.s3-eu-

west-1.amazonaws.com/kvittering/521c471fe4b08

4b6bd0d4ae1/533177d0e4b01a06ae438c7c.pdf"

}

.

.

.

]

Side 46 av 103

alle delområder blitt hentet samtidig som kortene blir hentet fra APIet, slik at det ble gjort

mer sjeldent. Dette er noe kunden også var enig i, men de ønsket ikke å endre det grunnet

kostnader ved omskriving. I Figur 36 vises et utdrag av respons som mottas ved henting av

data for aktivering. I dette tilfellet vil det være 62 JSON-objekter med delområder, her vist

med tre objekter

Figur 36: Utdrag av JSON-array som mottas ved henting av data for aktivering.

[

.

.

.

"områder":[

{

"id":"s185",

"navn":"Balvatnet",

"kommentar":"stengt for jakt fra og med

15. april."

},

{

"id":"s196",

"navn":"Beiarn Vest",

"kommentar":"Området fredes for

storfugljakt fra 1. oktober"

},

{

"id":"s104",

"navn":"Brønn 1"

},

.

.

.

]

.

.

.

]

Side 47 av 103

3.8 AccountManager AccountManager er en klasse som gir tilgang til et sentralisert register av brukerens

online-kontoer på telefonen. Vi ønsket å bruke dette for håndtering av cookien som mottas

ved innlogging. Ved å benytte dette kunne vi også ha lagret brukernavn og passord på en

sikker måte, slik at brukeren ikke hadde vært nødt til å logge inn hver 14 dag.

Vi satte oss inn i hvordan AccountManager fungerer og leste gjennom mange eksempler,

men det er en kompleks klasse, noe vi også hadde blitt advart om på forhånd.

3.9 Sikkerhet Sikkerhet er et viktig aspekt når man behandler sensitiv informasjon. I kapitlene som

følger blir noen av våre utfordringer rundt dette beskrevet.

3.9.1 Bevaring av cookie

Ved gjennomført pålogging er det nødvendig å ta vare på en cookie. Disse blir brukt i alle

fremtidige API-kall for å identifisere brukeren. Cookien inneholder en token23 som er

gyldig i 14 dager fra den er utstedt. Cookien skal i utgangspunktet håndteres på samme

måte som brukernavn og passord, av sikkerhetsmessige hensyn, da den identifiserer en

bruker. Derfor var vårt ønske å bruke AccountManager. Vi ble på forhånd advart om at

dette var komplekst å sette seg inn i. Etter utallige timer med lesing av dokumentasjon og

eksempler, og forsøk på implementasjon uten å lykkes, besluttet vi i samråd med veileder

hos oppdragsgiver at vi ikke skulle bruke mer tid på dette. Vi bestemte derfor at cookien

heller blir lagret i SharedPreferences. Konsekvensen av dette er at det vil være mulig å

hente ut cookien hvis enheten blir rootet24. Allikevel vil man ikke få tilgang til brukernavn

og passord, da dette ikke blir lagret i cookien. Man vil derfor kun få brukt denne cookien i

applikasjonen, og med tilgang til denne cookien kan man ikke gjøre noen handlinger som

ikke kan endres senere. Dessuten blir cookien i SharedPreferences slettet ved utlogging

eller når den har utløpt.

23 Data som brukes i nettverkskommunikasjon (ofte over HTTP) til å identifisere en session, en serie av

relaterte meldingsutvekslinger. 24 Å roote vil si å låse opp enheten, slik at man kan gjøre endringer i software.

Side 48 av 103

3.9.2 JSON escaping

JSON responser fra API-kall blir escapet med prefikset «{}&&». Årsaken til dette er å

beskytte mot JSON hijacking25. Retrofit kan konvertere JSON-objekter til egendefinerte

objekter, men på grunn av JSON escaping vil ikke dette fungere i vår applikasjon. Derfor må

vi konvertere JSON-objektene til egne objekter på en annen måte. Dette har vi valgt å gjøre

ved hjelp av responsen etter å ha fjernet prefikset.

3.10 Retningslinjer for design Vi har i stor grad fulgt Googles retningslinjer for

design av Android applikasjoner. Dette ønsket vi å

gjøre for at brukerne skulle få en følelse av en

fullverdig applikasjon som er laget for Android. I

begynnelsen satte vi inn knapper i listene som viser kort og aktiveringer for at det skulle

ligne på nettsiden til kunden. Etter hvert kom vi på at dette ikke var særlig Android-

vennlig, og tok opp med kunden at vi ønsket å fjerne knappene til fordel for funksjoner ved

trykk på elementene. Dette ville ikke kunden, da de mente det var mer brukervennlig med

knapper som var synlig. Det ble begrunnet med at mange av brukerne muligens ikke

kjenner godt til typiske Android funksjoner, og dermed ville det blitt vanskelig å forstå

applikasjonen. Derfor beholdt vi disse knappene. I tillegg la vi til funksjoner for klikk på

elementene i listen, slik at det skal fungere intuitivt for brukere som er kjent med Androids

brukermønster.

I menylinjen har vi valgt å bruke Androids standardikoner der det ikke har vært fare for

misforståelser. Vi har benyttet ikoner da det er mer riktig etter Googles retningslinjer, og i

tillegg sparer det plass på skjermen. Allikevel har vi valgt å bruke tekst i menylinjen for

aktivering, da vi ikke fant et ikon som kunne brukes der vi var sikre på at brukere ville

forstå.

25 Når noen som i utgangspunktet ikke skal ha tilgang til JSON dokumentet får tak i den informasjonen. Se

ordboken for mer detaljert forklaring.

Figur 37: Knapper i listen

Side 49 av 103

Figur 38: Menylinje med ikoner

Figur 39: Menylinje med tekst

Bruk av Toast for å gi informasjon til bruker er også brukt der det er hensiktsmessig. Dette

kan man lese mer om i kapittel 2.2.2. Toast er mye brukt i applikasjoner for Android.

3.11 Kravspesifikasjonens rolle Kravspesifikasjonen er en beskrivelse av hvordan et datasystem skal fungere og hva slags

krav kunden har til systemet. Kravspesifikasjonen har vært en sentral rolle i vårt prosjekt,

og det er der rammene for arbeidet ble definert. Vi har underveis brukt denne som en

rettesnor for å holde fokus på hva kunden ønsket av det ferdige prosjektet.

I de påfølgende underkapitlene tar vi for oss språk for koding, kravene til

tilleggsfunksjonalitet, design og testdreven utvikling som er beskrevet i

kravspesifikasjonen.

3.11.1 Norsk kode

Oppgavens krav har vært godt definert, men kunden har samtidig gitt oss frie tøyler til

hvordan vi skulle oppfylle disse kravene. Ett krav som var helt klart var at koden i

applikasjonen skulle være på norsk. Dette har iblant vært krevende, da vi tidligere

hovedsakelig har skrevet kode på engelsk. Det har vært utfordrende å vurdere hvor det er

naturlig å oversette Java- og Android-spesifikke komponenter til norske ord. Derfor har vi

noen steder valgt å bruke de ord og uttrykk det er vanlig å bruke, som for eksempel

sharedPreferences.

Side 50 av 103

3.11.2 Tilleggsfunksjonalitet

Kunden hadde noen ønsker om tilleggsfunksjonalitet som skulle implementeres hvis det

var tid og gjennomførbart. I tillegg kom vi med flere forslag som kunden godkjente. Vi har

implementert flere av funksjonene som tillegg, men tidsrammene for dette prosjektet satte

en grense for hvor mye som var gjennomførbart. Noen av ønskene om

tilleggsfunksjonalitet ble også trukket tilbake av kunden, da det ville medført tung lasting

av data. Selv om noe av tilleggsfunksjonaliteten ikke er implementert er produktet en

fullverdig applikasjon. Nedenfor er kommentarer til gjennomført tilleggsfunksjonalitet.

3.11.2.1 Synliggjøring av manglende fangstrapport

Da det ikke var mulig å hente informasjon om manglende fangstrapportering før en

aktivering forsøkes gjennomført, har vi valgt å gjøre slik at det vises en dialogboks på

skjermen der bruker blir bedt om å levere fangstrapport hvis dette er nødvendig.

3.11.2.2 Bytte språk til engelsk

Funksjonalitet er lagt til, og brukeren vil få applikasjonen på engelsk hvis språk for enheten

er valgt til engelsk.

3.11.2.3 Forstørre skriften

Funksjonalitet for å forstørre og forminske teksten er lagt til, og brukeren kan endre

skriftstørrelse i applikasjonens innstillinger.

3.11.3 Designkrav

Kundes ønske har hele veien vært at brukeropplevelsen skal være mest mulig lik deres

egen nettside, slik at applikasjonen skal fremstå som en del av et større system. Vi

etterspurte derfor kundes fargepalett, og bestemte oss for å kun benytte disse fargene i

den grad det var mulig. Vi har også forsøkt så godt det lar seg gjøre å bygge opp

applikasjonen med komponenter og ord som brukeren kjenner igjen fra nettsiden.

3.11.3.1 Faner

Vi ønsket at brukeren skulle kunne velge mellom visning av kort og aktiveringer ved hjelp

av faner, slik brukeren navigerer på kundens nettside. En annen grunn til at vi ønsket

navigasjon ved hjelp av faner, var at dette er noe som gjør det enklere å navigere mellom

skjermbilder. Det var viktig for oss å la brukeren få følelsen av at applikasjonen var en

Side 51 av 103

utvidelse av nettsiden, og derfor lagde vi egen styling på fanene som en del av det

helhetlige temaet. Dette var helt nytt for oss, da vi ikke tidligere har benyttet faner ved

programmering av apper, og det innebar at vi måtte sette oss inn i oppbyggingen av faner.

Figur 40: Fanevalg på kundens nettside

Figur 41: Fanevalg i applikasjonen

Figur 42: Androids standard fane, blå strek indikerer gjeldende fane

3.11.3.2 Bevis

Beviset er en viktig del av applikasjonen, da det er dette de må bære med seg ut i naturen.

Derfor har vi forsøkt å gjøre beviset i applikasjonen identisk med beviset som blir utstedt

ved aktivering på nett. Vi har valgt å gjøre noen små endringer i ordvalg på beviset. Der det

på beviset fra nettsiden står «Område» har vi valgt å presisere teksten til «Delområde», da

det er dette ordet kunden har brukt i definisjoner til oss. Vi har også erstattet «Kort er

gyldig for:» til «Gyldig:», fordi beviset kun gjelder for den enkelte aktiveringen, og ikke for

selve kortet.

Side 52 av 103

Figur 43: Bevis utstedt fra nettsiden

Figur 44: Bevis utstedt fra applikasjonen

3.11.3.3 Visning av kalender

Kunden ønsket at brukerne enklest mulig skulle kunne aktivere for 14 dager samtidig.

Dette ønsket de fremvist ved hjelp av en tabell eller annet som lignet en kalender. Vi fikk se

både hvordan de har det i dag og hvordan de i fremtiden forestiller seg fremstillingen på

nettsiden. Vi gikk for en løsning der det vises en kalender på 14 dager fra i dag, der

datorutene som er gyldig for aktivering er hvite. De dagene det ikke er mulig å aktivere for

er grå. Øverst i høyre hjørnet må man velge delområde fra en spinner. Vi valgte å bare vise

kalender for ett delområde av gangen, da vi synes det ville blitt for mye informasjon på en

liten skjerm hvis vi skulle vist kalender for alle delområdene samtidig, slik som kundens

nye løsning for web. Det skal her sies at det kan være opp mot 64 delområder som det kan

velges mellom.

Figur 45: Visning av kalender p.t.

Side 53 av 103

Figur 46: Forslag til visning av kalender i ny løsning

Figur 47: Den endelige kalenderen med valg av delområde på toppen

3.11.3.4 Status i kalender ved aktivering av kort

Kunden ønsket at vi skulle bruke de samme statusene i kalenderen ved aktivering av kort

som de har gjort på web. Dette ønsket har vi dermed fulgt. Fra ønskene deres var det i

utgangspunktet spesifisert at status «Gyldig» skulle være grå og status «Ikke gyldig» skulle

være hvit, men disse to fargene er byttet om hos kunden i den nye planlagte webløsningen,

og derfor valgte vi også å gjøre slik de har planlagt.

Statusene er som følger:

Side 54 av 103

Kunden har gyldig jaktkort og dagen lar seg aktivere

Figur 48: Status «Gyldig» fra kunden

Figur 49: Status «Gyldig» i applikasjonen

Ikke gyldig jaktkort for denne dagen – inaktiv og lar seg ikke aktivere

Figur 50: Status «Ikke gyldig» fra kunden

Figur 51: Status «Ikke gyldig» i applikasjonen

Fullt – lar seg ikke aktivere

Figur 52: Status «Fullt» fra kunden

Figur 53: Status «Fullt» i applikasjonen

Stengt – lar seg ikke aktivere

Figur 54: Status «Stengt» fra kunden

Figur 55: Status «Stengt» i applikasjonen

Valgt dag/aktivert dag

1

1 av 10

Side 55 av 103

Figur 56: Status «Valgt dag» fra kunden

Figur 57: Status «Valgt dag» i applikasjonen

3.11.4 Lansering i Google Play

Oppdragsgiver ønsket ved oppstart av prosjektet at

vi skulle lansere applikasjonen i Google Play så raskt

som mulig. Vi satte oss derfor mål om å legge ut

applikasjonen for beta-testing 28.02.14. På grunn av

problemer med leveranse av APIet, som er

beskrevet i kapittel 3.7, var det ikke mulig å

overholde denne fristen. Første versjon av

applikasjonen var dermed klar 17.03.14. Vi ønsket

da at noen utvalgte sluttbrukere skulle være med å beta-teste applikasjonen. Da APIet kun

var tilknyttet testmiljøet, var det ikke mulig å la sluttbrukere delta i testingen. Vi bestemte

derfor at vi skulle lansere den som alfa-testing, og la kunden få teste applikasjonen.

Deretter lastet vi opp ny versjon disse datoene:

04.04.14

15.04.14

16.04.15

07.05.14

Den nyeste versjonen var etter planen meningen skulle lanseres for alle sluttbrukerne.

Dette var heller ikke mulig da APIet fortsatt kun er knyttet til kundens testmiljø.

3.11.5 Testdreven utvikling

Vi valgte i utgangspunktet å benytte testdreven utvikling, da dette brukes mye i

arbeidslivet. Vi brukte mye tid på å sette oss inn i hvordan dette fungerte, og på å

implementere det i applikasjonen. Det viste seg at dette var meget krevende, spesielt i

Figur 58: Google Play logo

Side 56 av 103

sammenheng med Android utvikling, og etter råd fra BEKK-veileder valgte vi å gå bort fra

dette. Vi ønsket heller å ha fullt fokus på utviklingen av selve applikasjonen.

Side 57 av 103

4 Prosessbeskrivelse

Under dette kapittelet vil prosessen mot det ferdige produktet bli beskrevet. Først har vi

tatt for oss hvordan det var å sette seg inn i Inatur som domene. Deretter er det

underkapitler som tar for seg planleggingsfasen og implementasjonsfasen. Videre følger

underkapitler der det er beskrevet arbeidsforhold og kommunikasjon, både innad i

gruppen og med oppdragsgiver og kunden. Til slutt har vi tatt for oss smidig utvikling og

beskrevet verktøyene vi har benyttet i prosessen og utviklingsfasen.

4.1 Inatur som domene I oppstarten av prosjektet var det mange nye ord og uttrykk som var nye for oss med tanke

på jakt og fiske. Ingen av oss er aktive innenfor disse feltene, og har dermed ikke brukt

inatur.no. Vi fikk derfor både en skriftlig og muntlig introduksjon til det viktigste innenfor

domenet. Allikevel var det noen ting vi ikke fikk klart definert, og vi tok derfor egne

antagelser som vi følte var logisk. Dette var i stor grad knyttet til hvordan kort og

aktiveringer henger sammen. For eksempel snakket vi oss imellom om aktiverte og ikke-

aktiverte kort. Dette gjorde at vi noen steder i programmet forvirret oss selv, og

programmerte på en måte som ble mer komplisert enn det som var nødvendig.

Misforståelsene ble lagt merke til av kunden i møter og gjennom skisser av applikasjonen

som ble sendt.

4.2 Planleggingsfasen Planleggingsfasen ble innledet med innsamling av informasjon og krav fra kunden. Dette

ble brukt til å lage UML-diagrammer og skisser for design av applikasjonen. I de neste

underkapitlene er dette beskrevet med tekst og figurer.

4.2.1 UML

I de påfølgende underkapitlene vises UML-diagrammene som ble tegnet i oppstarten av

prosjektet. Diagrammene er justert underveis. Tilleggsfunksjonalitet er i disse

diagrammene utelatt.

Side 58 av 103

4.2.1.1 Use case diagram

Use case diagrammet reflekterer kundens krav til funksjonalitet.

Figur 59: Use case diagram

Side 59 av 103

4.2.1.2 Aktivitetsdiagram

Aktivitetsdiagrammet reflekterer brukers interaksjon med applikasjonen.

Figur 60: Aktivitetsdiagram

Side 60 av 103

4.2.1.3 Tilstandsdiagram

Tilstandsdiagrammet reflekterer tilstandene applikasjonen kan befinne seg i.

Figur 61: Tilstandsdiagram

4.2.2 Design

Det forutsettes i dette kapittelet at kapittel 3.11.3, som omhandler design i samsvar med

kravene til kunden, er lest.

Vi startet prosessen mot det endelige designet med å lage skisser. Skissene ble først tegnet

på papir, og deretter tegnet inn på pc. Deretter utarbeidet vi disse med tanke på farger som

harmonerte og passet til kravene til kunden.

Da disse skissene var ferdige sendte vi de til kunden for godkjenning. Kunden

kommenterte skissene, og da kom det frem at vi hadde misforstått noe av logikken. Dette

kan også leses om i kapittel 4.1. Tilbakemeldingene medførte endringer, som for eksempel

Side 61 av 103

at vi valgte å gå bort fra skjermbildet i Figur 68 og Figur 77. Informasjonen her ble lik

informasjonen i Figur 69 og Figur 78, med unntak av tekstfeltet med blant annet regler og

kart over området. Dette fikk vi uansett ikke med fra APIet.

Kunden ønsket også at vi ikke skulle skrive «Ikke

aktivert» på Figur 64 og Figur 72, da deler av kortet kan

være aktivert. Vi gikk dermed bort fra dette i det endelige

designet. Da kortinformasjonen for et kort var svært lik beviset, valgte vi å legge inn en

tekst om at kortinformasjon ikke er gyldig som bevis.

Vi valgte også å droppe eget skjermbilde for valg av delområde, Figur 65 og Figur 73.

Grunnen til at vi ønsket et eget skjermbilde for dette var at kunden fortalte oss at for noen

områder kunne det være veldig mange delområder. Vi tenkte oss derfor at det kunne være

mulig å få delområdene sortert på kommune, og at valg av delområde kunne velges slik

som i skissene. Dette var ikke mulig, og derfor bestemte vi oss for å droppe dette

skjermbildet for å minske antall klikk for brukeren.

4.2.2.1 Første utkast av skisser

Nedenfor er skissene som ble tegnet digitalt. Disse er identiske til skissene tegnet på papir.

Figur 62: Tekst i Kortinformasjon

Side 62 av 103


Figur 64: Kortinformasjon ikke aktivert kort

Figur 65: Velg delområde

Figur 66: Velg dato

Side 63 av 103


Figur 68: Kortinformasjon for aktivert kort

Figur 69: Bevis

Side 64 av 103

4.2.2.2 Andre utkast av skisser

Nedenfor er skissene som er tegnet digitalt med farger. Det er noen endringer fra første

utkast av skissene, men mye av designet er bevart.

Figur 70: Innlogging


Side 65 av 103

Figur 72: Kortinformasjon ikke aktivert kort

Figur 73: Velg delområde

Figur 74: Velg dato

Figur 75: Bekreft aktivering

Side 66 av 103


Figur 77: Kortinformasjon aktivert kort

Figur 78: Bevis

Side 67 av 103

4.3 Implementasjonsfasen Ved oppstarten av implementasjonsfasen bestemte vi oss for å fordele oppgaver ved hjelp

av use casene vi hadde fått for prosjektet. Da vi var usikre på hvor lang tid de forskjellige

oppgavene ville ta, ble vi enige om å jobbe med hvert vårt use case frem til vi var ferdig, og

deretter påbegynne et nytt. De ganger vi møtte på problemer vi ikke klarte å løse på

egenhånd bidro hele gruppen, slik at progresjonen i prosjektet ble opprettholdt. Vi erfarte

at noen av oppgavene var mer krevende enn andre, men dette løste vi på en god måte.

4.4 Arbeidsforhold Vi har i all hovedsak jobbet med prosjektet på grupperom på Høgskolen i Oslo og Akershus,

Pilestredet 35. Dette har i blant ført til problematikk, da det er stor pågang på

grupperommene ved skolen. Derfor har vi også i blant møttes hjemme hos et av

gruppemedlemmene, der det er god plass og rolige omgivelser.

I planleggingsfasen fordelte vi arbeid på alle gruppemedlemmene, slik at det skulle være

mulig å arbeide på egenhånd når det var behov for dette. Årsaken til dette er at vi hele

veien har vært klar over at det i blant ville bli utfordringer med å arbeide sammen grunnet

ulike fag ved siden av prosjektet. Når vi ikke arbeidet sammen hadde vi kontakt med

hverandre over telefon og Facebook. Hvis vi støtte på større utfordringer eller hadde behov

for diskusjon avtalte vi å møtes for å samarbeide og komme frem til løsninger.

4.4.1 Prosjektdagbok

Vi hadde i utgangspunktet en prosjektdagbok der vi noterte hvem som gjorde hva på

hvilket tidspunkt. Vi så etter hvert at dette var unødvendig, da vi fikk god oversikt over

progresjonen gjennom Git-commit kommentarene. Vi var nøye fra starten av med å tilføye

gode beskrivelser ved hver commit.

4.5 Kommunikasjon I dette kapittelet blir kommunikasjon i gruppen, med kunden og med oppdragsgiver

beskrevet.

Side 68 av 103

4.5.1 Kommunikasjon i gruppen

Når vi ikke har arbeidet sammen har vi kommunisert ved hjelp av telefon og chat-funksjon

på Facebook. Ved å ha brukt chat-funksjon har vi hatt mulighet til å gå tilbake til tidligere

samtaler hvis det har vært uenighet om hva som har blitt bestemt. Kommunikasjonen i

gruppen har vært god.

4.5.2 Kommunikasjon med kunden

Kunden er plassert i Namsos, og på grunn av demografiske avstander har vi ikke hatt

mulighet til noen personlige møter. Kommunikasjonen har derfor foregått på e-post,

telefon og Skype. I oppstarten av prosjektet hadde vi et Skype-møte hvor kunden ved hjelp

av skjermdeling gikk igjennom funksjonalitet på nettsiden deres. Deretter avtalte vi andre

møter ved behov, der vi har diskutert viktige avgjørelser. Sporadiske e-poster har blitt

brukt ved små avgjørelser. Erfaringsmessig har Skype-møtene fungert best, da det er

mindre fare for misforståelser enn ved e-post kommunikasjon.

4.5.3 Kommunikasjon med oppdragsgiver

Ved oppstart av hver sprint har vi avholdt møte med vår veileder hos oppdragsgiver. Her

har vi vist frem hva som har blitt gjort i den siste sprinten, i tillegg diskutert faglige

utfordringer. Veileder har også bidratt til kommunikasjon med kunden og andre ansatte

hos oppdragsgiver ved behov for raske avklaringer hvor vi ikke har nådd frem.

I tillegg er det ansatte hos oppdragsgiver som har utviklet APIet som vi har benyttet oss av.

På grunn av utfordringer vi har hatt med APIet, har det også vært en god del e-post-

korrespondanse for å få klarhet i usikkerheter, og for å få ordnet opp i feil vi har oppdaget.

4.6 Smidig utvikling Ved beslutning om hvilken utviklingsmetode vi skulle bruke, falt valget fort på den smidige

utviklingsmetoden Scrum. Smidige utviklingsmetoder benyttes i dag for utviklingen av de

fleste IT-systemer i Norge (Sintef, 2014). Scrum brukes også av oppdragsgiver, noe som

var en fordel da vår veileder hadde god erfaring med denne metoden.

Side 69 av 103

Scrum baserer seg på iterativ og inkrementell prosess, der løsningen utvikles gjennom

iterasjoner på 1-3 uker. Her er det fokus på rask og fleksibel respons på endring underveis

i hele prosjektet. Prosjektdeltakerne jobber i selvorganiserende team uten en tradisjonell

leder, men med en Scrum Master. Denne personen skal fungere som en buffer mellom

teamet og eventuelle forstyrrende faktorer, og han skal sikre at utviklingsprosessen går

som planlagt (Wikipedia, 2014).

Figur 79: Scrum prosessen

Vi har hatt noe erfaring med Scrum fra tidligere skoleprosjekter, men følte ikke at vi hadde

god kjennskap til dette. Smidig utvikling har fungert godt for vårt prosjekt, og vi har fått

verdifull erfaring med en metode som brukes mye i næringslivet.

I teamet vårt har Charlotte vært Scrum Master, men denne rollen har vært lite synlig da vi

ikke har hatt daily standup, eller andre faktorer som har krevd en Scrum Masters rolle. Da

vi kun har vært tre personer i gruppen, har vi til enhver tid vært oppdatert på hverandres

progresjon, og har hatt god kommunikasjon gjennom hele prosjektet. Dette var årsaken til

at vi ikke valgte å ha daily standup.

4.7 Verktøy I underkapitlene nedenfor er det beskrevet hvilke verktøy vi har benyttet under prosjektet.

Side 70 av 103

4.7.1 Prosessverktøy

Nedenfor er det beskrevet hvilke verktøy vi har benyttet i tilknytning til prosjektet.

4.7.1.1 Git

Git er et versjonskontrollsystem26 som vi var kjent med

fra tidligere gjennom skoleoppgaver. Git har egne

kommandoer, pull27 og push28, for synkronisering med

andre repositorier. Dette muliggjør alle-til-alle-

synkronisering (ikke bare alle-til-én, som i CVS og SVN).

Dessuten, uten implisitt synkronisering trenger man for

eksempel ikke å være koblet til nettverk hele tiden for å

kunne jobbe. Alt innhold i et Git-repositorium er indeksert

med sha1-sum. I tilfelle bitfeil i lagring eller overføring, kan

man være rimelig sikker på at det vil oppdages. Fordi sjekksummen regnes for å være

kryptografisk sikker, kan man stole på at ikke uvedkomne kan ha endret innholdet uten at

dette også vil oppdages (Wikipedia, 2013).

Kunden ga oss tilgang til et privat repositorium som vi skulle benytte oss av. Ved hjelp av

GitHub, som er et web-basert hostingsystem for Git-prosjekter, holdt vi oversikt over hvem

som hadde gjort hva til enhver tid. Ved commits29 skriver man inn en beskrivelse av hva

som er gjort i siste endring, slik at alle kan ha oversikt over hva de andre hadde gjort.

4.7.1.2 Trello

Som prosjekthåndteringsverktøy har

vi brukt Trello. Dette er et web-

basert verktøy som opprinnelig er

ment for utviklingsmetoden Kanban.

Vi valgte å benytte dette selv om vi

26 Programvare som kan holde orden på de forskjellige versjonene av en eller flere datafiler. 27 En git-kommando for å hente siste versjon av prosjektet. 28 En git-kommando for å laste opp siste versjon av prosjektet. 29 En git-kommando som klargjør de valgte delene av prosjektet for push.

Figur 80: Github logo

Figur 81: Trello logo

Side 71 av 103

har brukt Scrum som utviklingsmetode, fordi det er en enkel og oversiktlig «drag-and-

drop» applikasjon, som også egner seg godt til Scrum. Her presenteres prosjektet som en

tavle bestående av lister med oppgaver. Når en ny oppgave opprettes plasseres denne i

listen lengst til venstre og vil bli flyttet fra liste til liste mot høyre til den er ferdig

gjennomført. Oppgaver kan markeres med hvilke brukere som skal løse den aktuelle

oppgaven, slik at man får god oversikt over hvem som skal gjøre hva.

4.7.1.3 Microsoft Word

Vi har brukt Word til all dokumentasjon i prosjektet. Dette er et tekstbehandlingsprogram

som gjør det enkelt å redigere tekst og plassere bilder.

4.7.1.4 Dropbox

Dropbox er en skytjeneste som lar brukere dele data med hverandre. Underveis i

prosjektet har vi benyttet Dropbox til å dele filer i form av dokumenter og bilder.

4.7.1.5 Facebook

Facebook er et sosialt nettverk som tilbyr en chat-funksjon som gjør det enkelt og effektivt

å sende meldinger med hverandre gratis via internett. Dette har vi brukt til å avtale når vi

skal møtes og i tillegg når det har vært behov for å diskutere detaljer rundt prosjektet, når

vi ikke har sittet sammen og jobbet.

4.7.1.6 Skype

Skype er et program som tilbyr funksjonalitet for å ringe andre brukere over internett, og

dermed uten tilkoblingsavgift, minuttpris eller abonnementsavgift (Wikipedia, 2013).

Dette har vi brukt i kombinasjon med et skjermdelingsprogram til å kommunisere med

kunden ved oppklaring av mer komplekse spørsmål.

4.7.2 Utviklingsverktøy

Nedenfor er det beskrevet hvilke verktøy vi har benyttet i utviklingsfasen av prosjektet.

4.7.2.1 IntelliJ

Som programmeringsverktøy valgte vi å

bruke IntelliJ, som er et av de mest brukte

verktøyene for programmering i Java. Figur 82: IntelliJ logo

Side 72 av 103

IntelliJ tilbyr et stort utvalg av nyttig funksjonalitet for en programmerer som andre

utviklingsverktøy ikke har. Blant annet har den intelligent autofullfør og refaktorering,

altså at den gir programmereren forslag ut ifra konteksten, ikke bare med tanke på hva du

har skrevet inn eller hva du har valgt.

Vi hadde ingen erfaring med dette fra tidligere, men det var intuitivt og enkelt å bruke, og

gjorde programmeringen effektiv og behagelig.

4.7.2.2 Java Development Kit (JDK)

JDK er et programvare-utviklingsmiljø som brukes til å utvikle Java-

applikasjoner og applets. Det inkluderer alt som skal til for å utvikle,

kompilere og debugge java-applikasjoner.

4.7.2.3 Android Software Development Kit (Android SDK)

Android SDK tilbyr API bibliotekene og utviklerverktøyene som er nødvendig for å utvikle,

teste og debugge applikasjoner for Android.

4.7.2.4 Genymotion

Genymotion er en Android emulator som lar deg lage virtuelle kopier av Android-systemer

og kjøre dem på en datamaskin. Dette verktøyet kan

etterligne et stort utvalg av Android- enheter, og gjør

testingen av Android applikasjoner enkelt å utføre

(Informer Technologies, Inc., 2014). I tillegg til å være enkel å bruke er denne emulatoren

betydelig raskere, både ved oppstart og ved bruk, enn den som følger med Android SDK.

4.7.2.5 Maven

Maven er et verktøy som automatiserer byggingen av Java-prosjekter. Det bruker en xml-fil

som beskriver prosjektet, dets avhengigheter av eksterne moduler og komponenter,

byggerekkefølgen, kataloger, og nødvendige plug-ins. Det leveres med pre-definerte mål

for utføring av bestemte veldefinerte oppgaver, som kompilering av kode og pakkingen av

den. Maven laster dynamisk ned Java-biblioteker og Maven plug-ins og lagrer dem i en

lokal cache30 (Wikipedia, 2014).

30 En komponent som lagrer data slik at fremtidige forespørsler kan utføres raskere.

Figur 83: Java logo

Figur 84: Genymotion logo

Side 73 av 103

4.7.2.6 JSON

JSON er en tekstbasert standard for datautveksling. Det er lett for mennesker å lese og

skrive, og lett for maskiner å tolke og generere. Det er helt språkuavhengig, men bruker

konvensjoner som er kjent for blant annet Java-utviklere (JSON, 2014).

4.7.2.7 Joda Time

Joda Time er et bibliotek som tilbyr en erstatning for Javas innebygde håndtering av datoer

og tid. Det inneholder mye nyttig funksjonalitet for behandling av datoer, som i tillegg

forenkler koden. For eksempel kan man hente ut antall dager mellom to datoer ved å bruke

metoden daysBetween(startDato, sluttDato), og man kan enkelt hente ut dag eller år med

metodene getYear() og getDayOfWeek(). Dette er mer tungvint med Javas innebygde

funksjonalitet. I JDK 8 har mannen bak Joda Time vært med på å utvikle ny innebygd

datohåndtering som baserer seg på dette.

Side 74 av 103

5 Testbeskrivelse

Under dette kapittelet vil det bli beskrevet hvordan vi har gått frem for å kvalitetssikre

applikasjonen.

5.1 Verktøy og enheter benyttet ved testing Enheter vi har benyttet til testing:

Samsung Galaxy S4

Samsung Galaxy S2

Samsung Galaxy Nexus

Xperia Z1 Compact

Samsung Galaxy Tab 10.1

Programvare benyttet til testing:

Genymotion (forskjellige emulatorer med forskjellig API)

Android emulator, følger med i Android SDK (forskjellige emulatorer med

forskjellige skjermstørrelser)

5.2 Testing Nedenfor er det underkapitler som beskriver testingen underveis, brukertesting, hvilke

skjermstørrelser vi har testet på, testing av fargekontrast og alfatesting.

5.2.1 Testing underveis

Som objektorientert programmeringsspråk er Java et av de mest utbredte. En av fordelene

med å programmere objektorientert er at det er enklere å forhindre feil i koden. Ved

oppbyggingen av programmet har vi bevisst laget en logisk oppdeling, for å forebygge feil.

Fokuset vårt har vært å skrive robust kode, slik at vi kan være stolte av produktet og levere

en applikasjon av god kvalitet.

Å feilsøke Java-kode er relativt enkelt med de rette verktøyene. Vi har hele tiden testet

funksjonalitet underveis på telefon og emulator. Ved feil vises det stort sett alltid forklaring

Side 75 av 103

i LogCat31 om hva som er feil og hvor i programmet feilen oppstod. De ganger feilen ikke

har vært enkel å forstå har vi brukt internett til å finne forslag til løsning. Dette har gjort at

vi har laget en robust applikasjon som tar hånd om feil på riktig måte.

5.2.2 Brukertesting

Vi har testet applikasjonen på utenforstående, og var dermed nødt til å sette de inn i

hvordan systemet fungerer på nettsiden. Deretter lot vi de utføre punktene i testen, for å se

at de forstod essensen i applikasjonen. Resultatet kan du se nedenfor.

Funksjonalitet

Test Resultat

Logge inn Logge inn med brukernavn og

passord

OK

Navigasjon Navigere mellom de forskjellige

aktivitetene og fragmentene i

applikasjonen

OK

Oppdatere innhold Oppdatere innhold i listene over kort

og aktiveringer med

oppdateringsknappen

OK

Aktivere Utføre en aktivering for et jaktkort

OK

Vise bevis Vise bevis for en utført aktivering

OK

Slett aktivering Slette en aktivering

OK

Endre aktivering Endre en aktivering OK, men en av testerne

31 Del av Android SDK som viser en logg av systemmeldinger, inkludert feilmeldinger og meldinger som

programmereren eventuelt har skrevet til loggen (Android Inc.).

Side 76 av 103

forventet noe annet enn

skjermbildet for

aktivering da han trykket

på «Endre».

Endre skriftstørrelse Endre skriftstørrelse i applikasjonen

via innstillinger

OK

Logge ut Logge ut via menyen

OK

5.2.3 Testing på forskjellige Android API versjoner

Vi har testet applikasjonen på følgende API versjoner:

15

16

17

18

19

Resultatet ble bra på de API versjonene vi testet.

5.2.4 Testing på forskjellige skjermstørrelser

Vi har testet applikasjonen på følgende skjermstørrelser:

4.0”

4.2”

5.1”

2.7”

10.1”

Resultatet ble bra på de skjermstørrelsene vi testet.

Side 77 av 103

5.2.5 Testing av fargekontrast

Vi har under utviklingen vært bevisst på generell kontrast og fargebruk. Ved testing av

kontrast på http://www.snook.ca/technical/colour_contrast/colour.html er alt

kompatibelt med WCAG 2 AA og stort sett med WCAG 2 AAA, med unntak av knappene i

applikasjonen. Vi har dermed lagt på et sort omriss på hvit knappetekst, slik at kontrasten

ble større.

5.2.6 Alfa-testing

Applikasjonen ble lagt ut til alfa-testing32 i slutten av mars slik at kunden kunne teste og

komme med respons. Vi fikk nyttige tilbakemeldinger som vi implementerte i

applikasjonen, og etter hvert som vi gjorde forbedringer lastet vi opp nye versjoner til

testing.

Grunnen til at applikasjonen kun ble lagt ut til alfa-testing for kunden, og ikke beta-

testing33 for reelle brukere, er fordi APIet vi fikk bare går mot testmiljøet. Man må ha en

brukerkonto og tilgang til å kjøpe kort i miljøet APIet går mot, for å kunne bruke

applikasjonen. Når APIet blir implementert i produksjonsmiljøet vil reelle brukere også

kunne laste ned og benytte applikasjonen.

32 Gjøres internt. En alpha-versjon trenger ikke inneholde alle de planlagte funksjonene og kan mangle

dokumentasjon. 33 Representative brukere tester produktet i ekte omgivelser før den endelige versjonen slippes.

http://www.snook.ca/technical/colour_contrast/colour.html

Side 78 av 103

6 Avslutning

I dette kapittelet vil vi oppsummere prosjektet i form av hvilken verdi produktet har for de

involverte partene, hvilket læringsutbytte vi har hatt og tilbakemelding fra kunden og

oppdragsgiver. Kapittelet avsluttes med en konklusjon.

6.1 Verdien av produktet I dette kapittelet tar vi for oss verdien av produktet for brukerne, kunden, oppdragsgiver

og oss selv.

6.1.1 Verdien for brukere

Applikasjonen vi har utviklet gir brukerne en enklere jakthverdag. I stedet for å være

avhengig av å aktivere jakt- og fiskekort hjemme eller ved hjelp av en nettleser på mobilen,

har brukerne nå muligheten til å gjøre dette ved hjelp av applikasjonen med få tastetrykk.

Vi har gjennom hele prosessen lagt vekt på at produktet skal være brukervennlig, og

resultatet er en applikasjon som er enkel og innbydende for brukeren.

6.1.2 Verdien for kunden

Inatur har med denne oppgaven fått en applikasjon som de kan tilby sine brukere.

Produktet er et robust system som kommuniserer med Inaturs eksisterende løsning, og

med de fargevalg og generell oppbygging av applikasjon som er gjort, ser den ut som en del

av deres system.

6.1.3 Verdien for oppdragsgiver

BEKK har tidligere jobbet med flere prosjekter for Inatur. Vi har nå laget en solid

applikasjon for en av BEKKs kunder, og dette er med på å styrke forholdet mellom de to

partene. Vi har vist både for BEKK og Inatur at vi som studenter er pålitelige og

arbeidsomme, noe som kan føre til at Inatur senere ønsker å gjennomføre prosjekter med

studenter.

Side 79 av 103

6.1.4 Verdien for oss

Gjennom hovedprosjektet har vi fått muligheten til å jobbe med et spennende prosjekt som

har gitt oss realistisk erfaring til arbeidslivet. I tillegg til erfaringen vi har fått ved å jobbe

med et produkt for en kunde, har vi laget et produkt vi stolt kan referere til i senere

jobbsammenheng. Vi har fått erfare hvordan det er å være konsulenter, med kunder som

ikke alltid vet hva de ønsker. Selv med veldefinerte krav har vi opplevd endringer

underveis i prosjektet fra kundens side, men dette er noe vi har klart å forholde oss til på

en god måte. Ved ønsker om endringer har vi raskt kastet oss rundt og utført dette. Dette

er også noe kunden har gitt oss tilbakemelding om at de har vært veldig fornøyd med.

6.2 Læringsbytte I løpet av prosessen med dette prosjektet har vi tatt i bruk mye av teorien vi har lært de tre

siste årene. Blant annet har vi blitt flinkere til å jobbe med databaser, og blitt tryggere på

applikasjonsutvikling. Vi har også fått god erfaring med prosjektplanlegging og

prosjektstyring, som vi ikke har fokusert på i like stor grad tidligere. I tillegg har vi fått god

kjennskap til Git, som vi har brukt i liten grad før dette prosjektet.

Vi har også lært mye nytt gjennom prosjektet. Blant annet har vi benyttet oss av

rammeverk, dette har vi aldri tidligere gjort i skolesammenheng. Noen av rammeverkene

vi måtte sette oss inn i var AndroidAnnotations, Robolectric og Retrofit. Vi var heller ikke

kjent med Maven som byggingsverktøy. I tillegg har vi fått kjennskap til flere eksterne

biblioteker.

6.3 Tilbakemeldinger På de to påfølgende sidene er det tilbakemeldinger fra kunden og fra veileder hos

oppdragsgiver.

Side 80 av 103

Side 81 av 103

Side 82 av 103

6.4 Konklusjon Gjennom hele prosessen har vi passet på å programmere med tanke på at det skal være

enkelt å videreutvikle applikasjonen i ettertid. Valg vi har tatt i programmet er derfor ofte

basert på dette. Av den grunn har vi også skrevet gode forklaringer i koden der det har

vært nødvendig, slik at misforståelser kan unngås i størst mulig grad.

Vårt samarbeid innad i gruppen har fungert veldig godt, og dette er sannsynligvis noe av

årsaken til at vi har nådd de mål vi satte oss for prosjektet. Kommunikasjon med Inatur og

BEKK har også vært god, og samarbeidet totalt sett mener vi derfor har vært optimalt.

Vi har laget en brukervennlig og robust Android applikasjon som lar jegere og fiskere

aktivere jakt- og fiskekort på en enkel måte. Produktet fremstår innbydende og delikat,

med et design som er nokså likt Inaturs eget.

Avslutningsvis føler vi at det har vært et svært vellykket prosjekt, og produktet står til de

forventninger vi hadde ved oppstart. Dette reflekteres også av Inatur og BEKK.

Side 83 av 103

7 Kilder

Android Inc. (2014, Mai 2). Android Developers. Hentet Mai 8, 2014 fra

http://developer.android.com/reference/android/accounts/AccountManager.html


http://developer.android.com/reference/android/app/ProgressDialog.html


http://developer.android.com/reference/android/widget/RelativeLayout.html


http://developer.android.com/reference/android/widget/LinearLayout.html

Android Inc. (u.d.). Android Developers. Hentet April 29, 2014 fra

http://developer.android.com/guide/topics/ui/controls/spinner.html


http://developer.android.com/guide/topics/ui/layout/listview.html


http://developer.android.com/reference/android/widget/TextView.html


http://developer.android.com/reference/android/widget/EditText.html


http://developer.android.com/reference/android/os/AsyncTask.html

Android Inc. (u.d.). Android Developers. Hentet Mai 16, 2014 fra

http://developer.android.com/guide/topics/ui/dialogs.html

Android Inc. (u.d.). Android Developers. Hentet Mai 19, 2014 fra

http://developer.android.com/tools/debugging/debugging-log.html

Bekk Consulting AS. (u.d.). Bekk Consulting AS. Hentet Mars 3, 2014 fra

http://www.bekk.no/#OmBekk/

Colebourne, S. (2002). Joda-Time. Hentet April 29, 2014 fra http://www.joda.org/joda-

time/

Inatur Norge AS. (2014). Inatur. Hentet Mai 9, 2014 fra http://www.nyeinatur.no/

Inatur Norge AS. (u.d.). Inatur. Hentet Mars 3, 2014 fra https://www.inatur.no/om/inatur

Side 84 av 103

Informer Technologies, Inc. (2014). Software Informer. Hentet Mai 11, 2014 fra

http://genymotion.software.informer.com/

JSON. (2014). JSON. Hentet Mai 11, 2014 fra http://www.json.org/

Sintef. (2014, Mars 27). Sintef. Hentet Mai 14, 2014 fra

http://www.sintef.no/Presserom/Fra-Geminino/Norske-IT-forskere-pa-topp-i-

verden/

Wikipedia. (2013, Juni 11). Wikipedia. Hentet Mai 11, 2014 fra

http://no.wikipedia.org/wiki/Skype

Wikipedia. (2013, Juli 23). Wikipedia. Hentet Mai 10, 2014 fra

http://no.wikipedia.org/wiki/Git

Wikipedia. (2014, Mai 10). Wikipedia. Hentet Mai 11, 2014 fra

http://en.wikipedia.org/wiki/Apache_Maven

Wikipedia. (2014, Mai 11). Wikipedia. Hentet Mai 11, 2014 fra

http://en.wikipedia.org/wiki/Scrum_(software_development)

Side 85 av 103

8 Vedlegg

Vedlegg A: Figurliste ............................................................................................................................................ 86

Vedlegg B: Ordbok ................................................................................................................................................. 89

Vedlegg C: Kravspesifikasjon ........................................................................................................................... 94

Side 86 av 103

8.1 Vedlegg A: Figurliste

Figur 1: Android logo ........................................................................................................................................... 12

Figur 2: Oversikt over prosjektets deltakere ............................................................................................ 13

Figur 3: BEKK logo ................................................................................................................................................ 14

Figur 4: Inatur logo ............................................................................................................................................... 14

Figur 5: Innloggingsskjerm ............................................................................................................................... 15

Figur 6: Skjermbilde av kortliste .................................................................................................................... 16

Figur 7: Skjermbilde av aktivering ................................................................................................................. 16

Figur 8: Skjermbilde av utførte aktiveringer ............................................................................................. 16

Figur 9: Innlogging ................................................................................................................................................ 17

Figur 10: Kortaktivering ..................................................................................................................................... 18

Figur 11: Kortinformasjon ................................................................................................................................. 19

Figur 12: Aktivering ............................................................................................................................................. 19



Figur 15: Dialogboks fangstrapport .............................................................................................................. 21


Figur 17: Utførte aktiveringer .......................................................................................................................... 22

Figur 18: Utførte aktiveringer liste meny ................................................................................................... 22

Figur 19: Dialogboks bekreft sletting ........................................................................................................... 23

Figur 20: Bevis ........................................................................................................................................................ 23

Figur 21: Meny ........................................................................................................................................................ 24

Figur 22: Hjelp ........................................................................................................................................................ 24

Figur 23: Om Inatur .............................................................................................................................................. 25

Figur 24: Kontakt ................................................................................................................................................... 25

Figur 25: Innstillinger .......................................................................................................................................... 26

Figur 26: Dialogboks - endre skriftstørrelse ............................................................................................. 26

Figur 27: Dialogboks - bekreft utlogging ..................................................................................................... 27

Figur 24: Dialog ...................................................................................................................................................... 27

Figur 25: ProgressDialog .................................................................................................................................... 28

Side 87 av 103

Figur 26: Toast ........................................................................................................................................................ 28

Figur 27: TextView med informasjon ........................................................................................................... 28

Figur 32: Oversikt over aktivitetene og fragmentene ........................................................................... 30

Figur 33: Klasseoversikt ..................................................................................................................................... 36

Figur 34: Databasemodell .................................................................................................................................. 39

Figur 35: Utdrag av JSON-array ved henting av utførte aktiveringer ............................................. 45

Figur 36: Utdrag av JSON-array som mottas ved henting av data for aktivering. ..................... 46

Figur 33: Knapper i listen .................................................................................................................................. 48

Figur 38: Menylinje med ikoner ...................................................................................................................... 49

Figur 39: Menylinje med tekst ......................................................................................................................... 49

Figur 40: Fanevalg på kundens nettside ..................................................................................................... 51

Figur 41: Fanevalg i applikasjonen ................................................................................................................ 51

Figur 42: Androids standard fane, blå strek indikerer gjeldende fane .......................................... 51

Figur 43: Bevis utstedt fra nettsiden ............................................................................................................ 52

Figur 44: Bevis utstedt fra applikasjonen ................................................................................................... 52

Figur 45: Visning av kalender p.t. ................................................................................................................... 52

Figur 46: Forslag til visning av kalender i ny løsning ............................................................................ 53

Figur 47: Den endelige kalenderen med valg av delområde på toppen ........................................ 53

Figur 48: Status «Gyldig» fra kunden ............................................................................................................ 54

Figur 49: Status «Gyldig» i applikasjonen ................................................................................................... 54

Figur 50: Status «Ikke gyldig» fra kunden .................................................................................................. 54

Figur 51: Status «Ikke gyldig» i applikasjonen ......................................................................................... 54

Figur 52: Status «Fullt» fra kunden ............................................................................................................... 54

Figur 53: Status «Fullt» i applikasjonen ...................................................................................................... 54

Figur 54: Status «Stengt» fra kunden ............................................................................................................ 54

Figur 55: Status «Stengt» i applikasjonen ................................................................................................... 54

Figur 56: Status «Valgt dag» fra kunden...................................................................................................... 55

Figur 57: Status «Valgt dag» i applikasjonen ............................................................................................. 55

Figur 54: Google Play logo ................................................................................................................................. 55

Figur 59: Use case diagram ............................................................................................................................... 58

Figur 60: Aktivitetsdiagram .............................................................................................................................. 59

Side 88 av 103

Figur 61: Tilstandsdiagram ............................................................................................................................... 60

Figur 58: Tekst i Kortinformasjon .................................................................................................................. 61


Figur 64: Kortinformasjon ikke aktivert kort ........................................................................................... 62

Figur 65: Velg delområde ................................................................................................................................... 62

Figur 66: Velg dato ................................................................................................................................................ 62


Figur 68: Kortinformasjon for aktivert kort .............................................................................................. 63

Figur 69: Bevis ........................................................................................................................................................ 63

Figur 70: Innlogging ............................................................................................................................................. 64


Figur 72: Kortinformasjon ikke aktivert kort ........................................................................................... 65

Figur 73: Velg delområde ................................................................................................................................... 65

Figur 74: Velg dato ................................................................................................................................................ 65

Figur 75: Bekreft aktivering.............................................................................................................................. 65


Figur 77: Kortinformasjon aktivert kort ..................................................................................................... 66

Figur 78: Bevis ........................................................................................................................................................ 66

Figur 79: Scrum prosessen ................................................................................................................................ 69

Figur 76: Github logo ........................................................................................................................................... 70

Figur 77: Trello logo ............................................................................................................................................. 70

Figur 78: IntelliJ logo ........................................................................................................................................... 71

Figur 79: Java logo ................................................................................................................................................. 72

Figur 80: Genymotion logo ................................................................................................................................ 72

Side 89 av 103

8.2 Vedlegg B: Ordbok

8.2.1 Kodebegreper

AccountManager Klassen gir tilgang til et sentralisert register av brukerens online-

kontoer (Android Inc., 2014).

Adapter Et Adapter-objekt knytter visningen av for eksempel ListView

eller Spinner til de dataene som skal vises. Adapteren gir tilgang

til dataelementene.

Aktivitet En applikasjons-komponent som viser et skjermbilde som

brukerne kan samhandle med, for eksempel å vise data, ta et bilde

eller vise et kart.

AlarmManager En klasse som gir tilgang til systemalarmtjenester.

Alfa-testing Gjøres internt. En alpha-versjon trenger ikke inneholde alle de

planlagte funksjonene og kan mangle dokumentasjon.

AndroidAnnotations Et rammeverk med åpen kildekode for å gjøre Android utvikling

raskere.

AsyncTask Gjør riktig og enkel bruk av UI tråden. Denne klassen gjør det

mulig å utføre bakgrunnsoperasjoner og publisere resultatene på

UI tråden uten å måtte manipulere tråder og / eller

behandlingsprogrammer (Android Inc.).

Beta-testing Representative brukere tester produktet i ekte omgivelser før den

endelige versjonen slippes.

Side 90 av 103

BroadcastReceiver En komponent som registrerer systemhendelser, som for

eksempel at enheten blir slått på eller at det er lavt batterinivå.

Dialog En dialog er et lite vindu som ber brukeren om å ta en beslutning

eller angi tilleggsinformasjon (Android Inc.).

EditText Ett tekstfelt som brukeren kan skrive tekst inn i (Android Inc.).

Fragment Representerer en oppførsel eller en del av brukergrensesnittet i

en aktivitet. Man kan også kombinere flere fragmenter i en enkelt

aktivitet for å bygge et brukergrensesnitt med flere vinduer. Man

kan tenke på et fragment som en modulær del av en aktivitet, som

har sin egen livssyklus, mottar sine egne inndatahendelser, og

som du kan legge til eller fjerne mens aktiviteten kjører (omtrent

som en «sub aktivitet» som du kan gjenbruke i ulike aktiviteter).

ImageView Bildevisning i Android

JodaTime Et bibliotek som kan erstatte Javas Date- og Calendar-klasse og

tilbyr enklere behandling av dato-håndtering (Colebourne, 2002).

JSON hijacking Når noen som i utgangspunktet ikke skal ha tilgang til JSON

dokumentet får tak i den informasjonen. Slike situasjoner oppstår

som regel ved å utnytte sårbarheter i programvare som behandler

disse dokumentene.

JUnit Rammeverk for enhetstesting.

LinearLayout En oppdeling der de indre elementene er organisert i en enkelt

kolonne eller rad (Android Inc., 2014).

Side 91 av 103

ListView En visningsgruppe som viser en liste med rullbare elementer.

Listeelementene blir automatisk satt inn i listen ved hjelp av en

adapter som trekker innhold fra en kilde, for eksempel en matrise

eller databasespørring og konverterer hvert element inn i en

visning som er plassert inn i listen (Android Inc.).

LogCat Del av Android SDK som viser en logg av systemmeldinger,

inkludert feilmeldinger og meldinger som programmereren

eventuelt har skrevet til loggen (Android Inc.).

PendingIntent Ved å gi en PendingIntent til en annen applikasjon, gir du retten til

å utføre operasjoner med samme rettigheter som den selv.

ProgressDialog En dialogboks som viser en fremdriftsindikator og en valgfri tekst

(Android Inc., 2014).

RelativeLayout En oppdeling der posisjonen til de indre elementene kan

beskrives i forhold til hverandre (Android Inc., 2014).

Retrofit En REST-klient for Android og Java.

Robolectric Rammeverk for enhetstesting

Service En komponent som kjøres i bakgrunnen, og således ikke

nødvendigvis blir lagt merke til av brukerne.

SharedPreferences Brukes til å lagre innstillinger for en applikasjon og vil bevares

også når applikasjonen blir avsluttet.

Spinnner Androids innebygde dropdown liste, ved berøring av spinneren

blir alle tilgjengelige valg synlig (Android Inc.).

Side 92 av 103

SQLite En åpen kildekode relasjonsdatabase. SQLite er innebygd i enhver

Android-enhet.

TextView Ett tekstfelt som viser tekst til brukeren, men er ikke mulig å

redigere (Android Inc.).

Toast Et liten popup med tilbakemelding til brukeren.

Token Data som brukes i nettverkskommunikasjon (ofte over HTTP) til å

identifisere en session, en serie av relaterte meldingsutvekslinger.

8.2.2 Jakt- og fiskebegreper

Aktivering En jeger eller fisker som har betalt for rettighet til å jakte/fiske

innenfor et jaktfelt eller fiskevald med aktiveringsfunksjon, skal

melde hvilket delområde en skal jakte/fiske ved å utføre en

aktivering på et kort. Én aktivering gjelder kun for ett delområde

og for én dato. Det kan utføres flere aktiveringer på ett kort.

Aktiveringskvittering En bekreftelse kunden mottar på hvilket delområde/fiskesone

som er aktivert for hvilket tidsrom.

Bevis Inngår i aktiveringskvitteringen og er en bekreftelse på en

aktivering. Dette må fremvises ved kontroll.

Delområde Et mindre geografisk område innenfor et jaktfelt.

Fisketrykk Det antall fiskere som har aktivert sitt fiskekort i et bestemt

fiskesone.

Side 93 av 103

Jaktfelt Et geografisk avgrenset område hvor jakt er tillatt. I denne

sammenhengen er et jaktfelt delt inn i flere delområder.

Jakttrykk Det antall jegere som har aktivert sitt jaktkort på et bestemt

delområde.

Trykkregulering Selger kan sette en antallsbegrensning på hvor mange

jegere/fiskere som er tillatt inn i et delområde/fiskesone pr dag.

Side 94 av 103 8.3 Vedlegg C: Kravspesifikasjon

Side 95 av 103

Side 96 av 103

Side 97 av 103

Side 98 av 103

Side 99 av 103

Side 100 av 103

Side 101 av 103

Side 102 av 103

Side 103 av 103

Tilbakemelding fra veileder hos oppdragsgiver

Documents

Android app for aktivering av jakt- og fiskekortstudent.cs.hioa.no/hovedprosjekter/data/2014/06/Sluttrapport.pdf · Side 5 av 103 Til produktet er det ikke laget noen brukerveiledning,