HOVEDPROSJEKT

HOVEDPROSJEKTETS TITTEL

Kost

DATO

27.05.2014

ANTALL SIDER / BILAG

125

PROSJEKTDELTAKERE

Jonas Moltzau s176250

Martin Witsø Løkkeberg s176251

INTERN VEILEDER

Eva Hadler Vihovde

OPPDRAGSGIVER

Studieretning for samfunnsernæring HIOA

v/ Asgeir Brevik

KONTAKTPERSON

Asgeir Brevik

SAMMENDRAG

Oppgaven går ut på å utvikle en IT-løsning for innrapportering av data for bruk i forskning ved

Instituttet HEL. Denne består av en Android applikasjon, hvor brukere kan registrere kostholdsvaner

basert på mattilsynets matvaretabell, og et API med tilhørende web-grensesnitt utviklet i MS Visual

Studio, for registrering av matkonsum og uthenting av statistiske rådata. Systemet skal forenkle

forskningsprosessen for forskere i ernæringsmiljøet ved HEL, samt at den skal appellere til vanlige

brukere og promotere kostholdsbevissthet.

3 STIKKORD

Android

Kosthold

Web-API

Studieprogram: Ingeniørfag-data

Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo

Besøksadresse: Holbergs plass, Oslo

PROSJEKT NR.

2014-12

TILGJENGELIGHET

Lukket

Telefon: 22 45 32 00

Telefaks: 22 45 32 05

Kost 2014

Forord

Denne rapporten er kulminasjonen av flere måneders hardt arbeid, hvor vi har dratt på alle de erfaringer vi har ervervet oss i løpet av vår bachelorgrad ved Høgskolen i Oslo og Akershus. Oppgaven var av en vesentlig størrelse og vårt ambisjonsnivå gav oss muligheten til å produsere et produkt vi er stolte av å ha eierskap til og som nå faktisk skal settes til livet. Ferdigstillelsen av dette prosjektet og denne dokumentasjonen hadde ikke vært mulig uten vår veileder Eva Hadler Vihovde og vår oppdragsgiver Asgeir Brevik. Eva har holdt oss på stø kurs og gitt oss den veiledningen vi trengte for å holde motivasjonen oppe når prosjektet til tider virket uoverkommelig. Hun har kommet med verdifulle innspill og gjennom disse gitt oss et klarere perspektiv på oppgaven og våre evner og begrensninger. Asgeir Brevik har vært en iderik og entusiastisk oppdragsgiver og kontaktperson gjennom det hele. Han skal ha all ære for å ha dannet grunnlaget for oppgaven med en utmerket idé og oppgavebeskrivelse. Under utviklingen har han gitt oss stor selvstendighet og kreativ frihet til å forme produktets struktur etter den visjonen som presenterte seg for oss i vår rolle som programmerere. Denne visjonen sammen med Asgeirs idéer bidro til at produktet ble mer enn bare et forskningsverktøy, men også noe vanlige forbrukere kan ha nytte av i sin hverdag, og på den måten bidra til høyere kostholdsbevissthet og et bredere forskningsgrunnlag. Vi ønsker derfor å takke dere begge for støtten og alle mulighetene vi ble gitt.

Kost 2014

Leserveiledning

Dokumentasjonen vil forsøke å gi en samlet oversikt og beskrivelse av et arbeid som startet allerede høsten 2013 og som nå er avsluttet 27. mai 2014. Målgruppen for denne dokumentasjonen er i hovedsak produktets interessenter, veileder og sensor. Det er også lagt opp til at produktdelen kan brukes, med visse endringer, som brukerveiledning eller innføring.

Oppbygning Rapporten består av en presentasjonsdel, tre hoveddeler og en avsluttende del. Presentasjonsdelen inneholder en introduksjon av selve oppgaven, de ulike interessentene i prosjektet og et sammendrag av det endelige produktet. Første hoveddel, kalt Produktet, tar for seg produktet i detalj. Her gjennomgås våre mål og intensjoner under utviklingen, funksjonaliteten sett fra et brukerperspektiv og systemets struktur og bakenforliggende mekanismer. I neste del, kalt Utvikling, gis et innblikk i hvordan utviklingen har foregått og hvilke utfordringer vi støtte på underveis. Her blir også tilblivelsen av prosjektets grafiske profil presentert, sammen med en gjennomgang av testingen som er utført på systemet og hvordan denne hjalp oss med å drive utviklingen videre uten kritiske feil. Tredje hoveddel Prosess tar for seg planleggingen og prosessen i arbeidet med prosjektet, bl.a. avgrensning og redefinering av oppgaven, utviklingsmetodikk, prosjektstyring og verktøy. Til sist kommer en avsluttende del med en konklusjon som beskriver vår erfaring med prosjektet og et tilbakeblikk på læringsutbytte og utfordringer.

Struktur Slik rapporten foreligger er intensjonen at den skal kunne leses fra A til Å. Vi har valgt, i samarbeid med veileder, å strukturere dokumentasjonen mer sammenfattet enn det som tidligere har vært normen. Rapporten er ment å sees som en helhet og delene er ikke beregnet for å være enkeltstående rapporter. Det finnes av den grunn kun én innholdsfortegnelse som omfatter hele dokumentet og antallet repetisjoner er redusert til det helt nødvendige. Dette ga oss muligheten til å lage dokumentasjonen mer konsis, samt mer lettleselig og navigerbar i sin helhet.

Fokus Hvis man ikke har mulighet til å lese dokumentasjonen ord for ord vil vi anbefale å fokusere på presentasjon, produkt og avslutning. Dette er de delene som sammen gir en rask og grundig innsikt i systemet slik det i dag foreligger, og bør derfor prioriteres.

Ord og begreper Det er visse ord og begreper som er brukt om hverandre i denne dokumentasjonen, men som betyr så godt som det samme. Applikasjonen for Android henvises til som applikasjonen, appen og app. Skjermene inne i appen kan refereres til som en aktivitet (dette er Androids ord for skjermer). Denne dokumentasjonen kalles enten rapporten eller dokumentasjon. Vanskelige ord og begreper er definert i en alfabetisk ordliste lagt inn etter avslutningsdelen.

Kost 2014 Innhold

Innhold

DEL 1 – PRESENTASJON .................................................................................................................................... 6

1.1 - OM GRUPPEN .................................................................................................................................................. 7 1.2 - OPPGAVEN ..................................................................................................................................................... 7

1.2.1 - Oppdragsgiver ..................................................................................................................................... 7 1.2.2 - Bakgrunn ............................................................................................................................................. 8 1.2.3 – Mål ...................................................................................................................................................... 8

1.3 – SLUTTPRODUKT ............................................................................................................................................... 9 1.3.1 - App .................................................................................................................................................... 10 1.3.2 – API og Administrasjonsside ............................................................................................................... 10

DEL 2 – PRODUKT ........................................................................................................................................... 11

2.1 - APPLIKASJONEN ............................................................................................................................................. 12 2.1.1 - Login .................................................................................................................................................. 12

2.1.1.1 - Login-skjermen ............................................................................................................................................ 12 2.1.1.2 – Rolle og funksjonalitet ................................................................................................................................ 13

2.1.2 – Hjemskjermen ................................................................................................................................... 14 2.1.2.1 - Anbefalt energifordeling og hjemskjermen generelt ................................................................................... 15 2.1.2.2 - Din energifordeling ...................................................................................................................................... 15 2.1.2.3 - Vanskelighetsgrad ........................................................................................................................................ 15

2.1.3 - Utforsk ............................................................................................................................................... 16 2.1.3.1 - Beskrivelse ................................................................................................................................................... 16 2.1.3.2 – Skjermens rolle............................................................................................................................................ 17 2.1.3.3 – Spesifikt for måltider ................................................................................................................................... 17

2.1.4 – Vis-skjermen ..................................................................................................................................... 18 2.1.4.1 – Felles for alle vis-skjermene ........................................................................................................................ 18 2.1.4.2 – Unikt for matvarer kategorien .................................................................................................................... 19 2.1.4.3– Unikt for retter kategorien ........................................................................................................................... 19 2.1.4.4 – Unikt for måltider og oppskrifter kategoriene ............................................................................................ 20

2.1.5 - Søking ................................................................................................................................................ 21 2.1.5.1 - Kort om søk .................................................................................................................................................. 21 2.1.6 - Spist ................................................................................................................................................................ 22 2.1.6.1 - Historikk og navigasjon deretter .................................................................................................................. 22 2.1.6.2 - Selve listen ................................................................................................................................................... 23 2.1.6.3 - Liste over næringsstoffer ............................................................................................................................. 23 2.1.6.4 - Kakediagrammenes funksjon og farge ......................................................................................................... 24

2.1.7 - Nytt måltid ........................................................................................................................................ 25 2.1.7.1 - Hva kan man legge til? ................................................................................................................................. 25 2.1.7.2 – Tittel og liste................................................................................................................................................ 26 2.1.7.3 - Knapperaden................................................................................................................................................ 26

2.1.8 – Navigasjon ........................................................................................................................................ 28 2.1.8.1 - Menylinje ..................................................................................................................................................... 28 2.1.8.2 – Nedtrekksmenyen ....................................................................................................................................... 28

2.1.9 - Innstillinger ........................................................................................................................................ 29 2.1.9.1 – Nettverk og oppdateringer ......................................................................................................................... 30 2.1.9.2 – Generelle innstillinger ................................................................................................................................. 30 2.1.9.3 - Bruker .......................................................................................................................................................... 32 2.1.9.4 - Logg ut ......................................................................................................................................................... 32

2.2 NETTSIDE ....................................................................................................................................................... 33 2.2.0.1 Generelt ......................................................................................................................................................... 33 2.2.0.2 Forside ........................................................................................................................................................... 33 2.2.0.3 API Hjelpesider ............................................................................................................................................... 34 2.2.0.4 Innlogging ...................................................................................................................................................... 35

2.2.1 Administrasjonsfunksjonalitet ............................................................................................................. 35 2.2.1.1 Matvarer ........................................................................................................................................................ 35 2.2.1.2 Enheter .......................................................................................................................................................... 37

Kost 2014 Innhold

2.2.1.3 Retter og kategorier ....................................................................................................................................... 37 2.2.1.4 Versjonsnummer............................................................................................................................................ 38 2.2.1.5 Rådata ............................................................................................................................................................ 40 2.2.1.6 Tokens ............................................................................................................................................................ 40

2.3 API ............................................................................................................................................................... 41 2.3.1 Ressurser ............................................................................................................................................. 41

2.3.1.1 Matvarer og Retter ........................................................................................................................................ 41 2.3.1.2 Enheter .......................................................................................................................................................... 42 2.3.1.3 Rettkategorier ................................................................................................................................................ 42 2.3.1.4 Andre ............................................................................................................................................................. 42

2.3.2 Tilgang og bruk .................................................................................................................................... 44 2.3.2.1 Autorisering ................................................................................................................................................... 44 2.3.2.2 Filtrering ......................................................................................................................................................... 44 2.3.2.3 Bruk ................................................................................................................................................................ 44 2.3.2.4 Responskoder ................................................................................................................................................ 45

2.4 PROGRAMSTRUKTUR ........................................................................................................................................ 45 2.4.1 Databasedesign ................................................................................................................................... 46

2.4.1.1 - Matvarer og Enheter: App og Server ........................................................................................................... 46 2.4.1.2 – Retter: App og Server .................................................................................................................................. 47 2.4.1.3 - Spiste matvarer og rapportering: App og Server ......................................................................................... 47 2.4.1.4 – Måltider: App .............................................................................................................................................. 48 2.4.1.5 - UserEaten: App ............................................................................................................................................ 48 2.4.1.6 - Komplette entitetsdiagrammer over databasene med attributter .............................................................. 49

2.4.2 - JSON .................................................................................................................................................. 51 2.4.3 - MVC ................................................................................................................................................... 51 2.4.4 - Appstruktur ....................................................................................................................................... 51

2.4.4.1 - Generelt om Android ................................................................................................................................... 51 2.4.4.2 - Vår struktur .................................................................................................................................................. 52

2.4.5 – Serverside-struktur ........................................................................................................................... 56 2.4.5.1 - Database – MSSQL og Entity Framework Code First .................................................................................... 57 2.4.5.2 - REST API ....................................................................................................................................................... 57

2.5 PERSONVERN OG ANONYMITET ........................................................................................................................... 58

DEL 3 – UTVIKLING ......................................................................................................................................... 59

3.1 - KONSEPTUTVIKLING ........................................................................................................................................ 60 3.1.1 - Logo og navn ..................................................................................................................................... 60

3.1.1.1 - Navnet Kost.................................................................................................................................................. 60 3.1.1.2 - Logo ............................................................................................................................................................. 60 3.1.1.3 - Slagord og helheten ..................................................................................................................................... 61 3.1.1.4 - Sammendrag ................................................................................................................................................ 61 3.1.1.5 - Videreutvikling og helhet ............................................................................................................................. 62

3.1.2 - Tidlig designprosess og skisser .......................................................................................................... 63 3.1.2.1 - Innehold ....................................................................................................................................................... 63 3.1.3.1 - Skissenes rolle .............................................................................................................................................. 63

3.2 – UTVIKLINGSHISTORIER .................................................................................................................................... 64 3.2.1 – Spist kakediagram ............................................................................................................................ 64

3.2.1.1 - Lerret og størrelse........................................................................................................................................ 64 3.2.1.2 - Fargen .......................................................................................................................................................... 65 3.2.1.3 - Tekst ............................................................................................................................................................ 66 3.2.1.4 – Vår erfaring ................................................................................................................................................. 66

3.2.2 - Søkefunksjonalitet ............................................................................................................................. 67 3.2.2.1 - Original versjon ............................................................................................................................................ 67 3.2.2.2 - Første forbedring ......................................................................................................................................... 67 3.2.2.3 - Andre forbedring ......................................................................................................................................... 68 3.2.2.4 - Tredje forbedring ......................................................................................................................................... 68 3.2.2.5 - Utfordringer med flere Cursors ................................................................................................................... 69 3.2.2.6 - Den endelige løsningen ................................................................................................................................ 70

3.2.3 – Oppdateringer .................................................................................................................................. 70 3.2.3.1 – Første iterasjon ........................................................................................................................................... 70 3.2.3.2 – Blokking av hovedtråden ............................................................................................................................. 73 3.2.3.3 – Feiltesting .................................................................................................................................................... 73

Kost 2014 Innhold

3.2.3.4 – Andre iterasjon ........................................................................................................................................... 73 3.2.3.5 – Konklusjon ................................................................................................................................................... 75

3.3 – TESTING ...................................................................................................................................................... 75 3.3.1 - Valg ................................................................................................................................................................. 75 3.3.1 - Utviklertesting ................................................................................................................................................ 75 3.3.2 - Brukertesting .................................................................................................................................................. 76 3.3.3 - Vår erfaring ..................................................................................................................................................... 76 3.3.4 – Videre testing ................................................................................................................................................. 77

3.4 OM VERKTØY .................................................................................................................................................. 78 3.4.1 – Selvutviklede støtteprogrammer ...................................................................................................... 78

3.4.1.1 - FolderDiff ..................................................................................................................................................... 78 3.4.1.2 - MatvaretabellImporter ................................................................................................................................ 78 3.4.1.3 - UsernameHasher ......................................................................................................................................... 79

3.4.2 - Verktøysoversikt ................................................................................................................................ 80 3.4.2.1 - Eclipse .......................................................................................................................................................... 80 3.4.2.2 - MS Visual Studio .......................................................................................................................................... 80 3.4.2.3 - SQLite Spy .................................................................................................................................................... 80 3.4.2.4 - Fiddler .......................................................................................................................................................... 80 3.4.2.5 - Microsoft Office ........................................................................................................................................... 80 3.4.2.6 - Adobe Photoshop ........................................................................................................................................ 81 3.4.2.7 - Gliffy............................................................................................................................................................. 81 3.4.2.8 - Dropbox ....................................................................................................................................................... 81 3.4.2.9 - Skype ............................................................................................................................................................ 81 3.4.2.10 - Trello .......................................................................................................................................................... 81

DEL 4 – PROSESS ............................................................................................................................................. 82

4.1 - TOLKNING OG DEFINISJON AV OPPGAVEN ............................................................................................................ 83 4.1.1 - Førsteinntrykk og møte med oppdragsgiver ..................................................................................... 83 4.1.2 – Begrense og definere oppgaven ....................................................................................................... 83

4.1.2.1 Plattform og rammeverk ................................................................................................................................ 83 4.2 - KRAVSPESIFIKASJONEN .................................................................................................................................... 84

4.2.1 - Kravspesifikasjonens rolle ................................................................................................................. 84 4.2.1.1 - Under arkitektur og planlegging .................................................................................................................. 84 4.2.1.2 - Under Utviklingsfasen .................................................................................................................................. 84 4.2.1.3 - Under Dokumentasjonen ............................................................................................................................. 84

4.2.2 – Ble kravspesifikasjonens krav oppfylt? ............................................................................................. 84 4.3 - PLANLEGGING OG UTVIKLINGSMETODIKK ............................................................................................................ 85

4.3.1 - Samarbeid og kommunikasjon .......................................................................................................... 85 4.3.2 Valg av metodikk ................................................................................................................................. 85

4.3.2.1 - Smidig utvikling ............................................................................................................................................ 86 4.3.2.2 - XP ................................................................................................................................................................. 86

4.3.3 Prosjektstyring ..................................................................................................................................... 87 4.3.3.1 - Trello ............................................................................................................................................................ 87 4.3.3.2 - Arbeidsplan .................................................................................................................................................. 87 4.3.3.3 - Prosessnettside og dagbok .......................................................................................................................... 87 4.3.3.4 - Databasediagrammenes rolle i utviklingen .................................................................................................. 88

DEL 5 – AVSLUTNING ...................................................................................................................................... 89

5.1 – DET FERDIGE PRODUKTET ................................................................................................................................ 90 5.1.1 – Videre utvikling ................................................................................................................................. 90 5.1.2 – Produktets verdi ................................................................................................................................ 90

5.1.2.1 – Verdi for oppdragsgiver .............................................................................................................................. 90 5.1.2.1 – Verdi for brukerne....................................................................................................................................... 91

5.2 – ORD FRA OPPSRAGSGIVER ............................................................................................................................... 91 5.3 – LÆRINGSUTBYTTE .......................................................................................................................................... 91 5.4 – KONKLUSJON ................................................................................................................................................ 92

ORDLISTE ....................................................................................................................................................... 93

KILDER ............................................................................................................................................................ 99

VEDLEGG ...................................................................................................................................................... 100

Kost 2014 Presentasjon

6

Del 1 – Presentasjon _________________________________________________________________________________

Denne delen er en oppsummering og introduksjon til dette prosjektet. Her presenterer vi oss som

gruppe, oppgaven vi har valgt og hva denne går ut på, samt et kort overblikk over sluttproduktet. Hensikten med denne delen er å gi leseren et grunnlag for å kunne forstå de påfølgende delene av rapporten og å sette oppgaven i kontekst. _________________________________________________________________________________

Kost 2014 Presentasjon

7

1.1 - Om gruppen

Vi er to studenter fra ingeniørfag data som har kjent hverandre i mange år og jobbet sammen på en rekke prosjekter helt fra tidlig ungdomsskole til nå. Fordi gruppedynamikken dermed er godt innarbeidet var det et naturlig valg for oss å samarbeide på denne bacheloroppgaven, da det er spesielt viktig at ambisjoner og forventningen til arbeidsmengde er i samsvar. Vi har i alle år vært over middels interessert i data og det som hører til, og det var derfor kort vei fra den iboende interessen til en utdannelse innen IT ved HIOA. Etter å ha jobbet med flere aspekter i og rundt IT har vi tilegnet oss ferdigheter innen flere programmeringsspråk, metodikker og rammeverk. Når vi nå har nådd tredje året av utdannelsen har vi funnet noen favorittspråk og plattformer, og for oss er dette helt klart Java, C# .net og Windows. Derfor passet det utmerket når vi fikk muligheten til å jobbe med denne oppgaven som involverer Android-programmering i Java og server API programmering i C# .net.

1.2 - Oppgaven

Oppgaven gikk ut på å utvikle en IT-løsning for innrapportering av data for bruk i forskning ved Instituttet HEL. Denne består av en Android applikasjon, hvor brukere kan registrere kostholdsvaner basert på Mattilsynets matvaretabell, og et API med tilhørende web-grensesnitt, for registrering av matkonsum og uthenting av statistiske rådata. Systemet skal forenkle forskningsprosessen for forskere i ernæringsmiljøet ved HEL, samt at den skal appellere til vanlige brukere og promotere kostholdsbevissthet. Denne oppgaven var i utgangspunktet beregnet på flere grupper. Hvis man tar en kikk på den originale oppgaveteksten i Vedlegg F kan man se hvorfor. Ikke bare var det tiltenkt å lage API, nettside og app, men også en brukernettside med egne profiler, integrasjon mot sosiale nettverk og brukerinteraksjon i form av chatting og forum. Når vi begrenset oppgaven ned til teksten i avsnittet over var vi innforstått med at dette fortsatt ville bli en enorm utfordring for en gruppe på bare to medlemmer. Det å lage et helt system med API, nettside og app ble noe av det vanskeligste og mest tidkrevende vi har gjort i vår skolegang, men det har også vært det mest lærerike og givende.

1.2.1 - Oppdragsgiver

HIOA Institutt for helse, ernæring og ledelse (HEL) holder til på studiested Kjeller og har om lag 85 ansatte og 1060 studenter tilknyttet instituttets virksomhet. Vår oppgave er forespurt av studieleder ved Samfunnsernæring Asgeir Brevik. For å ha høy kvalitet på undervisningen fokuserer undervisningspersonalet på å holde seg oppdatert innenfor forskning og fagutvikling. Fagmiljøet ved instituttet HEL er aktive innenfor ulike flerfaglige forskningsaktiviteter, og forskningen har et helsefremmende og forebyggende perspektiv. Tilsatte ved instituttet deltar i følgende forskningsgrupper ved Fakultet for helsefag: • Empowerment

• Humane kostforsøk og helseeffekter

• Samfunnsernæring

• Aldring, helse og velferd

Kost 2014 Presentasjon

8

1.2.2 - Bakgrunn

Institutt for Samfunnsernæring driver jevnlig med forskningsprosjekter i henhold til ernæring hvor innsamling av nok kostholdsdata ofte kan være en utfordring. Derfor har vår oppgave vært å utvikle et system som forenkler og automatiserer deler av denne prosessen. Ved å tilgjengeliggjøre vårt system for offentligheten og større brukermasser via de mest brukte moderne teknologiene, nemlig applikasjoner for mobil, i et intuitivt og brukervennlig format, vil dagens situasjon forenkles for medarbeiderne i forskningsprosjektene. Det er også et poeng at brukerne av appen selv vil få innsikt i deres eget kosthold og at dette systemet på den måten kan bidra til folkeopplysning i henhold til ernæring. For ytterligere informasjon om bakgrunnen for prosjektet er det naturlig å henvende seg til det som er skrevet av oppdragsgiver selv, da han er den som merker hvor skoen trykker. Vi har valgt en paragraf fra hans attest, Vedlegg E, som ytterligere illustrerer situasjonen i dag.

«Tungvinte datainnsamlingsmetoder og lite fokus på deltakeres bekvemmelighet preger kostholdsforskningen i dag, og er noe av grunnen til at forskningsprosjekter innen ernæring har problemer med å rekruttere travle moderne mennesker til deltakelse. Android-appen som er utviklet av Martin Witsø Løkkeberg og Jonas Moltzau, for a effektivt kunne samle inn kostdata i tilnærmet sanntid, vil kunne gjøre livet lettere og mer interessant, bade for deltakere og forskere i fremtidige forskningsprosjekt i Norge.»

- (Asgeir Brevik, 2014. Vedlegg E.)

1.2.3 – Mål

Denne oppgaven var i utgangspunktet ment å være kun et forskningsverktøy, men i samarbeid med oppdragsgiver valgte vi å utvide fokuset til å inkludere disse målene:

Bidra til enklere informasjonsinnsamling av ernæringsdata.

Å skape lettere tilgang til matvaretabellen. o API for programmerere o App for menigmann

Hjelpe brukere med å få oversikt over eget kosthold. o Brukervennlighet i fokus. o Motivere brukere til å bruke appen aktivt.

Promotere kostholdsbevissthet Med disse målene i tankene fikk vi et grunnlag for å utvikle et system som kunne være med på å påvirke menneskers hverdag samtidig som at vi bidrar til økt innsamling av forskningsdata, og ikke bare som et anonymt verktøy. Vi vil forklare dette nærmere i del 4 som tar for seg prosessen.

Kost 2014 Presentasjon

9

1.3 – Sluttprodukt

Som en introduksjon og overblikk over sluttproduktet er det naturlig å starte med et diagram som viser systemet i sin helhet.

Dette diagrammet er laget som en representasjon av de forskjellige delene av systemet og hvilke aktører de skal brukes av og interagere med. Backend-løsningen er representert nederst i diagrammet og har tittel Server. Denne delen består av et API og en administrasjonsside som begge bruker samme underliggende struktur og database. For å forstå inndelingen av de ulike delene av systemet er det viktig å vite hvordan matvarer er representert. Det finnes to typer matvarer, den ene typen er matvarer fra Mattilsynets Matvaretabell, disse finnes både lokalt i appen og sentralt på serveren og refereres til som matvarer. Den andre typen er matvarer som oppdragsgiver og hans studenter finner næringsinnholdet i og registrerer via administrasjonssiden, og som deretter synkroniseres til alle brukerne av appen, disse har vi valgt å kalle retter. I appen finnes det også en tredje type lokale matvarer som refereres til som måltider, disse er komponert av hver enkelt bruker bestående av retter og matvarer. Et annet viktig konsept er enheter. Disse er knyttet direkte til matvarene fra matvaretabellen og representerer naturlige enheter slik som skive, glass, stk. etc. Dette er nødvendig fordi matvarene kun er oppgitt i verdier per hundre gram, som er lite brukervennlig i hverdagssammenheng hvor man skal registrere hele sitt kosthold. Enheter kan derfor opprettes fortløpende av oppdragsgiver og vil etter hvert representere en betydelig del av det som skiller systemet fra konkurrentene.

Figur 1 - Oversiktsdiagram

Kost 2014 Presentasjon

10

1.3.1 - App

Android applikasjonen gir brukeren muligheten til å registrere sine kostholdsvaner i form av matvarer tatt fra matvaretabellen, retter som er komponert enten av brukeren selv (måltider) eller prekomponert av oppdragsgiver og studenter ved HEL (retter). Funksjonalitet for å organisere matvarer, retter og måltider er implementert på en måte som gjør systemet lett forståelig og brukervennlig. Brukeren har muligheten til å enkelt kunne søke etter valgt matvare, rett eller måltid for deretter å kunne registrere dette som spist for denne dagen. Når matvaren, retten eller måltidet er registrert kan brukeren følge sitt næringsinntak på hjemskjermen ved enkle figurer, og deretter gå mer i detalj via dagsoversikter. Applikasjonen sender registrert kostholdsdata til APIet daglig, der det lagres anonymisert.

1.3.2 – API og Administrasjonsside

APIet tilbyr matvaretabellen i et programmeringsvennlig rammeverk. Man kan hente ut ønsket informasjon om matvarer, retter, enheter og ernæringsvaner etter oppdragsgivers diskresjon. Tilgangen til APIet styres av oppdragsgiver via administrasjonssiden hvor han kan opprette og dele autorisasjons-koder (tokens). På administrasjonssiden har oppdragsgiver også mulighet til å legge inn retter og enheter og kan gi begrenset tilgang til sine studenter. Samme side brukes for å hente ut rådata om kostholdsvaner samlet inn fra app-brukere for videre statistisk bearbeidelse. Rådata suppleres i en brukervennlig kommaseparert liste som kan importeres direkte i bl.a. Excel.

Både app, administrassjonside og API vil bli gjennomgått i detalj i del 2 om produktet.

Figur 3 - Listen over matvarer på administrasjonssiden.

Figur 2 - Skjermskudd av visningssiden for en matvare i appen.

Kost 2014 Produkt

11

Del 2 – Produkt _________________________________________________________________________________

I dette avsnittet vil vi ta for oss selve produktet slik det er i skrivende stund. Vi vil først gå igjennom

applikasjonen. Denne vil vises skjermbilde for skjermbilde og hvor vi vil beskrive bildets funksjonalitet, baktanke og formål samt aktivitetens plass i applikasjonen. Det skal ikke legges skjul på at appen er den delen av systemet som har vært mest tidkrevende og som også er funksjons- og kompleksitetsmessig den mest avanserte delen. Dette anser vi for å være naturlig fordi appen er den delen av systemet som den generelle bruker blir eksponert for. Appen har høy fokus på enkel brukerinteraksjon, som er laget så sømløst som mulig for at brukeren skal ha en god opplevelse som fører til forlenget bruk. Vi har fokusert mye på at appen skal være intuitiv og nyttig for hvermannsen, slik at den ikke blir kun et innsamlingsverktøy for bruk i forskning, men også står på egne ben og har en nytteverdi for forbrukerne uavhengig av forskningsverdi. Appen er derfor laget med intensjonen om å gi brukere et ønske om å bruke den, dette er viktig fordi uten brukerdeltakelse vil resten av systemet ha meget begrenset verdi. På bakgrunn av dette vil appdelen være helt klart mest fremtredende, ikke bare her i produkt-delen, men også videre i rapporten. Vi skal derimot ikke glemme hverken administrasjonssiden eller APIet, og disse vil også bli beskrevet i henholdsvis avsnitt 2.2 og 2.3. Her vil vi ikke gå skjermbilde for skjermbilde slik som i applikasjonen, men vil gi leseren et overblikk over hvordan disse delene fungerer i skrivende stund, hvordan de interagerer med de andre delene av systemet og hvilken funksjonalitet og mulighet de gir oppdragsgiver i hans forskningsarbeid. I de siste delene i dette kapittelet kommer det et segment om programmets struktur og oppbyggning, dette er en høyst relevant del av produktdokumentasjonen, men tar utgangspunkt i en leser med større grad av IT teknisk bakgrunn enn de første segmentene. _________________________________________________________________________________

Kost 2014 Produkt

12

2.1 - Applikasjonen

Her vil vi presentere applikasjonen fra et brukerperspektiv med en forholdsvis enkel tilnærming. Det er meningen at selv en lite erfaren bruker skal kunne hente ut verdifull informasjon fra dette avsnittet og at det med mindre endringer skal kunne fungere som en slags brukerveiledning hvis oppdragsgiver får bruk for dette. Vi har derfor inkludert mange skjermbilder av aktivitetene og dialogene slik at leseren her skal få et inntrykk av appen. Har man muligheten ville vi selvfølgelig også anbefale å installere appen, som vil være tilgjengelig i Google Play Store mellom 27. mai og 10 juni. Målgruppen for denne delen av systemet vil være en størst mulig brukermasse av begge kjønn, og alle aldre, slik at mest mulig kostholdsstatistikk kan samles inn. Appen kan også brukes i målrettede studier, i form av spesifikke forskningsgrupper som får beskjed om å ta i bruk appen i hverdagen.

