Nanna Mjørud. Anette Molund. Charlotte Sjøthun. Hovedprosjekt Android app for aktivering av jakt- og fiskekort. Høgskolen i Oslo og Akershus

Transkript

1 Nanna Mjørud Anette Molund Charlotte Sjøthun Hovedprosjekt 2014 Android app for aktivering av jakt- og fiskekort Høgskolen i Oslo og Akershus

2 Side 1 av 103

3 Side 2 av 103

4 Side 3 av 103

5 Forord Dette dokumentet er en endelig rapport for vårt hovedprosjekt på Høgskolen i Oslo og Akershus våren 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: hovedprosjekt@hioa.no 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: s180477@stud.hioa.no. 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. Side 4 av 103

6 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 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 5 av 103

7 Innholdsfortegnelse Forord... 4 Leserveiledning... 4 For sensor... 5 For videreutviklere... 5 For andre interesserte Presentasjon Innledning Prosjektets deltakere Studentgruppen Bekk Consulting AS Inatur Norge AS Om bakgrunnen Kort presentasjon av sluttproduktet Produktbeskrivelse Applikasjonen i skjermbilder Innlogging Kortaktivering Kortinformasjon Aktivering Utførte aktiveringer Bevis Meny Kommunikasjon med brukeren Meldinger som krever interaksjon Side 6 av 103

8 2.2.2 Meldinger som ikke krever interaksjon Meldinger som er informasjon Applikasjonens komponenter Java-klasser XML-filer Teknisk beskrivelse av klassene Innlogging Kortlister Kortaktivering Utførte aktiveringer Aktivering Bevis Kortinformasjon Hjelp Kontakt Om Inatur Innstillinger KortaktiveringArrayAdapter og UtforteAktiveringerArrayAdapter DatabaseHaandterer APIHaandterer Aktiveringsdata Innloggingsparametere DagsAktivering Delomraade Kort Person SettPeriodiskService SjekkUtlopteKortService StartServiceBroadcastReceiver Side 7 av 103

9 3 Valg og utfordringer AndroidAnnotations JDK 7 fremfor JDK Retrofit fremfor Jersey IntelliJ fremfor Android Studio Behandling av dato og tid Service og BroadcastReceiver Utfordringer med APIet Nettverkstrafikk AccountManager Sikkerhet Bevaring av cookie JSON escaping Retningslinjer for design Kravspesifikasjonens rolle Norsk kode Tilleggsfunksjonalitet Synliggjøring av manglende fangstrapport Bytte språk til engelsk Forstørre skriften Designkrav Faner Bevis Visning av kalender Status i kalender ved aktivering av kort Lansering i Google Play Testdreven utvikling Prosessbeskrivelse Side 8 av 103

10 4.1 Inatur som domene Planleggingsfasen UML Use case diagram Aktivitetsdiagram Tilstandsdiagram Design Første utkast av skisser Andre utkast av skisser Implementasjonsfasen Arbeidsforhold Prosjektdagbok Kommunikasjon Kommunikasjon i gruppen Kommunikasjon med kunden Kommunikasjon med oppdragsgiver Smidig utvikling Verktøy Prosessverktøy Git Trello Microsoft Word Dropbox Facebook Skype Utviklingsverktøy IntelliJ Java Development Kit (JDK) Android Software Development Kit (Android SDK) Genymotion Side 9 av 103

11 Maven JSON Joda Time Testbeskrivelse Verktøy og enheter benyttet ved testing Testing Testing underveis Brukertesting Testing på forskjellige Android API versjoner Testing på forskjellige skjermstørrelser Testing av fargekontrast Alfa-testing Avslutning Verdien av produktet Verdien for brukere Verdien for kunden Verdien for oppdragsgiver Verdien for oss Læringsbytte Tilbakemeldinger Konklusjon Kilder Vedlegg Vedlegg A: Figurliste Vedlegg B: Ordbok Kodebegreper Side 10 av 103

