i

Roommates

En applikasjon for gjre bofellesskap enklere.

Gruppedeltakere / Real Kode:

Gjermund Bjaanes,

Johann Eckhoff og

Katrine Myklevold

ii

Hovedoppgave

Gruppen har utviklet en mobil applikasjon. Applikasjonen brukes for kommunikasjon i

samboersituasjoner. Man kan sende notater til hverandre, fre utlegg og lage huskelister.

Dette er organisert slik at brukerne kan logge seg inn. Disse brukerne kan knyttes opp mot en

husholdning, hvor all informasjon som blir postet, blir delt med de andre medlemmene.

SAMMENDRAG

DA-2014-02 OPPGAVE NR

TILGJENGELIGHET

PEN

ETTER AVTALE

KONFIDENSIELL

Besksadr.: Raveien 215 3184 Borre Tlf: 33031000, Fax: 33031100

Institutt for ingenirutdanning i Vestfold

Roommates - En applikasjon for gjre bofelleskap enklere.

NORSK OPPGAVETITTEL

Roommates - An application to make shared housing easier.

ENGELSK OPPGAVETITTEL

75

DATO LEVERT

ANTALL SIDER

Gjermund Bjaanes

Johann Eckhoff

Katrine Myklevold

FORFATTER(E)

Egen

OPPDRAGSGIVER

Veileder: Thomas Nordli

REF. /VEILEDER(E)

Applikasjon, Multiplattform, Skylsning

3 STIKKORD

iii

SAMMENDRAG (forts.)

Applikasjonen synkroniserer data over skyen ved hjelp av et back-end-system som heter

Parse. Dette er et system med en NoSQL-database, sttte for push-meldinger og tjenerside-

kode. Her ligger databasen hvor alle brukerdata er lagret, samt tjenerside-kode for utfre

visse oppgaver. Applikasjonen er laget og testet for brukes p alle enheter som kjrer iOS,

samt mobiltelefoner som kjrer Android 4.0 og oppover.

Gjennom prosjektet er det blitt brukt en systemutviklingsmetode som heter inkrementell

utvikling. Denne metoden gr ut p at systemet leveres i inkrementer, hvor ny funksjonalitet

blir lagt til for hvert inkrement. Applikasjonen er utviklet i tre inkrementer.

Gruppen har gjennom prosjektet ftt kunnskap innen programmering mot Android og iOS,

samt bruk av 3. parts biblioteker og dets dokumentasjoner. Gruppen har ogs tilegnet seg

erfaring med strre prosjektarbeid og metoder rundt dette.

For videre utvikling er det planlagt gi applikasjonen ut p Apple App Store og Google Play.

Dette krever at det blir satt hyere krav til applikasjonens kvalitet. Da er det behov for nye

runder med beta-testing, samt utarbeidelse av en konomisk plan for hvordan fremtidige

utgifter til drift av back-end skal finansieres.

iv

Skjemaet skal leveres sammen med besvarelsen.

Obligatorisk erklring Jeg erklrer herved at min:

Eksamensbesvarelse i emnekode: FE-BAC3000 Fakultet: TekMar

1. er utfrt av undertegnede. Dersom det er et gruppearbeide, blir alle involverte holdt ansvarlig og alle skal undertegne blanketten.

2. ikke har vrt brukt til samme/en annen eksamen ved HVE eller et annet institutt/ universitet/hgskole innenlands eller utenlands.

3. ikke er kopi eller avskrift av andres arbeid, uten at dette er korrekt oppgitt.

4. ikke refererer til eget tidligere arbeid uten at dette er oppgitt.

5. har oppgitt alle referanser/kilder som er brukt i litteraturlisten.

Jeg/vi er kjent med at brudd p disse bestemmelsene er betrakte som fusk og

behandles i hht. 18 i Forskrift om eksamen og studierett ved HBV og U-loven Kap. 4

4-7.

Dato: Sted:

Underskrift1: Kand.nr.:

Ved gruppebesvarelse m alle gruppas deltagere undertegne:

Underskrift: Kand.nr.: Underskrift: Kand.nr.:

Underskrift: Kand.nr.:

1 Hvis erklringen leveres inn elektronisk via Fronter er underskrift ikke ndvendig, skriv da inn navn.

v

Hovedprosjektets tittel:

Roommates - En applikasjon for gjre bofellesskap enklere.

Forfatternes navn:

Gjermund Bjaanes, Johann Eckhoff og Katrine Myklevold

Kurs/avdeling:

Ingenirfag, Datateknikk. Avdeling TekMar

Dato: _______________________

Rett til innsyn, kopiering og publisering av hovedprosjekt

Biblioteket og avdelingene fr ofte foresprsler om kopi eller innsyn i hovedprosjekt. Biblioteket nsker gjre gode hovedprosjekt tilgjengelig ved publisere dem i papirutgave og legge dem p internett. Hgskolen trenger studentenes tillatelse til dette.

Hovedprosjektet vil fortsatt vre forfatterens ndsverk med de rettigheter det gir.

Hgskolens bruk vil ikke omfatte kommersiell bruk av studenters hovedprosjekt.

Tillater du/dere at din/deres hovedprosjekt blir publisert bde i papir og nettutgave ?

___ ja ___ nei

Signatur av alle forfattere:

vi

Forord Denne rapporten er utarbeidet som en del av eksamineringen av FE-BAC3000, Bachelor oppgave.

Hensikten med denne rapporten er vise hvordan prosjektet har blitt gjennomfrt, hvordan

systemet er satt sammen, hvilke utfordringer som har oppsttt underveis, hvordan disse er hndtert

og hva resultatet av prosjektet ble.

Rapporten er utarbeidet av prosjektgruppen: Gjermund Bjaanes, Johann Eckhoff og Katrine

Myklevold. Vi er alle studenter ved Ingenirfag, Datateknikk, Hgskolen i Buskerud og Vestfold.

Takk til Vi nsker takke vr veileder gjennom prosjektet, Thomas Nordli, for hjelp med tekniske

sprsml, konstruktiv kritikk og veiledning generelt underveis.

Vre dyktige sprkvaskere: Astrid Bjaanes og Roald Bjaanes som har hjulpet oss med f

rapporten p et bedre sprklig niv.

Under betatesting har vi hatt god hjelp av Marlene Angelica Sjonsti Bjrnsen og dne Aalmo. De

har testet applikasjonen vr og gitt konstruktive tilbakemeldinger.

Til slutt vil vi takke Paul Hegarty fra Stanford University. Vi har ikke hatt direkte kontakt med han,

men han har likevel hjulpet oss veldig med opplringen i utvikling til iOS. Hans forelesninger som

ligger tilgjengelig p nettet har srget for en solid forstelse av plattformen. Den inspirasjon han

har gitt oss, kan ikke verdsettes hyt nok.

vii

Innholdsfortegnelse

Forord ............................................................................................................................... vi

Takk til .............................................................................................................................. vi

1 Innledning ................................................................................................................... 2

1.1 Bakgrunn for oppgaven ........................................................................................ 2

1.2 Problemstilling ...................................................................................................... 2

1.3 Problemformulering .............................................................................................. 2

1.4 Mlformulering ..................................................................................................... 3

1.4.1 Prosjektml ................................................................................................... 3

1.4.2 Produktml .................................................................................................... 3

1.4.3 Prosessml ................................................................................................... 3

1.5 Rapportens oppbygning ....................................................................................... 3

2 Kravspesifikasjon ........................................................................................................ 4

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

2.2 Ikke-funksjonelle krav ........................................................................................... 8

3 Valg av teknologi ......................................................................................................... 9

3.1 Valg av plattformer ............................................................................................... 9

3.2 Valg av back-end ................................................................................................. 9

4 Designspesifikasjon ...................................................................................................10

4.1 Systemoversikt ....................................................................................................10

4.2 Systemarkitektur .................................................................................................10

4.3 Datadesign ..........................................................................................................11

4.3.1 Role ..............................................................................................................13

4.3.2 Household ....................................................................................................13

4.3.3 User .............................................................................................................14

4.3.4 Note .............................................................................................................14

4.3.5 Event ............................................................................................................15

4.3.6 Invitation .......................................................................................................16

4.3.7 TaskList ........................................................................................................16

4.3.8 TaskListElement ...........................................................................................17

4.3.9 Installation ....................................................................................................17

4.3.10 Expense .....................................................................................................18

5 Prosess og metoder ...................................................................................................19

5.1 Utvikling ..............................................................................................................19

viii

5.1.1 Utviklingsmodell ...........................................................................................19

5.1.2 Kodestandard ...............................................................................................20

5.1.2.1 Navnsetting ............................................................................................20

5.1.2.2 Innrykk ....................................................................................................21

5.1.2.3 Krllparentes-posisjon ............................................................................21

5.1.3 Versjonskontroll ............................................................................................22

5.1.4 Utviklingsverkty ..........................................................................................22

5.1.4.1 Integrerte utviklingsmiljer (IDE) .............................................................22

5.1.4.2 Brukergrensesnittmodellering .................................................................24

5.1.4.3 Diagrammer ............................................................................................24

5.1.5 Testing .........................................................................................................25

5.1.5.1 Enhetstesting ..........................................................................................26

5.1.5.2 Systemtesting .........................................................................................28

5.1.5.3 Godkjenningstesting ...............................................................................28

5.2 Prosjekt ...............................................................................................................29

5.2.1 Gruppestruktur .............................................................................................29

5.2.2 Evernote .......................................................................................................29

5.2.3 Gantt-diagram ..............................................................................................30

5.2.4 Prosjektstyringsverkty ................................................................................31

6 Resultat......................................................................................................................31

6.1 Produkt ...............................................................................................................31

6.1.1 Produktml ...................................................................................................31

6.1.2 Kildekode .....................................................................................................31

6.1.2.1 Samtidighet (Concurrency) .....................................................................32

6.1.2.2 Facebook ................................................................................................32

6.1.2.3 iOS .........................................................................................................33

6.1.2.4 Cloud Code ............................................................................................39

6.1.2.5 Android ...................................................................................................40

6.1.3 Brukergrensesnitt .........................................................................................46

6.1.3.1 Applikasjonens Innhold ...........................................................................47

6.1.3.2 Navigasjon ..............................................................................................48

6.1.3.3 Fonts og farger .......................................................................................48

