HOVEDPROSJEKT. Studieprogram: Ingeniørfag-data Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo

Transkript

1

2 PROSJEKT NR Studieprogram: Ingeniørfag-data Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Lukket Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Kost DATO ANTALL SIDER / BILAG 125 PROSJEKTDELTAKERE Jonas Moltzau s Martin Witsø Løkkeberg s 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

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

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

5 Innhold Innhold DEL 1 PRESENTASJON OM GRUPPEN OPPGAVEN Oppdragsgiver Bakgrunn Mål SLUTTPRODUKT App API og Administrasjonsside DEL 2 PRODUKT APPLIKASJONEN Login Login-skjermen Rolle og funksjonalitet Hjemskjermen Anbefalt energifordeling og hjemskjermen generelt Din energifordeling Vanskelighetsgrad Utforsk Beskrivelse Skjermens rolle Spesifikt for måltider Vis-skjermen Felles for alle vis-skjermene Unikt for matvarer kategorien Unikt for retter kategorien Unikt for måltider og oppskrifter kategoriene Søking Kort om søk Spist Historikk og navigasjon deretter Selve listen Liste over næringsstoffer Kakediagrammenes funksjon og farge Nytt måltid Hva kan man legge til? Tittel og liste Knapperaden Navigasjon Menylinje Nedtrekksmenyen Innstillinger Nettverk og oppdateringer Generelle innstillinger Bruker Logg ut NETTSIDE Generelt Forside API Hjelpesider Innlogging Administrasjonsfunksjonalitet Matvarer Enheter... 37

6 Innhold Retter og kategorier Versjonsnummer Rådata Tokens API Ressurser Matvarer og Retter Enheter Rettkategorier Andre Tilgang og bruk Autorisering Filtrering Bruk Responskoder PROGRAMSTRUKTUR Databasedesign Matvarer og Enheter: App og Server Retter: App og Server Spiste matvarer og rapportering: App og Server Måltider: App UserEaten: App Komplette entitetsdiagrammer over databasene med attributter JSON MVC Appstruktur Generelt om Android Vår struktur Serverside-struktur Database MSSQL og Entity Framework Code First REST API PERSONVERN OG ANONYMITET DEL 3 UTVIKLING KONSEPTUTVIKLING Logo og navn Navnet Kost Logo Slagord og helheten Sammendrag Videreutvikling og helhet Tidlig designprosess og skisser Innehold Skissenes rolle UTVIKLINGSHISTORIER Spist kakediagram Lerret og størrelse Fargen Tekst Vår erfaring Søkefunksjonalitet Original versjon Første forbedring Andre forbedring Tredje forbedring Utfordringer med flere Cursors Den endelige løsningen Oppdateringer Første iterasjon Blokking av hovedtråden Feiltesting... 73

7 Innhold Andre iterasjon Konklusjon TESTING Valg Utviklertesting Brukertesting Vår erfaring Videre testing OM VERKTØY Selvutviklede støtteprogrammer FolderDiff MatvaretabellImporter UsernameHasher Verktøysoversikt Eclipse MS Visual Studio SQLite Spy Fiddler Microsoft Office Adobe Photoshop Gliffy Dropbox Skype Trello DEL 4 PROSESS TOLKNING OG DEFINISJON AV OPPGAVEN Førsteinntrykk og møte med oppdragsgiver Begrense og definere oppgaven Plattform og rammeverk KRAVSPESIFIKASJONEN Kravspesifikasjonens rolle Under arkitektur og planlegging Under Utviklingsfasen Under Dokumentasjonen Ble kravspesifikasjonens krav oppfylt? PLANLEGGING OG UTVIKLINGSMETODIKK Samarbeid og kommunikasjon Valg av metodikk Smidig utvikling XP Prosjektstyring Trello Arbeidsplan Prosessnettside og dagbok Databasediagrammenes rolle i utviklingen DEL 5 AVSLUTNING DET FERDIGE PRODUKTET Videre utvikling Produktets verdi Verdi for oppdragsgiver Verdi for brukerne ORD FRA OPPSRAGSGIVER LÆRINGSUTBYTTE KONKLUSJON ORDLISTE KILDER VEDLEGG

8 Presentasjon 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. 6

9 Presentasjon 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 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 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 7

10 Presentasjon 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, Vedlegg E.) 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. 8