2.1.1 - Login

Først ut er login-skjermen. Her vil vi først beskrive aktiviteten, deretter dens rolle og funksjonalitet. Dette er en av de mindre aktivitetene i applikasjonen, men den har allikevel en rolle å spille, da spesielt for oppdragsgiver.

2.1.1.1 - Login-skjermen

Figur 4 - Login-skjermen og dialogen for å registrere bruker

Kost 2014 Produkt

13

Det første som møter en bruker når vedkommende åpner applikasjonen er login-skjermen. Dette er en standard login-skjerm som gir brukeren muligheten til å skrive inn sitt brukernavn og passord for å logge inn i appen. Hvis brukeren ikke har en brukerkonto kan man trykke på knappen «Ny bruker» og deretter registrere en ny konto ved å fylle inn feltene. Har brukeren allerede gjort dette kan man bare skrive inn brukernavn og passord og trykke på «Logg inn». Når man logger inn i appen forblir man innlogget helt til man manuelt logger ut igjen, uavhengig om man går ut av appen eller skrur av telefonen. For å kunne logge inn eller registrere ny bruker er man nødt til å ha en aktiv internett-tilkobling. Dette er fordi applikasjonen kontakter APIet for enten å lagre informasjon under registrering av en bruker, eller for å verifisere brukerens identitet når de logger inn.

Ny bruker dialogen Når man har trykket på «Ny bruker» knappen får man opp dialogen man kan se til høyre i figur 4. Her blir brukeren bedt om å fylle inn informasjon om seg selv slik at de kan registrere en bruker og starte appen. All informasjon brukeren skriver inn her holdes anonymt og brukes for å beregne anbefalt daglig inntak for brukeren via «Harris Benedikt likningen», samt til statistisk grupperingsdata for oppdragsgiver i hans forskning. I denne dialogen kan man også lese EULA (End User License Agreement) ved å trykke på «EULA» knappen som vist nederst til høyre i figuren. Her presenteres bl.a. alle forbehold som tas fra oppdragsgivers side ved bruk av appen og hvilken lisens applikasjonen er lisensiert under (se Vedlegg G for EULA).

2.1.1.2 – Rolle og funksjonalitet

Brukerkontosystemets rolle Brukerkontosystemet i appen slik den er i dag er ikke en essensiell del av systemet. For brukere av appen vil det tilby lite funksjonalitet bortsett fra at de kan «låse» appen ved å logge ut slik at andre dermed må ha deres passord for å får tilgang til deres data. Dette er en brukbar mulighet for de som ikke vil at andre skal se deres opplysninger når de legger igjen telefonen eller liknende. For oppdragsgiver derimot er brukerkontosystemet viktig. Han kan for eksempel bruke dette til å hente data fra en bestemt bruker (anonymt med mindre brukeren gir eksplisitt godkjenning, omtalt i avsnitt 2.5), men kanskje det viktigste er at brukerne, under registrering, kan skrive inn et forsøksnummer slik at oppdragsgiver kan ha egne separate forsøk med en avgrenset målgruppe inne i systemet. Dette er en kraftfull funksjon som gir ham muligheten til å utføre flere studier samtidig med ett og samme verktøy, samtidig som han får muligheten til å samle data fra alle brukerne.

Funksjonalitet og utvidelser Fordi brukerkontosystemet ikke er essensielt for applikasjonens funksjonalitet har flere funksjoner blitt nedprioritert her. Dette innebefatter slikt som at brukerne ikke kan resette sitt eget passord. Når en bruker mister passordet sitt må vedkommende, som det står nederste til venstre i figur 1, rett og slett lage en ny konto. For brukerne selv vil ikke dette merkes på noen måte bortsett fra at de må oppgi et annet brukernavn og passord ved login. For oppdragsgiver derimot vil dette kunne by på små utfordirnger for hans forsøk, da med tenke på at noen brukere vil kunne ha flere kontoer. I mindre forsøk med forsøksnummer mener han at dette ikke vil være et stort problem da han kan få meldinger fra brukerne direkte om at de har mistet passordet og dermed være klar over dette. I oppdragsgivers forsøksprosjekter vil han da måtte assosiere to kontoer med de brukerne som evt. glemmer sitt passord. Utenfor hans forsøksprosjekter vil ikke dette ha noen store innvirkninger. Dette er fordi all data vil gå inn i samme «pool» og vil til slutt bli håndtert av samme statistiske algoritme uavhengig av brukernavn på grunn av den ekstensive mengden med data som vil genereres med selv et lavt antall brukere. I skrivende stund kan man logge inn med flere brukere på samme telefon, men det eneste som vil endre seg inne i applikasjonen når man gjør dette er brukerinnstillingene (se avsnitt 2.1.9 for mer informasjon om innstillinger). Hvilke oppdateringer man har lastet ned og måltider man har laget, vil

Kost 2014 Produkt

14

være felles for alle brukere som logger inn på telefonen. Vi valgte å nedprioritere total seperasjon av brukere på samme telefon da vi anså det for å være lite sannsynlig at denne funksjonaliteten vil brukes hyppig. Vi tok derimot noen grep for å tilrettelegge for at funksjonaliteten kan implementeres i ettertid. Ett slikt tiltak er seperasjon av brukerprofiler ved at hver bruker har en separat brukerprofil lagret i telefonen. Dermed kan man senere opprette en ny database per bruker, og ikke én per telefon slik som i dag, og på den måten sikre at all informasjon forblir separert ved å lagre en bane til en egen database inne i hver brukerprofil. Brukerkontosystemet er laget slik at det kan utvides til å bruke en nettside for brukerne hvor de kan holde seg oppdatert på sitt kosthold og synkronisere sine data mellom flere plattformer og systemer. Vi laget denne funksjonaliteten slik at alle brukernavn er unike og all informasjon om brukeren holdes oppdatert på nett. Dermed kan brukerens konto brukes av alle systemer som har tilgang til APIet. Dette gir uendelige muligheter for nye utviklere som dermed kan bruke vårt system for brukerhåndtering til alle typer utvidelser.

2.1.2 – Hjemskjermen

Her vil vi se på hjemskjermen og dens funksjonalitet og formål i applikasjonen. På denne skjermen har vi to viktige diagrammer som vi vil gå i dybden på og beskrive grundig for å vise hvordan denne skjermen på en rask måte kan forsyne brukeren med nyttig informasjon.

Figur 5 - Hjemskjermen og dens to diagrammer

Kost 2014 Produkt

15

2.1.2.1 - Anbefalt energifordeling og hjemskjermen generelt

Hjemskjermen er det første brukeren ser når de starter appen så lenge de er logget inn. Det er meningen at man her skal kunne få et raskt overblikk over dagens inntak av hovednæringsstoffer (fett, protein og karbohydrat), og at brukeren skal kunne holde seg oppdatert på sitt inntak og progresjon i løpet av dagen bare ved denne skjermen. Derfor laget vi to diagrammer som brukeren kan forholde seg til for å få denne informasjonen så raskt som mulig. Disse laget vi i tett samarbeid med oppdragsgiver da det krever høy domenekunnskap for å sette sammen disse på riktig måte. Ved oppstart av hjemskjermen er det diagrammet for Anbefalt energifordeling (se til venstre i figur 5) som møter brukeren. Dette diagrammet viser de tre hovednæringsstoffene fordelt i henhold til daglig anbefalt energiprosent. Som standard skal karbohydrat utgjøre 52,5% av daglig inntak, protein 15% og fett 32,5% (tallene er godkjent av oppdragsgiver, se Vedlegg D). Dette kan endres i innstillinger-skjermen som vi vil gå inn på senere i avsnitt 2.1.9.2. Diagrammet viser altså hovednæringsstoffene fordelt per energiprosent, men det viser også hvor mye brukeren har inntatt av dem. Dette gjøres ved at de tre delene av diagrammet fylles opp med en sterkere farge etter hvert som brukeren registrerer spiste matvarer og retter gjennom dagen. Når en del fylles helt opp av den sterkere fargen har man spist anbefalt mengde av det næringsstoffet. Vi implementerte ingen indikasjon på om brukeren har spist for mye av et næringsstoff, til dels fordi dette gjøres i «Spist» skjermen, som vi vil gå igjennom senere i avsnitt 2.1.5.1, men også fordi diagrammet da ville blitt vanskeligere å lese.

2.1.2.2 - Din energifordeling

Hvis brukeren «swiper» (drar fingeren over skjermen) mot venstre på hjem-skjermen får man opp det andre diagrammet som vi valgte å kalle Din energifordeling. Her er tanken at brukeren skal kunne se hvordan dagens inntak av hovednæringsstoffer er fordelt prosentvis. Hvis dette diagrammet likner, i fordeling, på det originale Anbefalt energifordeling - diagrammet, er brukerens inntak riktig fordelt etter anbefalingen eller evt. den verdien man selv har satt. Brukeren kan da først sjekke sin anbefalte fordeling og se hvor mye man «har igjen» av dagens inntak i Anbefalt energifordeling-diagrammet og deretter «swipe» for å se om dagens fordeling i Din energifordeling-diagrammet er riktig så langt i forhold til den satte/anbefalte fordelingen. Slik mener både vi og oppdragsgiver at hjemskjermen skal gi et raskt overblikk over dagens inntak.

2.1.2.3 - Vanskelighetsgrad

Vi må, som utviklere, si oss fornøyd med hjemskjermen. Den fungerer nesten helt optimalt i forhold til de visjonene vi hadde når vi skrev kravspesifikasjonen i samarbeid med oppdragsgiver. Minuset med konfigurasjonen av diagrammene slik de er i dag er at brukeren kanskje ikke umiddelbart forstår hvordan dette fungerer. Vi kunne derfor trengt en innføringsløsning integrert i appen som viste brukeren hvordan dette skal brukes ved første innlogging. Dette var også planen da vi pratet med oppdragsgiver, men dessverre er dette ekstremt dårlig tilrettelagt i Androids biblioteker og man er nødt til å lage slike innføringer på egen hånd helt fra bunnen av. På grunn av dette falt denne innføringsmuligheten utenfor rammene av oppgaven. Vi har derimot pratet med oppdragsgiver om å lage en innføringsfilm som kan legges ut på nettsiden, og i tillegg publisere deler av denne dokumentasjonen slik at brukere kan få en rask gjennomgang av de mer kompliserte funksjonene.

Kost 2014 Produkt

16

2.1.3 - Utforsk

Her vil vi gå igjennom utforsk-skjermen og dens rolle i applikasjonen. Vi vil bruke tabeller og skjermskudd mer her enn hos de andre aktivitetene fordi utforsk først og fremst er en visuell representasjon av applikasjonens database. For å lese mer om databasestrukturen se avsnitt 2.4.1.

2.1.3.1 - Beskrivelse

Utforsk-skjermen er stedet hvor brukeren kan navigere seg gjennom alle matvarer, retter, måltider og oppskrifter i applikasjonen. Før vi begynner på beskrivelsen av selve skjermen kan vi oppsummere hva de forskjellige kategorien er helt spesifikt:

(Tabell følger på neste side)

Figur 6 - Utforsk skjermen før og etter et trykk på «Matvarer» kategorien

Kost 2014 Produkt

17

Beskrivelse

Matvarer Alle matvarer i matvaretabellen som er inneholdt i appen, samt enheter som er hentet fra APIet som tilhører hver matvare.

Retter Alle matvarer og retter som oppdragsgiver registrer i hans administrasjonsløsning. Disse kommer som oppdateringer til appen.

Mine måltider Dette er brukerens egenkomponerte måltider og retter, som kan inneholde matvarer fra både rett- og matvarekategoriene og faktisk også måltider.

Oppskrifter Samme som måltider, men en egen kategori for å enkelt kunne skille mellom de.

Tanken bak kategoriene, som før nevnt i presentasjonen, er enkel. Vi trengte rett og slett å skille mellom matvaretabellens matvarer, oppdragsgivers retter og de måltidene brukeren komponerer selv. Ser man i tabellen vil det samme sentimentet være uttrykt der. Det er mulig at dette vil forvirre brukeren i et tidlig stadiet av brukeropplevelsen, noe vi har prøvd å unngå ved å legge inn beskrivelser under hver kategori som man ser til venstre i figur 6. Utforsk-skjermen er enkel i bruk. Man trykker rett og slett på den kategorien man ønsker å utforske og får da opp neste steg i kategorihierarkiet. Retter og matvarer har underkategorier, slik at man kan utforske et ubegrenset antall steg innover i strukturen. Eksempelvis kan man først gå til matvarer, deretter melk og melkeprodukter, så til melk og melkebasert drikke, for å til slutt ende opp med Helmelk 3.5% fett. Måltider og oppskrifter derimot har ingen underkategorier da de er laget av brukeren, så her er det bare ett nivå.

2.1.3.2 – Skjermens rolle

Utforsk-skjermen er som sagt lagt inn i appen slik at brukeren kan få en oversikt over hva som finnes i databasen. Det er ikke så lett å skjønne hvordan ting er navngitt og hvilke produkter som er delt inn hvor, hvis man f.eks. bare skulle ha brukt søkefunksjonen. Søkefunksjonen, som vi vil omtale senere, er helt klart raskere enn å trykke seg gjennom kategorihierarkiet på leting etter matvarer, men ville aldri ha gitt brukeren den samme oversikten. Derfor mener vi at utforsk-skjermen er essensiell for appens synergi og for å gi brukeren oversikt over innholdet i applikasjonen på en forståelig måte.

2.1.3.3 – Spesifikt for måltider

I utforsk-skjermen for måltider og oppskrifter kan man slette oppføringer i listen ved å holde inne på dem. De vil da endre ikon til et stopp skilt (se figur 7). Trykker man så på dette ikonet vil matvaren slettes fra listen. Denne måten å slette objekter på er forholdsvis vanlig i touch-applikasjoner fordi den gir et ekstra lag med sikring før sletting i likhet med en advarselsdialog. I tillegg tar selve funkjsonaliteten lite plass inne i applikasjonen. Skulle man f.eks. hatt en knapp eller et ikon for sletting, ville dette gjort skjermen mer rotete og kanskje vanskeligere å finne frem i.

Figur 7 - Måltidets oppføring endrer ikon når man holder inne på det

Kost 2014 Produkt

18

2.1.4 – Vis-skjermen

Vis-skjermen er stedet hvor brukeren kan se all relevant informasjon om en matvare, en rett eller et måltid. Den varierer i utseende i henhold til hvilken hovedkategori man har valgt slik man kan se i figur 8. Derfor vil vi beskrive disse først ved å se på det som er felles for alle tre, for deretter å se på det som er unikt per skjerm.

2.1.4.1 – Felles for alle vis-skjermene

Titler og knapper Disse tre skjermene er alle basert på samme aktivitet, to av dem har til og med samme superklasse (se avsnitt 2.4.4 for mer informasjon om appstrukturen). Dette betyr at det er mange likhetstrekk mellom dem. Vi kan starte på toppen og se at alle har en overskrift og en undertittel. Disse brukes forholdsvis likt for retter og matvarer, hvor overskriften er tittelen på matvaren og undertittelen er kategorien, for måltider derimot er det en subtil ulikhet i form av at den bruker undertittelen for å vise porsjonsstørrelsen til måltidet. Hvis man er ekstra observant kan man også se at denne opplysningen også finnes for retter men her er denne skrevet inn i beskrivelsen til høyre (se på midterste bilde i figur 8). Spis knappen er neste fremtredende element. Denne knappen registrerer matvaren, retten eller måltidet brukeren har gått inn på som spist. Det betyr at denne blir lagt inn i listen over spiste matvarer i spist aktiviteten, som vi vil gå igjennom i avsnitt 2.1.6. Ved siden av spis knappen finner vi Legg til i Måltid knappen. Denne knappen legger matvaren, retten eller måltidet til i Lag Måltid aktiviteten som vi vil gå igjennom i avsnitt 2.1.7. På bildet til høyre i figur 8 ser denne knappen litt merkelig ut, men det er bare fordi emulatoren for pc gjør skriften unaturlig stor. Selv på små mobiler vil det ikke se slik ut.

Figur 8 – Vis-skjermene for henholdsvis matvarer, retter og måltider

Kost 2014 Produkt

19

Listen over næringsstoffer Den siste og kanskje mest fremtredende likheten mellom alle tre skjermene er listen over næringsstoffene matvaren, retten eller måltidet inneholder. Denne finner man nederst på skjermen med en «Vis alle» knapp under seg. Som standard vil man bare se de næringsstoffene man kan se nederst til venstre i figur 8. Dette er de mest vanlige næringsstoffene i dagligtale og erderfor valgt som standard. Man kan endre dette i innstillinger-skjermen som gås igjennom i avsnitt 2.1.9. Som nevnt finnes det også en «Vis alle» knapp som brukeren kan trykke på for å ekspandere listen til å vise alle næringsstoffene. Hvis brukeren forsøker å «swipe» nedover i aktiviteten ekspanderer listen automatisk. Noe som også er verdt å nevne her er at hvis man endrer hvor mange gram av matvaren man ser på vil denne listen oppdateres automatisk.

2.1.4.2 – Unikt for matvarer kategorien

Enheter Matvarer-kategoriens vis-skjerm har bare én funksjon som er unik. Dette er enheter. Enheter er, som man ser av figur 8, en mer lettleselig måte å representere gramverdier på i form av naturlige enehter. I vår figur er det ett glass melk som er vist frem. Gramverdien for denne enheten er satt til 250 gram som man kan se til høyre for navnet. Trykker man på selve navnet kan man velge mellom alle enhetene på denne matvaren. Disse lages av oppdragsgiver i hans administrasjonsside (for å se hvordan, gå til avsnitt 2.2.1.2). Noen eksempler på andre enheter som kan brukes på helmelk er: liter, desiliter, lite glass, etc.

Hvorfor enheter? Denne funksjonaliteten er noe av det som gjør applikasjonen vi har laget unik. Det finnes så å si ingen andre apper hvor man kan bruke naturlige enheter for kostholdsregistrering på markedet, og i hvert fall ingen med den norske matvaretabellen i bunn. Hvis oppdragsgiver legger inn enheter på de fleste basismatvarene i matvaretabellen er dette den funksjonaliteten som vil gjøre at vår app skiller seg ut mot konkurrentene i forhold brukervennlighet på markedet.

2.1.4.3– Unikt for retter kategorien

Beskrivelse I motsetning til matvarer, men i likhet med måltider, har retter en beskrivelse. Disse blir laget av oppdragsgiver i hans administrasjonsside og vises til brukerne i appen slik man kan se i midterste bilde på figur 8. Beskrivelsen er her tiltenkt som en mulighet for oppdragsgiver til å kommunisere «direkte» med brukerne av appen ved å kunne legge inn forbehold, spesifikasjoner eller oppskrifter på de rettene han legger inn via administrasjonssiden.

Porsjoner Istedenfor enheter har retter porsjoner. Grunnen til dette er at skopet for oppgaven ikke tillot oss å prioritere å legge inn enheter her også. Det er en tidkrevende og designmessig vanskelig oppgave som vi valgte å nedprioritere. Vi mener derimot at porsjoner er godt alternativ. Dette er simpelthen en multippel av porsjoner-feltet oppdragsgiver har tilgjengelig når han registrerer retter i administrasjonssiden. Har han f. eks. funnet ut hva 400 g spagetti bolognese inneholder, og dette regnes som én porsjon, kan han sette 400 g som porsjonsstørrelsen. Når brukeren da skal «spise» spagetti bolognese vil han kunne legge inn 1 porsjon = 400g, 2 porsjoner = 800g, osv. Dette vil gjøre registreringen raskere og mer brukervennlig for brukerne, noe vår brukertesting har vist og, vi antar, videre brukertesting kan bekrefte.

Kost 2014 Produkt

20

2.1.4.4 – Unikt for måltider og oppskrifter kategoriene

Innhold Innhold-knappens funksjonalite er forholdsvis enkel. Den viser rett og slett et lite vindu med hva måltidet inneholder som vist i figur 9. Man kan trykke på de ulike matvarene og vil deretter bli sendt direkte til visningsiden for den matvaren.

Porsjoner Porsjoner er implementert litt annerledes på måltider enn på retter. Her har vi en såkalt «slider» som brukeren kan bruke for å spise alt fra 0.1 porsjon til 10. Hvor mange porsjoner man har valgt blir dynamisk oppdatert i den grønne teksten over knapperaden.

Beskrivelse Denne beskrivelsen kan brukeren legge til når man oppretter måltidet eller oppskriften. Spesiellt i henhold til oppskrifter er dette viktig da den kan

inneholde instruksjoner for hvordan oppskriften skal lages, slik som steketid og temperatur. Man kan endre beskrivelsen på måltider og oppskrifter ved å holde inne på beskrivelsens tekst, eller evt. der den skulle ha vært, hvis man har opprettet uten beskrivelse.

Figur 9 - Innehold dialogen som viser en liste over innholdet i en måltid.

Figur 10 - Dialogen for endring av beskrivelse

Kost 2014 Produkt

21

Figur 11 - Søkefunksjonene med forslag til venstre og selve søkeskjermen til høyre.

2.1.5 - Søking

Søkefunksjonaliteten i applikasjonen er noe vi har viet mye tid til. Utviklingen av denne var spesielt kompleks og vi laget flere spesialtilpassede klasser og databasetabeller bare for å tilby raskere og bedre søk. Store deler av søkesidenes funksjonalitet vil derfor bli gjennomgått i detalj i utviklingsdelen punkt 3.2.2, og vi anbefaler sterkt å ta en titt på dette punktet. Vi kan allikevel tillatte oss en rask summering av de viktigste funksjonelle aspektene her.

2.1.5.1 - Kort om søk

Når man søker i vår app kan man gjøre det på to måter. Enten kan man søke via forslag, som er søkeordene som dukker opp når man skriver deler av ordet i søkefeltet som følger brukeren gjennom appen (vist til øverst til venstre i figur 11), eller man kan skrive deler av, eller hele ordet, og trykke «Utfør» på tastaturet. Uansett om man velger et forslag eller en søkestreng vil man sendes til selve søkesiden hvor ordets eller strengens resultater vil vises. Man kan søke på retter, måltider og matvarer og man kan søke på engelsk hvis telefonen har engelsk språk.

Kost 2014 Produkt

22

2.1.6 - Spist

Her vil vi gå igjennom spist-skjermen. Dette er kanskje en av de viktigste og mest avanserte skjermene i appen. Noe av kompleksiteten er beskrevet i utviklingsdelen avsnitt 3.2.1, hvor vi tar for oss kakediagrammene i detalj. I dette avsnittet vil vi se mer på skjermens funksjonalitet og rolle i appen og vi vil gå inn på noen av tankene bak funksjonaliteten og utfordringer vi hadde under implementasjonen.

2.1.6.1 - Historikk og navigasjon deretter

På spist-skjermen kan brukeren se hva man har spist og har her tilgang til hele inntakshistorikken som har blitt registrert i applikasjonen. Denne skjermen består i all hovedsak av en liste over inntak sortert per dag, som brukeren kan bla igjennom ved å bruke pilene ved siden av tittelen (se figur 12). Disse listene er primært sortert på dato i en 24-timers syklus. De tre første sidene derimot er laget mer leselige slik at brukeren raskere kan få et overblikk over det nyligste inntaket av næringsstoffer. Den første listen som møter brukeren er dagen i dag. Denne listen viser inntaket fra kl 05.00 samme dag til 04.00 neste dag. Hvis brukeren så trykker på pilen til venstre vil spist siste 24 timer dukke opp. Denne skjermen viser alt inntak fra det eksakte tidspunktet du åpner skjermen og 24 timer bakover i tid. Hvis brukeren så trykker tilbake en gang til vil man få opp en liste med tittel spist i går.

Figur 12 - Spist-skjermen for dagen i dag og for den 12.05

Kost 2014 Produkt

23

Denne listen viser gårsdagens inntak fra kl 05.00 til 04.00 kommende dag, i likhet med spist i dag. Flere trykk på pilen til venstre vil gi deg en skjerm som den til høyre i figur 12, altså en skjerm som inneholder inntaket fra kl 00.00 til 24.00 den datoen (her den 12.05).

2.1.6.2 - Selve listen

Listen som viser det man har spist er den viktigste delen av spist-skjermen. Her vil man få listet opp alle måltider, retter og matvarer man har inntatt i henhold til hvilken dato man har velgt. Matvarene vil være sortert etter tid spist med den eldste på toppen og de nyere i synkende rekkefølge under. Vi valgte å bytte ut datoen med i dag og i går der hvor det passer for høyere lesbarhet. Til høyre i listen finner man gramverdien for hver spiste matvare. Denne kan endres opptil 24 timer tilbake i tid. Grunnen for denne tidsbegrensningen er at applikasjonen vil sende inn alle registrerte matvarer, retter og måltider som statistikk når tilhørende postering er eldre enn 24 timer. Hvis brukeren kunne endre ting eldre enn 24 timer hadde statistikken blitt inkonsistent på serversiden. Minuset for brukeren oppstår hvis vedkommende legger inn feil verdier som man da ikke får endret, men vi mener det er lite sannsynlig at brukeren ikke vil oppdage dette innenfor 24-timers grensen. Måten man endrer gramverdien på er ved å trykke på matvarens oppføring i listen. Da dukker dialogen i figur 13 opp. Her bruker man «slideren» (den blå streken) eller «numberpickeren» (den vertikale rekken med tall) for å endre mengden. Man kan også trykke på selve tallet for å få opp tastaturet og dermed skrive inn ønsket mengde. Hvis man leter nederst i midten på dialogen ser man Gå til matvare knappen som vil sende brukeren rett til matvarens visningsside. For å slette elementer i listen kan man holde inne på elementets oppføring. Dette er den samme funksjonaliteten som brukes for måltider og oppskrifter som er forklart i avsnitt 2.1.3.3.

2.1.6.3 - Liste over næringsstoffer

Gjennom spist-skjermen har brukeren tilgang på informasjon om sitt næringsinntak. Dette går i all hovedsak ut på hvor mye av hvert næringsstoff man har fått i seg i forhold til referanseverdien. Hvis man ser nederst på figur 12 vil man se en liste over alle næringsstoffene. Denne likner i stor grad på listen beskrevet i punkt 2.1.4.1, men med én stor forskjell; nemlig at her vises også referanseverdien for alle næringsstoffene. Disse referanseverdiene er satt i forhold til algoritmene i Vedlegg D, som er såpass komplekse at de ikke vil gjennomgås her. Brukeren kan forholde seg til næringsstoffene og refreanseverdiene i listen ved å se på de sorte tallene til venstre for skråstreken hvor man ser hvor mye av det næringsstoffet man har inntatt, og deretter se til høyre for skråstreken, på de grå tallene, for å se hvor mye man skal innta av det næringsstoffet den dagen.

Figur 14 - Ikonet endres på oppføringer i listen når man holder inne på dem.

Figur 13 - Dialogen for å endre mengden av spist matvare

Kost 2014 Produkt

24

Figur 15 - Kakediagrammene på spist skjermen

Oransje tall Verdier i listen kan skifte farge til oransje. Dette betyr at en av matvarene man har spist har manglende informasjon på denne næringsverdien. Det er en forskjell i systemet på om et næringsstoff har tallet 0 som verdi eller har manglende verdi N/A (denne representeres som tallet -1). Hvis næringsstoffet har tallet 0 som verdi er det reelt sett 0 gram av det næringsstoffet i den aktuelle matvaren og bruker kan ta dette for god fisk. Er derimot verdien N/A eller tallene har blitt oransje betyr det at matvaren mangler informasjon om denne næringsverdien og at vi kan ikke garantere for mengden det tallet representerer.

2.1.6.4 - Kakediagrammenes funksjon og farge

Utviklingen av disse kakediagrammene er gjennomgått i detalj i avsnitt 3.2.1, derfor skal vi her kun se på funksjonen disse har for brukeren. Kakediagrammene er ment å være et enkelt visuelt hjelpemiddel slik at brukeren kan få et raskt overblikk over inntak i forhold til referanseverdi. Diagrammet viser rett og slett prosentvis inntak av næringsstoff i forhold til referanseverdien i henhold til den dagen du har bladd frem til. Denne prosenten er skrevet under diagrammet. Hvilke kakediagrammer og næringstoffer som vises kan brukeren selv velge og kan endres i innstillingene for brukeren beskrevet i avsnitt 2.1.9.2. Det mer oppsiktsvekkende aspektet ved disse diagrammene er fargen. Her har vi implementert et komplekst fargesystem som er grundig beskrevet i avsnitt 3.2.1.2. Kort fortalt vil dette systemet skifte farge på diagrammet avhengig av om brukeren har spist lite, mye eller passe i forhold til tiden på dagen. Grunnen til at vi valgte å implementere dette fargesystemet var at brukeren skulle kunne få en pekepinn på hvordan inntaket ligger an i forhold til tid. Hvis kokken er 22.00 og brukeren bare har spist 1000 av 2000 kcal vil diagrammet minne brukeren på at mengden han har spist er hittil er mindre enn forventet. Tanken her er at blir man minnet på hvilke mål man har satt, eller hva som er anbefalt inntak, kan man bli ledet til å tenke mer over hva man spiser og kanskje få et sunnere kosthold.

Kost 2014 Produkt

25

Figur 16 - Skjermene for opprett måltid og opprett oppskrift med 2 matvarer lagt til

2.1.7 - Nytt måltid

Her vil vi ta for oss skjermen for nytt måltid. Dette er aktiviteten hvor brukeren kan opprette nye måltider og oppskrifter, og er en av de fundamentale funkjsonene som gjør at vår app skiller seg ut fra andre liknende apper på markedet. Vi vil først se på hva man kan legge til i et måltid og hvordan disse er bygget opp, for så å ta en titt på selve funkjsonaliteten i skjermen.

2.1.7.1 - Hva kan man legge til?

Å opprette et måltid er en forholdsvis enkel idé; man kan ta en eller flere retter eller matvarer og kombinere dem slik at man raskere kan registrere matvarer og retter man regelmessig spiser sammen. Dette var det utgangspunktet vi hadde når vi laget kravspesifikasjonen og det er dette vi startet med å implementere. Vi støtte derimot på en utfordring i form av at brukeren kunne lage veldig enkle måltider som man kanskje ville kombinere med hverandre. Man kan f. eks. se for seg at en bruker legger inn et måltid kalt «Brød med ost». Dette er noe denne brukeren spiser ofte og det er naturlig å lage et måltid slik at registreringen kan gå fortere. Problemet oppstår når brukeren også drikker et glass melk til sin brødskive med ost. Skal man da måtte sette sammen hele måltidet på nytt, altså legge inn, ikke bare melk, men også brød og ost én gang til? Dette mente vi ville være alt for tungvint i henhold til rask registrering av inntak. Derfor modifiserte vi ideen bak nytt måltid til å inkludere, ikke bare retter og matvarer, men også andre måltider. Under vår nye tankegang kan man altså legge til, ikke bare retter og matvarer, men også andre måltider inn i måltider. Vår før så