12 8.2.2 Jakt- og fiskebegreper Vedlegg C: Kravspesifikasjon Side 11 av 103

13 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 netttilgang. For å implementere denne funksjonaliteten var Figur 1: Android logo 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 Side 12 av 103

14 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 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 13 av 103

15 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 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). Figur 3: BEKK logo 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 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. Figur 4: Inatur logo 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. Side 14 av 103

16 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 internetttilgang. 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 Figur 5: Innloggingsskjerm 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 Side 15 av 103

17 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 16 av 103

18 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 BroadcastReceiver 1 og to Servicer 2. 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 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 17 av 103

19 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 18 av 103

20 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 aktiverknappen 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 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). Aktiverknappen 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 19 av 103

21 Her er det trykket på spinneren 3 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. Figur 13: Aktivering 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. Figur 14: Aktivering 3 Androids innebygde dropdown liste, ved berøring blir alle tilgjengelige valg synlig (Android Inc.). Side 20 av 103

22 Her vises dialogboksen 4 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. 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. Figur 15: Dialogboks fangstrapport Figur 16: Aktivering 4 En dialog er et lite vindu som ber brukeren om å ta en beslutning eller angi tilleggsinformasjon. Side 21 av 103

23 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 22 av 103

24 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 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 internetttilgang. Figur 20: Bevis Side 23 av 103

25 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 24 av 103

26 Dette er skjermbildet for om Inatur. Her kan brukerne lese informasjon om Inatur. Denne informasjonen er hentet fra inatur.no. Dette er skjermbildet for kontakt. Her vises kontaktinformasjonen til Inatur. Denne informasjonen er hentet fra inatur.no. Figur 23: Om Inatur Figur 24: Kontakt Side 25 av 103

27 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). 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 25: Innstillinger Figur 26: Dialogboks - endre skriftstørrelse Side 26 av 103

28 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å 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 Figur 28: Dialog 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 Side 27 av 103

29 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 Meldinger som ikke krever interaksjon Meldinger som ikke krever interaksjon med bruker, men som er nyttig informasjon for brukeren, blir vist som en Toast 5. 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 ProgressDialog 6, for å vise brukeren at applikasjonen jobber. Denne dialogen Figur 30: Toast er det ikke mulig å lukke, og brukeren kan ikke foreta seg noe annet i applikasjonen når denne vises. Figur 29: ProgressDialog Meldinger som er informasjon Der det er nyttig informasjon til bruker, men som ikke krever interaksjon, blir meldingen vist i form av et TextView 7. Dette brukes i Kortaktivering og Utførte Aktiveringer hvis det ikke er noen kort som kan aktiveres eller det Figur 31: TextView med informasjon 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.). Side 28 av 103

30 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 fragmenter 8 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 29 av 103

31 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 30 av 103

32 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 31 av 103

33 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 aktivering_stor.xml o aktivering_xstor.xml o bevis.xml o innlogging.xml o kortaktivering_rad.xml Side 32 av 103

34 o kortinformasjon.xml o utforte_aktiveringer_rad.xml layout-large o aktivering.xml o bevis.xml o bevis_liten.xml o bevis_stor.xml o bevis_xstor.xml o innlogging.xml o kortaktivering_rad.xml o kortaktivering_rad_liten.xml o kortaktivering_rad_stor.xml o kortaktivering_rad_xstor.xml o kortinformasjon.xml o utforte_aktiveringer_rad.xml o utforte_aktiveringer_rad_stor.xml o utforte_aktiveringer_rad_xstor.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 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 Side 33 av 103

35 o kortinformasjon_stor.xml o kortinformasjon_xstor.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-small-land o bevis.xml o kortaktivering_rad.xml o kortinformasjon.xml o utforte_aktiveringer_rad.xml layout-xlarge o aktivering.xml o aktivering_stor.xml o aktivering_xstor.xml o bevis.xml o bevis_liten.xml o bevis_stor.xml o bevis_xstor.xml o innlogging.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_stor.xml o kortinformasjon_xstor.xml o utforte_aktiveringer_rad.xml o utforte_aktiveringer_rad_liten.xml o utforte_aktiveringer_rad_stor.xml Side 34 av 103