11 Presentasjon 1.3 Sluttprodukt Som en introduksjon og overblikk over sluttproduktet er det naturlig å starte med et diagram som viser systemet i sin helhet. Figur 1 - Oversiktsdiagram 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. 9

12 Presentasjon 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 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 Figur 2 - Skjermskudd av visningssiden for en matvare i appen. 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. Figur 3 - Listen over matvarer på administrasjonssiden. Både app, administrassjonside og API vil bli gjennomgått i detalj i del 2 om produktet. 10

13 Produkt 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. 11

14 Produkt 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 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 Login-skjermen Figur 4 - Login-skjermen og dialogen for å registrere bruker 12

15 Produkt 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 internetttilkobling. 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) 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 for mer informasjon om innstillinger). Hvilke oppdateringer man har lastet ned og måltider man har laget, vil 13

16 Produkt 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 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 14

17 Produkt 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 innstillingerskjermen som vi vil gå inn på senere i avsnitt 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 , men også fordi diagrammet da ville blitt vanskeligere å lese 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 energifordelingdiagrammet 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 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. 15

18 Produkt 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 Beskrivelse Figur 6 - Utforsk skjermen før og etter et trykk på «Matvarer» kategorien 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) 16

19 Produkt Matvarer Retter Mine måltider Oppskrifter Beskrivelse Alle matvarer i matvaretabellen som er inneholdt i appen, samt enheter som er hentet fra APIet som tilhører hver matvare. Alle matvarer og retter som oppdragsgiver registrer i hans administrasjonsløsning. Disse kommer som oppdateringer til appen. Dette er brukerens egenkomponerte måltider og retter, som kan inneholde matvarer fra både rett- og matvarekategoriene og faktisk også måltider. 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å 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 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 touchapplikasjoner 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 17

20 Produkt 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. Figur 8 Vis-skjermene for henholdsvis matvarer, retter og måltider 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 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 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 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. 18

21 Produkt 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 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 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 ). 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 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. 19

22 Produkt 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 20

23 Produkt 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. Figur 11 - Søkefunksjonene med forslag til venstre og selve søkeskjermen til høyre 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. 21

24 Produkt 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. Figur 12 - Spist-skjermen for dagen i dag og for den 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 samme dag til 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. 22

25 Produkt Denne listen viser gårsdagens inntak fra kl til 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 til den datoen (her den 12.05) 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. Figur 13 - Dialogen for å endre mengden av spist matvare 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 Figur 14 - Ikonet endres på oppføringer i listen når man holder inne på dem 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 , 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. 23

26 Produkt 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 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 Figur 15 - Kakediagrammene på spist skjermen 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 Det mer oppsiktsvekkende aspektet ved disse diagrammene er fargen. Her har vi implementert et komplekst fargesystem som er grundig beskrevet i avsnitt 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 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. 24

27 Produkt 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. Figur 16 - Skjermene for opprett måltid og opprett oppskrift med 2 matvarer lagt til 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å 25

28 Produkt 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 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 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 spistskjermen 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. Figur 17 - Dialogen for spis-knappen 26

29 Produkt 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. Figur 18 - "Er du sikker?" -dialogen for fjern alle knappen Figur 19 - Dialogen for å lagre et måltid 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

30 Produkt 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. Figur 20 - Til venstre er tilbake-knappen og til høyre ser vi opp-knappen. Bildet er hentet fra android.com Menylinje Figur 21 - Applikasjonens menylinje. Her navigert til Utforsk-skjermen 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 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 ) 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 22 - Nedtrekksmenyen 28

31 Produkt 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 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. Figur 23 - Innstillinger-skjermen. Første del til venstre andre del til høyre. 29

32 Produkt 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 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. 30

33 Produkt 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. Figur 24 - Dialogen for valg av standard næringsverdier. 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. Figur 25 - Undermenyen for referanseverdi innstillingen 31

34 Produkt 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 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. Figur 26 - Dialogen for å endre verdiene for protein, fett og karbohydrat 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. Figur 27 - Dialogboksen for å endre aktivitetsnivå. Figur 28 - Varseldialogen for utlogging 32

35 Produkt 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 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 og hostes hos godaddy.com, men kan i praksis hostes på en hvilken som helst nyere Windows Server med støtte for Microsoft IIS. Figur 29 - Sidekart over administrasjonssiden 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 30 - Skjermskudd av forsiden 33

36 Produkt 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 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 34