6.1.3.4 Forskjeller ...............................................................................................49

6.2 Prosjekt ...............................................................................................................51

6.2.1 Prosjektml ..................................................................................................51

6.2.2 Tidsbruk .......................................................................................................51

7 Konklusjon .................................................................................................................53

ix

7.1 Hvis gruppen startet p nytt.................................................................................53

7.2 Veien videre ........................................................................................................53

8 Litteraturliste ..............................................................................................................55

9 Begrepsliste ...............................................................................................................59

10 Vedlegg ....................................................................................................................61

11 Appendiks - Bakgrunnsteori .....................................................................................62

11.1 iOS ....................................................................................................................62

11.1.1 Brukergrensesnitt .......................................................................................62

11.1.2 Versjoner ....................................................................................................62

11.1.3 ObjectiveC ................................................................................................62

11.1.3.1 Syntaks .................................................................................................63

11.1.4 iOS Software Development Kit ...................................................................65

11.1.4.1 Rammeverk ..........................................................................................65

11.1.4.2 SDK Innhold: Abstraksjonslag ..............................................................65

11.1.5 Apples App Store .......................................................................................67

11.2 Android ..............................................................................................................67

11.2.1 Brukergrensesnitt .......................................................................................68

11.2.2 Versjoner ....................................................................................................68

11.2.3 Java ...........................................................................................................68

11.2.3.1 Dalvik Virtual Machine ..........................................................................68

11.2.3.2 Syntaks .................................................................................................68

11.2.4 XML Extensible Markup Language ..........................................................69

11.2.5 Android Software Development Kit .............................................................69

11.2.5.1 Arkitektur ..............................................................................................70

11.2.6 Google Play ................................................................................................71

11.3 Parse.................................................................................................................71

11.3.1 Teknologi ....................................................................................................71

11.3.2 Sikkerhet ....................................................................................................71

11.3.2.1 Autentisering.........................................................................................72

11.3.2.2 Konfidensialitet .....................................................................................72

11.3.2.3 Autorisasjon ..........................................................................................72

11.3.3 NoSQL .......................................................................................................72

11.4 Versjonskontroll med Git ...................................................................................73

Side 2 av 75

1 Innledning

1.1 Bakgrunn for oppgaven Prosjektet er ikke gitt av en arbeidsgiver, men er i stedet en id formet og utviklet av

prosjektgruppen.

1.2 Problemstilling Hvordan lage en helhetlig lsning/applikasjon for praktiske problemstillinger knyttet til

samboerskap, p tvers av plattformer?

1.3 Problemformulering I valget av oppgave bestemte prosjektgruppen seg for se p problemstillinger i forhold til

kryssplattformutvikling, lagring av data i skyen og mobile applikasjoner. Gruppen oppdaget et

behov alle hadde i forhold til samkjring av aktiviteter knyttet til samboerskap. Dette er noe veldig

mange studenter m forholde seg til, og gruppen bestemte seg derfor for utforske disse omrdene

og det som mtte dukke opp underveis i forhold til dette.

Samtidig s gruppen en mulighet til gjre et prosjekt der det kunne trekkes mange paralleller til

andre programfag fra studiet og dermed ta i bruk kunnskap som er opparbeidet. Gruppen nsker

blant annet bruke formelle systemutviklingsmetoder for effektivisere og kvalitetssikre arbeidet.

Gruppen nsket ogs se p muligheten for flere niver med testing. Det var nsket fokusere p

enhets-testing, automatisk testing og manuell testing (etterhvert ogs med utvidet publikum for

Alpha/Beta-testing). Dette er kunnskap og ferdigheter som mtte tilegnes bde fr og underveis i

prosjektet. Det var nskelig med et godt testet og solid sluttprodukt.

Som tidligere nevnt ville gruppen gjre et prosjekt knyttet til kryssplattformutvikling og lagring av

data i skyen. Valget falt p lage en mobilapplikasjon til de to strste mobilplattformene: Android

og iOS. Her valgte gruppen se p utfordringer knyttet til utvikle til to plattformer samtidig,

spesielt knyttet til kode og design. I forhold til skylagring ville gruppen bruke et ferdig BaaS-

system (Back-end as a Service) med ferdige rammeverk for de forskjellige utviklingsplattformene

som er valgt bruke.

Selve applikasjonen var tenkt som en roommates-app for samboere/studenter. Denne applikasjonen

skulle inneholde handleliste, utlegg, vaskelister, felles beskjeder etc. Dette er aktiviteter som de

fleste som er i samboerskap eller bofellesskap kan ha nytte av ha sentralisert og lett tilgjengelig.

Dette er ogs et behov som ikke er srlig godt dekket av andre tilbud p markedet per i dag. Det

finnes andre som har gjort forsk p dette, men de er etter gruppens mening ikke srlig gode.

Eksempler p applikasjoner gruppen har prvd som prver tilby det samme er Roommat.es til

iOS, og HomeSlice til Android og iOS. Ingen av disse applikasjonene dekker alle behovene

gruppen har, og gruppen mener problemet kan lses p en bedre mte enn det som allerede er gjort.

Side 3 av 75

1.4 Mlformulering

1.4.1 Prosjektml Gruppen nsket med dette prosjektet utvikle et produkt som fungerer og som kan brukes til

daglig. Systemet skulle synkronisere over skyen, vre tilgjengelig for s mange brukere som mulig

og vre lett bruke. Erfaringen gruppen nsket tilegne seg i dette prosjektet, ville vre veldig

relevant for arbeidslivet og gjre gruppens medlemmer mer attraktive i arbeidsmarkedet.

Gruppen mtte utforske og fordype seg i omrder som tidligere var relativt ukjente. Dette var ment

gi lring som er relevant og realistisk i forhold til en arbeidslivsituasjon. Siden prosjektet var

omfattende av natur, ville det vre naturlig lre mye om strre programvareutviklingsprosjekter.

1.4.2 Produktml Gruppen nsket lage en applikasjon som skulle fungere p tvers av kjente plattformer og

synkronisere smlst mellom disse. Gruppen ville lse et problem som alle medlemmene har hatt;

utfordringer tilknyttet til samboerskap og bofellesskap. Disse utfordringene skulle bli lettere mte

for alle ved lage en applikasjon som sentraliserer informasjon og oppgaver tilknyttet bofellesskap.

Applikasjonen skulle ogs vre lett bruke og ha et intuitivt brukergrensesnitt for at den skulle

vre enklere ta i bruk. Gruppen nsket gjre hverdagen lettere for alle som bor i et

bofellesskap, enten de har store problemer med f det til fungere fra fr, eller bare vil gjre det

lettere for seg selv og de de bor sammen med.

1.4.3 Prosessml Med dette prosjektet nsket gruppen lre mer om alt som er knyttet til programvareprosjekter;

prosjektarbeid, programmering, systemutviklingsmetoder, testing og dokumentasjon.

1.5 Rapportens oppbygning Rapporten er bygd opp av disse hovedpunktene

Kravspesifikasjon o Liste med krav, skrevet for beskrive egenskaper og tjenester som kreves av

systemet.

Valg av teknologi o Beskriver teknologiene som er valgt for lse problemet og tilfredsstille kravene i

kravspesifikasjonen.

Designspesifikasjon o Dokumentasjon av systemets arkitektur og datadesign.

Prosess og metoder o Beskriver prosesser, metoder og verkty som er benyttet for utvikle systemet.

Resultat o Beskriver resultatet av prosjektet og produktet som er laget.

Konklusjon o Slutning p prosjektet og sammenfatter resultatene fra prosjektet.

Litteraturliste o Liste over alle kilder som er brukt i rapporten.

Begrepsliste o Liste over ord og begreper som er brukt i rapporten, og en forklaring p disse.

Appendiks - Bakgrunnsteori o Utdypende forklaring av teorien bak en del av teknologien som er brukt. Den gir

en innsikt i applikasjonen som er produsert og systemet som en helhet.

Side 4 av 75

2 Kravspesifikasjon Prosessen med skrive en kravspesifikasjon definerer egenskaper og tjenester som kreves av

systemet.

Kravene er ment som en beskrivelse av systemets funksjonalitet, egenskaper og begrensninger.

2.1 Funksjonelle krav Funksjonelle krav er grunnleggende funksjoner i systemet. De beskriver bestemt funksjonalitet som

systemet skal ha.

Funksjonelt krav #1: Bruker skal kunne registrere bruker med e-post og selvvalgt passord.

Bruker skal kunne registrere seg med sin egen e-post og passord direkte fra applikasjonen. E-post

fungerer som brukernavn.

Registrering av bruker skal skje i applikasjonen, men autentiserer mot Parse sine tjenere.

Funksjonelt krav #2: Bruker skal kunne resette passordet sitt dersom bruker har glemt

passordet sitt.

Fra innloggingsskjermen skal bruker kunne fylle inn e-post og f tilsendt en e-post med veiledning

for stille tilbake passordet sitt.

Funksjonelt krav #3: Bruker skal kunne registrere ny bruker med Facebook.

Dette skal fungere p samme mte som andre applikasjoner som benytter seg av Facebook-

innlogging: Applikasjonen har en knapp med Facebook som sender bruker til Facebook hvor

bruker godkjenner at applikasjonen skal f tilgang til de ressurser som applikasjonen ber om.

Deretter blir bruker sendt tilbake til den originale applikasjonen som fr data fra Facebook som blir

brukt til registrere bruker.

Nr man registrere seg med Facebook skal det automatisk lages en ny bruker til applikasjonen som

er p lik linje med vanlige brukere i applikasjonen, bortsett fra at man ikke kan endre brukerdata.

Man skal ogs kun kunne logge inn via Facebook etter man frst har registrert med e-post-adressen

fra Facebook.

Registrering og innlogging med Facebook skal skje med samme knapp rett fra

innloggingsskjermen.

Funksjonelt krav #4: Bruker skal kunne lage felles beskjeder som alle medlemmer av

bofellesskapet kan se i applikasjonen.

Bruker skal kunne skrive beskjeder direkte i applikasjonen som blir tilgjengelig for alle brukere av

bofellesskapet.

Beskjeden skal komme opp i en meldingsstrm i applikasjonen til alle brukere som er medlem av

bofellesskapet.