Kost 2014 Produkt

26

Figur 17 - Dialogen for spis-knappen

uheldige bruker med sitt glass med melk og sitt måltid «Brød og ost» kan nå registrere glasset med melk ved siden av måltidet simpelthen ved å legge inn måltidet «Brød og ost» i et nytt måltid, for deretter å søke opp matvaren melk og legge denne til også. Når brukeren da skal registrere dette som spist inne i appen trenger han bare å trykke på spis knappen på det nye måltidet og ikke på alle de separate matvarene. For vårt lille eksempel med kun brød og melk vil nok ikke dette være spesielt tidsbesparende, men ser man på større måltider slik som en middag med f. eks. kjøttkaker, som fort kan inneholde mer enn 6 ingredienser, vil brukeren langt over halvere tiden det tar å registrere et slikt måltid. Denne tanken med å kunne legge måltider i måltider er derfor en av hjørnesteinen i applikasjonen vi har laget. Den gjør jobben med å registrere det man spiser mye raskere og mer intuitiv. Det er ingen hindringer for hva man kan legge inn i måltider og dette gir brukeren et mektig verktøy for rask registrering.

2.1.7.2 – Tittel og liste

Tittelen Det første man legger merke til i «nytt måltid» -skjermen er at man kan bruke tittelen som en nedtrekksliste. Trykker brukeren på denne listen kan man velge mellom å opprette et måltid, slik man ser til venstre i figur 16, eller en oppskrift, slik man ser til høyre.

Listen Under tittelen med nedtrekkslisten kommer listen over matvarene, rettene og måltidene lagt til på dette måltidet. Man kan bare opprette ett måltid av gangen og matvarene, rettene eller måltidene man legger til vil lagres selv om telefonen skrus av eller appen termineres. Denne listen fungerer helt likt listen i spist-skjermen forklart i punkt 2.1.6.2.

2.1.7.3 - Knapperaden

Knapperaden i denne aktiviteten er forholdsvis særegen og vi vil derfor gå igjennom knappene hver for seg med et bilde per dialog. Vi kan starte med spis-knappen.

Spis Spis-knappen er den knappen brukeren trykker på hvis de setter sammen et måltid, men ikke vil lagre det for fremtidig bruk, slik som brukeren i eksempelet over. Vi valgte å implementere denne knappen slik at det skulle være enda enklere å legge måltider inn i måltider og deretter registrere dem raskt. Når man trykker på spis knappen vil man få opp et dialogvindu som ber deg gi måltidet et navn. Dette er for å gjøre det enklere for brukeren å skjønne hva man har spist når man ser på historikken i spist-skjermen senere. Hvis alle måltider som ble spist på denne måten hadde fått intetsigende navn ville historikken blitt så å si uleselig på et senere tidpunkt. Dermed er dette et slags «redd brukerne fra dem selv» -tiltak. Man kan velge mellom flere forhåndsdefinerte navn (se figur 17) som sier noe om når på dagen og til hvilket måltid man spiser måltidet.

Kost 2014 Produkt

27

Figur 19 - Dialogen for å lagre et måltid

Fjern alle Fjern alle knappen er helt og holdent det den sier den er: en knapp som fjerner alle matvarer, retter og måltider fra listen for dette måltdet. Brukeren vil få opp en «er du sikker» dialog når de trykker på denne knappen.

Lagre Lagre-knappen er den helt klart viktigste knappen for denne skjermen. Det er med denne knappen brukerne kan lagre sine måltider og gjenbruke dem så mange ganger de vil. Når man trykker på denne knappen vil man komme til en dialog som spør brukeren om to ting. Det første er navnet man vil gi måltidet. Her er det ingen begrensninger fra applikasjonens side bortsett fra at det ikke kan være tomt, man kan også ha navn med spesialtegn, bare én bokstav eller tall. Vi så ingen vits i å begrense dette da brukeren selv er den som skal se og bruke måltidene og vil de gi disse et merkelig navn mener vi de burde få lov til det. Det andre dialogen spør om er hvor mange porsjoner man har registrert. For å foklare dette kan vi ta et eksempel: la oss si at du er hos bestemor og spiser en fantastisk sjokoladekake. Dette er en langpannekakeoppskrift som er angitt til 10 porsjoner. Når du spør om oppskriften blir det upraktisk å måtte dele denne på 10 bare for å kunne registrere den i appen. Derfor la vi inn porsjonsangivelse slik at du da kan registrere hele oppskriften til 10 porsjoner og bare velge at det du nå har registrert tilsvarer 10 porsjoner. Da vil appen automatisk omregne dine 10 porsjoner ned til 1 porsjon som du kan bruke for å registrere konsum, eller lage oppskriften i din egen størrelsesorden av senere.

Spesifikt for oppskrifter Hvis man ser nøye på figur 16 ser man at spis knappen har skiftet farge på skjermen til høyre. Dette er for at man ikke skal kunne spise oppskrifter direkte. Dette ikke er en logisk operasjon å kunne utføre fordi det du da gjør er å spise et måltid og ikke lage en oppskrift. Man kan derimot legge en oppskrift til i et måltid og spise den derfra eller lagre den som et nytt måltid som kan spises direkte.

Listen over næringsinnhold Denne er helt lik listene på spist- og vis-skjermen og er beskrevet i avsnitt 2.1.4.1.

Figur 18 - "Er du sikker?" -dialogen for fjern alle knappen

Kost 2014 Produkt

28

Figur 20 - Til venstre er tilbake-knappen og til høyre ser vi opp-knappen. Bildet er hentet fra android.com

2.1.8 – Navigasjon

Vi jobbet en del med å få navigasjonene i appen til å virke intuitiv. På alle Android telefoner har man i all hovedsak to navigasjonsmuligheter som består av en tilbake knapp og en opp knapp (se figur 17). Vanligvis vil tilbake knappen konfigureres av Android selv, men det skulle vise seg at noen av mekanismene i vår app krevde manuell innstilling av denne. Opp knappen må man som utvikler selv velge å slå på og konfigurere, noe vi gjorde for, så godt som, hele applikasjonen.

2.1.8.1 - Menylinje

Helt fra de tidligste skissene (se 3.1.2) hadde vi planlagt en menylinje som skulle følge brukeren gjennom hovedaktivitetene. Vi hadde egentlig tenkt til å lage denne selv, slik at vi kunne ha den på bunnen av skjermen, men under utviklingen fant vi ut at Android har lagt inn funksjonalitet og biblioteker for å utvide den allerede eksisterende menylinjen som er lokalisert på toppen av skjermen. Denne funksjonaliteten derimot var egentlig beregnet på fragments (se 2.4.4.1 for mer info om fragments), men med noen selvlagde justeringer fikk vi implementert den slik vi ville. Hvis man ser i figur 21 kan man se at menylinjen lar brukeren navigere til hjem-, utforsk-, spist- og måltidskjermen. Den skjermen man står i er merket med en oransje linje under navnet i menyen. Hvis man har en liten skjerm kan man fjerne denne menyen i instillinger-skjermen (se 2.1.9.2).

2.1.8.2 – Nedtrekksmenyen

Fordi menylinjen ikke har plass til alle aktivitetene brukeren vil navigere til, og fordi noen aktiviteter ikke er aktuelle for alle brukere, har appen en nedtrekksmeny i tillegg til menylinjen. Denne gir brukeren tilgang til innstillinger-skjermen, og det er her «om» -skjermen vil bli implementert før lansering. Nedtrekksmenyen er tiljengelig fra alle aktiviteter hvor det var mulig for oss å implementere den slik at brukeren kan navigere appen så raskt som mulig.

Figur 21 - Applikasjonens menylinje. Her navigert til Utforsk-skjermen

Figur 22 - Nedtrekksmenyen

Kost 2014 Produkt

29

Figur 23 - Innstillinger-skjermen. Første del til venstre andre del til høyre.

2.1.9 - Innstillinger

I dette avsnittet vil vi gå igjennom funksjonaliteten som tilbys av innstillinger-skjermen og hvilken rolle denne spiller for applikasjonen. En av kravene for Applikasjonen var at:

«Applikasjonen skal gi bruker muligheten til å konfigurere så mange innstillinger som mulig for å kunne skreddersy sin brukeropplevelse».

(Fra kravspesifikasjonen punkt 2.2.1 d)

På bakgrunn av dette kravet visste vi hele tiden at det skulle legges ned en del arbeid i innstillinger. Å gjøre dette var viktig for oss fordi mange applikasjoner på dagens marked låser brukeren til ett spesifikt brukermønster som ikke alltid er i tråd med brukerens egne ønsker. En slik begrensning og spesialisering av brukermønsteret var ikke noe vi ønsket å implementere i vårt system til større grad enn nødvendig. Vi vil gå igjennom innstillings-skjermen kategori for kategori og presentere funksjonaliteten den tilbyr. Noen kategorier vil beskrives i større detalj enn andre basert på arbeidsmengde og kompleksitet.

Kost 2014 Produkt

30

2.1.9.1 – Nettverk og oppdateringer

Under kategorien nettverk og innstillinger finner man konfigurasjonsmuligheter i forhold til nettverkstilganger og oppdateringer.

3G Rapportering At brukeren kan velge hvilke funksjoner man vil bruke via 3G har vært en kjernesak for oss som utviklere. Det er ikke alle situasjoner hvor dette passer like godt, men der hvor det lot seg gjøre lar vi brukeren få velge dette selv. Bakgrunnen for å gi brukerne denne muligheten er simpelthen å ikke påføre vedkommende uforutsette kostnader hvis de har dyre eller små abonnementer. Det første stedet man kan velge om man vil bruke 3G er for å sende rapporter til databasen (se øverst til venstre i figur 23). Dette er en innstilling som teoretisk sett kan gjøre at applikasjonen ikke sender inn rapporter til APIet. Noen brukere har kanskje ikke internett eller bruker bare 3G og selv om denne innstillingen er satt på som standard kan de skru den av og dermed unngå å sende rapporter. Vi vurderte det slik derimot at brukerens valg om bruk av deres 3G-kvote var viktigere enn å sende 100% regelmessig statistikk til server. Samtidig har nesten alle i vår tid telefonen koblet til en eller annen form for trådløst internett regelmessig. Et annet sted man kan velge om man vil bruke 3G er under oppdateringer. Dette er ikke satt på som standard og er noe brukeren må skru på selv om de ønsker det. Applikasjonen vil derimot sjekke om oppdateringer er nødvendig regelmessig og gi brukeren en liten melding hvis man bør oppdatere. Denne sjekken gjøres uavhengig av om brukeren har 3G eller trådløst internett fordi den krever ekstremt lite dataoverføringsmengde.

Oppdateringer Oppdateringsfunksjonaliteten blir gjennomgått i detalj under avsnitt 3.2.3.

2.1.9.2 – Generelle innstillinger

Under kategorien generelt finner vi innstillingene som går på selve applikasjonens bruksmønster. Her finnes konfigurasjonsmuligheter for visning av næringsstoffer, endring av referanseverdier og visning av menyer.

Topp-navigasjonsmeny Denne innstillingen gir brukeren muligheten til å slå av og på topp-navigasjonsmenyen i appen. Vi laget denne innstillingen mest for de brukerne med små telefoner slik at ikke halve skjermen spises opp av menyen.

Ekspander næringsstoffer Denne innstillingen gir brukerne muligheten til å ekspandere alle listene over næringsstoffer i appen. Dette betyr at man ikke trenger å trykke på «Vis alle» knappen for å få se hele listen over næringsstoffer når man f. eks. ser på en matvare eller i spist-skjermen.

Kost 2014 Produkt

31

Figur 24 - Dialogen for valg av standard næringsverdier.

Figur 25 - Undermenyen for referanseverdi innstillingen

Standard næringsverdier Denne innstillingen gir brukerne muligheten til å endre hvilke næringsstoffer som vises som standard i appen. Dette påvirker hvilke kakediagrammer man ser i spist-skjermen og hvilke næringsstoffer som dukker opp i listen over næringsstoffer der den er implementert. Hvis man ser på figur 24 kan man se hvordan dialogen som gir deg disse valgene ser ut.

Referanseverdier Dette er den innstillingen det gikk mest arbeid ned i av alle innstillingene, kanskje til og med mer enn alle de andre til sammen. Grunnen for denne prioriteringen var at denne innstillingen alene gjør applikasjonen et stort hakk mer kraftfull. Her gir vi nemlig brukeren muligheten til å overstyre appens valgte referanseverdier. Hvis brukeren tar i bruk applikasjonen uten å skru på denne funksjonaliteten vil appen regne ut brukerens anbefalte daglige inntak basert på Harris-Benedict likningen og Helsedirektoratets anbefalinger (se for mer informasjon se Vedlegg D). Ved å gi brukeren muligheten til å endre dette kan appen brukes for alle kosthold og dietter. Man kan velge å gå fra 2500 kcal om dagen til 1500 hvis man mener det er fornuftig, eller man kan bruke appen mens man går på lavkarbo-dietter og liknende. Ser man på figur 25 kan man se undermenyen for innstillingen av referanseverdier. Det første man legger merke til er at man kan skru denne funksjonaliteten av og på med brytere. Når man starter appen for første gang vil man komme inn i denne skjermen og se at alt er grået ut bortsett fra den øverste innstillingen kalt «Egendefinert kcal». Trykker brukeren på denne vil man slå på funksjonaliteten som gir muligheten til å sette sitt eget referanseinntak av kcal. Dette betyr at brukeren kan endre referanseinntaket av kcal fra det appen har regnet ut automatisk, til en selvvalgt verdi. Det som ikke vil endre seg med denne innstillingen er fordelingen av karbohydrater, protein og fett (heretter hovednæringsstoffene) som står for 95% av det daglige kcal inntaket. Dette vil fortsatt regnes ut etter Helsedirektoratets anbefaling.

Kost 2014 Produkt

32

Figur 27 - Dialogboksen for å endre aktivitetsnivå.

Figur 26 - Dialogen for å endre verdiene for protein, fett og karbohydrat.

Figur 28 - Varseldialogen for utlogging

Hvis man i tillegg slår på «Selvvalgt Energifordeling» vil man ikke bare kunne sette daglig inntak av kcal men også energidistribusjonen over hovednæringsstoffene. Dette kan man gjøre ved å trykke på innstillingen «Sett protein, fett og karbo». Da vil man få opp dialogen i figur 26. Her kan vi se at brukeren blir presentert for tre rekker med tallverdier som representerer hovednæringsstoffenes verdi innenfor daglig inntak av kcal. Når brukeren endrer på en av disse rekkene vil samlet inntak av kcal, som står over rekkene, endre seg proporsjonalt.

2.1.9.3 - Bruker

I denne innstillingskategorien kan brukeren endre opplysninger om seg selv. Når man registrerer en bruker må man skrive inn sin alder, høyde, vekt, aktivitetsnivå og kjønn. Av disse fem er det høyde, vekt og aktivitetsnivå som kan endres senere. Vi gjorde det slik fordi det er lite sannsynlig at man endrer kjønn eller fødselsår, og hvis man skriver feil her så kan man evt. lage en ny bruker. Høyde var et usikkerhetsmoment fordi det å endre høyde gir muligheten for at barn kan bruke programmet etter hvert som de vokser og ikkebare rette opp feil hos voksne. Vi ville ikke utelate muligheten for at noen voksne kanskje vil bruke appen for sine barn eller at ungdommer i tenårene vil bruke den og vi la derfor til denne endringsmuligheten. Det er derimot ikke meningen at mennesker under 18 år skal bruke applikasjonen og den er ikke beregnet på denne målgruppen, vi som utviklere ser derimot ikke noe hinder for at de som endrer høyde kan bruke appen hvis de vil. Man endrer høyde, vekt eller aktivitetsnivå ved å bruke helt standard dialogbokser for dette. I figur 27 kan man se aktivitetsnivå boksen.

2.1.9.4 - Logg ut

Det er ikke så mye å si om logg ut funksjonen. Den gjør som den sier og logger brukeren ut. Det litt spesielle her er at man ikke kan logge inn igjen uten en aktiv internettilkobling. Derfor får brukeren en advarsel før man logger ut om at man ikke kommer inn igjen med mindre man har 3G eller trådløst tilgjengelig.

Kost 2014 Produkt

33

2.2 Nettside

Denne delen av produktoversikten vil ta for seg nettsiden som er utviklet som en del av løsningen til oppdragsgiver. Nettsiden har to sentrale oppgaver, det primære formålet er å fungere som et administrasjonspanel for hele løsningen, det andre formålet er å gi et overblikk over de ulike API kallene som er tilgjengelig i form av ulike hjelpesider som gir informasjon om hvilke adresser forespørslene skal sendes til og hvilket format som kan forventes i retur. Når det i administrasjonsdelen refereres til bruker vil det si oppdragsgiver eller eventuellt andre i forbindelse med hans forskning. Bruk av APIets hjelpesider er ment for videre uviklere av f.eks en iOS app og andre aktører oppdragsgiver ønsker å gi tilgang til matvaredatabasen og data fra hans forskning.

2.2.0.1 Generelt

Nettsiden, per i dag, er kun aktuell for oppdragsgiver og, i mindre grad, eventuelle tredjepartsaktører som ønsker å benytte seg av APIet, og bærer derfor preg av et simplistisk funksjonelt design med fokus oversiktlighet og ryddighet. Den er av samme grunn ikke optimalisert for mobile plattformer, men er beregnet på å primært brukes fra en PC. Siden fungerer i alle de større nettleserne, men er optimalisert for nettleseren Chrome. Nettsiden finnes under domene http://kostregistrering.net og hostes hos godaddy.com, men kan i praksis hostes på en hvilken som helst nyere Windows Server med støtte for Microsoft IIS.

2.2.0.2 Forside

Den første siden man møter når man besøker nettsiden er en beskjeden velkomstside hvor det vises en tekst som er forhåndsbestemt av oppdragsgiver. Denne siden gir besøkende mulighet til å logge inn til administrasjonsdelen av siden eller se igjennom APIets hjelpesider.

Figur 29 - Sidekart over administrasjonssiden

Figur 30 - Skjermskudd av forsiden

Kost 2014 Produkt

34

2.2.0.3 API Hjelpesider

Hjelpesidene til APIet er tilgjengelig for alle som besøker siden, uten krav om noen form for innlogging el.l. slik at utenforstående aktører lett kan se igjennom hva som potensielt er tilgjengelig av data før de tar kontakt med oppdragsgiver for å be om tilgang til selve APIet. Hjelpesidene kan åpnes fra hvilket som helst sted på nettsiden ved hjelp av menylinken øverst på siden som dirigerer bruker til http://kostregistrering.net/Help, som viser en liste over de ulike ressursene tilgjengelig i APIet. Trykker man på en av ressursene som er listet opp kommer man til en side lagt opp som på Figur 31, som viser formen den gitte resurssen kan hentes ut på.

Figur 31 - Skjermskudd av API hjelpesiden

Kost 2014 Produkt

35

Figur 33 - Navigeringsmeny

2.2.0.4 Innlogging

“Login” -linken tar deg til en side hvor man kan logge inn for å bruke den administrative delen av nettsiden. Det er ikke laget funksjonalitet for å opprette brukere da det kun er oppdragsgiver som skal ha tilgang, isteden er det opprettet noen prekonfigurerte brukere. Av brukerne som finnes har én full tilgang til alt av funksjonalitet og resten har begrenset tilgang. Tanken bak dette er at oppdragsgiver skal kunne gi brukere til sine studenter som da kan få i oppgave å legge inn nye matvarer, retter og enheter i databasen. Det er ikke lagt inn noen begrensninger for en eventuell senere implementasjon av et mer avansert brukerhåndteringssystem.

2.2.1 Administrasjonsfunksjonalitet

Følgende avsnitt omhandler den administrative delen av nettsiden og vil gå igjennom funksjonaliteten som er tilgjengelig etter en suksessfull innlogging. Siden har en enkel inndeling hvor alle undersider er direkte tilgjengelige fra en meny på venstre side, som kan sees på Figur 33 dette gjenspeiles også på sidekartet Figur 29. Elementene i navigeringsmenyen tilsvarer de ulike funksjonene som er tilgjengelig

2.2.1.1 Matvarer

Fordi store deler av løsningen baserer seg rundt matvaretabellen er denne også inkludert på nettsiden. Den vises som en liste, alfabetisk inndelt etter kategorier, hvor man ser navnet og IDen til matvaren samt den første enheten knyttet til denne. På toppen av siden har vi lagt inn en søkeboks med et enkelt sanntidssøk, søket er implementert i JavaScript og krever derfor ingen kommunikasjon tilbake til serveren, men filtrerer listen som allerede er lastet for å vise resultatet.

Figur 32 - Skjermskudd av innloggingssiden

Kost 2014 Produkt

36

Det finnes ingen funksjonalitet på nettsiden for å endre eller legge til matvarer, dette er for å sikre at matvarene i databasen er identiske med Mattilsynets matvarer, som kun oppdateres én gang i året.

Figur 34 - Skjermskudd av nettsidens matvareoversikt og enhettilknytning

Kost 2014 Produkt

37

2.2.1.2 Enheter

Som nevnt, i punkt 2.1.4.2 om appen, er et viktig aspekt for sluttbrukere muligheten til å kunne registrere matkonsum i form av naturlige enheter. Det fantes dessverre ingen systematisert oversikt eller database over slike enheter fra før så en slik database måtte bygges opp manuelt over tid. Vi har av den grunn tilrettelagt for at man kan huke av ulike matvarer på nettsiden og knytte disse opp mot enten en ny enhet eller en enhet man har opprettet tidligere (illustrert i Figur 34). I henhold til krav fra oppdragsgiver har vi laget enhetene slik at de er unikt identifisert ved både navn og vekt, slik at man kan ha flere enheter med samme navn men ulik vekt, eksempelvis en “skive” gulost som veier 10g og en “skive” brød som veier 70g. Under siden «Enheter» er alle opprettede enheter listet opp og bruker har mulighet til å endre navn og vekt på disse. Merker man av en enhet i listen hentes alle matvarene som er tilknyttet enheten via et Ajax-kall til serveren og vises i en liste som man kan se til høyre i figur 35. Her har man mulighet til å fjerne tilknytningen mellom enheten og dens respektive matvaren. Det er ikke lagt inn noen begrensning på hvor mange matvarer som kan være tilknyttet en enhet og vica versa.

2.2.1.3 Retter og kategorier

I motsetning til matvareadministreringen har man full kontroll på opprettelse, endring og kategorifordeling av retter på nettsiden. Dette er fordi retter eksklusivt skal opprettes og vedlikeholdes av oppdragsgiver, de skal kunne opprettes når som helst og kunne synkes til appen når de er klare. Denne funksjonaliteten er samlet under sidene “Retter” og “R-Kategorier”. “R-Kategorier” gir bruker muligheten til å opprette og endre navn på kategoriene, samt endre overkategori. På “Retter” -siden er alle opprettede kategorier og retter listet opp i en hierarkisk liste, her kan man trykke på en rett og endre denne, eller man kan opprette nye retter under en gitt kategori.

Figur 35 - Skjermskudd av nettsidens enhetsoversikt

Kost 2014 Produkt

38

Figur 36 - Skjermskudd av rettersiden

Noen av feltene ved opprettelse av en ny rett (se figur 36) er obligatoriske og blir bl.a. validert med JavaScript når bruker trykker «Opprett» eller «Endre». Hvis noen av næringsverdifeltene ikke blir fylt inn antas det at ingen informasjon om næringsverdien foreligger og det settes derfor inn “-1” i disse feltene. Det verdt å merke seg at det gjøres en distinksjon mellom “0” og “-1”, “0” betyr null innhold, mens “-1” betyr manglende verdi og vises som “N/A” i appen.

2.2.1.4 Versjonsnummer

Kort om versjonsnumrene Både backend-løsningen og appen opprettholder hver sin liste med versjonsnummer tilknyttet de ulike databasetabellene. På appen angir disse versjonsnumrene hvilken versjon av en gitt tabell som befinner seg på appen, og på serveren angir versjonsnumrene hvilken versjon som er den nåværende versjonen av databasetabellen. Når en ny enhet eller rett blir opprettet via nettsiden får denne det nåværende versjonsnummeret tilknyttet seg. I tillegg oppdateres versjonsnummeret til en enhet eller rett seg når denne blir oppdatert. Dette gjør det mulig for appen å kun hente nye og oppdaterte ressurser istedenfor å hente alle.

Kost 2014 Produkt

39

Versjonskontroll Et viktig aspekt ved administrasjonssiden er å kunne gjennomgå og kvalitetssikre retter og enheter før de synkroniseres til appen. Dette er implementert ved at appen, når den forespør serveren om nyeste versjon, får den nyeste versjonen minus én. På denne måten vil ikke nylig opprettede enheter eller retter bli synkronisert mot appen før versjonen på serveren har blitt økt.

En tabell over hvilke versjoner de ulike database-tabellene befinner seg på og hvilken versjon som blir returnert til appen vises på forsiden av administrasjonsdelen. Her kan man også velge å se igjennom hvilke enheter og retter som har blitt endret eller opprettet siden siste versjonsøkning og deretter øke versjonsnummeret om ønskelig.

Figur 37 - Skjermskudd av nettsidens versjonskontroll

Figur 38 - Skjermskudd av øk versjon side

Kost 2014 Produkt

40

2.2.1.5 Rådata

For at oppdragsgiver skal kunne få brukt den innrapportere dataen til sitt forskningsarbeid er han nødt til å få hentet den ut. Det er derfor laget en side hvor man som bruker kan fylle inn predefinerte filtre og deretter få eksportert en csv-fil med rådata som matcher de gitte kriteriene. Eksportering av rådata vil potensielt kunne ta lang tid grunnet store mengder innsendte rapporter kombinert med sammenslåing av data på tvers av databasetabeller, og derfor foregår dette i en egen tråd som skriver til fil i en egen mappe på serveren. Når en bruker så besøker «Rådata» -siden lister serveren opp alle filer i eksport-mappen som ikke har en fil-lås på seg, ergo ferdig eksporterte data.

Det er verdt å nevne at oppdragsgiver kun ønsket rådata, ingen statistikk, eller annen form for prosessert data, siden han bruker egne programmer til dette.

2.2.1.6 Tokens

I tillegg til all funksjonalitet direkte relatert til de ulike ressursene i databasen har nettsiden også funksjonalitet for å opprette tokens til APIet. Denne funksjonaliteten er nødvendig fordi det for å bruke APIet kreves et gyldig token med riktig tilgangsnivå. Tilgangene er som følger:

Tilgang Beskrivelse

3 – Lese alt fra matvaretabellen Lesetilgang til Matvarer 2 – Lese alt unntatt Rådata Lesetilgang til Matvarer, Enheter, Retter og

rettkategorier. 1 – Full lesetilgang Lesetilgang til hele APIet 0 – Full tilgang Lese/skrivetilgang til hele APIet

I tillegg til å sette tilgangsnivå har oppdragsgiver også anledning til å sette antall uker et token skal være gyldig, samt å slette tokens hvis det skulle være behov for å stenge tilgangen denne gir.

Figur 40 - Skjermskudd av nettsidens token-funksjonalitet

Figur 39 - Skjermskudd over rådataeksportering

Kost 2014 Produkt

41

2.3 API

APIet er en sentral del av systemet vi har utviklet og all kommunikasjon mellom backend-delen og appen foregår via APIet. APIet er RESTfult (mer om REST i utviklingsdel 2.4.5.2) og tilgjengeliggjør de ulike ressursene som brukes av både nettsiden og appen. De følgende avsnittene tar for seg hvilke ressurser som eksponeres av APIet samt en kort beskrivelse av disse og hvordan man får tilgang til og bruker APIet. Ser man på hele systemet vi har utviklet som en helhet kan det kanskje virke som at APIet kun har verdi som et kommunikasjonsgrensesnitt mellom app og server-databasen, men det er denne delen av systemet som gjør at all data som er samlet inn, og arbeid som er utført, kan komme flere enn bare oppdragsgiver til nytte. Med oppdragsgivers samtykke kan potensielt hele kostholdsforskningsmiljøet i norge og evt. andre aktører som jobber med kosthold hente ut matvarer, retter og statistisk data med noen få kodelinjer. All data fra APIet returneres i JSON-format, mer om dette formatet og hvorfor vi valgte det finnes i segmentet om programstruktur, avsnitt 2.4.2.

2.3.1 Ressurser

De følgende avsnittene tar for seg de ulike ressursene eller entitetene som er tilgjengelige via APIet og på hvilken form de kan hentes ut på.

2.3.1.1 Matvarer og Retter

