Vi beskriver hvordan arbeidsprosessen gjennom hele hovedprosjektet har vært for vår gruppe.. Den består av fire kapitler i følgende rekkefølge:

Transkript

1 PROSESSRAPPORT FORORD I denne rapporten vil vi beskrive prosessen bak utviklingen av Digipost for Android. Vi forutsetter at leseren har lest presentasjonsdokumentet og gjort seg kjent med helheten i dokumentasjonen. Noen kapitler forutsetter også at leseren er kjent med teknologier og tekniske aspekter. Ellers oppfordres det til å benytte Android-sammendraget (vedlegg 1) og ordlisten (vedlegg 2) ettersom tekniske ord og uttrykk vil bli benyttet uten forklaring. Vi beskriver hvordan arbeidsprosessen gjennom hele hovedprosjektet har vært for vår gruppe.. Den består av fire kapitler i følgende rekkefølge: Planlegging og metode: Tar for seg planleggingen, hvordan vi har jobbet sammen, kommunikasjon med oppdragsgiver og kunde, arbeidsfordeling og prosjektstyring. Til slutt gis en oversikt over verktøy og teknologi som er benyttet Utviklingsprosessen: Her beskrives prosjektes gang fra konseptutvikling til programmering av funksjonalitet og design. Vi begrunner våre løsninger, samt beskriver de utfordringer vi har møtt på veien mot et ferdig produkt Kravspesifikasjonen og dens rolle: Tar for seg nytteverdien av kravspesifikasjonen og dens viktighet i en så omfattende oppgave vi har utført Avsluttende del: Presenterer våre tanker rundt læringsutbyttet og produktet og gir en avsluttende konklusjon Den som skal vurdere rapporten, bør legge spesielt fokus på utviklingsprosessen. Vi ønsker at denne delen spesielt i sammenheng med produktrapporten. Det vil i produktrapporten bli beskrevet de tekniske finessene bak utfordringene og valgene hver funksjonalitet beskrevet i denne rapporten har medført. Delkapitlene læringsutbytte og det ferdige produktet under kapittelet avsluttende del bør også leses under vurderingen. Side 1 av 38

2 INNHOLD Forord... 1 Planlegging og metode... 5 Forløp til prosjektstart... 5 Arbeidsteknikker og utviklingsmetoder... 5 Smidig utvikling... 5 Kommunikasjon med kunde/veileder... 8 Prosjektstyringsdokumenter... 9 Arbeidsplan... 9 Fremdriftsplan... 9 Arbeidslogg... 9 Arbeidsforhold Postgirobygget HiOA Verktøy Versjonskontroll Prosjekthåndtering Dokumentasjon Utviklingsverktøy Utvidelser og rammeverk Analyseverktøy Android Utviklingsprosessen Konseptutvikling Datainnsamling Målgruppe og behov Gruppemøter og Brainstorming Side 2 av 38

3 Presentasjon av konsept for oppdragsgiver og kunde Utvikling med Android SDK og Android NDK Fordeler og ulemper med native utvikling Open source REST-rammeverket Implementering av funksjonalitet Testing Sikker lagring Minnebruk Utforming av brukergrensesnitt Navigasjonsvalg Dokumentbehandling Fargevalg Grafikk Helhetlig følelse Personvern Kravspesifikasjon og dens rolle Bakgrunn for kravspesifikasjon Rammekrav Fortløpende endringer Vår erfaring med kravspesifikasjonen Kravspesifikasjonen av det endelige produktet Oppfyllelse av krav og/eller måloppnåelse Tilbakemelding fra oppdragsgiver og kunde Konklusjon Google Analytics Avsluttende del Side 3 av 38

4 Ord fra oppdragsgiver Ord fra kunden Samarbeid i gruppen Konfliktløsing og konstruktive diskusjoner Veiledning ved HiOA Læringsutbytte Det ferdige produktet Nytteverdi Videre utvikling Fora for brukerdialog Google Play som kanal Twitter lab.digipost.no Konklusjon Side 4 av 38

5 PLANLEGGING OG METODE God planlegging er essensielt for å oppnå et godt resultat. I dette kapittelet vil vi beskrive teknikker, metoder, verktøy og hjelpemidler som har hjulpet oss med å oppnå et vellykket prosjektarbeid. FORLØP TIL PROSJEKTSTART Det første gruppemøtet fant sted tidlig i oktober Møtets hensikt var å få kartlagt tanker og ideer, hvilke teknologier vi ønsket å benytte og hva vi generelt så for oss som aktuelt å jobbe med. Ideene haglet og engasjementet var på topp! Vi diskuterte også hvilke virksomheter som var potensielle oppdragsgivere og som kunne tilby et prosjekt som samsvarte med de visjonene vi hadde. Vi noterte ideer og aktuelle oppdragsgivere underveis. Etter idemyldringen satt vi igjen med en liste bedrifter og en vag formulering av hvordan oppgaven skulle se ut. Deretter måtte vi finne ut om bedriftene hadde en eksisterende ordning og tradisjon rundt det å tilby hovedprosjekter til studenter. Dette lot seg undersøke raskt på nettet. Vi opprettet første kontakt via e-post og telefonsamtaler og ble i de fleste tilfeller bedt om å sende over karakterer og et lite skriv om hvilke teknologier vi var kjent med og ønsket å jobbe med. Vi fikk mye positiv respons og interesse og flere tilbakemeldinger med forespørseler om å komme til uforpliktende møter. Vi var på flere interessante møter der vi ble introdusert for spennende oppgaver, men tok en rask avgjørelse hos BEKK da vi ble kjent med Digipost-oppgaven. Av de oppgavene vi ble introdusert til var dette oppgaven med størst omfang og mest spennende teknologi. Det faktum at applikasjonen skulle produksjonssettes og brukes av potensielt digipostbrukere, var også med i betraktningen og en del av motivasjonen. ARBEIDSTEKNIKKER OG UTVIKLINGSMETODER SMIDIG UTVIKLING Smidig utvikling har de siste årene blitt meget populært og er den mest brukte modellen for programvareutvikling. Begreper som Scrum, Kanban og Extreme Programming dukker opp i de fleste utviklingssammenhenger - representanter fra næringslivet hevder det er nøkkelen til en effektiv utviklingsprosess. Å definere hva smidig utvikling er kan være vanskelig, men disse tre påstandene kan være med å synliggjøre behovet: Du vil aldri klare å samle alle krav til en løsning før du begynner! Kravene vil garantert komme til å endre seg underveis! Det vil alltid være mer å gjøre enn man har tid til! Punktene er hentet fra I forkant av prosjektet hadde vi kun et teoretisk bekjentskap til disse metodikkene, blant annet fra skolefag og media. Vi skjønte fort at det ikke nyttet med de tradisjonelle metodene som for eksempel Fossefallmetoden og Unified Process. Det vi trengte var en lettvekter innfor smidighetsmodellen som hadde en iterativ og inkrementell arbeidsform siden rammene for prosjektet sannsynligvis ville endres underveis. Side 5 av 38