36 o utforte_aktiveringer_rad_xstor.xml 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 35 av 103

37 Figur 33: Klasseoversikt Innlogging Aktiviteten Innlogging består av et ImageView 9 med Inaturs logo, to EditText 10, 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 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 ListView 11 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 36 av 103

38 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 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 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 Aktivering Det er i aktiviteten Aktivering at en aktivering blir gjennomført. Aktiviteten er komplekst oppbygd med mange LinearLayout 12, RelativeLayout 13 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 37 av 103

39 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 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 Hjelp Aktiviteten Hjelp består kun av ett TextView med statisk tekst. Teksten er en kortfattet veiledning for bruk av applikasjonen Kontakt Aktiviteten Kontakt består kun av ett TextView med statisk tekst. Teksten inneholder kontaktinformasjon til kunden Om Inatur Aktiviteten OmInatur består kun av ett TextView med statisk tekst. Teksten inneholder en generell beskrivelse av kunden Innstillinger Aktiviteten Innstillinger består av et PreferenceFragment, det vil si en liste av innstillinger. Disse innstillingene vil automatisk bli lagret i SharedPreferences 14, 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 38 av 103

40 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 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 SQLite 15, og inneholder tabellene «Kort», «Person», «Kortgyldighet», «Dato», «Delomraade» og «Aktivering». Figur 34: Databasemodell 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 39 av 103

41 håndtert. APIHaandterer inneholder også konstanter for URLene som brukes i applikasjonen 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 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 DagsAktivering Klassen DagsAktivering er et objekt som simulerer en utført aktivering, og består av variablene «aktiveringsid», «dato» og «delomraade» Delomraade Klassen Delomraade er et objekt som simulerer et delområde, og består av variablene «id», «navn», «kommentar», «makstrykk», «dagstrykk» og «alleredeaktivertedager» 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» Person Klassen Person er et objekt som simulerer en jeger eller fisker, og består av variablene «navn» og «telefonnummer». Side 40 av 103

42 SettPeriodiskService Klassen SettPeriodiskService arver klassen Service, og oppretter en AlarmManager 16 som starter SjekkUtlopteKortService hvert døgn ved midnatt SjekkUtlopteKortService Klassen SjekkUtlopteKortService sjekker om det er lagret noen kort og aktiveringer i databasen som ikke lenger er gyldig, og sletter disse 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 41 av 103

43 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 AndroidAnnotations 17. 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 JUnit 18 og Robolectric 19. 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 Retrofit fremfor Jersey I utgangspunktet hadde vi planer om å benytte oss av Jersey for API-kall. Etter litt diskusjon valgte vi heller å benytte Retrofit 20, fordi det da ikke er nødvendig å bruke klassen AsyncTask 21 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 42 av 103

44 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 PendingIntent 22 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 43 av 103

45 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 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 44 av 103

46 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. [ { "id": "533177b4e4b01a06ae438c7a", "kjopid": "532fd17ce4b0e531d09df934", "tilbudstittel": "Småviltjakt i Nordland Nordlandskortet", "korttittel": "Nordlands- og bostedskommunekort - sesong", "kortnummer": " ", "dato": " ", "område": "Beiarn Vest", "kvitteringslenke": " dev.s3- euwest- 1.amazonaws.com/kvittering/521c471fe4b08 4b6bd0d4ae1/533177d0e4b01a06ae438c7c.pdf" ] }... 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 Side 45 av 103

47 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 [... "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" ]... Figur 36: Utdrag av JSON-array som mottas ved henting av data for aktivering. Side 46 av 103

48 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 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 token 23 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 rootet 24. 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 47 av 103

49 3.9.2 JSON escaping JSON responser fra API-kall blir escapet med prefikset «{}&&». Årsaken til dette er å beskytte mot JSON hijacking 25. 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 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 Androidvennlig, 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. Figur 37: Knapper i listen 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. Side 48 av 103