APIet tilgjengeliggjør store deler av informasjonen som finnes i Mattilsynets matvaretabell, bl.a. en liste på ca. 1500 av de vanligste matvarene som spises i Norge med oversikt over deres innhold av energi og næringsstoffer per 100g. I tillegg til matvarene fra Mattilsynet tilgjengeliggjør APIet også matvarer og retter hvor næringsstoffene er utregnet av oppdragsgiver for å supplere matvarene fra matvaretabellen. (En nettutgave av matvaretabellen finnes på Mattilsynets sider http://matvaretabellen.no.)

Figur 41 - Matvare og rett JSON-objekt

Kost 2014 Produkt

42

Grunnen til at vi har valgt å tilgjengeliggjøre retter er fordi appen trenger å kunne synkronisere retter fortløpende uavhengig av oppdateringer av selve appen. Etterhvert som databasen over retter øker kan denne også være av interesse for andre aktører og i samarbeid med tokens-funksjonaliteten kan dette bli et kraftfullt verktøy oppdragsgiver kan bruke for å dele sin ernæringsinformasjon. Matvarer i motsetning til retter shippes med appen og oppdateres såpass sjelden at behovet for dynamisk synkronisering ikke er tilstede, vi valgte allikevel å gjøre disse tilgjengelig via APIet fordi andre aktører kan dra nytte av matvaretabellen i et programmeringsvennlig format. Som man ser av Figur 41 hentes både matvarer og retter ut i noenlunde likt format, de inneholder begge en oversikt over næringsstoffer samt felter som id, navn, etc. De har to forskjeller som er verdt å merke seg, når en matvare hentes ut inneholder den også en liste over enheter som passer til matvaren, eksempelvis enheten “stk.” på Figur 42. Den andre forskjellen er at matvarer hentes ut med kategorinavnet, mens retter hentes kun ut med IDen til sin kategori. Dette er gjort bevisst fordi matvarenes kategorier ikke er utsatt for endring, men det kan være tilfellet med rettenes kategorier siden disse kan oppdateres via nettsiden. Retter-kategoriene kan også av den grunn hentes ut med et eget API-kall.

2.3.1.2 Enheter

I tillegg til å hentes ut med matvarer kan enheter også hentes ut separat. De inneholder da en liste over matvare-IDer som viser hvilke matvarer som bruker den gitte enheten.

2.3.1.3 Rettkategorier

Rettkategorier kan hentes ut med informasjon om navn og hvilken overkategori den har. Figur 43 viser en kategori som er hentet ut som ikke har noen overkategori.

2.3.1.4 Andre

I tillegg til de ovennevnte ressursene eksponerer APIet også funksjonalitet for opprettelse og autentisering av brukere, dette er metoder som tar imot POST forespørsler med ny brukerdata eller med brukerakkreditiver. På neste side foreligger en komplett oversikt over alle de ulike API-kallene, tilde(~) representerer basisstien http://kostregistrering.net/api.

Figur 42 - Enhet JSON-objekt

Figur 43 - Kategori JSON-objekt

Kost 2014 Produkt

43

HTTP Handling Adresse Beskrivelse

MATVARER: GET ~/Food Returnerer alle matvarene i databasen GET ~/Food/{id} Returnerer matvare med gitt id GET ~/Food?$filter=somefield gt 5 Returnerer matvarer som matcher filter GET ~/Food/{version}/GetVersion Returnerer matvaretabellversjon POST ~/Food Lagrer mottatt matvarekonsum fra

appbruker i databasen RETTER: GET ~/Dish Returnerer alle rettene i databasen GET ~/Dish/{id} Returnerer rett med gitt id GET ~/Dish?$filter=somefield gt 5 Returnerer rett som matcher filter GET ~/Dish/{version}/GetVersion Returnerer rett-tabellversjon POST ~/Dish Lagrer mottatt rettkonsum fra appbruker i

databasen RETT-KATEGORIER: GET ~/DishCategory Returnerer alle rettkategoriene i databasen GET ~/DishCategory/{id} Returnerer rettkategori med gitt id GET ~/DishCategory?$filter=somefield gt 5 Returnerer rettkategori som matcher filter GET ~/DishCategory/{version}/GetVersion Returnerer rettkategori-tabellversjon ENHETER: GET ~/Unit Returnerer alle enheter i databasen GET ~/Unit/{id} Returnerer enhet med gitt id GET ~/Unit/{version}/GetVersion Returnerer enhetstabellversjon BRUKERE: POST ~/User Oppretter ny appbruker POST ~/User/{nr}/Authenticate Autentiserer appbruker

Som man kan se ut ifra tabellen har de ulike ressursene et kall som returnerer ressursens versjonsnummer, dette brukes i all hovedsak til synkronisering mot appen, et eksempel på hvordan dette gjøres finnes i Del 3 Utvikling avsnitt 3.2.3. Matvarer og Retter har også hver sine POST-metoder som brukes til å ta imot rapporter fra appen, som sier hva en bruker har spist av henholdsvis matvarer og retter siden forrige rapportering. Figur 44 viser hvordan et slikt objekt kan være bygd opp, her ser vi at høyde, vekt og aktivitetsnivå tas imot sammen med konsumerte matvarer, dette er nødvendig siden disse attributtene hele tiden kan endre seg og ikke er faste for brukeren.

Figur 44 - JSON rapport data

Kost 2014 Produkt

44

2.3.2 Tilgang og bruk

Dette avsnittet tar kortfattet for seg hvor man finner APIet og hvordan man kan benytte seg av det. APIet huses sammen med nettsiden og finnes på adressen http://kostregistrering.net/api, alle de ulike ressursene starter med denne adressen.

2.3.2.1 Autorisering

For å sikre mot uautorisert tilgang til APIet er det implementert funksjonalitet som krever at forespørsler mot APIet inkluderer et autoriseringstoken, dette skal befinne seg i «Authorization» -feltet i Http-forespørselens «Header». Tokenet skal prefikses med type autorisering. Per i dag brukes kun to typer; «app» som kun brukes internt i appen, og “basic” denne brukes for alle andre API-kall. Som nevnt i 2.2.1.6 om nettsiden har ethvert token et bestemt tilgangsnivå og gyldighetsperiode. En typisk forespørsel kan se slik ut: GET http://kostregistrering.net/api/Food/06529 HTTP/1.1

Authorization: basic YsCoLSU+kbD5pjW0onA+X1RJlvYJBCYDmusj8H0RbFE=

(Tokenet over gir full lesetilgang og kan brukes frem til 10.juli 2014)

2.3.2.2 Filtrering

Alle GET API-kallene som returnerer en liste av en ressurs, eksempelvis matvarer eller retter, støtter ODATA filtreringssyntaks, dvs. de støtter bruk av følgende kodeord:

$filter – Brukes til å begrense resultater etter visse kriterier.

$orderby – Brukes til å sortere resultatene

$skip – Brukes til å hoppe over n-antall resultater.

$top – Brukes til å hente de n-første resultatene. Eksempler på forespørsler:

Syntaks Resultat

~/Food?$filter=Kilocalories gt 90 Matvarer med kaloriinnhold over 90kcal ~/Food?$orderby=name_no Alle matvarer sortert etter navn ~/Food?$orderby=name_no&$top=10 De 10 første matvarene sortert etter navn ~/Food?$filter=categoryName_no eq ‘Kaker’ Matvarer i kategori “Kaker”. ~/Food?$filter=Fat lt 20&$orderby=Fat Matvarer med mindre enn 20g fett, sorter etter

fettinnhold.

2.3.2.3 Bruk

APIet setter ingen begrensning på hvordan det kalles, det er derimot ikke mulig å kalle det direkte fra nettleserens adressefelt fordi man er nødt til å sette autorisering på forespørselen. For å teste uthenting av ulike data kan man derimot bruke et nettlesertillegg som tillater å sette egne Headere. Figur 45 under viser hvordan man kan bruke nettleserutvidelsen «Advanced Rest Client» (gratis) til Chrome for å hente ut en matvare via APIet.

Figur 45 - API-kall eksempel

Kost 2014 Produkt

45

2.3.2.4 Responskoder

Hvis et API kall er vellykket vil serveren svare med en respons med statuskode 200 - “OK” og evt. en kropp i form av et JSON objekt/array hvis dette forventes. Hvis autorisering mangler eller angitt autoriseringstoken ikke gir tilstrekkelig tilgang svarer serveren med statuskode 401 – «Unauthorized». Serveren kan også svare med 400 – «Bad Request» hvis data som POSTes ikke er på korrekt format, 404 – «Not Found» hvis f.eks. ressurs med gitt id ikke finnes eller 500 – «Internal Error» hvis det av andre grunner ikke er en gyldig forespørsel.

2.4 Programstruktur

Får å gi en innsikt i hvordan API, Nettside og App fungerer, individuelt og samlet, vil vi her forsøke å gi et overblikk over strukturen til de mest relevante delene. Under utviklingen av systemet har vi hele tiden måttet ta stilling til, og måttet utvikle innenfor, en rekke ulike standarder, protokoller, rammeverk og arkitektoniske design-mønstre, mange av disse har vært med på å bestemme utformingen av prosjektet og vil av den grunn være inkludert her. Det er naturlig å dele inn i to hoveddeler henholdsvis Serverside og App. I de tilfellene hvor de samme strukturene er aktuelle i begge hoveddelene vil den enten beskrives separat eller der den er mest relevant.

Figur 46 - Helhetlig strukturdiagram

Kost 2014 Produkt

46

2.4.1 Databasedesign

Sentralt i utviklingen av prosjektet og i det ferdigstilte systemet står databasedesignet, og utviklingen av databasen, sentralt. Vi startet tidlig med å diskutere hvordan databasen skulle se ut, hvilke tabeller som måtte være med og hvilke data som skulle lagres. Spesielt diskuterte vi hvordan vi skulle representere matvaretabellen fordi den står sentralt både i appen og på serversiden. Vi innså tidlig at vi var nødt til å ha to ulike databaser, én på server og én i appen, slik at appen oppfylte kravspesifikasjonens krav om å fungere uten en aktiv internett tilkobling. Begge databasene inneholder informasjon om matvarer, retter og enheter, men forskjellen ligger i at appens database må holde oversikt over hvilke måltider en bruker har opprettet og hvilke matvarer, retter og måltider som har blitt spist sammen. I kontrast trenger serverdatabasen en liste over registrerte appbrukere, innsendte data fra app og tilgangstokens for bruk av APIet. For å lettere forstå strukturen og oppbyggingen av databasen bryter vi her opp databasen i deler og går igjennom delene hver for seg.

2.4.1.1 - Matvarer og Enheter: App og Server

I Matvaretilsynets liste har hver matvare en oversikt over innhold av 38 ulike næringsstoffer, et navn og en unik id. Matvarene er delt inn i en rekke ulike kategorier som igjen har overkategorier og strukturen er slik at en kategori kun kan ha underkategorier eller matvarer. Kategoriens unike id gir informasjon om hvilken, om noen, overkategori den har. Eksempelvis indikerer ID 1.4.1, at kategorien har overkategori 1.4 som igjen har overkategori 1. All denne informasjonen ville vi ivareta i vår database og valgte derfor å bruke den samme strukturen og de samme IDene på både matvarer og kategorier, med noen små endringer, n-te nivå kategorier fikk alltid n*2 siffer i ID og punktum ble fjernet, ergo 1.4.1 ble 010401. I tillegg til matvarer og kategorier skulle det være mulig å knytte en enhet opp mot flere matvarer, slik at man fikk en mange-til-mange relasjon mellom enheter og matvarer. Dette førte til følgende entiteter:

Figur 47: Databasediagram mat og enheter

Kost 2014 Produkt

47

2.4.1.2 – Retter: App og Server

Fordi oppdragsgiver skulle ha muligheten til å opprette sine egne matvarer og retter, måtte disse også lagres i databasen. For å skille oppdragsgivers retter fra matvaretilsynets offisielle liste besluttet vi å separere de fra hverandre, men å beholde en tilnærmet lik struktur med samme næringsstoffer og kategorisystem, men derimot uten enheter (Retter oppgis alltid i porsjoner og gram, mer om dette i avsnitt 2.1.4.3).

2.4.1.3 - Spiste matvarer og rapportering: App og Server

Informasjon om hva brukerne av appen har registrert som spist lagres i to ulike tabeller. På appen heter disse “FoodEaten” og “DishEaten” og inneholder oppføringer med ID til sin respektive matvare eller rett, mengde spist målt i gram og tidspunkt spist. Tilsvarende tabeller på serveren heter “FoodCompositions” og “DishCompositions” og inneholder samme informasjon i tillegg til å være knyttet opp mot en oppføring i “AppReports”. “AppReports” er en tabell over rapporter innsendt fra appen og har relasjoner til en tabell over registrerte brukere, kalt “AppUsers”.

Figur 48: Databasediagram, Retter

Figur 49: Databasediagram, spist og rapporter

Kost 2014 Produkt

48

2.4.1.4 – Måltider: App

I appen gis brukerne muligheten til å komponere sine egne måltider basert på matvarer og retter fra matvaretabellen og oppdragsgivers opprettede retter. Det gis også mulighet til å inkludere sine tidligere komponerte måltider i et nytt måltid. Fordi måltidene er kompositte, blir de dekomponert til matvarer og retter når de blir spist og lagret i “FoodEaten” og “DishEaten” tabellene. Måltider er lagret med følgende skjema;

Unik måltids-ID, måltidsnavn, det totale antallet gram i én porsjon og beskrivelse lagres i tabellen: “Meal”.

ID til matvare/rett/måltid, antall gram i én porsjon og fremmednøkkel til Meal-tabellen lagres i tre tabeller: MealFood-, MealDish- og MealMealRelation.

2.4.1.5 - UserEaten: App

Fordi spist tabellene (“FoodEaten” og “DishEaten”) ikke sier noe om hvilke matvarer og retter som ble spist sammen, om de var en del av et måltid eller spist separat, finnes det på appen en ekstra tabell “UserEaten” som inneholder denne informasjonen. “UserEaten”-tabellen brukes derfor når brukeren ser gjennom hva man har spist og de andre “Eaten” tabellene brukes til å summere næringsstoffer samt til å rapportere brukerens kosthold til server. Som en ytterligere illustrasjon, legg merke til forskjellene mellom tabellene hos en bruker som har spist en eplekake og et glass melk:

“UserEaten” kan i praksis også brukes til utregning av næringsstoffsummer ol., men fordi antall nivåer av måltider inne i hverandre ikke er begrenset, kan summering ved hjelp av denne potensielt involvere tunge rekursive operasjoner. Skulle man da ved et senere tidspunkt implementere funksjoner for å se snitt konsum av næringsstoffer siste uke, måned, år, etc. vil det spares mye ressurser på å bruke Food- og DishEaten tabellene.

UserEaten FoodEaten

Helmelk (200 gram) Helmelk (200 gram) Eplekake (250 gram) Epler (100 gram) Sukker ( 30 gram) Smør ( 40 gram) Egg (50 gram) ...osv

Figur 50: Databasediagram, Måltider

Kost 2014 Produkt

49

2.4.1.6 - Komplette entitetsdiagrammer over databasene med attributter

App:

Kost 2014 Produkt

50

Server:

Kost 2014 Produkt

51

2.4.2 - JSON

JSON er en enkel tekstbasert standard for datautveksling og er sammen med XML en av de to mest brukte standardene i RESTful APIer. XML og JSON har ulike fordeler og ulemper, og mange sverger til den ene eller andre, men begge kan håndteres noenlunde likt, er lettleselige for mennesker og har stor utbredelse og støtte i de fleste programmeringsspråk. Valget for overføringsformat til APIet falt på JSON fordi JSON er hakket mindre ordrik enn XML noe som bl.a. fører til mindre bruk av nettverksdata fra appens side. I appen brukte vi Androids innebygde støttebiblioteker for håndtering av JSON, på serversiden brukte vi Web API rammeverkets biblioteker og tredjepartsbiblioteket Newtonsoft Json.NET.

2.4.3 - MVC

MVC står for Model-View-Controller og er et designmønster brukt i utviklingen av brukergrensesnitt. MVC går ut på å separere den interne representasjonen av data fra måten denne dataen er presentert til brukeren og hvordan brukerinput fanges opp. Modellen består av data og business logikk, Presentasjonen (View) er laget som presenterer informasjon til brukeren og kontrolleren håndterer kommunikasjonen mellom dem. I prosjektet vårt har vi kontinuerlig fulgt MVC designmønsteret under utviklingen av både App og Nettside for å separere brukergrensesnitt og logikk, slik at det skulle være lettere å fasilitere endringer i én av komponentene individuelt uten å måtte endre alle avhengige komponenter.

2.4.4 - Appstruktur

Under utviklingen av appen har vi forsøkt å holde strukturen og designet så konsistent som mulig i forhold til informasjonen som finnes på sidene til Android APIet og de eksempler og veiledninger som finnes på Googles offisielle utviklingssider. Under følger en utgreiing over hvordan vår app er bygget opp og hva vi har tenkt når vi implementerte denne strukturen.

2.4.4.1 - Generelt om Android

En dyptgående gjennomgang av hvordan Android er bygd opp mtp. utvikling og de ulike metodikkene de bruker er utenfor skopet av denne dokumentasjonen, men skal heller ikke være nødvendig for å skjønne hvordan vår app er strukturert. Noen nøkkelelementer som er verdt å nevne om utvikling i Android er:

Skjermer brukeren ser presenteres av klasser som arver “Activity” eller subtyper som “ListActivity”

Brukergrensesnitt defineres i ulike XML-filer, generelt én per skjerm og meny.

Ressurser defineres også i ulike XML filer, inndelt i ulike grupper, f.eks. animasjoner, farger, strenger, osv.

“ContentProviders” er klasser som gir tilgang til data, som f.eks. en SQLite database.

“Intents” er asynkrone meldinger som tillater apper å forespørre funksjonalitet fra andre tjenester eller aktiviteter. Brukes bl.a. til å veksle mellom aktiviteter.

Kost 2014 Produkt

52

Figur 51 - Applikasjonens lagstruktur og kommunikasjonsmønster

2.4.4.2 - Vår struktur

Applikasjonen er lagdelt etter Androids standardprinsipper med XML for generering av GUI der det er mulig, slik som beskrevet i avsnittet over. Vi har laget et diagram for å beskrive denne lagdelingen i Figur 51.

Som nevnt i innledningen til denne delen er mye av strukturen i appen er basert rund eller inspirert av databasen og designet av denne. Dette gjenspeiles ved egne aktiviteter for utforskning av de ulike matvarene, rettene og måltidene, som alle har sine bakenforliggende tabeller og aktiviteter for opprettelse og visning av disse samt visning av brukerens kostholdshistorikk. Et avansert diagram av dette er å finne på neste side.

Kost 2014 Produkt

53

Figur 52 - Oversiktsdiagram over appens aktiviteter

Kost 2014 Produkt

54

Pakker Vi har fulgt Javas navnekonvensjon i navngivning av pakker og pakkestruktur til de ulike java-filene, alle pakkenavn starter med domene, deretter navnet på bedrift, i vårt tilfelle prosjekt, og så evt. annen naturlig inndeling. Inndelingen vår endte opp som følger:

net.kost

net.kost.activities

net.kost.dialogs

net.kost.views

Database - SQLite Støtte for SQLite databaser er inkludert i Androids rammeverk og vi benyttet oss derfor av denne typen database i appen. All interaksjon med databasen skjer via en selvlagd ContentProvider-klasse kalt “DatabaseHelper”. I tillegg til å håndtere alle spørringer mot databasen, sørger denne klassen også for å kopiere over databasen som følger med appen (denne inkluderer bl.a. alle matvarene) til appens eget data-område. Databasen brukes i så å si alle de ulike aktivitetene i appen og er sentral for appens funksjon. “DatabaseHelper” er av den grunn appens største klasse med over 1000 linjer kode. På neste side følger en oversikt over et utvalg av klasser. Utelatt er en rekke mindre klasser, bl.a. adaptere, lyttere og dialoger.

Kost 2014 Produkt

55

KLASSE BESKRIVELSE

net.kost: DatabaseHelper Hjelpeklasse for databaseinteraksjon og opprettelse DatabaseUpdater Hjelpeklasse for henting av oppdateringer fra APIet

Implementerer Runnable10 for å kunne kjøres asynkront KostSettings Hjelpeklasse for interaksjon med preferansefiler, lagrer brukerens

preferanser. NetworkHelper Hjelpeklasse for nettverkskommunikasjon ReporterHelper Klasse som sender brukerstatistikk til server, implementerer

Runnable ServerUserHelper Hjelpeklasse for oppretting av ny bruker på server og innlogging

av bruker mot API. SqlNames Klasse med Enums og Konstanter for navn på databasekolonner SuggestionContentProvider Hjelpeklasse for å hente ut søkeresultater fra databasen UsersHelper Hjelpeklasse for opprettelse av nye brukere, utregning av deres

kaloribehov, etc. net.kost.activites: AddMealActivity Aktivitet for oppretting av nye måltider DishBrowserActivity Aktivitet for utforskning av Retter FoodBrowserActivity Aktivitet for utforskning av Matvarer MealBrowserActivity Aktivitet for utforskning av Måltider og Oppskrifter DisplayActivity Superklasse for visningsklasser DishDisplayActivity Aktivitet for visning av retter FoodDisplayActivity Aktivitet for visning av matvarer MealDisplayActivity Aktivitet for visning av måltider HomeActivity Aktivitet for visning av hjemskjerm LoginActivity Aktivitet for visning av login skjerm OverviewDayActivity Aktivitet for oversikt over hva en bruker har spist SearchActivity Aktivitet for utforskning av databasen SearchResultsActivity Aktivitet for visning av søkeresultater og live-search SetPreferenceActivity Aktivitet for visning av innstillinger-vindu net.kost.views: BListView Klasse som fasiliterer “bounce” i lister som vises i ulike aktiviteter BScrollView Klasse som fasiliterer “bounce” i scrollbare aktiviteter PieView Klasse som tegner kakediagrammer TriPieView Klasse som tegner tredelte kakediagrammer

Kost 2014 Produkt

56

2.4.5 – Serverside-struktur

Serversiden består av både API og nettside, disse er separert ved at de bruker ulike kontrollere som definerer hvilke metoder/kall som er tilgjengelige, oppførselen til disse og ulik håndtering av innkommende forespørsler. Kontrollerne bruker allikevel samme underliggende forretningslogikk og datagrunnlag fordi disse er uavhengige av grensesnittet mot omverden. Serverside programvaren er utviklet som et sammensatt prosjekt basert på ASP.NET MVC 4 rammeverket og Microsofts Web API rammeverk, som muliggjør utviklingen av en web-server med MVC arkitektur og et API i C#. Vi valgte å strukturere koden vår etter en flerlagsarkitektur i kombinasjon med MVC mønsteret og Entity Framework. Flerlagsarkitektur er en arkitektur som bruker flere logiske lag for å fordele ansvar/oppgaver og hvor hvert lag som regel kun har tilgang til laget umiddelbart over/under. Grunnet løs kobling mellom lagene kan et lag lett byttes ut med et annet tilsvarende lag eller brukes av flere ulike lag. Vi valgte denne inndelingen spesielt med tanke på at nettsiden og APIet vårt skulle kunne få bruke samme logikklag, datamodeller og databaseaksesslag. Vi endte opp med følgende inndeling:

Presentasjonslag (View og Controller)

Forretningslogikklag(BLL)

Dataaksesslag(DAL)

Datamodeller

Figur 53 - Server strukturdiagram

Kost 2014 Produkt

57

2.4.5.1 - Database – MSSQL og Entity Framework Code First

Til databasen bruker vi en MSSQL server hvor databasen og alle tabellene blir opprettet ved hjelp av Entity Framework rammeverket. Entity Framework er et objekt-relasjon kartleggings rammeverk innen .NET, som muliggjør arbeid med data i form av objekter og egenskaper, her f.eks. “Food” og “Dish”, uten å ta hensyn til de underforliggende databasetabellene og kolonnene. Bruk av CodeFirst vil si at vi koder entitets-klassene (Food, Dish, etc.) og en spesiell kontekst-klasse først og deretter genereres databasen ut ifra disse. Entitetsklassene er helt vanlige objektklasser hvor egenskapene til klassen blir kolonner i databasen, mange-til-én forhold representeres enkelt ved å ha en liste av et type objekt i en annen. I Food.cs:

Mange-til-mange relasjoner krever litt ekstra kode, under er en kodesnutt som viser hvordan vi fikk

opprettet en relasjonstabell mellom matvarer og enheter. I FoodDbContext.cs:

LINQ og Lambda For å kjøre spørringer mot databasen brukte vi LINQ og Lambda som genererte de ferdige SQL spørringene. Eksempel på uthenting av en matvare i databasen med Lambda:

2.4.5.2 - REST API

Når API delen av server-siden skulle utvikles bestemte vi oss tidlig for å bruke REST arkitektur som grensesnitt mot dataene i APIet vårt.

Hvorfor REST? REST er en av de mest brukte arkitekturene i nye APIer som utvikles i dag, ref. Ruter, Posten, m.fl., og det finnes av den grunn mange ferdige moduler, ol. man kan benytte seg av. MS Visual Studio har eksempelvis et rammeverk for utvikling av et RESTfult-API ved siden av MVC-arkitektur, som kom oss til gode i denne oppgaven.

Kost 2014 Produkt

58

Noen fordeler med REST:

Lite overhead i forhold til annen bruk av HTTP eller f.eks SOAP.

Godt standardisert, HTTP operasjoner er kjente, velforståtte og konsistente.

Lett lesbart for mennesker og lett å teste i kun en vanlig nettleser.

Krever ikke bruk av et spesifikt format for overføring.

Hva er REST? REST er en forkortelse for Representational state transfer, og baserer seg på kommunikasjon ved tradisjonelle HTTP spørringer (GET, POST, osv.) mellom en klient og server, og egner seg derfor ypperlig til vårt API hvor formålet er at klienter skal kunne hente informasjon fra server. REST er tilstandsløst, det skal med andre ord ikke være behov for å huske sesjoner, og enhver spørring er uavhengig av andre og står på egne ben. Alle ressurser må ha en unik adresse, f.eks. i vårt API er matvarer en ressurs og har unik adresse; http://kostregistrering.net/api/Food/{id}.

2.5 Personvern og anonymitet

Personvern og opprettholdelse av brukeres rettigheter til privatliv er noe som har stått sentralt i vår utvikling og har vært viktig for oss fra dag én. Det er viktig når man har med potensielt sensitive opplysninger å gjøre at man følger de retningslinjer satt av Datatilsynet relatert til behandling av personopplysninger. Retningslinjene sier bl.a. at opplysninger om brukere ikke skal samles inn hvis det ikke har noe legitimt formål, og at det skal samles inn og behandles det minimum av data som er nødvendig for appens formål. Av denne grunnen sender vi kun det minimum av informasjon fra app til API som er nødvendig for at dataene skal være nyttig i forskningsarbeidet til oppdragsgiver. Dataene som sendes er brukerens høyde, vekt, aktivitetsnivå, alder og hvilke matvarer vedkommende registrerer som konsumert, siden dette er formålet med appen kreves det at bruker godkjenner at denne dataen sendes i anonymisert form til bruk i ernæringsforskning. Som beskrevet i avsnitt 2.1.1 må det opprettes en bruker for å kunne benytte appen, derfor blir det, når bruker skriver inn et selvvalgt brukernavn, generert en anonym tekststreng ut ifra denne og det er denne anonyme strengen som sendes med dataene slik at det i forskningen kan skilles mellom ulike individer. Selv om brukernavnet, per se, ikke sendes over internett har vi allikevel bevisst unngått å bruke unikt identifiserende opplysninger som f.eks. brukerens epost, telefonens nummer eller IMEI-nummer. I stedet har vi gitt brukeren muligheten til å opprette en tilfeldig identitet om ønskelig. Det er nødvendig å kunne skille mellom ulike individer av to grunner, den første er slik at man kan se bl.a. gjennomsnittlig konsum per individ og lignende data. Grunn nummer to gjelder de som er med i spesielle forskningsgrupper og velger å oppgi sin anonymitet ved å oppgi sitt brukernavn til oppdragsgiver, slik at han på den måten kan gi personrettede kostholdsanbefalinger. Hvis det ved en senere anledning blir implementert funksjonalitet for at appbrukere skal kunne logge inn og sjekke sin statistikk på nettet er det også nødvendig med unike, men fortsatt anonyme, brukeridentiteter.

Kost 2014 Utvikling

59

Del 3 – Utvikling _________________________________________________________________________________

I denne delen vil vi presentere utviklingen av systemet inkludert testing og konseptutvikling. Fordi

løsningen er såpass omfattende ville det vært umulig å dokumentere hele utviklingsprosessen, derfor har vi valgt å ta for oss tre spesifikke utviklingshistorier som vi mener eksemplifiserer vårt arbeid og de utfordringene vi har stått ovenfor. Vi vil også ta for oss hvilke verktøy og programmer vi brukte og hvilken rolle disse har hatt for vårt prosjekt. _________________________________________________________________________________

Kost 2014 Utvikling

60

Figur 55 - Førsteutkast til logo

3.1 - Konseptutvikling

I dette avsnittet vil vi ta for oss utviklingen av prosjektets konsept og identitet. Først vil vi se på hvordan vi utviklet en grafisk profil for systemet før vi deretter begynte med skisser og den tidlige designprosessen av appen.

3.1.1 - Logo og navn

I vår gruppe har vi begge en bakgrunn fra Medier og Kommunikasjonslinjen ved videregående skole. To av hovedfokusene ved denne linjen var å skape en forståelse for merkevarebygging og gi en innføring i hvordan man skal profilere og reklamere for et produkt eller en bedrift. Vi er på ingen måter eksperter innenfor disse feltene, men har begge jobbet i en ungdomsbedrift og gjennom det arbeidet laget en full grafisk profil og reklamekampanje for bedriftens respektive produkter. Dermed mente vi at vi burde kunne ta på oss utfordringen ved å lage en enkel grafisk profil til systemet.

3.1.1.1 - Navnet Kost

Det første vi trengte var et navn. Hittil hadde systemet bare gått under navnet Kostholdapp, men vi mente dette var misvisende da oppgaven besto av å lage et helt system med API og Administrasjonsside i tillegg til en applikasjon. Navnet var også kjedelig og representerte systemet dårlig. Vi snakket med oppdragsgiver og han var av samme oppfatning og ga oss løyve til å komme opp med et bedre navn. Etter nøye gjennomgang endte valget på Kost. Kost er kort nok til å vises på alle smarttelefoner, er et ord som står som kjerne i vårt prosjekt og dermed er ekstremt beskrivende for hva systemet gjør og i tillegg klarte vi ikke å finne noen andre norske bedrifter eller systemer med dette navnet. Vi presenterte dette for oppdragsgiver og han var godt fornøyd med hva vi var kommet fram til.

3.1.1.2 - Logo

Når vi hadde funnet et navn ble vi enige med oppdragsgiver om at systemet også trengte en logo. Den skulle være enkel å forstå og skulle brukes som ikon for applikasjonen på mobil. Når vi tenkte på hva systemet vårt skulle inneholde av funksjonalitet endte vi opp med tre hovedformål vi kunne basere den nye logoen på: forskning, ernæring og kostholdopplysning. Med disse tre ordene i tankene begynte letingen etter enkle symboler som ville eksemplifisere disse sidene ved systemet. Vi diskuterte mellom oss mens vi lette og endte til slutt opp med to symboler vi mente, kombinert, ville representere vårt system på en enkel og stilfull måte. Dette var ett forstørrelsesglass og et eple i konfigurasjonen vist i figur 54. Tanken her er at man gransker eplet, som symboliserer kosthold og ernæring, med et

Figur 54 - Logo inkorporert i navnet på systemet

Kost 2014 Utvikling

61

forstørrelsesglass, som symboliserer forskning og kostholdsopplysning. Etter litt prøving og feiling fikk vi også laget en logo med hele navnet Kost inkorporert (se figur 54).

3.1.1.3 - Slagord og helheten

Når vi ble bedt om å holde en presentasjon av oppgaven, først for medstudenter i veiledningsgruppen til vår veileder, og senere for oppdragsgiver, bestemte oppdragsgiver at vi trengte et slagord i tillegg til logoen som kunne brukes på plakater og liknende. Etter å ha satt opp en ny liste med ord og setninger som beskriver vårt system kom vi frem til setningen: Forskning og kosthold i hverdagen. Med dette slagordet var tanken å binde systemet vårt til det siste og kanskje viktigste konseptet for systemet, nemlig at alle skal kunne bruke applikasjonen. Under utviklingen av ideen for systemet, som det ses nærmer på i avsnitt 4.2, hadde oppgaven evolvert fra å være et system kun til bruk i forskning til noe som skulle kunne brukes av hvermansen som et verktøy for personlig kostholdopplysning og ernæringsinformasjon. Derfor ville vi, når vi først skulle lage et slagord, ha med noen ord om hvordan systemet vårt skulle appellere ikke bare til forskningsprosjekter, men også skulle kunne brukes hver dag av vanlige mennesker.

3.1.1.4 - Sammendrag

Når man nå ser på helheten til logo, navn og slagord mener vi at vi i samarbeid med oppdragsgivere hadde laget noe som eksemplifiserer vårt system og alle dets viktigste deler og hovedmål. Når man ser på det endelige resultatet i Figur 58, kan man oppsummere det endelige resultatet slik:

Logo som representerer forskningen ved at man gransker et eple med forstørrelsesglass. Eplet representerer her ernæring og kosthold.

Navnet Kost som på en enkel og rask måte forteller brukeren hva applikasjonen handler om; nemlig kosthold.

Slagordet som binder logo og navn til hverdagen til vanlige mennesker og viser at vårt system ikke bare kan brukes til forskning, men er noe alle kan bruke for å få bedre oversikt over sitt eget kosthold, samt at de kan bidra til bedre generell kostholdopplysning ved å sende data om sine kostholdvaner til oppdragsgiver anonymt.

Figur 56 - Logo med slagord og navn

Kost 2014 Utvikling

62

Figur 57 - Skjermbilde fra 02.04.14

3.1.1.5 - Videreutvikling og helhet

Arbeidet med logo, navn og slagord ble gjort tidlig i arbeidsprosessen før vi hadde begynt med å utvikle hverken app, API eller administrasjonsnettside. Dette var bra da tanken bak å lage logen var å opprette en følelse av eierskap for systemet så tidlig som mulig, samt å lage noe vi kunne basere den grafiske delen av applikasjonen for Android på. Etter hvert som vi utviklet mer av funksjonaliteten ved appen, og det grafiske begynte å falle på plass, så vi derimot at en grønn logo ikke var optimalt. Hvis man ser på figur 57 ser man at eplet i logoen øverst til venstre nesten forsvinner helt i det grønne temaet vi valgte for appen. Vi bestemte oss derfor for å endre eplets farge for at det skulle synes bedre. I flere deler av applikasjonen hadde vi nå begynte å bruke en oransje farge. Denne kan man se gjengitt i kakediagrammene i figuren. Samme farge går også igjen i flere andre deler av applikasjonen f. eks. på forsiden, i ikoner for matvarer og i søkevinduets underoverskrifter. Dermed ble det naturlig å bytte eplets farge fra grønn til oransje. Vi så tidlig to utfordringer med fargebyttet. Den

første var at brukerne kunne tro det var en appelsin pga. den nye oransje fargen og det mer stilistiske utseende på eplet. Den andre var at det ikke er vanlig å se oransje epler og dermed ville nok et grønt eple være lettere gjenkjennelig. Derfor begynte vi å se på det helhetlige designet for å se om fargebyttet skulle beholdes eller forkastes. Når man ser på logoen som en helhet er ikke det viktigste at brukerne umiddelbart gjenkjenner det som granskes av forstørrelsesglasset som et eple, det viktigste er heller at brukeren ser at det er mat, og vi mente at uansett om eplet var oransje eller grønt, så ville man se at det var frukt det dreide seg om. Vi var også enige om at epler finnes i oransje selv om det ikke er den mest vanlige fargen, og at eplet ble mye penere som logo enn en appelsin (som nødvendigvis bare blir en runding når den er stilisert). Når vi presenterte problemet for oppdragsgiver var også han enig i vår beslutning og mente at en oransje logo ville synes bedre i applikasjonen og i tillegg ville binde det grafiske sammen på en bedre måte. Det endelige resultatet med logo, slagord og navn kan sees i figur 58.

Figur 58 - Endelig logo, slagord og navn

Kost 2014 Utvikling

63

3.1.2 - Tidlig designprosess og skisser

Når logo, navn og slagord var ferdig og vi følte at vi begynte å kjenne systemet bedre, satte vi oss ned for å lage noen konseptskisser av applikasjonen. Her brukte vi kravspesifikasjonen aktivt og prøvde å tilrettelegge for inkludering av så mye av funksjonaliteten definert der som mulig. I figur 59 under kan man se skissene i sin helhet.

3.1.2.1 - Innehold

Vi fokuserte på å illustrere de viktigste aktivitetene i applikasjonen og hvordan de skulle samhandle med hverandre. Når man ser på skissene kan man tydelig se at funksjonaliteten som er inkludert i disse er godt sammenlignbare med det endelige produktet beskrevet i Del 2. Man kan f.eks. allerede se kakediagrammet på hjemskjermen og listen over matvarer, retter og måltider i Spis-skjermen eller som den til slutt ble kalt; Utforsk. I tillegg kan vi se Vis-skjermen hvor matvaren er vist med et bilde og næringsinnhold som oppramses under.

3.1.3.1 - Skissenes rolle

Når man ser hvor mye av denne funksjonaliteten som faktisk ble implementert og hvor likt det er de endelige resultatene, kan man ikke komme til noen annen konklusjon enn at disse skissene hjalp oss i stor grad. Det var skissene vi konsulterte når vi var i villrede, grafisk sett, tidlig i prosessen, og det var disse vi brukte som forbilde for teorien bak applikasjonens struktur og endelige aktivitetsmønster.

Figur 59 - Tidlig skisse nr. 1 av aktivitetene Spis, Hjem og matvare i applikasjonen

Kost 2014 Utvikling

64

3.2 – Utviklingshistorier

Når man skal snakke om utviklingen av et IT-system kan man ikke unngå å snakke om kode. Kode er gjerne vanskelig å forstå og selv for programmeringsveteraner kan det å sette seg inn i noen andres kode være en stor og tidkrevende utfordring. Vi har derfor valgt ut tre eksempler fra koden og utviklingsprosessen som vi mener representerer den prosessen vi hadde rundt utviklingen og som eksemplifiserer de utfordringene vi sto ovenfor. Vi vil gå igjennom hvert eksempel grundig, men avgrenset og kortfattet slik at man kan få et innsyn i koden, men ikke blir offer for den ekstremt tidkrevende oppgaven det er å sette seg inn i store stykker med kode. Vi håper denne delen vil gi leseren et innblikk i vår verden og prosess og anbefaler at det dermed brukes litt tid på å forstå disse utdragene.

3.2.1 – Spist kakediagram

Dette utdraget vil handle om utviklingen av kakediagrammene under «Spist» aktiviteten. Vi valgte å ta med denne delen av utviklingen fordi det bød på større utfordringer enn vi hadde forutsett å implementere denne funksjonaliteten. Vi måtte også lage våre egne finurlige løsninger for å tegne disse riktig og gi brukeren en god opplevelse av å bruke denne funksjonaliteten. I figur 60 ser vi hvordan kakediagrammene ser ut i skrivende stund (aktiviteten er omtalt tidligere i del 2.1.6). Når vi skulle tegne disse prøvde vi først å finne noe i Androids egne biblioteker for sammensetning av slike diagrammer, men oppdaget tidlig at dette ikke fantes. Derfor tok vi et dypdykk i grafikkbibliotekene til Android isteden og der tilegnet vi oss informasjon om hvordan vi kunne tegne diagrammene fra bunnen av. Med denne informasjonen for hånd kunne vi konkludere med at den enkleste måten å få dette til på var ved å lage en klasse som arver Android.View som er superklassen for alle grafiske elementer i Android. Underklassen vi lagde ble hetende PieView og skulle implementere alle metoder som var nødvendige for å tegne sirklene basert på informasjon hentet fra brukerens preferanser og fra brukernes inntastende verdier lagret i databasen.

3.2.1.1 - Lerret og størrelse

Hvis man ser på figur 61, vil man se metoden CreatePie som tegner sirklene inn i Viewet. Den første linjen i metoden, linje 86, viser opprettelsen av lerretet alle sirklene skal tegnes på. Her bruker vi padding og størrelse beregnet ut ifra selve skjermstørrelsen til telefonen, slik at diagrammene får samme størrelse i forhold til de andre komponentene i aktiviteten på alle skjermstørrelser. Disse variablene regnes ut i andre metoder i konstruktøren.

Figur 60 - Spist aktiviteten slik den ser ut nå

Kost 2014 Utvikling

65

3.2.1.2 - Fargen

Fargen på diagrammet settes avhengig av hvilken tid det er på dagen. Dette er det metoden getEatenColor() som bestemmer og returnerer i linje 103. Mellom linje 90 og 102 er det spesialtilfellene som håndteres. Her skal ikke fargen settes etter når på dagen det er, men den skal settes til den universale fargekombinasjonen som viser at man har gått over daglig referanseinntak på den næringsverdien kakediagrammet representerer. Denne kombinasjonen er; grønn som bakgrunnsfarge på sirkelen, istedenfor hvit som normalt, og rødfarget for andel over 100% spist. Hvis

spesialtilfellene ikke slår til vil altså getEatenColor() returnere en farge basert på følgende algoritme, illustrert som en liste:

1. Er klokken mellom 08.00 og 12.00 og brukeren har spist mindre enn 33 % av referanseinntaket for næringsverdien vil fargen på det som er spist være grønt. Har brukeren spist mer enn 33 % vil sirkelens fargede del være oransje.

2. Er klokken mellom 12.00 og 17.00 og brukeren har spist mellom 33% og 75 % vil fargen være grønn. Har brukeren spist mindre enn 33 % vil fargen være lyseblå, og igjen vil fargen være oransje hvis brukeren har spist mer enn 75 %.

3. Er klokken mellom 17.00 og 23.00 og brukeren har spist mellom 75% til 100 % vil fargen være grønn. Har man spist mindre enn 75 % vil fargen være lyseblå.

4. Er klokken mellom 23.00 og 08.00 er dagen over og fargen vil være lilla.

Figur 61 - Koden for å tegne hvert enkelt kakediagram

Kost 2014 Utvikling

66

Figur 62 - Algoritmen for å regne ut tekstposisjon over diagrammene

3.2.1.3 - Tekst

Det siste metoden gjør i linje 110 til 119 er å tegne inn navnet på næringsverdien over kakediagrammet og tallprosenten av spist næringsverdi under. Vi prøvde først å få dette til via Androids innebygde XML-system for redigering av GUI, men når vi ga brukeren muligheten til å ha så mange diagrammer man ville måtte vi også gi dem muligheten til å bevege seg gjennom dem. Dette gjorde vi ved å sette på et såkalt ScrollView som er en innpakning for Views som gjør dem «scrollbare». Slik som Android er lagt opp kan man ikke lage denne typen GUI med det innebygde XML-systemet og vi ble derfor nødt til å tegne teksten direkte inn i lerretet for diagrammet. Den største utfordringen med dette var at vi da måtte regne ut hvor teksten skulle stå. Vi hadde jo tidligere beregnet størrelsen på diagrammene dynamisk i forhold til skjermstørrelsen og det betød at teksten måtte regnes på samme måte. Tekststørrelsen var det første vi regnet ut. Dette gjorde vi ved å dele skjermbredden på en konstant, for deretter å prøve og feile med tilfeldig konstanter og deling på både skjermens høyde og bredde før vi fant en enkel algoritme som beregnet tekstposisjonen riktig på de fleste skjermstørrelser. Algoritmen kan man se i figur 62. Her brukes tre faktorer for å beregne avstanden mellom teksten, den første er w som er bredden på skjermen delt på konstanten 12. Deretter beregnes variabelen b utfra hvor mange diagrammer som skal tegnes minus konstanten 6. Når vi ganget disse med hverandre og plusset på standard padding ganger to ble teksten riktig plassert på alle skjermer vi testet på inkludert nettbrett og mini-telefoner.

3.2.1.4 – Vår erfaring

Når man ser på hvordan diagrammer, tekst og prosenttall er beregnet og tegnet kan man se hvorfor dette bød på utfordringer for oss. Ikke bare valgte vi å tegne diagrammene i forskjellige farger basert på tid, men vi skulle også blande brukerens egne preferanser inn i tegningen ved at man selv kan velge antall diagrammer. Når man da ser på utfordringen med å tegne diagrammene i forskjellig størrelse basert på skjermen til brukeren og hvordan dette også måtte overføres til tekst og mellomrom, ble utfordringen bare enda større. For å løse dette best mulig utviklet vi denne delen av systemet sakte og med høy nøyaktighet og konsentrasjon, det var en tidkrevende prosess, men ved å være spesielt nøye og ved å diskutere utviklingsvalg underveis, klarte vi å bearbeide koden slik at den fungerte sømløst med resten av applikasjonen. Det skulle selvfølgelig også en del testing til (beskrevet i Avsnittet testing 3.3) for å få alt opp til en god standard, slik at kakediagrammene og aktiviteten generelt var klar til bruk.

Kost 2014 Utvikling

67

3.2.2 - Søkefunksjonalitet

En kjernefunksjonalitet i appen er søkingen og derfor er det naturlig at det skrives noen paragrafer om hvordan søkefunksjonaliteten har utviklet seg fra det å trykke på en knapp som søkte verbatim gjennom listen over matvarer, til «live» -søkefunksjonalitet tilgjengelig fra alle appens aktiviteter med egne intuitive søkeforslag og resultater fra både matvarer, retter og måltider.

3.2.2.1 - Original versjon

I skissene vi tegnet i begynnelsen av prosjektet og i den første implementasjonen av søkefunksjonaliteten kunne man kun søke fra en tekstboks fra den samme aktiviteten hvor utforsk menyen befant seg. Man skrev inn et søkeord, trykket søk og ble sendt til en ny aktivitet. Søket ble utført med en enkel SQL «where» -spørring som returnerte resultatet i en Cursor. Cursoren ble sendt videre til en CursorAdapter og CursorAdapteren bruktes som datagrunnlag for Listeaktiviteten, som har som hovedoppgave å vise en liste elementer fra en datakilde.

3.2.2.2 - Første forbedring

Den første løsningen fungerte som den skulle, men for at en app skal være lett og intuitiv å bruke i dag er den nødt til å ha et søk som viser resultater i sanntid. Vi undersøkte om det fantes noen innebygde muligheter i Android for sanntidssøk og oppdaget underveis at det fantes noe lignende. Nemlig et søkefelt (SearchView) man kunne bake inn i appens action-bar, med egne søkeforslag. Det var flere steg involvert i å implementere denne søkebaren, de viktigste var som følger:

Lage en egen ContentProvider for søkeforslag, søkeforslagene var foreløpig kun de samme som hele matvaretabellen.

Søkekonfigurasjon i form av en XML-fil.

Lage en søkeaktivitet for å vise resultatene, her kunne vi beholde den vi allerede hadde laget, med noe ekstra kode for å håndtere innkommende søke-intenter.

Deklarere aktiviteten søkbar i appens manifest-fil.

Override onCreateOptionsMenu(MenuItem) i aktiviteter som ønsket å bruke søkebaren.

Sanntidssøk var nå implementert for søkeforslag, for å implementere det på den faktiske søkesiden opprettet vi en klasse av OnQueryTextListener som fyrer av hendelser hver gang tekst endres.

Figur 63 - Javakode for sanntidssøk

Kost 2014 Utvikling

68

Figur 64 - Skjermskudd av søkeforslag i app

3.2.2.3 - Andre forbedring

Nå hadde vi et fungerende sanntidssøk med søkeforslag, men søkealgoritmen var fortsatt ikke videre god. Et søk etter “Melk med” returnerte “Melk med smak, type Litago”, men ikke “Biola, syrnet melk, uspesifisert med smak” som jo inneholder de samme ordene og som man dermed forventer skal være med. Vi brukte derfor en del tid på å lage metodene createWhereQuery(..) og createOrderByClause(..) for henholdsvis å forespørre og sortere resultatene. Et søk på “milk %” genererer nå følgende SQL where-setning: name LIKE ‘%milk%’ ESCAPE ‘*’ AND name LIKE

‘%*%%’ ESCAPE ‘*’

Søket vil nå returnere alle matvarer med “milk” og “%” i seg, uavhengig av rekkefølge, om ordet er inntil andre ord eller med små eller store bokstaver. ESCAPE nøkkelordet gjør slik at man også kan søke etter spesialtegn som f.eks. prosent. Et søk på “apple” genererer følgende ORDERBY setning: CASE

WHEN name LIKE ‘apple’ OR name LIKE ‘apple,%’

THEN 1

WHEN name LIKE ‘apple%’ THEN 2

WHEN name LIKE ‘%apple’ THEN 3

WHEN name LIKE ‘%apple% THEN 4 END

Denne sørger for at “Apple, Norwegian, raw” dukker opp før “Apples, dried” som igjen dukker opp før “Pineapple, canned, in syrup”.

3.2.2.4 - Tredje forbedring

Vi begynte på dette stadiet å bli ganske fornøyd med søket, men søkeforslagene som dukket opp var fortsatt relativt brukerfiendtlige. Et søk på “che” viste følgende søkeforslag: “Cheese, hard, Cheddar”, “Cheese, semihard, Gräddost”, “Cheese, blue mold, Norzola”, osv. Problemet var med andre ord at hvis man i det foregående søket var ute etter “Cherries, raw” var man nødt til å bla igjennom alle 42 resultatene med “Cheese...” før man fant det man var ute etter. For å forbedre dette lagde vi en algoritme i MatvaretabellImporter-programmet vårt (beskrevet i 3.4.1) som itererte gjennom alle matvarene og opprettet en egen søkeforslagstabell i SQLite databasen. Kort fortalt henter den ut første og andre ord i matvarenavnet (separert med komma), første ordet blir lagt til i et sett (uten duplikater), andre ordet skrevet ut til fil som ble gjennomgått manuelt og deretter automatisk lagt til i søkeforslagstabellen hvis den ikke fantes der fra før. Søk etter “che” returnerer nå “Cheese”, “Cherries”, “Cherimoya”, “Chestnuts”, osv.

Kost 2014 Utvikling

69

Figur 65 - Skjermskudd av søk i app

3.2.2.5 - Utfordringer med flere Cursors

Opptil dette punktet bestod søket vårt kun av matvarer, den manglet altså resultater fra oppdragsgivers retter og appbrukers måltider. Vi måtte derfor finne en løsning som inkluderte data fra tre forskjellige Cursor objekter. Dette viste seg å være en større utfordring en først antatt, det finnes nemlig ingen “MultiCursorAdapter”-klasse, alternativer som ble vurdert og forkastet var:

MergeCursor, som presenterer en liste av cursors som én cursor. Denne ble forkastet hovedsakelig fordi den ikke tillater duplikater av IDer (en rett kan fint ha samme id som et måltid siden de finnes i ulike tabeller), den er dessuten forholdsvis tungvinn å bruke og lite fleksibel.

Å slå sammen alle Cursorene i en ArrayList, forkastet fordi dette krever mye ekstra arbeid og ressurser per søk og underminer poenget med en Cursor.

Første måten vi prøvde å løse utfordringen på var å forkaste hele Adapter-klassen og heller iterere igjennom alle resultatene fra et søk og opprette et row-View per resultat, som adapter klassen gjorde uansett (trodde vi). Dette skulle vise seg å være en verdifull lærepenge i hvorfor man bør bruke klasser som kommer med rammeverket og er skrevet av erfarne programmerere. Søket vårt ble nemlig suppetregt, med mange resultater tok et søk opptil 15-20 sekunder. Vi fant ut at bl.a. to viktige optimaliseringer var gjort i Adapter-klassen, nr.1, den tegner kun radene etterhvert som du scroller og, nr. 2, den gjenbruker View-objekter hvis mulig istedenfor å instansiere et nytt per rad.

Kost 2014 Utvikling

70

3.2.2.6 - Den endelige løsningen

Vi funderte en stund på hvordan vi kunne løse utfordringen vi nå stod overfor. Vi ende opp med å forkaste CursorAdapter-klassen og lage vår egen “MultiCursorAdapter”-klasse ved å arve “BaseAdapter”-klassen og override bl.a. changeCursor(), getCount(), getItem()og getItemId() som ikke vanligvis trenger å overrides. Løsningen gikk ut på å i alle metodene sjekke hvilken posisjon adapteren “var på” og beregne en forskyvning i forhold til de ulike Cursor indeksene. Et utdrag fra getItemId() illustrerer løsningen noenlunde: For full oversikt finnes klassen som en indre klasse kalt FoodAdapter i klassen SearchResultsActivity.

3.2.3 – Oppdateringer

Dette utdraget vil handle om oppdateringsfunksjonaliteten for applikasjonen. Appen mottar oppdateringer over retter og enheter fra APIet og dette er kanskje den funkjsonaliteten som er viktigst i henhold til målet og intensjonen bak systemet.

3.2.3.1 – Første iterasjon

I utgangspunktet skulle det å sette opp kommunikasjon mot APIet være en enkel sak. Vi bygde forholdsvis raskt en metode basert på HttpGet biblioteket til Android som skulle ta imot JSON-objekter konstruert i andre metoder og sende disse til APIet og deretter vente på svar. (Mer om hvordan kommunikasjonen foregår kan leses i avsnitt 2.3) Metoden er gjengitt i figur 67.

Figur 66 - Javakode for deler av MultiCursorAdapter-algoritmen

Kost 2014 Utvikling

71

Figur 67 - Den ikke-fungerende koden for oppdatering

I denne figuren kan man se den enkle algoritmen for å kommunisere med APIet som setter de nødvendige http-headerne og deretter sender http-GET forespørselen med det konstruerte JSON objektet som «payload». Denne metoden brukes flere ganger under oppdateringene og trekkes ut her fordi den er selve grunnmuren for applikasjonens kommunikasjon med APIet. For å illustrere hvordan denne kommunikasjonen fungerer under en oppdatering, steg for steg, har vi laget aktivitetsdiagrammet i figur 68 (figur på neste side).

Kost 2014 Utvikling

72

Her ser vi at aktiviteten starter når brukeren trykker på oppdater-knappen. Da sjekker applikasjonen, ved å bruke metoden i figur 67 og senere figur 70, APIets versjonsnummer for retter, retter-kategorier og enheter. Hvis en eller flere av disse versjonsnumrene er høyere enn applikasjonens eget versjonsnummer starter steg 2 hvor applikasjonen kjører metoden fra figurene igjen og mottar de oppdaterte objektene som JSON. Hvis disse objektene kommer frem og er konfigurert riktig oppdateres deretter den lokale databasen på telefonen i steg 3. Hvis noen av stegene i steg 3 feiler vil applikasjonen ikke sette oppdateringen som fullført (vil også si ifra om dette til brukeren) og vil prøve på nytt med samme versjonsnummer neste gang brukeren trykker på oppdater-knappen.

Figur 68 - Aktivitetsdiagram over de forskjellige stegene under en oppdatering

Kost 2014 Utvikling

73

3.2.3.2 – Blokking av hovedtråden

Under oppdateringer er det ekstremt viktig at brukeren ikke bruker databasen da dette kan gjøre den korrupt og forårsake kanselleringer slik som vist i Figur 68 steg 3. Det første vi prøvde var rett og slett å kjøre oppdateringene i hovedtråden og la applikasjonen fryse mens den oppdaterer. Dette ville derimot ikke Android-operativsystemet tillate og applikasjonen vår ble drept når vi brukte denne metoden. Vi omstrukturerte derfor koden slik at oppdateringene kjørtes i en egen tråd. Ved å gjøre dette introduserte vi derimot muligheten for at brukeren kunne bruke appen mens den oppdaterte, noe vi som sagt ikke kunne tillate. Vi løste dette ved å manuelt vise en dialog til brukeren (se Figur 69) som blokkerte all brukerinteraksjon mot appen og låste applikasjonen gjennom hele oppdateringsprosessen. Her var det viktig med nøye gjennomgang av koden og riktig feilhåndtering for å sørge for at applikasjonen ikke ble evig låst hvis oppdateringene feilet. Derfor brukte vi mye tid på å fange alle feil vi kunne fremprovosere eller forutse og låste i alle disse tilfellene enten opp applikasjonene igjen eller lot den krasje helt ut til operativsystemet hvis feilen var ødeleggende for programflyten.

3.2.3.3 – Feiltesting

Da vi feiltestet funksjonaliteten fungerte oppdateringene strålende. Oppdateringsdialogen låste all brukerinteraksjon og vi hentet oppdateringer raskt og uten feil. Vi var godt fornøyde med resultatet og gikk over til å utvikle annen funksjonalitet. Det var først når vi avinstallerte applikasjonen fordi vi hadde gjort noen små endringer med databasen at vi tilfeldigvis også skulle oppdatere. Vi trykker på oppdateringsknappen, som hadde fungert perfekt frem til nå, og plutselig krasjer applikasjonen totalt. Under krasjet følger vi med på Logcat og ser at applikasjonen, istedenfor å få melding «200 ok» fra server, får melding «500 bad request». Melding 500 oppstår når det sendes noe til serveren som den ikke skjønner formatet på. Altså mente vårt API at meldingen den fikk ikke var formatert på riktig måte. Vi syntes dette var høyst merkelig da alt hadde fungert fint for noen minutter siden og bestemte oss for å restarte applikasjonen for å utelukke engangsfeil. Etter å ha restartet trykket vi igjen på oppdateringsknappen og nå fungerte alt strålende igjen! Det virket som om vi hadde oppdaget en feil som bare skjedde første gangen applikasjonen kjørte på mobilen. Etter å ha bekreftet dette for testmobilen prøvde vi det samme på flere typer emulatorer og andre mobiler og fikk samme feil der; hver gang applikasjonen starter for første gang ville oppdateringsfunksjonaliteten krasje.

3.2.3.4 – Andre iterasjon

Det skulle vise seg at det å ha isolert feilen var av begrenset hjelp da dette problemet var ekstremt vanskelig å finne årsaken til. Slike feil, som bare skjer i visse instanser av et programs kjøremønster, er notorisk vanskelig å løse. Derfor endte vi opp med å bruke over 8 timer hardt arbeid på å prøve å finne årsaken til feilen uten hell. Det var først dagen etter at vi begynte å se i detalj på hva applikasjonen faktisk sendte via http-protokollen til APIet. Når vi åpnet pakkene i Fiddler så vi at alle

Figur 69 - Oppdateringsdialogen

Kost 2014 Utvikling

74

http-headerne hadde forsvunnet fra http-GET forespørselen. Dette betød at APIet ikke klarte å gjenkjenne autorisasjonsnøkkelen i forespørselen eller hvilken formatering den sendtes med. Vi prøvde derfor flere metoder i HttpGet rammeverket til Android, men uansett hva vi gjorde fikk vi den samme feilen med manglende headere. Det var først når vi gikk inn i Androids egen dokumentasjon for HttpGet og finleste teksten at vi så at Android selv ikke anbefaler utviklere å bruke HttpGet og at dette biblioteket er foreldet. Her mente Android at man heller skulle bruke det nye og forbedrede biblioteket HttpURLConnection som er mer stabilt og raskere. Vi kastet oss over tastaturet og byttet ut vår originale metode med en oppdatert versjon som brukte HttpURLConnection. Problemet ble da løst umiddelbart og det viste seg at feilen lå i selve HttpGET. Resultatet av endringen kan ses i figur 70.

Figur 70 - Den endelige metoden for henting av data fra API

Kost 2014 Utvikling

75

3.2.3.5 – Konklusjon

Oppdateringsfunksjonaliteten fungerer godt i skrivende stund og vi har ikke funnet noen nye feil hverken i betatestingsgruppen eller under vår egen testing. Da denne funksjonaliteten er så vital for applikasjonens virkemåte mener vi at tiden det tok å fikse feilen og de ressursene vi brukte på det var nødvendige. Vi har også fått muligheten til å gjøre applikasjonen mer robust i annen funksjonalitet som følge av denne erfaringen. Å bygge oppdateringsfunksjonaliteten for applikasjonen skulle vise seg og bli en tøff og tidkrevende utfordring hvor vi måtte grave oss gjennom internettprotokollers virkemåte, avansert pakke-sniffings software og detaljer i Androids klasse-bibliotek. Men vi har helt klart lært mye av prosessen og det har vist oss hva man burde se etter når man benytter nye biblioteker i et rammeverk.

3.3 – Testing

3.3.1 - Valg

Fordi oppgaven orginalt var tiltenkt flere grupper var funksjonaliteten prosjektet krevde for å fungere, selv på enkleste nivå, enorm for en enkel gruppe på to. Derfor advarte vi oppdragsgiver allerede under sammensetningen av kravspesifikasjonen om at utvidet testing av koden måtte bli nedprioritert i forhold til utvikling av funksjonalitet hvis systemet skulle fungere tilfredsstillende. Oppdragsgiver var enig i tankegangen og sa han heller ville ha et produkt som fungerte enn et halvferdig system med god bruk av enhetstesting og andre automatiserte tester. Vi ble enige om å ta dette med så tidlig som mulig og satte dermed dette som et tydelig krav i kravspesifikasjonen (se Vedlegg A).

3.3.1 - Utviklertesting

Avgjørelsen om å nedprioritere automatiske tester betød på den andre siden ikke at systemet aldri skulle testes. Vi, som utviklere, gjorde enormt mye praktisk testing av funksjonalitet og robusthet (deler av denne prosessen kommer frem i avsnitt 3.2 om utviklingshistorier). Her brukte vi en enkel form for integrasjonstesting for å få testet og verifisert hver modul ettersom den ble ferdigstilt. Man kan dele prosessen under utviklingen av en modul inn i steg som vist i Figur 71.

Figur 71 - Gangen i testprosessen

Kost 2014 Utvikling

76

Her kan man se at testprosessen er iterativ. Vi gjorde gjerne flere runder med testing både når modulen var ferdig, og når nye moduler som skulle samhandle med den originale modulen skulle implementeres. Dette er selvfølgelig en god del arbeid, men i henhold til den erfaringen vi har med enhetstesting og automatiserte tester fra andre prosjekter, kan vi med sikkerhet si, at hadde vi valgt å implementere dette, hadde ikke systemet vært funksjonelt i dag.

3.3.2 - Brukertesting

Etter hvert som systemet begynte å bli ferdig trengte vi input fra brukerne av applikasjonen selv. Det er notorisk vanskelig som utvikler å sette seg inn i brukerens hode, og selv om oppdragsgiver hadde kommet med kommentarer til de ulike delene av systemet underveis, mente vi at vi trengte mer brukerinput. Det var i den ånd at vi opprettet en beta-testingsgruppe på Facebook. Her inviterte vi venner og familie samt noen andre interesserte og ba dem om å kjøre og teste applikasjonen. Vi spurte om tilbakemelding på design, brukervennlighet og alle feil og mangler de måtte finne. I dette stadiet var systemet selvfølgelig ikke helt ferdig og noen av tilbakemeldingene gjaldt uimplementert funksjonalitet. Vi prøvde å være raskt ute med svar på testbrukernes tilbakemeldinger og noen av deres kommentarer hjalp oss med å gjøre store forbedringer i systemet. Det var f.eks. denne gruppen som først fant en feil som gjorde at hele applikasjonen krasjet når man opprettet en ny bruker. Med deres hjelp fikk vi diagnostisert problemet og fant ut at det skyldtes en oversettelsesfeil mellom engelsk og norsk. I Figur 72 kan man øverst se tilbakemeldingene fra en testbruker hvor han systematisk går gjennom sine erfaringer med applikasjonen og under kan man se vårt svar (her fra Martin W. Løkkeberg).

3.3.3 - Vår erfaring

Etter hvert som systemet ble større og større og mer av funksjonaliteten kom på plass merket vi at det hadde vært mer optimalt med automatiserte tester. I noen tilfeller «ødela» vi gammel kode ved å gjøre endringer når noe nytt skulle implementeres. Heldigvis hadde vi drevet parprogrammering gjennom hele prosessen og fordi begge medlemmer av gruppen kunne like mye om koden klarte vi å diagnosere feilene relativt raskt, før det ble alt for store problemer. Hadde derimot systemet blitt enda større og hadde det ikke vært mulig med parprogrammering ville nok mangelen på automatiserte tester blitt en mye større utfordring etter hvert som systemet vokste.

Figur 72 - Eksempel på tilbakemelding og svar fra testbruker

Kost 2014 Utvikling

77

Det hadde også vært en fordel med automatiserte tester når andre utviklere skal videreutvikle vårt arbeid, av den grunn fasiliterte vi for implementasjon av enhetstesting på serversiden ved å strukturere etter flerlagsarkitektur som gjør det mulig å bytte ut ett lag med et annen, f.eks. et testlag, ved hjelp av dependency-injection. Vi har i tillegg prioritert kodekommentering og god dokumentasjon, både i denne rapporten og på nett, så vi mener det bør være godt mulig for utenforstående å sette seg inn i systemet. Vi vil si at testprosessen vår har vært forholdvis vellykket. Systemet fungerer og skal nå lanseres. Vi har et lavt antall krasj per dag og oppdragsgiver har ikke hatt noen store problemer med sin administrasjonsside. Det vil nok høyst sannsynlig oppstå bugs senere, men det gjør det i alle systemer, uavhengig av type og mengde med tester. Vi må derfor si oss fornøyde med systemets test-tilstand i forhold til krav og rammebetingelser for utviklingen.

3.3.4 – Videre testing

Når appen lanseres vil vi sette opp Google Analytics for å overvåke dens tilstand. Dette analyseverktøyet gir andre utviklere og oppdragsgiver muligheten til å hente ut statistikk fra appen om hvor mange krasj man har hver dag per app og hvor mange som bruker appen osv. Med et slikt verktøy for hånd kan videre testing og feilretting utføres og sendes til alle brukere via oppdateringer i Google PlayStore.

Kost 2014 Utvikling

78

3.4 Om Verktøy

De følgende avsnittene tar kort for seg hvilke verktøy (programmer) vi har brukt i løpet av prosjektet, hva verktøyene er til og hvorfor vi valgte de. Hånd-i-hånd med valg av verktøy følger valg av rammeverk og teknologier, i løpet av et såpass stort prosjekt som dette er det naturlig å utnytte en stor mengde rammeverk, men de er lite hensiktsmessige å ramse opp i en liste her, og derfor har vi valgt å heller flette de viktigste inn i prosessdelen(4.1) og produktstrukturdelen(2.4) av dokumentasjonen.

3.4.1 – Selvutviklede støtteprogrammer

Under prosjektets forløp har det under ulike stadier vært behov for en del funksjonalitet, både direkte og indirekte relatert til produktet, og vi utviklet i den anledning våre egne små støtteprogrammer for å dekke behovene som oppstod. Under følger en oversikt over disse og deres rolle i prosjektet.

3.4.1.1 - FolderDiff

Fordi vi ofte jobbet med lokale kopier av prosjektene, som ved endt arbeidsøkt skulle synkroniseres til felles prosjektmappe i Dropbox (se avsnitt 3.4.2.8), trengte vi et rudimentært program som enkelt kunne vise hvilke filer som var blitt oppdatert samt håndtere synkroniseringen for oss. Varianter av slike programmer finnes allerede, men ingen som kombinerte akkurat den funksjonalitet vi ønsket, derfor lagde vi et skrivebordsprogram vi kaller FolderDiff, som utnytter Windows’ innebygde kopieringsprogram RoboCopy til synkronisering. Programmet ble skrevet i Visual Studio i C#.

3.4.1.2 - MatvaretabellImporter

Fordi Matvaretilsynets matvaretabell ikke finnes i et lett anvendelig format mtp. programmering, men kun som et nedlastbart Excel-ark, trengte vi et program for å parse, dvs. analysere og systematisere, matvaretabellen slik at vi kunne bruke den i appen og backend-løsningen. Vi laget derfor laget en skrivebordsapplikasjon som tar imot en filsti til matvaretabellen i form av to Excel ark, et på norsk og et på engelsk. Programmet oppretter en SQLite database, prosesserer og forener de to Excel-arkene til matvare- og matvarekategori-oppføringer i databasen og genererer en

Figur 73 - Skjermskudd av FolderDiff som sammenligner to mapper

Kost 2014 Utvikling

79

tabell med søkeforslag (se avsnitt 3.2.2 om utviklingen av disse) ut ifra matvarenes navn. En fin oversikt over hvordan disse oppføringene ser ut finnes i databasediagrammene i produktdelen(2.4.1) av dokumentasjonen. Selve databasefilen programmet genererer er den som blir brukt i appen, men algoritmene som prosesserer Excel-arkene blir også brukt, med enkle modifikasjoner, for å fylle databasen til backend-løsningen. Programmet ble skrevet i MS Visual Studio i C#.

3.4.1.3 - UsernameHasher

UsernameHasher er et enkelt skrivebordsprogram som tar imot en tekststreng som den hasher med algoritmen SHA-256 for deretter å vise denne til bruker. Programmet er laget for oppdragsgiver slik at han kan få ut det hashede brukernavnet, som følger med i all eksportert rådata, og dermed generere personalisert statistikk i samarbeid med en spesifikk bruker. Dette forutsetter at bruker av appen frivillig oppgir anonymiteten sin ved å sende inn sitt faktiske brukernavn.

Figur 74 - Skjermskudd av MatvaretabellImporter

Kost 2014 Utvikling

80

3.4.2 - Verktøysoversikt

Hvorfor vi endte opp med å velge de programmene vi gjorde har flere grunner, men mange av valgene var ganske klare etter at vi hadde bestemt oss for rammeverk og språk å utvikle i. Som vil begrunnes i avsnitt 4.1.2, om begrensning og definering av oppgaven, endte vi opp med å velge Android og Java som utviklingsgrunnlag for appen. Valget falt derfor ganske naturlig på Eclipse som er en av de mest brukte verktøyene for Android utvikling og som har lenger fartstid som Android utviklingsmiljø enn flertallet av alternativene. Valget av C# og MS Visual Studio baserte seg i størst grad på familiaritet, vi hadde kjennskap til disse fra tidligere prosjekter og var allerede nødt til å lære oss en helt ny utviklingsplattform for å utvikle app til Android og ønsket ikke å gjøre det samme for utviklingen av backend-løsning, men heller dra nytte av de erfaringene vi hadde.

3.4.2.1 - Eclipse

Eclipse er et flerspråklig utviklingsverktøy for programvare bestående av et integrert utviklingsmiljø (IDE) med støtte for utvidet funksjonalitet ved programvareutvidelser. Vi har i vårt prosjekt brukt «Eclipse ADT bundle» som er en versjon av Eclipse med innebygget støtte for Android-utvikling (blir altså distribuert med Android SDK). Dermed inneholder denne versjonen verktøy for å emulere telefoner, kjøre debugging via Dalvik Debug og støtte for visuell redigering av grafisk grensesnitt.

3.4.2.2 - MS Visual Studio

I utviklingen av backendløsningen, dvs API, Server og nettside, har vi brukt utviklingsverktøyet Visual Studio som er en ekstensiv IDE for en stor rekke språk, hovedsakelig rettet mot Windows plattformen, utviklet av Microsoft. Visual Studio har også spesialtilpassede prosjekttyper for utvikling i rammeverket ASP.NET som vi har benyttet oss av under utviklingen, språkene vi har utviklet i er i all hovedsak C#, med noe Javascript, Html og CSS. Verktøyet har utallige funksjoner, en av de som har vært flittigst brukt av oss er bl.a. innebygd funksjonalitet for utforsking av ekstern database samt mulighet for å generere databasetabeller ved bruk av Entity Framework Code First, som er ytterligere beskrevet i avsnitt 2.4.5.1 i produktdelen av dokumentasjonen. Vi har også brukt Visual Studio til å utvikle en skrivebordsapplikasjon for å generere en SQLite database, til bruk i Android Appen, ut ifra matvaretabellen.

3.4.2.3 - SQLite Spy

SQLite Spy er et lite og enkelt program for å vise innholdet av, samt og kjøre spørringer mot, SQLite databaser. Vi har brukt dette programmet for å vedlikeholde, slette/opprette/endre tabeller, og til feilsøking av databasen som blir brukt i appen.

3.4.2.4 - Fiddler

Fiddler er en HTTP basert Proxy server applikasjon for debugging. Med fiddler har vi analysert pakker som blir sendt mellom applikasjonen på en emulert mobiltelefon og vårt REST-API. Dette ga oss uvurderlig informasjon om hvordan disse to delene av vårt system faktisk samhandlet og gjorde at vi klarte å fikse en stor feil i applikasjonen (finnes under 3.2.3).

3.4.2.5 - Microsoft Office

Microsoft Office er en programvarepakke med ulike programmer tilpasset kontorbruk. I vårt arbeid har vi brukt to programmer fra denne pakken: Word til dokumentbehandling og PowerPoint til produksjon av lysbildeserier for presentasjon av oppgaven til interesserte parter.

Kost 2014 Utvikling

81

3.4.2.6 - Adobe Photoshop

Adobe Photoshop er et avansert bilderedigeringsprogram fra Adobe Systems. Vi har brukt denne programvaren til å lage den grafiske profilen til applikasjonen og systemet. Dette innbefatter sammensetning av logo med og uten tilhørende slagord, ikoner for matvarer og annet i applikasjonen og annen grafikk slik som plakater o.l.

3.4.2.7 - Gliffy

Gliffy er et nettbasert verktøy for produksjon av de fleste typer diagrammer. Vi har brukt dette verktøyet til å produsere alle diagrammer som trengtes til vårt system. Gliffy støtter alt fra UML til enkle figurer og har vært uvurderlig under vårt arbeid for raskt å kunne produsere oversiktlige diagrammer over bl.a. databaser, klassehierarkier og hendelsesforløp.

3.4.2.8 - Dropbox

Dropbox er et program, og en tjeneste, som lar deg opprette en spesiell mappe lokalt på harddisken, hvor alt innholdet blir synkronisert i sanntid mot en webserver. Det er også mulig å dele mapper med andre brukere og se fil-historikk slik at man kan gjenopprette tidligere versjoner av filene sine. I prosjektet vårt har vi brukt Dropbox som sentralisert versjonskontroll for all kode og dokumentasjon. Siden vi kun har vært to som har jobbet sammen prioriterte vi sanntidssynkronisering og enkel bruk/tilgang enn bl.a. strengere kontroll på hvem som har bidratt med hva, branching av prosjekter, etc. som man får ved distribuert versjonskontroll slik som f.eks. Git.

3.4.2.9 - Skype

Skype er et program for utveksling av meldinger og fasiliterer talekommunikasjon via ip-telefoni. I de tilfellene hvor gruppen ikke har jobbet fra samme sted har vi vært i kommunikasjon via Skype.

3.4.2.10 - Trello

Dette programmet er en essensiell del av prosessen og vil bli beskrevet i avsnittet om prosjektstyring 4.3.3.1.

Kost 2014 Prosess

82

Del 4 – Prosess _________________________________________________________________________________

I dette avsnittet vil vi ta for oss gruppens prosess før, og under, utviklingsstadiet. I vår oppgave var

hovedfokuset hele tiden på å utvikle en løsning som faktisk kunne distribueres og brukes. Vi som gruppe var ikke særlig interesserte i å lage et pilotprosjekt som aldri ville se dagens lys. Vi innså tidlig at dette ville bli en stor utfordring da oppgaven egentlig var ment for tre eller flere hovedprosjekter. I planleggingsfasen var derfor noe av det viktigste vi gjorde å avgrense oppgaven og sette et mål som faktisk var mulig å oppnå. Vi visste vi måtte jobbe hardt, men valgte å gå den ekstra distansen for å ha sjansen til å produsere noe som kunne bli verdifullt og fungerende. Dermed vil denne delen av dokumentasjonen gi en grundig forklaring på hvordan vi gjorde denne avgrensningen og tolkningen av oppgaven, slik at vi kunne lage noe både vi og oppdragsgiver kunne være fornøyde med. Neste steg etter avgrensing og tolkning var å sette sammen en kravspesifikasjon. Her vil vi diskutere kravspesifikasjonens rolle i prosjektet og hvordan den fungerte under samarbeidet med oppdragsgiver. I tillegg går vi igjennom hvilke arbeidsteknikker og utviklingsmetoder vi brukte under utviklingen og hvordan disse fungerte for gruppen i henhold til dynamikk og progresjon. Når man planlegger en oppgave må man nødvendigvis velge noen rammeverk og verktøy som kan gjøre utviklingen så rask og smertefri som mulig. Hvordan vi som gruppe tok avgjørelser i forhold til dette og hvordan dette påvirket arbeidet, er også inkludert her. _________________________________________________________________________________

Kost 2014 Prosess

83

4.1 - Tolkning og definisjon av oppgaven

Fordi oppgaven egentlig var ment for flere grupper krevde den ekstensiv tolkning og redefinering før arbeidsstart. Vi vil her gå igjennom denne prosessen og hvilke tanker som farget avgjørelsene vi tok under dette stadiet.

4.1.1 - Førsteinntrykk og møte med oppdragsgiver

Da vi så oppgaven for første gang var det flere ting som tiltrakk oss. Det første var at oppgaven var veldefinert og klar i formuleringen av problemstillingen (se Vedlegg F for oppgaveteksten). Vi hadde allerede vært i kontakt med andre oppdragsgivere hvor oppgavene var forholdsvis diffuse, eller skulle utarbeides av oss som gruppe rett før prosjektstart, og dette var ikke noe vi egentlig ønsket oss. Derfor virket denne oppgaven mer tiltrekkende med klart språk og presise ønsker. Det er nødvendigvis mangler ved oppgaveteksten fra et teknologisk standpunkt, men alt i alt så dette ut som noe vi ville være involvert i. Vi tok derfor kontakt med utstederen av oppgaveteksten (Asgeir Brevik) og avtalte et møte 05.11.13, hvor vi skulle prate om oppgaven og se om vi som gruppe var en god match med det oppdragsgiver hadde sett for seg. Under møtet diskuterte vi flere scenarioer og ideer rundt prosjektet og vi hadde en god tone gjennom det hele. Noen dager senere sendte vi en mail om at vi gjerne ville være med å utvikle systemet skissert i oppgavebeskrivelsen, og kort tid etter fikk vi positivt svar.

4.1.2 – Begrense og definere oppgaven

Nå som vi var om bord på oppgaven startet arbeidet med å definere oppgaven innenfor et skop som passet tidsrammene for hovedprosjektet. Vi var klare for å jobbe hardt med oppgaven, men ville ikke gå i fellen hvor gjennomføringen av oppgaven ble uoppnåelig. Det ble tidlig klart at vi var nødt til å lage tre deler til systemet, en backend del i form av et API, en frontend del i form av en app og en administrasjonsnettside for å administrere API og oppdateringer til appen. Disse tre delene må til for at systemet skal fungere etter oppdragsgivers minimumsønsker.

4.1.2.1 Plattform og rammeverk

Når vi startet med å innskrenke oppgaven var det i utgangspunktet meningen at vi skulle lage en app som skulle fungere både til Android og iOS. Skal man gjøre dette må man enten, som vi først tenkte, lage én app i Androids SDK med Java og XML og én app i Apples Objective C rammeverk, eller man kan lage appen for begge plattformene i ett språk slik som en web-app med JavaScript eller via C++ i Qt. Vi brukte ca. to uker på å utforske teknikker som kunne brukes for å utvikle til begge plattformer samtidig, men innså forholdsvis tidlig at både utvikling i Qt og utvikling i JavaScript ville by på flere ulemper. Blant disse var at vi ikke kunne noen av disse språkene godt. Vi har god erfaring med Java, C# og web-programmering men hadde bare hatt enkle kurs i JavaScript og C++. Når man tar hensyn til oppgavens omfang ville det simpelthen bli for tidkrevende å sette seg inn i et helt nytt språk og rammeverk når vi var nødt til å implementere den store mengden med funksjonalitet som skulle til for å produsere noe oppdragsgiver faktisk kunne bruke. Fordi vi begge hadde god erfaring med Java og vi mente at læringskurven ville bli minst bratt hvis vi holdt oss til dette språket, la vi frem et forslag til arbeidsgiver hvor vi laget applikasjonen bare til Android, men hvor vi skulle ta hensyn til utvidelsesmuligheter slik at det enkelt skulle kunne lages en app til iOS på et senere tidspunkt. Vår oppgave skulle derfor bestå av å lage en app til Android, et API for kommunikasjon mellom app og server og en Administrasjonsside hvor oppdragsgiver kunne administrere API og databaser. Oppdragsgiver var godt fornøyd med forslaget vårt og vi ble enige om at vi skulle gjøre det slik. Når dette var avgjort satte vi oss ned og definerte en forprosjektrapport som man kan se i Vedlegg B.

Kost 2014 Prosess

84

4.2 - Kravspesifikasjonen

Kravspesifikasjonen ble satt sammen etter at oppgaven var veldefinert og omfanget var avklart. Vi skal her gjennomgå kravspesifikasjonens rolle i prosjektet og hva den betød for vår utvikling og vårt samarbeid med oppdragsgiver. Kravspesifikasjonen i sin helhet kan man finne i Vedlegg A.

4.2.1 - Kravspesifikasjonens rolle

Kravspesifikasjonens rolle varierte i forhold til hvilken fase av prosjektet vi befant oss i. Derfor er det naturlig å oppdele dette avsnittet deretter.

4.2.1.1 - Under arkitektur og planlegging

Kravspesifikasjonen var spesielt viktig for oss tidlig i prosjektet. Vi brukte den flittig til å kartlegge prosjektet under utviklingen og den var en stor del av inspirasjonen bak databasediagrammene og arkitekturen i systemet. Den var nyttig for å holde oss, som programmerere, i skjortekragen og sette oss på riktig kurs i forhold til oppdragsgivers ønsker for systemet. Det er lett når man utvikler et system å bli revet med i øyeblikket og produsere funksjonalitet som hverken fungerer godt i systemet eller for oppdragsgiver, men som man i øyeblikket ser på som noe som vil gi appen en «wow faktor» eller litt ekstra piff. Vi må innrømme at fristelsen for å produsere slik funksjonalitet slo oss titt og ofte, men med kravspesifikasjonen i hånd ble det lettere å holde kursen.

4.2.1.2 - Under Utviklingsfasen

Under utviklingsfasen var ikke kravspesifikasjonen like viktig. Vi hadde da allerede laget en skisse av systemet og vi hadde en forholdsvis klar idé om hvordan ting skulle bli. Det hendte vi refererte til den for å sjekke småting, men i all hovedsak følte vi at kravspesifikasjonen her har spilt en mer passiv rolle.

4.2.1.3 - Under Dokumentasjonen

I den fasen vi er i nå, med skriving av dokumentasjon og tilbakeblikk på de ulike fasene i prosjektet, er kravspesifikasjonens rolle blitt mer fremtredende igjen. Vi har sammenliknet systemet som faktisk ble laget med de kravene vi satte for over 3 måneder siden og sett at de fleste kravene er oppfylt eller viste seg og bli uvesentlige. Noen krav som ble uvesentlige var sikkerhetskravene for databasen på server som vi fjernet etter avtale med oppdragsgiver. Disse gikk på sikkerhetskopiering og liknende på API og nettside som nå blir automatisk håndtert av hostingtjenesten og derfor ikke var ikke noe vi trengte å legge oss opp i. Kravet er jo for så vidt oppfylt, men det trengtes ingen innsats fra vår side for å oppnå dette og det var derfor irrelevant i kravspesifikasjonen.

4.2.2 – Ble kravspesifikasjonens krav oppfylt?

Det korte svaret her er «ja». Vi har implementert alle minimumskravene, og noen få av de ønskede og eventuelle kravene. Dette var å forvente pga. oppgavens omfang og vi er generelt sett godt fornøyd med systemets ferdighetsgrad slik det er i dag. Vi har hele tiden prøvd å tilrettelegge for utvidet funksjonalitet og noe av dette er spesifikt dokumentert i denne dokumentasjonen. Andre utvidelsesmuligheter som man kan hente direkte fra kravspesifikasjonen slik som muligheten for å legge inn bilde på matvarer, er tilrettelagt for, men ikke utover enkle grep i databasen. Grep slik som dette er blitt gjort under hele utviklingen, og bør gjøre det slik at andre utviklere er i stand til å videreutvikle vår kode. Vi vil også anbefale leseren av denne rapporten til å ta en kikk på oppdragsgivers ord om oppgaven i Vedlegg E, som også vil være relevant her.

Kost 2014 Prosess

85

4.3 - Planlegging og utviklingsmetodikk

Når man skal jobbe med et prosjekt over lengre tid og utvikle produkt(er) av en viss størrelsesorden er det essensielt å være bevisst på hvilke arbeidsmetoder og hvilken utviklingsprosess man ønsker å ha. Ikke minst er det viktig at det er en enighet mellom gruppens medlemmer og en forståelse mellom de ulike interessentene over hvilken utviklingsmetodikk som brukes. Vi diskuterte derfor tidlig i prosjektet hvilke utfordringer vi kom til å støte på underveis i prosjektet, spesielt med tanke på at vi kun var to personer i gruppen, og hvilke utviklingsmetoder som best egnet seg til vårt prosjekt. I dette avsnittet vil vi derfor presentere vår metode under arbeidet og hvordan planleggingen av prosjektet foregikk. Vi vil se på samarbeidet i gruppen og hvordan dette påvirket det endelige resultatet. Prosjektstyringen er en viktig del av dette og vil bli fremlagt her.

4.3.1 - Samarbeid og kommunikasjon

Samarbeid Som tidligere nevnt i presentasjonen (1.1) har vi, som de to eneste deltakerne i gruppen, jobbet sammen en lang stund. Vi har kjent hverandre nesten hele livet og har gjennom det funnet en god balanse når vi skal samarbeide. Hvis det oppstår tvister eller uenigheter, enten i forhold oppgaven eller til personlige områder er vi komfortable nok med hverandre til å diskutere dette og komme til en løsning forholdsvis raskt. Dette har gjort at samarbeidet på gruppen gått forholdsvis smertefritt og at gruppens tilgjengelige tid har blitt brukt effektivt og målrettet. Uten denne gode dynamikken innad i gruppen hadde vi ikke kunnet komme så langt som vi har gjort og vi hadde hatt mye større problemer med å levere et produkt som faktisk fungerer.

Kommunikasjon Fordi vi jobbet med parprogrammering (vil bli forklart i neste avsnitt) var kommunikasjon sjeldent et problem. Vi satt i samme rom, foran samme skjerm og programmerte og hadde vi noen problemer med det den som satt foran tastaturet den dagen gjorde, hadde vi muligheten til å si ifra der og da. Var en av oss syke eller ikke kunne møte opp den dagen, jobbet vi gjerne over Skype eller fordelte små deler av kode som man kunne gjøre for seg selv. For å kommunisere med arbeidsgiver brukte vi i all hovedsak mail eller Trello. Trello og hvilken rolle det har spilt i prosjektet kan man lese om i avsnitt 4.3.3.1.

4.3.2 Valg av metodikk

Generelt sett har IT-prosjekter en tendens til, i kontrast til prosjekter innenfor en rekke andre fagfelt, å være i konstant utvikling mtp. hva interessentene ønsker, hvilken teknologier som er tilgjengelig og hvilke plattformer produktene skal tilpasses for. Av denne grunnen kreves det ofte at IT-prosjekter er fleksible og det har i de siste årene blitt veldig populært med ulike former for smidig utvikling. Det var, med kun to personer, mindre behov for ekstensive planleggingsdokumenter og streng overholdelse av forhåndsbestemte krav og planer, fordi man får en veldig tett dialog og det er færre personer involvert i hele prosessen. På den andre siden er det lett å bli for detaljfokusert og få et for snevert syn, slik at man rett og slett mister oversikt over prosjektet hvis man ikke har en oversikt over ulike milepæler og en liste med funksjonalitet et produkt må ha for å tilfredsstille interessentene. Av disse grunnene og siden begge gruppemedlemmene allerede før prosjektets start var kjent med smidig utvikling, ble vi raskt enige om at dette var en utviklingsmetodikk som passet vårt prosjekt.

Kost 2014 Prosess

86

4.3.2.1 - Smidig utvikling

Smidig utvikling er en gruppe med IT-utviklingsmetoder basert på iterativ og inkrementell utvikling, hvor krav og løsninger utvikles gjennom tett samarbeid mellom alle involvert i utviklingen, inkludert kunden. Det finnes mange måter å jobbe etter smidig metodikk på, ofte det vanligste er å følge en av de etablerte smidigmetodikkene som bl.a. kanban og scrum. I vår situasjon, med kun to utviklere, ville mange av de etablerte prosessene involvere en del overflødig arbeid og medføre ofte unødvendig ekstra prosessadministrasjon. Vi valgte derfor å fokusere på verdiene bak smidig utvikling;

Individer og samhandling er viktigere enn prosesser og verktøy

Fungerende programvare er viktigere enn ekstensiv dokumentasjon

Tett kundesamarbeid er viktigere enn kontraktsforhandling

Hurtig svar på endringer er viktigere enn å følge en plan.

Med disse i bakhodet jobbet vi tett etter grunnidéene om iterativ og inkrementell utvikling, og valgte å følge en kjent arbeidsteknikk innenfor smidig utvikling kjent som XP (eXtreme Programming).

4.3.2.2 - XP

Mye av grunnen til at valget falt på XP er fordi vi har god erfaring med å jobbe med XP fra tidligere programmeringsprosjekter, spesielt par-programmeringen egner seg godt med to utviklere. Par-programmering går ut på at én skriver kode mens den andre kvalitetssikrer og ser over koden som skrives, og vica versa. Det er spesifikt fire aspekter ved par-programmering vi har hatt god nytte av:

1. Vedkommende som koder har en tendens til å miste oversikten over helheten når han holder på med skrivingen av spesielt komplekse algoritmer, det er da veldig nyttig å ha en programmeringspartner som hele tiden kan holde helheten i fokus.

2. Ofte er det vanskeligste med programmeringen av en ny modul/iterasjon rett og slett å komme i gang med kodingen. Er man to er dette mye lettere fordi man da får en forpliktelse overfor hverandre. Vår erfaring er at vi har kommet raskt i gang de gangene vi har planlagt å kode og vi har holdt fokuset på programmering over lengre tidsrom enn ellers.

3. Ofte blir den resulterende koden av bedre kvalitet fordi man konstant kan dra nytte av begge utviklernes erfaring og kunnskap.

4. I henhold til vårt prosjekt spesifikt, fordi vi kun var to, har en gevinst vært at begge har hele tiden hatt kunnskap om alle de ulike delene av prosjektets kode, som har redusert tiden brukt på feilsøking betraktelig.

Det skal dog ikke feies under teppe at denne typen arbeidsteknikk også kan føre med seg ulemper. Noen av ulempene har hatt positive effekter, eksempelvis er man nødt til å programmere på samme tidspunkt og følge samme timeplan, dette har hos oss ført til bl.a. jevn fremgang og mindre utsettelse av arbeidsoppgaver. Av rent negative ulemper er kanskje den mest fremtredende at når enkel kode produseres kunne man ofte ha doblet produktiviteten ved å kode separat, men vi mener at i vårt prosjekt har gevinstene ved XP, og smidig utvikling generelt, veid opp for ulempene.

Kost 2014 Prosess

87

Figur 75 - Utdrag fra Trello-prosjektet. Viser listen «Aktuelt for Asgeir» og «Done»

4.3.3 Prosjektstyring

4.3.3.1 - Trello

Trello er en gratis web-basert prosjektstyrings applikasjon som er spesielt tilrettelagt for prosjektstyringsteknikken kanban. Når man bruker Trello oppretter man «boards» som i all hovedsak er en nettside av lister med lister. Hver liste er bygd opp av kort som man kan legge til selv. Disse representerer gjerne en oppgave eller mål som skal oppnås innenfor prosjektet. Det er meningen at kortene skal flyttes fra liste til liste etter hvert som statusen på den oppgitte oppgaven endrer seg. Skriver man f.eks. et kort som heter «Lag en overskrift» kan man starte dette kortet helt til venstre i listen «Oppgaver», deretter flytte den til «Under utvikling» når man starter å lage overskriften og til «ferdig» når den er implementert. Man kan ha et uendelig antall lister i Trello og man kan bruke det til alle typer prosjektstyring, enten det er å bake en kake eller å utvikle en søkemotor.

Trellos rolle for oss Vi brukte Trello flittig under utviklingen av prosjektet. Applikasjonen erstattet i all hovedsak dagboken og ga oss muligheten til å holde oversikten over hva som skulle gjøres og hvilken status de forskjellige oppgavene hadde. Vi mener

at Trello gjorde vårt arbeide lettere og gav oss et enkelt verktøy for å lett kunne drive prosjektstyring. Vi brukte også Trello som kommunikasjonsmiddel mot oppdragsgiver. Vi hadde en egen liste som het «Aktuelt for Asgeir (oppdragsgivers navn)» hvor vi la inn bilder, lenker og statusrapporter som han kunne se på. Dette var en god måte for han å holde tritt med prosjektet på i sin travle hverdag, han fikk oppdateringer på sin mobil når noe ble gjort i prosjektet og kunne se progresjonen dag for dag.

4.3.3.2 - Arbeidsplan

Vår arbeidsplan har ikke vært et spesifikt dokument men heller et amalgam av mindre periodiske arbeidsplaner opprettet ved starten av en sprint, disse tok i begynnelsen av prosjektet form av innlegg på prosessnettsidens logg, men etterhvert gikk vi over til å bruke Trello til å sette frister på og planlegge oppgaver.

4.3.3.3 - Prosessnettside og dagbok

Prosessnettsiden er en nettside vi opprettet helt i starten av prosjektet, her opprettet vi en dagbok vi brukte mye i starten av prosjektet for å holde oversikt over hvilke oppdragsgivere vi hadde vært i kontakt med, hvilke mail vi hadde sendt, møtereferater, ulike statusrapporter, osv. Den andre funksjonen nettsiden hadde var å huse dokumentasjonen vi opprettet underveis i prosjektet, slik at veileder og oppdragsgiver lett kunne får tilgang til den. Etter at utviklingen var kommet godt i gang gikk vi i all hovedsak over til Trello til det vi hadde brukt dagboken til, men prosessiden huset fortsatt prosjektskissen, forprosjektrapporten og kravspesifikasjonen.

Kost 2014 Prosess

88

4.3.3.4 - Databasediagrammenes rolle i utviklingen

Som punkt 2.4.1 i utviklingsdelen beskriver stod databasedesignet sentralt i vår utviklingen og av samme grunn var den viktig i styringen av prosjektet. Når første utkast av databasen hadde blitt designet fikk vi en mye bedre oversikt over hva vi hadde fremfor oss av utvikling. Ut ifra databasedesignet kunne vi se hvilke deler backend-løsningen og appen kom til å bestå av og dette i stor grad styrte planlegging av de grove trekkene i prosjektet og ga en målestokk på hvor vi lå an i utviklingen.

Kost 2014 Avslutning

89

Del 5 – Avslutning _________________________________________________________________________________

I denne avsluttende delen gjør vi rede for noen av de erfaringene og resultatene vi har oppnådd i

henhold til selve posjektet, det ferdige produktet og prosessen underveis. Vi tar for oss hvilket læringsutbytte prosjektet har brakt oss, samt hvilke teknologier og rammeverk vi har måttet lære oss under utviklingen. Det siste avsnittet inneholder en konklusjon som kort summerer opp våre tanker rundt hele oppgaven. _________________________________________________________________________________

Kost 2014 Avslutning

90

5.1 – Det ferdige produktet

Det ferdige produktet vil som tidligere nevnt lanseres i Google Play Store i begynnelsen av Juni, det er derfor sannsynlig at appen, under navnet Kost, vil være tilgjengelig når dette leses. Nettsiden er tilgjengelig på adressen kostregistrering.net og kan i en begrenset periode brukes med brukernavn og passord vedlagt i mappen «Sensur» på CDen som følger med rapporten. Vi ber om at denne kontoen ikke brukes til å gjøre endringer, men kun for å se igjennom sidene. Det samme gjelder APIet som kan brukes med token som også vil være inkludert på CDen. Ut ifra den testingen vi har utført, tilbakemedlinger vi har fått fra testgrupper og egne erfaringer fungerer løsningen forholdsvis knirkefritt, men det er naturlig å forvente at ulike bugs vil vise seg når systemet blir tatt i bruk av større brukermasser etter lansering i App Store. Slik systemet er laget kan koden håndtere store brukermasser, men grunnet budsjetter kjører løsningen på en mindre ressurssterk server og vil være den begrensende faktoren. Dette kan lett løses ved å oppgradere til en mer ressurssterk, evt. en dedikert, server.

5.1.1 – Videre utvikling

Vi har hele tiden under utviklingen vært påpasselig med å tilrettelegge for videre ekspansjon av løsningen, dette fremgår også underveis i denne dokumentasjon hvor flere aspekter rundt dette tas opp. Oppgaven var originalt ment for flere grupper og det gjenstår fortsatt deler av oppgavebeskrivelsen, mest fremtredene her er en applikasjon for iOS tilsvarende den vi har utviklet for Android. Det kan også være aktuelt å lage en nettside for brukere hvor de kan logge inn og se statistikk over sitt eget næringsinntak, denne siden kan da utnytte store deler av det vi har utviklet i henhold til API og administrasjonsside. Vi håper at alle disse planene vil realiseres etter hvert som brukerbasen og interessen øker, og at oppdragsgiver da til slutt vil sitte på en omfattende løsning basert på det grunnlaget vi har dannet.

5.1.2 – Produktets verdi

Her vil vi se på hvilken verdi produktet har for oppdragsgiver og for brukerne av appen. Vi har hele tiden hatt to sterke interessenter i form av disse to gruppene og det er derfor naturlig å se på hvordan de kan dra nytte av vårt prosjekt og hvordan vi håper hverdagen deres vil endres.

5.1.2.1 – Verdi for oppdragsgiver

Mye av verdien for oppdragsgiver er godt forklart i oppdragsgivers attest i punkt 5.2, men vi tillater oss å lage et sammendrag av det vi mener er det viktigste i henhold til dette. Det viktigste momentet når vi skal snakke om verdi for oppdragsgiver er den nye måten han nå kan samle inn data på. Han trenger ikke lenger å bruke skrevne ark og skjemaer, som både brukeren og han selv må slave over for å digitalisere, men kan derimot heller få rådata generert automatisk og importere dette direkte inn i sine analyseprogram. Fordi han kan kjøre multiple forsøk samtidig innunder samme systemet kan han drive flere forsøk enn han kunne under papirmøllen og samtidig enkelt hente ut rådata per forsøk som kan bearbeides uten større forbehandling. Oppdragsgiver kan også «låne» ut systemet til andre prosjekter som kan bruke hans løsning for innsamling på sine egne forsøk. Dermed kan potensielt systemet revolusjonere hele datainnsamlingsprosessen for større deler av forskningsmiljøet han er en del av, eller til og med andre miljøer han velger å gi tilgang. Andre institutter og prosjekter kan også inkorporere sine egne uthentingsløsninger, applikasjoner eller systemer og knytte disse opp til oppdragsgivers nye API for å dra nytte av den datamengden

Kost 2014 Avslutning

91

appen har hentet inn. Dette gjør det lettere for oppdragsgiver å dele sin forskning og kanskje lage større prosjekter i samarbeid med andre aktører. Med de databasene oppdragsgiver vil generere gjennom sin registrering av naturlige enheter og retter vil appen til slutt kunne inneholde alle norske matvarer som selges. Selv om appen kanskje blir utdatert eller ikke blir populær vil hans arbeid med disse databasene til slutt gi ham en verdi som ingen andre har klart å skape. Fordi oppgaven ble utvidet med mål om å tiltrekke vanlige mennesker og ikke bare brukes som et lukket forskningsverktøy vil oppdragsgiver også ha tilgang til mye større mengder data fra grupper som ellers aldri hadde vært med på slike forsøk. Han kan i fremtiden tiltrekke oppmerksomhet til produktet for å få større brukerbaser og utvide forskningen i det uendelige hvis det er ønskelig. Fordi vi har hatt konstant fokus på å tilrettelegge for videre utvikling kan han også utvide systemet til å inneholde alle deler han beskrev i oppgaveteksten (Vedlegg F), og dermed ende opp med en helt komplett løsning som kjører på alle plattformer.

5.1.2.1 – Verdi for brukerne

Personer som deltar i forsøk hos oppdragsgiver trenger ikke lenger å skrive ned hva de har spist om- og om igjen, men kan lagre sine måltider og registrere konsum ved et enkelt trykk i appen. Fordi brukeren også har tilgang til en logg over hva de selv har spist kan de, uten å måtte gjøre ekstra arbeid, følge med på sin egen progresjon og se tilbake på det kostholdet de har hatt uten å måtte lete i skjemaer og statistikker. For alle andre brukere på det åpne markedet representerer appen en revolusjon innen norskbaserte kostholdsapper. Det finnes kun enkle apper for visning av den norske matvaretabellen på markedet i dag og ingen hvor man kan drive noen form for registrering av inntak. Vår app vil også inneholde oppdragsgivers databaser som potensielt kan overskygge matvaretabellen og øke antallet retter tilgjengelig for registrering betraktelig. På den måten vil brukerne kunne registrere, og holde styr på, sitt egen næringsinntak på en enklere måte etterhvert som appen forsetter å bli forbedret. Det vil stadig bli flere naturlige enheter og retter når oppdragsgiver legger disse inn via nettsiden og med vårt oppdateringssystem vil alle appbrukere kunne bruke disse med bare et enkelt tastrykk fra oppdragsgivers side. Hvis han deretter oppretter en dialog med sine brukere kan de potensielt etterspørre retter og brukergruppen selv kan dermed være med å påvirke hvilke oppdateringer som prioriteres.

5.2 – Ord fra oppsragsgiver

Oppdragsgivers attest er å finne under Vedlegg E.

5.3 – Læringsutbytte

I løpet av prosjektet har i måttet sette oss inn i rammeverk, best practices, teknologier og generellt sett praktisk kunnskap om lanseringen av en løsning. Vi hadde aldri som gruppe lansert hverken en nettside, app eller API fra bunnen av og dette var noe vi måtte lære oss underveis. Fordi vi, på dette prosjektet, ikke hadde noen tekniske rådgivere, og oppdragsgiver ikke besitter kompetanse innenfor IT, måtte vi rådgi oppdragsgiver i forhold til alt teknisk i løsningen, bl.a. web-hosting, sikkerhet og robusthet for systemet.

Kost 2014 Avslutning

92

Selv om vi begge hadde god kjennskap til Javaprogrammering, hadde ingen av oss tidligere erfaring med Android utvikling eller noen av Androids rammeverk. Vi så derfor på dette prosjektet som en god mulighet til å lære oss denne typen programmering. Nå når prosjektet er ferdig kan vi med sikkerhet si at vi har ervervet oss en masse god erfaring som vil komme til nytte i arbeidslivet. Vi har fått kjennskap til de mest brukte klassene i Androids rammeverk, samt Androids designprinsipper, struktur, oppbygning og etablerte teknikker. Til slutt er det også verdt å nevne at vi aldri hadde laget et API før, selv om vi hadde erfaring med nettsideutvikling i C#. Dette betød at læringskurven her var slakere, men at det fortsatt var betydelige mengder å sette seg inn i.

5.4 – Konklusjon

Av alle våre semestere ved HIOA var dette semesteret det mest intensive og krevende, men også det mest lærerrike og givende. Vi har under dette prosjektet jobbet jevnt og trutt fra starten av og strukturert tiden vår godt, men grunnet omfanget av oppgaven har det ikke vært uvanlig med 10-timers arbeidsdager, selv i høytider og helger. Vi kan derfor se tilbake og være fornøyd med resultatet av arbeidet og innsatsen vi har lagt inn i det. Det var aldri aktuelt for oss å levere et produkt som ikke kunne lanseres eller brukes av oppdragsgiver, derfor har hovedfokuset vært på å produsere fungerende moduler. Dette har naturlig nok farget mange av valgene vi har tatt, men vi har aldri følt at vi har forsaket andre kvaliteter ved programmet. Vi har implementert alle minimumskravene nedsatt i kravspesifikasjonen, og noen få av de spesifiserte ekstra kravene. Vi er generelt sett godt fornøyd med systemets ferdighetsgrad slik det er i dag. Alt i alt kan vi konkludere med at prosjektet har vært en suksess. Oppdragsgiver har fått et system som fungerer godt under testing og er som nå er så godt som klar for lansering.

Kost 2014

93

Ordliste

A

Activity (Android) En Aktivitet er en separat, fokusert ting en bruker kan gjøre. Nesten alle aktiviteter samhandler med en bruker, så aktivitetsklassen håndterer opprettelse av vindu til plassering av brukergrensesnitt.

Ajax Asynkron JavaScript og XML, er en webutviklingsteknikk for å lage interaktive nettsider. Dette gjøres ved at sidene utveksler litt og litt data med serveren i bakgrunnen, i stedet for å laste hele siden på nytt hver gang brukeren gjør en forandring.

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.

Android SDK Android SDK er en programvareutviklingspakke som gjør det mulig å utvikle Android-applikasjoner. Denne inneholder mange nyttige verktøy, emulator og eksempler på applikasjoner med medfølgende kildekode.

API API er et trebokstavs akronym for engelsk Application Programming Interface, på norsk applikasjonsprogrammeringsgrensesnitt, som betegner et grensesnitt i en programvare slik at spesifikke deler av denne kan aktiviseres (kjøres) fra en annen programvare. Slike samarbeidende programvaredeler betegnes gjerne komponenter.

ASP.NET Webapplikasjons-rammeverk utviklet og markedsført av Microsoft. Rammeverket gir brukere muligheten til å programmere dynamiske websider, webapplikasjoner og webtjenester.

Asynkron (Programmering) Brukes om operasjoner som gjøres utenom hovedtråden, eller mer generelt en operasjon som ikke «stopper opp» eksekveringen av et program.

Autoriseringstoken

Dette er en tilfeldig generert nøkkel som kan enten generes i av oppdragsgiver for utlån for adgang til APIet eller av appen og systemet selv for adgang internt. Denne tokenen kan se slik ut: YsCoLSU+kbD5pjW0onA+X1RJlvYJBCYDmusj8H0RbFE=.

B

Best practice En best practice eller «beste praksis» er en metode eller teknikk som har vist seg å konsistent bedre eller mer robust enn de oppnådd ved andre metoder.

Branching Et komplekst konsept brukt av bl.a. GIT som det finnes en forklaring på her: http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging

Kost 2014

94

C

C# C# (uttales C sharp) er et programmeringsspråk for objekt-orientert programmering, utviklet av Microsoft, basert i hovedsak på programmeringsspråkene C++ og Java.

C++ C++ er et populært høynivå programmeringsspråk som er en utvidelse av språket C. Har støtte for bl.a. objektorientert programmering.

ContentProvider (Android) “ContentProviders” er klasser som gir tilgang til data, som f.eks. en SQLite database.

CSS Cascading Style Sheets (CSS, gjennomgående stilark) er et språk som brukes til å definere utseende på filer skrevet i HTML eller XML.

CSV Comma-separated values (CSV) er et filformat brukt for å lagre tabellarisk data hvor nummer og tekst lagres i ren tekstform som kan leses i et tekstredigeringsverktøy. Linjene i tekstfilen representerer radene i en tabell, og kommaene i en linje deler det som er felter i en tabellrad.

Cursor (Android) Et Interface som tilbyr tilfeldig aksessering via lese og skriveopperasjoner mot et resultat av en databasespørring mot Androids lokale database.

CursorAdapter (Android) En adapter som fremviser data fra en Cursor til en ListWidget.

D

Dalvik Debug DDMS benytter seg av ADB til å feilsøke applikasjoner kjørende på enhet eller emulator. Her kan man feilsøke nettverkstrafikk, diskplass, minnebruk mm.

Dependency-Injection Dependency injection er et software design pattern hvor en eller flere avhengigheter blir «injected». http://stackoverflow.com/questions/130794/what-is-dependency-injection

E

Enhet En naturlig enhet laget av oppdragsgiver og assosiert med passende matvare via administrasjonssiden.

Entity Framework Entity Framework er et objekt-relasjon kartleggings rammeverk innen .NET, som muliggjør arbeid med data i form av objekter og egenskaper.

F

Fremmednøkkel En nøkkel i en database er attributter/data som kan peke til eller fastsette andre data. Nøkkelbegrepet brukes i hovedsak i sammenheng med relasjonsdatabaser. I tillegg til at nøkler tjener

Kost 2014

95

som referanser, er de viktige integritetsregler, dvs. regler som begrenser hvilke tilstander som er lovlige i databasen.

G

Git Git er et versjonskontrollsystem. Det kjennetegnes ved å være distribuert og ikke mappehierarki-basert.

GUI «Graphical User Interface» representerer den grafiske siden av et brukergrensesnitt

H

Harris–Benedict likningen Er en metode for beregning av en persons basalmetabolisme (hvilestoffskiftet) som baserer seg på alder, vekt, aktivitetsnivå og kjønn.

HTTP-Header En HTTP-header er kjernen av HTTP forespørsler og svar, de inneholder informasjon om bl.a. klient browser, forespurt side, server, etc.

HTTP-GET En metode på HTTP-protokollen med hensikt å hente data fra mottaker.

HTTP-POST En metode på HTTP-protokollen med hensikt å levere data til mottaker.

I

IDE Et integrert utviklingsmiljø, ofte forkortet IDE (fra det engelske uttrykket Integrated Development Environment), er en type programvare som brukes til å skrive og lage annen programvare.

Integrasjonstesting Fasen i testingen av et system hvor individuelle moduler blir kombinert og testet som en gruppe.

Intent (Android) Asynkrone meldinger som tillater apper å forespørre funksjonalitet fra andre tjenester eller aktiviteter.

J

Javascript JavaScript er en implementasjon av ECMAScript, et skriptspråk som er best kjent for å tilføre dynamiske elementer til nettsider. Sammen med øvrig innhold på nettsiden (hovedsakelig HTML) sendes det kode (innenfor et <script> - tagpar), som kjøres lokalt i nettleseren, automatisk eller som reaksjon på brukervalg på siden.

JSON JavaScript Object Notation, en enkel tekstbasert standard for datautveksling.

Kost 2014

96

L

Lambda I C# er et lambda utrykk en anonym funksjon som eksekverer kode.

LINQ Language Integrated Query (LINQ) er en .NET Framework-komponent som gir spørre-funksjonalitet med SQL-lignende syntaks.

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 filtrering.

M

Microsoft IIS Er en web-server laget av Microsoft for bruk med Windows NT familien. Den har vært en integrert del av Windows siden Windows NT 4.0.

MSSQL Microsoft SQL Server er et relasjonsdatabasehåndteringssystem utviklet av Microsoft.

MVC Modell View Controller. En arkitektur for programvareutvikling

N

Newtonsoft Json.NET En JSON serialiserer som kan serialisere og deserialisere .NET objekter med Json.NET’s kraftige JavaScriptSerializer.

O

Objective-C Objective-C er programmeringsspråket som brukes av Apple. Det er basert på C.

P

Padding Her menes: et mål på mellomrommet mellom objekter.

Parse «Parsing» eller syntaktisk analyse er prosessen med å analysere en tekststreng i henhold til dets grammatiske regler, for deretter å kunne bruke dets data i andre former.

Payload En «payload» refereres som oftest til som innholdet eller kroppen i en overføring av data.

Q

Qt Qt er et portabelt programvarebibliotek for utvikling av programmer som uten endringer i kildekoden kan kompileres til å kjøres på flere ulike operativsystemer og plattformer.

Kost 2014

97

R

REST En programvarearkitektur for å tilby innhold. Baserer seg på kommunikasjon ved tradisjonelle HTTP spørringer (GET,POST,osv.) mellom en klient og server.

RoboCopy Robocop eller “Robust File Copy” er en kommandolinje kommando for å synkronisere, kopiere, klippe ut og lime inn data via kommandolinjen i Windows.

Runnable (Java) Et Interface som implementeres for trådhåndtering i Java-rammeverket. Er designet for å tilby en standardprotokoll for objekter som vil utføre kode når de er aktive.

S

SearchView En Widget som tilbyr brukere søkemuligheter i form av en søkelinje i menyfeltet på en Android-applikasjon.

SOAP SOAP er en plattformuavhengig protokoll for utveksling av XML-baserte meldinger i datanettverk.

SQL Structured Query Language (SQL) er et programmeringsspråk brukt til å kommunisere med relasjonsdatabaser

SQLite SQLite er et relasjonsdatabasesystem i et lite C-bibliotek. I motsetning til andre databasesystemer er SQLite integrert i klientapplikasjonen og ikke en separat prosess.

Superklasse Brukes om klasser som nedarver metoder og egenskaper til andre klasser.

T

Tråd En tråd er en sekvens av programinstrukser som kan kjøres uavhengig av andre instrukser i et program (en lettvekts-prosess).

U

UML Unified Modeling Language (UML) er en industristandard for datarelatert modellering, forvaltet av et internasjonalt konsortium kalt Object Management Group (OMG).

V

View (Android) Klasser som eksponerer grunnleggende brukergrensesnitt klasser som håndterer skjerm-layout og brukerinteraksjon.

Kost 2014

98

X

XML Extensible Markup Language (XML) er et universelt og utvidbart markeringsspråk. Brukes til deling av strukturerte data mellom informasjonssystemer og til koding av dokumenter og som kommunikasjonsmiddel mellom ulike informasjonssystemer og dataformater.

Kost 2014

99

Kilder Det er vanskelig å vite hva som er aktuellt å ha med som kilder i en rapport som denne, fordi grensen mellom nyervervet erfaring og oppslått informasjon lett glir over i hverandre. De mest brukte kildene under dokumenteringen er i all hovedsak vår egen løsning, både i form av bruk av app, API og nettside, men også i form av kildekoden.Derfor tas det her kun med et utvalg konkrete kilder som er konsultert under skrivingen av dokumentasjonen. REST - http://stackoverflow.com/questions/90451/why-would-one-use-rest-instead-of-web-services Personvern - https://www.datatilsynet.no/Teknologi/Apper/Mobilt-personvern/ Android klasser - http://developer.android.com/reference/packages.html

Kost 2014

100

Vedlegg

2014

Høgskolen i Oslo og Akershus

[KRAVSPESIFIKASJON] Jonas Moltzau & Martin W. Løkkeberg Gruppe 12

Vedlegg A

Innhold

Innhold .................................................................................................................................................... 0

1. Introduksjon ........................................................................................................................................ 2

1.1 Presentasjon .................................................................................................................................. 2

1.2 Forord ............................................................................................................................................ 3

1.3 Leserveiledning .............................................................................................................................. 3

1.4 Bakgrunn ....................................................................................................................................... 3

2. Systembeskrivelse ............................................................................................................................... 4

2.0.1 Mål for systemet .................................................................................................................... 4

2.1 Funksjonelle krav ........................................................................................................................... 4

2.1.1 Applikasjon [1]: ....................................................................................................................... 4

2.1.2 Kost API og administrasjonsside[2]: ....................................................................................... 5

2.2 Ikke-funksjonelle krav .................................................................................................................... 6

2.2.1 Brukervennlighet: ................................................................................................................... 6

2.2.2 Effektivitetskrav: ..................................................................................................................... 6

2.2.3 Sikkerhetskrav ........................................................................................................................ 6

2.2.4 Implementasjonskrav: ............................................................................................................ 6

2.2.5 Leveransekrav: ........................................................................................................................ 6

2.2.6 Fremtidig utvidelse av systemet ............................................................................................. 7

2.2.7 Lovmessige krav ..................................................................................................................... 7

2.2.8 Krav til grensesnitt .................................................................................................................. 7

4. Ordliste ................................................................................................................................................ 8

Vedlegg A

2 Hovedprosjekt 2014 - Kost Fakultet for teknologi og design, Høgskolen i Oslo og Akershus

1. Introduksjon

Hovedprosjekt 2014 Fakultet for teknologi og design, Høgskolen i Oslo og Akershus

1.1 Presentasjon

Tittel: Kost Oppgave: Å utvikle en IT-løsning for innrapportering av data for bruk i forskning, bestående av en Android applikasjon og et API1 med tilhørende web-grensesnitt2, for registrering av matkonsum og uthenting av statistiske rådata. Gruppenummer: 12 Gruppemedlemmer: Jonas Moltzau Martin W. Løkkeberg Veileder: Eva Hadler Vihovde Oppdragsgiver: Studieretning for samfunnsernæring Institutt for helse ernæring og ledelse Fakultet for helsefag Høgskolen i Oslo og Akershus Ansvarlig for oppgaven (HIOA): Asgeir Brevik 483 53 097 Email: Asgeir.Brevik@hioa.no

Vedlegg A

3 Hovedprosjekt 2014 - Kost Fakultet for teknologi og design, Høgskolen i Oslo og Akershus

1.2 Forord

Kravspesifikasjonen er et internt styringsdokument beregnet som en avtale mellom oppdragsgiver og oppdragstager. Det skal i dette dokumentet fremlegges hvilke krav oppdragsgiver har til systemet for at det skal kunne utføre de oppgaver oppdragsgiver vil effektivisere. Kravspesifikasjonen er beregnet på alle interessenter i prosjektet, og er skrevet deretter mtp. faguttrykk og liknende.

1.3 Leserveiledning

Kravspesifikasjonen er delt inn i Forord, Leserveiledning, Bakgrunn, Systembeskrivelse, Funksjonelle krav, Ikke-funksjonelle krav og konklusjon.

Forordet beskriver kravspesifikasjonens rolle generelt i prosjektet. Bakgrunn beskriver aktualiteten til prosjektet. Systembeskrivelse er en tekstlig beskrivelse av systemet og dets funksjonalitet, samt rollen det

spiller for oppdragsgiver.

Funksjonelle krav er delt inn i krav for hver del systemet, disse er merket med notasjonen [n]. Del [1] er applikasjonen for Android, mens del [2] er APIet og administrasjonssiden. Under hver av disse delene merkes hvert krav med notasjonen a) - z), når det henvises til et spesifikt krav, gjøres dette på formen [2a] for del 2 krav a). Ord og uttrykk som kan være uklare eller trenger forklaring er samlet i en ordliste på slutten av dokumentet. Ord som har en forklaring er merket med en superskript notasjonslik.