6 Det var naturlig for oss å velge Extreme Programming (XP), en utviklingsmodell som har flere egnede faktorer som parprogrammering, brukerinteraksjon under utviklingen og som tillater iterativ og inkrementell utvikling. I kombinasjon med XP har vi benyttet Trello, et prosjekthåndteringsverktøy beskrevet i neste delkapittel. Å velge smidighetsmodell var ikke en tidskrevend oppgave, men vi ønsket alikevel å være bevisste på dette valget. EXTREME PROGRAMMING XP er en utviklingsmetodikk med fokus på enkelhet, fleksibilitet og løpende endring i kundebehov. Det er de korte sprintene med høy produktivitet som gjør denne metodikken egnet for små til mellomstore prosjekter, eller som delmetodikk i store prosjekter. Følgende punkter beskriver XP: Iterativ og inkrementell utvikling Brukerinteraksjon under utviklingen Omfattende kodegjennomgang og refaktorisering Testing av all kode Implementasjon ved behov Parprogrammering Kommunikasjon BEGRUNNELSE FOR BRUK AV EXTREME PROGRAMMING Vi var på forhånd ikke innstilt på å legge mye tid eller arbeid i å følge en omfattende utviklingsmetodikk slavisk. Dette kunne medføre tap av tid i form av unødvendig forarbeid og planlegging som i stor del allerede var utført av kunden. Rammene, samt en stor del av funksjonaliteten var allerede på plass. Mye var dermed tilrettelagt for at utviklingen av selve applikasjonen kunne påbegynnes forholdsvis tidlig. Vi hadde kjennskap til teorien rundt XP og visste at den var enkel å bruke og tillot stor grad av fleksibilitet og endringsmuligheter. Vi visste også at samarbeidet i stor grad kom til å foregå rundt samme bord, som ga mulighet for parprogrammering. VÅR ERFARING MED XP Å benytte XP i praksis, har i liten grad vært et moment vi har måttet følge opp og bruke tid på. Dette fordi den naturlige måten å samarbeide på i dette prosjektet ville vært av lignende natur. Vi har likevel dratt nytte av flere aspekter i metodikken. Parprogrammering har forekommet på en daglig basis, og i denne sammenheng har også kodegjennomgang og refaktorisering av kode fulgt naturlig. I en applikasjon som håndterer sensitiv informasjon er det ikke rom for feil. Derfor har det vært viktig for oss å kvalitetssikre koden. Grundig testing har vært en stor del av utviklingsarbeidet. Fleksibiliteten og endringsmulighetene til XP har også vært verdifullt ettersom vi hatt en løpende dialog med fremtidige brukere som har ytret sine meninger på våre kommunikasjonskanaler. Det var spesielt viktig etter beta-versjonen. Side 6 av 38

7 TRELLO Trello er et verktøy for prosjekthåndtering basert på et brett bestående av flere lister som inneholder mange kort. I denne sammenhengen representerer brettet selve prosjektet, hver liste en tilstand og hvert kort oppgaver som har oppnådd denne tilstanden. Alle prosjektdeltakere kan legges til brettet og på den måten erklære sin avhengighet og sitt ansvar til arbeidsoppgaver i de forskjellige listene. Det er også mulighet for å kommentere på kort, sette opp sjekklister, legge ved filer med mer. Siden Trello er en nettbasert tjeneste oppdateres prosjektfremgangen i sanntid. HVORFOR UTVIKLE MED TRELLO? Ingen av oss var fra før kjent med Trello som utviklingsverktøy. Det var våre veiledere som introduserte oss for verktøyet på første ukentlige møte. Vi ble fortalt at Digipost sine utviklere benyttet seg av dette med suksess. Ved å bruke Trello kunne både kunde og oppdragsgiver følge prosjektutviklingen tett, samt være tilgjengelig for å svare på kommentarer vi måtte komme med på oppgaver under arbeid. Det var et ønske at vi skulle ta i bruk verktøyet. HVORDAN VI UTVIKLET MED TRELLO Figur 7: Trello Et brett ble opprettet under navnet Digipost for Android. Alle med tilknytning til prosjektet ble gitt tilgang til å lese, samt redigere. Videre opprettet vi følgende lister: Info: Informasjonskanal mellom oss, kunde og oppdragsgiver. Her la vi kort knyttet til prosjektet, men ikke direkte relevant for selve utviklingen av funksjonalitet. Milepæler: Tidsbestemte kort som utgjorde vår milepælsplan. Prioritert backlog: Funksjonalitet og ideer til funksjonalitet som enda ikke var ferdig utviklet. De forskjellige kortene ble markert enten Must have eller Nice to have avhengig av prioriteten. Under arbeid: Kort hentet fra prioritert backlog som det ble jobbet med å implementere. Trenger tilbakemelding fra Digipost: Ferdig funksjonalitet som trengte en vurdering/ tilbakemelding fra veileder. Ferdig (Beta): Funksjonalitet ferdig til betaversjonen. Ferdig (Versjon 1.0): Funksjonalitet ferdig til første versjon. Ferdig (Andre ting): Andre praktiske ting utført i sammenheng med prosjektet, men ikke direkte relevant til selve utviklingen av funksjonalitet. Gangen i implementering av funksjonalitet startet med at vi valgte ut det høyest prioriterte kortet i listen prioritert backlog. Deretter ble vi enige om hvem som skulle få ansvar for arbeidet. Den ansvarlige oppdaterte så kortet med sjekklister over hvilke deloppgaver som måtte utføres for å ferdigstille funksjonaliteten. Kortet ble deretter flytte over til under arbeid. Dersom det var nødvendig med tilbakemelding fra veileder var neste stopp trenger tilbakemelding fra Digipost. Hvis utbedringer var Side 7 av 38

