Bachelorprosjekt i informasjonsteknologi Øyvind Årset Alexander Jensen Maaby Gruppe 29

Transkript

1 Bachelorprosjekt i informasjonsteknologi 2015 Øyvind Årset Alexander Jensen Maaby Gruppe 29

2 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo PROSJEKT NR TILGJENGELIGHET ÅPEN Telefon: Telefaks: BACHELORPROSJEKT HOVEDPROSJEKTETS TITTEL M/S Norge PROSJEKTDELTAKERE Øyvind Årset Alexander Jensen Maaby OPPDRAGSGIVER Steinar Årset s189099@stud.hioa.no s189101@stud.hioa.no DATO ANTALL SIDER / BILAG 59/28 INTERN VEILEDER Torunn Gjester torunn.gjester@hioa.no KONTAKTPERSON Steinar Årset steinar.aarset@gmail.com SAMMENDRAG Applikasjon for å dele bilder og tekst fra tur og applikasjon for å følge prosjektet M/S Norge på mobil. 3 STIKKORD Android Applikasjon M/S Norge 1

3 Innhold Forord... 6 Bakgrunn for prosjektet Mål Effektmål Resultatmål Læringsmål Kortfattet Kravspekk På Langs På Topp Backend... 9 Produktrapport Forord Produktet På langs Hovedmenyen Turdelen Følg oppdragsgivers tur Blogg Bildegalleri På topp Hovedmeny Legg ut bilde på Instagram/Del et øyeblikk Nytt blogginnlegg Backend Design Innledning Applikasjonens utforming Hovedmenyen Turdelen

4 4.2.3 Følg oppdragsgiver sin tur Blogg Applikasjonens utseende Størrelse på elementer Knapper Fargevalg Farger og tilgjengelighet Logo Bilder Navigasjon Hovedmenyen Tilbake- og opp-knappen Fysiske knapper ActionBar Batteriforbruk GPS Nettverk Skjermstørrelser Språk API-versjon Oppdragsgivers applikasjon Research Tur-delen Ren GPS Ren skritteller GPS + Skritteller løsning Verktøy og teknologier Android Studios Git/Github Dropbox Google Drive/Docs Skype

5 Facebook Paint.net Inkscape Creately Prosessrapport Planlegging og metode Arbeidsfordeling og samarbeid Kommunikasjon I gruppa Med oppdragsgiver Med veileder Kompetanseutvikling Planlegging og metodikk Dokumenter Prosjektside på nett Utviklingsmodell Versjonskontroll og backup Diagrammer og modeller Gantt-skjema Gantt-skjema endringer Utviklingsprosessen Utredningsfasen Forprosjektet Produksjonsfasen februar - 25.februar februar - 16.mars mars - 2.april april - 21.april Problemstillinger underveis Manglende design profil Dokumentasjonsfasen Testrapport

6 7 Testing Verktøy og testenheter Testing Testing underveis Forandringer på bakgrunn av testing Skritteller fjernet fra turdel Færre knapper i turdel Bildegalleri i applikasjonen Informasjon om M/S Norge Brukertesting Avsluttende del Nytteverdi For applikasjonens brukere For oppdragsgiver På topp Videre utvikling Læringsutbytte Konklusjon Ordliste Kilder Vedlegg

7 Forord Denne rapporten er resultatet av et hovedprosjekt ved Høgskolen i Oslo og Akershus våren Oppgaven var å produsere to Android applikasjoner som skulle gjøre prosjektet M/S Norge lettere å følge. I denne rapporten vil vi presentere prosjektet M/S Norge, hvordan og hvorfor vi har laget disse applikasjonene. Vi vil først og fremst takke oppdragsgiver Steinar Årset for muligheten til å være en del av dette prosjektet. Vi vil også takke vår interne veileder Torunn Gjester som ukentlig har kommet med tilbakemeldinger og ideer som har vært viktige for resultatet av dette prosjektet. Bakgrunn for prosjektet M/S Norge er et prosjekt som er utført i samarbeid med MS-forbundet og gitt økonomisk støtte fra ExtraStiftelsen. Prosjektet går ut på at oppdragsgiver Steinar Årset skal på tur fra Lindesnes til Nordkapp. Oppdragsgiver er selv rammet av sykdomen Multippel Sklerose og gjennomfører prosjektet for å motivere andre rammet av sykdomen. Det skal også produseres en dokumentarfilm av turen. Oppdragsgiver ønsket å øke tilgjengeligheten til prosjektet ved å tilby en egen løsning for mobile enheter som supplementerer nettstedet og som samtidig skal gi en ekstra motivasjon for å få folk selv ut på tur. 6

8 1. Mål Målet med prosjektet er å hjelpe oppdragsgiver å nå flest mulig med sitt budskap om tur-glede, og vise hvor vakkert landet vårt er. Samtidig som det skal skape motivasjon for å få flere ut på tur. 1.1 Effektmål Systemet skal gjøre det enkelt for oppdragsgiver å dele blogg-innlegg og bilder på nettet. Systemet skal gjøre det lettere å følge oppdragsgiver på tur fra Androidmobiltelefoner. Systemet skal motivere andre til å komme seg ut på tur. Figur 1.1: Den planlagte flyten i systemet. 1.2 Resultatmål Det skal utvikles et system for android som gir oppdragsgiver mulighet til å publisere tekst og bilder fra sin egen mobiltelefon. Det er viktig at dette kan gjøres på en enkel måte da oppdragsgiver potensielt kan komme til å håndtere denne delen av systemet 7

9 utendørs. Det er også viktig at dette skjer på en måte som gjør at mobilen ikke bruker unødvendig store mengder med strøm, da mulighetene for å lade opp mobilen kan variere. Materialet som oppdragsgiver publiserer skal videre gjøres tilgjengelig for allmenheten gjennom en nedlastbar Android-applikasjon. Systemet skal også bruke data fra en GPS-sender for å gjøre det mulig å følge hvor oppdragsgiver befinner seg til enhver tid. Det skal også være mulig for brukere å sette seg egne ukemål, og gjennomføre turer som registreres i applikasjonen. Dersom ukemålene gjennomføres belønnes brukeren med unike bilder fra oppdragsgivers tur. 1.3 Læringsmål Vi ønsker gjennom dette prosjektet å sette oss bedre inn i å utvikle omfattende applikasjoner for Android. Vi ønsker også å tilegne oss erfaring rundt hvordan det er å jobbe med en reell oppdragsgiver. Spesielt ønsker vi å utvikle kompetansen rundt hvordan det er å publisere en applikasjon fra idé, helt til den ligger på Google Play. 2. Kortfattet Kravspesifikasjon For å løse oppgaven har vi valgt å dele systemet i tre deler. En android-applikasjon som skal gjøre det mulig å følge oppdragsgiver på tur, samt oppfordre brukeren til å komme seg ut i naturen selv. Denne har vi kalt På Langs. En applikasjon som oppdragsgiver kan benytte seg av ute på tur for å legge ut bilder og blogg-innlegg fra turen. Som vi har kalt På Topp Og til slutt en backend som håndterer data samt kobler de to applikasjonene sammen. 2.1 På Langs Dette er den delen av oppgaven som skal gjøre det mulig å følge oppdragsgiveren på tur. Samtidig som at den skal kunne oppfordre til å sette seg egne turmål hver uke. Applikasjonen skal ha følgende funksjonalitet: Gi brukeren mulighet til å lese blogg-innlegg når oppdragsgiver legger ut disse. Lar brukeren følge turen på et kart med jevnlige oppdateringer. 8

10 Lar brukeren benytte seg av en egen tur funksjon, der de kan sette seg egne mål og gjennomføre disse i løpet av uka. Dette ved å gå turer som registreres i applikasjonene, ved hjelp av GPS. Gir brukeren tilgang til et bildegalleri. Det skal også være mulig å få tilgang til bilder, som kun er tilgjengelig for de som greier å gjennomføre det ukemålet som de satte seg i tur-delen av applikasjonen. Skal kunne hente ut og vise statistikk over hvor mange som har klart målene sine de forskjellige ukene og hvor langt alle som bruker applikasjonen har gått. 2.2 På Topp Oppdragsgiver trenger en applikasjon som han kan bruke ute i felt for å formidle bilder og blogg-innlegg til sine følgere. Denne applikasjonene har tre hovedoppgaver: La brukeren legge ut bilder med riktig hashtag på Instagram. Legge ut tur-øyeblikk (bilde og tekst) som dukker opp i mobil-appen (På Langs). Legge ut blogginnlegg som dukker opp på hjemmesiden og i mobil-applikasjonen (På Langs). Når det gjelder bruk av koordinater så ønsker oppdragsgiver at disse legges inn manuelt. Dette er for at det skal være mulig å legge inn andre posisjoner enn akkurat der han befinner seg når han skriver innlegget, eller legger ut bildet på nett. I tillegg er dette batteri besparende, da GPS funksjonen i telefonen bruker en del strøm, og han uansett går med en ekstern GPS. 2.3 Backend For å håndtere lagring av data samt henting av data fra eksterne API, trengs det et backend som på en enkel måte lar oss ta vare på og hente data. De viktigste punktene for valg av backend løsning var: God støtte mot Android applikasjoner. Mulighet for å gjøre kontinuerlige og automatiske operasjoner. Høy oppe-tid og god redundans i tjenesten. Lavt prisnivå. 9

11 Produktrapport 10

12 Forord I denne delen av sluttrapporten legger vi fokus på produktet. Dette inkluderer beskrivelser av teknologien som ligger bak og rammeverk som er benyttet. Vi forklarer hvordan applikasjonene er bygget opp og hvordan de kommuniserer. Vi redegjør også om grensesnittet til applikasjonene og om designvalg. I denne delen av rapporten så blir det til tider veldig teknisk. Vi redegjør for ord og uttrykk i slutten av rapporten ved en ordliste, men denne delen er ment og leses av folk med teknisk bakgrunn. Dette med unntak av designdelen som er litt mer tilgjengelig for alle. Produktrapporten er ment som et redskap for at eksterne utviklere skal kunne få forståelse for systemet bak applikasjonene og dermed ha muligheten til videreutvikling. Her tar vi i hovedsak for oss applikasjonen som skulle publiseres på Google Play, men det er et eget kapittel som omfatter applikasjonen til oppdragsgiver ( På topp ). 3. Produktet Dette kapittelet inneholder en teknisk beskrivelse av de diverse funksjonene til applikasjonene. Først tar vi for oss På langs -applikasjonen som er publisert på Google Play. Og etter dette beskriver vi På topp -applikasjonen som oppdragsgiver benytter på tur. Til slutt tar vi for oss hvordan vi har brukt Parse.com som backend og hvordan vi henter GPS koordinater fra et eksternt API. 11

13 3.1 På langs Her følger en teknisk beskrivelse av den applikasjonen som er publisert på Google Play Hovedmenyen Hovedmenyen er det første brukeren møter på i applikasjonen. Her har vi tatt utgangspunkt i stilen og fargene hentet fra design-profilen vi ble gitt, for å sørge for at vi beholdt helheten i prosjektet over de forskjellige plattformene som prosjektet M/S Norge er planlagt for Turdelen Turdelen er en av applikasjonens funksjoner. Denne delen presenteres som hovedårsaken til at en bruker skal laste ned applikasjonen og ikke bare følge oppdragsgivers tur via bloggen på nettsiden. Vår visjon for denne delen var enkel. Vi ønsket at brukeren skulle via applikasjonen enkelt kunne sette seg mål, og gå turer som blir lagt til mot dette målet. Hvis brukeren i løpet av en uke oppnår måloppnåelse så vil brukeren bli belønnet med ekstra innhold i applikasjonen. Dette i form av ekstra bilder fra oppdragsgivers tur. Dette er ikke personlig innhold, men det samme ekstra innholdet for alle som oppnår målet sitt hver enkelt uke. Fra uke til uke kan man justere målet sitt basert på hvordan det gikk forrige uke. Følte man for eksempel at man undervurderte seg selv uken før kan man skru opp målet sitt betydelig frem mot neste periode. Den originale planen for turdelen var en todelt løsning hvor brukeren kunne velge mellom bruk av skritteller eller bruk av GPS. Basert på disse ideene gjorde vi undersøkelser og testing rundt nøyaktighet og konklusjonen ble til slutt en løsning hvor vi bare tok til bruk GPS. Dette på bakgrunn av: 12