1.4 Bakgrunn

HIOA Institutt for helse, ernæring og ledelse (HEL) holder til på studiested Kjeller. For å ha høy kvalitet på undervisningen fokuserer undervisningspersonalet på å holde seg oppdatert innenfor forskning og fagutvikling. Oppgaven er forespurt av studieleder ved Samfunnsernæring Asgeir Brevik.

Vedlegg A

4 Hovedprosjekt 2014 - Kost Fakultet for teknologi og design, Høgskolen i Oslo og Akershus

2. Systembeskrivelse

Oppgaven går ut på å utvikle en IT-løsning for innrapportering av data for bruk i forskning ved Instituttet HEL. Denne skal bestå av en Android applikasjon, hvor brukere kan registrere kostholdsvaner basert på mattilsynets matvaretabell3, og et API med tilhørende web-grensesnitt utviklet i MS Visual Studio4, for registrering av matkonsum og uthenting av statistiske rådata. Systemet skal forenkle forskningsprosessen for forskere i ernæringsmiljøet ved HEL, samt at den skal appellere til vanlige brukere og promotere kostholdsbevissthet. Android applikasjonene skal gi brukeren muligheten til å registrere sine kostholdsvaner i form av matvarer tatt fra matvaretabellen, retter5 som er komponert enten av brukeren selv eller prekomponert av studenter ved HEL. Det skal også kunnes registrere måltider som kan bestå av både retter og matvarer, disse skal bare komponeres av brukeren og lagres på brukerens telefon. Funksjonalitet for å organisere matvarer, retter og måltider skal implementeres på en måte som gjør systemet lett forståelig og brukervennlig. Brukeren skal ha muligheten til å enkelt kunne søke etter valgt matvare, rett eller måltid og deretter kunne legge dette til som spist for denne dagen. Når matvaren, retten eller måltidet er registrert skal brukeren kunne følge sitt næringsinntak på hjemskjermen ved enkle figurer, og deretter kunne gå mer i detalj via tabeller og liknende. Applikasjonen skal sende denne dataen til APIet daglig, der det lagres anonymisert. APIet skal tilby matvaretabellen i et programmeringsvennlig rammeverk. Man skal kunne hente ut ønsket informasjon om matvarer, retter og evt. ernæringsvaner etter administrators diskresjon. Administrator vil få tilgang til å sette inn informasjon og gi tilganger via en administrasjonsside2. Denne skal administrator kunne bruke til å hente ut rådata for videre statistisk bearbeidelse. Rådata skal suppleres i et brukervennlig format slik som XML6.