8 nødvendig, ble det iterert tilbake til under arbeid. Hvis ikke ble funksjonaliteten ansett som ferdig og plassert i den riktige listen for ferdigstilte kort. Under hele utviklingsperioden hadde vi hatt en løsning for at oppdragsgiver og kunde skulle kunne laste ned en oppdatert utgave av applikasjonen. Hver gang et kort ble plassert i listen ferdig, ble det lastet opp en ny versjon for dem å laste ned og teste. Med dette oppnådde vi en kontinuerlig testing og et bra grunnlag for veileder å komme med tilbakemeldinger på vårt arbeid. VÅR ERFARING MED TRELLO Å jobbe med en smidig utviklingsmetodikk var en ny og lærerik prosess for oss i gruppen. Ved tidligere prosjekter har vi hatt langsiktige mål, og underveis ikke jobbet med små, konkrete delmål. Her fikk vi derimot erfare hvordan det var å jobbe med konkrete delmål underveis. Å utvikle i Trello ga oss også muligheten til å starte på kodingen umiddelbart etter konseptutviklingsfasen. Trello sin oppbyggning med kort som flytter seg fra fase til fase har vært en motiverende faktor for oss i gruppen. Vi har alltid hatt en følelse på hvordan vi ligger an, og kort har alltid blitt flyttet fra under arbeid til ferdig med et preg av stolthet. Trello har også vært en viktig kanal for kommunikasjon med veileder. Siden dette er et verktøy Digipost sine utviklere bruker daglig og alltid er pålogget, har det vært rask respons på våre spørsmål og kommentarer. KOMMUNIKASJON MED KUNDE/VEILEDER Gjennom utviklingsprosessen har vi hatt ukentlige møter med veileder og kunde. Her har vi gitt statusoppdateringer for utviklingen og drøftet eksisterende og ny funksjonalitet. Det har vært et forum for oppdragsgiver og kunde til å komme med deres tilbakemeldinger og forslag, samt for oss til å presentere vårt arbeid og komme med problemstillinger som er under arbeid. Disse møtene var veldig verdifulle under hele prosessen. Det at Digipost er en tjeneste som besitter privatpersoner sine konfidensielle brev, gir ikke rom for feil i sikkerheten til applikasjonen og ivaretakelse av personvern. I tillegg til de ukentlige møtene på Postgirobygget, har vi hatt sporadiske møter med veileder fra HiOA, Eva Hadler Vihovde. Temaet på disse møtene har vært planlegging av dokumentasjon underveis, strukturering og innhold i sluttrapporten. HiOAs veileder har hatt en mindre rolle i selve prosjektet, da vi følte oss relativt selvgående med hensyn til dokumentasjonen. Ved eventuelle spørsmål, var veileder derimot rask til å svare og korrigere eventuelle feil vi hadde gjort. Vi sitter igjen med et meget positivt inntrykk av arbeidsprosessen med vår veiledere. Kontinuerlig kommunikasjon og tilbakemelding bidro til å gjøre prosjektet så komplett og ferdig som overhodet mulig i den tildelte prosjektperioden. Side 8 av 38

9 PROSJEKTSTYRINGSDOKUMENTER ARBEIDSPLAN Ved fornuftig bruk av Trello til utvikling, vil du også få mye prosjektstyring med på kjøpet. Vi brukte verktøyet til å føre opp tidsbestemte arbeidsoppgaver og milepæler. Milepælene har vært fastsatt fra starten av, mens arbeidsoppgavene var mer flytende etter vurdering av fremdriften i prosjektet. Arbeidsoppgaver ble også på Trello knyttet til personen som jobbet med dem slik at det var lett for veileder å ta kontakt dersom det skulle være behov for oppklaring. FREMDRIFTSPLAN Fremdriftsplanen ga oss en oversikt over hvor vi burde være på hvilket tidspunkt. Tidsbestemte Trello-kort under listen prioritert backlog gjorde det lett for alle involverte i prosjektet å følge progresjonen. Fremdriftsplanen ble kontinuerlig justert for endringer, og var et nyttig verktøy i både planleggingen og utføringen av prosjektet. ARBEIDSLOGG Vår arbeidslogg har i hovedsak vært historien over commits på Github. Vi har fra starten av vært nøye på at commits skulle ha gode beskrivelser. På denne måte ville det være lett å se hva som er gjort til hvilken tid og av hvem. Github har også muligheten til å vise grafer basert på forskjellige parametere fra commit-historien. I tillegg til Github opprettet vi en konto på Twitter knyttet til prosjektet. Her kom vi med kontinuerlige oppdateringer på arbeidet som ble gjort. Dette var opprinnelig et ønske fra kunden for å nå ut til den mest entusiastiske delen av deres brukere. Siden vi la ut oppdateringer om funksjonalitet og design, ga dette også en mulighet for personer utenforstående prosjektet til å gi tilbakemeldinger underveis. Side 9 av 38

