Roommates: Rapport for hovedoppgave

83
i Roommates En applikasjon for å gjøre bofellesskap enklere. Gruppedeltakere / Real Kode: Gjermund Bjaanes, Johann Eckhoff og Katrine Myklevold

Transcript of Roommates: Rapport for hovedoppgave

Page 1: Roommates: Rapport for hovedoppgave

i

Roommates

En applikasjon for å gjøre bofellesskap enklere.

Gruppedeltakere / Real Kode:

Gjermund Bjaanes,

Johann Eckhoff og

Katrine Myklevold

Page 2: Roommates: Rapport for hovedoppgave

ii

Hovedoppgave

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

samboersituasjoner. Man kan sende notater til hverandre, føre 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

Besøksadr.: Raveien 215 3184 Borre Tlf: 33031000, Fax: 33031100

Institutt for ingeniørutdanning i Vestfold

Roommates - En applikasjon for å gjøre 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, Skyløsning

3 STIKKORD

Page 3: Roommates: Rapport for hovedoppgave

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, støtte for push-meldinger og tjenerside-

kode. Her ligger databasen hvor alle brukerdata er lagret, samt tjenerside-kode for å utføre

visse oppgaver. Applikasjonen er laget og testet for å brukes på alle enheter som kjører iOS,

samt mobiltelefoner som kjører Android 4.0 og oppover.

Gjennom prosjektet er det blitt brukt en systemutviklingsmetode som heter inkrementell

utvikling. Denne metoden går 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 fått kunnskap innen programmering mot Android og iOS,

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

erfaring med større 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 høyere 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.

Page 4: Roommates: Rapport for hovedoppgave

iv

Skjemaet skal leveres sammen med besvarelsen.

Obligatorisk erklæring Jeg erklærer herved at min:

Eksamensbesvarelse i emnekode: FE-BAC3000 Fakultet: TekMar

1. er utført av undertegnede. Dersom det er et gruppearbeide, blir alle involverte holdt

ansvarlig og alle skal undertegne blanketten.

2. ikke har vært brukt til samme/en annen eksamen ved HVE eller et annet institutt/

universitet/høgskole 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 erklæringen leveres inn elektronisk via Fronter er underskrift ikke nødvendig, skriv da inn navn.

Page 5: Roommates: Rapport for hovedoppgave

v

Hovedprosjektets tittel:

Roommates - En applikasjon for å gjøre bofellesskap enklere.

Forfatternes navn:

Gjermund Bjaanes, Johann Eckhoff og Katrine Myklevold

Kurs/avdeling:

Ingeniørfag, Datateknikk. Avdeling TekMar

Dato: _______________________

Rett til innsyn, kopiering og publisering av hovedprosjekt

Biblioteket og avdelingene får ofte forespørsler om kopi eller innsyn i hovedprosjekt. Biblioteket ønsker å gjøre gode hovedprosjekt tilgjengelig ved å publisere dem i papirutgave og legge dem på internett. Høgskolen trenger studentenes tillatelse til dette.

Hovedprosjektet vil fortsatt være forfatterens åndsverk med de rettigheter det gir.

Høgskolens bruk vil ikke omfatte kommersiell bruk av studenters hovedprosjekt.

Tillater du/dere at din/deres hovedprosjekt blir publisert både i papir og nettutgave ?

___ ja ___ nei

Signatur av alle forfattere:

Page 6: Roommates: Rapport for hovedoppgave

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 gjennomført, hvordan

systemet er satt sammen, hvilke utfordringer som har oppstått underveis, hvordan disse er håndtert

og hva resultatet av prosjektet ble.

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

Myklevold. Vi er alle studenter ved Ingeniørfag, Datateknikk, Høgskolen i Buskerud og Vestfold.

Takk til Vi ønsker å takke vår veileder gjennom prosjektet, Thomas Nordli, for hjelp med tekniske

spørsmål, konstruktiv kritikk og veiledning generelt underveis.

Våre dyktige språkvaskere: Astrid Bjaanes og Roald Bjaanes som har hjulpet oss med å få

rapporten på et bedre språklig nivå.

Under betatesting har vi hatt god hjelp av Marlene Angelica Sjonsti Björnsen og Ådne Aalmo. De

har testet applikasjonen vår 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 opplæringen i utvikling til iOS. Hans forelesninger som

ligger tilgjengelig på nettet har sørget for en solid forståelse av plattformen. Den inspirasjon han

har gitt oss, kan ikke verdsettes høyt nok.

Page 7: Roommates: Rapport for hovedoppgave

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 Målformulering ..................................................................................................... 3

1.4.1 Prosjektmål ................................................................................................... 3

1.4.2 Produktmål .................................................................................................... 3

1.4.3 Prosessmål ................................................................................................... 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

Page 8: Roommates: Rapport for hovedoppgave

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 Krøllparentes-posisjon ............................................................................21

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

5.1.4 Utviklingsverktøy ..........................................................................................22

5.1.4.1 Integrerte utviklingsmiljøer (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 Prosjektstyringsverktøy ................................................................................31

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

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

6.1.1 Produktmål ...................................................................................................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 Prosjektmål ..................................................................................................51

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

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

Page 9: Roommates: Rapport for hovedoppgave

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 Objective–C ................................................................................................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

Page 10: Roommates: Rapport for hovedoppgave

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 løsning/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 samkjøring av aktiviteter knyttet til samboerskap. Dette er noe veldig

mange studenter må forholde seg til, og gruppen bestemte seg derfor for å utforske disse områdene

og det som måtte dukke opp underveis i forhold til dette.

Samtidig så gruppen en mulighet til å gjøre 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 nivåer 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 måtte tilegnes både før og underveis i

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

Som tidligere nevnt ville gruppen gjøre et prosjekt knyttet til kryssplattformutvikling og lagring av

data i skyen. Valget falt på å lage en mobilapplikasjon til de to største 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 særlig godt dekket av andre tilbud på markedet per i dag. Det

finnes andre som har gjort forsøk på dette, men de er etter gruppens mening ikke særlig gode.

Eksempler på applikasjoner gruppen har prøvd som prøver å 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 løses på en bedre måte enn det som allerede er gjort.

Page 11: Roommates: Rapport for hovedoppgave

Side 3 av 75

1.4 Målformulering

1.4.1 Prosjektmål Gruppen ønsket med dette prosjektet å utvikle et produkt som fungerer og som kan brukes til

daglig. Systemet skulle synkronisere over skyen, være tilgjengelig for så mange brukere som mulig

og være lett å bruke. Erfaringen gruppen ønsket å tilegne seg i dette prosjektet, ville være veldig

relevant for arbeidslivet og gjøre gruppens medlemmer mer attraktive i arbeidsmarkedet.

Gruppen måtte utforske og fordype seg i områder som tidligere var relativt ukjente. Dette var ment

å gi læring som er relevant og realistisk i forhold til en arbeidslivsituasjon. Siden prosjektet var

omfattende av natur, ville det være naturlig å lære mye om større programvareutviklingsprosjekter.

1.4.2 Produktmål Gruppen ønsket å lage en applikasjon som skulle fungere på tvers av kjente plattformer og

synkronisere sømløst mellom disse. Gruppen ville løse et problem som alle medlemmene har hatt;

utfordringer tilknyttet til samboerskap og bofellesskap. Disse utfordringene skulle bli lettere å møte

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

Applikasjonen skulle også være lett å bruke og ha et intuitivt brukergrensesnitt for at den skulle

være enklere å ta i bruk. Gruppen ønsket å gjøre hverdagen lettere for alle som bor i et

bofellesskap, enten de har store problemer med å få det til å fungere fra før, eller bare vil gjøre det

lettere for seg selv og de de bor sammen med.

1.4.3 Prosessmål Med dette prosjektet ønsket gruppen å lære 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 å løse problemet og tilfredsstille kravene i

kravspesifikasjonen.

Designspesifikasjon

o Dokumentasjon av systemets arkitektur og datadesign.

Prosess og metoder

o Beskriver prosesser, metoder og verktøy 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.

Page 12: Roommates: Rapport for hovedoppgave

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 måte 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 får data fra Facebook som blir

brukt til å registrere bruker.

Når 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 først 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 meldingsstrøm 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 måte, 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.

Page 13: Roommates: Rapport for hovedoppgave

Side 5 av 75

Hendelser skal også komme opp i en hendelses-strøm direkte i applikasjonen slik at brukere av

bofellesskapet kan gå igjennom alle hendelser som har vært.

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

strømmen.

Bruker skal kunne velge en hendelse fra hendelsesstrømmen 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.

Når en liste blir opprettet skal det opprettes en event i systemet som vises i hendelses-strømmen.

Hendelsen skal fortelle hvilken bruker som opprettet listen.

Funksjonelt krav #8: Bruker skal kunne gå inn på alle lister for å se listelementer og gjøre

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 gjøre 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 fullført.

Bruker skal kunne redigere navn, slette og markere lister som fullført.

Når en liste blir markert som fullført skal det opprettes en event i systemet som vises i hendelses-

strømmen. Hendelsen skal fortelle hvilken bruker som markerte listen som fullført.

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

fullført.

Bruker skal kunne redigere navn, slette og markere listeelementer som fullført.

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

Når noen har markert en liste som fullført, skal det være mulig å se i både hendelses-strømmen og i

liste-oversikten hvem som har markert listen som fullført.

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

fullført.

Når noen har markert et listelement som fullført, skal det være mulig å se inne på listen hvem som

har fullført 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.

Page 14: Roommates: Rapport for hovedoppgave

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.

Når en bruker har mottatt en invitasjon skal bruker kunne godta denne for å melde seg inn i

bofellesskapet.

Det skal kun være mulig å godta invitasjoner dersom bruker ikke allerede er medlem av et

bofellesskap.

Når en bruker får en invitasjon, skal dette varsles med en push-melding til bruker.

Når en bruker godtar en invitasjon, skal det opprettes en event i systemet om hendelsen som vises i

bofellesskapets hendelsesstrøm. 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.

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

som vises i bofellesskapets hendelsesstrøm. 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 når bruker skal legge til nytt utlegg hvor bruker fyller ut følgende

informasjon:

Navn på utlegg (påkrevd felt)

Beløpet tilsammen som skyldes (påkrevd felt)

Page 15: Roommates: Rapport for hovedoppgave

Side 7 av 75

Detaljer om utlegget (valgfritt felt)

Hvilke brukere som er skyldige i utlegget

Beløpet skal deles likt på alle som er med på utlegget.

Dersom bruker som legger til utlegget er satt opp til å være med på utlegget blir automatisk bruker

satt som ferdig betalt, da den som gjør utlegget allerede har betalt sin del.

Dersom bruker ikke skal være med på utlegget, men har betalt utlegget for noen andre, kan bruker

velge seg selv bort fra listen og da vil beløpet deles på de som faktisk skal betale.

Bruker som legger til beløpet er automatisk markert og blir satt som betalt.

Eksempel:

Beløp: 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 står 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

Beløp tilsammen

Detaljert tilleggsinformasjon om utlegget

Hvilke brukere som har betalt

Hvilke brukere som ikke har betalt

Hva hver enkelt bruker skylder (skal være samme beløp, da totalbeløpet blir delt på

brukere som er med på utlegget)

Funksjonelt krav #26: Bruker skal kunne gjøre 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 gjøre endringer på et utlegg. Alle andre brukere i bofellesskapet kan kun se

på utlegget, men ikke endre det.

Endringer som bruker skal kunne gjøre på sine egne utlegg:

Endre navn på utlegg

Endre beløp 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

Page 16: Roommates: Rapport for hovedoppgave

Side 8 av 75

2.2 Ikke-funksjonelle krav Ikke-funksjonelle krav er systemets egenskaper som sikkerhet, pålitelighet og tilgjengelighet.

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

Data som tilhører systemet, brukere, innlegg og annen informasjon, skal være lagret og være

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 være 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 være sikkert nok til at datainnbrudd på systemet ikke skal være 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 være sikkert nok til at datainnbrudd på systemet ikke skal være trivielt.

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

Ikke-funksjonelt krav #7: Ingen skal kunne gjøre ting på andres vegne.

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

Dersom bruker fullfører en liste skal det være tydelig hvem som har markert listen som fullført.

Bruker skal ikke ha tilgang til å endre andre brukeres utlegg.

Ikke-funksjonelt krav #8: Innholdet skal være tilgjengelig så ofte som mulig

Back-end må være responsiv nok til å kunne svare på forespørsler og levere data til de fleste tider.

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

Page 17: Roommates: Rapport for hovedoppgave

Side 9 av 75

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

undersøke teknologier og plattformer, samt utforske mulige alternativer. Disse skulle tilfredsstille

kravene som var satt, og være realistiske å bruke for prosjektgruppen (både i prosjekttiden og i

tiden etter prosjektet er ferdig).

3.1 Valg av plattformer For å kunne bruke en applikasjon som gjør bofellesskap enklere var det behov for en plattform som

var tilgjengelig "på farten". De fleste er på farten når ting skal gjøres 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 forståelse 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 verktøy for å lage profesjonelle applikasjoner, er meget populært, 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 være tilgjengelig på

de viktigste mobile plattformene. Klientene skulle være native for sin plattform, og samtidig være

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

utviklingsplattformene Xamarin eller Qt som fokuserer på å kjøre 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 støttet

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 løsning 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

måtte denne kunne integreres mot prosjektets valgte plattformer: Android og iOS. Dette tilbød

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

oppgaven.

Parse håndterer 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-støtte, men valgte

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

nylig som legger til bredere offlinestøtte til Android, og det er annonsert det samme til iOS i nær

fremtid. Dette betyr at det i fremtiden vil være enklere å implementere dette i prosjektet om det

skulle være ønskelig.

Andre alternativer som har vært oppe til diskusjon er Apstrata og Stackmob. Apstrata tilbyr

tilsvarende funksjonalitet som Parse, og kunne nok vært brukt for å dekke prosjektets krav. Til slutt

ble Parse valgt på grunn av en tilsynelatende bedre dokumentasjon og at de tilbød mer gratis bruk

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

Page 18: Roommates: Rapport for hovedoppgave

Side 10 av 75

sin tilsynelatende enklere dokumentasjon. Stackmob ble senere kjøpt 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 å være en dokumentasjon av systemets arkitektur og

datadesign. Designspesifikasjonen skal være 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

løpet av prosjektets løpetid.

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 løsning for back-end som heter Parse. Her ligger det databaseløsning

i form av NoSQL, brukerhåndtering (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 består av klienter.

Klientene har ikke alle data selv, men håndterer 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å håndtere noe automatisk kode i sin Cloud Code-modul. Cloud Code er kode som

kan kalles på fra klienten, men som ligger lagret og blir kjørt på Parse sine tjenere. Dette gjør at

man kan gjøre automatisk behandling av objekter sentralt, i stedet for å måtte implementere

logikken på alle klienter. Det gjør 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.

Page 19: Roommates: Rapport for hovedoppgave

Side 11 av 75

Klienten skal bygges opp av to deler. Den første er selve applikasjonen. Dette er klientkoden.

Denne håndterer 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-løsning som gjør det mulig å gjøre spørringer offline,

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

kommende forbedring i SDK'et).

SDK'et gjør all kommunikasjon mot back-end over HTTPS og SSL og sørger derfor for

tilstrekkelig sikkerhet under datahåndtering.

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 være é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-<Household.objectId>" (f.eks. hvis et nytt

household har id="UlKu48h8ZN" vil name-feltet til Role-objektet være "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 får 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 hører 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 følger med automatisk.

Visse felter er like for alle klassene og blir automatisk oppdatert og håndtert 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 å låse ned data.

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

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

Page 20: Roommates: Rapport for hovedoppgave

Side 12 av 75

Figur 2: Datadesign tegnet i UML

Page 21: Roommates: Rapport for hovedoppgave

Side 13 av 75

Datadesignet er bygd opp av klasser i Parse sin NoSQL-løsning. 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å være 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 å låse ned tilganger på alt som har

med et Household å gjøre. Siden medlemslisten til et Household ligger lagret i Household-ets

respektive Role får alle medlemmer tilgang til objekter hvor Role-en settes i ACL.

Spesielle felter i Role:

I Role-klassen finnes det en del felter som følger med, men som ikke er standard på vanlige Parse-

klasser.

roles (Relation<_Role>): En rolle kan være medlem av andre roller. Denne er ikke i bruk i

dette prosjektet.

users (Relation<_User>): 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-<Household.objectId>".

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 være et Role-

objekt som hører 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.

Page 22: Roommates: Rapport for hovedoppgave

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 følger med, men som ikke er standard på vanlige Parse-

klasser.

username(String): Brukernavnet til brukeren (skal være 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 (gjøres

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<_User>): Peker til brukeren som har opprettet objektet

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

Relasjoner i Note:

En Note skal ha 1 User

En Note skal ha 1 Household

Page 23: Roommates: Rapport for hovedoppgave

Side 15 av 75

4.3.5 Event Event-klassen beskriver en hendelse i et bofellesskap. Den brukes for å kunne vise en strøm av

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

over hendelses-strømmen.

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 følger:

0: Ny bruker i bofellesskapet

1: En bruker har forlatt bofellesskapet

2: Ny Liste (TaskList)

3: Liste har blitt markert som fullført

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 å avgjøre 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<Household): Peker til det bofellesskapet som hendelsen gjelder for.

user (Pointer <_User>): Peker til brukeren som hendelsen gjelder for.

objects (Array): Denne listen inneholder kun ett objekt. Objektets type er ikke bestemt på

forhånd, men kan castes til riktig type ved å bruke type. Objektet som ligger lagret her er

objektet som hendelsen omhandler. For eksempel ved en hendelse som handler om et

utlegg vil utlegget ligge lagret her slik at data fra utlegget kan hentes frem.

Relasjoner i Event:

En Event skal ha 1 Household

En Event skal ha 1 User

En Event skal ha 0-1 Expense eller TaskList (objects)

Page 24: Roommates: Rapport for hovedoppgave

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". Når en

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

for.

Egendefinerte felter i Invitation:

household (Pointer<Household>): Peker til det bofellesskapet som invitasjonen gjelder

for.

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

invitee (Pointer<_User>): 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 gjøremålslister 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 kjøpes 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<Household>): Peker til bofellesskapet som listen er laget for.

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

done (Boolean): En boolsk verdi som beskriver om listen er fullført 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

Page 25: Roommates: Rapport for hovedoppgave

Side 17 av 75

4.3.8 TaskListElement TaskListElement er underelementer av en TaskList. Disse er tenkt som gjøremål som kan utføres og

markeres som ferdige når de er blitt gjort. Mer informasjon under TaskList.

Egendefinerte felter i TaskListElement:

elementName (String): Navnet på elementet (for eksempel vaske badet eller kjøpe melk).

taskList (Pointer<TaskList>): Peker til listen som elementet hører til i.

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

finishedBy (Pointer<_User>): 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 å håndtere 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.

Når en push-melding skal lages, så gjøres det en spørring 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<_User>): Peker til brukeren som er logget inn på enheten