2.0.1 Mål for systemet

- Bidra til enklere informasjonsinnsamling av ernæringsdata. - Å skape lettere tilgang til matvaretabellen. - Hjelpe brukere med å få oversikt over eget kosthold.

2.1 Funksjonelle krav

2.1.1 Applikasjon [1]:

2.1.1.1 Minimumskrav:

a) Mulighet til å registrere konsum av enkle matvarer og drikke fra matvaretabellen

b) Mulighet for bruker å lokalt komponere enkle måltider ut ifra råvarer fra matvaretabellen.

c) Volum/mengdeangivelse for matvarer i naturlig enhet7 og/eller i gram.

d) Visning av enkel grafikk, f.eks. kakediagram, som indikerer det prosentvise bidraget av henholdsvis karbohydrat, protein og fett, evt. andre relevante næringsstoffer, til det totale energiinntaket.

e) Mulighet til å vise logget/registrert inntak av ulike næringsstoffer i en tabell eller liste til brukeren, med referanseinntak8 markert som tallverdi eller nivå.

f) Applikasjonen skal rapportere samlet dagsinntak av matvarer til ekstern database én gang i døgnet så fremt den har internettilgang.

g) Mulighet for bruker å registrere anonym konto med brukernavn, passord, høyde (f), vekt (f), alder, aktivitetsnivå (f)og kjønn.