10 ARBEIDSFORHOLD Vi har i hovedsak arbeidet på Posthuset og på Høgskolen i Oslo og Akershus. Hvor vi har jobbet og når, har i stor grad vært avhengig av når vi skulle treffe veiledere. POSTGIROBYGGET I januar 2013 fikk vi utdelt adgangskort og faste plasser i 14. etg. på Postgirobygget, adgangskortene ga oss tilgang til bygget fra 07:00 til 22:00 på hverdager hele perioden. Siden vi hadde faste møter med ekstern veileder hver tirsdag, var det naturlig for oss å sitte her mandag til onsdag. Vi hadde tilgang til ansattkantine og spiste vi ofte lunsj sammen med kunde og oppdragsgiver. Vi hadde gratis tilgang til kaffemaskiner og på sene kvelder ble det bestilt pizza. HIOA På HIOA satt vi for det meste på Datatorget i 4. etg. i Pilestredet 35. Her var vi på torsdager og fredager. Figur 8: Utsikt fra kontoret på Postgirobygget VERKTØY Vi har benyttet oss av følgende verktøy og hjelpemidler for å gjennomføre hovedprosjektet: VERSJONSKONTROLL Et versjonskontrollsystem er programvare laget for å dele filer i prosjekter, og sørger for at endringer blir sammensmeltet. Versjonskontrollsystemer er essensielle for prosjekter med flere utviklere GIT MED GITHUB Git er et versjonskontrollsystem som vi tidligere har lært i forbindelse med andre prosjekter. Git har egne kommandoer, bl. a. pull og push, for synkronisering med andre repositorier. Dette muliggjør alle-til-allesynkronisering (ikke bare alle-til-en, 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 etter 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 uvedkommende kan ha endret innholdet uten at dette også vil oppdages. Git er både raskt og godt til sammenfletting (merging) av kode. Figur 9: Octocat, Github Side 10 av 38

11 Ved hjelp av Github, som er et web-basert hostingsystem for Git-prosjekter, har vi oversikt over hvem som har tilgang til hvem som jobber med prosjektet og hvilke endringer de gjør, samt oppgaver som må gjøres. Ved commit av endringer skrives en beskrivelse av endringen inn, som igjen kan sees av alle medlemmer på GitHub. Slik er det enkelt å se siste endringer gjort av andre. PROSJEKTHÅNDTERING TRELLO Trello er beskrevet tidligere i dette dokument. DOKUMENTASJON MICROSOFT WORD Microsoft Word er et tekstredigeringsprogram som gjør det enkelt å forfatte innhold, plassere grafikk og endre stiloppsett. GOOGLE DOCS Google Docs er et webbasert tekstredigeringsprogram som støtter at flere brukere skriver samtidig og har mulighet for å eksportere innhold som PDF eller Word-dokument. ADOBE PHOTOSHOP Adobe Photoshop er et bilderedigeringsprogram som gjør det enkelt å tegne og redigere bilder uten å forringe kvaliteten. Alle elementer i et dokument kan ligge i egne lag, dette gjør det lettere å kopiere og redigere enkeltelementer. DROPBOX Dropbox er en skybasert lagring og fildelingstjeneste som synkroniserer lagrede filer automatisk. UTVIKLINGSVERKTØY ECLIPSE Eclipse versjon 4, kodenavn Juno. Eclipse er en fullverdig Java IDE som har alt som skal til for å utvikle fullverdige Java applikasjoner med unntak av Java JDK. Eclipse ble konfiguert med formateringsreglene som brukes hos Digipost utviklere. JAVA DEVELOPMENT KIT (JDK) JDK er en programvareutviklings pakke for å utvikle, kompilere, debugge og overvåke java-applikasjoner. Side 11 av 38

12 ANDROID SDK Android SDK er en programvareutviklingspakke som gjør det mulig å utvikle Android-applikasjoner. Android SDK inneholder mange nyttige verktøy, emulator og eksempler på applikasjoner medfølgende kildekode. Følgende er de mest brukte verktøyene som inngår i Android SDK: ANDROID DEBUG BRIDGE (ADB) ADB er et verktøy for å opprette forbindelse mellom Eclipse og en enhet eller emulator. Over denne forbindelsen kan man overføre data begge veier. Brukes oftest til å laste en ny versjon av en applikasjon for så å få tilbakemeldinger fra enheten. DALVIK DEBUG MONITOR SERVER (DDMS) DDMS benytter seg av ADB til å feilsøke applikasjoner kjørende på enhet eller emulator. Her kan man feilsøke nettverkstrafikk, diskplass, minnebruk mm. LOGCAT Logcat benytter seg av ADB for å samle inn og kategorisere systeminformasjon fra en enhet slik at man enklere kan finne den informasjonen man er ute etter ved hjelp av filtering. ECLIPSE MEMORY ANALYZER Eclipse Memory Analyzer er et enkeltstående kjapt og effektivt minneanalyseringsverktøy som gjør det lettere å lokalisere objekter Garbage Collector (GC) ikke klarer å håndtere på ønsket måte, slik at de forårsaker minnelekkasjer i applikasjonen. ANDROID NDK Android NDK er et rammeverk som lar deg utvikle applikasjoner i native programmeringsspråk som C og C++. CYGWIN Cygwin er et verktøy som simulerer linux-funksjonalitet på Windows. APACHE ANT Apache ANT er et hjelpeverktøy for å bygge java-applikasjoner fra kommandolinjen. UTVIDELSER OG RAMMEVERK MAVEN Side 12 av 38

13 Maven er et verktøy for automatisk importering og bygging av Java-prosjekter. Det er eid av Apache Software Foundation. Maven bruker en XML-fil til å beskrive programvaren, avhengigheter til eksterne biblioteker og komponenter, byggerekkefølge, nødvendige plugin og lignende. Eksterne komponenter blir automatisk lastet ned fra Maven Central Repository og lagret i en lokal cache. JERSEY Jersey er en åpen kildekode-implementasjon for bygging av REST-tjenester i Java. JSON JSON er en tekstbasert struktur for enkel overføring av data. JACKSON Jackson er Java-bibliotek for prosessering av JSON til java-objekter. MUPDF MuPDF er et lettvekts bibliotek skrevet i C som konverterer sider i et PDF-dokument om til bilder, tekst i dokumentet er fortsatt søkbar ved visning. PHOTOVIEW PhotoView er bibliotek for å tolke bilder som ImageView på Android, PhotoView gitt ut som åpen kildekode under apache 2 lisens. POSTMAN REST CLIENT Postman REST Client er en Google Chrome utvidelse som gjør det enkelt å forstå eksterne REST APIer. Etter at man har opprettet en forbindelse til API via en autentiseringstjeneste som OAuth kan man åpne Postman og kjøre spørringer mot APIet, for så å motta svaret som JSON i en nettleser. Slik kan man gjøre spørringer og tolke svaret på en ryddig måte. ANALYSEVERKTØY GOOGLE ANALYTICS Google Analytics er et web-basert statistikk- og analyseverktøy som gjør det lett å samle inn og kategorisere data slik at man kan lage informasjon i form av bruksmønstre og andre relevante opplysninger. ANDROID Se eget dokument for innføring til Android operativsystem og dets retningslinjer for design (Vedlegg 1). Side 13 av 38

14 UTVIKLINGSPROSESSEN Vi vil i dette kapittelet beskrive prosessen med å utvikle applikasjonen i flere faser. Den første og innledende fasen er konseptutvikling. Neste fase tar for seg implementering av funksjonalitet og utforming av brukergrensesnitt i to separate deler. Vi har valgt å separere disse delene for å få frem det omfattende arbeidet som er gjort på begge fronter, og for ikke å blande prinsipper for god programmering med prinsipper for god design. Dette kapittelet vil også ta for seg utfordringer ved de enkelte funksjonaliteter. KONSEPTUTVIKLING Helt siden vårt første møte med oppdragsgiver og kunde har de vært klare på at det overordnede målet med applikasjonen er at den skal tilsvare den allerede eksisterende applikasjonen for ios, men med en Android brukefølelse. Vi stod relativt fritt i hvordan vi skulle gå frem for å nå målet, men fikk vite at dersom vi hadde behov for et ekstra par øyne kunne designansvarlig for Digipost stilles til vår disposisjon. Annet enn at applikasjonen skulle gjenspeile en Android brukeropplevelse, var den eneste begrensningen vi fikk at farger skulle passe kundens konsept. Vi vil i de følgende underkapitler beskrive hvordan vi kom frem til vårt konsept. DATAINNSAMLING Det finnes retningslinjer for å utvikle en god applikasjon for Android, men ingen fasit. For å danne et best mulig grunnlag for videre arbeid med konsept, samlet vi inn flere populære designmønstre og utforsket mulighetene rundt bruken av forskjellige komponenter i brukergrensesnittet. Vi ville komme frem til noe som kunne virke kjent for brukere av Android, men også ha et unikt preg over seg. MÅLGRUPPE OG BEHOV Digipost er en tjeneste som skal gi et alternativ til dagens fysiske postkasse, Digipost har hittil rundt unike brukere. En markedsundersøkelse basert på Our Mobile Planet ( sine nettsider på oppdrag fra Google viser at 39% av smarttelefonene i Norge har Android operativsystem. Det kommer også frem at denne fordelingen er omtrentlig lik for alle aldersgrupper. Vi anså det som sannsynlig at disse dataene også er representative for Digipost sin brukermasse. Vår målgruppe er brukere av Digipost med en Android smarttelefon som vi optimistisk anslår at er * 0.39 = unike brukere. Siden Digipost i dag er en relativt avansert tjeneste antar vi at alle brukere har smarttelefon og derfor inngår i målgruppen. I juni 2011 lanserte Digipost en applikasjon for ios. Det har siden den tid vært stor etterspørsel på deres forumer etter en applikasjon også til Android. Det ble utviklet en webløsning tilpasset mobile enheter, men denne løsningen gir ikke inntrykk av å være utviklet for Android. En selvstendig applikasjon utviklet for Android gir langt flere muligheter til å utnytte mobilens egenskaper. GRUPPEMØTER OG BRAINSTORMING Etter datainnsamlingen startet vi en periode med regelmessige grupemøter. På disse møtene brukte vi aktivt brainstorming og diskusjon for å komme frem til det beste resultatet. Den kunnskapen vi hadde tilegnet oss ved å utforske populære mønster for Android design viste seg å være av stor betydning. Vi opplevde at vi på Side 14 av 38

15 dette tidspunkt hadde gode forutsetninger for å komme frem til en god løsning, hvilket også viste seg i den faglige dybden i diskusjonene. Når vi var kommet til enighet om et forslag til konsept tegnet vi dette opp som en skisse. Denne prosessen gjentok vi flere ganger for å ha flere alternativer og presentere kunden. Iterasjoner her gjorde også at forkastede elementer til et konsept kunne gjenbrukes i et annet. Vi oppnådde på denne måten stor variasjon i konseptene, men alle med den likhet at de hadde en gjennomført Android brukeropplevelse. PRESENTASJON AV KONSEPT FOR OPPDRAGSGIVER OG KUNDE Den 28. januar hadde vi et møte hos kunden hvor vi presenterte våre forslag til konsept, hvor vi i etterkant kom frem til et felles konsept ved hjelp fra Olav Bjørkøy, designansvarlig i Digipost, og innspill fra veileder og produktsjef Martin Bekkelund om hvilke ideer de likte best. Konseptet det ble kommet frem til minner om konseptet til applikasjonen for ios. Forskjellen ligger i hvordan ting blir presentert. Komponentene som blir brukt i brukergrensesnittet er alle typisk Android. Farger er tilpasset Digipost sitt overordnede konsept. I grove trekk inneholdt konseptet følgende: En innloggingsskjerm med linker til juridisk informasjon, samt hvordan opprette en konto i Digipost for nye brukere. En toppmeny i hovedvinduet som skal holde seg lik for postkassen, kjøkkenbenken, arkivet og elektroniske kvitteringer. Bruk av fingerbevegelser for å navigere seg mellom postkassen, kjøkkenbenken, arkivet og elektroniske kvitteringer. Visning av brevinnhold i et eget vindu med en toppmeny og bunnmeny som gjenspeiler toppmenyen brukt i hovedvinduet. UTVIKLING MED ANDROID SDK OG ANDROID NDK I dette kapittelet beskrives utvikling av funksjonalitet og brukergrensesnitt og de utfordringene vi møtte i forbindelse med dette. Vi beskriver forhold som har påvirket applikasjonen og kundens Rest-rammeverk det blir kommunisert med. Det ble hensiktsmessig å inkludere utfordringene i beskrivelsen av funksjonaliteten for å forstå problemene bedre. FORDELER OG ULEMPER MED NATIVE UTVIKLING Native utvikling i Android NDK kan gi en betydelig øking i ytelse for enkelte applikasjoner eller operasjoner i en applikasjon. Generelt vil det være en fordel å programmere C i Android NDK for programmer som prosesserer mye data, har et høyt CPU-forbruk eller foretar tunge grafikkoperasoner. Å bruke native kode vil altså ikke nødvendigvis forbedre ytelsen til en applikasjon, men det vil alltid øke kodens kompleksitet. Du har heller ikke tilgang til det brede klassebiblioteket i Android SDK og Java. Det er generelt anbefalt å bruke Android SDK med mindre applikasjonen som skal utvikles foretar liknende operasjoner som de beskrevet tidligere i avsnittet. Side 15 av 38

16 OPEN SOURCE Det var en betingelse fra første stund at koden vi produserte skulle være åpen kildekode. Det ble opprettet en katalog for vårt prosjekt på Github under kundens konto. Vi var de eneste som fikk skriverettigheter med unntak av produkteier. En av hovedgrunnene til at kunden ønsket kildekoden som åpen var for å inspirere andre til å utvikle mot Digipost. Det skulle være mulig for andre å hente inpirasjon eller ta utgangspunkt i vår kode for videre utvikling. Dette ble også en pådriver for oss mot å skrive ryddig og semantisk riktig kode. Applikasjonen er lisensiert under Apache 2.0. Denne lisensen krever at det legges til en kopirettsnotis på alle filer i kildekoden og også en kopi av lisensvilkårene lagt ved prosjektet. Apache 2.0 gir andre utviklere tillatelse til å gjenbruke, modifisere og redistribuere kildekode i prosjektet i henhold til lisensvilkårene (Vedlegg 6). REST-RAMMEVERKET Vi fikk i første møte med kunden en introduksjon til Digiposts REST-API og fikk beskjed om det var kritisk å komme raskt i gang med utviklingen og at vi ble kjent med dette så fort som mulig. Veileder sendte oss i etterkant av møtet en omfattende e-post med blant annet henvisning til en delvis ferdig dokumentasjon av API-et som lå på utviklersiden til Digipost.no, i tillegg ble det tipset om diverse lesetips om REST. Det ble her også opplyst om Chrome-utvidelsen Postman REST-Client som kunne benyttes til å utforske API-et. Et verktøy vi fant hadde stor nytteverdi. I begynnelsen virket API-et stort og uoversiktlig, men ved å ta tilnærmingen stegvis og samtidig få strukturen visuelt ved hjelp av POSTMAN ble læringskurven brattere enn forventet. Dette verktøyet kombinert med dokumentasjonen til API-et gjorde at vi kom raskt igang med kommunikasjon mot tjeneren. Det var essensielt med en grundig forståelse av REST API-et fra begynnelsen for å kunne gjøre klient-implementasjonen riktig fra dag en. Side 16 av 38

17 IMPLEMENTERING AV FUNKSJONALITET LOGG INN/UT På oppstartsmøtet ble vi enig med veileder om at første milepæl for prosjektet ville være å utvikle en prototype som logger deg inn i Digipost ved hjelp av OAuth2 og viser navnet til den innloggede personen. OAuth2 var en ny teknologi for oss, så i startfasen brukte vi tiden til å gjøre oss kjent med og forstå rammeverket. OAuth2- implementering for mobile enheter var nytt også for utviklerne i Digipost da applikasjonen for IPhone benytter seg av en annen løsning for innlogging. For at prototypen skulle tilfredsstille kravene satt av kunden for sikker innlogging, måtte vi lese oss opp på sikkerhet i Java under bruk av https-overføringer, samt kryptografi og validering av signaturer. Innloggingen er en avansert prosess med flere steg, nærmere forklart i produktrapporten. 25. januar hadde vi er prototype der det kunne logges inn som bruker i Digipost og se innholdet i postkassen. Dette var en viktig milepæl da resten av funksjonaliteten er avhengig av informasjonen som blir mottatt fra Digipostserveren etter pålogging. Vi var under hele prosessen med å utvikle denne løsningen svært nøye på de sikkerhetsaspekter som spillte inn. Dette var en faktor som gjorde at programmeringsarbeidet gikk mer langsomt, men på den andre siden var den ferdige løsningen robust og i henhold til alle sikkerhetskrav. Vi anså dette som viktig å gjøre 100 prosent fra starten ikke bare på grunn av vår egen trygghet på oppgaven, men også at oppdragsgiver og kunde tidlig kunne se resultatet av- og gi oss tillitt og stort ansvar. Figur 10: OAuth2 innloggingsvindu KONTOINNHOLD Nå var det på tide å få brukerens kontoinnhold ut på skjermen. Med innhold menes en representasjon av dataene i de forskjellige delene av Digipostkontoen: Postkassen, Kjøkkenbenken, Arkivet og Kvitteringer. Dette måtte hentes tjener, vises på en oversiktlig måte, samt legges tilrette for enkel aksess til underliggende data. API-et er som tidligere beskrevet en webbasert REST-tjeneste. Det krevde en god forståelse av hvordan API-et fungerte. For å lettere kunne forstå dette, benyttet vi Postman REST-client. Vi ønsket å gi brukeren mulighet til å forsette og interagere med applikasjonen mens kontoinnholdet blir lastet ned i bakgrunnen. Vi bestemte oss derfor å kjøre alle nettverkspørringer i asynkrone tråder og ikke på applikasjonens egen hovedtråd. Android har en innebygd funksjon for dette kalt ASyncTask. Side 17 av 38

18 Vi ble tipset av veilederen vår om at det kunne være lurt å benytte et eksternt verktøy for overføring av data mellom tjener og klient, Jersey. Med Jersey kunne man også benytte Jackson, et JSON-prosesseringsverktøy som ville gjøre det veldig enkelt å få responsen fra tjeneren inn i objekter, via eget Jackson-oppset i modellklassene for objektene. Dette var verktøy de selv benyttet og hadde god erfaring med. Dette utsatte den ferdige funksjonaliteten en liten stund fordi vi måtte sette oss inn i disse ukjente verktøyene, men vi hadde i forkant utviklet en ren java-versjon som fungerte, slik at når vi ikke jobbet med akkurat denne problemstillingen kunne vi jobbe videre med data fra API-et tilgjengelig. Å hente hele brukerprofilen med all metadata var en sammensatt prosess som krevde en rekke nettversspørringen til å kjøre sekvensielt. VISE PDF Funksjonalitet for visning av PDF viste seg å være en større utfordring enn forventet. Android SDK har ikke et innebygd bibliotek for å utføre denne oppgaven. Alternativene var derfor enten å sende den aktuelle pdf til en annen selvstendig applikasjon, som Adobe Reader, via et intent. Dette krever imidlertid at pdfen kan nås med en filsti, hvilket betyr at filen må lagres på enhetens SD-kort. Siden det var et krav at filer som ble hentet fra Digipost skulle lagres kryptert hvis de skulle lagres, ble dette et problem. Vi hadde ikke utviklet en løsning for dette, og det var heller ikke tenkt å påstartes i første versjon av applikasjonen. For å unngå kryptering av filer, ble de istedet lagret midlertidig i enhetens minne. Den kan da ikke hentes ved hjelp av en filsti. Løsningen fallt på MuPDF, beskrevet tidligere under Verktøy. Det måtte gjøres en modifikasjon i den native C-koden for å kunne åpne en pdf lagret i minnet siden MuPDF i utgangspunktet kun støtter åpning ved hjelp av filstier. Dette krevde at vi satt oss inn i et hittil ukjent språk, og omfattende kildekode, samt bruk av Android NDK sammen med Android SDK. Grunnen til at MuDF bruker Android NDK er at sider i et pdf-dokument blir rendret til bilder som kan vises. Det gikk med mye tid til å forstå kildekoden til MuPDF skrevet i C. Ingen av oss hadde nevneverdig erfaring med språket fra før og vi anså det som viktig å forstå gangen i hvordan en pdf-fil ble åpnet og hva de forskjellige Figur 11: Visning av PDF metodekallene utførte. Dette gjorde at vi fikk en lettere jobb med å innsnevre kunnskapen vi måtte tilegne oss for å ta i bruk biblioteket, som igjen førte til at vi totalt sett sparte tid. En prototype for å åpne pdf ble utviklet og testet. Denne viste at visning av pdf-filer fra minnet fungerte bra med den modifiserte koden som er beskrevet mer i detalj i produktdokumentasjonen. Før denne kode kunne implementeres måtte den bygges som et native bibliotek med Android NDK. Siden dette ble gjort Side 18 av 38

19 på en maskin med Windows var det her nødvendig å ta i bruk Cygwin og Apache ANT. Det native biblioteket ble implementert sammen med applikasjonens kildekode for så å integreres sammen med funksjonene for å hente pdf som en bytestrøm fra Digipost sitt API. Et annet problem som imidlertid oppsto før vi det hele tatt fikk aksessert pdf-filen på tjener var at det ikke var implementert tilgang for vår applikasjon til å hente selve innholdet av filer fra API-et. På spørringer fikk vi tilbake HTTP-statuskoder som tilsa at vi ble nektet adgang. Vi tok derfor kontakt med utviklerteamet til kunden og opplyste om dette. Dette utsatte implementasjonen 2-3 dager fordi det da måtte gjøres endringer på tjener-siden, som ikke kunne lanseres før det var ny produksjonssetting. VISE KVITTERINGER Kvitteringerløsningen til Digipost er utviklet og driftet av en tredjepartsaktør, bedriften dsafe AS. Når det gjøres spørringer mot denne løsningen hentes kvitteringene fra tredjeparts tjener. Å hente kvitteringer skulle ikke være et problem fordi vi på dette tidspunktet hadde god kjennskap til API-et. Likevel oppsto det komplikasjoner. URI-en til kvitteringene ble utelatt i respons fra tjener. Vi dobbeltsjekket med Postman REST-Client som ikke så ut til å ha det samme problemet. Vi forsto derfor at det måtte være noe med akkurat vår kommunikasjon med tjeneren. Vi drøftet dette med BEKK-utviklerne, som driftet API-et og hadde tilgang til loggene. Løsningen på problemet var at de hadde utelatt (eller glemt?) URI-en til kvitteringer i OAuth2- spørringer mot API-et. De fortalte at dette var en feil fra deres side som skulle bli rettet ved første produksjonssetting. Uheldigvis for oss var det ikke planlagt en ny produksjonssetting på halvannen uke. Vi var derfor nødt til å lage en midlertidig løsning på problemet. Vi visste hvordan URI-en skulle se ut og hvilke parametere som skulle med. Vi bygget derfor opp en tilsvarende URI ved hver spørring mot kvitteringene som baserte seg på et ID-nummer som var unikt for kontoen. Denne ID-en skulle plasseres som parameter i URI-en. Nå kunne vi endelig motta kvitteringsobjektene. Vi så på forhånd ved hjelp av Postman at tredjepartstjeneren ga Figur 12: Visning av kvittering oss muligheten til å hente innholdet både som PDF og HTML. Vi valgte HTML fordi dette ville redusere datatrafikken, samt forenkle selve visningen. En annen viktig faktor for valget var at vi ønsket av kvitteringen skulle forholde seg som en liste, og ikke som en rekke sider. En enkel HTML-visning i et Webview ville dekke våre behov. Side 19 av 38

20 VISE BILDER Det å kunne vise bildefiler var ikke en prioritert funksjonalitet. Hovedsaklig er det PDF som blir mest brukt i Digipost. Bildevisning ble derfor implementert sent i prosjektet som en nice to have feature. Grunnen til at vi valgte bildevisning før visning av eventuelle andre filtyper er muligheten til å arkivere private filer i Digipost. En vurdering ble tatt på at etter PDF ville sannsynligvis bilder være populært å lagre i et sikkert arkiv. Som beskrevet under PDF ovenfor, er det ikke mulig å bruke enhetens programmer for bildevisning med mindre filen som skal åpnes er lagret på disk eller blir hacket til å fremstå som en nettside. Vi måtte igjen implementere en egen løsning for dette. Å lage en løsning fra bunn av ville vært for mye arbeid til at bildevisning ikke ble sett på som en en prioritert funksjonalitet. Etter vurdering av forskjellige open source biblioteker, grunnet brukertilbakemeldinger og en diskusjon rundt våre behov, valgte vi PhotoView, en egendefinert klasse for bildevisning basert på Android sitt ImageView. Vi anså det som viktig å tilby naturlige patterns slik at zoom og navigering i innzoomet modus skulle være en smal sak for sluttbrukeren. Dette biblioteket møtte våre krav, i tillegg til Android sine egne krav for designretningslinjer. SØKEFUNKSJONALITET Mengden brev brukere av Digipost mottar, arkiverer eller legger på kjøkkenbenken for fremtidig arbeid vil øke i takt med at stadig flere bedrifter velger å nå sine kunder gjennom digital post. For å effektivt kunne finne igjen innhold var det nødvendig med en løsning for søk. To mulige implementasjoner ble vurdert. Den første var en standard løsning hvor brukeren skriver inn en søkestreng for så å vise resultater basert på denne strengen i et selvstendig vindu. Den andre gikk ut på filtrering av de allerede populerte listene basert på en søkestreng. Filtreringssøk gir den fordelen at søket gjøres live, det vil si at resultatet oppdateres for hver endring som blir gjort i søkestrengen. Vi anså sistnevnte som det beste alternativet. Med filtreringssøk kan det lett presenteres deler av et større utvalg på en effektiv og brukervennlig måte. Det gir en dynamisk effekt av å kunne gruppere i utgangspunktet ugruppert data som også nettsidene til Digipost benytter seg av. Vi valgte å bruke filtreringssøk. Dette ble vurdert til å være den mest gunstige løsningen siden søket skulle omfatte brevenes metadata og ikke selve innholdet. Med metadata menes avsender, emne og dato. Vi gjorde alle disse variablene filtrerbare og det er mulig å kombinere disse i søkestrengen. Figur 3: Filtreringssøk Side 20 av 38

21 FLYTTING OG SLETTING AV BREV,DOKUMENTER OG KVITTERINGER Muligheten til å organisere brev og dokumenter var en viktig funksjon som var høyt ønsket av kunden. Det var i utgangspunktet bare ønske om kunne gjenspeile funksjonaliteten til nettsiden som ga mulighet til å flytte og slette dokumenter enkeltvis i selve visningen av innholdet av et dokument. Vi så det som nødvendig å utvide denne funksjonaliteten med noe vi kalte for multiselect, som gjorde det mulig å gjøre operasjoner på flere dokumenter samtidig. Dette var noe vi mente smarttelefonbrukere forventet å finne i slike typer applikasjoner. API-et hadde bare støtte for operasjoner på et brev av gangen. Det var derfor naturlig å implementere dette som en rekke av enkeltoperasjoner, opplevd av brukeren som en enkeltoperasjon på flere dokumenter. Dette gikk smertefritt for sletting, men ikke for flytting. Som forklart i introduksjonen til REST-tjenesten blir alle brev, dokumenter og kvitteringer sendt til klienten i form av JSON-objekter med blant annet delete- og update-uri. Mot disse kjøres det henholdsvis HTTP-DELETE og HTTP- POST. Vi hadde på dette stadiet integrert Jersey i alle nettverkspørringene våre. Det viste seg at fra mobile enheter som Android- og ios-enheter støttet ikke Jersey POST-spørringer med JSON-innhold. I våre HTTP-POST må man legge ved JSON som inneholder blant annet en lokasjonsvariabel som forteller til hvilket sted dokumentet skal flyttes. Ved forsøk på å flytte krasjet applikasjonen, og feilmeldingene ga lite mening. Etter mye undersøkelse Figur 14: Flytting av flere dokumenter viste det seg at dette var et kjent problem og det fantes ingen work-arounds vi fikk til å fungere. Denne spørringen måtte derfor reimplementeres med en ren javametode. Den samme funksjonaliteten for sletting ble implementert for kvitteringer. VEDLEGG Kort tid før planlagt lansering av applikasjonen i Google Play kom det en utvidelse av API-et. Det var nå mulig å sende dokumenter med flere vedlegg. Vi måtte prøve å få implementert dette før lansering. Dette krevde en restrukturering av noen modellklasser, ny kode og logikk, men skapte ikke store problemer. Side 21 av 38

22 TESTING Testing og prosessen rundt dette er beskrevet i Testrapporten. SIKKER LAGRING For at applikasjonen skulle bli vesentlig bedre enn en mobiltilpasset nettside var det viktig at den kunne lagre data på en sikker måte. Dette skulle vise seg å bli vår største utfordring, ikke fordi vi ikke kunne lage sikre løsninger, men fordi vi måtte finne kompromisser mellom sikkerhet og brukervennlighet. Fra et brukervennlighetssynspunkt burde man gi bruker tillitt til applikasjonen uten å pålegge bruker slitsomme rutiner og synlige sikkerhetsmekanismer som tar fokus bort fra hovedfunksjonaliteten. Siden applikasjonen utvikles som åpen kildekode kan man ikke basere sikkerheten på at en potensiell angriper ikke vet hva som skjer, dette begrenser alternativene for sikker lagring. Siden det ofte er veldig begrenset med minne og regnekraft på en håndholdt enhet, fokuserte vi på og kun kryptere og dekryptere det absolutt nødvendige, og heller laste ned annen data fra nettet. Siden bruker kan ha mange filer på opptil 100 MB lagret hos Digipost, kunne det ha blitt problematisk å kryptere og dekryptere disse uten at det skulle oppstå for mange problemer og systemkrasj. Vi valgte derfor kun å kryptere refresh token, så kan brukere heller laste og åpne dokumenter etter behov. Vi inkluderte filstørrelse i visningen slik at brukerne får forståelse for tiden det tar å åpne dokumenter. Som beskrevet i Android-dokumentet, må man kryptere data før det lagres på enheten for at det skal være sikkert lagret. Etter mye leting på internett og egen utforsking satt vi igjen med disse tre alternativene - og vi endte opp med alternativ 3. ALTERNATIV 1: Den vanligste måten å gjøre dette på er å kryptere innholdet basert på et applikasjonsspesifikt passord, dette passordet må lages en hash av og denne hashet lagres på telefonen. Når man skal dekryptere innholdet, må man skrive inn passordet som så blir hashet og sammenlignet med den lagrede hashet og hvis de er identiske kan innholdet dekrypteres med passordet man tastet inn. Hovedproblemet med denne løsningen er at vi hadde blitt nødt til å lagre hashen på enheten og da kan en angriper alltids få tak i den siden den igjen ikke er kryptert. Siden bruker sannsynligvis ville forventet å bruke fire siffer som passord kunne en angriper uten store vanskeligheter ha generert et passord som produserte en hash identisk med den lagrede hashen ved hjelp av et brute force angrep. Dette gjorde at løsningen ikke var sikker nok og måtte forkastes. ALTERNATIV 2: Et annet alternativ var å ikke lagre refresh token, og la access token ligge i minne slik at bruker hadde blitt nødt til å logge inn med personnummer hvert 15 minutt. Dette hadde gjort applikasjonen sikker i forhold til tyveri siden ingenting hadde vært lagret, men samtidig forsvinner litt av poenget med applikasjonen siden den ville ha virket mer som en nettside hvis bruker måtte logge inn hver gang på samme måte som man gjør i en nettleser. Side 22 av 38

23 ALTERNATIV 3: Kunden, oppdragsgiver og vi ville veldig gjerne lagre refresh token så bruker slipper å logge inn med personnummer og passord hvert 15 minutt. Siden kreves at refresh token skal være kryptert om det skal lagres, endte vi opp med å kryptere det basert på Android sin egen skjermlås ved hjelp av Android KeyStore. På denne måten blir brukers enhet generelt sett mye sikrere og det blir mye vanskeligere for en angriper å få tilgang til det dekrypterte refresh tokenet. Skjermlås benytter seg av innebygde metoder for å sette skjermlås om bruker ikke allerede har, på denne måten kan bruker velge mellom det skjermlås-alternativet bruker liker best. Om ikke bruker allerede har skjermlås er alternativene vanligvis egendefinert mønster, pin eller passord. Siden flere store bedrifter i Norge krever at ansatte har skjermlås med pin eller passord på sine enheter, antar vi at dette er en sikkerhetsmekanisme som er godt utprøvd og kan stoles på. Siden det ikke er så mange applikasjoner som krever skjermlås vil antageligvis noen brukere reagere. Det kan virke unødvendig siden de ikke er vant til å ha det, men slik vi ser det er det absolutt nødvendig for å lagre innhold på tilfredsstillende måte. Når kunden en gang i fremtiden kommer til å oppdaterere applikasjonen, er det mulig at de kommer til å endre sikkerhet. Det er da viktig å huske at den versjonen vi utviklet mest sannsynligvis vil eksistere på Figur 15: Skjermlås enkelte enheter som ikke oppdaterte applikasjonen. Derfor er det viktig at vår utgave har god nok sikkerhet med tanke på innhold. Skjermlåsen kan ikke fjernes med mindre man fjerner legitimasjonslageret som benytter seg av skjermlåsen. Dette gjøres enkelt inne på enhetens egen meny for innstillinger. Side 23 av 38

24 MINNEBRUK En viktig ting å tenke på når det utvikles til mobile enheter er at det ofte er begrensede ressurser i forhold til en vanlig datamaskin spesielt hva gjelder minne. Etterhvert som applikasjonen ble større og mer funksjonalitet implementert, meldte det seg enkelte feilmeldinger angående manglende minne. Disse feilmeldingene kom når store pdf- eller bildefiler skulle åpnes. Det viste seg at feilsøking basert på tilbakemeldinger fra Android SDK var umulig. Feilmeldingene oppgav ingen informasjon om hvor feilen hadde oppstått. Løsningen var å ta i bruk Memory Analyzer. Android SDK har en innebygd funksjon kallt Dalvik Debug Monitor Server (DDMS). Denne utvidelsen kan benyttes til å lagre en fil som inneholder informasjon om hva de enkelte komponenter i applikasjonen bruker av minne. Denne filen kan så åpnes i Memory Analyzer for en grundig analyse av minnebruk. Det vi ved hjelp av Memory Analyzer fant, var at et objekt av en dialogboks ble hengende igjen i minnet, selv etter at den var blitt fjernet. Dette opptok mye av applikasjonens totalt tildelte minne, hvilket førte til krasj dersom store filer ble forsøkt åpnet. Ved analyse i sanntid oppdaget vi også at GC innebygd i Java brukte lang tid på å frigjøre minne etter at en fil hadde blitt vist og deretter lukket. Dette skapte problemer dersom to store filer ble åpnet med raskt mellomrom. Løsningen på dette var å aktivt be GC starte når filen ble lukket. Figur 17: Memory Analyzer Side 24 av 38

25 UTFORMING AV BRUKERGRENSESNITT Neste utfordring var å finne en god løsning på hvordan vi skulle fremstille informasjonen for bruker. Vi var selvfølgelig påvirket av hvordan nettsiden og ios-applikasjonen så ut, men både vi og kunde var fast bestemt på å gi bruker en renest mulig Android-brukeropplevelse. Siden vi fikk så mye frihet, ønsket vi å lage et flatt og moderne grensesnitt uten så mye skygger, 3D-effekter og gradienter, vi følte dette valget er en økende trend i utformingen av grensesnitt blant dagens applikasjoner. Vi fant store mengder retningslinjer og tips på nettet samt et internt styringsdokument for Posten. Samtidig ble det innført noen nye trender og patterns i den relativt nye versjonen av operativsystemet, Android 4.0 som vi har som et minstekrav. For å forstå beslutningene vi har tatt, er det nødvendig å forklare kortfattet hvordan de forskjellige elementene fungerer. Når vi arbeidet med grensesnitt lagde vi ofte mockups i Photoshop eller tok skjermbilder av applikasjonen, deretter delte vi det med oppdragsgiver på Trello eller med brukere på sosiale medier for så å lytte og reflektere på tilbakemeldingene. Slik fikk vi ofte bekreftet eller avkreftet våre tanker om hvordan Androidbrukergrensesnitt burde være. Vi fikk mange konstruktive tilbakemeldinger og det skulle vise seg å være en veldig verdifull prosess for sluttresultatet. Vi lot testbrukere bruke applikasjonen foran oss samtidig som vi observerte og noterte hvordan de prøvde å bruke funksjonene uten forklaring. Dette lot oss få et godt innsyn i brukerens til tider frustrerende verden. NAVIGASJONSVALG Av erfaring vet vi at brukere ikke benytter seg av applikasjoner som har ulogisk navigasjon, dermed var det viktig for oss å gjøre navigasjonsopplevelsen så god som mulig. TOPPMENY Øverst på skjermen i Android applikasjoner finnes det ofte et område kalt toppmeny hvor man har logo, hovednavigasjon og ytterligere knapper. Dette område blir ofte laget ved å benytte en innebygd klasse i Android som heter Action Bar. I starten av utviklingsprosessen benyttet vi oss av en standard Action Bar, men siden vi ville ha flere muligheter valgte vi å lage en egen layout for dette området. Vi ville blant annet ha muligheter til å kunne skjule hele menyen, dra den ned for flere valg, og variere intern layout i større grad. Vi tror dette valget vil lønne seg over tid siden applikasjonen sannsynligvis vil bli videreutviklet i og ny funksjonalitet vil bli implementert. Figur 18: Toppmeny For at brukere som er vant til standard Action Bar skal kjenne seg igjen, prøvde vi i høyest mulig grad å etterligne utseende til denne. Når bruker skal søke blant brev, dokumenter eller kvitteringer bytter varierer vi innholdet i toppmenyen med en View Switcher. Når man trykker på søkeknappen, vises det et søkefelt med passende tekst, oppdateringsknappen, tastatur og popupknappen. Når man trykker på tilbakeknappen vil søkefeltet og tastaturet fjernes, deretter vil Side 25 av 38