Funksjonelt krav #5: Bruker skal kunne f beskjed om nye hendelser i bofelleskapet (nye

beskjeder, nye personer osv.).

Brukere av et bofellesskap skal kunne f meldinger i form av push-meldinger ved nye hendelser og

felles beskjeder.

Dersom en bruker skriver en felles beskjed, skal alle andre i bofellesskapet f en push-melding om

at det har kommet en ny felles beskjed. P samme mte, dersom en annen viktig hendelse skjer i

bofellesskapet (som for eksempel at en ny liste eller utlegg er lagt til), skal det bli sendt ut en push-

melding om dette.

Side 5 av 75

Hendelser skal ogs komme opp i en hendelses-strm direkte i applikasjonen slik at brukere av

bofellesskapet kan g igjennom alle hendelser som har vrt.

Funksjonelt krav #6: Bruker skal kunne f opp alle detaljer om en hendelse i hendelses-

strmmen.

Bruker skal kunne velge en hendelse fra hendelsesstrmmen og f opp alle detaljer som er lagret

om den hendelsen.

Funksjonelt krav #7: Bruker skal kunne opprette lister.

Bruker skal kunne opprette nye lister og sette egenvalgte navn p listene.

Nr en liste blir opprettet skal det opprettes en event i systemet som vises i hendelses-strmmen.

Hendelsen skal fortelle hvilken bruker som opprettet listen.

Funksjonelt krav #8: Bruker skal kunne g inn p alle lister for se listelementer og gjre

endringer p listen.

Bruker skal kunne velge en liste for g inn p listen. Inne p listen skal bruker kunne se alle

listeelementer for listen, samt gjre endringer p listen (som for eksempel slette listen, endre navn

osv.).

Funksjonelt krav #9: Bruker skal kunne opprette listeelementer i alle lister.

Bruker skal kunne opprette nye listelementer i alle lister som er tilknyttet bofelleskapet, uavhengig

om det er bruker som opprinnelig laget listen.

Funksjonelt krav #10: Bruker skal kunne redigere alle lister og markere dem som fullfrt.

Bruker skal kunne redigere navn, slette og markere lister som fullfrt.

Nr en liste blir markert som fullfrt skal det opprettes en event i systemet som vises i hendelses-

strmmen. Hendelsen skal fortelle hvilken bruker som markerte listen som fullfrt.

Funksjonelt krav #11: Bruker skal kunne redigere alle listelementer og markere dem som

fullfrt.

Bruker skal kunne redigere navn, slette og markere listeelementer som fullfrt.

Funksjonelt krav #12: Bruker skal kunne se hvem som har markert en liste som fullfrt.

Nr noen har markert en liste som fullfrt, skal det vre mulig se i bde hendelses-strmmen og i

liste-oversikten hvem som har markert listen som fullfrt.

Funksjonelt krav #13: Bruker skal kunne se hvem som har markert et listelement som

fullfrt.

Nr noen har markert et listelement som fullfrt, skal det vre mulig se inne p listen hvem som

har fullfrt listelementet.

Funksjonelt krav #14: Bruker skal kunne logge seg inn med en registrert bruker.

Dersom en bruker har registrert seg i systemet skal brukeren kunne logge inn p systemet og f

tilgang til sine ressurser.

Funksjonelt krav #15: Bruker skal kunne opprette nytt bofellesskap.

Dersom en bruker ikke er medlem av et eksisterende bofellesskap, skal brukeren har mulighet til

opprette et eget bofellesskap med selvvalgt navn.

Funksjonelt krav #16: Bruker skal kunne invitere andre brukere til eksisterende

bofellesskap.

Side 6 av 75

Alle brukere av et bofellesskap skal ha muligheten til invitere andre brukere i systemet til

bofellesskapet. Invitasjon skal skje ved referere til andre brukere med deres e-post-adresse.

Invitasjon skal kun fungere dersom e-post-adressen allerede er registrert i systemet.

Funksjonelt krav #17: Bruker skal kunne motta invitasjon og godta denne for bli meldt inn

i eksisterende bofellesskap.

Nr en bruker har mottatt en invitasjon skal bruker kunne godta denne for melde seg inn i

bofellesskapet.

Det skal kun vre mulig godta invitasjoner dersom bruker ikke allerede er medlem av et

bofellesskap.

Nr en bruker fr en invitasjon, skal dette varsles med en push-melding til bruker.

Nr en bruker godtar en invitasjon, skal det opprettes en event i systemet om hendelsen som vises i

bofellesskapets hendelsesstrm. Det skal ogs sendes en push-melding til alle medlemmer av

bofellesskapet om hendelsen.

Funksjonelt krav #18: Bruker skal kunne se oversikt over hvem som er med i bofellesskapet.

Bruker skal ha mulighet til se en oversikt over hvem som er medlem av bofellesskapet som

bruker er medlem av.

Oversikten skal vise e-post, navn og bilde for hvert enkelt medlem av bofellesskapet.

Funksjonelt krav #19: Bruker skal kunne melde seg ut av bofellesskapet.

Bruker skal ha mulighet til melde seg ut av bofellesskapet.

Nr en bruker melder seg ut av et bofellesskap skal det opprettes en event i systemet om hendelsen

som vises i bofellesskapets hendelsesstrm. Det skal ogs sendes en push-melding til alle

medlemmer av bofellesskapet om hendelsen.

Funksjonelt krav #20: Bruker skal kunne se oversikt over utlegg i bofellesskapet.

Bruker skal kunne g inn p en utleggsoversikt og se alle utlegg i bofellesskapet.

Funksjonelt krav #21: Bruker skal kunne hvilke utlegg som er gjort opp og hvilke som ikke

er det.

Bruker skal kunne se i oversikten over utlegg i bofellesskapet hvilke utlegg som det er gjort opp

for, og hvilke som fremdeles er uoppgjort.

Funksjonelt krav #22: Bruker skal kunne se hvor mye bruker skylder p et utlegg.

Bruker skal kunne se i oversikten over utlegg i bofellesskapet hvor mye bruker skylder p hvert

enkelt utlegg (dersom bruker er en av de skyldige i utlegget).

Funksjonelt krav #23: Bruker skal kunne se hvor mye andre brukere skylder bruker for et

utlegg.

Bruker skal kunne se i oversikten over utlegg i bofellesskapet hvor mye andre brukere skylder

bruker p hvert enkelt utlegg (dersom bruker er den som det er skyldt penger til i utlegget).

Funksjonelt krav #24: Bruker skal kunne legge til utlegg.

Bruker skal kunne legge til nye utlegg.

En dialog skal komme opp nr bruker skal legge til nytt utlegg hvor bruker fyller ut flgende

informasjon:

Navn p utlegg (pkrevd felt)

Belpet tilsammen som skyldes (pkrevd felt)

Side 7 av 75

Detaljer om utlegget (valgfritt felt)

Hvilke brukere som er skyldige i utlegget

Belpet skal deles likt p alle som er med p utlegget.

Dersom bruker som legger til utlegget er satt opp til vre med p utlegget blir automatisk bruker

satt som ferdig betalt, da den som gjr utlegget allerede har betalt sin del.

Dersom bruker ikke skal vre med p utlegget, men har betalt utlegget for noen andre, kan bruker

velge seg selv bort fra listen og da vil belpet deles p de som faktisk skal betale.

Bruker som legger til belpet er automatisk markert og blir satt som betalt.

Eksempel:

Belp: 1000. Bruker har betalt for utlegget og 3 andre i bofellesskapet var med p utlegget. Dermed

skal de 3 andre brukerne betale 250 hver (siden bruker ogs er med p utlegget). I oversikten over

utlegg str det at bruker er skyldt 750. Hos de andre brukerne som er med p utlegget vil oversikten

si at de skylder 250 for utlegget.

Funksjonelt krav #25: Bruker skal kunne se all informasjon om alle utlegg.

Alle brukere skal kunne g inn p alle utlegg for se informasjon om utlegget som er valgt:

Navn p utlegg

Belp tilsammen

Detaljert tilleggsinformasjon om utlegget

Hvilke brukere som har betalt

Hvilke brukere som ikke har betalt

Hva hver enkelt bruker skylder (skal vre samme belp, da totalbelpet blir delt p brukere som er med p utlegget)

Funksjonelt krav #26: Bruker skal kunne gjre endringer i utlegg som bruker selv har lagt

til.

Bruker skal kunne endre utlegg som bruker selv har lagt til. Det vil si at det kun er brukeren som er

skyldt penger som kan gjre endringer p et utlegg. Alle andre brukere i bofellesskapet kan kun se

p utlegget, men ikke endre det.

Endringer som bruker skal kunne gjre p sine egne utlegg:

Endre navn p utlegg

Endre belp tilsammen p utlegget

Endre detaljert tilleggsinformasjon om utlegget

Slette utlegget

Sette brukere som betalt p utlegget

Sette brukere som ikke betalt p utlegget

Legge til brukere p utlegget

Fjerne brukere fra utlegget

Side 8 av 75

2.2 Ikke-funksjonelle krav Ikke-funksjonelle krav er systemets egenskaper som sikkerhet, plitelighet og tilgjengelighet.

Ikke-funksjonelt krav #1: Systemet skal ha data lagret i skyen.

Data som tilhrer systemet, brukere, innlegg og annen informasjon, skal vre lagret og vre

tilgjengelig fra en back-end-tjeneste.

Ikke-funksjonelt krav #2: Systemet skal synkronisere data lagret lokalt til skyen.

Data som blir produsert lokalt p klienter, skal synkroniseres til skyen og vre tilgjengelig for

andre som har rettigheter til dataene.

Ikke-funksjonelt krav #3: Systemet skal ha klienter slik at de fleste brukere har mulighet til

bruke det.

Systemet skal ha klienter tilgjengelig for et s bredt spekter med brukere som mulig, slik at s

mange som mulig har mulighet til benytte seg av systemet.

Ikke-funksjonelt krav #4: Systemet skal ha klienter som har plattformspesifikke grensesnitt

En klient av systemet som er laget for en spesifikk plattform skal ha utseende og brukergrensesnitt

som passer plattformen og dens retningslinjer for dette.

Ikke-funksjonelt krav #5: Ingen skal kunne logge inn p andres brukere.

Systemet skal vre sikkert nok til at datainnbrudd p systemet ikke skal vre trivielt.