Vedlegg A

5 Hovedprosjekt 2014 - Kost Fakultet for teknologi og design, Høgskolen i Oslo og Akershus

h) Applikasjonen skal ha en lokal kopi av databasen over matvarer og retter.

i) Applikasjonen skal ha en navigeringsmeny som alltid er tilgjengelig.

j) Bruker skal kunne søke, og bla gjennom, matvarer, retter og måltider.

k) Energibehovet skal beregnes ut ifra Harris–Benedict prinsippet9.

l) Applikasjonens lokale database skal kunne sømløst oppdateres til nyeste versjon av APIets database for retter og matvarer.

2.1.1.2 Ønsket tilleggsfunksjonalitet:

m) Engelsk versjon av applikasjonen.

n) Utvide funksjonaliteten i krav [1e] til å vise statistikk over inntak av spesifikke næringsstoffer i løpet av siste uke, mnd., år osv.

o) Utvide krav [1f] med rapportering av måltider, måltidstidspunkt, type måltid osv.

2.1.1.3 Eventuell tilleggsfunksjonalitet:

p) Mulighet til å legge ved bilde til brukernes selvlagde retter og måltider.

2.1.2 Kost API og administrasjonsside[2]:

2.1.2.1 Minimumskrav:

a) Mulighet for registrering av retter i databasen via et web-grensesnitt for administrasjon av APIet heretter referert til som administrasjonssiden.

b) Eksportere statistisk rådata fra et spesifisert tidsrom til administrasjonssiden i form av tabeller eller relevant filformat6.

c) APIet skal ha flere ulike databaser dette inkluderer databaser for; matvarer fra matvaretabellen, retter opprettet av oppdragsgiver, brukerinformasjon, og rapporterte data fra brukere.

d) Innrapportering av data i henhold til registrering av næringsstoffer skal lagres med knytning til brukernavn.

e) Brukernavn og passord skal lagres hashet10 for sikkerhet og anonymitet.

f) Det skal kunne hentes ut matvarer og retter enkeltvis eller som datasett fra APIet med riktig autorisasjon.

2.1.2.2 Ønsket tilleggsfunksjonalitet

g) Brukerinnsendt data skal kunne kontrolleres av APIet og data som vekker mistanke vil forkastes automatisk eller kreve manuell godkjenning. (f. eks. et kaloriinntak på 20 000).

2.1.2.3 Eventuell tilleggsfunksjonalitet:

h) Mulighet til å legge ved bilde i krav [2a].

i) APIet skal kunne logge endringer som er gjort i databasen.

j) Mulighet for administrator å kunne legge inn nye brukere til administrasjonssiden med et valgt adgangsnivå.

k) Krav [2i] utvides til å kunne bruke denne loggen for å gjenopprette tidligere tilstand.

Vedlegg A

6 Hovedprosjekt 2014 - Kost Fakultet for teknologi og design, Høgskolen i Oslo og Akershus

2.2 Ikke-funksjonelle krav