50 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 Toast er mye brukt i applikasjoner for Android 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 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 49 av 103

51 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 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 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 Forstørre skriften Funksjonalitet for å forstørre og forminske teksten er lagt til, og brukeren kan endre skriftstørrelse i applikasjonens innstillinger 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 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 50 av 103

52 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 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 51 av 103

53 Figur 43: Bevis utstedt fra nettsiden Figur 44: Bevis utstedt fra applikasjonen 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 52 av 103

54 Figur 46: Forslag til visning av kalender i ny løsning Figur 47: Den endelige kalenderen med valg av delområde på toppen 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 53 av 103

55 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 1 1 av 10 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 Side 54 av 103

56 Figur 56: Status «Valgt dag» fra kunden Figur 57: Status «Valgt dag» i applikasjonen 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 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 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: Figur 58: Google Play logo 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ø 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 Side 55 av 103

57 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 56 av 103

58 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 ikkeaktiverte 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 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 57 av 103

59 Use case diagram Use case diagrammet reflekterer kundens krav til funksjonalitet. Figur 59: Use case diagram Side 58 av 103

60 Aktivitetsdiagram Aktivitetsdiagrammet reflekterer brukers interaksjon med applikasjonen. Figur 60: Aktivitetsdiagram Side 59 av 103

61 Tilstandsdiagram Tilstandsdiagrammet reflekterer tilstandene applikasjonen kan befinne seg i. Figur 61: Tilstandsdiagram Design Det forutsettes i dette kapittelet at kapittel , 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 60 av 103

62 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 Figur 62: Tekst i Kortinformasjon 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 Første utkast av skisser Nedenfor er skissene som ble tegnet digitalt. Disse er identiske til skissene tegnet på papir. Side 61 av 103

63 Figur 63: Kortaktivering Figur 64: Kortinformasjon ikke aktivert kort Figur 65: Velg delområde Figur 66: Velg dato Side 62 av 103

64 Figur 67: Utførte aktiveringer Figur 68: Kortinformasjon for aktivert kort Figur 69: Bevis Side 63 av 103

65 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 Figur 71: Kortaktivering Side 64 av 103

66 Figur 72: Kortinformasjon ikke aktivert kort Figur 73: Velg delområde Figur 74: Velg dato Figur 75: Bekreft aktivering Side 65 av 103

67 Figur 76: Utførte aktiveringer Figur 77: Kortinformasjon aktivert kort Figur 78: Bevis Side 66 av 103

68 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 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 67 av 103

69 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 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 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-postkorrespondanse 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 68 av 103

70 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 69 av 103

71 4.7.1 Prosessverktøy Nedenfor er det beskrevet hvilke verktøy vi har benyttet i tilknytning til prosjektet Git Git er et versjonskontrollsystem 26 som vi var kjent med fra tidligere gjennom skoleoppgaver. Git har egne kommandoer, pull 27 og push 28, for synkronisering med andre repositorier. Dette muliggjør alle-til-allesynkronisering (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). Figur 80: Github logo 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 commits 29 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 Trello Som prosjekthåndteringsverktøy har vi brukt Trello. Dette er et webbasert verktøy som opprinnelig er ment for utviklingsmetoden Kanban. Vi valgte å benytte dette selv om vi Figur 81: Trello logo 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. Side 70 av 103

72 har brukt Scrum som utviklingsmetode, fordi det er en enkel og oversiktlig «drag-anddrop» 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 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 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 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 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 Utviklingsverktøy Nedenfor er det beskrevet hvilke verktøy vi har benyttet i utviklingsfasen av prosjektet 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 71 av 103