household (Pointer<Household>): 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)

Page 26: Roommates: Rapport for hovedoppgave

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 oppført i owed, mens de som skal være 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 nærmere beskrivelse av utlegget.

Egendefinerte felter i Expense:

name(String): Navnet på utlegget.

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

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

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

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

household(Pointer<Household>): Peker til householdet utlegget hører 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

Page 27: Roommates: Rapport for hovedoppgave

Side 19 av 75

5 Prosess og metoder Gruppen har benyttet flere prosesser, verktøy og metoder for å løse 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 å følge

gjennom utviklingen av prosjektet. En slik utviklingsprosess sørger for en strømlinjeformet

utvikling som er forutsigbar og tydelig. Det skal aldri være 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 forståelse av

et problem og utvikler denne i inkrementer frem til man har en ferdig løsning.

Hvert inkrement består hovedsakelig av fire deler: Kravspesifikasjon, designspesifikasjon,

utvikling og til slutt validering og testing. Ved starten på hvert nye inkrement går 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

gjøres 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 fører 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 nært beslektede iterativ utvikling og den mer

tradisjonelle waterfall-metoden da kravene på forhånd ikke var helt fastsatt og mest sannsynlig

ville endre seg i løpet av prosjektets utviklingstid.

Page 28: Roommates: Rapport for hovedoppgave

Side 20 av 75

5.1.2 Kodestandard Før 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 følger:

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 være for vidløftig og har ingen hensikt)

Page 29: Roommates: Rapport for hovedoppgave

Side 21 av 75

Layout-filer skal ha små bokstaver og ordene deles med understrek. Typen layout skal være første

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 være tabulatortegn, men i stedet bestå av 4 mellomromstegn.

Med andre ord:

Tab = 4 mellomrom

5.1.2.3 Krøllparentes-posisjon

Krøllparenteser skal settes på samme linje som funksjons- og klassenavn, med unntak av der

funksjons- og klassenavnene er så lange at de går over flere linjer.

Eksempler:

public void funksjon() { ... }

Figur 8: Riktig

private double annenFunksjon() { ... }

Figur 9: Feil

public void langtFunksjonsNavnSomMåDelesOverFlereLinjer(int index, double value) { ... }

Figur 10: Riktig bruk av unntak

public void langtFunksjonsNavnSomMåDelesOverFlereLinjer(int index, double value) { ... }

Figur 11: Feil bruk av unntak

Page 30: Roommates: Rapport for hovedoppgave

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 løsning med både

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, søke og bla seg igjennom nåværende og tidligere

versjoner av kildekoden sentralt, har gjort mange utviklingsoppgaver enkle.

5.1.4 Utviklingsverktøy Utviklingsverktøy er en vesentlig del av et prosjekt og mye tid har blitt brukt på å velge riktig

verktøy til jobben som skal gjøres. Verktøyene gjør arbeid lettere, øker produktivitet og er viktige

for at gruppens medlemmer skal trives i arbeidet. Dårlige verktøy kan felle store deler av et

prosjekt, mens gode og riktige verktøy kan fremme kvalitet.

Gruppen har i løpet av utviklingen brukt en rekke verktøy for å gjennomføre prosjektet - alt fra

integrerte utviklingsmiljøer (IDE) til verktøy for prosjektstyring og modellering av

brukergrensesnitt.

Verktøyene er valgt etter gruppens preferanser og hva som har passet best for prosjektet.

5.1.4.1 Integrerte utviklingsmiljøer (IDE)

Prosjektet har brukt mange programmeringsspråk 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 verktøy

som gjør utvikling av Android-applikasjoner lettere. (Getting Started with Android Studio, u.å.)

Android Studio har meget god støtte 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.

Page 31: Roommates: Rapport for hovedoppgave

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 støtte for WYSIWYG-editor (What You See Is What You Get) og

krever som regel Xcode for å gjøre elementære oppgaver som simulering.

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

applikasjon.

Xcode er en utviklingsplattform laget spesielt for utvikling til Apple sine produkter og gjør en

meget solid jobb på akkurat dette. Xcode har god støtte 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 måte.

Figur 13: Skjermdump Xcode

Page 32: Roommates: Rapport for hovedoppgave

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 kjøpes fra Apple Mac Store

og støtter en rekke programmeringsspråk til web.

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

denne fra før 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 verktøy

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 å gjøre

implementasjon av en sammensveiset brukeropplevelse enklere og lettere under utvikling og

implementasjon.

Brukergrensesnittmodelleringen er gjort i et verktøy for iPad som heter AppCooker. Dette

verktøyet har latt gruppen tegne opp brukergrensesnitt for iOS. Android sitt brukergrensesnitt er

oversatt med skjønn for å sørge 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

diagramverktøy relativt enkelt.

UML har spesifikasjoner som i mange applikasjoner er dårlig og mangelfullt implementert.

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

Diagrammer har først og fremst blitt brukt i designspesifikasjonsdokumentene for å beskrive

systemarkitektur og databasedesign.

Page 33: Roommates: Rapport for hovedoppgave

Side 25 av 75

Figur 15: Skjermdump LucidChart

5.1.5 Testing Testing er en viktig del av ethvert prosjekt, særlig 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 nivåer, basert på hva de tester og omfanget av testene.

Teknikkene for de forskjellige nivåene er mange og varierende. Det finnes ulike synspunkter på

hvilke nivåer av programvaretesting som er nødvendige og hvilke som er mest nødvendige. Det de

fleste dog er enige om er at testing er nødvendig.

Figur 16: Software Testing Nivåer (Software Testing Levels, u.å.)

Fire ofte brukte nivåer 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.

Page 34: Roommates: Rapport for hovedoppgave

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 oppfører 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 måte 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 løses ved å lage en etterligning av enheten

som laster ned informasjonen. Etterligningen vil oppføre seg på samme måte 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 høyt tidsbruk for å skrive testene. Skulle prosjektet bli dekket av enhetstester, ville ikke

resultatet blitt like godt gjennomført som det faktisk ble.

Denne delen beskriver forsøkene som ble gjort på implementasjon av enhetstesting, og hvilke

problemer som dukket opp.

Enhetstester ble forsøkt implementer tre ganger i løpet av prosjektet.

Page 35: Roommates: Rapport for hovedoppgave

Side 27 av 75

5.1.5.1.1.1 Første forsøk

I første forsøk ble enhetstestene skrevet uten å bruke Dependency Injection. Dette førte til tester

som hadde mange avhengigheter, som gjorde det tilnærmet umulig å garantere at en test fungerte

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

fort.

For at enhetstester skal være mest effektive bør de kunne kjøres ofte for å finne regresjoner i koden.

Dette ble vanskeligjort fordi det tok mange minutter å kjøre testene, selv for små mengder med

tester.

5.1.5.1.1.2 Andre forsøk

Etter at første forsøk måtte skrotes (slette alle tester og gå tilbake til ingen tester) var det fremdeles

et sterkt ønske om å ha enhetstesting som en del av prosjektet. Løsningen ble å bruke mer korrekte

enhetstester med bruk av Dependency Injection.

Før Dependency Injection kunne brukes måtte all logikk separeres inn i klasser og funksjoner med

Dependency Injection implementert. Dette var mye arbeid som kunne vært unngått om feilene i

første forsøk 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 å gjøre 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 førte til et forsøk 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 måtte 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 gjør at de ikke kan injiseres, og dermed heller ikke kan etterlignes. Dermed måtte i stedet

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

responsen fra Parse måtte pakker fra Parse sniffes ved bruk av nettverkssniffere. Dette lot seg gjøre

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 gjennomføres for et prosjekt av

denne størrelsen.

5.1.5.1.1.3 Tredje forsøk

I det tredje (og siste) forsøket var mye lært. Bruk av Dependency Injection var fremdeles

løsningen, men Parse sitt statiske API gjorde dette vanskelig.

Løsningen 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

gjennomføres, samt at nye tester måtte skrives.

Den nye løsningen 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.

Page 36: Roommates: Rapport for hovedoppgave

Side 28 av 75

Problemet kunne vært unngått 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 innebære 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 vært gjort ved å teste applikasjonen manuelt.

Testing av hele systemet har vært gjort flere ganger i løpet 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 gjør 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

avgjør om systemet følger 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 prøve 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 utført helt på slutten

av prosjektet. Feil som ble rapportert, er det eneste som er håndtert 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 være litt tvetydig.

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

prosjektet.

Page 37: Roommates: Rapport for hovedoppgave

Side 29 av 75

5.2 Prosjekt For at et prosjekt skal kunne utføres effektivt og pålitelig er det ofte behov for å bygge opp en

gruppestruktur, styrket av verktøy for prosjektstyring og informasjonsflyt. Gruppen har hele tiden

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

dette kapittelet følger gruppens oppbygning, samt de forskjellige verktøyene 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 særlige

ansvarsområder på de forskjellige medlemmene. De forskjellige ansvarsområdene 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

Håndtering av Beta-testing

5.2.2 Evernote Til felles notater og smådokumenter har Evernote fra Evernote Corporation blitt brukt.

Evernote er en kryssplattform notat-applikasjon. Den lar brukere lage notatbøker 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 smådokumenter underveis i prosjektet.

I den delte notatboken har det ligget mye informasjon som har vært greit å kunne referere til under

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

Page 38: Roommates: Rapport for hovedoppgave

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 når ting er

planlagt å starte, hvor lang tid det er planlagt å bruke på det og når det skal være 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

Page 39: Roommates: Rapport for hovedoppgave

Side 31 av 75

5.2.4 Prosjektstyringsverktøy 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 å gjøre 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.

Verktøyet har sørget for at gruppen har holdt en stø kurs hele tiden og fått gjort unna oppgaver

innen rimelig tid.

6 Resultat Resultatet av prosjektet er avgjort av produktet og prosjektets mål.

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 Produktmål Gruppen mener de har lykkes i å lage en applikasjon som oppfyller mesteparten av produktmålet,

og kan gjøre samboerskapssituasjoner enklere.

Gruppen har fått tilbakemeldinger på applikasjonen som bekrefter dette, men det er også mottatt

noen negative tilbakemeldinger. Disse går ut på at læringskurven for å komme i gang er litt bratt.

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

applikasjonen første gang man tar den i bruk. Allikevel mener gruppen at produktmålet er delvis

oppnådd.

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.

Page 40: Roommates: Rapport for hovedoppgave

Side 32 av 75

6.1.2.1 Samtidighet (Concurrency)

Begge klientene gjør nettverkskall utenfor hovedtrådene, men det er ikke implementert manuelt

med tråder 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 støtte for samtidighet, og bruker call-back's for å varsle klientene om at de er

ferdige med å laste ned og bearbeide.

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

Figur 23: Spørring i Android med Parse sitt API

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

Figur 24: Spørring i iOS med Parse sitt API

Android-koden i figur 23 og iOS-koden i figur 24 er bruker begge Parse sitt API for å gjøre

nettverkskall mot Parse sine tjenere. Begge har en call-back som blir utført når API'et er ferdig med

jobben den skal gjøre.

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. Når 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 gjør 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

Page 41: Roommates: Rapport for hovedoppgave

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 løpet av prosjektet, som en følge 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 behøvd å være, men har gjort at utviklingen av disse har gått

betydelig fortere. Dette er også måten Parse har gjort ting i sine eksempler og veiledninger.

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

klasse som håndterer bruker-input og viser feilmeldinger, og en lengre hjelpeklasse for å håndtere

selve innlogging og feil fra Parse sine tjenere. Dette ville vært 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

håndtering av brukerinput, kommunikasjon mot Parse, håndtering av feil og visning av disse til

bruker.

Å lage hjelpeklasser til alle interaksjoner mot Parse viste seg å være 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 løsning som er "perfekt" er ikke funnet for dette prosjektet.

Den beste løsningen ville vært å lage et lite sett med generiske hjelpeklasser. Dette var ikke noe

gruppen fikk tid til å gjennomføre.