37 Produkt 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. Figur 32 - Skjermskudd av innloggingssiden 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 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 Figur 33 - Navigeringsmeny 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. 35

38 Produkt 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 36

39 Produkt Enheter Som nevnt, i punkt 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 Figur 35 - Skjermskudd av nettsidens enhetsoversikt 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 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. 37

40 Produkt 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 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. 38

41 Produkt 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. Figur 37 - Skjermskudd av nettsidens versjonskontroll 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 38 - Skjermskudd av øk versjon side 39

42 Produkt 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. Figur 39 - Skjermskudd over rådataeksportering 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 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 40

43 Produkt 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 ) 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 JSONformat, mer om dette formatet og hvorfor vi valgte det finnes i segmentet om programstruktur, avsnitt 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å Matvarer og Retter APIet tilgjengeliggjør store deler av informasjonen som finnes i Mattilsynets matvaretabell, bl.a. en liste på ca 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 Figur 41 - Matvare og rett JSON-objekt 41

44 Produkt 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. Retterkategoriene kan også av den grunn hentes ut med et eget API-kall 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 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 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 Figur 42 - Enhet JSON-objekt Figur 43 - Kategori JSON-objekt 42

45 Produkt 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 Matvarer og Retter har også hver sine POSTmetoder 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 43

46 Produkt 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 alle de ulike ressursene starter med denne adressen 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 om nettsiden har ethvert token et bestemt tilgangsnivå og gyldighetsperiode. En typisk forespørsel kan se slik ut: GET HTTP/1.1 Authorization: basic YsCoLSU+kbD5pjW0onA+X1RJlvYJBCYDmusj8H0RbFE= (Tokenet over gir full lesetilgang og kan brukes frem til 10.juli 2014) 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 ~/Food?$filter=Kilocalories gt 90 ~/Food?$orderby=name_no ~/Food?$orderby=name_no&$top=10 ~/Food?$filter=categoryName_no eq Kaker ~/Food?$filter=Fat lt 20&$orderby=Fat Resultat Matvarer med kaloriinnhold over 90kcal Alle matvarer sortert etter navn De 10 første matvarene sortert etter navn Matvarer i kategori Kaker. Matvarer med mindre enn 20g fett, sorter etter fettinnhold 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 44

47 Produkt Responskoder Hvis et API kall er vellykket vil serveren svare med en respons med statuskode 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 45

48 Produkt 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 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 ble 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 46

49 Produkt 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 ). Figur 48: Databasediagram, Retter 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 49: Databasediagram, spist og rapporter 47

50 Produkt 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. Figur 50: Databasediagram, Måltider 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 Helmelk (200 gram) Eplekake (250 gram) FoodEaten Helmelk (200 gram) Epler (100 gram) Sukker ( 30 gram) Smør ( 40 gram) Egg (50 gram)...osv 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. 48

51 Produkt Komplette entitetsdiagrammer over databasene med attributter App: 49

52 Produkt Server: 50

53 Produkt 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 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 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 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. 51

54 Produkt 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. Figur 51 - Applikasjonens lagstruktur og kommunikasjonsmønster 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. 52

55 Produkt Figur 52 - Oversiktsdiagram over appens aktiviteter 53

56 Produkt 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. 54

57 Produkt KLASSE net.kost: DatabaseHelper DatabaseUpdater KostSettings NetworkHelper ReporterHelper ServerUserHelper SqlNames SuggestionContentProvider UsersHelper net.kost.activites: AddMealActivity DishBrowserActivity FoodBrowserActivity MealBrowserActivity DisplayActivity DishDisplayActivity FoodDisplayActivity MealDisplayActivity HomeActivity LoginActivity OverviewDayActivity SearchActivity SearchResultsActivity SetPreferenceActivity net.kost.views: BListView BScrollView PieView TriPieView BESKRIVELSE Hjelpeklasse for databaseinteraksjon og opprettelse Hjelpeklasse for henting av oppdateringer fra APIet Implementerer Runnable 10 for å kunne kjøres asynkront Hjelpeklasse for interaksjon med preferansefiler, lagrer brukerens preferanser. Hjelpeklasse for nettverkskommunikasjon Klasse som sender brukerstatistikk til server, implementerer Runnable Hjelpeklasse for oppretting av ny bruker på server og innlogging av bruker mot API. Klasse med Enums og Konstanter for navn på databasekolonner Hjelpeklasse for å hente ut søkeresultater fra databasen Hjelpeklasse for opprettelse av nye brukere, utregning av deres kaloribehov, etc. Aktivitet for oppretting av nye måltider Aktivitet for utforskning av Retter Aktivitet for utforskning av Matvarer Aktivitet for utforskning av Måltider og Oppskrifter Superklasse for visningsklasser Aktivitet for visning av retter Aktivitet for visning av matvarer Aktivitet for visning av måltider Aktivitet for visning av hjemskjerm Aktivitet for visning av login skjerm Aktivitet for oversikt over hva en bruker har spist Aktivitet for utforskning av databasen Aktivitet for visning av søkeresultater og live-search Aktivitet for visning av innstillinger-vindu Klasse som fasiliterer bounce i lister som vises i ulike aktiviteter Klasse som fasiliterer bounce i scrollbare aktiviteter Klasse som tegner kakediagrammer Klasse som tegner tredelte kakediagrammer 55