Det er ikke mulig beskytte mot at noen kan finne andres passord, men dette kan minimeres ved

krav om passord som er vanskelige gjette.

Ikke-funksjonelt krav #6: Ingen skal kunne se andres bofellesskap.

Systemet skal vre sikkert nok til at datainnbrudd p systemet ikke skal vre trivielt.

Bruker skal kun kunne f tilgang til det bofellesskapet som bruker selv er medlem av.

Ikke-funksjonelt krav #7: Ingen skal kunne gjre ting p andres vegne.

Bruker skal ikke kunne legge inn beskjeder eller andre ting p vegne av andre brukere.

Dersom bruker fullfrer en liste skal det vre tydelig hvem som har markert listen som fullfrt.

Bruker skal ikke ha tilgang til endre andre brukeres utlegg.

Ikke-funksjonelt krav #8: Innholdet skal vre tilgjengelig s ofte som mulig

Back-end m vre responsiv nok til kunne svare p foresprsler og levere data til de fleste tider.

Noe nedetid er forvente fra alle tjenester som tilbyr back-end.

Side 9 av 75

3 Valg av teknologi For lse problemet som er valgt var det viktig velge riktig teknologi. Mye tid ble brukt p

underske teknologier og plattformer, samt utforske mulige alternativer. Disse skulle tilfredsstille

kravene som var satt, og vre realistiske bruke for prosjektgruppen (bde i prosjekttiden og i

tiden etter prosjektet er ferdig).

3.1 Valg av plattformer For kunne bruke en applikasjon som gjr bofellesskap enklere var det behov for en plattform som

var tilgjengelig "p farten". De fleste er p farten nr ting skal gjres og beskjeder skal gis. De

fleste i bofelleskaps-situasjoner er unge mennesker, som ogs er kjent for ha smarttelefoner.

Valget ble fokusere p mobile plattformer.

Valget av plattformer falt naturlig p iOS og Android p bakgrunn av at det er det de aller fleste

mennesker har (Mobile/Tablet Operating System Market Share, 2014). Gruppen har forskjellige

mobile enheter og samtlige av disse bruker iOS eller Android som operativsystem. Gruppen er

kjent med plattformene og har en god forstelse av retningslinjene for brukergrensesnitt p begge.

Gruppens medlemmer mener at begge plattformene ogs har store fordeler som skiller disse fra

andre. Android er gratis utvikle til, det lett distribuere applikasjoner og er den mest utbredte i

verden. iOS har gode verkty for lage profesjonelle applikasjoner, er meget populrt, det lett

distribuere applikasjoner, og det har et meget aktivt utviklermilj p internett.

Sett i forhold til kryssplattformutvikling ble det fokusert p at resultatet skulle vre tilgjengelig p

de viktigste mobile plattformene. Klientene skulle vre native for sin plattform, og samtidig vre

realistiske utvikle innenfor de gitte tidsrammene. I stedet for velge for eksempel

utviklingsplattformene Xamarin eller Qt som fokuserer p kjre samme kode p alle klienter (p

tvers av plattformer), falt valget p utvikle to separate klienter. Dette grunnet gruppens mindre

kjennskap med C# (Xamarin) og C++/QML (Qt). Utviklingsplattformene var ogs mindre stttet

av de fleste back-end-tjenestene som fantes p markedet.

Valget av plattformer dekker ikke-funksjonelle krav #3 og #4.

3.2 Valg av back-end Da prosjektgruppen skulle velge hvilken back-end lsning som skulle brukes i prosjektet falt valget

p Parse fordi det hadde mye av funksjonaliteten som var nsket innebygd. Parse hadde ogs et

API som s meget ryddig og praktisk ut.

Det var behov for en database hvor dataene kunne lagres slik at de var tilgjengelig overalt. Videre

mtte denne kunne integreres mot prosjektets valgte plattformer: Android og iOS. Dette tilbd

Parse, sammen med en brukerhndtering som har gjort at gruppen kunne fokusere p andre deler av

oppgaven.

Parse hndterer innlogginger, lagring av passord, tilgangskontroll p objekter og vedlikehold av

tjenere.

En ting gruppen s p som et mulig problem med Parse var begrenset offline-sttte, men valgte

allikevel benytte oss av tjenesten. Som nevnt i appendikset er det kommet en ny oppdatering

nylig som legger til bredere offlinesttte til Android, og det er annonsert det samme til iOS i nr

fremtid. Dette betyr at det i fremtiden vil vre enklere implementere dette i prosjektet om det

skulle vre nskelig.

Andre alternativer som har vrt oppe til diskusjon er Apstrata og Stackmob. Apstrata tilbyr

tilsvarende funksjonalitet som Parse, og kunne nok vrt brukt for dekke prosjektets krav. Til slutt

ble Parse valgt p grunn av en tilsynelatende bedre dokumentasjon og at de tilbd mer gratis bruk

enn Apstrata. Stackmob ble vurdert som et alternativ, men dette ble ogs forkastet grunnet Parse

Side 10 av 75

sin tilsynelatende enklere dokumentasjon. Stackmob ble senere kjpt av PayPal, og lagt ned i

februar. (Larson, 12)

Valget av back-end dekker ikke-funksjonelle krav #1, #2, #3, #5, #6, #7 og #8.

4 Designspesifikasjon Hensikten med designspesifikasjonen er vre en dokumentasjon av systemets arkitektur og

datadesign. Designspesifikasjonen skal vre s detaljert at en annen gruppe med utviklere skal

kunne plukke opp denne, og lage et tilsvarende sluttprodukt.

Designspesifikasjonen gjenspeiler den siste versjonen av designdokumentet som har blitt skrevet i

lpet av prosjektets lpetid.

Designdokumentet har blitt utvidet, revidert og oppdatert i begynnelsen av hvert inkrement i

prosjektet, slik som inkrementell utvikling tilsier.

Selve designdokumentet som er skrevet under utviklingen ligger som vedlegg.

4.1 Systemoversikt Systemet skal bruke en ferdig lsning for back-end som heter Parse. Her ligger det databaselsning

i form av NoSQL, brukerhndtering (innlogging, registrering, glemt passord), tjener-side

JavaScript-kode, push-meldinger, lagring, sosiale funksjoner og administrasjon.

Systemet fungerer slik at all data ligger lagret i Parse ("skyen") og applikasjonen bestr av klienter.

Klientene har ikke alle data selv, men hndterer en del av opprettingen og lagringen av dem (sender

data til Parse). I stedet snakker klientene med Parse for f tak i dataene de har behov for.

Parse skal ogs hndtere noe automatisk kode i sin Cloud Code-modul. Cloud Code er kode som

kan kalles p fra klienten, men som ligger lagret og blir kjrt p Parse sine tjenere. Dette gjr at

man kan gjre automatisk behandling av objekter sentralt, i stedet for mtte implementere

logikken p alle klienter. Det gjr gjenbruk av kode enklere.

4.2 Systemarkitektur

Figur 1: Systemarkitektur for prosjektet

Systemet er bygget opp av to hovedmoduler: klient og back-end. Hver av disse har undermoduler

som er vesentlige for funksjonaliteten i systemet.

Parse SDK, og hele back-end er ferdig utviklet og kommer fra Parse. Det som i all hovedsak er

utviklet er klient-koden, databasen og Cloud Code-biten.

Side 11 av 75

Klienten skal bygges opp av to deler. Den frste er selve applikasjonen. Dette er klientkoden.

Denne hndterer brukere direkte. Klientkoden bruker Parse sitt SDK for prate mot back-end-API'

et. Her gis det tilgang til database, push-meldinger og de andre tjenester som Parse sin back-end

tilbyr. Back-end API'et tilbyr ogs en buffer-lsning som gjr det mulig gjre sprringer offline,

men lagring av data lar seg for yeblikket ikke gjre i SDK'et (dette er blitt forespeilet som en

kommende forbedring i SDK'et).

SDK'et gjr all kommunikasjon mot back-end over HTTPS og SSL og srger derfor for

tilstrekkelig sikkerhet under datahndtering.

4.3 Datadesign En User er medlem av et Household, men medlemslisten ligger lagret i en Role som er tilknyttet

Household-et. Det skal dermed vre n Role per Household.

Ved opprettelse av et Household lages det automatisk en Role som knyttes til Household-et

