roommates: rapport for hovedoppgave
Embed Size (px)
TRANSCRIPT
i
Roommates
En applikasjon for å gjøre bofellesskap enklere.
Gruppedeltakere / Real Kode:
Gjermund Bjaanes,
Johann Eckhoff og
Katrine Myklevold
ii
Hovedoppgave
Gruppen har utviklet en mobil applikasjon. Applikasjonen brukes for kommunikasjon i
samboersituasjoner. Man kan sende notater til hverandre, 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
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.
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.
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:
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.
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
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
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
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.
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.
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.
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.
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)
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
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.
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
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.
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).
Side 12 av 75
Figur 2: Datadesign tegnet i UML
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.
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
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)
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
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)
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
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.
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)
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
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.
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
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.
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.
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.
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.
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.
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.
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
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.
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
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.
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 *
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.
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
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
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.
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.
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
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.
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.
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.
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.
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
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.
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.
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.
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
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.
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
Side 52 av 75
Figur 56: Gantt-digram for faktisk tidsbruk
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.
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.
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:
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
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
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
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.
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.
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
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.å.)
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.å.)
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 ... }];
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.å.)
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)
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.å.)
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();
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.å.)
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.å.)
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.
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.
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.
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.
Side 75 av 75
Figur 61: Versjonskontroll med snapshots, slik det gjøres i Git. (Git, u.å.)