73 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 Java Development Kit (JDK) JDK er et programvare-utviklingsmiljø som brukes til å utvikle Javaapplikasjoner og applets. Det inkluderer alt som skal til for å utvikle, kompilere og debugge java-applikasjoner 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 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 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 cache 30 (Wikipedia, 2014). Figur 83: Java logo Figur 84: Genymotion logo 30 En komponent som lagrer data slik at fremtidige forespørsler kan utføres raskere. Side 72 av 103

74 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) 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 73 av 103

75 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 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 74 av 103

76 i LogCat 31 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 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 75 av 103

77 Endre skriftstørrelse Endre skriftstørrelse i applikasjonen via innstillinger forventet noe annet enn skjermbildet for aktivering da han trykket på «Endre». OK Logge ut Logge ut via menyen OK Testing på forskjellige Android API versjoner Vi har testet applikasjonen på følgende API versjoner: Resultatet ble bra på de API versjonene vi testet Testing på forskjellige skjermstørrelser Vi har testet applikasjonen på følgende skjermstørrelser: Resultatet ble bra på de skjermstørrelsene vi testet. Side 76 av 103

78 5.2.5 Testing av fargekontrast Vi har under utviklingen vært bevisst på generell kontrast og fargebruk. Ved testing av kontrast på 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 Alfa-testing Applikasjonen ble lagt ut til alfa-testing 32 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 betatesting 33 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. Side 77 av 103

79 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 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 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 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 78 av 103

80 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 79 av 103

81 Side 80 av 103

82 Side 81 av 103

83 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 82 av 103

84 7 Kilder Android Inc. (2014, Mai 2). Android Developers. Hentet Mai 8, 2014 fra Android Inc. (2014, Mai 2). Android Developers. Hentet Mai 13, 2014 fra Android Inc. (2014, Mai 2). Android Developers. Hentet Mai 13, 2014 fra Android Inc. (2014, Mai 13). Android Developers. Hentet Mai 16, 2014 fra Android Inc. (u.d.). Android Developers. Hentet April 29, 2014 fra Android Inc. (u.d.). Android Developers. Hentet April 29, 2014 fra Android Inc. (u.d.). Android Developers. Hentet April 29, 2014 fra Android Inc. (u.d.). Android Developers. Hentet April 29, 2014 fra Android Inc. (u.d.). Android Developers. Hentet April 29, 2014 fra Android Inc. (u.d.). Android Developers. Hentet Mai 16, 2014 fra Android Inc. (u.d.). Android Developers. Hentet Mai 19, 2014 fra Bekk Consulting AS. (u.d.). Bekk Consulting AS. Hentet Mars 3, 2014 fra Colebourne, S. (2002). Joda-Time. Hentet April 29, 2014 fra Inatur Norge AS. (2014). Inatur. Hentet Mai 9, 2014 fra Inatur Norge AS. (u.d.). Inatur. Hentet Mars 3, 2014 fra Side 83 av 103

85 Informer Technologies, Inc. (2014). Software Informer. Hentet Mai 11, 2014 fra JSON. (2014). JSON. Hentet Mai 11, 2014 fra Sintef. (2014, Mars 27). Sintef. Hentet Mai 14, 2014 fra Wikipedia. (2013, Juni 11). Wikipedia. Hentet Mai 11, 2014 fra Wikipedia. (2013, Juli 23). Wikipedia. Hentet Mai 10, 2014 fra Wikipedia. (2014, Mai 10). Wikipedia. Hentet Mai 11, 2014 fra Wikipedia. (2014, Mai 11). Wikipedia. Hentet Mai 11, 2014 fra Side 84 av 103

86 8 Vedlegg Vedlegg A: Figurliste Vedlegg B: Ordbok Vedlegg C: Kravspesifikasjon Side 85 av 103