gjennom navnet sitt som er p formen "household-" (f.eks. hvis et nytt

household har id="UlKu48h8ZN" vil name-feltet til Role-objektet vre "household-

UlKu48h8ZN"). I Role-en ligger alle medlemmene av Household-et.

Role er en spesiell klasse i Parse som brukes for sette rettigheter p objekter via en RBAC

implementasjon i Parse sin ACL. Alle medlemmer av en Role fr tilgang til alle objekter som Role-

objektet har tilgang til.

Klassene er koblet tett sammen og er avhengig av en del samhandling. En User er medlem av et

Household gjennom en Role som er tilknyttet det respektive Household-et. En Note er skrevet av en

User og hrer til et Household.

Parse tilbyr et sett med ferdig definerte klasser som kan brukes og utvides med egne felter. De

klassene som er tatt i bruk, er User, Role og Installation. Resten er egendefinerte klasser. Feltene

markert med tykk skrift, er de som er lagt til, resten flger med automatisk.

Visse felter er like for alle klassene og blir automatisk oppdatert og hndtert av Parse:

objectId

o objectId er en unik ID. Alle objekter har sine egne unike ID'er.

o Denne er garantert unik for alle objekter i en gitt klasse (kan med andre ord i teorien ha duplikate objectId'er p tvers av klasser).

createdAt

o createdAt beskriver datoen objektet ble opprettet.

updatedAt

o updatedAt beskriver datoen objektet sist ble oppdatert.

ACL

o ACL (Access Control List) beskriver hvem som har rettigheter til skrive og lese objektet.

Kan enten settes til enkeltbrukere, eller til Role-objekter.

o Blir ikke oppdatert av Parse.

o Denne styres av utvikler for lse ned data.

All data som hentes blir lagret i datastrukturene som Parse sitt SDK for hver plattform tilbyr. Disse

fremstr for brukere av SDK'et som key-value store-datastruktur (dictionary/hash-map).

Side 12 av 75

Figur 2: Datadesign tegnet i UML

Side 13 av 75

Datadesignet er bygd opp av klasser i Parse sin NoSQL-lsning. Et bilde av klassene og deres

relasjoner ses i figur 2.

4.3.1 Role Role-klassen er en klasse som er bygget inn i Parse. De to viktigste feltene i bruk er name og

users.

Navnefeltet m vre unikt, da det er dette som brukes for lokalisere objektet i databasen. Role

skal kun brukes i forbindelse med Household (se beskrivelse av Household) i dette prosjektet.

En Role i Parse blir brukt til sette ACL p andre objekter. Man setter ACL p et annet objekt med

enten brukere eller roller og spesifiserer om det er tilgang til lese og/eller skriverettigheter

(eventuelt nekt p tilgang). Det er i dette prosjektet benyttet til lse ned tilganger p alt som har

med et Household gjre. Siden medlemslisten til et Household ligger lagret i Household-ets

respektive Role fr alle medlemmer tilgang til objekter hvor Role-en settes i ACL.

Spesielle felter i Role:

I Role-klassen finnes det en del felter som flger med, men som ikke er standard p vanlige Parse-

klasser.

roles (Relation): En rolle kan vre medlem av andre roller. Denne er ikke i bruk i dette prosjektet.

users (Relation): Liste over brukere som er medlem av rollen. Denne blir brukt som brukerlisten til bofellesskapet.

name (String): Navnet p rollen. Denne blir brukt til referere til objektet, i stedet for objectId. Feltet skal ha navn p formen "household-".

Relasjoner i Role:

En Role skal ha 1 Household.

4.3.2 Household Household-klassen beskriver et bofellesskap. Hvert bofellesskap knytter brukere opp mot seg selv

som medlemmer gjennom sin respektive Role. For hver eneste Household skal det vre et Role-

objekt som hrer til denne. Det er i dette Role-objektet hvor medlemslisten til bofellesskapet ligger

lagret.

Et Household skal kun lages via Cloud Code-funksjonen som heter "createNewHousehold".

Egendefinerte felter i Household:

householdName (String): Navnet p bofellesskapet.

Relasjoner i Household:

Et Household skal ha 0 eller flere User.

Et Household skal ha 1 Role.

Et Household skal ha 0 eller flere Note.

Side 14 av 75

4.3.3 User User-klassen beskriver en bruker. Den er bygget inn i Parse og er utvidet for dette bruket (se tykke

felter i ER-diagrammet). Hvert objekt er en unik bruker og kan ses p som en brukerkonto.

Egendefinerte felter i User:

displayName (String): I stedet for fornavn og etternavn er det ett felt hvor man kan velge hvilket navn som skal vises hos deg og hos andre brukere.

profilePicture (File): En bilde-fil som brukeren selv kan laste opp som sitt profilbilde.

Spesielle felter i User:

I User-klassen finnes det en del felter som flger med, men som ikke er standard p vanlige Parse-

klasser.

username(String): Brukernavnet til brukeren (skal vre samme som email)

password(String): Passordet til brukeren (kryptert og skjult for alle)

email(String): E-post-adressen til brukeren

authData (authData): Felt som blir brukt ved autentisering med sosiale medier (gjres automatisk av Parse)

Relasjoner i User:

En User skal ha 0 eller flere Household.

En User skal ha 0 eller flere Note.

4.3.4 Note Note-klassen beskriver et felles notat/beskjed i et Household. Det er en beskjed som er skrevet av

en User som er medlem av et Household og kan ses av alle andre brukere som er medlem av det

samme Household-et (dette styres av Household-ets sin Role som blir satt som ACL).

Egendefinerte felter i Note:

body (String): Selve notatet og informasjonen som skal vises til brukere

createdBy (Pointer): Peker til brukeren som har opprettet objektet

household (Pointer): Peker til bofellesskapet objektet er knyttet til.

Relasjoner i Note:

En Note skal ha 1 User

En Note skal ha 1 Household

Side 15 av 75

4.3.5 Event Event-klassen beskriver en hendelse i et bofellesskap. Den brukes for kunne vise en strm av

hendelser til brukere i et bofellesskap, slik at man kan holde seg oppdatert ved kun ta et overblikk

over hendelses-strmmen.

Event er bygget opp av et type-system. Typen hendelse er definert ved tall og hendelsene som er

implementert i klient og cloud-code er som flger:

0: Ny bruker i bofellesskapet

1: En bruker har forlatt bofellesskapet

2: Ny Liste (TaskList)

3: Liste har blitt markert som fullfrt

4: Nytt utlegg (Expense)

5: Utlegg har blitt gjort opp (Expense settled)

En Event opprettes automatisk med Cloud Code og skal aldri lages direkte av en klient. Klienten

bruker kun type-systemet for avgjre hvordan informasjonen i et Event-objekt skal vises til

bruker.

Egendefinerte felter i Event:

type (Number): Hvilken type hendelse objektet handler om (se forklaring over).

household (Pointer

Side 16 av 75

4.3.6 Invitation Denne klassen beskriver en invitasjon til et Household. Den blir sendt fra en User til en annen.

En Invitation kan aksepteres med en Cloud Code-funksjon som heter "acceptInvitation". Nr en

Invitation er akseptert er den inviterte brukeren medlem av bofellesskapet som invitasjonen gjelder

for.

Egendefinerte felter i Invitation:

household (Pointer): Peker til det bofellesskapet som invitasjonen gjelder for.

inviter (Pointer): Peker til brukeren som har invitert.

invitee (Pointer): Peker til brukeren som har blitt invitert til bofellesskapet.

Relasjoner i Invitation:

En Invitation skal ha 1 User (inviter)

En Invitation skal ha 1 User (invitee)

En Invitation skal ha 1 Household

4.3.7 TaskList TaskList representerer en liste som inneholder en mengde med TaskListElement-er. Disse er tenkt

som gjremlslister for brukere av et Household. En TaskList er tenkt som en liste med elementer

som kan krysses av. For eksempel en handleliste, hvor selve tingen som skal kjpes inn er

TaskListElement-et og selve handlelisten er en TaskList.

Disse er felles for alle brukere av et Household. Alle brukere av Household-et som TaskList-en er i

kan legge til, fjerne og redigere alt i TaskList-en.

Egendefinerte felter i TaskList:

listName (String): Navnet til listen (for eksempel handleliste, vaskeliste eller todo).

household (Pointer): Peker til bofellesskapet som listen er laget for.

createdBy (Pointer): Peker til brukeren som har opprettet listen.

done (Boolean): En boolsk verdi som beskriver om listen er fullfrt eller ikke.

Relasjoner i TaskList:

En TaskList skal ha 1 User (createdBy)

En TaskList skal ha 1 Household

En TaskList skal ha 0 eller flere TaskListElement

Side 17 av 75

4.3.8 TaskListElement TaskListElement er underelementer av en TaskList. Disse er tenkt som gjreml som kan utfres og

markeres som ferdige nr de er blitt gjort. Mer informasjon under TaskList.

Egendefinerte felter i TaskListElement:

elementName (String): Navnet p elementet (for eksempel vaske badet eller kjpe melk).

taskList (Pointer): Peker til listen som elementet hrer til i.

createdBy (Pointer): Peker til brukeren som har opprettet elementet.

finishedBy (Pointer): Peker til brukeren som har markert elementet som ferdig.

Relasjoner i TaskListElement:

En TaskListElement skal ha 1 User (createdBy)

En TaskListElement skal ha 0-1 User (finishedBy)

En TaskListElement skal ha 1 TaskList

4.3.9 Installation Installation blir brukt til hndtere push-meldinger. Hver enhet som installerer applikasjonen blir

registrert som en Installation. Med andre ord er en Installation en enhet (iOS-enhet eller Android-

enhet). Hver enhet skal ha en, og bare en, Installation.

Nr en push-melding skal lages, s gjres det en sprring etter Installation-objekter som er knyttet

til en bruker eller et household, avhengig av hvem meldingen er ment for.

Egendefinerte felter i Installation:

user (Pointer): Peker til brukeren som er logget inn p enheten

household (Pointer): Peker til bofellesskapet som innlogget bruker er medlem av.

Relasjoner i Installation:

En Installation skal ha 0-1 User (user)

En Installation skal ha 0-1 Household (household)

Side 18 av 75

4.3.10 Expense Expense-klassen beskriver utlegg. Den blir brukt for holde orden p utlegg som er gjort i et

bofellesskap. Brukeren som har gjort et utlegg blir oppfrt i owed, mens de som skal vre med p

betale, blir lagt i en liste som heter notPaidUp.

Etter hvert som pengene blir betalt tilbake vil brukerne flyttes fra notPaidUp til PaidUp av

brukeren som er skyldt penger. Klassen inneholder ogs et felt for navn p utlegget, et for hvor

mye som er lagt ut og et for en nrmere beskrivelse av utlegget.

Egendefinerte felter i Expense:

name(String): Navnet p utlegget.

owed(Pointer ): Peker til brukeren som gjorde utlegget.

notPaidUp(Array): Liste over de brukerne som ikke har betalt tilbake.

paidUp(Array): Liste over de brukerne som har betalt tilbake.

totalAmount(Number): Hvor mye som ble lagt ut.

household(Pointer): Peker til householdet utlegget hrer til.

details(String): Utfyllende detaljer om utlegget.

Relasjoner i Expense:

En Expense skal ha 1 User (Owed)

En Expense skal ha 0 eller flere User (notPaidUp)

En Expense skal ha 0 eller flere User (paidUp)

En Expense skal ha 1 Household

Side 19 av 75

5 Prosess og metoder Gruppen har benyttet flere prosesser, verkty og metoder for lse oppgaven. Disse har gjort

fremgang og utvikling raskere og mer strukturert.

5.1 Utvikling

5.1.1 Utviklingsmodell De fleste programvareprosjekter benytter seg av utviklingsmodeller for ha en klar plan flge

gjennom utviklingen av prosjektet. En slik utviklingsprosess srger for en strmlinjeformet

utvikling som er forutsigbar og tydelig. Det skal aldri vre tvil om hva neste steg i prosjektet er.

Prosjektet har blitt utviklet med en variant av inkrementell utviklingsmodell.

Inkrementell utviklingsmodell baserer seg p tanken om at man starter med en initial forstelse av

et problem og utvikler denne i inkrementer frem til man har en ferdig lsning.

Hvert inkrement bestr hovedsakelig av fire deler: Kravspesifikasjon, designspesifikasjon,

utvikling og til slutt validering og testing. Ved starten p hvert nye inkrement gr forrige inkrement

inn som utgangspunkt til endringer og forbedringer.

En inkrementell utviklingsprosess kan ses p som i figur 3:

Figur 3: Inkrementell utviklingsprosess

Inkrementell utvikling er en utviklingsmetode som lar prosjekter justere krav og utvikling

underveis. Dette skjer fordi planlegging og kravspesifikasjon skjer i begynnelsen av hvert

inkrement. Det er p dette punktet at inkrementell utvikling skiller seg spesielt ut i fra den mer

tradisjonelle waterfall-modellen hvor et prosjekt i praksis er ett stort inkrement, og all planlegging

gjres p begynnelsen av prosjektet.

Inkrementell utvikling kan ligne veldig p iterativ utvikling, men skiller seg ut ved at iterativ

utvikling ofte har kortere og mindre spesifiserte inkrementer. For eksempel har et inkrement i

inkrementell utvikling et sett med krav som skal implementeres, mens iterativ utvikling gjerne har

en satt tidsperiode hvor man skal implementere s mye som mulig i stedet. Dette frer til at iterativ

utvikling har flere og mer forutsigbare tider p slipp av programvare, mens inkrementell utvikling

har mer funksjonalitet i hver inkrement.

Gruppen valgte inkrementell utvikling fremfor sin nrt beslektede iterativ utvikling og den mer

tradisjonelle waterfall-metoden da kravene p forhnd ikke var helt fastsatt og mest sannsynlig

ville endre seg i lpet av prosjektets utviklingstid.

Side 20 av 75

5.1.2 Kodestandard Fr utvikling ble det satt opp en kodestandard for koden som skulle skrives. Dette ble gjort slik at

koden skulle bli ryddig og lik for alle som skulle jobbe med den.

Standarden er ikke veldig detaljert, s utgangspunkt ble satt til Google sin kodestandard for pene

kildekode-prosjekter.

De detaljene som har blitt spesielt definert for prosjektet, er som flger:

5.1.2.1 Navnsetting

Lange deskriptive navn fremfor forkortelser.

Eksempler:

UIButton *settingsButton;

Figur 4: Riktig

UIButton *setBut;

Figur 5: Feil. Forkortelser som er vanskelige forst

Stor forbokstav i klassenavn og camelCase overalt

Eksempler:

class MinKlasse { public void minFunksjonSomGjoerNoe() {...} }

Figur 6: Riktig

class minKlasse { public void Funksjon() {...} public int enannenfunksjon() {...} }

Figur 7: Feil

5.1.2.1.1 Android-spesifikt

Navnet p java-filene i Android, som er av en spesifikk Android-klasse, skal slutte p navnet til

klassen.

Det vil si at filer lett kan identifiseres som Activity-filer, Fragment-filer osv.

Eksempler

Riktig: LoginActivity.java

Riktig: FeedFragment.java

Feil: Login.java

Feil: Feed.java

Riktig: Event.java (denne er en subklasse av ParseObject, men er ikke relevant til Android rent

spesifikt)

Feil: EventParseObject.java (dette vil vre for vidlftig og har ingen hensikt)

Side 21 av 75

Layout-filer skal ha sm bokstaver og ordene deles med understrek. Typen layout skal vre frste

ord i filnavnet.

Eksempler:

Riktig: activity_main.xml

Riktig: dialog_new_note.xml

Riktig: fragment_me.xml

Feil: main.xml, main_acitivity.xml

Feil: new_note_dialog.xml, noteDialog.xml, note_dialog.xml

Feil: me.xml

5.1.2.2 Innrykk

Innrykk skal ikke vre tabulatortegn, men i stedet best av 4 mellomromstegn.

Med andre ord:

Tab = 4 mellomrom

5.1.2.3 Krllparentes-posisjon

Krllparenteser skal settes p samme linje som funksjons- og klassenavn, med unntak av der

funksjons- og klassenavnene er s lange at de gr over flere linjer.

Eksempler:

public void funksjon() { ... }

Figur 8: Riktig

private double annenFunksjon() { ... }

Figur 9: Feil

public void langtFunksjonsNavnSomMDelesOverFlereLinjer(int index, double value) { ... }

Figur 10: Riktig bruk av unntak

public void langtFunksjonsNavnSomMDelesOverFlereLinjer(int index, double value) { ... }

Figur 11: Feil bruk av unntak

Side 22 av 75

5.1.3 Versjonskontroll Gruppen har valgt Git som versjonskontrollsystem og med dette en sentralisert Git-tilbyder som

heter Github og befinner seg p www.github.com. Github tilbyr en enkel og rask lsning med bde

privat og offentlig oppbevaring av data. Prosjektet har under utviklingen ligget i en privat

oppbevaring som kun gruppens medlemmer har hatt tilgang til lese og skrive til.

Git ble valgt for versjonskontroll fordi dette er en de mest brukte programvarene for dette

(Freeman, 2013), samt at gruppens medlemmer hadde kunnskap og erfaring med Git fra tidligere.

Det finnes flere gode Git-tilbydere, men Github passet bedre med tanke p enkelhet og

funksjonalitet. Muligheten til utforske, ske og bla seg igjennom nvrende og tidligere

versjoner av kildekoden sentralt, har gjort mange utviklingsoppgaver enkle.

5.1.4 Utviklingsverkty Utviklingsverkty er en vesentlig del av et prosjekt og mye tid har blitt brukt p velge riktig

verkty til jobben som skal gjres. Verktyene gjr arbeid lettere, ker produktivitet og er viktige

for at gruppens medlemmer skal trives i arbeidet. Drlige verkty kan felle store deler av et

prosjekt, mens gode og riktige verkty kan fremme kvalitet.

Gruppen har i lpet av utviklingen brukt en rekke verkty for gjennomfre prosjektet - alt fra

integrerte utviklingsmiljer (IDE) til verkty for prosjektstyring og modellering av

brukergrensesnitt.

Verktyene er valgt etter gruppens preferanser og hva som har passet best for prosjektet.

5.1.4.1 Integrerte utviklingsmiljer (IDE)

Prosjektet har brukt mange programmeringssprk og plattformer under utviklingen og det har

derfor blitt brukt flere IDE'er.

Valgene er blitt gjort basert p hva som er sett p som standard og hva som er gruppens egne

preferanser.

5.1.4.1.1 Android

Til utvikling av Android-klienten valgte gruppen Android Studio.

Android Studio er et nytt IDE fra Google som skal erstatte Eclipse med ADT Plugin. Android

Studio er bygget p et Java IDE som heter IntelliJ IDEA og har lagt til Android-spesifikke verkty

som gjr utvikling av Android-applikasjoner lettere. (Getting Started with Android Studio, u..)

Android Studio har meget god sttte for syntaks-fremheving, faktorisering av kode som tar hensyn

til Android-spesifikk deler, integrasjon med Android sitt SDK, en layout-editor med trekk-og-slipp

og mange andre nyttige funksjoner.

Side 23 av 75

Figur 12: Skjermdump Android Studio

5.1.4.1.2 iOS

Da det ikke er mange gode alternativer til IDE'er for iOS-utvikling falt valget naturlig p Xcode.

Andre alternativer mangler sttte for WYSIWYG-editor (What You See Is What You Get) og

krever som regel Xcode for gjre elementre oppgaver som simulering.

Xcode er et program for Mac, laget av Apple Inc. og har sttte for alle steg i utviklingen av en iOS-

applikasjon.

Xcode er en utviklingsplattform laget spesielt for utvikling til Apple sine produkter og gjr en

meget solid jobb p akkurat dette. Xcode har god sttte for syntaks-fremheving, debugging,

brukergrensesnitt-generering (WYSIWYG) og har en simulator som lar utviklere simulerer

applikasjonene sine p iPhone og iPad. Simulatoren er rask og har mange funksjoner for simulere

enheter p en troverdig mte.

Figur 13: Skjermdump Xcode

Side 24 av 75

5.1.4.1.3 Cloud Code

Cloud Code er kun JavaScript og til dette har IDE'et Coda 2 blitt brukt.

Coda 2 er et program laget av Panic Inc til Mac OS X. Programmet kan kjpes fra Apple Mac Store

og sttter en rekke programmeringssprk til web.

Dette verktyet ble valgt, da syntaks-fremhevingen er meget godt, samt at gruppen hadde tilgang til

denne fra fr prosjektets start.

Coda 2 ble brukt til skrive selve koden, men ikke til opplastning av koden til Parse. Dermed

fungerte Coda 2 mer som en tekst-editor enn et IDE. Parse har egne kommandolinjebaserte verkty

for opplastning av Cloud Code til Parse sine egne tjenere.

5.1.4.2 Brukergrensesnittmodellering

Det har i designfasen blitt laget modeller av brukergrensesnittet som har blitt brukt for gjre

implementasjon av en sammensveiset brukeropplevelse enklere og lettere under utvikling og

implementasjon.

Brukergrensesnittmodelleringen er gjort i et verkty for iPad som heter AppCooker. Dette

verktyet har latt gruppen tegne opp brukergrensesnitt for iOS. Android sitt brukergrensesnitt er

oversatt med skjnn for srge for en tilsvarende opplevelse som iOS-brukergrensesnittet, men

som fremdeles oppleves som en Android-applikasjon.

Figur 14: Skjermdump AppCooker

5.1.4.3 Diagrammer

Til tegne og lage diagrammer er LucidChart av Lucid Software Inc. brukt.

LucidChart er en webapplikasjon for lage flytskjemaer, UML-diagrammer og figurer. Med et

enkelt grensesnitt basert p trekk-og-slipp, samt en bred implementasjon av UML var valget av

diagramverkty relativt enkelt.

UML har spesifikasjoner som i mange applikasjoner er drlig og mangelfullt implementert.

LucidChart var den eneste som hadde alle elementene som prosjektet hadde behov for innebygd.

Diagrammer har frst og fremst blitt brukt i designspesifikasjonsdokumentene for beskrive

systemarkitektur og databasedesign.

Side 25 av 75

Figur 15: Skjermdump LucidChart

5.1.5 Testing Testing er en viktig del av ethvert prosjekt, srlig programvareprosjekter, da disse har veldig

mange muligheter til feil. Det f luket ut feil er helt essensielt for kunne levere et

tilfredsstillende produkt.

Programvaretesting deles gjerne opp i niver, basert p hva de tester og omfanget av testene.

Teknikkene for de forskjellige nivene er mange og varierende. Det finnes ulike synspunkter p

hvilke niver av programvaretesting som er ndvendige og hvilke som er mest ndvendige. Det de

fleste dog er enige om er at testing er ndvendig.

Figur 16: Software Testing Niver (Software Testing Levels, u..)

Fire ofte brukte niver p testing er (i stigende omfangsgrad) enhetstesting, integrasjonstesting,

systemtesting og godkjenningstesting. (Software Testing Levels, u.) Se figur 16.

Prosjektet valgte bruke enhetstesting, systemtesting og godkjenningstesting.

Side 26 av 75

5.1.5.1 Enhetstesting

Enhetstesting er en type testing som skal teste en liten enhet av koden, isolert fra resten av

systemet. Man tester gjerne en klasse eller en funksjon direkte, og fjerner alle avhengigheter fra

andre deler av systemet, slik at kun det som skal testes faktisk blir testet.

Figur 17: Avhengigheter og Dependency Injection

Problemet er beskrevet i figur 17. En enhet skal testes, men har avhengigheter som igjen har mange

avhengigheter. Feil i avhengighetene kan lage feil i testen, selv om feilen ikke ligger i enheten som

skal testes. Derfor lager man etterligninger av avhengighetene som man injiserer inn i enheten som

skal testes. Etterligningen oppfrer seg som avhengigheten, men er fullstendig kontrollert av

utvikleren. Dette kalles for Dependency Injection (DI).

Et eksempel p bruk av Dependency Injection er hvis en enhet skal hente ned informasjon fra en

sentralisert tjener, bearbeide informasjonen og returnere resultatet. Enheten bruker en annen enhet

(avhengighet) som kobler seg til den sentraliserte tjeneren og laster ned informasjonen. Det man

nsker teste er at enheten bearbeider data p korrekt mte og returnerer (eventuelt fornuftige og

korrekte feilmeldinger) som den skal. Dersom den sentraliserte tjeneren ikke er oppe vil testen

feile, uavhengig om enheten er korrekt eller ikke. Dette lses ved lage en etterligning av enheten

som laster ned informasjonen. Etterligningen vil oppfre seg p samme mte som enheten den

etterligner, men vil levere et sett med falsk informasjon som er testbar.

5.1.5.1.1 Problemer med enhetstester i prosjektet

Enhetstesting var ment som en del av prosjektet helt fra forprosjektet. Det ble fjernet fra prosjektet

grunnet hyt tidsbruk for skrive testene. Skulle prosjektet bli dekket av enhetstester, ville ikke

resultatet blitt like godt gjennomfrt som det faktisk ble.

Denne delen beskriver forskene som ble gjort p implementasjon av enhetstesting, og hvilke

problemer som dukket opp.

Enhetstester ble forskt implementer tre ganger i lpet av prosjektet.

Side 27 av 75

5.1.5.1.1.1 Frste forsk

I frste forsk ble enhetstestene skrevet uten bruke Dependency Injection. Dette frte til tester

som hadde mange avhengigheter, som gjorde det tilnrmet umulig garantere at en test fungerte

hver gang. I tillegg ble det gjort implisitte nettverks-kall som frte til at testene ble trege veldig

fort.

For at enhetstester skal vre mest effektive br de kunne kjres ofte for finne regresjoner i koden.

Dette ble vanskeligjort fordi det tok mange minutter kjre testene, selv for sm mengder med

tester.

5.1.5.1.1.2 Andre forsk

Etter at frste forsk mtte skrotes (slette alle tester og g tilbake til ingen tester) var det fremdeles

et sterkt nske om ha enhetstesting som en del av prosjektet. Lsningen ble bruke mer korrekte

enhetstester med bruk av Dependency Injection.

Fr Dependency Injection kunne brukes mtte all logikk separeres inn i klasser og funksjoner med

Dependency Injection implementert. Dette var mye arbeid som kunne vrt unngtt om feilene i

frste forsk ikke hadde blitt gjort.

Det viste seg at selve testene ble veldig omfattende og kompliserte. Grunnen til dette var mest

sannsynlig en systemarkitektur som ikke er helt ideell. For skrive en enkel test hvor enheten

brukte Parse sine tjenere til gjre noe som helst, innebar det mange linjer kode.

Siden Parse sitt API bruker statiske objekter var det ikke mulig bruke Dependency Injection

direkte p disse. Det frte til et forsk p fange opp nettverkskallene til Parse og gi en falsk

respons for sikre at responsen var den samme hver gang. Det innebar manuell skriving av HTTP-

responser som mtte etterligne HTTP-responsene fra Parse sine tjenere.

Grunnen til at det var behov for etterligne HTTP-responsene var fordi det ikke var mulig

etterligne Parse sine klasser (for separere ut avhengigheter). Parse sine klasser er statiske, noe

som gjr at de ikke kan injiseres, og dermed heller ikke kan etterlignes. Dermed mtte i stedet

Parse sitt API injiseres p nettverksniv med egne HTTP-responser. For kunne etterligne

responsen fra Parse mtte pakker fra Parse sniffes ved bruk av nettverkssniffere. Dette lot seg gjre

ved godta alle sertifikater p iOS simulatoren. Alt dette gjorde skrivingen av en test til en meget

tidskrevende aktivitet.

En enhetstest for en enhet som skulle hente ned siste notater for et bofellesskap endte opp med bli

betydelig lengre enn selve enheten.

Dette var heller ikke et brukbart alternativ, og kunne ikke i praksis gjennomfres for et prosjekt av

denne strrelsen.

5.1.5.1.1.3 Tredje forsk

I det tredje (og siste) forsket var mye lrt. Bruk av Dependency Injection var fremdeles

lsningen, men Parse sitt statiske API gjorde dette vanskelig.

Lsningen ble lage en wrapper til Parse sitt API. Det vil si en ikke-statisk klasse som pakker inn

Parse sitt statiske API til noe som kan injiseres i en kontekst hvor Dependency Injection er brukt.

En slik antistatisk klasse kan etterlignes og dermed brukes til Dependency Injection.

Dette innebar nok en gang en omskriving av betydelige mengder kildekode for kunne

gjennomfres, samt at nye tester mtte skrives.

Den nye lsningen gjorde testene betydelig mindre, men samtidig langt mer omfattende fordi det

etterligne alle avhengighetene er en komplisert jobb.

Grunnet kompleksiteten av testene og tiden det tok skrive de, ble nok en gang enhetstestene

fjernet fra prosjektet. Denne gangen for godt.

Side 28 av 75

Problemet kunne vrt unngtt om hele prosjektet hadde hatt en annen struktur med mindre

avhengigheter i hver enhet.

Det var ikke forsvarlig skrive om hele prosjektet p det tidspunktet som dette var kommet til. Det

ville innebre alt for mye tid og arbeid som ikke ville gitt nok tilbake for tiden lagt inn i det.

Ved fjerning av testene og strukturen som var lagt opp rundt enhetstesting var dette resultatet av

opplastning til git:

94 files changed, 957 insertions(+), 4053 deletions(-)

Figur 18: Utskrift fra git etter fjerning av tester og struktur rundt

3000 linjer med kode ble slettet over 94 filer totalt (dette gjaldt kun iOS). Dette utgjorde en

betydelig del av prosjektet og styrket valget om til slutt fjerne testene.

5.1.5.2 Systemtesting

Systemtesting er den testprosessen hvor man tester et sammensatt, fungerende system. Det er i

dette tilfellet vrt gjort ved teste applikasjonen manuelt.

Testing av hele systemet har vrt gjort flere ganger i lpet av hvert inkrement. Systemtestingen har

blitt gjort ved bruke et skjema med avkryssing. Skjemaet har forskjellig funksjonalitet som skal

testes, og dersom funksjonalitet fungerer som ventet, krysses det av for den.

Figur 19: Utklipp fra testdokument

Ved legge til nye manuelle tester for hvert inkrement, har all funksjonalitet blitt testet ved hvert

inkrement. Dette gjr at samtidig som man tester ny funksjonalitet, testes det ogs for regresjoner.

5.1.5.3 Godkjenningstesting

Godkjenningstestingen er testing for akseptabilitet, om systemet blir godtatt av brukere. Testingen

avgjr om systemet flger kravene som er satt og om det er klart for levering.

Godkjenningstestingen i prosjektet har blitt gjort helt p slutten av prosjektet med en betatest for

iOS og Android. Gruppen fant noen brukere som kunne prve systemet i egen kontekst og som

kunne gi tilbakemeldinger p systemet og melde om feil.

Det er ikke blitt gjort stort med tilbakemeldingene fra betatesten, da denne ble utfrt helt p slutten

av prosjektet. Feil som ble rapportert, er det eneste som er hndtert i etterkant. Tilbakemeldingene

er dog notert og kan vurderes i videre utvikling av prosjektet.

Det ble meldt nske om mer veiledning i applikasjonen, slik at brukerne lettere kan vite hva ting

kan brukes til og hvordan de skal brukes.

Det ble ogs meldt om noe forvirrende navn p den delen som er ment for felles beskjeder. I dag

heter den "Notes", noe som kan vre litt tvetydig.

Testingen ga en god indikasjon p ting som burde endres, og staker ut veien for videre utvikling av

prosjektet.

Side 29 av 75

5.2 Prosjekt For at et prosjekt skal kunne utfres effektivt og plitelig er det ofte behov for bygge opp en

gruppestruktur, styrket av verkty for prosjektstyring og informasjonsflyt. Gruppen har hele tiden

hatt en flat struktur, hvor alles mening har veid like tungt vedrrende valg som er gjort underveis. I

dette kapittelet flger gruppens oppbygning, samt de forskjellige verktyene som er blitt benyttet

underveis.

5.2.1 Gruppestruktur Selv om gruppen har hatt en flat struktur uten en utnevnt leder har det blitt fordelt srlige

ansvarsomrder p de forskjellige medlemmene. De forskjellige ansvarsomrdene er fordelt slik:

Katrine Myklevold

Design av brukergrensesnitt

Utvikling til iOS

Testrutiner

Testing

Gjermund Bjaanes

Implementasjon av database, samt Cloud Code i Parse

Utvikling til iOS

Utvikling til Android

Johann Eckhoff

Utvikling til Android

Testing

Hndtering av Beta-testing

5.2.2 Evernote Til felles notater og smdokumenter har Evernote fra Evernote Corporation blitt brukt.

Evernote er en kryssplattform notat-applikasjon. Den lar brukere lage notatbker og skrive alle

slags mulige notater (med rikt innhold som tekst, bilder og lyd). Gruppen har hatt en delt notatbok

som har blitt brukt til alle notater og smdokumenter underveis i prosjektet.

I den delte notatboken har det ligget mye informasjon som har vrt greit kunne referere til under

utviklingen. Eksempler p dette er testskjemaer, designbestemmelser og kodestandard.

Side 30 av 75

Figur 20: Skjermdump Evernote

5.2.3 Gantt-diagram Et Gantt-diagram er et diagram for illustrere tidsplanleggingen i et prosjekt. Det viser nr ting er

planlagt starte, hvor lang tid det er planlagt bruke p det og nr det skal vre ferdig.

For produsere Gantt-diagrammer til prosjektet har et pent-kildekode-program som heter Gantt

Project blitt brukt.

Gantt Project er en kryssplattform-applikasjon som er enkel bruke og har tilstrekkelig

funksjonalitet til produsere Gantt-diagrammer.

Figur 21: Skjermdump Gantt Project

Side 31 av 75

5.2.4 Prosjektstyringsverkty Gruppen har benyttet seg av en web-applikasjon som heter Trello.

Trello lar brukere sette opp en digital arbeidstavle som representerer prosjektet man jobber med. P

tavlen kan man sette opp lister hvor hver liste kan ha kort som representerer en oppgave.

Kortene (oppgavene) har navn og kan inneholde tidsfrister, hvilke medlemmer av gruppen som har

blitt satt til gjre oppgaven og mer detaljert informasjon om oppgaven.

Figur 22: Skjermdump fra Trello (tatt fra gruppens egen tavle)

Gruppen har brukt Trello gjennom hele prosjekttiden for holde styr p oppgaver og tidsfrister.

Verktyet har srget for at gruppen har holdt en st kurs hele tiden og ftt gjort unna oppgaver

innen rimelig tid.

6 Resultat Resultatet av prosjektet er avgjort av produktet og prosjektets ml.

6.1 Produkt Produktet er to klienter og en back-end, satt sammen til et system som fungerer i henhold til de

kravene som er satt.

Klientene fungerer hver for seg og sammen. Kommunikasjon mellom klienter skjer implisitt ved at

brukere kommuniserer seg i mellom via data som er lagret i back-end.

6.1.1 Produktml Gruppen mener de har lykkes i lage en applikasjon som oppfyller mesteparten av produktmlet,

og kan gjre samboerskapssituasjoner enklere.

Gruppen har ftt tilbakemeldinger p applikasjonen som bekrefter dette, men det er ogs mottatt

noen negative tilbakemeldinger. Disse gr ut p at lringskurven for komme i gang er litt bratt.

Det er ytret nsker om en veiledning som tar brukeren gjennom hovedfunksjonaliteten til

applikasjonen frste gang man tar den i bruk. Allikevel mener gruppen at produktmlet er delvis

oppndd.

6.1.2 Kildekode Dette kapittelet forklarer litt om hvordan koden er lagt opp i klientene og demonstrer noen

teknikker og metoder som er brukt i prosjektet.

Side 32 av 75

6.1.2.1 Samtidighet (Concurrency)

Begge klientene gjr nettverkskall utenfor hovedtrdene, men det er ikke implementert manuelt

med trder eller samtidighets-API'er. Dette er i stedet brukt implisitt ved benytte metoder fra

Parse sitt API som arbeider i bakgrunnen.

Parse sitt API har sttte for samtidighet, og bruker call-back's for varsle klientene om at de er

ferdige med laste ned og bearbeide.

ParseQuery query = new ParseQuery("Expense"); query.getInBackground(expenseObjectId, new GetCallback() { @Override public void done(Expense expense, ParseException e) { ... } });

Figur 23: Sprring i Android med Parse sitt API

[PFUser logInWithUsernameInBackground:username password:password block:^(PFUser *user, NSError *error) { ... }];

Figur 24: Sprring i iOS med Parse sitt API

Android-koden i figur 23 og iOS-koden i figur 24 er bruker begge Parse sitt API for gjre

nettverkskall mot Parse sine tjenere. Begge har en call-back som blir utfrt nr API'et er ferdig med

jobben den skal gjre.

6.1.2.2 Facebook

Applikasjonen er integrert mot Facebook ved at man kan registrere seg som bruker av

applikasjonen ved hjelp av profildetaljene sine fra Facebook. For dette brukes en kombinasjon av

Parse sitt Facebook-API og Facebook sin egen SDK. Nr brukeren logger inn med Facebook, vil

han bli spurt om applikasjonen skal f tilgang til profildetaljene sine. Disse blir s lagret som en ny

bruker i databasen hos Parse. Dette gjr at det ikke tillates endre profildetaljer for en bruker som

er logget inn via Facebook.

I figur 25 (Android-kode) og figur 26 (iOS-kode) kan man se hvordan man kaller p Parse sin

Facebook-integrasjon for logge inn med Facebook.

ParseFacebookUtils.logIn(permissions, this, new LogInCallback() {

@Override

public void done(ParseUser parseUser, ParseException e) {

// When login is done, the data fields are updated with the details

// from the facebook user

...

});

Figur 25: Innlogging med Facebook p Android

[PFFacebookUtils logInWithPermissions:permissionsArray block:^(PFUser *user, NSError *error) { // When login is done, the data fields are updated with the details // from the facebook user ... }];

Figur 26: Innlogging med Facebook p iOS

Side 33 av 75

6.1.2.3 iOS

Koden til iOS er skrevet utelukkende i Objective-C og bruker Parse sitt iOS SDK.

6.1.2.3.1 Struktur

Koden til iOS har endret struktur flere ganger i lpet av prosjektet, som en flge av ny kunnskap og

et nske om eksperimentere.

Grunnet enhetstestenes bortgang var det ikke behov for separere all logikk fra View Controllers.

Derfor er koden lagt opp slik at hver View Controller inneholder all relatert logikk. Dette har gjort

noen klasser litt lengre enn de hadde behvd vre, men har gjort at utviklingen av disse har gtt

betydelig fortere. Dette er ogs mten Parse har gjort ting i sine eksempler og veiledninger.

For illustrere forskjellene har en innloggingsskjerm med separert logikk en liten View Controller-

klasse som hndterer bruker-input og viser feilmeldinger, og en lengre hjelpeklasse for hndtere

selve innlogging og feil fra Parse sine tjenere. Dette ville vrt en klart bedre struktur, men grunnet

tidsbegrensninger ble ikke dette gjort.

Slik det er gjort i prosjektet, har innloggingsskjermen kun View Controller-klassen som inneholder

hndtering av brukerinput, kommunikasjon mot Parse, hndtering av feil og visning av disse til

bruker.

lage hjelpeklasser til alle interaksjoner mot Parse viste seg vre mye repeterende kode, noe

som tyder p at deler av strukturen ikke er ideell. Det ble ogs mye repeterende kode ved kutte ut

hjelpeklassene fullstendig, s en lsning som er "perfekt" er ikke funnet for dette prosjektet.

Den beste lsningen ville vrt lage et lite sett med generiske hjelpeklasser. Dette var ikke noe

gruppen fikk tid til gjennomfre.

Side 34 av 75

6.1.2.3.2 MVC-mnsteret

MVC (Model-View-Controller) design-mnsteret dreier seg om den globale arkitekturen i et

program. Derfor er det et hyniv-mnster. MVC designmnsteret klassifiserer gjenstander etter de

generelle rollene de spiller i applikasjonen. Et MVC design-mnster kan ogs omfatte flere

MVC'er. Man drar nytte av tilpasse MVC'en for sitt eget design fordi mange gjenstander i disse

programmene har en tendens til vre mer gjenbrukbare. Dette gjr at applikasjoner enklere kan

tilpasse seg dersom krav endres eller hvis man trenger utvide applikasjonen. (Model View

Controller, 2012)

I MVC designmnsteret finnes det tre typer objekter: Model-objekter, view-objekter og controller-

objekter. Modell-objekter er hva applikasjonen er (men ikke hvordan den er vist). Controller-

objekter (eller View Controller) kontrollerer hvordan model-objekter blir presentert til brukeren

(UI-logikk). View-objekter er brukergrensesnitt-elementer som controlleren styrer og bruker for

presentere model-objekter.

View Controlleren kan alltid snakke direkte til sine Model-objekter og til sine View-objekter.

Model-objekter og View-objekter skal ikke snakke med hverandre. (Model View Controller, 2012)

Det finnes flere mter implementere MVC i en iOS-applikasjon. Den mest ryddige mten er

separere all logikk som ikke er direkte avhengig av data eller skjermelementer ut av View

Controlleren. Dette har lett for innebre svrt mange klasser, en god del mer kode og litt mer

rotete struktur i prosjektet. Samtidig har det en tendens til bli mindre klasser, er mer testbart og

lettere forst hvordan View Controlleren jobber.

Prosjektet har benyttet seg av en annen variant av MVC, der mesteparten av logikken ligger i View

Controlleren, og modellene er enkle objekter (som for eksempel tabeller). Dette er for gjre

utvikling raskere og fordi det ikke var noen klare fordeler med separere ut all logikken. Dette gjr

ogs at iOS- og Android-versjonene har likere struktur.

I en typisk skjerm kan View-delen vre skjermelementer som er laget i Xcode sin Storyboard (dra-

og-slipp). Knapper, tekstfelter, oversikter og tabeller er typiske skjermelementer som er en del av

View'et.

Figur 27: Skjermdump fra Xcode. Viser et View

Modellen kan for eksempel vre en liste med objekter som skal vises p skjermen p et eller annet

vis.

// Model @property (strong, nonatomic) NSArray *unfinishedTaskLists; // of TaskList *