Under hele utviklingen skal det fokuseres på å utvikle en fungerende løsning som ved lansering kan brukes av oppdragsgiver. Dette vil si at tertiærfunksjonalitet vil kunne forsakes for å oppnå dette.

2.2.1 Brukervennlighet:

a) Applikasjonen skal være fullt fungerende uten internettilgang.

b) Applikasjonen skal være på norsk.

c) Applikasjonen skal være intuitiv.

d) Applikasjonen skal gi bruker muligheten til å konfigurere så mange innstillinger som mulig for å kunne skreddersy sin brukeropplevelse.

e) Applikasjonen skal fungere “out of the box” uten konfigurasjon for de fleste brukere.

2.2.2 Effektivitetskrav:

a) Så nært som mulig 100% av alle tunge beregninger skal foregå på server, hvis dette er mulig for den gitte oppgaven.

b) Applikasjonen skal føles som en naturlig del av telefonen og være så rask som situasjonen tillater.

2.2.3 Sikkerhetskrav

a) Det skal være mulig å sikkerhetskopiere all data på databasen.

b) All data som lagres om brukere skal lagres anonymisert og det skal ikke være mulig å knytte denne dataen til en person uten samtykke, og hjelp, fra bruker.

c) APIet skal alltid autentisere brukere av informasjonen lagret i databasen og skal følge normale sikkerhetsstandarder.

2.2.4 Implementasjonskrav:

a) Applikasjonen skal ha minimumsversjon 4.0.3 (Ice Cream Sandwich; API nivå 15)

b) Applikasjonen skal rettes mot den nyeste versjonen11 av Android 4.4 (KitKat; API nivå 19)

c) Applikasjonen skal utvikles i Java12 og XML med Eclipse IDE13 med Android SDK14.

d) Applikasjonen skal lages etter MVC15 mønsteret i tråd med standarden for Android.

e) APIet skal utvikles i Microsoft sitt .net rammeverk16.

f) APIet skal kodes i C#17.

g) APIet skal være RESTful18.

h) APIet skal utvikles i Microsoft Visual Studio 2012 etter MVC mønsteret med entity framework19.

2.2.5 Leveransekrav:

a) Den ferdige applikasjonen skal være klar for lansering i Android Play Store.

b) Det ferdige APIet skal leveres ferdig installert på en Windows server.

c) Windows serveren skal leies av oppdragsgiver og vedkomne skal stå ansvarlig på alle måter i forhold til denne.

d) Det skal ikke foregå vedlikehold eller drift fra oppdragstagers side etter at produktet er levert, med mindre dette avtales spesifikt.

Vedlegg A

7 Hovedprosjekt 2014 - Kost Fakultet for teknologi og design, Høgskolen i Oslo og Akershus

2.2.6 Fremtidig utvidelse av systemet

a) Koden for systemet skal så langt det er mulig håndtere et ubegrenset antall brukere, begrensninger skal evt. ligge i oppdragsgivers valg av serverløsning.

b) Koden skal i aller største grad tilrettelegge for videreutvikling for større funksjonalitet

2.2.7 Lovmessige krav

a) Applikasjonen skal inneholde teksten: "Inneholder data under norsk lisens for offentlige data

(NLOD) tilgjengeliggjort av Matvaretilsynet."

b) Applikasjonen skal opplyse om, og avskrive seg ansvar for, eventuelle feil og mangler som måtte forekomme.

2.2.8 Krav til grensesnitt

a) Applikasjonens utseende skal ligge nært det normale utseende for Android applikasjoner.

b) Det skal være kort vei til de mest brukte funksjonene og det skal, så langt det er mulig, gå an å nå disse innenfor 3 «klikk».

c) Applikasjonen skal benytte seg av et enkelt menysystem som følger brukeren under hele brukerforløpet.

Vedlegg A

8 Hovedprosjekt 2014 - Kost Fakultet for teknologi og design, Høgskolen i Oslo og Akershus

4. Ordliste

1API Her menes: Serversideprogramvare som håndterer forespørsler fra internett, verifiserer identitet, autoriserer databaseaksess, henter ut data fra databasen og sender dette tilbake.

Generelt: Application Programming Interface (API) er et grensesnitt for kommunikasjon mellom programvare. APIet beskriver de metoder som en gitt programvare eller et bibliotek kan kommunisere med.

2web-grensesnitt/ administrasjonsside Her menes: En nettside som henter data fra APIet og presenter dette

for bruker. 3Matvaretabell Mattilsynets matvaretabell som ligger til grunn for

matvaredatabasen. Kan finnes her: http://www.matvaretabellen.no. 4MS Visual Studio Visual Studio er et integrert utviklingsmiljø (IDE) for Microsofts .NET

plattform. 5Retter Her menes: En rett er et objekt som består av to eller flere

ingredienser hentet fra matvaretabellen med et fast mengdeforhold. 6XML XML (Extensible Markup Language) er et universelt og utvidbart

markeringsspråk (språk som kombinerer tekst og ekstra informasjon

om teksten). 7Naturlig enhet Her menes: Den enhet som er mest nærliggende nå man snakker om

en spesifikk matvare. (f. eks. ett glass melk, ett stk. eple, en skive ost) 8Referanseinntak Her menes: Standard referanseinntak for vitaminer og mineraler

samt energibehov (se Harris-Benedikt prinsippet). 9Harris–Benedict prinsippet Er en metode for beregning av en persons basalmetabolisme

(hvilestoffskiftet). 10Hashet En sjekksum, en kort kode som brukes til å sjekke integriteten av

dataofte kalt hash-funksjon. Ikke reversibel, original data kan ikke

hentes ut fra sjekksummen. 11Android versjon Google anbefaler å rette utviklingen mot nyeste versjon av Android

(se http://developer.android.com/guide/practices/compatibility.html for detaljer).

12Java Java er et multiplattform objektorientert programmeringsspråk. 13Eclipse IDE Eclipse er et flerspråklig utviklingsmiljø (IDE) med støtte for utvidet

funksjonalitet ved programvareutvidelser (slik som Android SDK). 14Android SDK Et utviklingsbibliotek for androidplattformen. 15MVC Model View Controller er en måte å dele opp og strukturere koden

på i en applikasjon. 16Microsoft .NET .NET eller .NET Framework er en samling teknologier rundt

programvareutvikling fra Microsoft. 17C# C# er et programmeringsspråk for objekt-orientert programmering,

utviklet av Microsoft, som en del av deres satsing på .NET. 18REST Representational State Transfer, er en programvarearkitektur for

distribuerte systemer som World Wide Web. REST har etter hvert blitt den dominerende designmodellen for web-APIer.

19Entity Framework Er et object-relational mapping (ORM – en konverteringsteknikk for objekter til database) rammeverk. En del av .NET.

Vedlegg A

Forprosjektrapport Hovedprosjekt 2014 Fakultet for teknologi og design, Høgskolen i Oslo og Akershus Presentasjon Tittel: Kost Oppgave: Å utvikle en IT-løsning for innrapportering av data for bruk i forskning, bestående av en Android applikasjon og et API med tilhørende web-grensesnitt, for registrering av matkonsum og uthenting av statistiske rådata. Gruppenummer: 12 Gruppemedlemmer: Jonas Moltzau Martin W. Løkkeberg Veileder: Eva Hadler Vihovde Oppdragsgiver: Studieretning for samfunnsernæring Institutt for helse ernæring og ledelse Fakultet for helsefag Høyskolen i Oslo og Akershus Ansvarlig for oppgaven (HIOA): Asgeir Brevik 483 53 097 Email: Asgeir.Brevik@hioa.no Sammendrag Oppgaven går ut på å utvikle en IT-løsning for innrapportering av data for bruk i forskning ved Instituttet HEL. Denne skal bestå av en Android applikasjon, hvor brukere kan registrere kostholdsvaner basert på mattilsynets matvaretabell, og et API med tilhørende web-grensesnitt utviklet i MS Visual Studio, for registrering av matkonsum og uthenting av statistiske rådata. Systemet skal forenkle forskningsprosessen for forskere i ernæringsmiljøet ved HEL, samt at den skal appellere til vanlige brukere og promotere kostholdsbevissthet. Om oppdragsgiver HIOA Institutt for helse, ernæring og ledelse (HEL) holder til på studiested Kjeller og har om lag 85 ansatte og 1060 studenter tilknyttet instituttets virksomhet. Vår oppgave er forespurt av studieleder ved Samfunnsernæring Asgeir Brevik.

Vedlegg B

For å ha høy kvalitet på undervisningen fokuserer undervisningspersonalet på å holde seg oppdatert innenfor forskning og fagutvikling. Fagmiljøet ved instituttet HEL er aktive innenfor ulike flerfaglige forskningsaktiviteter, og forskningen har et helsefremmende og forebyggende perspektiv. Tilsatte ved instituttet deltar i følgende forskningsgrupper ved Fakultet for helsefag:

• Empowerment • Humane kostforsøk og helseeffekter • Samfunnsernæring • Aldring, helse og velferd

Om oss Vi er to studenter fra ingeniørfag data som har kjent hverandre i mange år og jobbet sammen på en rekke prosjekter helt fra tidlig ungdomsskole til nå. Fordi gruppedynamikken dermed er godt innarbeidet var det et naturlig valg for oss å samarbeide på denne bacheloroppgaven, da det er spesielt viktig at ambisjoner og forventningen til arbeidsmengde er i samsvar. Vi har i alle år vært over middels interessert i data og det som hører til, og det var derfor kort vei fra den iboende interessen til en utdannelse innen IT ved HIOA. Etter å ha jobbet med flere aspekter i og rundt IT har vi tilegnet oss ferdigheter innen flere programmeringsspråk, metodikker og rammeverk. Når vi nå har nådd tredje året av utdannelsen har vi funnet noen favorittspråk og plattformer og for oss er dette helt klart Java, C# .net og Windows. Derfor passet det utmerket når vi fikk muligheten til å jobbe med denne oppgaven som involverer android-programmering i java og server API programmering i C# .net. Dagens situasjon Institutt for Samfunnsernæring driver jevnlig med forskningsprosjekter i henhold til ernæring hvor innsamling av nok kostholdsdata ofte kan være en utfordring. Derfor er vår oppgave å utvikle et system som forenkler og automatiserer deler av denne prosessen. Ved å tilgjengeliggjøre vårt system for offentligheten/større brukermasser via de mest brukte moderne teknologiene, nemlig applikasjoner for mobil, i et intuitivt og brukervennlig format, vil dagens situasjon forenkles for medarbeiderne i forskningsprosjektene. Det er også et poeng at brukerne av appen selv vil få innsikt i deres eget kosthold og at denne appen på den måten kan bidra til folkeopplysning i henhold til ernæring. Appen skal bruke et API basert på mattilsynets matvaretabell, laget av oss. Dette APIet vil bidra med en betydelig verdi for oppdragsgiver, som vil sitte som administrator for dette. Som det første programmeringsvennlige grensesnittet mot denne informasjonen vil dette APIet gjøre det lettere for andre aktører og prosjekter i forskningsmiljøet i Norge å lage sine egne systemer for kostholdopplysning og annen bearbeiding av matvareinformasjon. Mål

- Bidra til enklere informasjonsinnsamling av ernæringsdata. - Å skape lettere tilgang til matvaretabellen.

o API for programmerere o App for menigmann

- Hjelpe brukere med å få oversikt over eget kosthold. o Brukervennlighet i fokus. o Motivere brukere til å bruke appen aktivt.

Vedlegg B

Rammebetingelser - Applikasjonen skal benytte data fra matvaretabellen. - Applikasjonen utvikles for Android i Eclipse med Android SDK. - Nettside og API utvikles i MS Visual Studio.

o Kjøres på Windows server. Løsninger Oppdragsbeskrivelsen gir rom for et forholdsvis enormt utviklingsprosjekt. Oppdragsgiver ville i utgangspunktet fordele oppgaven utover flere grupper og ønsket en IOS app, en Android app, en nettside for brukerne av appen og en mindre backend løsning for forskerne. Fordi det bare var vår gruppe som meldte interesse for prosjektet, og kun to av oss, måtte oppgaven innsnevres til det vi kan klare å utvikle. Ingen av oss har noen erfaring med applikasjonsutvikling så rammeverk og språk må læres fra bunnen av. Vi tenkte umiddelbart på utvikling kun for Android fordi rammeverket er basert på java som vi har god erfaring med, noe som gjør startfasen mye enklere, samt at å begrense oss til en plattform ville gi oss muligheten til å utvikle en fullverdig applikasjon. En annen løsning som vi også diskuterte, var muligheten for å utvikle appen til begge plattformer samtidig. Dette kan gjøres ved hjelp av bl. a. QT Mobile med C++, eller HTML5/Javaskript rammeverk. Vi utforsket disse mulighetene og fant ut at QT mobile krevde et månedsabonnement på 149$. Dette var den plattformen vi kjente oss mest igjen i og den som er mest nær de språkene vi kan, men krever at du utvikler på en Mac for å teste på IOS enheter og altså månedsabonnement. Denne plattformen ble dermed forkastet og vi så på HTML5/Javascript rammeverk. Her testet vi spesifikt XDK fra Intel som virket som det mest ekstensive og robuste verktøyet for denne typen utvikling. Vi innså fort at denne måten å programmere på var svært fremmed for oss, og at den vanskeliggjør bruk av en god del avanserte funksjoner. Applikasjonen utviklet i dette rammeverket måtte ha kjørt i en browser eller en web-frame (hybrid native app) på telefonen som kunne ha gjort appen fremmed for brukere i forhold til native apps. Fordi vi så at dette ville være mer tidkrevende å sette seg inn i, samt at det var vanskelig for oss å se eventuelle fremtidige hindringer, ville vi fått mindre tid til selve funksjonaliteten i appen samt APIet. Derfor virket dette som en dårligere løsning og vi mener at det er bedre å fokusere på én god app som blir brukt, enn to som kanskje ikke blir brukt. Slik vi ser det, er det mest verdifulle for oppdragsgiver, på lang sikt, en backend-løsningen med matvaretabell og innsamlet data, og derfor foreslo vi å utvide denne delen av oppgaven slik at verdien for arbeidsgiver øker. VI forslo derfor at vi kunne utvikle en app for Android samt APIet på server i tillegg til en web-basert administrasjonsløsning for innsamlet informasjon knyttet til APIet, men tilrettelegge for senere IOS utvikling. Dette syntes arbeidsgiver var fornuftig og vi har derfor blitt enige om å gjøre det på denne måten. Etter å ha tatt avgjørelsen om å utvikle for Android har vi laget noen enkle skisser av appen som beskriver følgende foreløpig funksjonalitet:

1. Man skal kunne opprette en bruker med et brukernavn, passord, alder, kjønn og aktivitetsnivå.

2. Man skal kunne se dagens næringsinntak i forhold til referanseverdier på hjemskjermen. 3. Appen skal ha en navigeringsmeny som alltid er tilgjengelig 4. Bruker kan opprette predefinerte måltider og retter basert på matvaretabellen. 5. Man skal kunne søke/bla gjennom gjennom matvarer, retter og måltider. 6. Appen skal fungere lokalt uten nett.

Vedlegg B

7. Appen skal synkronisere mot server ved nettilgang og rapportere anonyme data om brukerens konsthold

Backend-løsningen skal fungere som et API med matvaretabellen som basis. Her skal oppdragsgiver være administrator og han skal kunne hente ut rådata over brukernes innrapporterte kostholdsvaner, basert på ulike uthentingskriterier (bl. a. dato, kjønn, alder, aktvitetsnivå osv.) Vi har ikke sett nærmer på hvilke protokoller APIet skal bruke, men vi ser for oss JSON og XML. Oslo: ____________________________ _____________________________

Jonas Moltzau Martin W. Løkkeberg

Vedlegg B

Prosjektskisse for Hovedprosjekt Data 2014 Oslo, 05.12.13 Tittel: Kostholdsapp Gruppemedlemmer: Jonas Moltzau (s176250) Martin W. Løkkeberg (s176251) Oppdragsgiver: Studieretning for samfunnsernæring Institutt for helse ernæring og ledelse Fakultet for helsefag Høyskolen i Oslo og Akershus Kontaktperson: Asgeir Brevik Studieleder, studieretning for samfunnsernæring Høgskolen i Oslo og Akershus, Fakultet for helsefag, Institutt for helse, ernæring og ledelse Postboks 4 St. Olavs plass 0130 Oslo Mob: 483 53 097 Email: Asgeir.Brevik@hioa.no Beskrivelse: Oppdragsgiveren for vår oppgave er Studieretning for samfunnsernæring ved HIOA og vi mener dermed at nærmere beskrivelse av oppdragsgiver er lite hensiktsmessig i denne sammenhengen. I oppdragsbeskrivelsen fra arbeidsgiver finner vi følgende:

“Ernæringsmiljøet ved Studieretning for samfunnsernæring ved Høyskolen i Oslo og Akershus ønsker å utvikle en iOS og Android app for kostregistrering. Appen bygges opp med den norske matvaretabellen som database. I tillegg til enkeltmatvarene som utgjør matvaretabellen skal det være mulig å registrere hele måltider/retter som også ligger i matvaretabellen.”

Slik vi ser det etter samtale med arbeidsgiver, skal det i dette prosjektet lages 2 apper, en for IOS og en for Android, samt en backend del med database og webgrensesnitt for administrasjon/uthenting av statistikk/data. Som backend tenker vi å bruke ASP.net Web API programmert i MS Visual Studio som kan overføre data til både app og nettside. Nettsiden vil vi helst lage i Visual Studio. Appene lages i XCode og IOS SDK for IOS og Eclipse ADT Bundle/Android Studio for Android. Etter nærmere korrespondanse med kontaktperson har vi spesifisert høyt prioriterte krav/ønsker til prosjektet:

- Appen skal ha mulighet for å registrere konsum av enkle matvarer og drikke, fra den norske matvaretabellen.

- Mulighet til å registrere konsum av enkle "retter" (kombinasjoner av matvarer) - Volumangivelse/mengdeangivelse i naturlig format/standard størrelser. - Visning av grafikk, f.eks. kakediagram, som indikerer prosentvis bidraget av henholdsvis

karbohydrat, protein og fett, til det totale energiinntaket for brukeren. - Mulighet til å vise logget inntak av ulike næringsstoffer i en tabell eller graf til brukeren. - Mulighet til å eksportere logg til database som forskerne kan hente ut data fra. - Mulighet til å lagre data offline.

Vedlegg C

Angående referanseverdier

Vi regner først ut daglig kaloribehov ved hjelp av Harris-Benedicts likning, verdier tatt herfra: http://en.wikipedia.org/wiki/Harris%E2%80%93Benedict_equation Deretter regner vi ut andre behov ut ifra kaloribehovet, basert på anbefalinger funnet her: http://helsedirektoratet.no/publikasjoner/norske-anbefalinger-for-ernering-og-fysisk-aktivitet/Publikasjoner/norske-anbefalinger-for-ernering-og-fysisk-aktivitet.pdf (Referanser referer til sidetall i dette dokumentet)

Antagelser:

Mange verdier er oppgitt i intervaller i kilden, i disse tilfellene har vi tatt utgangspunkt i snittet/midtpunktet, 25%-35% blir eksempelvis 30%. Antar at protein, fett og karbohydrater skal utgjøre 95% av det totale energibehovet, derfor vil: Protein stå for ca. 15% av energi-inntaket (ref. s. 7) Fett stå for ca. 32,5% av energi-inntaket (ref. s. 6) Karbohydrater stå for ca. 52,5% av energi-inntaket (ref. s. 6)

Av karbohydrater skal:

Sukker stå for ca. 18% av Karbohydrat-energien, tilsvarende 10% av det totale energi-inntaket (ref. s. 6)

Kostfiber stå for ca. 4,56% av Karbohydrat-energien, tilsvarende 2,51% av det totale energi-inntaket (ref. s. 6)

Av fett skal:

Mettede fettsyrer stå for ca. 30,77% av Fett-energien, tilsvarende 10% av det totale energi-inntaket (ref. s. 6)

Transfettsyrer stå for ca. 3,08% av Fett-energien, tilsvarende 1% av det totale energi-inntaket (ref. s. 6)

Enumettede fettsyrer stå for ca. 46,15% av Fett-energien, tilsvarende 15% av det totale energi-inntaket (ref. s. 6) Flerumettede fettsyrer stå for ca. 20% av Fett-energien, tilsvarende 24,05% av det totale energi-inntaket (ref. s. 6)

Andre:

Vann ca.30ml per kg, Alkohol ca. 10g (ref. s. 12), Retinol ingen data, Beta-caroten ingen data Vitamin A ca. 80 RAE per MJ (ref. s. 11), Vitamin B6 ca. 0,13 mg per MJ (ref. s. 11)

Vitamin B12 ca. 0,2 μg per MJ (ref. s. 11), Vitamin C ca. 8 mg per MJ (ref. s. 11)

Vitamin D ca. 1,4 μg per MJ (ref. s. 11), Vitamin E ca. 0,9 alfa-TE per MJ (ref. s. 11)

Thiamin ca. 0,12 mg per MJ (ref. s. 11), Riboflavin ca. 0,14 mg per MJ (ref. s. 11)

Niacin ca. 1,6 mg per MJ (ref. s. 11), Folat ca. 45 μg per MJ (ref. s. 11)

Kalsium ca. 100 mg per MJ (ref. s. 11), Jern ca. 1,6 mg per MJ (ref. s. 11)

Natrium ca. 1,9166 mg (ref. s. 12), Kalium ca. 350 mg per MJ (ref. s. 11)

Magnesium ca. 32 mg per MJ (ref. s. 11), Sinc ca. 1,2 mg per MJ (ref. s. 11)

Selen ca. 5,7 μg per MJ (ref. s. 11), Kobber ca. 0,1 mg per MJ (ref. s. 11)

Fosfor ca. 80 mg per MJ (ref. s. 11)

Vedlegg D

Utregningseksempeler (gitt 2400 kcal):

Stoff Utregning Produkt/Sum

Kilokalorier 2400 kcal

Megajoules 2400 kcal * 4.18 KJ/kcal * 0,001KJ/MJ 10 MJ

Kilojoules 2400 kcal * 4.18 KJ/kcal 10 000 KJ

Protein 2400 kcal * 15% ÷ 4.0g/kcal 90g

Fett 2400 kcal * 30% ÷ 9.0g/kcal 80g

Mettet Fett 2400 kcal * 30% * 30% ÷ 9.0g/kcal 24g

Transfettsyrer 2400 kcal * 30% * 3,3% ÷ 9.0g/kcal 2,64g

Enumettede 2400 kcal * 30% * 41% ÷ 9.0g/kcal 32,8g

Flerumettede 2400 kcal * 30% * 25% ÷ 9.0g/kcal 20g

Kolesterol 2400 kcal * 1% ÷ 9.0g/kcal 2600mg

Karbohydrater 2400 kcal * 55% ÷ 4.0g/kcal 330g

Sukker 2400 kcal * 55% * 18% ÷ 4.0g/kcal 59g

Kostfiber 2400 kcal * 55% * 54% ÷ 4.0g/kcal 178g

Stivelse 2400 kcal * 55% * 14% ÷ 4.0g/kcal 46g

Mono-Di sakkarider 2400 kcal * 55% * 14% ÷ 4.0g/kcal 46g

Vedlegg D

Stoff Utregning Produkt/Sum

Vann 75 kg * 30 milliliter/kg 2,25 L

Alkohol 10g

Vitamin A 80 RAE/MJ * 10 MJ 800 RAE

Vitamin B6 0,13 mg/MJ * 10 MJ 1,3mg

Vitamin B12 0,2 μg /MJ * 10 MJ 2μg

Vitamin C 8 mg/MJ * 10 MJ 80 mg

Vitamin D 1 μg/MJ * 10 MJ 10μg

Vitamin E 0,9 alfa-TE/MJ * 10 MJ 9 alfa-TE

Thiamin 0,12 mg/MJ * 10 MJ 1,2mg

Riboflavin 0,14 mg/MJ * 10 MJ 1,4mg

Niacin 1,6 mg/MJ * 10 MJ 16mg

Folat 45 μg/MJ * 10 MJ 450μg

Kalsium 100 mg/MJ * 10 MJ 1000mg

Jern 1,6 mg/MJ * 10 MJ 16mg

Natrium 2550 mg

Kalium 350 mg/MJ * 10 MJ 3500mg

Magnesium 35 mg/MJ * 10 MJ 350mg

Sinc 1,1 mg/MJ * 10 MJ 11mg

Selen 4 μg/MJ * 10 MJ 40μg

Kobber 0,1 mg/MJ * 10 MJ 1mg

Fosfor 80 mg/MJ * 10 MJ 800mg

Vedlegg D

Vedlegg E

Vedlegg E

App for registrering av kosthold basert på matvaretabellen

Ernæringsmiljøet ved Studieretning for samfunnsernæring ved Høyskolen i Oslo og Akershus ønsker

å utvikle en iOS og Android app for kostregistrering. Appen bygges opp med den norske

matvaretabellen som database. I tillegg til enkeltmatvarene som utgjør matvaretabellen skal det være

mulig å registrere hele måltider/retter som også ligger i matvaretabellen.

I tillegg til smarttelefon app er det ønskelig at brukere skal kunne registrer seg på egen nettside for å

få tilgang til, og mulighet til å manipulere egne tall, diagrammer og grafer fra nettleser

(se www.cronometer.com for eksempel på amerikansk system med både app og nettsted). Denne

delen, det vi si design og oppsett av nettsted, kan utgjøre trinn to av utviklingen. Trinn to kan

adresseres i egne prosjekt på et senere tidspunkt, men det er greit at man har dette i mente når man

starter med trinn 1.

Det skal i appen kunne gis feedback, i form av tabeller, til brukeren, hvor samlet inntak for dagen

summeres med hensyn på næringstoffer og kalorier. Appen må laste ned databasen (dvs

matvaretabellen, http://www.matvaretabellen.no/) lokalt slik at det er mulig å logge måltider uten

3G/WiFi. De loggede måltider skal kunne synkes, helst automatisk, ved senere nettilgang.

Appene tenkes brukt i forskning; parallelt med at data helst skal kunne lastes opp til egen profil på

nettet (det blir som sagt trinn 2) må det derfor lages en mulighet for at lagrede data skal kunne

eksporteres (spreadsheet eller txt format). Eksporten kan være på formen send på mail som vedlegg.

Denne muligheten til å eksportere loggede tall må inngå i trinn 1 av utviklingen.

Integrasjon mot sosiale nettverk er ønskelig. Denne integrasjonen kan være på formen dele på

facebook, men det er mulig at de som deltar i et vektreduksjonsforsøk ikke ønsker å dele alt på

facebook, og at et eget lukket forum kan fungere bedre. Beste løsningen på dette området kan

diskuteres. Tanken er dog å åpne for at de som er med på et program kan snakke/chatte med

hverandre online, dele erfaringer og tips, og gjennom denne aktiviteten utvikle en styrkende

lagfølelse. Hensikten er at man åpner for å bruke sosialt press på en positiv måte. Vi er takknemlig

for ideer til hvordan den sosiale integrasjonen best kan organiseres. Integrasjon mot sosialt nettverk

kan utgjøre trinn tre av utviklingen, og kan adresseres i eget prosjekt på et senere tidspunkt, men det

er greit at man har dette i mente fra start. Det er i først omgang interessant å få utarbeidet et godt og

velfungerende fundament, og det utgjør naturlig trinn en i prosjektet.

Oppdragsgiver:

Studieretning for samfunnsernæring

Institutt for helse ernæring og ledelse

Fakultet for helsefag

Vedlegg F

Høyskolen i Oslo og Akershus

For spørsmål kontakt:

Asgeir Brevik

Studieleder, studieretning for samfunnsernæring

Høgskolen i Oslo og Akershus,

Fakultet for helsefag, Institutt for helse, ernæring og ledelse

Postboks 4 St. Olavs plass

0130 Oslo

Pakkelevering:

Kunnskapsveien 55, Rom C 227

2007 Kjeller

Kontor 6484 9230

Mob 4835 3097

Vedlegg F

End-User License Agreement for Kost

This End-User License Agreement (EULA) is a legal agreement between you (either an

individual or a single entity) and the mentioned author (Asgeir Brevik) of this Software for the

software product identified above, which includes computer software and may include

associated media, printed materials, and “online” or electronic documentation (“SOFTWARE

PRODUCT”).

By installing, copying, or otherwise using the SOFTWARE PRODUCT, you agree to be

bounded by the terms of this EULA. If you do not agree to the terms of this EULA, do not

install or use the SOFTWARE PRODUCT.

SOFTWARE PRODUCT LICENSE

Kost is being distributed for personal, non-profit organization, and educational purpose. You

are NOT allowed to make a charge for distributing this Software (either for profit or merely to

recover your media and distribution costs) whether as a stand-alone product, or as part of a

compilation or anthology, nor to use it for supporting your business or customers.

1. GRANT OF LICENSE. This EULA grants you the following rights: Installation and Use.

You may install and use an unlimited number of copies of the SOFTWARE PRODUCT.

Reproduction and Distribution. You may not reproduce and distribute copies of the

SOFTWARE PRODUCT.

2. DESCRIPTION OF OTHER RIGHTS AND LIMITATIONS.

Limitations on Reverse Engineering, Decompilation, Disassembly and change (add, delete or

modify) the resources in the compiled the assembly. You may not reverse engineer,

decompile, or disassemble the SOFTWARE PRODUCT, except and only to the extent that

such activity is expressly permitted by applicable law notwithstanding this limitation.

Update and Maintenance

Kost upgrades are FREE of charge.

Separation of Components.

The SOFTWARE PRODUCT is licensed as a single product. Its component parts may not be

separated for use on more than one smartphone.

Software Transfer.

You may permanently transfer all of your rights under this EULA, provided the recipient

agrees to the terms of this EULA.

Termination.

Without prejudice to any other rights, the Author of this Software may terminate this EULA if

you fail to comply with the terms and conditions of this EULA. In such event, you must

destroy all copies of the SOFTWARE PRODUCT and all of its component parts.

Vedlegg G

3. COPYRIGHT.

The SOFTWARE PRODUCT is protected by copyright laws and international treaty

provisions. Therefore, you must treat the SOFTWARE PRODUCT like any other copyrighted

material.

LIMITED WARRANTY

NO WARRANTIES.

The Author of this Software expressly disclaims any warranty for the SOFTWARE

PRODUCT. The SOFTWARE PRODUCT and any related documentation is provided “as is”

without warranty of any kind, either express or implied, including, without limitation, the

implied warranties or merchantability, fitness for a particular purpose, or noninfringement.

The entire risk arising out of use or performance of the SOFTWARE PRODUCT remains with

you.

NO LIABILITY FOR DAMAGES.

In no event shall the author of this Software be liable for any special, consequential,

incidental or indirect damages whatsoever (including, without limitation, damages for loss of

business profits, business interruption, loss of business information, or any other pecuniary

loss) arising out of the use of or inability to use this product, even if the Author of this

Software is aware of the possibility of such damages and known defects.

Vedlegg G