87 8.1 Vedlegg A: Figurliste Figur 1: Android logo Figur 2: Oversikt over prosjektets deltakere Figur 3: BEKK logo Figur 4: Inatur logo Figur 5: Innloggingsskjerm Figur 6: Skjermbilde av kortliste Figur 7: Skjermbilde av aktivering Figur 8: Skjermbilde av utførte aktiveringer Figur 9: Innlogging Figur 10: Kortaktivering Figur 11: Kortinformasjon Figur 12: Aktivering Figur 13: Aktivering Figur 14: Aktivering Figur 15: Dialogboks fangstrapport Figur 16: Aktivering Figur 17: Utførte aktiveringer Figur 18: Utførte aktiveringer liste meny Figur 19: Dialogboks bekreft sletting Figur 20: Bevis Figur 21: Meny Figur 22: Hjelp Figur 23: Om Inatur Figur 24: Kontakt Figur 25: Innstillinger Figur 26: Dialogboks - endre skriftstørrelse Figur 27: Dialogboks - bekreft utlogging Figur 24: Dialog Figur 25: ProgressDialog Side 86 av 103

88 Figur 26: Toast Figur 27: TextView med informasjon Figur 32: Oversikt over aktivitetene og fragmentene Figur 33: Klasseoversikt Figur 34: Databasemodell Figur 35: Utdrag av JSON-array ved henting av utførte aktiveringer Figur 36: Utdrag av JSON-array som mottas ved henting av data for aktivering Figur 33: Knapper i listen Figur 38: Menylinje med ikoner Figur 39: Menylinje med tekst Figur 40: Fanevalg på kundens nettside Figur 41: Fanevalg i applikasjonen Figur 42: Androids standard fane, blå strek indikerer gjeldende fane Figur 43: Bevis utstedt fra nettsiden Figur 44: Bevis utstedt fra applikasjonen Figur 45: Visning av kalender p.t Figur 46: Forslag til visning av kalender i ny løsning Figur 47: Den endelige kalenderen med valg av delområde på toppen Figur 48: Status «Gyldig» fra kunden Figur 49: Status «Gyldig» i applikasjonen Figur 50: Status «Ikke gyldig» fra kunden Figur 51: Status «Ikke gyldig» i applikasjonen Figur 52: Status «Fullt» fra kunden Figur 53: Status «Fullt» i applikasjonen Figur 54: Status «Stengt» fra kunden Figur 55: Status «Stengt» i applikasjonen Figur 56: Status «Valgt dag» fra kunden Figur 57: Status «Valgt dag» i applikasjonen Figur 54: Google Play logo Figur 59: Use case diagram Figur 60: Aktivitetsdiagram Side 87 av 103

89 Figur 61: Tilstandsdiagram Figur 58: Tekst i Kortinformasjon Figur 63: Kortaktivering Figur 64: Kortinformasjon ikke aktivert kort Figur 65: Velg delområde Figur 66: Velg dato Figur 67: Utførte aktiveringer Figur 68: Kortinformasjon for aktivert kort Figur 69: Bevis Figur 70: Innlogging Figur 71: Kortaktivering Figur 72: Kortinformasjon ikke aktivert kort Figur 73: Velg delområde Figur 74: Velg dato Figur 75: Bekreft aktivering Figur 76: Utførte aktiveringer Figur 77: Kortinformasjon aktivert kort Figur 78: Bevis Figur 79: Scrum prosessen Figur 76: Github logo Figur 77: Trello logo Figur 78: IntelliJ logo Figur 79: Java logo Figur 80: Genymotion logo Side 88 av 103

90 8.2 Vedlegg B: Ordbok Kodebegreper AccountManager Klassen gir tilgang til et sentralisert register av brukerens onlinekontoer (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 89 av 103

91 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 LinearLayout Rammeverk for enhetstesting. En oppdeling der de indre elementene er organisert i en enkelt kolonne eller rad (Android Inc., 2014). Side 90 av 103

92 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 PendingIntent Del av Android SDK som viser en logg av systemmeldinger, inkludert feilmeldinger og meldinger som programmereren eventuelt har skrevet til loggen (Android Inc.). 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 Service Rammeverk for enhetstesting 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 91 av 103

93 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 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 92 av 103

94 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 93 av 103

95 8.3 Vedlegg C: Kravspesifikasjon Side 94 av 103