58 Produkt 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 56

59 Produkt 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: 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. 57

60 Produkt 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; 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 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. 58

61 Utvikling 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. 59

62 Utvikling 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 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 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 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 55 - Førsteutkast til logo Figur 54 - Logo inkorporert i navnet på systemet 60

63 Utvikling 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) 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 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 61

64 Utvikling 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 Figur 57 - Skjermbilde fra 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 62

65 Utvikling 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. Figur 59 - Tidlig skisse nr. 1 av aktivitetene Spis, Hjem og matvare i applikasjonen 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 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. 63

66 Utvikling 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 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. Figur 60 - Spist aktiviteten slik den ser ut nå 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. 64

67 Utvikling Figur 61 - Koden for å tegne hvert enkelt kakediagram 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 og 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 og 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 og 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 og er dagen over og fargen vil være lilla. 65

68 Utvikling 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 Figur 62 - Algoritmen for å regne ut tekstposisjon over diagrammene 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 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. 66

69 Utvikling 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 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 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 67

70 Utvikling 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 Figur 64 - Skjermskudd av søkeforslag i app Denne sørger for at Apple, Norwegian, raw dukker opp før Apples, dried som igjen dukker opp før Pineapple, canned, in syrup 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. 68

71 Utvikling 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 Figur 65 - Skjermskudd av søk i app 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 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. 69

72 Utvikling 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. Figur 66 - Javakode for deler av MultiCursorAdapter-algoritmen 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 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 JSONobjekter 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

73 Utvikling 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). 71

74 Utvikling Figur 68 - Aktivitetsdiagram over de forskjellige stegene under en oppdatering 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, retterkategorier 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. 72

75 Utvikling 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 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 Andre iterasjon Figur 69 - Oppdateringsdialogen 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 73

76 Utvikling 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 74

77 Utvikling 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 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) 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 75

78 Utvikling 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 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) Vår erfaring Etter hvert som systemet ble større og større og mer av funksjonaliteten kom på plass Figur 72 - Eksempel på tilbakemelding og svar fra testbruker 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. 76

79 Utvikling 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 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. 77

80 Utvikling 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 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 FolderDiff Fordi vi ofte jobbet med lokale kopier av prosjektene, som ved endt arbeidsøkt skulle synkroniseres til felles prosjektmappe i Dropbox (se avsnitt ), 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#. Figur 73 - Skjermskudd av FolderDiff som sammenligner to mapper 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 78

81 Utvikling tabell med søkeforslag (se avsnitt 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 backendløsningen. Programmet ble skrevet i MS Visual Studio i C#. Figur 74 - Skjermskudd av MatvaretabellImporter 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. 79

82 Utvikling 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 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 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 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 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 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) 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. 80

83 Utvikling 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 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 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 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 Trello Dette programmet er en essensiell del av prosessen og vil bli beskrevet i avsnittet om prosjektstyring

84 Prosess 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. 82

85 Prosess 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 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 , 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 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 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. 83

86 Prosess 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 Kravspesifikasjonens rolle Kravspesifikasjonens rolle varierte i forhold til hvilken fase av prosjektet vi befant oss i. Derfor er det naturlig å oppdele dette avsnittet deretter 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 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 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 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. 84

87 Prosess 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 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 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. 85

88 Prosess 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) 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. Parprogrammering 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. 86

89 Prosess Prosjektstyring 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. Figur 75 - Utdrag fra Trello-prosjektet. Viser listen «Aktuelt for Asgeir» og «Done» 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 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 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. 87