14 Presisjon - Under testing av distansemåling så var GPS den som leverte de distansen som var riktigst i forhold til virkeligheten. Dette var jo også forventet siden ved en skritteller løsning må man måle distansen basert på skrittlengde (ca 0.415*høyde) noe som ga varierende resultater. Det viste seg også vanskelig å levere en nøyaktighet skritteller til den bredden av enheter vi sikter til med denne applikasjonen. Turfølelsen - Siden prosjektet handler om mestringsfølelse og mann mot natur. Så er det naturlig at disse turene man går sammen med applikasjonen de skal foregå utendørs. Hovedfordelen med skritteller over GPS var muligheten for å bruke det innendørs, men nytteverdien av det hele forsvinner om poenget er å sende brukerne ut i naturen. Google Maps - En av funksjonene til applikasjonen er at man til enhver tid kan se hvor oppdragsgiveren vår befinner seg på tur, via Google Maps og en Spot GPS som oppdragsgiver går med. For å forsterke den følelsen for brukeren at de er ute på tur sammen med oppdragsgiver, ønsket vi å presentere brukerne sine turer på samme måte som oppdragsgivers. Dette betyr da at når brukeren er på tur, så blir turen streket opp i et kart på skjermen. Dette kunne vi heller ikke fått til med skritteller. Det første som møter brukeren etter å ha valgt Star ny tur i hovedmenyen er en knapp hvor brukeren kan starte en tur, som vist i Figur 3.2. Denne delen er styrt av WalkActivity.java og består av en layout activity_walk2.xml. Knappen som starter tur bytter om til å avslutte tur om en tur er i gang. Hvilken handling som blir utført når brukeren trykker på knappen blir bestemt av om boolean started returnerer true eller false. Teksten på knappen styres av metoden flipbuttons(boolean). public void flipbuttons(boolean start) { Button startbtn = (Button)findViewById(R.id.walk); } if (start) { startbtn.settext(this.getstring(r.string.stopwalk)); } else { startbtn.settext(this.getstring(r.string.startwalk)); } Når en tur startes så begynner applikasjonen å hente brukeren sin lokasjon. Dette blir lagret som LatLng -objekter som inneholder lengdegrad og breddegrad. Når det første objektet lagres så settes det en marker på kartet. Det sørges her for at tekstfeltene med informasjon rundt turen oppdaterer seg med relevant informasjon hver gang et nytt punkt blir lagret. public void onlocationchanged(location location) { addcoord(location.getlongitude(),location.getlatitude()); LatLng curloc = new LatLng(location.getLatitude(), location.getlongitude()); coordlist.add(curloc); if (firstcoordtaken == false) { 13

15 firstlat = location.getlatitude(); firstlong = location.getlongitude(); map.addmarker(new MarkerOptions().title("Start lokasjon").snippet("her startet du turen din!").icon(bitmapdescriptorfactory.defaultmarker(172)).position(curloc)); firstcoordtaken = true; } //For testing, vis en toast for å minne om at onlocation har skjedd. String str = "Gps lokasjon lagret"; Toast.makeText(getBaseContext(), str, Toast.LENGTH_LONG).show(); TextView finaltxt = (TextView)findViewById(R.id.thedistance); finaltxt.settext(string.format("%.2f", sumupwalk() ) + "km"); paceupdater(); setmapfragment(location.getlatitude(),location.getlongitude()); } Når brukeren avslutter turen så oppsummeres den ved metoden sumupwalk(). Denne tar og måler distansen mellom alle LatLng objektene lagret ved hjelp av metoden distancebetweentwolocationsinkm(double,double,double,double). Det siste som skjer er at brukeren får turens resultater presentert i en dialogboks. Og distansen blir lagret i Shared Preferences som en integer verdi med navnet weeklyprogress Følg oppdragsgivers tur Her kan brukeren følge turen til oppdragsgiver. Det første som skjer når brukeren åpner denne aktiviteten, er at det sjekkes om brukeren har aktivert nettverk. Dette skjer ved den følgende koden: public boolean isconnectedtointernet(){ ConnectivityManager connectivity = (ConnectivityManager)getApplicationContext().getSystemService(Co ntext.connectivity_service); if (connectivity!= null) { NetworkInfo[] info = connectivity.getallnetworkinfo(); if (info!= null) for (int i = 0; i < info.length; i++) if (info[i].getstate() == NetworkInfo.State.CONNECTED) { return true; } } return false; } 14

16 Er brukeren koblet til nettverk så vil aktiviteten begynne å laste et kart. Hvis brukeren ikke har nettverk aktivert blir brukeren spurt om han/hun vil åpne innstillinger for og slå dette på. Deretter så startes det et GoogleMap fragment. Dette blir fylt med markers over hvor oppdragsgiver har befunnet seg, på den følgende måten: public void drawmarkers(googlemap googlemap){ try { for (int i = 0; i < geocount-1; i++) { LatLng templatlng = new LatLng(geoList[i].latitude, geolist[i].longitude); String time = geotimelist[i]; googlemap.addmarker(new MarkerOptions().position(tempLatLng).title(time).icon(BitmapDescriptorFactory.fromResource(R.drawable.orange3))); } } catch(exception e){ Log.e("Nullpointer on Coords", e.getmessage()); } } Etter at kartet er ferdig lastet så vil det automatisk sentreres over det siste punktet oppdragsgiver har besøkt. Nå kan brukeren bruke vanlige fingerbevegelser til å panere eller zoome kartet Blogg I blogg delen av applikasjonen kan brukeren lese de blogginnleggene som oppdragsgiveren har lagt ut. Her har vi en aktivitet, BloggActivity.java med ListFragmenter, BloggFragment.java. Denne klassen henter alle blogginnlegg som ligger i skyen og legger dataen i ArrayLists, ved å bruke en ArrayAdapter<String>, BlogListArrayAdapter.java lages en liste med tittel og en kort tekst for hver av blogginnleggene. Ved å klikke på et blogginnlegg blir vi her tatt videre til selve innlegget. 15

17 3.1.5 Bildegalleri Bildegalleriet vises ved hjelp av PictureActivity.java. Denne inneholder en layout med en GridView. Dette fylles med elementer fra et array som ligger i strings.xml. Dette utføres av metoden getdata() : private ArrayList<ImageItem> getdata() { final ArrayList<ImageItem> imageitems = new ArrayList<>(); TypedArray imgs = getresources().obtaintypedarray(r.array.image_ids); for (int i = 0; i < imgs.length(); i++) { Bitmap bitmap = BitmapFactory.decodeResource(getResources(), imgs.getresourceid(i, -1)); imageitems.add(new ImageItem(bitmap, "Bilde " + (i + 1))); } return imageitems; } Dette gjør at bildegalleriet ser ut som i Figur 3.6. Her kan brukeren trykke seg inn på elementer for å se bildet ved hjelp av DetailsActivity.java. Det er også mulig å scrolle, om det er for mange bilder til å vise på skjermen. 16

18 3.2 På topp Her tar vi for oss utformingen av applikasjonen vi leverte til oppdragsgiver Hovedmeny Hovedmenyen gir oppdragsgiver 3 valg presentert som store knapper som skal være lette å navigere ute i naturen. Fargene er valgt etter design-profilen for prosjektet Legg ut bilde på Instagram/Del et øyeblikk Disse gjør mye av det samme, begge sender et bilde, en hilsen og koordinater til skyen, Instagram delen vil i tillegg legge ut bildet på Instagram med et sett med predefinerte hashtags (#msnorge, #lat og #lon). I utgangspunktet var det tenkt at vi skulle hente GPS-koordinater fra oppdragsgivers telefon, men pga kravet om at applikasjonene ikke skulle bruke for mye strøm, pluss at han ønsket å kunne legge inn koordinater som ikke nødvendigvis stemte overens med der han befant seg når han lastet opp bildene. Endte vi opp med å la oppdragsgiver selv fylle inn koordinatene. For å hente et bilde benytter vi oss av Intent.ACTION_GET_CONTENT 17

19 private void findpicture(){ Intent findpictureintent = new Intent(); findpictureintent.settype("image/*"); findpictureintent.setaction(intent.action_get_content); startactivityforresult(intent.createchooser(findpictureintent, "Velg Bilde"), FILE_SELECTION_RESULT); } som vi der etter sender til skyen. For Instagram delen Benytter vi oss deretter av en InstagramIntent: private void createinstagramintent(string type, Uri uri, String caption){ // Create the new Intent using the 'Send' action. Intent share = new Intent(Intent.ACTION_SEND); // Set the MIME type share.settype(type); // Add the URI and the caption to the Intent. share.putextra(intent.extra_stream, uri); share.putextra(intent.extra_text, caption); } // Broadcast the Intent. startactivity(intent.createchooser(share, "Share to")); Hvor caption inneholder #lat, #lon for koordinatene og #msnorge Nytt blogginnlegg Her lar vi oppdragsgiver skrive inn navnet på blogginnlegget, en kort beskrivelse og fullstendig tekst, samt koordinatene for hvor bloggen ble skrevet. Alt dette settes sammen til et objekt som deretter legges opp på skyen. 18

20 3.3 Backend Som backend har vi valgt å bruke Parse.com. Dette er en MBaaS ( Mobile Backend as a Service) som er eid av Facebook, og som er spesial designet for å tilby alt av tjenester som en mobil applikasjon kan trenge. Tjenesten er sky-basert, og har et stort og godt dokumentert API samtidig som det er gratis for applikasjoner av den størrelsesorden som vi forventer å oppnå. De tre viktigste funksjonene vi benytter oss av er background-jobs, cloud-code og datalagring. Noe som var viktig for oss ved valg av backend var muligheten til å hele tiden kunne oppdatere databasen med koordinater fra oppdragsgivers GPS-sender. Måten dette gjøres på er ved at han går med en SPOT-GPS sender som hvert 10. minutt sender hans posisjon til SPOT sin database. Denne dataen er tilgjenglig for oss gjennom deres API som.json objekter. Vi bruker så en background job som hvert 10minutt sender en httprequest etter de siste 50 koordinatene. Vi har valgt og henter 50 koordinater istedenfor bare siste, da senderen ikke alltid greier å sende siste posisjon (på grunn av sattelitt-skygge) og på denne måten går vi ikke glipp av noen punkter. Punktene sjekkes deretter mot den høyeste UNIX time verdien som ligger i databasen, og dersom den er høyere lagres et nytt objekt. I tillegg til en egendefinert background job har vi også egendefinerte metoder kalt Cloud-code dette er javascriptmetoder som applikasjonen vår kan kalle på. For eksempel har vi definert en egen metode for å hente alle koordinatene som er lagret i databasen slik at vi kan bruke disse for å tegne ruten i FollowActivity.java Lagringen av data i Parse.com sin sky gjøres gjennom å sende ParseObjects til skyen som matcher de klassene som er blitt opprettet. Dette gjør at det er enkelt å jobbe mot, sammen med objekt-orientert-programmering 19

21 Figur 3.10 Posisjonen til oppdragsgiver lagret i Parse skyen. 4 Design Vi har under designprosessen av vår applikasjon prøvd å tenke på informasjonen fra Android sine design prinsipper. Disse sier i hovedsak at man skal gjøre det så enkelt som mulig for brukeren, men samtidig skal brukeren føle seg mektig. Det skal også være så lite tekst som mulig, men heller fokus på at et bilde sier mer enn tusen ord. I denne delen av rapporten så redegjør vi for hvordan og hvorfor designet på applikasjonen har blitt som det har blitt og hvorfor. 4.1 Innledning Det tok litt tid inn i prosjektperioden før vi virkelig fikk satt oss ned og jobbet konkret med hvordan designet skulle se ut. Dette var fordi vi ventet på et designprofil som skulle gjelde overordnet for alle deler av oppdragsgivers prosjekt. Men vi brukte tiden frem til 20

22 dette på navigasjon og backend. Men det ble altså en litt uvant arbeidsflyt hvor skissene ble produsert etter at vi hadde begynt å kode. Da vi først kom i gang med designet så gikk dette veldig fort fremover. Vi tok utgangspunkt i gjenkjennelighet med prosjektet sine andre medier og lagde noen skisser basert på dette. 4.2 Applikasjonens utforming I punktene under vil vi gå gjennom utformingen av applikasjonen. Her presenterer vi også skissene som ble produsert Hovedmenyen Vi bestemte oss tidlig for at vi ville ha en tradisjonell hovedmeny. En av grunnene til dette var at applikasjonen har et såpass variert innhold, at ingenting stod ut som en åpenbar oppstartsskjerm. I Figur 4.1 ser man hvordan denne skjermen var tiltenkt å se ut. Basert på designprinsippet, bare hvis det jeg trenger, når jeg trenger det, ble hovedmenyen noe forandret underveis. Vi flyttet innstillinger til menyen som ligger på meny -knappen til Android. Vi gjorde også den ene knappen dobbelt så høy som de andre for å skape en asymmetri i designet. Noe som gjorde menyen mer spennende visuelt. Resultatet av dette kan man se i Figur Turdelen Turdelen var som du ser i Figur 4.2 tiltenkt en tredelt løsning. Her har man knappene som kontrollerer å starte og slutte tur øverst. Informasjon om turen i midten. Og et kart fra turen nederst. Det endelige resultatet her ble ganske likt som skissen. Vi sammensatte de to knappene siden to viste seg overflødig. Vi la også til en TextView hvor brukeren kan se sin ukentlige progresjon. Dette kan du se i Figur

23 4.2.3 Følg oppdragsgiver sin tur I denne delen av applikasjonen så ønsket vi å benytte Google Maps til å vise lokasjonen til oppdragsgiver. Det var derfor ikke noe stort behov for å tenke på designet eller utformingen av dette. Det gjorde Google Maps API for oss. Her ble det ingen endringer underveis, da vi brukte Google Maps som planlagt Blogg Bloggen skulle være en liste med blogginnlegg. Her vil bare overskriften og den første linjen med tekst vises. For å lese innlegget i sin helhet må brukeren trykke seg inn på dette. En skisse av hvordan vi tenkte oss dette kan du se i Figur 4.4. Det ble heller ikke her utført noen endringer mellom skissen og det ferdige produktet. 4.3 Applikasjonens utseende Størrelse på elementer Siden alle enheter applikasjonen vår skal kjøres på er touchscreen-baserte er det viktig å tenke på dette i utformingen av knapper og andre trykkbare elementer. Viktigheten av dette i vårt prosjekt er spesielt stor siden vi ønsker at applikasjonen skal benyttes av personer med Multippel Sklerose (Fra nå av MS i teksten). En av symptomene som personer med MS kan oppleve er manglende kontroll over muskler. Dette kan lede til 22

24 unøyaktige bevegelser og i verste fall kan det være vanskelig å operere en touchscreen-basert enhet. Basert på dette så har vi passet på at alle trykkbare elementer i applikasjonen er av en størrelse som skal være så tilgjengelig som mulig. For og oppnå dette holder vi alle trykkbare elementer over 48 dp 1. Dette garanterer at ingen av disse elementene er under 7mm uavhengig av hvilken enhet som brukes til å kjøre applikasjonen Knapper De originale utkastene av applikasjonen hadde en god del knapper, men jo lenger vi kom i utviklingen av applikasjonen jo flere knapper ble fjernet. Dette var for å følge Android sine egne prinsipper for design. De knappene som er applikasjonen er gjort så spennende som mulig. Dette vil si at på hovedmenyen så har vi laget store knapper med farger og bilder som minner litt om Windows 8 sin startskjerm. Vi har også laget våre egne knapper for andre deler av applikasjonen. Disse har blitt produsert med prosjektet sin fargepalett for å styrke det helhetlige inntrykket i applikasjonen Fargevalg Vi fikk beskjed tidlig i prosjektet om at det ville komme en designprofil som vi ville være forventet å følge. Det inneholdt blant annet prosjektets logo og farger. Disse fargene skulle passe prosjektets ut i naturen tema. Fargene kan ses i figuren under. Mer informasjon om dette finnes i designprofilen som er lagt som vedlegg bakerst i denne rapporten. Figur 4.5: Fargene som var tiltenkt bruk i dette prosjektet. 1 Density independant pixels 23

25 Farger og tilgjengelighet I valget av farger passet vi på at vi hadde god kontrast mellom bakgrunner og tekst. Vi brukte det nettleserbasert verktøyet Coblis 2 for å simulere fargeblindhet og testet fargevalgene våre på denne måten. Et eksempel på dette kan du se i Figur Logo Vi lagde en enkel logo som skulle representere vår applikasjon. Denne logoen er det første brukeren vil se etter og ha installert applikasjonen på sin enhet og det er derfor viktig at den gir et godt inntrykk. Logoen vår er basert på prosjektet sitt tema altså at oppdragsgiver skal gå Norge på langs. Fargebruken er også konsekvent med den ellers i applikasjonen og prosjektet. Vi hadde også tilgang til prosjektet M/S Norge sin logo. Denne har vi brukt innad i applikasjon for å bygge opp under at dette er en offisiell applikasjon som er en del av M/S Norge prosjektet. I Figur 4.7 kan du se prosjektet M/S Norge sin logo og applikasjonen sitt launcher icon. 2 Coblis - Color blindness simulator. 24

26 4.3.5 Bilder Med et fokus i prosjektet på at oppdragsgiver og brukerne av applikasjonen skal dele opplevelser ute i naturen så er det naturlig med bilder i applikasjonen. Disse bildene er tatt av oppdragsgiver, og er samlet i et bildegalleri. 4.4 Navigasjon Androids utviklerprinsipper sier at ingenting er mer frustrerende for brukeren enn navigasjon som oppfører seg på en uventet måte. Man skal også passe på at ingenting ligger for dypt (for mange undermenyer) i applikasjonen. Vi har derfor produsert et system hvor alle aktiviteter er tilgjengelige fra en overordnet hovedmeny. Figur 4.8: Hvordan aktivitetene i applikasjonen henger sammen Hovedmenyen Den første skjermen som møter brukeren er hovedmenyen. Dette er applikasjonens MainActivity og det er her du får tilgang til alt innholdet. Den vanlige løsningen for navigasjon i Android applikasjoner er en skjult meny som kan vises ved behov. Slik at du kan navigere mellomaktiviteter flytende. Men vi følte ikke at vi hadde noe behov for en slik løsning i denne applikasjonen. Ingen elementer i applikasjonen ligger dypere enn 2-trykk innover. Dette bidrar til at brukeren ikke mister oversikt over hvor han/hun er. 25

27 4.4.2 Tilbake- og opp-knappen Opp-knappen er i Android ment til å sende deg oppover i hierarki av skjermer. Denne ligger i ActionBar og ble introdusert i API-versjon 3. Tilbake-knappen er en fysisk knapp på smarttelefoner som tar deg tilbake til det skjermbildet du var på før det nåværende. I vår applikasjon får disse to knappene helt lik funksjonalitet siden det ikke er noen navigering mellom de forskjellige aktivitetene Fysiske knapper Ovenfor (4.4.2) nevnte vi tilbake-knappen som tar deg tilbake til det foregående skjermbildet. Vi har også tatt i bruk meny -knappen som befinner seg på Androidenheter. Denne gir brukeren tilgang til en skjult meny hvor de kan navigere til applikasjonens innstillinger ActionBar Fordi det i vår applikasjon er en overordnet hovedmeny som tar seg av all navigering, er ActionBar i hovedsak brukt til å navigere tilbake til forrige aktivitet. Dette går igjen i både På Topp og på Langs Figur 4.9: Skjermbilde av ActionBar fra M/S Norge applikasjonen. 26

28 4.5 Batteriforbruk Applikasjonen er tiltenkt bruk utendørs over lengre tid med bruk av både nettverk og GPS. Dette gjorde det viktig for oss å passe på effekten applikasjonen vår hadde på batteribruket til enheten GPS Vi brukte GPS lokasjon til å måle turene som brukerne går i turdelen. Her måtte vi finne en balanse mellom nøyaktighet og batteriforbruk. I utviklerdokumentasjonen til Android så nevnes tre mulige måter å begrense batteriforbruket til GPS på. Gjøre vinduet hvor GPS lokasjon hentes kortere, hente lokasjon på større intervaller innad i vinduet eller å begrense kildene man henter lokasjon fra. Når brukeren starter en tur i applikasjonen så setter dette i gang oppdateringer rundt brukeren sin lokasjon. Dette vinduet med oppdateringer varer helt til brukeren selv velger å avslutte turen. Derfor valgte vi å fokusere på oppdaterings-intervaller som måten å begrense batteriforbruket. Vi satt i utgangspunktet et intervall på ti sekunder, men ga også brukeren mulighet til å velge dette selv. Altså kan brukeren ofre nøyaktighet for lavere batteribruk. Figur 4.10: Koden som setter i gang at det hentes oppdateringer rundt GPS-lokasjon. Figur 4.11: En tidslinje som representerer vinduet av tid en applikasjon leter etter GPSlokasjoner. Fra Androids utviklerdokumentasjon om lokasjon. 27

29 En tur kan ikke startes i applikasjonen uten at brukeren har GPS aktivert på sin enhet. Prøver brukeren å starte en tur uten så kommer det en beskjed opp om dette i en dialog boks. Når brukeren avslutter turen så kommer informasjon om denne i en liknende dialogboks. Her foreslår vi til brukeren at GPS kan slås av og har en knapp som tar brukeren til innstillinger. På bakgrunn av mulighetene over så gir applikasjonen brukerne en viss kontroll over hvordan batteriforbruket til applikasjonen er Nettverk Applikasjonen benytter seg også av nettverk, som kan være den største synderen på batteribruk i Android applikasjoner. I hovedsak er det forventet at applikasjonen kommer til å benytte seg av mobilnettverk, da man ikke kan forvente pålitelig wifi tilgang ute på tur. Smarttelefoner har en innebygd radio som sender og mottar data. Denne har tre mulige tilstander. (Som vist i figur 4.12). Standby - Ingen aktiv tilkobling og dermed veldig lav batteriforbruk. Lav styrke - Har omtrent halvparten av batteriforbruket til full styrke. Full styrke - Høyest batteriforbruk og best hastighet på sending og mottak av data. En 3G radio er satt opp sånn at det automatisk går til standby om ingenting foregår. Ulempen med dette er at det tar den ca to sekunder å komme opp på full styrke igjen, om det skulle bli behov for nettverk. Det tar også 5 sekunder uten bruk for at den skal falle tilbake til lav styrke, og videre 12 sekunder for og nå standby. Dette gjør at selv et kort nettverkskall vil påvirke ekstra forbruk av batterikraft i minst 19 sekunder. På bakgrunn av dette har vi passet på at applikasjonen ikke gjør nettverkskall unødvendig ofte. Figur 4.12: De forskjellige tilstandene til en standard 3G radio. 28

30 4.6 Skjermstørrelser Vår applikasjon er i utgangspunktet tiltenkt bruk på smarttelefoner fordi de egner seg best og gå på tur med. Fokuset på turdelen er en av grunnene til å velge å bruke applikasjonen over nettsiden. Altså regner vi med at folk som bruker nettbrett uansett vil velge nettsiden over applikasjonen. Og på bakgrunn av dette er nettbrett ikke blitt prioritert under utvikling. 4.7 Språk Applikasjonen er bare levert med norsk språk, men vi har tatt høyde for en mulig utvidelse på dette i fremtiden. Tekst i applikasjonen er i hovedsak tekststrenger som henter en verdi basert på enheten sin språkinnstilling. Så ønsker oppdragsgiver i fremtiden at denne applikasjonen skal støtte flere språk er det bare oversetting som må utføres. 29

31 4.8 API-versjon API-versjonen bestemmer hvilke versjoner av operativsystemet Android en applikasjon kan kjøre på. Vår applikasjonen har et minstekrav på API-versjon 16 (Android 4.1 og oppover). Dette gjør applikasjonen vår tilgjengelig for nesten 90% av de enhetene som besøker Google Play. Denne informasjonen ligger på Android sitt utvikler dashboard og oppdateres ukentlig. Informasjonen er innhenta ved å sjekke Android-versjonen til alle enheter som besøker Google Play, og er derfor meget representativ for markedet. Figur 4.13: Ubredelsen til de forskjellige API-versjonene. 30

32 4.9 Oppdragsgivers applikasjon Fordi denne applikasjonen bare skulle brukes av oppdragsgiver, ble viktigheten av design mindre. Oppdragsgiver ønsket noe som fungerte godt og var enkelt å bruke. Oppdragsgiver skulle benytte seg av denne applikasjonen ute i naturen. Derfor valgte vi å lage ekstra store knapper slik at navigasjonen var enkel å benytte seg av Research Enkelte valg vi måtte ta i løpet av prosjektet krevde at vi gjorde litt arbeid på forhånd sånn at vi tok de riktige valgene. Det var også et mål for oss med prosjektet å kunne begrunne valgene tatt i forarbeid. Her har vi dokumentert dette arbeidet Tur-delen Siden en av hovedfunksjonene til applikasjonen er å måle brukerens turer utendørs, så er det viktig at teknologien for dette er på plass. Det stilles også krav til ting som nøyaktighet. Dette for at brukeren ikke skal føle seg snytt og bli frustrert over applikasjonens funksjonsevne. Vi har derfor brukt tid på å teste forskjellige løsninger på problemet. Disse testene er utført kvalitativt og det er lagt vekt på i størst grad nøyaktighet, men også påvirkning på enheten sin levetid. Dette fordi vi ønsker å sende folk ut på både korte og lange turer i skog og mark, da er det ikke veldig gøy om applikasjonen tar knekken på enhetens batteri halvveis gjennom turen. De mulige løsningene er: 31

33 Ren GPS Her vil applikasjonen be om permisjon til å bruke enheten sin GPS. I det brukeren forteller applikasjonen at han/hun vil gå på tur så starter applikasjonen å samle GPS punkter. Dette vil applikasjonen fortsette med jevnlig frem til brukeren sier at turen er over. Videre kan det brukes funksjoner som sjekker distansen mellom punktene og bruker det til å regne ut turens lengde. Et mulig problem her kan være om punktene ikke settes ofte nok slik at brukeren vil miste distanse om han/hun svinger mye. I eksemplet under (Figur 4.15) ser man dette problemet illustrert. Til venstre i dette bildet tas punktene på akkurat riktig tidspunkt slik at brukeren får det riktige resultatet (i dette eksemplet 693m), men til høyre så har applikasjonen satt et punkt bare på starten og slutten av brukeren sin runde og dette resulterer i et veldig misvisende resultat. (143m noe som er 550m kortere enn brukeren faktisk gikk). Figur Eksempel på hvordan punkt måling kan fungere. Bortsett fra dette problemet så må også GPS sin store bruk av batterikapasitet vurderes. Vi hadde også noen tanker rundt hvorvidt GPS var riktig siden det vil slutte å fungere innendørs, men her konkluderte vi med at applikasjonen sitt hovedformål er å sende folk ut på tur og at innendørs turer ikke vil være noen prioritering. 32

34 Ren skritteller Her vil applikasjonen utelukkende måle distansen basert på en skritteller. Det som er viktig her er da først og fremst at skrittelleren er nøyaktig slik brukeren ikke får dårligere eller bedre betalt for innsatsen enn han/hun skal. Fordeler med dette i forhold til GPS bruk vil være mindre belastning av enheten sitt batteri og muligheter for bruk av applikasjonen innendørs. (Selv om dette ikke er en prioritering eller noe krav til applikasjonen, da oppdragsgiver ønsker at folk skal ut i naturen). Teknisk sett så vil applikasjonen måtte ta i mot enkelte inputs fra brukerne. I hovedsak kjønn og høyde. Dette er for å regne ut lengden på et skritt. Vi kunne tatt utgangspunkt i gjennomsnittet for skrittlengde som vel er 70cm for kvinner og 78cm for menn, men her er nøyaktighet ønskelig og derfor er nok best å hente inn litt informasjon om brukeren. Deretter kan vi bruke høyde x 0.415(menn)/0,413(kvinner) for å finne skrittlengden. Etter det kan dette brukes til å finne distansen via steg/skrittlengde. Men her vil man uansett aldri finne total nøyaktighet fordi skrittlengde varier i løpet av dagen og andre faktorer som bakker og trapper kan også spille inn. Andre problemer rundt denne løsningen bortsett fra manglende nøyaktighet kan være hvor enkelt det er å lure systemet. Sitter man og rister smarttelefonen sin i noen minutter har man straks vært ute på tur. Dette er ikke ønskelig. Men det er heller ikke krise da man i stor grad bare lurer seg selv om man jukser på turer ut i naturen GPS + Skritteller løsning Denne løsningen vil kombinere de to mulighetene for å skape både mer nøyaktighet og mer fleksibilitet i applikasjonen. Det vil være mulig å starte og slutte turer innendørs fordi applikasjonen ikke er 100% avhengig av kommunikasjonen med GPS satellitt. Det vil også være mulig å snike inn en tur ut av at du går mye på jobb. Og selv om det er ønskelig å sende folk ut på tur så er det bra om applikasjonen er fleksibel. Men det er en fare for at en slik løsning vil virke for negativt inn på batteriet. 33

35 4.11 Verktøy og teknologier I denne delen av rapporten gir vi et lite innblikk i noen av de verktøyene og teknologiene som har blitt brukt underveis i prosjektet Android Studios Dette er den offisielle platformen for å utvikle applikasjoner til Android og vi bestemte oss for å bruke denne. Vi gikk tidlig inn for å jobbe i samme programvare for å møte på minst mulig problemer underveis på bakgrunn av dette Git/Github Versjonshåndtering er en viktig del av utviklingen og vi landet på å bruke Git. Android Studios hadde enkle integrerte løsninger for bruk av Git og det var et naturlig valg basert på gruppens tidligere erfaringer. Figur 4.16: Skjermbilde fra Github commit-loggen Dropbox Dropbox lar oss legge filer og mapper opp på en sky og dette var nyttig i de tilfeller hvor vi har måtte dele filer som ikke nødvendigvis hørte til kode-delen av prosjektet. Dette vare spesielt relevant i oppstartsfasen av prosjektet da vi delte mye skisser og diagrammer. Vi har også hatt tidligere versjoner av kildekoden liggende på Dropbox i tilfelle noe skulle gå forferdelig galt med det som ligger lokalt/på GitHub. 34

36 Google Drive/Docs Google Docs gir brukeren muligheten til å skrive i samme dokument samtidig. Dette har vi brukt aktivt til utformingen av den skriftlige delen av prosjektet. Det har også fordelen at det som skrives lagres på sky i Google drive og man da har en automatisk backup av alt som er skrevet for og best forhindre tap av data Skype Dette er Microsoft sin tjeneste for IP-telefoni og har blitt brukt av gruppen for kontakt når møter i person ikke har passet. Man har også muligheten til skjermdeling og det har vi hatt bruk for underveis i planleggingen av prosjektet for å raskt dele skisser og ideer Facebook Det sosiale nettverket Facebook var en av våre møtepunkter. Vi opprettet en gruppe her hvor vi kunne legge ut beskjeder og huskelapper om diverse ting underveis. Dette ble da spesielt brukt til å informere gruppepartner om sykdom eller andre grunner til at planlagte hendelser måtte utsettes eller avlyses Paint.net Når vi skulle tegne opp raske skisser eller oversikter så brukte vi Paint.net til dette. Dette ga oss litt mer muligheter enn Windows Paint, men vi fikk fortsatt forholde oss til gratis programvare som er forholdsvis enkel Inkscape Designprofilen til prosjektet var satt på forhånd av oppdragsgiver sammen med et design team. Dette gjorde at vi måtte sørge for at vår applikasjonen hadde et helhetlig inntrykk med resten av prosjektets medier (nettside, blog, sosiale medier osv). I Inkscape har vi kunne produsert vektorbaserte grafikkelementer til applikasjonen ved behov. 35

37 Creately Creately er et nettbasert verktøy hvor man kan produsere diagrammer. Vi brukte dette i hovedsak til å lage Use Case, aktivitetsdiagrammer og enkelte tegninger for denne rapporten. 36

38 Prosessrapport 37

39 5 Planlegging og metode I denne delen av rapporten tar vi for oss alt som har med planlegging, samarbeid, kompetanseutvikling underveis, verktøy benyttet under prosjektet og hvilke teknologier vi har tatt til bruk. 5.1 Arbeidsfordeling og samarbeid Vi bestemte oss ganske tidlig for at vi skulle jobbe sammen på hovedprosjektet. Vi hadde jobbet sammen i gruppefag alle semestre helt siden starten av studiet og har gjennom dette bygd opp gode rutiner og en god evne til å samarbeide. Et av valgene vi måtte ta tidlig var om vi skulle åpne gruppen vår for andre eller ikke. Ingen av de vi hadde jobbet med på tidligere fag var tilgjengelige så alternativet var å finne noen vi ikke hadde kjennskap til. Vi fant det mest hensiktsmessig og forbli en gruppe på to personer både på grunn av optimalt samarbeid og fordi oppgaven vår sitt omfang trolig ikke vil være ideell for en større gruppe. Samarbeidet fungerer også godt da vi begge bor forholdsvis nærme både hverandre og skolen så vi kan møtes for å jobbe på oppgaven når det er nødvendig. Dette har gjort at vi har kunnet justert arbeidssituasjonen fra dag til dag avhengig av nødvendighet. Noen ganger har vi jobbet på forskjellige deler som ikke har krevd veldig tett samarbeid, mens andre ganger så har det vært nødvendig å hele tiden hente tilbakemeldinger fra hverandre og arbeid i samme rom har vært påkrevd. Faglig så måtte vi lære en del underveis i denne oppgaven. Vi hadde begge erfaring med Java fra før av, men vi hadde ikke jobbet så veldig mye med utvikling av applikasjoner til Android. Vi valgte også å bruke Android Studios selv om vi ikke hadde erfaring med dette fra før av. Dette gjorde at det var en liten overgangsperiode der hvor vi måtte komme forbi noen av vanene vi hadde opparbeidet oss av å jobbe i Eclipse. Men det føltes naturlig og ikke bare bruke teknologier og verktøy som vi hadde kjennskap til fra før av, da litt av poenget med en hovedoppgave er og gi seg selv en utfordring. 38

40 5.2 Kommunikasjon Her beskriver vi hvordan kommunikasjonen fungerte mellom de diverse interessentene av prosjektet og hvordan det fungerte innad i gruppa. Vi har ikke hatt noen problemer med dette underveis og ingen problemer har oppstått på bakgrunn av dårlig kommunikasjon I gruppa Kommunikasjonen har fungert utmerket innad i gruppa gjennom hele prosjektet. Vi har variert hvor mye vi har møtt hverandre i person løpende basert på behov. I oppstartsfasen så holdt vi veldig tett kommunikasjon. Vi pratet daglig om mulige funksjoner og løsninger for applikasjonen. Dette foregikk ofte i grupperom på skolen slik at vi kunne tegne skisser og ideer. Det ble også enkelte møter i denne fasen over skype hvor vi tok til bruk skjermdeling for å vise hverandre ideer og skisser. Underveis i prosjektet når vi hadde kommet i gang med produksjon av applikasjonen ble møtene sjeldnere. Vi holdt fortsatt daglig kommunikasjon over Facebook for og ha oversikt hvordan vi lå an, men vi møttes bare i person en gang i uken. Dette funket greit da prosjektet hadde veldig klare deler som måtte utvikles og vi delte opp disse slik at det til enhver tid var mulig å jobbe uavhengig av hverandre. Under testingen av applikasjonen så jobbet vi igjen tettere for å teste forskjellige deler av applikasjonen på forskjellige fysiske enheter. Vi testet blant annet turdelen ved å gå på tur med applikasjonen kjørende på flere fysiske enheter samtidig. Dette for å sjekke etter forskjeller i resultater eller ytelse mellom enhetene Med oppdragsgiver I starten av prosjektet så var det ikke helt fastsatt hva som skulle være en del av applikasjonen og det ledet til flere møter hvor vi sammen med oppdragsgiveren fastsatte rammene for prosjektet. Siden oppdragsgiver ikke har kompetanse innenfor applikasjonsutvikling så ble dette en prosess hvor vi kunne foreslå masse muligheter som oppdragsgiver ikke var klar over at var mulig. Etter at rammene for prosjektet var fastsatt så hadde vi ingen flere møter med oppdragsgiver, men heller kontakt over telefon eller epost da det var nødvendig. Siden turen til oppdragsgiver skulle begynne 18. april så var det viktig at innen denne datoen så hadde vi ferdiggjort alt av han sin interaksjon med utviklingen. 39

41 Gjennom oppdragsgiver har vi også fått kontaktinformasjonen til både de som står bak nettsiden til prosjektet og de som lagde design-profilen. Dette for å sørge for at vår applikasjon bidrar til et helhetlig inntrykk for prosjektet. Dette har vært til stor hjelp spesielt siden vi i stor grad er utviklere og ikke designere Med veileder Kommunikasjonen underveis med veileder Torunn Gjester har bestått av ukentlige møter. Her har vi satt mål for hva som skal oppnås frem mot neste møte og fått tilbakemeldinger på det som er gjort siden sist. Dette har fungert veldig bra gjennom prosjektperioden. Det at veilederen i tillegg er ansvarlig for faget apputvikling på høgskolen gjør at vi underveis også har fått god faglig veiledning. 5.3 Kompetanseutvikling Vi visste på forkant av prosjektet at vi måtte sette av nok tid til å tilegne oss nødvendig kompetanse underveis siden vi ikke hadde så mye erfaring innen applikasjonsutvikling fra før av. Vi måtte lære oss hvordan vi effektivt skulle bruke Android Studios i utviklingen siden vi begge tidligere var brukere av Eclipse. Vi måtte også lære oss en god del rundt det å kode for mobile enheter da vi hadde erfaringer med programmeringsspråket Java, men ikke hadde brukt så veldig mye tid på å lage applikasjoner tidligere. Turdelen er en av hovedelementene av applikasjonen vår og den skisserte vi lenge før vi i det hele tatt hadde oversikt hvordan vi skulle løse det teknisk. Vi satt derfor av tid til å gjøre forskning inn i eksisterende løsninger og muligheter rundt dette slik at vi kunne løse det på den måten som passet vår applikasjon best mulig. Det arbeidet er dokumenter i kapittel Et annet element av prosjektet som krevde at vi tilegnet oss kunnskap vi ikke allerede hadde var backend løsningen. Vi hadde kompetansen til å produsere vår egen backend løsning med hjelp av skolens server, men vi ville se på alternative løsninger før vi satt i gang for å være sikre på at vi gjorde det riktige valget. Denne prosessen endte med at vi satt oss inn i og brukte Parse. 40

42 5.4 Planlegging og metodikk I dette kapittelet tar vi for oss hvilke programmer og ressurser som vi tok i bruk i planleggingen av prosjektet Dokumenter Gjennomgående for et prosjektet av denne størrelsen er det at man behøver god oversikt over hva som skal gjøres. En av måtene for å sikre dette er ved å dokumentere godt underveis i prosjektet. Vi startet prosjektet med å opprette en rekke dokumenter. Statusrapport - Dette var før prosjektet virkelig hadde kommet i gang og skulle bare beskrive litt rundt hva vi hadde planer å jobbe med og hvem vi hadde tenkt å jobbe med. Prosjektskisse - Dette var den første konkretiseringen av hva prosjektet skulle innebære. Den gikk ikke inn på detaljer slik som kravspesifikasjonen gjør, men her fikk vi oppsummert hvem som er de forskjellige interessentene i prosjektet. Forprosjektrapporten - Var et dokument som ble levert på slutten av oppstartsfasen av prosjektet. Denne inneholdt en avtale med oppdragsgiver og oversikt over detaljer som hvem som er talsmann for gruppen. Kravspesifikasjon - Finnes som vedlegg til denne rapporten. Møtelogg - Selv om vi bare er to medlemmer på gruppen så skrev vi møtelogger for de møtene som var spesielt viktige. Dette inkluderer da møter med oppdragsgiver og møter med veileder. Dette var for å ikke glemme viktige detaljer som oppdragsgiver eller veileder kom med underveis Prosjektside på nett Vi valgte å ikke gjøre så veldig mye ut av prosjektsiden vi opprettet, men heller holde den til det viktigste. Dette var styringsdokumenter som forprosjektrapporten, statusrapport og til slutt sluttrapporten. Det er også muligheter for at vi åpnet GitHub repository et vårt etter at prosjektet er over og legger ut lenken til dette for senere års studenter som skulle ha interesse av å se kildekoden til prosjektet Utviklingsmodell Vi har som tidligere nevnt jobbet sammen på en rekke prosjekter tidligere i løpet av studietiden på Høgskolen i Oslo og Akershus. Basert på dette så har vi opparbeidet oss en rekke rutiner som har fungert bra. Vi har derfor ikke basert utviklingen på en satt 41

43 utviklingsmodell, men heller tatt elementer av det som har fungert for oss tidligere og brukt det. Blant annet har vi arbeidet i sprinter hvor vi har på starten av hver 2-ukers periode satt klare mål for hva som skal gjøres i løpet av perioden. Hovedfilosofien rundt denne typen utvikling for vår del var å komme i gang så fort som mulig med produksjonen. Dette oppnår man ved at man sprer mer av planleggingen ut mellom 2-ukers periodene og ikke trenger å bruke så mye tid på det i oppstartsfasen av prosjektet Versjonskontroll og backup Siden styringsdokumentene ble lastet opp på nettsiden vi opprettet for prosjektet så fungerte dette som en backup for disse. Vi brukte også i hovedsak Google docs for å produsere skriftlig arbeide underveis i prosjektet og dette ble jo da automatisk lagret på Google drive slik at vi hadde en trygghet der. I tillegg til dette så lastet vi ned filene lokalt og hadde en kopi av disse liggende lokalt i en mappe som var synkronisert opp mot Dropbox slik at vi kunne jobbe på disse også uten tilgang til Internet. Og ikke minst ha den ekstra sikkerheten i en backup liggende på Dropbox. For versjonskontroll så brukte vi GitHub fordi vi har begge brukt dette tidligere i programmeringsfag. Dette var et naturlig valg både basert på tidligere erfaringer og at Android Studios allerede hadde støtte for dette. Vi har opplevd litt problemer med bruk av GitHub tidligere når flere gjør endringer til en fil og ting må merges, men det ble ikke noe problem under dette prosjektet da vi stort sett jobbet på forskjellige deler. Og de gangene vi jobbet på det samme så satt vi gjerne sammen på en maskin Diagrammer og modeller En naturlig del av å holde oversikter over prosjekter av denne størrelsesordenen er å produsere diagrammer og modeller som skisserer rammene til prosjektet og systemet. Det vi har brukt av diagrammer og modeller gjør vi rede for her Gantt-skjema Vi har ikke tidligere hatt noen prosjekter av denne størrelsen så vi bestemte oss for å planlegge de forskjellige fasene av prosjektet på forhånd. Her brukte vi et gantt-skjema for å planlegge på en visuell måte. Dette gir prosjektet en visuell tidslinje som vi kan referere til underveis i utvikling. Vi forventet ikke at vi kom til å følge denne nøyaktig 42

44 siden det alltid vil være ting som tar lengre eller kortere tid enn ventet, men dette ga oss noe å ta utgangspunkt i. Vi regnet med en kort oppstartsperiode hvor vi fullførte forprosjektrapporten og etter det kravspesifikasjonen. Etter dette la vi inn perioder på 2 uker hvor vi produserte. Etter det la vi inn 7 dager med testing og 20 dager med dokumentasjon. Med noen åpne dager før innleveringsfristen på sluttrapporten slik at vi kunne klargjøre alt til levering. Etter innleveringsfristen er det lagt inn tid til å forberede en muntlig presentasjon. Figur 5.1: Gantt-skjemaet vi oppretter i starten av prosjektet Gantt-skjema endringer Vi forventet at det kom til og bli avvik fra Gantt-skjemaet underveis og det ble det også. Forprosjekts perioden tok litt lenger tid enn ventet og vi endte opp med å begynne skikkelig produksjon litt senere enn ventet. Dette var spesielt fordi vi i starten av prosjektet jobbet med oppdragsgiver om å fastsette rammene for prosjektet og dette tok et par møter. Vi hadde også bare satt av en uke til testing, men dette ble en mer flytende prosess som varte lenger, men heller gikk parallelt med skriving av dokumentasjon og sluttrapporten. I denne perioden så brukte vi 2 dager i uken på programmering og fiksing av problemer som skulle vise seg gjennom testing. Og 5 dager i uken på å skrive dokumentasjon og annet innhold rundt rapporten. 43

45 6 Utviklingsprosessen I denne delen av rapporten vil vi fokusere på utviklingsprosessen. Her vil vi gjøre rede for de forskjellige periodene av prosjektet kronologisk. Det vil være noe overlapp med andre kapitler, men her er hovedfokuset å vise hvordan gangen i utviklingen har vært. 6.1 Utredningsfasen På høsten i 2014 så var prosjektet fortsatt ganske uklart. Vi hadde en dannet en gruppe og vi var klare på at vi hadde lyst til å gjøre et prosjekt som utfordret oss faglig. Det vi så etter var altså et prosjekt hvor vi kunne kode noe. Vår hovedplan var å være en del av prosjektet M/S Norge ved å produsere en applikasjon for dette, men det hele kunne falle sammen hvis prosjektet ikke fikk økonomisk støtte. Men med en gang søknaden om støtte ble godkjent, så satt vi opp et møte med prosjektleder for å prøve å spesifisere hva som skulle produseres. Vi hadde et møte med oppdragsgiver før jul, men vi gikk fortsatt inn i ferien med en veldig vag plan rundt hva som skulle produseres. Selv om vi ikke visste hvilke funksjoner applikasjonen skulle ha, så var vi ikke uten ting å gjøre i denne perioden. Vi brukte tiden på å sette opp prosjektet i IDE, sette opp styringsverktøy og planlegge smått rundt design. Vi brukte også tid i denne perioden på kompetanseutviklingen innenfor Android, GPS og forskjellige API-er som vi visste at vi kom til å måtte bruke i løpet av prosjektet. 6.2 Forprosjektet Forprosjektet begynte like etter juleferien. Vi satt opp flere møter med oppdragsgiver for å begynne å gjøre kravene til applikasjonen mer konkrete. Dette var en kreativ prosess hvor vi i et grupperom i Pilestredet 35 brain-stormet rundt mulige ideer. Oppdragsgiver hadde også mange spennende tanker rundt hva han ønsker av applikasjonen. Vi endte opp med en kravspesifikasjon som gruppen og oppdragsgiver var enige om. Forprosjekt-rapporten ble levert i slutten av januar. Kravspesifikasjonen var klar i begynnelsen av februar og dette markerte den offisielle starten på produksjonsfasen. Vi satte opp en plan for hva vi ønsket å utrette på de neste 2 ukene og satte i gang med programmering. 44

46 6.3 Produksjonsfasen Etter at vi hadde satt opp vår første to ukers-plan så satte vi i gang med utvikling. En av hovedfokusene i starten var å jobbe med den delen av prosjektet som under utvikling ble kalt På topp. Dette var den applikasjonen som bare skulle lages for oppdragsgiver og som hadde innleveringsfrist vesentlig tidligere enn de andre delene av prosjektet. Det som måtte på plass var backend og applikasjonen, så det var derfor naturlig at det var dette vi startet på i denne perioden februar - 25.februar Dette var den første delen av produksjonsfasen. I denne perioden jobbet vi veldig tett siden det var veldig mye klasser og aktiviteter som ble produsert på kort tid. Da var det greit at vi begge hadde god oversikt over hva hensikten til alle de forskjellige var. Målet i denne første perioden var og ha en tidlig utgave av applikasjonen På topp og en fungerende backend på plass. Målene som skulle testes på slutten av perioden var: Om applikasjonen kunne ta bilder og så sende disse til Instagram. Om applikasjonen og backend kunne kommunisere. Dette skulle testes både med reell data og dummy-data. Vi kom i mål med alle våre mål for denne perioden og kom i tillegg såvidt i gang med hovedapplikasjonen. Som ville være en sentral del av den neste to-ukers perioden. Det var også i løpet av denne perioden hvor vi tok det endelige valget om at vi skulle bruke Parse som backend. Dette valget er redgjort for i rapporten februar - 16.mars I denne delen av prosjektet så hadde vi en fungerende applikasjon som oppnådde oppdragsgivers krav. Så vi fikk levert På topp til oppdragsgiver slik at han kunne teste det videre for oss og komme med eventuelle tilbakemeldinger eller forslag til endringer. Vi rettet fokus mot hovedapplikasjonen På langs. Planen for denne perioden var og få opp en meny med alle elementene som skulle være del av denne og så fokusere på hver vår del av applikasjonen derfra. Her skulle Øyvind jobbe med å vise oppdragsgivers lokasjon på et kart og Alexander skulle jobbe med gå tur -delen. 45

47 Øyvind måtte forholde seg til dummy-data fordi oppdragsgiver ikke hadde fått GPSenheten han skulle gå med levert enda. Målene som skulle testes på slutten av perioden var: At det er mulig og få ut dummy-data i form av en skissert rute via Google Maps API. At det er mulig å gå en tur via applikasjonen. Man skal kunne starte og slutte en tur via en knapp og etter turen bli presentert med den totale distansen. Etter denne perioden så var den tiltenkte funksjonaliteten inne, men foreløpig helt uten tanke på design. I løpet av denne delen så ble valget tatt om at turdelen skulle bruke utelukkende GPS og ikke skritteller. Etter testing av applikasjonen under denne perioden så var vi fornøyde med resultatene som GPS ga oss mars - 2.april I denne perioden så var planen å legge inn de resterende funksjonene i applikasjonen. Blogg-delen av applikasjonen skulle hente bloggen fra nettsiden, men den var ikke oppe enda så der ble det brukt dummy-data. Målene som skulle testes på slutten av perioden var: En fungerende meny for innstillinger. Og muligheten til å slette all brukerinformasjon fra denne menyen. En blogg med dummy-data tilgjengelig fra hovedmenyen. En oversikt over turer og mål for brukeren, tilgjengelig fra hovedmenyen. Forbedret funksjonalitet i turdelen hvor GPS-lokasjonen hentes ut oftere slik at den totale distansen blir mer nøyaktig. Etter denne perioden så hadde vi en applikasjon hvor all planlagt funksjonalitet eksistert. Det var ikke alt som var designet ferdig, men alt var på plass. Det ga oss rom for å legge til noen funksjoner og å begynne å tenke på design. Vi hadde også ventet på en endelig design profil fra et designfirma som først ble levert til oppdragsgiver i slutten av denne perioden. Vi hadde uten denne profilen vært låst fast på designvalg siden vår applikasjon skal ha et helhetlig inntrykk med resten av prosjektets medier. 46

48 april - 21.april Da som vi endelig hadde fått fatt på design-profilen til prosjektet så var det på tide å tenke design. Det betydde at vi måtte tilbake til alle deler av applikasjonen for å pusse opp farger og layout. Oppdragsgiver hadde også fått tak i sin GPS-enhet som gjorde at vi kunne erstatte dummy-dataen i kartet over oppdragsgivers posisjon. Dette var også den siste offisielle 2-ukers perioden som også ble litt lenger enn 2 uker. Etter denne perioden skulle applikasjonen være klar til testing. Målene som skulle testes på slutten av perioden var: En applikasjon som er såpass klar at den kan testes av eksterne testere. At applikasjonen hentet riktig data i alle tilfeller og at all dummy-data var fjernet. (Bortsett fra bloggen, siden nettsiden fortsatt ikke var klar ved starten av denne perioden). Nærme slutten av denne perioden så begynte oppdragsgiver sin tur. Det var aldri et krav om at applikasjonen var ute og klar til denne datoen, men det var allikevel noe vi prøvde å klare. Men veldig sen designprofil og en nettside som først kom opp på samme dag som oppdragsgiver begynte og gå gjorde at applikasjonen fortsatt måtte vente noen uker. Vi ønsket å teste den skikkelig før vi la den ut for nedlasting Problemstillinger underveis Vi møtte som man gjerne gjør under prosjekter av denne størrelsen på en rekke problemer underveis. I denne delen av rapporten vil vi redgjøre for noen av disse og hvordan vi løste disse Manglende design profil En av kravene som oppdragsgiver satt til prosjektet vårt var at det vi produserte skulle ha gjenkjennelighet med prosjektets profil. Det vil si at folk som bruker nettsiden skal skjønne at applikasjonen er en del av prosjektet bare ved hjelp av layouten og fargevalgene. Problemet var at denne designprofilen brukte ganske lang tid på å ankomme og gjorde at applikasjonen fikk et design veldig sent i prosjektet. Som igjen gjorde at publiseringen av applikasjonen ble litt senere enn vi håpet på. Men dette var ingen krise siden vi aldri satt noen krav for prosjektet om at applikasjonen skulle ut på Google Play før oppdragsgiver sin tur startet. 47

49 6.4 Dokumentasjonsfasen Etter at vi var bortimot ferdig med produksjonen gikk vi over i en fase hvor vi skulle skrive rapporten. Men siden det fortsatt var forbedringspotensial på applikasjonen i tillegg så brukte vi også tid på produksjon i denne fasen av prosjektet. Her fulgte vi vår interne veileder sitt råd og satt av 2 dager i uken til produksjon og så brukte vi de andre 5 til skriving. Vi fortsatte i denne perioden våre ukentlige møter med veileder, slik at vi kunne få tilbakemeldinger også på det skriftlige arbeidet vi hadde gjort. Det var definitivt nyttig i denne fasen av prosjektet å få litt innsyn fra utsiden på hvordan rapporten skulle struktureres. 48

50 Testrapport 49

51 7 Testing I denne delen av rapporten vil vi redegjøre for hvordan applikasjonen har blitt kvalitetssikret underveis. 7.1 Verktøy og testenheter Det var viktig for oss å teste applikasjonen på så mange enheter som mulig. Det er en enorm mengde forskjellige enheter som kjører Android og det er også en rekke skjermstørrelser og versjoner av operativsystemet. Vi hadde valgt å sette minimumsgrensen på API nivå 16 (Android 4.1). Derfor så ønsket vi å teste på så mange fysiske enheter som kjørte forskjellige versjoner over dette som mulig. Enheter som vi har brukt til testing: Samsung Galaxy Xcover 2 Samsung Galaxy S4 Samsung Galaxy S2 Sony Xperia Z1 Compact Programvare benyttet til testing: Android emulatorer som er del av Android SDK. Dette er gjennomført gjennom Android Studios. Logcat, et program i Android SDK, som gir oss mulighet til å printe lesbare feilmeldinger fra applikasjonen. 7.2 Testing Fordi vi utviklet en applikasjon med et fokus på at brukeren skulle ut i naturen. Så endte vi også underveis opp med en god del tid brukt i naturen selv. Det var rett og slett lettere å teste turdelen på fysiske enheter i reelle situasjoner, enn å bruke emulator. 50

52 7.2.1 Testing underveis Det ble mye testing underveis spesielt på de delene som krevde bruk av GPS. Dette var i hovedsak turdelen. Vi brukte også mye av den tiden hvor vi måtte gjøre ting uansett på å teste applikasjonen. For eksempel på vei til skolen eller på vei til jobb. Dukket det opp problemer så noterte vi ned disse for å fikse ved første mulighet. 7.3 Forandringer på bakgrunn av testing Underveis under utviklingen var det en rekke forandringer som ble gjort på bakgrunn av kontinuerlig testing. Her er en oppsummering av disse forandringene og hva bakgrunnen for disse var Skritteller fjernet fra turdel Dette var kanskje en av de største forandringene som ble gjort på bakgrunn av testing. Vår originale visjon for turdelen var en løsning som tok til bruk både skritteller og GPS, men den ble skrinlagt. Vi fant ingen god løsning på en nøyaktig skritteller som leverte gode resultater over en rekke enheter. En mulig løsning var skrittelleren som er bygd inn i Android 4.4, men vi ville ikke sette minimumskravet for applikasjonen så høyt. Vi gjorde også Research rundt dette for å være sikre på at vi hadde utforsket alle muligheter. En annen grunn til at denne forandringen ble utført var at GPS alene ga oss gode resultater. Vi fikk også muligheten ved GPS til å presentere brukeren sin tur på et kart. Skritteller sin hovedfunksjon vil være at applikasjonen kunne benyttes innendørs, men det var ingen ønskelige krav til dette fra oppdragsgiver siden prosjektet hadde et gå tur i naturen fokus Færre knapper i turdel Dette var en liten forandring, men det kom frem i testing at vi brukte flere knapper enn brukeren ønsket å forholde seg til. Så i tur-del ble det som originalt var 3 knapper til bare 1. Start og stopp tur ble satt på samme knapp, bare med forskjellig hensikt basert på om brukeren er i en tur eller ikke. Knappen for å vise turen på kart ble fjernet og denne handlingen ble automatisert. 51

53 7.3.3 Bildegalleri i applikasjonen Vi merket oss under testing at testerne gjerne prøvde å trykke på bildet vi hadde på hovedmenyen for å se hva dette gjorde. For oss var dette i utgangspunktet bare et bilde for å pynte på skjermbildet, men vi innså på dette punktet at det ble forvirrende for brukeren med et grafisk element av lik størrelse som knappene som ikke gjorde noe. Løsningen ble å gjøre det om til en knapp som ledet til et bildegalleri med bilder fra oppdragsgiver sin tur. Dette var også det testerne forventet å finne da vi spurte dem hvorfor de trykket på bildet. Det var derfor en naturlig funksjon å legge til Informasjon om M/S Norge I likhet med bildeknappen på hovedmenyen så trodde testerne at M/S Norge logoen var en knapp. Dette løste vi på en liknende måte som med bildesituasjonen, men istedenfor en helt egen aktivitet så gjorde vi at å trykke på logoen gir brukeren informasjon om prosjektet M/S Norge i en dialog boks. 7.4 Brukertesting Selv om vi testet mye på egenhånd, var det også viktig å hente tilbakemeldinger fra potensielle brukere. Spesielt ønsket vi tilbakemeldinger fra brukere med andre forutsetninger innenfor teknologi. Vi plukket derfor ut en variert gruppe venner og bekjente som fikk prøve applikasjonen tidlig i applikasjonens levetid. Dette ble en type alfa-testing. Tilbakemeldingene samlet vi i den følgende tabellen. 52

54 Tilbakemelding Enhet Kommentar Status Kræsjer uten GPS i turdel. Flere La til en dialogboks som spør brukeren om og slå på GPS. Ok Bildet på hovedmenyen gjør ikke noe. Flere Forklart i Ok Tur leverer 7km i distanse uansett. Samsung S3 Feil i utregning Ok Kartet viser Sidney, Australia. Samsung S2 Glemt å slette dummydata Ok Applikasjonen kræsjer noen ganger tilfeldig. Xcover 2 Trolig ok 53

55 8 Avsluttende del Dette er den avsluttende delen av rapporten hvor vi kommer med noen tanker og konklusjoner hvordan prosjektet gikk og hva vi fikk ut av det. 8.1 Nytteverdi Det er naturlig etter et prosjekt av denne størrelsen å se på hva man sitter igjen med og vurdere nytteverdien av dette for de diverse interessentene av prosjektet For applikasjonens brukere Vi har hele tiden vært klare på at produktet vi produserer skal publiseres og ut blant ekte brukere. Det var derfor viktig å produsere noe som ikke bare ser bra ut, men fungerer bra. En av måtene vi har kvalitetssikret applikasjonen vår mot sluttbrukerne er å utføre mye kvalitativ testing hvor vi har testet applikasjonen på faktiske enheter i faktiske situasjoner. Resultatet av dette er at vi sitter igjen med en robust applikasjonen som vi er fornøyd med å publisere på Google Play. Vi la applikasjonen ut for nedlasting på Google Play før prosjektperioden var over for å finne ut hva brukerne synes. Vi forventet ikke en strøm av folk basert på dette, men var spent på reaksjonen fra de vi potensielt fikk til å laste ned applikasjonen. Vi brukte dette som en slags beta testing periode hvor vi kunne løpende fikse problemer som oppstod For oppdragsgiver Siden vi lagde to applikasjoner hvorav en er rettet mot så mange som mulig og en bare skal brukes av oppdragsgiver så tar vi de for oss, hver for seg. 54

56 På langs Dette er hovedapplikasjonen som er ment for offentlig publisering. Oppdragsgiver ønsket en applikasjon som skulle motivere andre til og dra på turer i skog og mark. I tillegg til dette skulle vi levere en enklere tilgang til prosjektet til oppdragsgiver på mobile enheter. Vi har jobbet hardt med å sørge for at applikasjonen holder seg til hovedprosjektet sin design profil og filosofi. Og resultatet er en applikasjon som kan publiseres og brukes av oppdragsgiver til å synligjøre og promotere prosjektet sitt. Vi har også planer om å støtte opp under applikasjonen videre i prosjektperioden til oppdragsgiver. Dette altså da utover prosjektperioden til hovedoppgaven På topp Denne applikasjonen var produsert kun for oppdragsgiver. Vi la inn akkurat de funksjonene som oppdragsgiver ønsket og holdt det simpelt utenom dette. Denne delen av prosjektet gjorde vi ferdig ganske tidlig i prosjektperioden slik at vi fikk testet det gjennom at oppdragsgiver tok med seg applikasjonen på en av oppvarmingsturene sine. Vi har fått gode tilbakemeldinger på at denne applikasjonen oppfyller kravene som var satt til den. 8.2 Videre utvikling I det fløyta går for bacheloroppgaven 2015 så er oppdragsgiveren vår et sted mellom Jotunheimen og Trollheimen. Dette vil si at selv om vårt prosjekt er ved veis ende, så har han fortsatt flere måneder med reise foran seg før han når sitt mål. Dette har vi lyst til å være med på og vi har derfor planer om å støtte applikasjonen videre ut oppdragsgiver sin prosjektperiode. I praksis betyr dette å legge ut oppdateringer som fikser problemer brukere har. Noe som trolig er sannsynlig siden det er vanskelig og ta alle forutsetninger når man utvikler til Android. Det er en alt for stor mengde Android API nivåer og enheter til at man kan teste for alt. I tillegg vil vi stå klare til å legge til funksjonalitet om oppdragsgiver skulle ringe inn noen ønsker fra hvor enn i landet han er. 55

57 8.3 Læringsutbytte Vi føler vi har lært mye om bruken av eksterne API er i Android programmering. Og om hvordan skrive kode og benytte seg av et backend som støtter opp under en applikasjon. Dette var noe ingen av oss hadde vært borte i fra før av. Vi har også lært mye om det å jobbe i gruppe på et såpass stort prosjekt. Og hvordan vi burde ha prioritert skriving og dokumentasjon i en høyere grad, i en tidligere fase av prosjektet. 8.4 Konklusjon Nå som applikasjonen blir publisert og kan lastes ned av alle, håper vi at den kan oppfylle de målene som ble satt for prosjektet. Det er vanskelig å vite hvor godt mottatt den vil bli før det har gått noen uker, men vi håper folk vil ta den i bruk og bli motivert til å komme seg ut på tur. Når det gjelder den delen av systemet som oppdragsgiver benytter seg av så er den i bruk, og han er godt fornøyd med funksjonaliteten. Når det gjelder våre egne mål for produktet føler vi at vi har lært mye, selv om vi innser at vi kanskje kunne lært mer om å jobbe med en oppdragsgiver, dersom oppdragsgiveren hadde vært mer ekstern. Vi er allikevel veldig glade for å kunne være del av et slikt positivt, inspirerende og unikt prosjekt 56

58 9 Ordliste Android API Dialog Google Play Git GitHub GPS GUI IDE Java Operativsystemet til mobile enheter basert på Java. Utviklet av Google. Står for Application Programming Interface. Det betegner et grensesnitt i en programvare slik at deler av denne kan kjøres i annen programvare. En boks som gir brukeren informasjon eller valgmuligheter. Dette er hovedkilden til applikasjoner i Android operativsystemet. Et bibliotek/en butikk med applikasjoner. Et verktøy for versjonshåndtering i programvare-utvikling. GitHub er en hosting tjeneste hvor man kan legge ut prosjekter som benytter seg av Git som versjonshåndtering. Global Positioning System. System som gjør det mulig å fastsette egen posisjon basert på satellitter. Graphical user interface eller grafisk brukergrensesnitt. Integrated development environment er programvare som brukes til å skrive annen programvare. Et objekt orientert programmeringsspråk. 57

59 Parse En løsning for skylagring eid av Facebook. Repository SDK SharedPreferences Skype Toast Software development kit er en pakke med verktøy og ressurser for utvikling. En lagringsmetode for Android, hovedsakelig for innstillinger. Forsvinner ikke etter at applikasjonen avsluttes. Programvare for IP-telefoni, skjermdeling og webcam. En liten boks med en beskjed til brukeren. 10 Kilder

60 11 Vedlegg 59

61 Kravspesifikasjon Øyvind Årset og Alexander Jensen Maaby Gruppe

62 Forord Kravspesifikasjonen er et internt styringsdokument som skal fungere som en del av avtalen mellom oppdragsgiver og prosjektgruppen. I dokumentet skal oppdragsgiver sine krav til produktet spesifiseres. Dokumentet er tilegnet alle interessenter av produktet og fagterminologi er tatt til bruk. Dokumentet er opprettet i samarbeid mellom gruppen og oppdragsgiver og skal være godkjent av alle parter før det regnes som gyldig. Leserveiledning Kravspesifikasjonen starter med en introduksjon av de diverse interessentene av prosjektet, bakgrunnen for at prosjektet skal gjennomføres og en beskrivelse av oppgaven. Videre følger funksjonelle krav og ikke funksjonelle krav. Gjennomgående for kravspesifikasjonen er det brukt teknisk språk. Disse ordene er forklart i fotnoter og kan også finnes i ordlisten på slutten av rapporten.

63 Innhold Kravspesifikasjon... 1 Forord... 2 Leserveiledning Introduksjon Gruppen Oppdragsgiver Veileder Oppgaven Systembeskrivelse Mål Rammebetingelser Funksjonelle krav Prioritert funksjonalitet På topp På langs Backend Ønskelig funksjonalitet På topp På langs Eventuell funksjonalitet På langs Ikke-funksjonelle krav Produktkrav Brukervennlighet Effektivitet Pålitelighet Prosesskrav Utviklingsmetodikk Leveransekrav Teknologikrav Endringshåndtering Oppdragsgiver Gruppen Use cases Risikoplan Brukerveiledning... 16

64 Forord Installering Bruk av applikasjonen Turdelen Bildegalleri Blogg Følg Oppdragsgiver på tur Ukesmål historie Kildekode CD... Feil! Bokmerke er ikke definert. 1. Introduksjon I dette kapittelet introdusere vi prosjektet. 1.1 Gruppen Gruppen består av Øyvind Årset og Alexander Jensen Maaby. Vi går begge på linjen Anvendt Datateknologi. Vi har jobbet sammen på en rekke prosjekter gjennom studietiden på Høgskolen i Oslo og Akershus og føler vi har opparbeidet oss gode rutiner og et godt samarbeid. Alexander Jensen Maaby - s189101@stud.hioa.no Øyvind Årset - s189099@stud.hioa.no 1.2 Oppdragsgiver Oppdragsgiver og forsåvidt også kunde for prosjektet er Steinar Årset. Han skal på sin drømmereise fra Lindesnes til Nordkapp i et prosjekt som har fått tittelen M/S Norge - Fra motgang til Nordkapp. Det skal for prosjektet produseres en nettside med blogg, en dokumentarfilm og en mobil applikasjon. Vår oppgave er å produsere mobil applikasjonen. Vår del skal følge like designprofil som resten av prosjektet og dette gjør at vi vil måtte forholde oss til de som skal produsere nettsiden. Men i hovedsak så blir det Steinar Årset som er vår kontaktperson om det er noe vi lurer på rundt prosjektet.

65 Steinar Årset E-post: Tlf: Veileder Prosjektet utføres ved instituttet for informatikk ved Høgskolen i Oslo og Akershus. Vår interne veileder er høgskolelektor Torunn Gjester. 2. Oppgaven Oppdragsgiver skal som tidligere nevnt på sin livs drømmetur fra Lindesnes til Nordkapp. Dette skal det produseres en dokumentarfilm av og han skal i tillegg være aktiv underveis med blogg oppdateringer og bilder på blant annet Instagram. Vi har fått i oppdrag om å lage en applikasjon som skal inneholde alt dette han produserer. I tillegg til dette skal det være en turdel hvor brukeren kan gå på og lagre sine egne turer. En egen applikasjon skal også lages bare for oppdragsgiver som raskt skal legge bilder inn på Instagram og nye innlegg inn i bloggen. Dette for å spare han tid når han er på tur. 3. Systembeskrivelse Det skal utvikles to applikasjoner som skal fungere på Android enheter. Den ene skal utelukkende brukes av oppdragsgiver og utvikles derfor spesifikt til enheten som oppdragsgiver skal bruke. Denne applikasjonen går under utvklingsnavnet På topp. Denne skal kunne kommunisere med en back end løsning for å laste opp blogginnlegg til oppdragsgiver sin nettside (nettsiden er ikke utviklet av oss) og til en Android applikasjon som vi skal utvikle. Den skal også kunne ta og sende bilder både til nettsiden/applikasjonen og Instagram. Hovedelen av prosjektet blir den andre Android applikasjonen under utviklingsnavnet På langs. Her skal brukere få tilgang til alt nettsiden har og by på. Dette ville si

66 blogg, oppdragsgiver nåværende lokasjon presentert på et kart og bilder. I tillegg skal det være funksjonalitet for at brukere skal kunne gå og lagre egne turer. Det skal også være mulig å sette ukentlige mål på hvor langt man skal gå på en uke. Oppnås dette målet skal brukeren bli belønnet med eksklusivt innhold fra turen til oppdragsgiver (I form av bilder og tekst). Det skal også produseres en backend løsning for prosjektet. Denne skal håndtere data for de to applikasjonene vi produserer og i tillegg ha mulighet til å kommunisere med nettsiden. Det skal også kontinuerlig lagres nye posisjoner for hvor oppdragsgiver befinner seg ved hjelp av data sendt fra en GPS Sattelitt enhet. 3.1 Mål Applikasjonen skal presentere innholdet fra nettsiden optimalisert for mobile enheter med forskjellige skjermstørrelser. Applikasjonen skal ha kunne kjøres på et så bredt spekter av Android enheter som mulig. Produsere en spennende turdel som gir brukere enn god grunn til å velge applikasjonen over å følge prosjektet til oppdragsgiver kun via nettsiden/bloggen. 3.2 Rammebetingelser Applikasjonen skal utvikles til Android. Applikasjonen skal følge designprofilen til prosjektet M/S Norge. 4. Funksjonelle krav Funksjonelle krav er krav til systemet. Disse der delt inn i tre forskjellige kategorier basert på viktigheten deres i det endelige produktet. Disse kategoriene er prioritert funksjonalitet, som vil fungere som minimumskrav til det endelig produktet. Ønskelig funksjonalitet som er ting vi gjerne vil implementere, men som først vil jobbes med etter at det prioriterte er på plass. Til slutt kommer eventuell funksjonalitet som da er ekstra ting vi kan legge til om vi har ekstra tid etter at alt annet er lagt inn. Siden

67 oppgaven vår på mange måter er tredelt gjennom 2 applikasjoner og en backend så velger vi å sette opp kravene til de forskjellige delene hver for seg for best oversikt. 4.1 Prioritert funksjonalitet Dette er funksjonaliteten som vi i samarbeid med oppdragsgiver har bestemt oss for at må være på plass for at prosjektet kan kalles ferdig På topp Brukeren skal kunne: Ta bilder via applikasjonen å sende disse via backend til nettsiden/bloggen/instagram. Skrive blogg-innlegg som kan sendes rett inn nettsiden/bloggen via backend På langs Brukeren skal kunne: Følge turen til oppdragsgiver i et kart. Her skal GPS lokasjon hentes via SPOT sin API og presenteres ved bruk av Google Maps API. Se blogg-innleggene som oppdragsgiver skriver underveis på turen sin. Sette seg ukentlige mål for hvor langt han ønsker og gå den uken. Gå turer hvor distansen blir lagt til på ukentlig progresjon mot målet Backend Backend skal kunne: Håndtere bilder og blogg-innlegg og legge disse inn på en server.

68 4.2 Ønskelig funksjonalitet Dette er funksjonalitet som vi gjerne vil legge til, men som har lavere prioritet enn prioritert funksjonalitet På topp På topp er en applikasjon som ikke trenger noe ekstra funksjonalitet. Oppdragsgiver ønsker noe som oppfyller kravene til applikasjonen på en så velfungerende måte som mulig På langs Brukeren skal kunne: Slette brukerdataen sin for å starte på nytt i applikasjonen uten å avinstallere applikasjonen. Se statistikk og historie rundt turene som er gått tidligere. Bli presentert turen sin oppsummert via streker mellom GPS punkter ved hjelp av Google Maps API. 4.3 Eventuell funksjonalitet Dette er funksjonaliteten som kommer etter alt annet er lagt inn. Dette er i hovedsak ting som er langt i fra essensielt for applikasjonen, men som likevel kan være nyttig for brukeren. Her er det bare På langs delen av prosjektet som har utvidingspotensiale. Siden backend og på topp har fastsatte mål for hva det skal utrette og ikke trenger å gjøre noe utover dette På langs Brukeren skal kunne: Se tur-statistikken sin opp mot gjennomsittet av alle brukere. Se bilder fra turen til oppdragsgiver presentert i et bildegalleri.

69 Ta bilder når han/hun er ute og går tur rett fra applikasjonen. Dele turer som er gått via applikasjonen via Facebook, Twitter og Instagram. 5. Ikke-funksjonelle krav Et ikke-funksjonelt krav beskriver hvilke egenskaper, kvaliteter og begrensninger et system må inneha, og er delt opp i produktkrav, prosess krav og eksternekrav. 5.1 Produktkrav Produktkrav omhandler krav til det ferdige produktet som ikke er en direkte funksjon. Dette omhandler krav til brukervennlighet, effektivitet og pålitelighet Brukervennlighet Applikasjonen skal være på norsk. Applikasjonen skal ha navigasjon som skal falle naturlig for den gjennomsnittlige bruker. Applikasjonen skal ikke ha tekst som er vanskelig å lese. Applikasjonen skal følge Android sine anbefalninger til design. Applikasjonen skal følge oppdragsgiver sitt prosjekt sin design profil for best mulig gjennkjennlighet gjennom de forskjellige platformene til prosjektet Effektivitet Applikasjonen skal i så stor grad som mulig begrense sin batteribruk. Applikasjonen skal også i så stor grad som mulig begrense sin nettverksbruk. Applikasjonen skal være minst mulig krevende å kjøre for enheten Pålitelighet

70 Innholdet som finnes i applikasjonen skal alltid være oppdatert i forhold til innholdet som ligger på nettsiden. 5.2 Prosesskrav Prosesskrav omhandler krav rundt utviklingsprosessen. Det vil si blant annet metodikk og standarder. Fordi oppdragsgiver ikke har teknisk bakgrunn, så står vi her fritt til og ta våre egne valg Utviklingsmetodikk Det stilles ingen offisielle krav til utviklingsmetode, men under utviklingen skal det utvikles i 2-ukers perioder hvor det på forhånd er satt klare mål over hva som skal oppnås Leveransekrav Applikasjonen til oppdragsgiver (Produksjonsnavn På topp ) skal være ferdig innen 1.mars Applikasjonen som skal ut til brukere (Produksjonsnavn På langs ) skal være publisert på Google Play innen 3. mai Sluttrapporten skal leveres innen 26. mai Teknologikrav Applikasjonen skal utvikles i Android Studios. Applikasjonen skal utvikles til et minimums API-nivå 16.

71 6. Endringshåndtering Dette kapittelet handler om prosedyrene rundt endringer underveis i prosjektet. Altså hvem som kan komme med forslag til endringer og hvordan disse vil bli evaluert. 6.1 Oppdragsgiver Ønsker oppdragsgiver endringer på rammene for en av de to applikasjonene som skal produseres må dette tas opp med gruppen. Gruppen vil videre diskutere hvorvidt disse endringene lar seg gjøre og hvor mye arbeid som vil bli forkastet på bakgrunn av endringene. Gruppen har her full vetorett om de føler at endringene ikke lar seg gjøre av tidsmessige eller andre årsaker, og kan fortsette prosjektet etter den kravspesifikasjonen som gruppen og oppdragsgiver har blitt enige om. 6.2 Gruppen Ønsker gruppen å endre rammene for en av de to applikasjonene må de ta kontakt med oppdragsgiver og foreslå endringene. Er det funksjoner gruppen ønsker å endre på eller å legge til kan oppdragsgiver bruke sin vetorett om funksjonaliteten ikke er ønskelig. Ved endringer til bruk av backend løsninger eller annen teknologi så står gruppen fritt til og ta sine egne valg.

72 Use cases Mulighetene til brukeren fra hovedmenyen i applikasjonen.

73 Navn Aktør: Registrer tur Bruker Prebetingelser: Postbetingelser: Hovedflyt: Unntak: Alternativ flyt 1: Alternativ flyt 2: Turen er lagret i applikasjonens lokale database. 1. Brukeren velger start tur fra hovedmenyen. 2. Brukeren trykker start tur. 3. Brukeren går tur. 4. Brukeren trykker stopp tur. 1. Brukeren setter ikke ukesmål og use-casen slutter. 2. Brukeren slår ikke på GPS og use-casen slutter. 1.1 Brukeren setter ukesmål. 2.1 Brukeren slår på GPS. Skriftlig beskrivelse for og gå tur i applikasjonen.

74 Risikoplan En evaluering av mulige problemer underveis og vurdering av konsekvensen av disse. Beskrivelse Sannsynlighet Konsekvens Tiltak Sykdom Middels Middels Her må god kommunikasjon underveis brukes slik at sykdom ikke påvirker prosessen. For omfattende prosjekt Lav Lav Ha klare planer for hvordan prosjektet sine rammer kan utvides underveis om nødvendig. En mulighet her er å porte applikasjonen til andre platformer om det blir nødvendig å utvide prosjektet. Kommunikasjonssvikt Lav Middels Sette opp gode kanaler for kommunikasjon på forhånd av prosjektstart. Ha fastsatte tider hvor gruppen skal kommunisere. Manglende kunnskap om teknologi Middels Middels Sette av nok tid til å lære de nødvendige teknologiene underveis. Tap av data Lav Høy Aktivt bruke versjonshåndtering underveis.

75

76 Brukerveiledning Øyvind Årset Alexander Jensen Maaby Forord Dette dokumentet tar for seg hvordan man bruker applikasjonen M/S Norge. Tidligere i kapittel 3 presenterte vi produktet på en teknisk måte. Dette dokumentet er beregnet for nye brukere av applikasjonen med lite erfaring med Android. 1 Installering For å installere applikasjonen trenger man en smarttelefon som kjører minst versjon 4.1 av Android. For mer informasjon om forskjellige versjoner av Android sjekk Du må også godkjenne at applikasjonen bruker GPS og bilder/medier/filer på enheten din.