Page 42: Roommates: Rapport for hovedoppgave

Side 34 av 75

6.1.2.3.2 MVC-mønsteret

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

program. Derfor er det et høynivå-mønster. MVC designmønsteret klassifiserer gjenstander etter de

generelle rollene de spiller i applikasjonen. Et MVC design-mønster 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 å være mer gjenbrukbare. Dette gjør at applikasjoner enklere kan

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

Controller, 2012)

I MVC designmønsteret 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 måter å implementere MVC i en iOS-applikasjon. Den mest ryddige måten er å

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

Controlleren. Dette har lett for å innebære svært 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 å gjøre

utvikling raskere og fordi det ikke var noen klare fordeler med å separere ut all logikken. Dette gjør

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

I en typisk skjerm kan View-delen være 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 være en liste med objekter som skal vises på skjermen på et eller annet

vis.

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

Page 43: Roommates: Rapport for hovedoppgave

Side 35 av 75

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

Figur 28: Definisjon av modeller

View Controlleren kan laste ned objektene fra Parse, oppdatere modellen med disse, og deretter få

View'et til å vise dataene på en bestemt måte.

6.1.2.3.3 Delegate-mønsteret

Delegate-mønsteret er et programmeringsmønster hvor et objekt, i stedet for å gjør en oppgave

selv, delegerer oppgaven til et annet objekt. Dette brukes av mange av brukergrensesnittelementene

i iOS og har vært mye brukt i dette prosjektet. Et godt eksempel på dette er UITableView som er et

element som viser data i en tabell på skjermen.

UITableView har to delegate-protokoller som definerer et sett med funksjoner (valgfrie og

obligatoriske) som må implementeres for å få vise data. Disse er UITableViewDataSource og

UITableViewDelegate.

UITableViewDataSource er en delegate som håndterer forespørsler for data som skal vises i

tabellen. Eksempler på funksjoner i denne protokollen er "numberOfSectionsInTableView",

"titleForHeaderInSection" og "cellForRowAtIndexPath".

#pragma mark - Table view data source - (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView { return 2; } - (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section { if (section == TASK_LIST_UNFINISHED_SECTION) { return self.unfinishedTaskLists.count; } else if (section == TASK_LIST_FINISHED_SECTION) { return self.finishedTaskLists.count; } } - (NSString *)tableView:(UITableView *)tableView titleForHeaderInSection:(NSInteger)section { if (section == TASK_LIST_UNFINISHED_SECTION) { return @"Tasks"; } else if (section == TASK_LIST_FINISHED_SECTION){ return @"Finished Tasks"; } } - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { // Get cell ... // Set up cell ... return cell; }

Figur 29: Delegate-metoder for UITableViewDataSource

Koden i figur 29 viser disse funksjonene implementert for Task Lists i Roommates. Siden det er to

seksjoner i tabellen (en for ferdige lister, og en for uferdige) returnerer

"numberOfSectionsInTableView" tallet 2. I "titleForHeaderInSection" sjekkes det hvilken seksjon

det er forspurt om og returnerer en tittel som skal vises i tabellen. I "cellForRowAtIndexPath" blir

det hentet ut en celle fra en gjennbrukskø, deretter finner den en Task List, basert på hvilken rad og

seksjon forespørselen handler om, og setter cellens data til data fra Task List'en.

Page 44: Roommates: Rapport for hovedoppgave

Side 36 av 75

UITableViewDelegate er en delegate for å håndtere forskjellige oppgaver som har med visningen

av tabellen og brukerinteraksjoner å gjøre.

Eksempler på funksjoner som er definert i UITableViewDelegate er "didSelectRowAtIndexPath",

"didBeginEditingRowAtIndexPath" og "shouldShowMenuForRowAtIndex". Alle disse håndterer

forskjellige ting som kan skje i en tabell. Ved å implementere disse kan man få tabellen til å

oppføre seg akkurat som man vil.

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath { if (indexPath.section == SETTINGS_SECTION) { if (indexPath.row == HOUSEHOLD_SETTINGS_ROW) { ... } else if (indexPath.row == LOGOUT_ROW) { ... } } }

Figur 30: Delegate-funksjon: didSelectRowAtIndexPath

Koden i figur 30 håndterer brukerens markering av en rad i tabellen. Basert på hvilken rad og

seksjon det er, utføres forskjellige oppgaver.

6.1.2.3.4 Observer-mønsteret

Et mindre brukt mønster i iOS-sammenheng er observer-mønsteret. Dette

programmeringsmønsteret baserer seg ganske enkelt på at objekter setter seg som observatører for

en spesiell type melding hos en meldingssentral. Deretter kan andre objekter sende meldinger via

meldingssentralen, som blir distribuert til alle observatører som er satt opp for den type meldinger.

(Observer pattern, u.å.)

Observer-mønsteret er brukt i prosjektet for å informere skjermer om endringer av data som er gjort

i andre skjermer. For eksempel sendes det en melding om at alle skjermer må resettes når bruker

logger ut av applikasjonen eller melder seg ut av en husholdning.

Dette gjøres ved at alle skjermer som trenger å resette seg selv ved en slik hendelse melder seg opp

hos NSNotificationCenter (som er en meldingssentral i iOS).

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(didReceiveResetHouseholdScenesNotification:) name:@"ResetHouseholdScenes" object:nil];

- (void)didReceiveResetHouseholdScenesNotification:(NSNotificationCenter *)notificationCenter { [self refreshTaskLists]; }

Figur 31: Oppsett av objekt som observatør i NSNotificationCenter

Koden i figur 31 viser hvordan en View Controller melder seg opp som observatør for meldinger

som heter "ResetHouseholdScenes".

For å sende meldingene, sender objektet som kan si ifra om at alle skjermene må resette seg selv,

en melding til NSNotificationCenter.

// Send a notification for the scenes to be reset [[NSNotificationCenter defaultCenter] postNotificationName:@"ResetHouseholdScenes" object:nil];

Figur 32: Sending av melding til NSNotificationCenter

Page 45: Roommates: Rapport for hovedoppgave

Side 37 av 75

Koden i figur 32 sender en melding til NSNotificationCenter med navn "ResteHouseholdScenes".

Alle observatører som har meldt seg opp til denne typen meldinger, får melding om dette.

6.1.2.3.5 Bruk av Parse sitt API

Parse sitt SDK inneholder et API som lar utviklere utføre spørringer og andre interaksjoner mot

Parse sine tjenere (som for eksempel å logge inn en bruker).

For å få tilgang til prosjektets data, blir det gitt en applikasjons-id og en klientnøkkel til API'et.

Dette sørger også for at uautoriserte ikke får tilgang til prosjektets data.

// Set up Parse: [Parse setApplicationId:@"****************hidden******************" clientKey:@"****************hidden******************"];

Figur 33: Oppsett av Parse

Etter at Parse sitt API er satt opp kan, klienten bruke API'et for å hente data fra Parse sine tjenere.

For eksempel kan klienten laste ned utlegg fra bofellesskapet til brukeren som er logget inn.

- (void)refreshExpenses { if ([[User currentUser] isMemberOfAHousehold]) { // Set up query PFQuery *expensesQuery = [Expense query]; [expensesQuery whereKey:@"household" equalTo:[User currentUser].activeHousehold]; [expensesQuery orderByDescending:@"updatedAt"]; // Also download pointers to: [expensesQuery includeKey:@"owed"]; [expensesQuery includeKey:@"notPaidUp"]; [expensesQuery includeKey:@"paidUp"]; [expensesQuery findObjectsInBackgroundWithBlock:^(NSArray *objects, NSError *error) { if (!error) { // Sort expenses ... // Set models ... // Update UI ... } }]; } else { // No user or not member of a household // Set empty models ... // Update UI ... } }

Figur 34: Spørring mot Back-end med Parse sitt API

Koden i figur 34 setter først en spørring med PFQuery, som er en del av Parse sitt API. Når

spørringen er satt opp, utføres selve spørringen med metoden

"findObjectsInBackgroundWithBlock", som tar en kodeblokk som argument. Kodeblokken sorterer

dataene og legger de i modellene, og deretter sender melding til en UITableView om at tabellen

trenger å oppdateres (siden modellene nettopp har blitt oppdatert).

Parse tilbyr også enkle metoder for registrering og innlogging av brukere.

[User logInWithUsernameInBackground:username password:password

Page 46: Roommates: Rapport for hovedoppgave

Side 38 av 75

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

Figur 35: Innlogging med Parse sitt API

Koden i figur 35 viser den statiske metoden "logInWithUsernameInBackground:password:block"

som tar brukernavn, passord og en kodeblokk som argumenter.

Parse håndterer selve innloggingen. Når den er ferdig, blir koden i kodeblokken kjørt. Der kan man

håndtere eventuelle feil, gjøre endringer på brukeren og vise et brukergrensesnitt for innloggede

brukere.

6.1.2.3.6 Tredjepartsbiblioteker

Under utviklingen har det dukket opp behov for funksjonalitet som har vært vanskelig og

tidkrevende å implementere selv. Dersom det har vært mulig, har tredjepartbiblioteker blitt tatt i

bruk.

Eksempel på dette er framdriftsindikatoren SVProgressHUD.

Ved tidskrevende oppgaver (som for eksempel innlogging) som må blokkere touch-events, har det

vært behov for å vise en indikasjon på at applikasjonen jobber. SVProgressHUD viser en

animasjon med en statustekst, og har mulighet for å samtidig blokkere touch-input. Figur 36

demonstrerer dette.

Figur 36: SVProgressHUD

[SVProgressHUD showWithStatus:@"Logging in" maskType:SVProgressHUDMaskTypeBlack]; [User logInWithUsernameInBackground:username password:password block:^(PFUser *user, NSError *error) { [SVProgressHUD dismiss]; ... }];

Figur 37: SVProgressHUD API

Koden i figur 37 starter opp SVProgressHUD med status "Logging in" og en maskType som

blokkerer touch-input. Når innloggingen med Parse sitt API er ferdig, fjernes SVProgressHUD fra

skjermen.

Page 47: Roommates: Rapport for hovedoppgave

Side 39 av 75

6.1.2.4 Cloud Code

All Cloud Code er skrevet i JavaScript, og bruker Parse sitt JavaScript SDK.

6.1.2.4.1 Struktur

Cloud Code er JavaScript, så det kan struktureres på samme måte som JavaScript-filer. All

kildekode til Cloud Code-delen er lagt inn i ett dokument som heter main.js. Her ligger alle

metodene som er definert til å brukes.

Koden kunne med fordel vært fordelt ut over flere filer med hjelpefunksjoner for å hindre

overdreven repetering av kode. Grunnet gruppens manglende kunnskap om JavaScript i

begynnelsen av prosjektet har dette ikke blitt gjort.

6.1.2.4.2 Metoder

Prosjektet har benyttet seg av to typer Cloud Code-metoder. Den ene er vanlige metoder som kan

kalles på direkte fra klientene, den andre er hooks som kjøres automatisk når en hendelse skjer på

data (for eksempel før og etter lagring av objekter).

/* Function for inviting a user to a household * * Input: * "username" : usernameString, * "householdId" : householdIdString * * Output: * String with information about the result (Can be shown to user) */ Parse.Cloud.define("inviteUserToHousehold", function(request, response) { ... }

Figur 38: Definisjon av Cloud Code-metode

Koden i figur 38 viser hvordan en vanlig funksjon blir definert i Cloud Code. Denne kan kalles på

dirkete fra klientene. Funksjonen som kjøres tar to objekter som argumenter, request og response.

Request-objektet inneholder data fra den som kalte på funksjonen. Response-objektet er det som

blir brukt til å sende data tilbake til den som kalte på funksjonen.

/* Before Delete for TaskList. * This hook is called every time someone tries to delete a task list * It makes sure that all task list elements and events that points to * the task list are also deleted. */ Parse.Cloud.beforeDelete("TaskList", function(request, response) { ... response.success(); }

Figur 39: Definisjon av "før-slett" hook

Koden i figur 39 viser hvordan en hook som skal kjøres etter sletting av et objekt, defineres.

Funksjonen som kjøres, tar to objekter som argumenter, request og response. Request-objektet

inneholder objektet som skal slettes. Response-objektet er det som blir brukt til å gi beskjed om at

objektet er klart for å slettes.

Prosjektet har brukt flere funksjoner for å gjøre ting som ville krevet mye dobbel implementasjon

på klientene. Disse funksjonene er:

"createNewHousehold": Funksjon som oppretter et nytt bofellesskap, setter opp

sikkerheten og legger til brukeren som kalte på funksjonen som medlem.

"leaveHousehold": Funksjon som fjerner brukeren som kalte på funksjonen fra

bofellesskapet. Den sørger for å fjerne alle rettigheter som bruker har hatt i bofellesskapet.

Page 48: Roommates: Rapport for hovedoppgave

Side 40 av 75

"inviteUserToHousehold": Funksjon som lar bruker av et bofellesskap invitere andre

brukere til bofellesskapet. Den tar seg av invitasjonen, push-melding og sikkerhet.

"acceptInvitationToHousehold": Funksjon som lar bruker godta en invitasjon. Den melder

brukeren inn i bofelleskapet og sørger for at riktige rettigheter blir satt.

I tillegg til funksjonene som er definert, er alle push-meldinger sendt fra Cloud Code når det gir

mening. For eksempel når en bruker lager en ny felles beskjed, sørger afterSave på Notes for at en

push-melding blir sendt til alle andre brukere av bofellesskap om den nye felles beskjeden.

6.1.2.5 Android

Koden til Android er skrevet i Java og i XML, og Android Studio er brukt som utviklingsverktøy. I

dette kapittelet vil det fokuseres på prosjektets struktur og noen teknikker som er benyttet under

utviklingen.

6.1.2.5.1 Android manifest

AndroidManifest.xml er en fil i rot-mappen til prosjektet. Denne inneholder info om navnet på

applikasjonen, hvilke aktiviteter den består av, og hva slags tillatelser applikasjonen trenger for å

kjøre.

Alle aktiviteter er deklarert i manifestet. I tillegg til navnet på aktiviteten er det også et element

som forteller om aktiviteten skal være låst i portrettmodus.

<activity

android:name=".Expenses.NewExpenseActivity"

android:screenOrientation="portrait"/> Figur 40: XML for å låse applikasjon i portrettmodus

Videre er det satt et intent-filter på LoginActivity. Dette er for at denne aktiviteten skal startes når

applikasjonen startes. En Android-applikasjon har ingen main()-metode, så derfor er det dette som

bestemmer hva som starter når applikasjonen blir kjørt.

<intent-filter>

<action android:name="android.intent.action.MAIN" />

<category android:name="android.intent.category.LAUNCHER" />

Figur 41: Definert entry point for applikasjonen

Page 49: Roommates: Rapport for hovedoppgave

Side 41 av 75

Videre er det også deklarert hvilke tillatelser applikasjonen trenger. Når en bruker installerer

applikasjonen, er han nødt til å godta at applikasjonen får disse tillatelsene.

// Necessary for changing profile picture

<uses-feature android:name="android.hardware.camera"

android:required="true" />

<uses-permission

android:name="android.permission.READ_EXTERNAL_STORAGE"/>

<uses-permission

android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

// Necessary for application to connect to internet

<uses-permission android:name="android.permission.INTERNET" />

<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"

/>

// Necessary for push to work properly

<uses-permission android:name="android.permission.WAKE_LOCK" />

<uses-permission android:name="android.permission.VIBRATE" />

<uses-permission

android:name="android.permission.RECEIVE_BOOT_COMPLETED" />

<uses-permission

android:name="com.google.android.c2dm.permission.RECEIVE" />

// Necessary for facebook-login

<uses-permission android:name="android.permission.GET_ACCOUNTS" />

Figur 42: Tillatelser i Android manifest

I manifestet er det også definert hvilken versjon av API-et som er nødvendig for å kunne ta

applikasjonen i bruk. Her er det definert API 14 som et minimum. Dette er Android versjon 4.0,

mens nyeste versjon av Android i dag er Android 4.4. Dette betyr at om man har en Android-enhet

som har en tidligere versjon enn 4.0, kan ikke applikasjonen brukes.

6.1.2.5.2 Struktur

Vi kan dele de forskjellige klassene inn i fire kategorier:

Aktiviteter og fragmenter

Subklasser av Parse

Hjelpeklasser

Listeadaptere

Aktiviteter og fragmenter er klassene som inneholder de grafiske elementene i applikasjonen. I

Roommates brukes fragmentene i et swipe view hvor man kan dra til siden for å bla til neste side.

Det er totalt fire fragmenter i applikasjonen. Dette er Feed, Me, Tasks og Expenses. Om man

trykker seg videre inn i applikasjonen fra en av disse, blir man tatt inn i en aktivitet. Når en ny

aktivitet blir opprettet, kalles metoden onCreate(). I figur 43 kan man se en typisk onCreate-

metode. Først hentes layouten fra en XML-fil. Deretter deklareres de forskjellige brukergrensesnitt-

elementene som objekter, før en spørring mot databasen utføres. Når spørringen er fullført kan

brukergrensesnitt-elementene fylles med dataene man har mottatt.

Page 50: Roommates: Rapport for hovedoppgave

Side 42 av 75

@Override

public void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_view_expense);

expenseNameView = (TextView) findViewById(R.id.expenseTextViewName);

expenseOwedView = (TextView) findViewById(R.id.expenseTextViewOwed);

expenseAmountView = (TextView)

findViewById(R.id.expenseTextViewAmount);

expenseDetailsView = (TextView)

findViewById(R.id.expenseTextViewDetails);

listView = (ListView) findViewById(R.id.listViewExpenseUsers);

final ProgressDialog progress =

ProgressDialog.show(ViewExpenseActivity.this, "Loading expense" , "

Please wait ... ", true);

final Context context = this;

String objectId = (String) getIntent().getExtras().get("expenseID");

ParseQuery<Expense> query = new ParseQuery<Expense>("Expense");

query.include("owed");

query.include("notPaidUp");

query.include("paidUp");

query.setCachePolicy(ParseQuery.CachePolicy.CACHE_THEN_NETWORK);

LocalBroadcastManager broadcastManager =

LocalBroadcastManager.getInstance(this);

broadcastManager.registerReceiver(mMessageReceiver, new

IntentFilter("expense-need-to-refresh"));

query.getInBackground(objectId, new GetCallback<Expense>() {

// Get query and set UI-elements accordingly

}

}

Figur 43: onCreate() fra ViewExpenseActivity.java

Subklassene for Parse er klasser for å hente ut data fra tabellene i databasen på en måte som er mer

lik slik man vanligvis håndterer objekter i Java. Disse klassene inneholder gettere og settere for alle

de relevante feltene for sin tabell i Parse, og de arver fra klassen ParseObject. Databasedata

behandles derfor som vanlige objekter. Et eksempel kan man se i figur 44. Her oppretter man et

nytt objekt, setter verdiene det skal ha, før man til slutt lagrer objektet. Dette viser styrkene til Parse

og dets NoSQL-database. Man slipper å skrive kompliserte spørringer, i stedet kan man bruke

programmeringsspråket på den måten man er vant til.

Page 51: Roommates: Rapport for hovedoppgave

Side 43 av 75

Expense expense = new Expense();

expense.setNotPaidUp(notPaidList);

expense.setPaidUp(paidList);

expense.setHousehold(User.getCurrentUser().getActiveHousehold());

expense.setDetails(description);

expense.setTotalAmount(totalAmount);

expense.setOwed(User.getCurrentUser());

expense.setName(expenseName);

expense.saveInBackground(new SaveCallback() {

@Override

public void done(ParseException e) {

// Finishing the activity and returns to the first activity on

the backstack.

ToastMaker.makeLongToast("Expense was saved",

getApplicationContext());

finish();

}

});

Figur 44: Modifisering av Parseobjekter

Det er skrevet noen hjelpeklasser til applikasjonen. ToastMaker er en klasse for å vise små

meldinger, eller "toasts" på skjermen. FacebookProfilePictureDownloader er en klasse som arver

fra AsyncTask. Dette gjør at arbeidet denne klassen gjør, kan utføres i bakgrunnen, slik at man ikke

låser hovedtråden. InputValidation brukes for å sjekke at skjemaer er fylt ut med gyldige verdier.

Her brukes regulære uttrykk (regex) for å sjekke at et passord tilfredsstiller kravene som er satt til

dette.

Den siste typen klasser i prosjektet er adaptere. Dette er klasser som fungerer som en bro mellom

listeelementer og dataene disse skal fylles med. I applikasjon er det mange steder hvor det listes

opp data. En ListView-komponent får da et adapter satt på seg, og adapteret tar imot en datakilde og

presenterer dette i ListViewet.

Et adapter arver fra BaseAdapter, og her kan man overstyre metoder fra denne klassen hvis man vil

gjøre endringer. I metoden getItemView() kan man sette en layout på hvert eneste listeelement og

presentere dataene på en ryddig måte. I figur 45 kan man se hvordan getItemView() overstyres for å

vise info om en bruker i en liste.

Page 52: Roommates: Rapport for hovedoppgave

Side 44 av 75

@Override

public View getItemView(User user, View view, ViewGroup parent) {

if (view == null) {

view = View.inflate(getContext(),

R.layout.list_household_members_layout, null);

}

super.getItemView(user, view, parent);

// Add and download the image

ParseImageView profilePic = (ParseImageView)

view.findViewById(R.id.icon);

ParseFile imageFile = user.getProfilePicture();

if (imageFile != null) {

profilePic.setParseFile(imageFile);

profilePic.loadInBackground();

}

// Add the title view

TextView titleTextView = (TextView) view.findViewById(R.id.text1);

titleTextView.setText(user.getDisplayName());

titleTextView.setTextColor(Color.BLACK);

TextView emailTextView = (TextView)

view.findViewById(R.id.textViewUserEmail);

emailTextView.setTextColor(Color.BLACK);

emailTextView.setText(user.getEmail());

return view;

}

Figur 45: getItemView fra HouseholdMembersAdapter

Prosjektet inneholder også en klasse som arver fra Application. Denne klassens onCreate()-metode

blir kalt før noe som helst annet skjer på klienten. I denne klassen autentiseres linken mot Parse ved

hjelp av en applikasjons-ID og en nøkkel.

6.1.2.5.3 XML

I utviklingen av Android-applikasjonen har gruppen brukt XML for å definere layout. Hvert

skjermbilde har en XML-fil tilknyttet som inneholder informasjon om hva slags brukergrensesnitt-

elementer som skal være på skjermen, dets egenskaper og plasseringen på skjermen. Ved å separere

brukergrensesnitt og funksjonalitet kan man skrive mer oversiktlig kode, i tillegg til at det er lettere

å endre på brukergrensesnittet i ettertid.

Layout-filene kan deles inn i tre kategorier. Hver aktivitet og hvert fragment har en tilhørende

layout-fil for å definere brukergrensesnittet. I tillegg er det produsert filer for å definere dialoger,

samt hvordan listeelementer skal se ut. Menylinjen øverst i applikasjonen tar også i bruk XML-

ressurser for å vise de forskjellige knappene knyttet til forskjellige menyer. Figur 46 viser hvordan

XML blir brukt for å definere layout til et listelement.

Page 53: Roommates: Rapport for hovedoppgave

Side 45 av 75

<LinearLayout

android:orientation="horizontal"

android:layout_width="fill_parent"

android:layout_height="fill_parent">

<com.parse.ParseImageView

android:id="@+id/icon"

android:layout_width="60dp"

android:layout_height="60dp"

android:layout_alignParentLeft="true"

android:layout_marginLeft="15dip"

android:layout_marginRight="15dip"

android:src="@drawable/placeholder" />

<LinearLayout

android:orientation="vertical"

android:layout_width="fill_parent"

android:layout_height="fill_parent">

<TextView

android:id="@+id/text1"

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:textSize="20sp"

android:layout_alignTop="@+id/icon"

android:layout_toRightOf="@id/icon"

android:text="Test Testesen" />

<TextView

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:textAppearance="?android:attr/textAppearanceMedium"

android:id="@+id/textViewUserEmail"

android:text="[email protected]" />

</LinearLayout>

Figur 46: Utdrag fra list_household_members_layout.xml

Page 54: Roommates: Rapport for hovedoppgave

Side 46 av 75

6.1.3 Brukergrensesnitt Design av brukergrensesnitt foregikk i to stadier. Det første var å lage en brukergrensesnitts-modell

ved hjelp av applikasjonen AppCooker til iPad, og det andre var å implementere brukergrensesnittet

i koden. AppCooker var til stor hjelp i implementeringen av applikasjonen og gav et solid grunnlag

for hvordan applikasjonen skulle se ut. Den gjorde det enkelt å vite hva enkelte scener

(iOS)/activities (Android) skulle inneholde. Det måtte gjøres endringer i brukergrensesnittet fra

AppCooker til selve applikasjonen for å tilpasse brukergrensesnittet til plattformene.

Figur 47: Skjermbilde fra AppCooker-modell

Figur 48: Skjermdump fra iOS applikasjonen

For eksempel måtte skjermbildet Feed endres. Opprinnelig ønsket gruppen at øverste del på

skjermen skulle kunne dras horisontalt, for å se forskjellige notes. Denne funksjonen måtte

umiddelbart fjernes fra Android (og senere fra iOS) på grunn av at en implementasjon av dette i

Android hadde vært ikke-trivielt sammenlignet med iOS (som har dette som et standard

brukergrensenitt-element).

Gruppen ønsket en applikasjon som ikke nødvendigvis var helt lik på iOS og Android, men at den

hadde den samme funksjonaliteten. Spørsmålet om å skrive brukergrensesnittet i HTML og CSS

ble tidlig stilt, men valget falt på å ta i bruk teknologiene som er skreddersydd for hver enkelt

plattform. Gruppen ønsket å ta vare på det som brukere liker med både Android og iOS, og ta i

bruk ressurser som erfarne designere har jobbet med lenge. Gruppen ønsket å lage en applikasjon

for Android og iOS som brukere kan kjenne seg igjen i og som har et brukergrensesnitt som følger

designprinsippene til begge plattformene, hver for seg.

Page 55: Roommates: Rapport for hovedoppgave

Side 47 av 75

6.1.3.1 Applikasjonens Innhold

I denne seksjonen forklares det hvilke komponenter som er i bruk i de forskjellige scenene i

applikasjonen og hvordan de henger sammen.

En scene kan tenkes å være et skjermbilde eller "område" i applikasjonen.

I applikasjonen har alle scenen og komponentene felles at bruker og bofellesskap er konstant så

lenge man er logget inn og medlem av et bofellesskap. Scenene er ikke tilgjengelige dersom dette

ikke er tilfelle (med unntak av Me, som er tilgjengelig så lenge man er logget inn).

I applikasjonen er det definert 4 scener: Feed, Me, Tasks og Expenses.

6.1.3.1.1 Feed

Feed-scenen er en skjerm som viser et overblikk over bofellesskap og hva som har skjedd i

bofellesskapet. Nye hendelser vises i en generert hendelsesstrøm. Det vil si at nye hendelser hentes

frem via spørringer. Denne viser nye medlemmer av bofelleskapet, nye utlegg, nye lister og andre

hendelser som er knyttet til det aktive bofellesskapet.

Det vises også et område for felles notater. Her vises det nyeste felles beskjeder, samt mulighet for

å se eldre beskjeder.

Dette fungerer som en inngang for applikasjonen og gir et overblikk over det siste som har skjedd,

slik at man ikke må lete i gjennom resten av applikasjonen for å finne ny informasjon.

6.1.3.1.2 Me

I Me-scenen er det mulig å se informasjon om innlogget bruker, aktivt bofellesskap, samt endre

disse. Det er også her man kan registrere nytt bofellesskap, invitere andre til bofellesskapet og

motta invitasjoner fra andre til deres bofellesskap.

6.1.3.1.3 Tasks

I Tasks-scenen kan man håndtere lister som hører til bofellesskapet. Når man går inn på Tasks, ser

man en liste over listene som er laget. Deretter kan man trykke seg videre inn på en liste for å se

listens gjøremål.

Man kan se på Tasks som lister over lister. Man får se en liste over hvilke lister som finnes i

bofellesskapet og kan gå inn på disse for å se selve gjøremålslisten.

Eksempler på lister kan være handlelister, vaskelister, generelle gjøremålslister eller andre lister

som bofellesskapet har behov for.

6.1.3.1.4 Expenses

I Expenses-scenen kan man se og håndtere utlegg som er gjort internt i husholdningen. Når man går

inn på Expenses, vil man få en liste over uoppgjorte og oppgjorte utlegg. Man får også informasjon

om hvilke utlegg man skylder penger for, og eventuelt hvor mye. I tillegg får man informasjon om

hvor mye andre skylder deg for utlegg.

Page 56: Roommates: Rapport for hovedoppgave

Side 48 av 75

6.1.3.2 Navigasjon

For å navigere rundt i applikasjonen har gruppen valgt å bruke Swipe View With Tabs (Android) og

TabBar NavigationController (iOS). Dette er en flat struktur som også gir brukeren muligheten til

å gå til hvilken som helst hoveddel av applikasjonen med bare ett trykk. (Navigation, u.å.) Dette er

hovedmåten å navigere rundt i applikasjonen på. Gruppen oppdaget tre forskjeller mellom Swipe

View With Tabs og TabBar NavigationController:

1. På Android kunne man dra horisontalt mellom hoveddelene av applikasjonen, men dette er

ikke mulig på iOS.

2. Det er brukt ikoner på iOS og tekst på Android. Ikonene er standard for iOS.

3. Den ligger nederst på skjermen på iOS, mens den ligger øverst på skjermen på Android.

Dette skyldes at softkeys i Android ligger nederst på skjermen og brukere har da lett for å

trykke feil.

Gruppen var veldig sikre på valget av navigasjonsmetode, men vurderte også andre alternativer

som for eksempel Navigation Drawer (Android) og SlideOverViewController (iOS). Dette

alternativet ble primært sett på fordi Facebook applikasjonen brukte dette og fordi det er populært

på Android. Gruppen følte også at Navigation Drawer var for tidkrevende for brukeren, ved at

brukeren måtte ha trykket to ganger for å navigere seg til en annen scene i applikasjonen.

ListView (Android) og UITableView Controller ble brukt for å navigere videre fra hoveddelene til

underdeler av applikasjonen. Årsaken til at dette ble brukt, er fordi det er en enkel måte å

presentere data på og iOS har god støtte for UITableView Controller. I tillegg har Parse mulighet

for ferdigløsninger til både UITableView Controller og Adapter til ListView.

Applikasjonen er også laget for iPad, brukergrensesnittet er skalert opp for å tilpasse den større

skjermen. All kode er lik for både iPhone og iPad versjonene.

6.1.3.3 Fonts og farger

Gruppen har brukt standard font for begge plattformene på applikasjonen. Dette for å være i tråd

med designprinsippene til både iOS og Android. Gruppen studerte hvilke valg som finnes, men ble

etter hvert enige i at standard font var det sikreste valget for å ikke ødelegge den native følelsen

som gruppen ønsket at applikasjonen skulle ha.

Page 57: Roommates: Rapport for hovedoppgave

Side 49 av 75

Figur 49: Skjermdump - Innlogging iOS

Figur 50: Skjermdump - Innlogging Android

Applikasjonen består primært av fire farger: sort, lysegrått, hvitt og blått. Sort er fargen for tekst,

hvitt er bakgrunnsfarge, lysegrått er bakgrunnsfarge på UITableView Controller og ListView. Blått

er fargen på innloggingsskjerm, applikasjonsikon, og knapper. Fargene har forskjellige nyanser på

tvers av plattformene. Dette ble gjort for å beholde den native følelsen ved bruk av standardfarger

til Android og iOS. Det eneste fargevalget gruppen har gjort, er fargen blå. Valget sto mellom blå

og lilla, men gruppen bestemte seg for blåfargen på grunn av at blå er i standardfargene til både

iOS og Android (noe lilla ikke er). Blåfargen passer også godt til hvitt, sort og grått.

6.1.3.4 Forskjeller

Figur 51: Skjermdump iOS

Figur 52: Skjermdump Android

Page 58: Roommates: Rapport for hovedoppgave

Side 50 av 75

Som vist i figur 51 og 52, er én forskjell farger. Det er som tidligere forklart at Android og iOS

bruker forskjellige nyanser av en farge. Android bruker en blåfarge på knappene ”Household

Settings”, ”Profile Information Settings” og ”Log out”. Dette på grunn av at det ikke er et ikon helt

til høyre på skjermen (slik som det er på iOS), og også for å presisere at det faktisk er knapper.

På figur 51 og 52 ser vi også to forskjeller som har samme forklaring: profilbildet og ”Change

Password”. På Android finner man ”Change Password” under ”Profile Information Settings”.

Begge disse forskjellene skyldes manglende kommunikasjon mellom utviklerne. Resultatet ble at

gruppen var fornøyd med begge alternativene og ikke ville kvitte seg med noen av dem.

Manglende kommunikasjon er også årsaken til at fremvisningen av medlemmer i et ”Household” er

forskjellig på plattformene. På Android skjer dette under ”Household Settings”, mens på iOS finnes

det en egen skjerm til dette. Utviklerne til iOS følte det var for lite skjermplass til å ha listen av

medlemmer på ”Household Settings”-skjermen, mens utviklerne til Android følte det var nok plass.

Dette kan ha en sammenheng med at de fleste Android-enheter har større skjerm enn iOS-enheter.

Figur 53: Skjermdump iOS

Figur 54: Skjermdump Android

Android og iOS har noen forskjeller som skyldes manglende kommunikasjon eller ønske om å

beholde den native følelsen, men gruppen mener at brukere kan få samme opplevelse av

applikasjonen uavhengig av plattform.

Page 59: Roommates: Rapport for hovedoppgave

Side 51 av 75

6.2 Prosjekt

6.2.1 Prosjektmål Gruppens prosjektmål var å utvikle et produkt som fungerer og som kan brukes til daglig. Systemet

skulle synkronisere over skyen, være tilgjengelig for så mange brukere som mulig og være lett å

bruke.

Gruppen ønsket også å tilegne seg kunnskap om større programvareprosjekter som er relevant i

forhold til en arbeidslivssituasjon. Disse målene føler gruppen er nådd og tilfredsstilt.

Prosjektet har resultert i et fungerende produkt som følger kravene som er stilt. Gruppen har

samtidig fått nye perspektiver på utvikling, særlig i forhold til større prosjekter som innebærer flere

mennesker i et team.

6.2.2 Tidsbruk Da gruppen skulle planlegge tidsbruken i prosjektet, var det vanskelig å se for seg hvor mye tid ting

ville ta. Tidsbruken på planlegging og det første inkrementet tok betydelig mer tid enn antatt. Det

gjorde også selve utviklingen.

For å se forskjellene på planlagt tidsbruk og faktisk tidsbruk, er Gantt-diagrammer for dette nyttig.

Figur 55 viser det planlagte tidsbruket. Sett i forhold til Figur 56 som viser det faktiske tidsbruket,

er det tydelig at startfasen hadde en urealistisk forventning til hvor mye tid det ville ta å

implementere et system av dette omfanget.

Figur 55: Gantt-diagram for planlagt tidsbruk

Page 60: Roommates: Rapport for hovedoppgave

Side 52 av 75

Figur 56: Gantt-digram for faktisk tidsbruk

Page 61: Roommates: Rapport for hovedoppgave

Side 53 av 75

7 Konklusjon Systemet som er utviklet, er i en stand hvor det fungerer og kan brukes. Det er fullt brukbart og

kunne i teorien vært levert i den standen det er ved prosjektets avslutning, men ville hatt behov for

litt polering for å gjøre helheten enda bedre.

Koden kunne hatt bedre struktur og vært mer lesbar og fremtidsrettet, men dette ble vanskelig med

den tidsbruken som ble brukt på læring og eksperimentering.

Klientene kunne vært utviklet ved bruk av egne verktøy til multiplattformutvikling, hvor

klientkoden deles på alle plattformer. Dette ble sett på før prosjektets start og det ble konkludert

med at det ville krevd for mye tid å lære å bruke disse. Siden klientene som er utviklet har mye av

den samme logikken, kunne dette spart mye tid. Brukergrensesnittet har dog forskjeller som gjør at

dette måtte blitt implementert separat. Det ville også gjort bruk av back-end-løsninger betydelig

vanskeligere (da kryssplattformverktøyene ikke er godt støttet av disse).

Tidsbruken og arbeidsmengden var vanskelig å forutse, på grunn av at gruppen hadde lite erfaring

med denne typen prosjekter fra tidligere (særlig i den skalaen).

Problemene med enhetstesting var en stor tidstyv som ga lite tilbake til produktet, men hadde

fordeler for læring.

Gruppen har tilegnet seg kunnskap om større programvareprosjekter og hvor mye arbeid og tid som

må legges ned i denne typen prosjekter. Kunnskap om teknologier som applikasjonsutvikling, nye

programmeringsspråk, teknikker og utviklingsprosesser har gjort gruppen bedre rustet til

arbeidslivet.

7.1 Hvis gruppen startet på nytt Dersom gruppen, med den kunnskapen som nå er tilegnet, hadde startet prosjektet på nytt, ville

visse ting vært gjort annerledes.

Strukturen til klientene ville blitt lagt opp for å støtte opp under testbarhet (særlig i forhold til

enhetstesting). Dette ville gjort de mer solide, og koden ville hatt høyere kvalitet (og være mer

lesbar).

Inkrementene ville vært fordelt over flere og mindre inkrementer, særlig det første inkrementet.

Godkjenningstesting kunne med fordel vært startet tidligere i prosjektet. Å få andre til å teste

systemet mer inngående etter hvert inkrement kunne luket bort mange feil og mangler som i stedet

dukket opp på senere tidspunkter.

Ved å bedre teste systemet underveis ville andre krav dukket opp og blitt justert inn i prosjektet

underveis. Mer funksjonalitet som brukere ville hatt god nytte av ville da mest sannsynlig blitt

implementert.

7.2 Veien videre Deler av gruppen ønsker å ta prosjektet videre til et punkt hvor det kan slippes på plattformenes

respektive applikasjonsbutikker.

Dette vil kreve en del opprenskning i kode og gjøre applikasjonen mer tilgjengelig ved å

implementere støtte for flere språk. Feilmeldinger har behov for å gjøres mer beskrivende og

hjelpende for brukere.

Som nevnt av godkjenningstesterne ville en mer intuitiv opplevelse vært å foretrekke. Dette burde

utforskes videre ved å endre brukergrensesnittet og innføre veiledning i applikasjonen.

Det er også ønske om å lage klienter for flere plattformer: Web-klient, Windows Phone og Ubuntu

Phone. Dette ville gjort systemet tilgjengelig for enda flere brukere.

Page 62: Roommates: Rapport for hovedoppgave

Side 54 av 75

Før en eventuell slipp er det også behov for å teste applikasjonen enda grundigere. Enhetstesting,

manuell testing og godkjenningstesting bør gjøres i en langt større skala enn det som er gjort i

prosjektet.

Det burde også ses på hvordan økonomien skal håndteres. Parse vil begynne å koste penger om

bruken øker nok, og dette må finansieres på et vis, samtidig som det dekke litt utviklingstid også.

Dette kan løses ved reklame i applikasjonen, eller ved at man betaler en engangssum for selve

applikasjonen.

Oppsummert har systemet behov for en opprydning i kode for å gjøre videre utvikling enklere. Det

er også behov å gjøre systemet enda mer tilgjengelig med støtte for flere språk, flere klienter og

veiledning for nye brukere.

Page 63: Roommates: Rapport for hovedoppgave

Side 55 av 75

8 Litteraturliste Abstraction Layer. (u.å.). Hentet Mai 16, 2014 fra Wikipedia: http://en.wikipedia.org/wiki/Abstraction_layer

Access Control List. (u.å.). Hentet Mai 10, 2014 fra Wikipedia: http://en.wikipedia.org/wiki/Access_control_list

Activities. (u.å.). Hentet Mai 08, 2014 fra Android: http://developer.android.com/guide/components/activities.html

Android Software Development. (u.å.). Hentet Mai 08, 2014 fra Wikipedia: http://en.wikipedia.org/wiki/Android_software_development

Android System Architecture. (u.å.). Hentet Mai 12, 2014 fra Wikipedia: http://commons.wikimedia.org/wiki/File:Android-System-Architecture.svg

Android. (u.å.). Hentet Mai 07, 2014 fra Wikipedia: http://en.wikipedia.org/wiki/Android_(operating_system)

Android Version History. (u.å.). Hentet Mai 2014, 05 fra Wikipedia: http://en.wikipedia.org/wiki/Android_version_history

android.webkit. (u.å.). Hentet Mai 08, 2014 fra Android: http://developer.android.com/reference/android/webkit/package-summary.html

App Store Sales Top $10 Billion in 2013. (2014, Januar 7). Hentet April 23, 2014 fra Apple: http://www.apple.com/pr/library/2014/01/07App-Store-Sales-Top-10-Billion-in-2013.html

App Store. (u.å.). Hentet April 23, 2014 fra Wikipedia: http://en.wikipedia.org/wiki/App_Store_(iOS)

Apple Push Notification Service. (u.å.). Hentet Mai 10, 2014 fra Wikipedia: http://en.wikipedia.org/wiki/Apple_Push_Notification_Service

Application Fundamentals. (u.å.). Hentet Mai 08, 2014 fra Android: http://developer.android.com/guide/components/fundamentals.html

ARM. (u.å.). Hentet Mai 16, 2014 fra Wikipedia: http://no.wikipedia.org/wiki/ARM_(prosessorarkitektur)

Blocks. (u.å.). Hentet April 30, 2014 fra Wikipedia: http://en.wikipedia.org/wiki/Blocks_(C_language_extension)

Cocoa Touch. (2012). Hentet April 28, 2014 fra Apple: https://developer.apple.com/technologies/ios/cocoa-touch.html

Cocoa Touch. (u.å.). Hentet April 28, 2014 fra Wikipedia: http://en.wikipedia.org/wiki/Cocoa_Touch

Comparison of Java and Android API. (u.å.). Hentet Mai 07, 2014 fra Wikipedia: http://en.wikipedia.org/wiki/Comparison_of_Java_and_Android_API

Core OS Layer. (2013, September 18). Hentet April 30, 2014 fra iOS Technology Overview: https://developer.apple.com/library/ios/documentation/miscellaneous/conceptual/iphoneostechoverview/CoreOSLayer/CoreOSLayer.html#//apple_ref/doc/uid/TP40007898-CH11-SW1

Core Services Layer. (2013, September 18). Hentet April 27, 2014 fra iOS Technology Overview, Apple:

Page 64: Roommates: Rapport for hovedoppgave

Side 56 av 75

https://developer.apple.com/library/ios/documentation/miscellaneous/conceptual/iphoneostechoverview/CoreServicesLayer/CoreServicesLayer.html#//apple_ref/doc/uid/TP40007898-CH10-SW1

Cutler, K.-M., & Constine, J. (2013, April 25). Facebook buys parse to offer mobile development tools as its first paid B2B service. Hentet Mai 05, 2014 fra Tech Crunch: http://techcrunch.com/2013/04/25/facebook-parse/

Dalvik. (u.å.). Hentet Mai 07, 2014 fra Wikipedia: http://en.wikipedia.org/wiki/Dalvik_(software)

Declaring Layout. (u.å.). Hentet Mai 07, 2014 fra Android: http://developer.android.com/guide/topics/ui/declaring-layout.html

Designing for iOS7. (u.å.). Hentet Mai 10, 2014 fra Apple: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/

Entity Relationship Model. (u.å.). Hentet Mai 16, 2014 fra Wikiåedia: http://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model

Freeman, J. (2013, September 18). Bitbucket vs. GitHub: Which project host has the most? Hentet April 25, 2014 fra InforWorld : http://www.infoworld.com/d/application-development/bitbucket-vs-github-which-project-host-has-the-most-227061

Getting Started with Android Studio. (u.å.). Hentet Mai 08, 2014 fra Android Developers: http://developer.android.com/sdk/installing/studio.html

Git. (u.å.). Hentet Mai 12, 2014 fra Git: http://git-scm.com/figures/18333fig0104-tn.png

Git. (u.å.). Hentet Mai 12, 2014 fra Git: http://git-scm.com/figures/18333fig0102-tn.png

Git. (u.å.). Hentet Mai 12, 2014 fra Git: http://git-scm.com/figures/18333fig0104-tn.png

Git. (u.å.). Hentet Mai 12, 2014 fra Git: http://git-scm.com/figures/18333fig0105-tn.png

Google Play. (u.å.). Hentet Mai 08, 2014 fra Wikipedia: http://en.wikipedia.org/wiki/Google_Play

HTML. (u.å.). Hentet Mai 16, 2014 fra Wikipedia: http://no.wikipedia.org/wiki/HTML

Idc. (u.å.). Hentet April 23, 2014 fra http://www.idc.com/getdoc.jsp?containerId=prUS23946013#.USuIPVrF2Bg

IOS SDK. (u.å.). Hentet April 23, 2014 fra Wikipedia: http://en.wikipedia.org/wiki/IOS_SDK

iOS. (u.å.). Hentet April 23, 2014 fra Wikipedia: http://en.wikipedia.org/wiki/IOS

iOS. (u.å.). Hentet 04 23, 2014 fra Wikipedia: http://en.wikipedia.org/wiki/IOS

IOS. (u.å.). Hentet April 23, 2014 fra Wikipedia: http://en.wikipedia.org/wiki/IOS

iOS7. (2014). Hentet April 23, 2014 fra Apple: https://www.apple.com/no/ios/what-is/

IphoneOS Technologies. (2013, September 18). Hentet April 27, 2014 fra Apple: https://developer.apple.com/library/ios/documentation/miscellaneous/conceptual/iphoneostechoverview/iPhoneOSTechnologies/iPhoneOSTechnologies.html#//apple_ref/doc/uid/TP40007898-CH3-SW18

Java Syntax. (u.å.). Hentet Mai 07, 2014 fra Wikipedia: http://en.wikipedia.org/wiki/Java_syntax

JavaScript. (u.å.). Hentet Mai 16, 2014 fra Wikipedia: http://no.wikipedia.org/wiki/JavaScript

Page 65: Roommates: Rapport for hovedoppgave

Side 57 av 75

Lardinois, F. (2014, April 30). Tech Crun. Hentet fra http://techcrunch.com/2014/04/30/facebook-updates-parse-with-lower-prices-improved-analytics-offline-capabilities/

Larson, S. (12, Februar 2014). StackMob Is Shutting Down To Devote Itself To PayPal. Hentet Mai 14, 2014 fra ReadWrite: http://readwrite.com/2014/02/12/stackmob-shutting-down#awesm=~oEgYYgtE4abxTH

Main, A. (u.å). Authen::Passphrase::BlowfishCrypt - passphrases using the Blowfish-based Unix crypt(). Hentet Mai 11, 2014 fra Metacpan: https://metacpan.org/pod/Authen::Passphrase::BlowfishCrypt

Media Layer. (2013, September 18). Hentet April 27, 2014 fra iOS Technology Overview, Apple: https://developer.apple.com/library/ios/documentation/miscellaneous/conceptual/iphoneostechoverview/MediaLayer/MediaLayer.html#//apple_ref/doc/uid/TP40007898-CH9-SW9

Mobile/Tablet Operating System Market Share. (2014, April). Hentet Mai 14, 2014 fra Net Market Share: http://www.netmarketshare.com/mobile-market-share

Model View Controller. (2012, Januar 09). Hentet April 30, 2014 fra Apple: https://developer.apple.com/library/ios/documentation/general/conceptual/CocoaEncyclopedia/Model-View-Controller/Model-View-Controller.html

MongoDB, Inc. (2014, April 19). NoSQL Databases Explained. Hentet April 19, 2014 fra MongoDB: http://www.mongodb.com/nosql-explained

Navigation. (u.å.). Hentet Mai 11, 2014 fra Apple: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/Navigation.html#//apple_ref/doc/uid/TP40006556-CH53-SW1

Nordli, T. (2014, Mars 10). Android I. Hentet Mai 07, 2014 fra da-nan3000: http://debbie.hive.no/da-nan3000/10.html

Objective-C. (u.å.). Hentet April 27, 2014 fra Wikipedia: http://en.wikipedia.org/wiki/Objective-C

Observer pattern. (u.å.). Hentet Mai 11, 2014 fra Wikipedie: http://en.wikipedia.org/wiki/Observer_pattern

Parse ACL. (u.å.). Hentet Mai 10, 2014 fra Parse: https://parse.com/docs/data#security-objects

Parse. (u.å). Data & Security. Hentet fra Parse: https://www.parse.com/docs/data#security

Parse. (2014, 3 4). Docs Overview. Hentet 3 4, 2014 fra Parse: https://parse.com/docs

Porting UNIX/Linux Applications to OS X. (2012, Juni 11). Hentet April 23, 2014 fra Apple: https://developer.apple.com/library/mac/documentation/Porting/Conceptual/PortingUnix/glossary/glossary.html

Pro Git. (u.å.). Hentet April 25, 2014 fra Git: http://git-scm.com/book/en/

Software Testing Levels. (u.å). Hentet Mai 10, 2014 fra Software Testing Fundamental: http://softwaretestingfundamentals.com/software-testing-levels/

Software Testing Levels. (u.å.). Hentet Mai 12, 2014 fra Software Testing Fundamentals: http://softwaretestingfundamentals.com/software-testing-levels/

System Architecture. (u.å.). Hentet Mai 08, 2014 fra Android: http://developer.android.com/images/system-architecture.jpg

(u.å.). Hentet April 23, 2014 fra Apple: http://support.apple.com/kb/DL1736

Page 66: Roommates: Rapport for hovedoppgave

Side 58 av 75

Wikipedia. (2014, April 24). Document-oriented database. Hentet fra Wikipedia - the free encyclopedia: http://en.wikipedia.org/wiki/Document-oriented_database

Wikipedia. (u.å). Heartbleed. Hentet Mai 11, 2014 fra Wikipeda - The free encyclopedia: http://en.wikipedia.org/wiki/Heartbleed

XNU. (u.å.). Hentet April 23, 2014 fra Wikipedia: http://en.wikipedia.org/wiki/XNU

Page 67: Roommates: Rapport for hovedoppgave

Side 59 av 75

9 Begrepsliste

Abstraksjonslag: Et abstraksjonslag er en måte å skjule implementasjonsdetaljer for et

bestemt sett av funksjonalitet. (Abstraction Layer, u.å.)

ACL – Access Control List: En liste for å sjekke brukeres autorisasjoner.

Aktivitet: En aktivitet representerer et enkelt skjermbilde med et brukergrensesnitt i

Android (dette er kalt Scene i iOS).

API – Application Programming Interface: Sett med instruksjoner for å aksessere en

tjeneste.

ARM – Advanced Risc Machine: Verdens mest brukte prosessorarkitektur. (ARM, u.å.)

Atomic: En atomisk operasjon er en operasjon som blir utført i et enkelt steg for å unngå

kappløpssituasjoner.

Autentisering: Innen datasikkerhet er dette å bekrefte at man er den man utgir seg for å

være

Automatisk testing: Prosessen med å utføre testing på en applikasjon eller kode

automatisk.

Autorisasjon: Å ha tillatelse til å utføre en handling. Eksempelvis leserettigheter på en fil.

Brute Force attack: Et dataangrep hvor man for eksempel prøver alle mulige

passordkombinasjoner for å bryte seg inn. Krever ofte mye datakraft og lang tid.

C: Høynivå Programmeringsspråk som Objective-C er bygget på.

C++: Høynivå programmeringsspråk som er bygget på C.

Callback: Et callback er en metode som kalles når en bakgrunnsoppgave er ferdig utført.

Cloud Code: Parse sin tjeneste for å kjøre programkode på tjeneren.

Controller objekt: Controller-objekter (eller View Controller) kontrollerer hvordan

model-objekter blir presentert til brukeren (UI-logikk).

CSS: Cascading Style Sheets. Stildokumenter for å definere hvordan websider skal se ut.

Debugging: Prosessen hvor man retter feil i programvaren

Delegate: Brukt om objekter som er fullmektige for andre. De kan utføre oppgaver for

andre objekter som har de som delegate.

ER-diagram: En Entity Relationship-modell er en modell for å beskrive data eller

informasjonaspekter av et domene i en abstrakt måte som til slutt blir implementert i en

database, for eksempel en relasjonsdatabase. (Entity Relationship Model, u.å.)

Fragment: En underdel av Activity som representerer en del av et skjermbilde i en

Android-applikasjon

Hashing: Prosessen hvor man gjør uvilkårlig data om til data med en spesifikk lengde og

type.

HTML – HyperText Markup Language: Er et markeringsspråk for formatering av

nettsider med hypertekst. Det kan også være annen informasjon som vises i nettleser som

for eksempel bilder, tabeller. (HTML, u.å.)

http – HyperText Transfer Protocol: Er en protokoll på web som brukes for å utveksle

informasjon.

IDE - Integrated Developer Environment: Komplett programvare for utvikling med

kodeeditor, byggsystem og ofte en debugger.

JavaScript: Er et scriptspråk som legger til dynamiske elementer på nettsider. (JavaScript,

u.å.)

Kode-fil (.m): En Objective-C-fil med implementasjonskode.

Libc: The GNU C Library. Et bibliotek for programmeringsspråket C som definerer blant

annet systemkall.

Man-in-the-middle attack: En teknikk for datainnbrudd hvor man går i mellom en klient

og en tjener og utgir seg for å være tjeneren.

Page 68: Roommates: Rapport for hovedoppgave

Side 60 av 75

Model Objekt: Modell-objekter er hva applikasjonen er (men ikke hvordan den er vist).

Disse finnes i MVC mønsteret.

Native Applikasjon: En applikasjon som er laget for å kjøre på ett spesifikt system.

Nonatomic: En ikke-atomisk operasjon er en operasjon som utføres i flere steg, hvor det i

teorien kan oppstå en kappløpssituasjon.

NoSQL: Not Only SQL. En dokumentbasert database som skiller seg fra

relasjonsdatabaser

Notification Manager: Et rammeverk i Android som styrer varsler.

Objective-C: Er et objektorientert programmeringsspråk som er bygget på C.

Openssl: En implementasjon av SSL-protokollen som er open-source.

Prosessor: Utfører instruksjoner i et dataprogram. Også kalt CPU-Central Prosessing Unit.

Rainbow Tables: Ferdigberegnede tabeller for å reversere hashfunksjoner. Ofte knyttet til

cracking av passord.

Regresjon: Programvarefeil i allerede eksisterende og tidligere fungerende kode som

dukker som en følge av ny kode.

Rest-API: Et API som benytter seg av HTTP-metoder med en definert protokoll for

meldingsflyt.

Salting: Tilfeldige data som blir hashet sammen med passordet og deretter lagret sammen

med hashen. Brukes for å motvirke angrep med rainbow tables.

SDK – Software Development Kit: Er en rekke verktøy som lar utviklere utvikle

applikasjoner til for eksempel iOS og Android. Hver plattform har sitt eget SDK.

Sky: Et fellesbegrep for databehandling og lagring over nettverk.

Snapshots: Et snapshot er en lagring av en datamaskins tilstand på det tidspunktet

snapshot'et er tatt på.

SQL: Structured Query Language. Et spørrespråk for håndtering av databaser.

SQLite: Et DBMS som implementerer mesteparten av SQL-standarden.

SSL: En protokoll for å kryptere datatrafikk over internett.

Ubuntu Phone: Mobilt operativsystem utviklet av Ubuntu. Ubuntu er en Linux

distribusjon.

UML – Unified Modelling Language: Er en metode å vise designet av et system grafisk.

View objekt: View-objekter er UI-elementer som controlleren styrer og bruker for å

presentere model-objekter. Dette er en del av MVC-design mønsteret.

Waterfallmetoden: En trinnvis systemutviklingsmetode hvor man gjør seg ferdig med

hvert steg i utviklingen før man går videre.

Webapplikasjon: En applikasjon som kjører i en nettleser og benytter seg av vanlige

teknologier støttet av disse (HTML, Javascript). Er plattformuavhengig.

WebKit: Programvaren som rendrer nettsider i Apple sin Safari-nettleser.

Windows Phone: Mobilt operativsystem fra Microsoft.

Wrapper: Innpakning for å lage et eget grensesnitt til et objekt.

WYSIWYG: What You See Is What You Get. Brukt om brukergrensesnitt-editorer.

XML: Exensible Markup Language.

RBAC: Role-Based Access Control. Samme som ACL, men basere seg på roller/grupper

som inneholder flere brukere, i stedet for kun enkeltbrukere.

Page 69: Roommates: Rapport for hovedoppgave

Side 61 av 75

10 Vedlegg

Vedlegg på cd (vist som mappestrukturen):

Arbeidsdokumenter

o Forprosjekt

o Kravspesifikasjon

o Designspesifikasjon

o Testskjema

o Timelister

Kildekode

o Android

o iOS

o Cloud Code

Fullstendige prosjekter (som kan bygges)

o Android

o iOS

Media

o Demonstrasjonsvideo

o Skjermdumper

Android

iOS

Utviklingsverktøy

o Logoer og ikoner

Page 70: Roommates: Rapport for hovedoppgave

Side 62 av 75

11 Appendiks - Bakgrunnsteori

11.1 iOS iOS er et mobilt operativsystem utviklet av Apple Inc. Opprinnelig ble iOS laget bare for iPhone

(derav det tidligere navnet iPhone OS), men har blitt utvidet til å støtte andre Apple-enheter som

iPod Touch, iPad og andre-generasjon Apple TV i henholdsvis september 2007, januar 2010 og

september 2010. Operativsystemet er bare distribuert for Apple hardware. (IOS, u.å.)

21% av alle smarttelefoner solgt på verdensbasis (fjerde kvartal 2012) hadde iOS som mobilt

operativsystem. Apple's iOS lå bak Googles Android som hadde 70,1%. (Idc, u.å.) Ifølge Apple har

400 millioner enheter blitt solgt (juni 2012).

11.1.1 Brukergrensesnitt Brukergrensesnittet i iOS er basert på konseptet av direkte manipulasjon. Dette skjer ved hjelp av

multi-touch bevegelser med fingre som sveip, trykke, klemme og omvendt klype. Alle disse har

spesifikke definisjoner i iOS operativsystemet og i multi- touch-grensesnittet. Brukergrensesnittets

kontrollelementer består av glidere, brytere og knapper. Enkelte programmer bruker enheters

interne akselerometre for å respondere på risting av enheten, samt andre bevegelser man gjør på

selve enheten. Man kan også rotere enheten for å bytte fra stående til liggende modus på

brukergrensesnittet. (iOS, u.å.)

11.1.2 Versjoner Store versjoner av iOS er utgitt årlig, den nåværende versjonen er iOS 7. Den ble utgitt 18

september 2013. Siste versjon av iOS per 23/04-14 er iOS 7.1.1 som ble utgitt 22/04-14.

(Apple, u.å.)

11.1.3 Objective–C Objective-C er det viktigste programmeringsspråket som brukes av Apple. Det brukes for OS X og

iOS operativsystemene og deres programmeringsgrensesnitt (API), Cocoa og Cocoa Touch. Cocoa

og Cocoa Touch er rammeverk som har med brukergrensesnitt å gjøre. OS X har Cocoa, mens iOS

har Cocoa Touch. Objective-C er objektorientert og er utarbeidet for å kjøre på høy hastighet. Det

er enkelt å blande C og C++ inn i Cocoa Touch applikasjoner (det er også mulig å kompilere et C-

program med en Objective-C kompilator) fordi Objective-C er bygget på C. (Objective-C, u.å.)

Page 71: Roommates: Rapport for hovedoppgave

Side 63 av 75

11.1.3.1 Syntaks

Programmeringen er basert på meldingsutveksling til objekt-instanser fremfor vanlige metodekall.

Man kaller ikke bare en metode, man sender en melding, det vil si at målet for en melding er løst

under kjøring (men mottakerobjektet må selv tolke budskapet). (Objective-C, u.å.)

Sender meldingsmetoden til objektet:

[objekt metode]; // Sender melding

I likhet med C og C++ krever Objective-C at grensesnittet og implementasjonen av en klasse skal

være separate. Det vil si at man plasserer grensesnittet i en header-fil og implementasjonen i en

kode-fil. Det er kan sammenlignes med at header-filen (.h) er lik C header-filer og

implementasjonsfiler (.m) er lik C kodefiler. (Objective-C, u.å.)

Når en klasse er skrevet, kan den bli instantiert. Dette gjøres ved å først allokere minne og deretter

initialisere. Dette tilsvarer for eksempel new kodeordet i Java. Objektet er ikke fullt funksjonelt før

både alloc og init er fullført.

Instansiering av et objekt med standard init (uten argumenter):

MittObjekt *objekt = [[MittObjekt alloc] init];

Protokoller i Objective-C er kalt grensesnitt i andre programmeringsspråk. Objective-C bruker ad

hoc-protokoller kalt uformelle protokoller og kompilator-tvungne protokoller kalt formelle

protokoller. Uformelle protokoller inkluderer ofte valgfrie metoder som (hvis implementert), kan

endre oppførselen til en klasse. En formell protokoll er en liste over metoder som enhver klasse

selv kan erklære og implementere. (Objective-C, u.å.)

@protocol MinProtokoll - (void) foo; - (void) bar; @end

Objective-C har en syntaks hvor instansvariabler blir definert som properties. Disse inkluderer

valgfrie attributter for å konfigurere genereringen av tilgangsmetoder. En property kan bli erklært

som readonly og kan være utstyrt med lagringssemantikk som assign, copy, weak eller strong.

Properties er som standard satt til atomic, noe som resulterer i en lås som hindrer flere tråder

tilgang til dem på til samme tid. En property kan bli erklært som nonatomic og da fjernes låsen.

Settere og gettere blir automatisk implementert, men kan overskrives for utvidet funksjonalitet.

(iOS, u.å.) (Objective-C, u.å.)

Page 72: Roommates: Rapport for hovedoppgave

Side 64 av 75

#import "MittObjekt.h" @interface MittObjekt () @property (strong, nonatomic) NSString *foo; @property (strong, readonly) NSString *bar; @end @implementation MittObjekt // Have to synthesize because both setter // and getter is manually implemented @synthesize foo = _foo; // getter for bar - (NSString *)bar { return @"readonly bar"; } - (void)setFoo:(NSString *)foo { _foo = foo; } - (NSString *)foo { if (!_foo) { _foo = @"not set from before"; } return _foo; } @end

Objective-C støtter singel-arv, som betyr at en klasse kun kan arve fra en klasse av gangen.

@interface MittObjekt : NSObject @end

Blokker er en forlengelse lagt til av Apple til sin implementasjon av Objective-C. Som

funksjonsdefinisjoner, kan blokkene ta argumenter, og erklære sine egne variabler internt. I

motsetning til vanlige funksjonsdefinisjoner kan blokken aksessere tilstander rundt blokkens

kontekst. En blokk-definisjon gir en verdi som inneholder både en referanse til koden i blokken og

et bilde av den nåværende tilstanden av lokale stakkvariabler. Blokkene kan senere startes på

samme måte som en funksjonspeker. Gitt en blokk, kan koden i blokken kjøres når som helst på

senere tidspunkt ved å kalle den, med samme syntaks som skulle brukes for å kalle en funksjon.

(Blocks, u.å.)

Blokker blir gjerne brukt som argumenter til metoder. Dette er blant annet mye gjort i Parse sitt

API som en måte for å gjøre call-back.

Eksempel på bruk av blokk (blokken er markert i gult):

[PFUser logInWithUsernameInBackground:username password:password block:^(PFUser *user, NSError *error) { // Kode som blir kjørt etter innlogging er ferdig ... }];

Page 73: Roommates: Rapport for hovedoppgave

Side 65 av 75

11.1.4 iOS Software Development Kit iOS SDK'et ble utgitt 6. Mars 2008. SDK'et gjør at man kan utvikle og teste applikasjoner for

iPhone, iPad og iPod Touch. Testene skjer i en iPhone-simulator eller ved lasting av en applikasjon

på enheter. Xcode er utviklingsmiljø for iOS SDK, hvor applikasjoner er skrevet i Objective-C.

Utviklere kan velge å distribuere sin applikasjon gratis eller for en pris over et satt minimum

gjennom App Store. Hvis man velger gratis, trenger man ikke betale noen kostnader for å utgi og

distribuere applikasjonen utenom gebyret for Apple sitt Developer Program. Ellers får Apple 30%

av inntektene, mens utvikleren får 70%. (IOS SDK, u.å.)

11.1.4.1 Rammeverk

iOS har rundt 60 rammeverk, de tre mest brukte er UIKit.framework, Foundation.framework og

CoreGraphics.framework. Når man lager en ny applikasjon så følger disse tre rammeverkene med.

11.1.4.2 SDK Innhold: Abstraksjonslag

På grunn av at iOS bruker en variant av den samme XNU kjernen som finnes i OS X, er verktøyet

som støttes for utvikling Xcode.

I iOS, er det fire abstraksjonslag: Core OS, Core Services, Media og Cocoa Touch.

11.1.4.2.1.1 Cocoa Touch

Det som driver iOS applikasjoner, er rammeverk som finnes i Cocoa Touch. Cocoa Touch tilbyr

abstraksjonslaget i iOS. Cocoa Touch deler mange mønstre med Cocoa (OS X). I motsetning til

Cocoa ble Cocoa Touch bygget med spesiell fokus på touch-baserte grensesnitt og optimalisering,

dette kommer frem i for eksempel UIKit rammeverket. Som tidligere nevnt er mye av Cocoa Touch

implementert i Objective-C, derfor er det lett å blande C og C++ inn i Cocoa Touch applikasjoner.

Cocoa Touch inneholder samlinger av rammeverk til alt som trengs for å skape iOS applikasjoner.

Alt fra 3D-grafikk, lydhåndtering, nettverk og spesielle APIer for å kontrollere kameraet, eller å få

plassering fra GPS. Cocoa Touch inneholder også multi-touch, kontroller, alarmer og web view.

(Cocoa Touch, 2012) Verktøy for å utvikle applikasjoner basert på Cocoa Touch er inkludert i

SDK'et. (Cocoa Touch, u.å.)

11.1.4.2.1.2 UIKit.framework

Dette inneholder klasser og metoder for iOS-applikasjonens brukergrensesnittlag. UIKit-

rammeverket gir avgjørende infrastruktur for å implementere grafiske, hendelsesdrevne

applikasjoner i iOS. UIKit inneholder blant annet følgende: Støtte for å håndtere touch- og

bevegelsesbaserte hendelser, støtte for multitasking, støtte for tekst og web-innhold, klippe ut-,

kopiere- og lime inn-støtte, animasjon, integrasjon med andre programmer på systemet, støtte for

Apple Push Notification. I tillegg inkorporerer UIKit også støtte for enkelte enhetsspesifikke

funksjoner (Det innebygde kameraet). (IphoneOS Technologies, 2013)

11.1.4.2.1.3 Apple Push Notification

Apple Push Notification Service er en tjeneste laget av Apple Inc. som ble lansert 17. juni 2009.

Den bruker push-teknologi gjennom en IP-tilkobling for å videresende meldinger fra tjenerne til

tredjeparts applikasjoner på Apple–enheter. Disse meldinger kan inneholde merker, lyder eller

egendefinerte tekstvarsler. (Apple Push Notification Service, u.å.)

Page 74: Roommates: Rapport for hovedoppgave

Side 66 av 75

11.1.4.2.2 Media

11.1.4.2.2.1 Grafikk, Lyd og Video

En viktig del av alle applikasjoner er grafikk av høy kvalitet. For å støtte denne typen grafikk tilbyr

iOS mange teknologier for å bidra til dette. iOS har en grafikkteknologi som tilbyr et bredt spekter

av støtte, og den jobber regelmessig med UIKit-rammeverket (som finnes i Cocoa Touch-laget) for

å gjøre det enkelt å levere innhold. (Media Layer, 2013)

iOS lydteknologi jobber med den underliggende maskinvaren for å gi en rik lydopplevelse for

brukerne. Dette gir muligheten til å spille og ta opp lyd med høy kvalitet, håndtere MIDI-innhold

og å jobbe med enhetens innebygde lyder.

iOS videoteknologi gir støtte for å håndtere statisk videoinnhold i programmet eller avspilling av

direkteavspilt innhold fra internett. Man kan også ta opp video og innlemme det i programmet.

(Media Layer, 2013)

11.1.4.2.2.2 CoreGraphics.framework

Core Graphics rammeverket inneholder grensesnitt for 2D-tegnings-API'et, Quartz. Quartz støtter

stibasert tegning, gradienter, bilder og farger for å nevne noen. Quartz er den samme vektorbaserte

tegningsmotoren som brukes i OS X. Det brukes objekt-baserte abstraksjoner til å representere

tegneobjekter (selv om API'et er C-basert), dette gjør det enkelt å lagre og gjenbruke

grafikkinnhold. (Media Layer, 2013)

11.1.4.2.3 Core Services

Core Services laget inneholder grunnleggende systemtjenester for applikasjoner. Nøkkelen blant

disse tjenestene er Core Foundation og Foundation rammeverkene. Dette laget inneholder også

noen teknologier for å støtte funksjoner som iCloud og sosiale medier. Core Services inneholder

også støtte for: samlinger, adressebok, fil aksessering, SQLite med mer. (IOS, u.å.)

11.1.4.2.3.1 Foundation.framework

Foundation-rammeverket inneholder grensesnitt for å håndtere strenger, samlinger og andre lav-

nivå datatyper. Rammeverket gir Objective-C wrappers til mange av funksjonene som finnes i

Core Foundation-rammeverket. Core Foundation-rammeverket er nært knyttet til Foundation-

rammeverket, disse gir Objective-C-grensesnitt for de samme grunnleggende funksjonene. Mellom

Foundation og Core Foundation rammeverkene kan man bruke noen typer om hverandre. (Core

Services Layer, 2013)

Selv om iOS og OS X deler samme rammeverk (Core Foundation, Foundation med mer) er det

noen forskjeller. Den viktigste av disse er kanskje rammeverket som har med brukergrensesnitt å

gjøre. OS X har rammeverket Cocoa, mens iOS har Cocoa Touch. iOS er derfor ikke kompatibel

med OS X for applikasjoner. (IOS, u.å.)

11.1.4.2.4 Core OS

Core OS-laget inneholder lavnivå funksjoner som de fleste andre teknologier er bygget på. Selv om

man ikke bruker disse teknologiene selv, er det mest sannsynlig at de benyttes av andre

programmer. Når man trenger å eksplisitt holde på med sikkerhet eller kommunisere med eksternt

hardware-tilbehør, gjør man det ved hjelp av rammeverkene i dette laget. Andre elementer i Core

OS-laget er blant annet: Mach 3.0, Bonjour, File System, Sockets, Security og Power Management.

(Core OS Layer, 2013)

Page 75: Roommates: Rapport for hovedoppgave

Side 67 av 75

11.1.4.2.4.1 Kernel

XNU er operativsystems-kjernen som Apple kjøpte og utviklet for bruk i Mac OS-X-

operativsystemet og utgitt som gratis og åpen programvare som en del av Darwin operativsystemet.

XNU er et akronym for ”X is Not Unix”. (Porting UNIX/Linux Applications to OS X, 2012)

Som noen andre moderne kjerner, er XNU en hybrid som inneholder funksjoner i både

monolittiske kjerner og mikrokjerner. Den forsøker å å gjøre det beste ut av begge teknologier.

Foreløpig kjører XNU på ARM, x86-32- og x86–64-prosessorer, både enkeltprosessor og SMP-

modeller. (XNU, u.å.)

11.1.5 Apples App Store I iOS finnes det langt mer enn en million mobilapplikasjoner. Apple gir utviklere verktøy og API-

er for å skape applikasjoner som utnytter teknologien i alle iOS enheter. Alle disse applikasjonene

er enkle å finne og enkle å søke etter fordi distribusjonen av applikasjonene er sentralisert på ett

sted; App Store. (iOS7, 2014)

App Store er en digital distribusjonsplattform for mobile applikasjoner på iOS, utviklet og

vedlikeholdt av Apple. App Store gjør det mulig for brukere å surfe og laste ned applikasjoner som

har blitt utviklet med Apples iOS SDK. (App Store, u.å.)

Applikasjoner i App Store er rettet mot iOS-enheter, og kan gjøre bruk av spesifikke attributter av

disse enhetene. For eksempel bevegelsessensorer for knapper og kameraer for online

videosamtaler. Applikasjoner har in-app inntjeningsmuligheter gjennom reklame eller kjøp. Alle

applikasjoner skal godkjennes av Apple. Dette gjøres ved grunnleggende pålitelighetstesting og

andre analyser. (App Store, u.å.)

Per oktober 2013 inneholdt Apples App Store mer enn 1 million iOS-applikasjoner, 500 000 av

disse ble optimalisert for iPad. Disse programmene har samlet blitt lastet ned mer enn 60 milliarder

ganger. (App Store Sales Top $10 Billion in 2013, 2014)

11.2 Android Android er et operativsystem basert på Linux-kjernen og utviklet for touch-screen på mobile

enheter som smarttelefoner og nettbrett. Til tross for at Android først og fremst er utviklet for

telefoner og nettbrett, har det også blitt brukt i TV'er, spillkonsoller, digitale kameraer og annen

elektronikk. I motsetning til iOS kjører Android på mange typer mobile enheter fra forskjellige

leverandører. Android ble opprinnelig utviklet av Android Inc., der de fikk økonomisk støtte fra

Google. I 2005 kjøpte Google opp Android Inc. Den første offentlige mobile enheten som kjørte

Android var HTC Dream i oktober 2008. (Android, u.å.)

Android er det mest populære mobile operativsystemet i verden. Enheter med Android som

operativsystem selger mer enn Windows og iOS-enheter til sammen. 70,1% av alle smarttelefoner

solgt på verdensbasis (fjerde kvartal 2012) hadde Android som mobilt operativsystem. Googles

Android lå foran Apple's iOS som hadde 21%. (Idc, u.å.). Per september 2013 hadde en milliard

Android-enheter blitt aktivert.

Kildekoden til Android er utgitt av Google under åpne kildekode-lisenser. Samtidig blir de aller

fleste Android-enheter til slutt levert med en kombinasjon av åpen kildekode og lukket

programvare. (Android, u.å.)

Page 76: Roommates: Rapport for hovedoppgave

Side 68 av 75

11.2.1 Brukergrensesnitt Brukergrensesnittet i Android er basert på konseptet av direkte manipulasjon. Dette skjer ved hjelp

av multi-touch bevegelser med fingre som å sveipe, å tappe, å klype, omvendt klype og å

manipulere objekter på skjermen. Flere brukerhandlinger for eksempel å justere skjermen fra

stående til liggende modus eller omvendt, responderer ved bruk av intern maskinvare som

akselerometre, gyroskoper og nærhetssensorer. (Android, u.å.)

11.2.2 Versjoner Store versjoner av Android er utgitt hver sjette til niende måned. Den nåværende versjonen er

Android 4.4 ”KitKat” som ble utgitt 31. oktober 2013. (Android Version History, u.å.)

11.2.3 Java Android applikasjoner er som oftest skrevet i Java, men Android har ikke alle Javas

klassebiblioteker. (Comparison of Java and Android API, u.å.) Android utfører koden på Dalvik

Virtual Machine i stedet for Java Virtual Machine. (Nordli, 2014)

11.2.3.1 Dalvik Virtual Machine

Dalvik VM er en virtuell maskin som kjører applikasjoner på Android-enheter. Programmene i

Android er som sagt ofte skrevet i Java. Disse programmene blir kompilert til bytekode og deretter

konvertert fra Java Virtual Machine-kompatible Java class-filer til Dalvik-kompatible Dex (Dalvik

executable) og Odex (Optimized Dalvik executable) filer. Dette skjer før man installerer

programmet på en enhet. Dalvik executable formatet er utviklet for å passe systemer som er

begrenset av minne og prosessorhastighet. (Dalvik, u.å.)

11.2.3.2 Syntaks

Forskjellig fra Objective-C's meldingsutveksling har Java tradisjonelle metodekall. En metode har

en returverdi, et navn og kan ha parametere som blir initialisert når metoden kalles med

argumenter. (Java Syntax, u.å.)

class MinKlasse { void foo() { ... } int bar(int a, int b) { return a + b; } }

En metode blir kalt på når man bruker ”.” notasjonen på et objekt.

MinKlasse mittObjekt = new MinKlasse(); mittObjekt.foo();

Page 77: Roommates: Rapport for hovedoppgave

Side 69 av 75

Klasser i Java kan bare arve fra en enkelt klasse. Man deklarer at en klasse arver fra en annen

klasse ved hjelp av nøkkelordet extends. Klassen kan referere til seg selv med extends, mens den

refererer til sin superklasse ved hjelp av nøkkelordet super. (Java Syntax, u.å.)

class AnnenKlasse extends MinKlasse { @Overrides void foo() { ... } void fooBar() { extends.foo(); super.foo(); } }

11.2.4 XML – Extensible Markup Language I Android kan man erklære en layout på to måter: i XML eller ved å instantiere layout elementer

under kjøring. Ved å erklære UI i XML kan man lettere kontrollere fremstillingen av

applikasjonen. Man kan tilpasse og gjøre om på XML uten å måtte endre kildekoden. XML gjør det

lettere å se sammenhengen mellom elementene og hvor de ligger i forhold til hverandre på

skjermen, dette gjør det også lettere å søke etter problemer. (Declaring Layout, u.å.) Ved å bruke

XML kan utviklere lett bestemme hvor elementer skal ligge i forhold til hverandre, hvilken type

layout som Aktiviteten skal bruke, endre farge på tekst, gjøre tekst bold/italic, midtstille den og

mye mer.

<?xml version="1.0" encoding="utf-8"?> <RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android" ... android:background="@color/LightGrey"> <LinearLayout ...> <TextView ... /> <ListView ... android:background="#ffffffff" android:layout_margin="10dp" android:layout_gravity="center_horizontal"> </ListView> </RelativeLayout>

11.2.5 Android Software Development Kit Android SDK har mange utviklingsverktøy som debugger, emulator, eksempelkode og biblioteker.

Primært brukes Eclipse med Android Development Tools (ADT) plugins, eller Android Studio,

men andre IDE'er har også mulighet for Android-støtte. I tillegg kan man også utvikle via

kommandolinjen og skrive Java- og XML-filer med andre editorer. (Android Software

Development, u.å.)

Page 78: Roommates: Rapport for hovedoppgave

Side 70 av 75

11.2.5.1 Arkitektur

Android-kjernen er basert på en Linux-kjerne, selv om den spesifikke kjerneversjonen avhenger av

hvilken Android-enhet man har. Dagens Android-versjoner er bygget på Linux kjerne 3.4.

(Android, u.å.). Android-kjernen har i tillegg flere drivere til kamera, tastatur, lyd osv. På laget rett

over kjernen finnes biblioteker. Der finnes biblioteker som WebKit, SGL, Media Framework og

libc. Sammen med bibliotekene finnes Android Runtime som inneholder kjernebiblioteker og

Dalvik VM. Over bibliotekene finnes Applikasjonsrammeverk og applikasjoner. (System

Architecture, u.å.)

Figur 57: Android Arkitektur (Android System Architecture, u.å.)

11.2.5.1.1 Applikasjonsrammeverk

Noen av de mest brukte applikasjonsrammeverkene er Activity Manager, Content Providers,

Notification Manager, View System med mer. (System Architecture, u.å.)

Content Providers tilbyr datatilgang til andre applikasjoner. Notification Manager styrer

notifikasjoner i statusfeltet. View System er brukergrensesnittelementer som knapper, tabeller m.m.

(Nordli, 2014)

11.2.5.1.1.1 Activity Manager

Activity Manager snakker med alle aktivitetene som kjører i et system. En aktivitet representerer et

enkelt skjermbilde med et brukergrensesnitt (dette er kalt Scene i iOS). Brukeren kan samhandle

med skjermen for å gjøre noe, for eksempel skrive et notat. En aktivitet er implementert som en

underklasse av Activity. (Application Fundamentals, u.å.) En applikasjon består i de fleste tilfeller

av flere aktiviteter. Når en bruker starter applikasjonen for første gang, er det første som vises til

brukeren, en hovedaktivitet som er spesifisert i Android sin manifest-fil.

Alle aktivitetene er uavhengige av hverandre, men jobber sammen for å skape sammenheng i selve

applikasjonen. Når en aktivitet stopper, er det fordi en annen aktivitet starter. Applikasjoner bør

rydde opp store objekter når den stopper. Når aktiviteten gjenopptas, kan man gjenskaffe de

nødvendige ressursene og fortsette handlinger som ble avbrutt. Disse tilstandsovergangene er en

del av aktivitetens livssyklus. (Activities, u.å.)

Page 79: Roommates: Rapport for hovedoppgave

Side 71 av 75

11.2.6 Google Play Google Play er en digital distribusjonsplattform som drives av Google. Den inneholder

applikasjoner for Android operativsystemet og het tidligere Android Market. Google Play gjør det

mulig for brukere å søke og laste ned applikasjoner til enhetene sine.

Alle applikasjoner her er utviklet med Android SDK og publisert gjennom Google. Applikasjoner

som er tilgjengelige enten gratis eller til en satt pris, kan lastes ned direkte på enheten eller ved å

laste det inn via nettstedet til Google Play. Per juli 2013 hadde Google Play nådd over 1 million

applikasjoner og over 50 milliarder nedlastinger. (Google Play, u.å.) Google Play er den største

butikken for Android, men det finnes også andre muligheter til å laste ned applikasjoner, som for

eksempel fra Amazon App Store.

11.3 Parse Parse er en back-end-løsning for å lage skybaserte applikasjoner. Det tilbys en lagringsløsning i

form av en NoSQL-database, brukerhåndtering (innlogging, registrering, glemt passord), tjener-

side JavaScript-kode, push-meldinger, integrasjon mot sosiale nettverk med mer.

Selskapet ble grunnlagt i 2011, og to år senere ble de kjøpt opp av Facebook. I 2013 var det

anslagsvis 60 000 applikasjoner som benyttet seg av Parse som back-end i en eller annen grad.

(Cutler & Constine, 2013) Blant disse er Travel Channel, Food Network og Cisco kunder av Parse.

Parse benyttet seg til og med april 2014 av en freemium-modell hvor tjenesten var gratis å bruke,

men om man ønsket tilgang på all funksjonaliteten, ble en nødt til å betale. Gratisutgaven var

begrenset til en million API-kall i måneden, og maks 20 API-kall i sekundet. Man fikk heller ikke

tilgang til et analyseverktøy for å se hvordan applikasjonen blir brukt.

I mai 2014 ble prisplanen oppdatert og forenklet. Restriksjonene på antall API-kall ble fjernet, og

nå er det kun antall kall i sekundet man betaler for. Dette er nå gratis for opptil 30 kall per sekund.

Videre er alle analyseverktøyene gjort tilgjengelig for gratisbrukere, og det er også kommet ny

funksjonalitet for å legge til offline-støtte på applikasjoner. (Lardinois, 2014)

11.3.1 Teknologi Parse benytter seg av en NoSQL-database for lagring av data. Her kan man lagre vanlige datatyper

som tall og tekst, samt bilder og lokasjoner. Denne databasen administreres gjennom et

webgrensesnitt hvor man enkelt kan se og endre data. Videre tilbyr Parse SDKer for flere store

plattformer. Deriblant iOS, Android, Windows Phone og et REST-API. Dette gjør det mulig å la en

applikasjon benytte seg av samme back-end på flere forskjellige plattformer.

I tillegg til databasen kan Parse også håndtere utsending av push-meldinger, samt kjøre kode

direkte på tjeneren. Parse sin Cloud Code kan være med på å redusere båndbreddebruken

betraktelig, ved å gjøre store beregninger på tjeneren før man sender resultatet til klienten.

11.3.2 Sikkerhet Et viktig element når det gjelder all kommunikasjon over internett, er sikkerhet. Parse tilbyr flere

tjenester som er med på å skape en sikker applikasjon. Parse kan hjelpe oss å håndtere aspekter som

konfidensialitet, autorisering og autentisering.

Page 80: Roommates: Rapport for hovedoppgave

Side 72 av 75

11.3.2.1 Autentisering

All kommunikasjon mellom klienten og Parse blir kryptert med SSL (Secure Socket Layer). Dette

forhindrer man-in-the-middle-angrep. Derfor kan Parse være sikker på at klienten er den som den

utgir seg for å være og vice verca. SSL har i den senere tid fått mye kritikk for en sårbarhet som ble

oppdaget i biblioteket openssl. (Wikipedia, u.å) Sårbarheten i biblioteket ble tettet 7. april 2014, og

dagen etterpå hadde Parse oppdatert sine systemer mot sårbarheten. Dette viser at Parse tar

sikkerheten på alvor.

11.3.2.2 Konfidensialitet

Parse lagrer ingen passord i klartekst. Alle passord blir hashet og saltet av Parse ved hjelp av en

implementasjon av bcrypt. bcrypt er en kryptografisk algoritme for å hashe passord. I tillegg til å

salte passordet, er det en parameter for kostnad involvert. Algoritmen er designet for å være treg å

utføre, og denne tregheten kan justeres. Dette sørger for at man forhindrer angrep med «rainbow

tables», samt at «brute-force» angrep ikke er like effektivt. (Parse, u.å) (Main, u.å)

11.3.2.3 Autorisasjon

Parse bruker en ACL (Access Control List) for å sjekke brukeres autorisasjoner. En ACL med

hensyn til en datamaskins filsystem er en liste med tillatelser som hører til et objekt. Hvem som får

lese-, utføre- eller skriverettigheter til objekter, blir spesifisert av ACL. Hvert felt i en typisk ACL

spesifiserer et subjekt og en operasjon. Hvis en fil for eksempel hadde en ACL som inneholdt (Ola,

write), gir dette Ola rettigheten til å skrive på fila. (Parse ACL, u.å.)

En ParseACL er brukt til å kontroller hvilke brukere som kan aksessere eller modifisere et spesielt

objekt. Alle Parse-Objekter kan ha sin egen ParseACL. Man kan gi lese- og skriverettigheter

separat til spesifikke brukere, grupper av brukere som hører til roller, eller man kan gi rettigheter til

«offentligheten» sånn at alle brukere kan lese det objektet, men at bare enkelte brukere kan skrive

til det. (Parse ACL, u.å.)

Den enkleste måten å kontrollere hvem som kan aksessere data, er som sagt gjennom en ACL.

Ideen bak en ACL er at hvert objekt har en liste av brukere og roller sammen med hva slags

tillatelser som brukeren eller rollen har. En bruker trenger leserettigheter (eller må tilhøre en rolle

som har leserettigheter) for å hente et objekts data, og en bruker trenger skriverettigheter (eller må

tilhøre en rolle som har skriverettigheter) for å oppdatere eller slette det objektet. (Access Control

List, u.å.)

11.3.3 NoSQL Dataene skal lagres i Parse sin database som er av type NoSQL.

Parse bruker (gjemt for brukere av tjenesten) MongoDB i bakgrunnen, noe som tilsier at all data

lagres i en dokumentbasert NoSQL-variant. Dokumentbaserte NoSQL-databaser er bygd opp av

nøkler som er paret med en datastruktur. Paret kalles for et dokument. Datastrukturene kan være en

verdi, en liste over verdier eller flere dokumenter. Et eksempel på hvordan et dokument kan være

strukturert kan man se i figur 58.

Page 81: Roommates: Rapport for hovedoppgave

Side 73 av 75

{

FirstName: "Jonas",

Address: "16 Main Street",

Children: [

{Name: "James", Age: 11},

{Name: "Peter", Age: 8},

{Name: "Helen", Age: 5},

{Name: "Miley", Age: 2}

]

}

Figur 58 Eksempel på NoSQL-dokument

Her ser man et dokument som inneholder verdipar med navn og adresse, og et verdipar som

inneholder et underdokument med nye verdipar.

Om vi ser på NoSQL-databaser sammenlignet med SQL, er det noen forskjeller. En av de viktigste

er at en NoSQL-database har dynamiske skjemaer. Man kan legge til og fjerne felter i skjemaet når

som helst. Dette betyr at man kan gjøre større endringer på databasen uten å innføre nedetid.

Om vi ser på skalering, skalerer SQL vertikalt. For å øke ytelsen, må man oppgradere utstyret

databasen kjører på. NoSQL kan skalere horisontalt. I stedet for å oppgradere tjeneren, kan

databasen spes ut på flere tjenere uten at man må gjøre store konfigurasjoner.

Datamanipulering skjer gjennom objekt-orienterte rammeverk i stedet for SQL. Dokumentbaserte

databaser har ingen predefinert protokoll for hvordan dokumentet skal bygges opp, og kan derfor

tilpasses i forhold til hvordan man jobber med dataene. Et eksempel er hvordan man i Java kan lage

arvede klasser av de forskjellige skjemaene i Parse-databasen, og dermed legge egne metoder på

disse, samt bruke gettere og settere slik man er vant til. (MongoDB, Inc, 2014)

11.4 Versjonskontroll med Git Versjonskontroll er et system for å kontrollere og holde styr på endringer av filer. Med et slikt

system kan man finne tidligere versjoner av filer dersom man skulle ha behov for det. Det gir

dermed muligheten til å rulle tilbake enkeltfiler, deler av, eller hele prosjekter tilbake til tidligere

stadier. Dette kan være særdeles nyttig dersom man for eksempel introduserer en regresjon som

ikke blir oppdaget i systemet før det har gått lang tid.

Versjonskontroll kan være en lokal tjeneste man kjører på sin egen maskin, eller man kan benytte

seg av en sentralisert tjener med versjonskontrollprogramvare. Fordelen med å bruke sentralisert

versjonskontroll er muligheten for at flere medlemmer av et team kan bruke samme

versjonskontrollerte kodebase.

Page 82: Roommates: Rapport for hovedoppgave

Side 74 av 75

Figur 59: Sentralisert versjonskontroll (Git, u.å.)

Når man benytter seg av versjonskontroll, starter man med å sjekke ut en versjon av programvaren

fra versjonskontrolleren (oftest siste versjon). Da har man en lokal gren av programvaren som det

kan gjøres endringer på og jobbes med lokalt. Når man er ferdig med det man skal gjøre (for

eksempel legge til ny funksjonalitet), sjekker man grenen tilbake i versjonskontrollsystemet.

Git er en versjonskontrollprogramvare skrevet av Linus Torvalds (skaperen av Linux). Git fungerer

litt annerledes enn andre versjonskontrollprogramvarer (Subversion, CVS, Bazaar osv) på måten

den håndterer data på. Andre versjonskontrollsystemer håndterer data som filer, og tar vare på

endringer som er gjort over tid. Det vil si at man tar vare på en fil, og ved oppdateringer tar vare på

endringene som er gjort (i stedet for å lagre hele filen på nytt).

Figur 60: Versjonskontroll med differanser. Ikke Git. (Git, u.å.)

Git derimot ser på data som snapshots. Så hver gang en ny versjon opprettes, lages det et snapshot

av hele filsystemet. Selv om hver versjon er et snapshot, vil det ikke være redundant data takket

være intelligent linking av filer. Man kan tenke seg at for hver gang det legges inn en ny versjon,

tar systemet et intelligent bilde av filene og tar vare på dette bildet til senere bruk. Forskjellen på

bildet i figur 59 og 60 viser hvordan Git fungerer i forhold til andre systemer.

Page 83: Roommates: Rapport for hovedoppgave

Side 75 av 75

Figur 61: Versjonskontroll med snapshots, slik det gjøres i Git. (Git, u.å.)