Sluttrapport - Høgskolen i Oslo

Transcription

Hovedprosjekt ved institutt for Informasjonsteknologi
Høgskolen i Oslo og Akershus våren 2015
Madeleine V. K. Rønning,
Informasjonsteknologi
Emilie Strand,
Rannveig A. Skjerve,
Dataingeniør
PROSJEKT NR.
2015-24
Studieprogram: Informasjonsteknologi
Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo
Besøksadresse: Holbergs plass, Oslo
TILGJENGELIGHET
Offentlig
Telefon: 22 45 32 00
Telefaks: 22 45 32 05
BACHELORPROSJEKT
HOVEDPROSJEKTETS TITTEL
DATO
Semitone
26.05.15
ANTALL SIDER / BILAG
114
PROSJEKTDELTAKERE
INTERN VEILEDER
Rannveig A. Skjerve
Madeleine Victoria Kongshavn Rønning
Emilie Strand
G. Anthony Giannoumis
OPPDRAGSGIVER
KONTAKTPERSONER
Accenture Norge AS
Henrik Bjerke og
Jonas Korssjøen
SAMMENDRAG
Konseptutvikling og teknisk implementering av Semitone.
Semitone er en mobilapplikasjon for tilgjengeliggjøring av lokale musikkmiljø.
3 STIKKORD
Proof Of Concept
Java for Android
.NET
Forord
Denne rapporten omhandler konseptutvikling og implementering av mobilapplikasjonen
“Semitone”, gjennomført som hovedprosjekt for gruppe 24 på fakultetet for teknologi, kunst og
design på Høgskolen i Oslo og Akershus, våren 2015. Kildekode ligger på vedlagt minnepenn.
Rapporten er delt i 4 deler
●
Innledning og bakgrunn
Presentasjon av teknisk, og kontekstuell bakgrunn, samt aktørene som har vært
involvert i oppgaven
●
Prosessdokumentasjon.
Beskrivelse av utviklingsprosessen og de 3 «Scrum-sprintene» vi gjennomførte.
●
Produktdokumentasjon
Detaljert beskrivelse av det ferdige produktet og testdokumentasjon.
●
Avslutning
Refleksjoner rundt prosessen, produktet, og mulig videreutvikling for applikasjonen.
Vi har laget en ordliste som ligger som vedlegg. Her er forklaringer av tekniske begreper,
forkortelser og akronymer vi har brukt, men ikke forklart, i løpet av rapporten.
Takk til Accenture Norge, spesielt til Henrik Bjerke og Jonas Korssjøen for hjelp, veiledning og
dårlige spøker.
Takk til samboer, venner og familie som har holdt ut med programmeringståker og
dokumentasjonsforbannelser.
Takk også til den usynlige entitenen Sindre Wigre, for å ha reddet oss fra oss selv og våre
kompliserte setninger.
And last, but definitely not least:
Thanks to G. Anthony Giannoumis, for cake, inspiration, support and for teaching us the proper
use of “that” and “which”.
3
Innhold
1.
Presentasjon ................................................................................................................... 9
1.1
Innledning .................................................................................................................... 9
1.2
Involverte aktører ......................................................................................................... 9
1.2.1 Studentgruppen ......................................................................................................... 9
1.2.2 Intern veileder fra HiOA .............................................................................................. 9
1.2.3 Veiledere fra Accenture .............................................................................................. 9
1.3
Presentasjon av de involverte aktørene ......................................................................10
1.3.1 Studentgruppa ..........................................................................................................10
1.3.2 HiOA .........................................................................................................................10
1.3.3 Accenture ..................................................................................................................10
1.4
Oppgaven ...................................................................................................................10
1.4.1 Hva slags oppgave er det?........................................................................................10
1.4.2 Mål for oppgaven ......................................................................................................10
1.5
Bakgrunn ....................................................................................................................10
1.5.1 Behovet .....................................................................................................................10
1.5.2 Eksisterende løsninger ..............................................................................................11
1.6
2.
Avgrensning ................................................................................................................11
Faglig bakgrunn..............................................................................................................11
2.1
Proof of concept ..........................................................................................................11
2.2
Scrum .........................................................................................................................11
2.2.1 Sprinter .....................................................................................................................12
2.2.2 Roller i Scrum ...........................................................................................................12
2.2.3 Valget av Scrum ........................................................................................................13
2.2.4 Scrum vs fossefallsmetoden .....................................................................................13
2.3
3.
Elevator pitch ..............................................................................................................13
Teknologier ....................................................................................................................14
3.1
EXtensible Markup Language(XML) ...........................................................................14
3.2
JavaScriptObjectNotation (JSON) ...............................................................................14
3.3
REpresentional State Transfer (REST) .......................................................................14
3.4
Java for Android ..........................................................................................................15
3.4.1 Dalvik VM ..................................................................................................................15
4
3.4.2 Valg av programmeringsspråk...................................................................................15
3.5
ASP.NET Web API .....................................................................................................15
3.6
Utviklingsmiljøer ..........................................................................................................15
3.6.1 Android Studio ..........................................................................................................15
3.6.2 Visual Studio .............................................................................................................15
3.7
Eksterne biblioteker og APIer ......................................................................................15
3.7.1 Spring for Android .....................................................................................................15
3.7.2 Robospice .................................................................................................................15
3.7.3 Google Places API ....................................................................................................16
3.7.4 Git .............................................................................................................................16
3.7.5 Azure-server .............................................................................................................16
3.7.6 Entity Framework ......................................................................................................16
3.7.7 Microsoft Azure Blob ................................................................................................16
3.8
Shared preferences .....................................................................................................17
3.9
Valg av ulike teknologier .............................................................................................17
3.9.1 Java for Android ........................................................................................................17
3.9.2 Valg av Azure ............................................................................................................17
3.9.3 Webserver.................................................................................................................17
Prosessdokumentasjon
4.
Innledning av samarbeid ................................................................................................19
4.1
Samarbeid i gruppa.....................................................................................................19
4.2
Samarbeid med oppdragsgiver ...................................................................................19
4.3
Samarbeid med veiledere ...........................................................................................19
4.3.1 Intern veileder ved Høgskolen ...................................................................................19
4.3.2 Veiledere ved Accenture ...........................................................................................19
5.
Utvikling av kravspesifikasjonen .....................................................................................20
5.1
Første utkast ...............................................................................................................20
5.2
“No fuss, just music” ...................................................................................................20
5.3
Spesifisering av målgruppe .........................................................................................21
5.4
Funksjonalitetskutt ......................................................................................................21
5.4.1 Diskusjoner etter funksjonalitetskutt ..........................................................................21
5.4.2 Use case etter funksjonalitetskuttene ........................................................................22
5.5
Brukertestingens innvirkning på oppgaven ..................................................................22
5
6.
Første sprint (03. feb - 24. feb) .......................................................................................23
6.1
Oppstart med Scrum ...................................................................................................23
6.2
Estimering ...................................................................................................................23
6.3
Problemer med Scrum ................................................................................................23
6.4
Realiseringer etter 1. sprint .........................................................................................23
6.5
Retrospektiv ................................................................................................................24
6.5.1 Hva fungerte dårlig, og hvorfor? ................................................................................24
6.5.2 Hva fungerte? ...........................................................................................................25
6.6
Presentasjoner............................................................................................................25
6.6.1 Styringsgruppen i Accenture .....................................................................................25
6.6.2 Veilederen på høyskolen og andre interessenter.......................................................25
7.
Andre sprint (24. feb - 07. apr)........................................................................................26
7.1
Planlegging .................................................................................................................26
7.2
Diskusjoner underveis .................................................................................................27
7.3
Avslutting av 2. sprint ..................................................................................................28
7.3.1 Første utsettelse av sluttdato på 2. sprint ..................................................................29
7.3.2 Andre utsettelse av sluttdato på 2. sprint ...................................................................29
7.4
Nødvendig med videre funksjonalitetskutt ...................................................................29
7.5
Retrospektiv ................................................................................................................30
7.5.2 Hva fungerte? ...........................................................................................................30
8.
Tredje sprint (08. apr - 01. mai) ......................................................................................31
8.1
Planlegging .................................................................................................................31
8.2
Valget om ikke å estimere tid ......................................................................................31
8.3
Underveis ...................................................................................................................33
8.3.1 Tekniske grunner til at vi ikke ble ferdige ...................................................................33
8.3.2 Andre grunner til at vi ikke ble ferdige .......................................................................33
8.4
Etter sprint ..................................................................................................................33
8.5
Retrospektiv ................................................................................................................35
8.5.2 Hva fungerte? ...........................................................................................................36
6
9.
Resultater .......................................................................................................................37
9.1
Kravspesifikasjon ........................................................................................................37
9.1.1 Overordnet systembeskrivelse ..................................................................................37
9.1.2 Funksjonelle egenskaper og brukergrensesnitt .........................................................37
9.2
Teknisk beskrivelse av produktet ................................................................................40
9.2.1 Systemets hovedkomponenter ..................................................................................40
9.2.2 Fronteend: Androidapplikasjon ..................................................................................40
9.2.3 Backend ....................................................................................................................55
9.3
Proof of concept ..........................................................................................................62
9.4
Oppfyllelse av krav til funksjonalitet ............................................................................62
9.5
Søkekriterier ...............................................................................................................63
9.5.1 Om geografisk område som søkekriterie ...................................................................63
9.5.2 Om sjanger som søkekriterie.....................................................................................63
9.5.3 Videreutvikling av søkekriterier..................................................................................64
9.6
10.
Sammenlignet med konkurrerende løsninger ..............................................................64
Brukertesting ..................................................................................................................65
10.1
Om undersøkelsene: Kvalitativ forskningsmetode ......................................................65
10.2
Forhold rundt testingen ...............................................................................................65
10.3
Hva undersøkte vi? .....................................................................................................65
10.4
Resultater ...................................................................................................................66
10.4.1 For mye funksjonalitet .............................................................................................66
10.4.2 Kommunikasjon mellom brukere .............................................................................66
10.4.3 Billettkjøp ................................................................................................................66
10.4.4 Liste vs. swipefunksjon............................................................................................66
10.4.5 Innlogging ...............................................................................................................66
10.4.6 Mengden informasjon ..............................................................................................66
10.4.7 Brukergrensesnitt ....................................................................................................67
10.5
11.
Innvirkninger av testresultat på produktet ...................................................................67
Konklusjon......................................................................................................................68
11.1
Egenevaluering ...........................................................................................................68
11.1.1 Gjennomføring ........................................................................................................68
11.1.2 Samarbeid/gruppeprosessen ..................................................................................68
7
11.1.3 Læringsutbytte ........................................................................................................69
11.2
12.
Videre arbeid ..............................................................................................................70
Referanser .....................................................................................................................72
Vedlegg
1.
Ordliste ..............................................................................................................................76
2.
Styringsdokumenter ...........................................................................................................78
3.
Elevator pitch .....................................................................................................................85
4.
Brukertester .......................................................................................................................86
5.
Prosjektskisse ....................................................................................................................87
6.
Brukerveiledning ................................................................................................................89
7.
HTTP API References......................................................................................................104
8.
Klasseoversikt – applikasjon ............................................................................................107
9.
Klasseoversikt – server ....................................................................................................113
8
1.
Presentasjon
1.1
Innledning
I denne delen presenteres oppgaven og de involverte aktørene. Bakgrunn og mål for oppgaven
beskrives, samt hvordan vi har avgrenset den.
1.2
Involverte aktører
1.2.1Studentgruppen
Rannveig A. Skjerve, s126247
Dataingeniør
[email protected]
Madeleine Victoria Kongshavn Rønning, s188895
[email protected]
Emilie Strand, s188904
[email protected]
1.2.2 Intern veileder fra HiOA
G. Anthony Giannoumis
[email protected]
1.2.3 Veiledere fra Accenture
Jonas Korssjøen
[email protected]
Henrik Bjerke
[email protected]
9
1.3
Presentasjon av de involverte aktørene
1.3.1 Studentgruppa
Gruppa har bestått av tre medlemmer fra linjene informasjonsteknologi og dataingeniørfag.
Madeleine og Emilie har jobbet sammen på mange prosjekter gjennom studietiden. Rannveig er
nyeste tilskudd i gruppa, og har samarbeidet med de to andre på obligatoriske innleveringer
siden andre året. Vi har jobbet godt sammen tidligere, og det var derfor et naturlig valg å
fortsette samarbeidet inn i bacheloroppgaven.
Medlemmene i gruppa har tidligere tatt emner innenfor apputvikling for Android og NETteknologi, som er hovedteknologiene som ble brukt i implementeringen av Semitone.
1.3.2 HiOA
Høgskolen i Oslo og Akershus (HiOA) er landets største statlige høgskole, med ca. 16 000
studenter og over 1850 tilsatte. Innenfor fakultetet TKD, teknologi, kunst og design, tilbys
høyere utdanning i datafagene Dataingeniør, Informasjonsteknologi og Anvendt Datateknologi.
Dette fakultetet har rundt 2800 studenter.
1.3.3 Accenture
Accenture er et globalt konsulentselskap som leverer tjenester innenfor rådgivning, teknologi og
outsourcing, og har ca. 305 000 ansatte verden rundt. I Norge har Accenture kontorer i Bergen,
Stavanger og Oslo, og har kunder innenfor både offentlig og privat sektor.
1.4
Oppgaven
1.4.1 Hva slags oppgave er det?
Oppgaven er et proof of concept i regi av Accenture Norge, og har hatt et todelt fokus;
Å videreutvikle en idé til et produkt, og en teknisk implementering av dette produktet.
1.4.2 Mål for oppgaven
Å utvikle en applikasjon som
-
1.5
Tilgjengeliggjør lokale musikkmiljø for flere
Fasiliterer «communitybygging» for de lokale musikkmiljøene
Gir små ukjente artister en enkel mulighet til å promotere seg selv
Bakgrunn
1.5.1 Behovet
Vi er en over gjennomsnittet musikkinteressert gruppe. Flere av oss er musikere, og har erfaring
med vanskelighetene knyttet til å finne fram til de lokale scenene, og å få musikken vår hørt i
havet av små ukjente artister.
Selv om det finnes flere verktøy som holder oversikt over konserter nær deg, finnes det få som
setter mindre scener og band i fokus. Det finnes heller ikke mange søkbare alternativer med
10
mindre man kan de «riktige» ordene. Subkulturer har dermed ingen plattform for enkelt å nå et
interessert publikum utenfor sin egen omgangskrets.
1.5.2 Eksisterende løsninger
Programmer som Spotify og SoundCloud gjør det lett å finne ny musikk. Denne typen
programmer tilbyr ofte topplister av trendende band og artister. Spotify vil også vise konserter i
din by for band du liker. Det er også tjenester som Bandsintown som finner konserter på de
kjente scenene i byen din.
Det finnes mange ulike plattformer for musikk, men som nevnt glemmer disse ofte de små
artistene og viktigheten av lokal tilhørighet. Ukjent musikk drukner i de mer populære og får ikke
samme sjanse til å bli hørt. Dette ønsker vi å endre på, og det er her vår løsning skiller seg fra
eksisterende løsninger. Appen orienterer seg rundt mindre band i nærmiljøer, og å gjøre deres
musikk tilgjengelig for flere. Tjenesten vil, ulikt de store musikkapplikasjonene, etablere et
fellesskap der man får utvidet sin kunnskap og kjærlighet for lokal musikk.
1.6
Avgrensning
Vi har hatt mange idéer, under videreutviklingen av produktet har vi derfor vært nødt til å
begrense antall idéer som skulle legges inn.
Oppgaven er avgrenset til å skulle produsere et ‘proof of concept’ og tilpasset en begrenset
målgruppe.
Et teknisk proof of concept er ikke et ferdig produkt, men et teknisk bevis på at en idé er
gjennomførbar. Vi har derfor valgt å fokusere på implementering av hovedfunksjonene og
godtatt at noen funksjoner blir stående som “placeholdere”. Spissing av målgruppen har endret
omfanget i appen, og har ført til mange kutt av funksjoner. Dette er beskrevet i detalj i avsnitt
5.4 Funksjonalitetskutt.
2.
Faglig bakgrunn
2.1
Proof of concept
Et proof of concept er en demonstrasjon av at et konsept eller en idé er gjennomførbar. Det vil
si at oppgavens fokus ikke har vært på levering av et ferdig produkt, men å produsere en
teknisk løsning som viser at det vil være mulig å utvikle idéen til et ferdig produkt.
Med andre ord er ikke alle funksjoner implementert, kun de som er nødvendige for å vise idéen.
Fokuset har ligget på å finne løsninger på tekniske utfordringer idéen fører med seg, og generelt
teste og finne ut hvordan vi best kan oversette konseptet vårt til en fungerende applikasjon.
2.2
Scrum
Scrum er et rammeverk for organisering av arbeid i forbindelse med utvikling av
programvarebaserte systemer. Teorien er basert på empirisk prosesskontroll, og på
inkrementell og iterativt produksjon i selvdrevne tverrfaglige «Scrum team». Scrum team styrer i
11
praksis seg selv, og definerer målene for programutviklingen underveis i kontinuerlig samarbeid
med produkteier1.
Arbeidsoppgaver knyttet til utvikling av funksjonene som skal utvikles, legges i en prioritert liste
kalt Product Backlog. Backlogen endrer seg gjennom hele prosjektet basert på tilbakemelding
fra produkteier og erfaringer i teamet. Utviklingen av Semitone har hele tiden vært basert på
brukertesting, noe som har ført til at implementerte og planlagte funksjoner ofte har endret
karakter. Det var derfor en stor fordel for oss å bruke Scrum, heller enn andre
utviklingsrammeverk som ofte krever en fastsatt kravspesifikasjon før implementeringen av
produktet kan begynne.
2.2.1 Sprinter
Målene oppnås gjennom utvikling av små produktinkrementer kalt sprinter. På begynnelsen av
en sprint velges det ut et sett med funksjoner som skal implementeres i løpet av de 1-4 ukene
sprinten foregår. Korte sprinter fører til at mye tid går med til planlegging, men lengre sprinter
gjør utviklingen mindre smidig. For hver av funksjonene som skal implementeres i prosjektet,
lages det oppgavelister. Disse legges i lister kalt “Sprint backlog”, og alle sprinter planlegges ut
fra disse.
Under hele sprinten gjennomføres det daglige møter, der teammedlemmene oppdaterer
hverandre og koordinerer arbeidet videre. Det blir lagt vekt på at disse møtene skal være korte,
og de gjennomføres gjerne stående, noe som har gitt disse møtene navnet “stand-up”. Disse gir
også oversikt for Scrum-master, og dermed prosjektleder. Ved å holde temaet oppdatert kan
man få hjelp tidlig; man får utnyttet hele teamets kompetanse og erfaring ved å fortelle om
arbeidsoppgavene sine og om ting som er til hinder.
På slutten av en sprint demonstreres produktet av sprinten, et Minimal Viable Product (MVP), til
noen utvalgte interesserte. Hensikten med dette er å få tilbakemeldinger og innspill til videre
utvikling. Etter dette gjennomfører teamet et «retrospekt» som er et møte der sprinten
diskuteres. Teamet går igjennom hva som fungerte og hva som ikke fungerte, og tar med seg
disse erfaringene inn i neste sprint.
2.2.2 Roller i Scrum
Scrumteam: Et Scrumteam er alle som er involvert i det nødvendige arbeidet. Scrumteamet
består av produkteier, Scrum master og et utviklingsteam.
Produkteier: Produkteieren representerer interessenter og skal sikre at Scrumteamet jobber
med de riktige tingene sett fra et forretningsperspektiv. Hen er ansvarlig for at product backlog
er oppdatert og tilgjengelig for interessenter og utviklingsteam.
Scrum master: Scrum master er ansvarlig for gjennomføringen av Scrum i Scrumteamet, samt
all ekstern kontakt slik at teamet kan jobbe uten distraksjoner.
1
se underkapittel “2.2.2 Roller i Scrum”
12
Utviklingsteam: Et utviklingsteam er et tverrfaglig team som står for selve produksjonen i hver
sprint.
2.2.3 Valget av Scrum
Det var et ønske fra Accenture at vi skulle benytte oss av Scrum som utviklingsmetode, fordi de
bruker det i sine prosjekter. Selv om vi teknisk sett selv er produkteiere har også Accenture,
representert av våre veiledere Jonas og Henrik, hatt denne rollen. På denne måten har de fått
jevnlige oppdateringer underveis, og ikke bare et ferdig produkt på slutten av semesteret.
2.2.4 Scrum sammenlignet med fossefallsmetoden
Scrum er godt egnet for en oppgave som vår ettersom det lar teamet utvikle både krav og
løsninger kontinuerlig. Andre metoder, som fossefallsmetoden, krever at man har ferdige
spesifikasjoner basert på satte krav før man kan begynne med selve programmeringen.
Scrum har flere iterasjoner med tidlig og hyppig feedback. Tidlig feedback på grovstruktur eller
enkeltkomponenter kan spare masse tid sammenlignet med å utvikle ferdig og dermed finne
store problemstillinger som må gjøres om på. I større og lengre prosjekter kan også bruk av
fossefall føre til et utdatert produkt ettersom det ikke får utviklet seg i takt med markedet. Scrum
gir derimot flere MVPs som fører til hyppige tilbakemeldinger underveis, og gjør at man får
optimalisert produktet på de viktige områdene. En ulempe her er at man kan bli for fokusert på å
utbedre det man får feedback på, slik at man ikke får videreutviklet. Det hender jo også at
kunden ikke vet best.
Med tanke på at vårt prosjekt begynte med kun en idé, og fordi vi ville være åpne for endringer
underveis, var fossefallsmetoden ikke et passende valg for oss. Scrum derimot ville gi oss det vi
trengte av fleksibilitet, samtidig som det fremdeles var klare strukturer og planer i form av
product backlog og sprinter.
2.3
Elevator pitch
En elevator pitch er en kort forklaring av et produkt, og hva som gjør det unikt. Man ønsker å
fange lytterens oppmerksomhet, og få dem til å ville vite mer. Navnet kommer av at den skal
være kort nok til å kunne holdes under en heistur, altså rundt 30 sekunder.
Å skrive et elevator pitch er ikke bare en øvelse i retorikk, men er også et nyttig verktøy for
definering av et konsept.
13
3.
Teknologier
3.1
EXtensible Markup Language (XML)
<element>
<subelement attribut="informasjon om element"/>
<subelement attribut="informasjon om element">
<andre_subelement attribut="informasjon om elementet"/>
<subelement>
</element>
(Figur 3.1 A – ‘‘XML-eksempel’’)
XML er et plattformuavhengig markeringsspråk designet for lagring og utveksling av strukturerte
data. Dataene struktureres hierarkisk i elementer markert med <starttag> og </sluttag>.
Attributter beskriver elementene.
XML har hovedsakelig blitt brukt til layoutbeskrivelser for mobilapplikasjonen i dette prosjektet.
3.2
JavaScriptObjectNotation (JSON)
"address_components" : [
{ "long_name" : "Gothenburg",
"short_name" : "Gothenburg",
"types" : [ "locality", "political" ]
}
]
(Figur 3.2 A – ‘’Utdrag fra JSON response fra Google Places Api’’ )
JSON er en tekstbasert representasjonsstandard for utveksling av data. I likhet med XML
organiseres JSON hierarkisk, men i motsetning til XML som baserer seg på elementbeskrivelse,
bruker JSON objekter for datautvekslingen. JSON har blitt brukt til datautveksling mellom
mobilapplikasjonen og server i dette prosjektet.
3.3
REpresentional State Transfer (REST)
REST er en arkitektonisk stil for utforming av skalerbare webtjenester. Den baserer seg på en
klient-server arkitektur, der ressurser via lett lesbare URI aksesseres og manipuleres gjennom
HTTP-metodene.
14
3.4
Java for Android
Standard programmeringsspråk for Android-applikasjoner er Java med Android SDK. Logisk
programmering blir gjort i Java-syntaks, mens det meste av den visuelle programmering blir
gjort i XML.
3.4.1 Dalvik VM
I syntaks er standard Java og Java for Android like, men en Androidapplikasjon kjører på en
annen type VM enn andre Javaapplikasjoner. Dalvik VM er basert på et subset av Apache
Harmony-prosjektet, og kjører ikke Java byte kode, men sitt eget format kalt DEX (Dalvik
Executable Format)
3.4.2 Valg av programmeringsspråk
Gruppemedlemmene har betydelig erfaring med Java for Android, samtidig var det et
tungtveiende argument for oss at vi ville ha en applikasjon som kunne kjøre på iOS også. Vi så
på cross-platform-alternativer som Xamarin og Appcelerator Titanium.
Etter råd fra veilederne våre på Accenture, valgte vi å bruke Java for Android. På denne måten
kunne vi fokusere på å produsere en god app, og kode bra i et språk vi allerede var kjent med.
3.5
ASP.NET Web API
ASP.NET er et rammeverk for server med åpen kildekode. Det er i utgangspunktet designet for
utvikling av dynamiske websider, men har de siste årene også fått fasiliteter for API-routing som
vi har brukt for å lage REST-APIen i Semitone.
3.6
Utviklingsmiljøer
3.6.1 Android Studio
For Androidapplikasjonen har vi valgt å bruke Android Studio. Android Studio bygger på
JetBrains IntelliJ IDEA Software og er designet spesielt for utvikling til Android.
3.6.2 Visual Studio
Visual Studios er en IDE utviklet for Microsofts .NET-teknologi, med støtte for flere språk som
blant annet Python, C#, Node.js og HTML/JavaScript.
3.7
Eksterne biblioteker og APIer
3.7.1 Spring for Android
Spring-rammeverket er en applikasjon for Java med åpen kildekode, og er en samling av flere
rammeverk. Spring for Android er fokusert på REST-kommunikasjon, og har en fullstendig
REST-klient som vi har brukt i kommunikasjon fra applikasjonen til server.
3.7.2 Robospice
Androidapplikasjoners oppbygging fører til en del utfordringer når det kommer til
nettverksoperasjoner. En aktivitet representerer et skjermbilde, og aktivitetens livssyklus er
knyttet til skjermbildets synlighet.
15
Robospice håndterer dette ved å la en Singleton Service kjøre lokalt i applikasjonen, og la
aktiviteter få tilgang til denne ved hjelp av SpiceManagers. På denne måten kan tjenesten kjøre
hele tiden, og nettverksoperasjoner stoppes og startes uten problemer.
3.7.3 Google Places API
Google Places API tilbyr flere måter å aksessere lokasjonsdata fra Googles databaser. I
Semitone har vi brukt JavaScript-biblioteket for autocomplete i appen og for å få tak i
koordinater på serversiden.
3.7.4 Git
Git er et system for versjonskontroll- og distribueringssystem. Hver utvikler jobber med sin egen
lokale versjon som «flettes» sammen på server. Vi har brukt Git for både server og
mobilapplikasjonsprosjektet. Vi har brukt GitHub som Git-server, og vekslet mellom å bruke
GitHubs UI og Git kommandolinje.
3.7.5 Azure-server
Microsoft Azure er en cloud computing platform, og er integrert med Visual Studio.
3.7.6 Entity Framework
Entity Framework er en Object-Relational Mapper som brukes i .NET-rammeverket for arbeid på
relasjonell data basert på domenemodeller. Med andre ord gjør Entity Framework jobben med å
behandle data i ulike representasjoner slik at ulike teknologier kan bruke, og jobbe med, disse
uten datainnlesningskode fra utvikler.
(Figur 3.7.6 A – «Entity Framework Mapping»)
3.7.7 Microsoft Azure Blob
Microsoft Blob gir brukere mulighet til å lagre
store mengder av ustrukturert data, som kan bli
aksessert fra hvor som helst i verden ved hjelp
av HTTP eller HTTPS. Microsoft Blob består av 3
hovedkomponenter.
(Figur 3.7.7 A – «Blob»)
16
Container: en container er en gruppering av et sett med blob’er. Alle blob’er må være i en
beholder.
Blob: en fil av enhver type eller størrelse. En blob kan enten være en block eller page.
Storage Account: all aksess til Azure lagring er gjort gjennom en storage konto.
3.8
Shared Preferences
Android gir mange muligheter til å lagre data i en applikasjon. En av disse er Shared
Preferences, som gjør det mulig å lagre og hente ut data i form av nøkkelverdi par. Passer
ideelt hvis man for eksempel skal lage IDen til en bruker.
3.9
Valg av ulike teknologier
3.9.1 Java for Android
Etter råd fra veilederne har vi valgt å programmere med Java for Android. Cross-platform
teknologier som Xamarin og Tamarin ble diskutert, men vi har valgt å fokusere på god koding i
et språk vi kjenner. For et proof of concept har dette vært en god løsning, men det er en
avgjørelse som bør diskuteres hvis applikasjonen skal videreutvikles for et kommersielt marked.
3.9.2 Valg av Azure
Ettersom vi bestemte oss for å ta i bruk Visual studio til å håndtere forespørsler for databasen,
ble bruk av Microsoft Azure en naturlig løsning for lagring av databasen og webserveren. Det at
Visual Studio integrerer bruk av Azure i tillegg til at Microsoft Azure fakturerer for faktisk bruk,
gjorde dette valget av lagringsenhet enkelt.
3.9.3 Webserver
Entity Framework Code First
For oppbygningen av databasen har vi brukt Entity Framework
Code First. Code First-tilnærmingen gir en bedre kontroll over
koden enn om vi hadde brukt Model First eller Database First.
Med Code First-tilnærmingen koder man selv modellene som blir
bruk til å generere databasen og man trenger ikke å forholde seg
til en rekke automatisk genererte filer.
Med Database First vil ikke relasjonene eller attributtene
nødvendigvis bli slik man ønsker. Selv om det ofte er løsninger
for problemer med genereringer av automatisk kode så gir valget
av Code First-tilnærmingen oss full kontroll over databasen, og
lar oss trygt spesifisere forhold, størrelse og restriksjoner.
(Figur 3.9.3 A – ‘‘Entity framework’’)
17
LINQ
Databaseforespørslene skjer ved hjelp av LINQ, som er en Microsoft .NET Framework
Component og er allerede integrert i Visual Studio. Vi har erfaringer med LINQ fra før av, så
dette ble en enkel avgjørelse.
18
Prosessdokumentasjon
4.
Innledning av samarbeid
4.1
Samarbeid i gruppa
Da vi begynte samarbeidet, bestemte vi at vi skulle møtes tirsdag, onsdag og torsdag fra 09.00
til 16.00, men opplevde at dette fungerte dårlig. Folk kom ofte for sent, og det ble uttrykt fra
medlemmer i gruppa om at det å sitte sammen så lenge per dag var en slitsom måte å jobbe
på. Vi bestemte oss derfor for å definere en ‘’kjernetid” mellom klokka 10.00 - 14.00, i denne
tiden skulle alle være tilstede, så var det opp til hver enkelt om de ville ta resten av tiden
hjemme eller fortsette å sitte sammen.
Bachelorprosjektet er 2/3 av studiepoengene dette semesteret, vi bestemte derfor at 3 av 5
arbeidsdager i uka skulle gå til arbeid med oppgaven. Med andre ord skulle hver av oss jobbe
minst 3*8 timer i uka. I tillegg bestemte vi at vi skulle sitte og jobbe på Accenture på torsdager.
Vi kom opp med en koselig idé for å holde oppe arbeidsmoral og en god stemning i gruppa:
song of the week. Hver uke valgte én av oss en sang som vi hørte på sammen om morgenene.
Dette har funket bra for humør og stemning; vi har fått delt vår kjærlighet for musikk med
hverandre, noe som i stor grad er relatert til prosjektet, og ble tvunget til en liten pause med
felles komplett avslapning eller sporadisk dansing.
4.2
Samarbeid med oppdragsgiver
Accenture driver i utgangspunktet ikke med utvikling av produkter og tjenester mot
konsumentmarkedet; å opptre som stakeholder for en oppstartsbedrift som utvikler en
musikkapp faller derfor utenfor Accenture’s kjernevirksomhet. Likevel er Accenture interessert i
studenter med teknisk innsikt og gode analytiske evner. Accenture sa seg derfor villig til å stille
som en teoretisk produkteier for prosjektet, selv om de ikke egentlig vil få noe ut av
sluttproduktet (prosjektgruppen innehar alle rettigheter for produktet).
4.3
Samarbeid med veiledere
4.3.1 Intern veileder ved Høgskolen
Fra Høgskolen fikk vi tildelt G. Anthony Giannoumis som veileder. Han har blant annet bistått
med utvikling av forretningsidé og presentasjonsteknikk. Vi møttes hver tirsdag på Høgskolen.
4.3.2 Veiledere ved Accenture
Hos Accenture har vi fått hjelp fra Henrik Bjerke og Jonas Korssjøen. Har spesielt vært til hjelp
med bruk av Scrum, og prioritering av oppgaver. Vi møttes hver torsdag på Accenture.
19
5.
Utvikling av kravspesifikasjonen
5.1
Første utkast
Problemstillingen vi har valgt oss har mange aspekter, og det er flere måter å angripe den på.
En viktig del av prosjektet har derfor vært å lage en kravspesifikasjon som oppfyller våre ønsker
og samtidig gir et gjennomførbart produkt.
Kravspesifikasjonen har vært under kontinuerlig endring mens vi jobbet med prosjektet, med
sterk påvirkning fra brukertesting.
Vår første prosjektskisse og forslag til scope2 besto av 6 use case:
1. En bruker har lyst til å finne en konsert å gå på i en gitt uke, eller dato. Brukeren kan bla
igjennom konserter innenfor sine sjangere og sitt område. Brukeren velger konsert og
blir eventuelt sendt videre til billettbooking.
2. Et band trenger en trommeslager. Gjennom applikasjonen kan de finne trommeslagere
innenfor samme sjanger og område som leter etter band.
3. En musiker trenger andre å spille med. Gjennom appen kan musikeren finne andre
innenfor samme sjanger som spiller de instrumentene musikeren leter etter.
4. Bruker skal ha fest og ønsker å hyre et liveband. Ved å gå inn i appen og lete blant de
etablerte bandene innen for en gitt sjanger, kan de finne et som passer til eventet og ta
kontakt.
5. En konsertarena har en ledig kveld for et band/en musiker. Som i use caset over, kan de
finne et band som passer til stedet og booke dem.
6. Bruker har funnet seg et band og de ønsker seg spillejobber. De kan lage en profil for
bandet og slik gjøre seg tilgjengelig for alle som ønsker å booke.
5.2
“No fuss, just music”
Etter oppfordring fra Anthony, skrev vi en rekke elevator pitches3 mens vi arbeidet med
omfanget av prosjektet. Gjennom dette arbeidet kom Rannveig opp med slagordet “no fuss, just
music”. Disse ordene har vært vår bibel; i resten av utviklingsprosessen ble all utvikling og alle
endringer gjort med dette i tankene. Vi ville at musikken skulle stå i sentrum, og at så lite som
mulig skulle være i veien.
For at kun nødvendig informasjon skulle komme fram til brukeren, gjorde vi flere valg:
●
●
●
Band kan kun opplyse om konserter; ingen andre oppdateringer
Det er ingen «vegger» man kan skrive på; ingen kommentarer, og ingen
meldingsfunksjoner
Man må være venn med noen for å sende band- eller konsertforslag
2
Ligger vedlagt som “5. Prosjektskisse”
3
Våre elevator pitches ligger som vedlegg nummer 3
20
●
●
5.3
Man må ha brukernavnet til en annen bruker for å legge dem til som venn, og slik
unngår man tilfeldige/fremmede venneforespørsler
Det skal være minimalt med informasjon om personer og band
Spesifisering av målgruppe
Brukergruppen var på dette tidspunktet dårlig definert. Det vi så på som én brukergruppe var i
realiteten mange ulike grupper mennesker. Målet for applikasjonen var veldig ambisiøst, og en
fullstendig løsning for bygging og tilgjengeliggjøring av lokale musikkmiljø vil inkludere flere
målgrupper. Selv om disse målgruppene har en felles interesse, har de svært forskjellige behov.
Vi bestemte oss for å fokusere på personer som er interesserte og engasjerte i sitt lokale
musikkmiljø.
5.4
Funksjonalitetskutt
Med bakgrunn i “no fuss, just music” og en ny, veldefinert målgruppe, bestemte vi oss for å
kutte ut funksjonalitetene for konsertarenaer og hyring av band, som i use case nummer 4, 5 og
siste del av 6. Under jobbing med elevator pitch og brukertesting innså vi at disse funksjonene
virket overflødige, og litt “på siden” av hva vi ønsket at appen skulle være.
Den skjebnesvangre dagen 20. januar kuttet vi bort vårt hjertebarn; musiker-finner-musikerdelen av appen (se use case 2 og 3). Den gjorde appen mer komplisert uten å føre til mer bruk,
i tillegg til at det falt utenfor den brukergruppen vi hadde valgt å fokusere på.
Vi fjernet også at en skulle bli sendt videre til billettbooking. Mange av konsertene i
applikasjonen, vil være små og ikke ha en nettside for kjøp av billetter. Om vi skulle opprette vår
egen betalingsfunksjon ville det kreve logistikk og sikkerhet som vi ikke hadde hatt tid til å
gjennomføre. Brukertesting var også til hjelp med denne beslutningen.
5.4.1 Diskusjoner etter funksjonalitetskutt
Selv om vi var enige om de større avgjørelsene, var det uenighet i gruppa rundt elementer som
virket som småting. Et eksempel på en slik diskusjon var hvorvidt brukere skulle kunne se hvor
mange følgere et band har, og hvem de er. Dette kom opp som et spørsmål fordi det ble sett på
som unødvendig detalj av enkelte i gruppa. Med andre ord går det i mot “no fuss, just music”.
På en annen side er man som bruker i en slik sammenheng vant til å kunne se hvem av sine
venner som liker et band. Det er helt klart viktig å ta hensyn til hva brukere er vant til når en
utvikler, med tanke på gjenkjennelse og at en tilbyr det som forventes. Samtidig ønsket vi å ikke
bare lage en kopi av tidligere applikasjoner. Det handler om å finne en balanse mellom å være
nyskapende og å skape trygghet for brukeren, samtidig som vi holder oss til “no fuss, just
music”.
Vi innså at det vi hadde sett på som unødvendige smådiskusjoner egentlig hadde vært
symptomer på en større uenighet; hva skulle hovedfokuset i appen være etter
funksjonalitetskuttene? På dette punktet hadde vi kuttet alle use case utenom halvparten av det
første:
21
En bruker har lyst til å finne en konsert å gå på i en gitt uke, eller dato. Brukeren kan bla
igjennom konserter innenfor sine sjangere og sitt område.
I tillegg var vi fremdeles avhengig av band, så de måtte også ha en plass i appen.
Til tross for at vi nå skulle fokusere på kun ett use case var det mange måter å løse det på og
dermed ulike idéer i gruppa. Skulle vi rendyrke ”no fuss, just music”-konseptet, ha lite
interaksjon mellom brukerne, og sikte oss inn mot undergrunnsmiljøer? Eller burde vi heller
gjøre appen tilgjengelig for et bredere publikum; mer Facebook-lignende, slik at brukerne hadde
en news feed og kunne kommunisere med venner om band og konserter? Med andre ord,
burde vi forenkle appen i størst mulig grad eller legge til flere interessante funksjoner?
5.4.2 Use case etter funksjonalitetskuttene
1.
2.
3.
4.
5.
6.
7.
8.
9.
Bruker kan logge inn med egen konto, eller via sin konto fra Google eller Facebook
Bruker får forslag til band basert på hens preferanser og kan legge dem til i lista si
Bruker får forslag til konserter på hens preferanser og kan legge dem til i lista si
Bruker har en venneliste, og kan legge til venner om hen vet brukernavnet
Bruker kan sende bandforslag til sine venner
Bruker kan sende konsertforslag til sine venner
Bruker kan opprette artistprofiler
Bruker kan redigere artistprofiler
Bruker kan opprette konserter for sine artistprofiler
Den endelige kravspesifikasjonen finnes under 9.1 Kravspesifikasjon.
5.5
Brukertestingens innvirkning på oppgaven
Diskusjoner om funksjonaliteter og hva brukere ønsket seg tok opp mye tid i den første delen av
utviklingsprosessen.
Vi valgte derfor å begynne med brukertesting, og bruke tilbakemeldingene aktivt i
beslutningsprosessen. Dette hindret timevis med diskusjoner i gruppa, gjorde oss sikrere på at
det finnes et marked for appen. På grunn av smidigheten i Scrum har vi hele tiden hatt mulighet
til å endre spesifikasjoner basert på tilbakemeldinger.
Brukertesting ble satt i sentrum etter dette, noe som førte til at vi hadde en kravspesifikasjon
som endret seg hele tiden. Vi valgte å ta utgangspunkt i de nye use casene, og var klare for
endringer basert på testing underveis4.
4
Utdypende om våre brukertester under punkt 10. Brukertesting
22
6.
Første sprint (03. feb - 24. feb)
6.1
Oppstart med Scrum
Scrum fungerer best med skreddersydde programmer for planlegging, organisering og
gjennomføring. Vi fikk anbefalt noen verktøy på Scrumkurset vi deltok på hos Accenture, men
siden vi ikke hadde tilgang til disse valgte vi å bruke Agilefant som var et gratis alternativ.
Agilefant er et verktøy for smidig utvikling, men er ikke utviklet spesielt for Scrum. Det
inneholder allikevel de grunnleggende funksjonalitetene vi trengte, som å legge inn oppgaver i
lister, markere disse med status o.l.
6.2
Estimering
Selv om vi hadde hatt et Scrumkurs var vi ikke helt sikre på hvordan vi skulle estimere hvor lang
tid de ulike oppgavene ville ta. Vi prøvde på best mulig vis å følge det vi lærte og gi en liten
oppgave et lavt tall som symbol på oppgavens omfang, og jobbe derifra ved å gi høyere og
høyere tall til større oppgaver. Vi brukte relative story points, som vil si at tallet i seg selv ikke
var en tidsramme eller tilsvarte arbeidstimer. Med relative tall kunne vi likevel lettere velge en
oppgave basert på om man kunne ta en liten eller større arbeidsmengde, uten å henge seg for
mye opp i nøyaktig hvor lang tid man hadde på seg. Arbeidstimer er også vanskeligere å
estimere, spesielt i begynnelsen av programmeringen når man ikke enda er kjent med
prosjektet med tanke på hvordan oppgavene bør løses, ny teknologi, arbeidsmiljø og annet som
spiller inn på effektivitet.
6.3
Problemer med Scrum
Underveis i sprinten ble vi mindre og mindre flinke til å bruke Agilefant fordi det var så
uoversiktlig, og dermed mindre flinke til å bruke Scrum. Vi hadde stand-up, men utenom dette
jobbet vi uten Scrum. Vi fulgte ikke planen nøye nok, tenkte ikke på hvor mye tid en oppgave
tok, og jobbet generelt med det vi selv følte var viktig fremfor det vi hadde loggført i Agilefant at
vi skulle gjøre under 1. sprint. Vi innså derfor ikke at vi hadde underestimert oppgavene og satt
inn alt for mye arbeid i sprinten, og som en følge av dette hang vi langt bak vår egen
framdriftsplan.
6.4
Erkjennelser etter 1. sprint
“Scrum: now it makes sense”
- Oss, etter 1. sprint
Scrum ble tydeligere og enklere i etterkant av 1. sprint. Planleggingen ble lettere å gjennomføre
for neste sprint, samt at vi følte at selve planleggingen virkelig ville hjelpe oss med arbeidet
framover. Dette i motsetning til 1. sprint hvor vi følte at Scrum var i veien, og bare ekstraarbeid.
Vi innså at vi hadde hatt veldig sterk fokus på business-delen av prosjektet, og vi måtte ta en
avgjørelse om at vi i neste sprint skulle prioritere koding for å sikre framgang. I løpet av 1. sprint
hadde vi hatt flere presentasjoner, hvorav én var helt business-rettet og ikke teknisk, vi jobbet
med elevator pitches, og tenkte på hva vi skal gjøre med appen etter at bachelorprosjektet er
ferdig; skal vi være med på Google Summer of Code, skal vi søke om støtte til å fortsette med
23
utvikling av appen, osv. Dette tok masse tid og vi kunne ikke la oss distrahere fra koding lenger,
spesielt siden vi ikke fikk gjort alt vi la inn i 1. sprint.
6.5
Retrospektiv
Vi utførte en retrospektiv av 1. sprint hvor vi skrev opp negative og positive opplevelser.
(Figur 6.5 A - “Retrospektiv for 1. sprint”)
6.5.1 Hva fungerte dårlig, og hvorfor?
Ettersom vi ikke var helt inne i bruk av Scrum, endte det opp med at vi ikke gjennomførte
estimering av tid og oppgaver ordentlig. I tillegg brukte vi relative story points istedenfor noe
fast, som timer, noe som resulterte i at vi bare jobbet så mye vi ville uten å tenke over det.
Programmet vi brukte for å holde oversikt over sprintene, Agilefant, var rotete og ineffektivt. Vi
bestemte at vi enten måtte finne oss et nytt program, eller finne ut av hvordan det kunne
benyttes bedre.
Vi brukte veldig mye tid på å diskutere og det gikk i stor grad utover arbeidet. For eksempel var
diskusjoner om smådetaljer i design unødvendig på dette punktet i prosjektet. Det er bedre å la
hverandre gjøre ferdig det man gjør på sin måte, og heller gi konstruktiv kritikk på det etterpå.
En viktig lærdom etter første sprint er at en diskusjon på flere timer om fargevalg har ikke mye
for seg såpass tidlig i utviklingen.
24
Grunnet kontinuerlig brukertesting gjorde vi en del endringer underveis i sprinten. Scrum, som
smidig prosjektmetodikk, lar oss ta hensyn til forandringer som skjer i løpet av prosjektet.
Allikevel bestemte vi oss for at slikt skulle skje mellom sprintene, i stedet for at vi skulle bruke tid
på endringer, diskusjoner og å planlegge på nytt underveis. For å opprettholde effektivitet i
arbeidet skulle altså sprintene foregå som planlagt, og idéer for endringer spares opp og
diskuteres etter sprintslutt.
6.5.2 Hva fungerte?
Noe som fungerte var «kjernetid». I løpet av sprinten lærte vi hvordan vi best jobbet sammen og
hvordan vi best kunne bruke Scrum. Stand-up funket for oss selv om vi i all hovedsak hadde
oversikt over hverandres arbeid. Det var alltid godt å vite helt konkret hvordan alle lå an i forhold
til planen.
6.6
Presentasjoner
Som utviklere med en idé, holder det ikke å være god på å kode. Det er bra å kunne overføre
konseptet til en teknisk løsning, men like viktig er å kunne presentere arbeidet slik at andre
mennesker blir interesserte og får tro på at en har noe å komme med.
Av å skrive elevator pitches lærte vi mye om hvordan en skaper interesse for et konsept. I løpet
av 1. sprint skulle vi ta dette et skritt videre; vi skulle begynne å holde presentasjoner.
6.6.1 Styringsgruppen i Accenture
Den første presentasjonen vi holdt, var for styringsgruppen hos Accenture. På forhånd hadde vi
forberedt en presentasjon som fokuserte på ideen som lå bak, og prosessen vi hadde hatt så
langt. Målet var å få styringsgruppen med på tankegangen, og gi de tro på mulighetene
konseptet førte med seg.
Det var en skivebom. Vi fikk tilbakemeldinger på at styringsgruppen ville se planer for hvordan vi
skulle få gjennomført den teknologiske delen av prosjektet. Presentasjonen burde inneholdt
risikoanalyser, milepælsplaner og andre styringsdokumenter. Vi lærte en god lekse:
Know your audience.
6.6.2 Veilederen på høyskolen og andre interessenter
Til neste presentasjon var vi bedre forberedt. Vi visste at de som skulle være tilstede var
interesserte i idéen og hvordan vi ville utvikle den. På presentasjonen hos Accenture var det
ikke alle som skjønte hvem målgruppen var, så vi endret på presentasjonen for å sikre at dette
kom ordentlig frem.
Tilbakemeldingene denne gangen var svært annerledes. Vi fikk høre at prosjektet var
interessant, og vi fikk mye input til hva vi burde gjøre fremover. Spesielt ble det tatt opp hvordan
vi skulle behandle sjangerbegrepet som kriterie; en sjanger er ikke lenger beskrivende for én
type musikk, og veldig få artister kan plasseres i kategorier på samme måte som tidligere.
25
7.
Andre sprint (24. feb - 07. apr)
7.1
Planlegging
Vi startet med å skrive opp oppgavene som var igjen fra forrige sprint, samt det vi ifølge
fremdriftsplanen skulle være ferdig med i løpet av de neste tre ukene. Vi satte hovedtemaene i
bobler for å finne ut i hvilken rekkefølge oppgavene måtte gjøres; hva som var avhengig av at
andre ting var ferdig.
(Figur 7.1 A ''2. sprint - avhengigheter'')
Vi kom fram til at det følgende måtte bli ferdig i gitt rekkefølge:
1.
2.
3.
4.
Brukergrensesnitt og funksjonalitet på band-, konsert- og vennesider
Knytte opp disse mot databasen
Hente ut informasjon fra databasen til lister
Caching av data for å hindre unødvendig oppslag i databasen, og dermed gjøre appen
mer effektiv og raskere
5. Brukergrensesnitt for notifikasjoner
6. Funksjonalitet og UI for at brukere skal kunne sende invitasjoner til konserter eller
forslag til band, og kunne legge til venner
7. Innlogging med Google og Facebook. Dette var uavhengig av at det andre var ferdig,
men vi satte det til slutten av sprinten. Det var litt uvisst hvor lang tid det ville ta, og det
var uansett viktigere å få ferdig det andre først.
Da vi følte at vi hadde fått opp punktene fra fremdriftsplanen, strukturert dem og estimert
tidsbruk, førte vi det opp i Agilefant. I og med at vårt første forsøk ble så rotete, bestemte vi oss
for å starte fra scratch. Denne gangen virket det ryddigere og ganske oversiktlig. Vi skjønte med
en gang at vi kom til å bli mye flinkere til å bruke programmet mer aktivt. Vi fant ut at vi enkelt
26
kan se hvem som skal gjøre hva, hvilken rekkefølge det skal gjøres i og hvor mye tid som bør
brukes. Beklager, Agilefant, vårt hat mot deg var uberettiget, det var vår feil hele tiden.
(Figur 7.1.B - “Screenshot fra Agilefant 19.02.15”)
7.2
Diskusjoner underveis
Vi diskuterte noen mulige endringer i appen underveis. Grunnet et ønske om å forenkle appen
ble det foreslått å lage en nettside og la band registrere seg der. Det ville ført til mindre
funksjonalitet i appen, og en enklere måte for band å lage profil. Fordi det allerede hadde gått
med en del tid til programmeringen av dette i applikasjonen la vi ideen på vent som en mulig
forbedring under videreutvikling.
Det ble bestemt at vi skulle kutte siden med brukers egen profil. Dette betyr at brukeren ikke ser
sin egen profil; lister over band og konserter finnes i sidemenyen allikevel, og brukernavn og
bilde kan endres i settings. Da kunne førsteside i appen heller være ”explore”, der man får
anbefalinger på konserter og band. Ettersom dette ikke ville være mye arbeid å få til, tenkte vi at
det kunne tas etter 3. sprint når vi hadde fått en bedre oversikt over appen i sin helhet, og over
explore/søkedelene av appen.
Vi lot alt ligge for øyeblikket, og ville programmere ferdig før vi eventuelt gjorde større endringer,
i tråd med det vi bestemte oss for etter 1. sprint. Ettersom vi hadde endret oppgaven drastisk så
mange ganger allerede, visste vi at det ikke ville vært gunstig for framgang å bruke tid på dette
midt i en sprint.
27
7.3
Avslutting av 2. sprint
Vi var ikke ferdig med de planlagte arbeidsoppgavene ved avtalt sluttdato tre uker etter start,
den 17. mars. Dette skyltes en del fravær i gruppa grunnet sykdom og casedager hos
Accenture, samt at vi nok en gang tok inn for mange oppgaver i sprinten.
Vi begynte å avslutte sprinten den 18. mars mens sprintplanen på Agilefant så slik ut:
(Figur 7.3 A - “Agilefant den 18.03.15”)
Alle svarte symboler er «deferred»; det vi ikke rakk som skulle dyttes over i neste sprint. Det var
tydelig alt for mye igjen, og vi hadde ikke på dette punktet et fungerende produkt slik man skal
på slutten av en sprint. Dette ga ikke resultatet bruk av Scrum egentlig skal gi, og det var
demotiverende.
28
7.3.1 Første utsettelse av sluttdato på 2. sprint
Med tanke på at vi allerede hadde lagt inn en dag til i sprinten fordi Rannveig var på casedag
hos Accenture dagen før, valgte vi å gjøre resten av uka til en del av denne sprinten. Vi mente
at på denne måten kunne vi fullføre det vi planla og ha 3. sprint som en «ren» søke-sprint.
Planen var alltid at vi skulle arbeide med søkealgoritmer, -oppsett, utseende og alt som
omhandler søk, i den 3. sprinten og ikke før.
Gjennom samtale innså vi at vi allikevel ikke ville rekke å bli ferdig med alt. Det var mange
småting, som å knytte elementer og funksjonalitet sammen, som ikke sto i sprintplanen, men
som var helt nødvendig for at vi skulle ha et fungerende produkt ved enden av sprinten. Vi
valgte derfor å fremdeles dytte innlogging og caching til neste sprint, ettersom dette viste seg å
være svært store oppgaver som vi ikke ville rekke å bli ferdig med uansett. Alle andre svarte
«deferred» endret vi tilbake til pending/in progress og fortsatte derifra.
7.3.2 Andre utsettelse av sluttdato på 2. sprint
På dette punktet innså vi at vi var nødt til å bruke en del tid på dokumentasjonen sammen. Mye
kodetid gikk bort på dette, og vi kom ikke særlig lenger på sprinten. Tirsdagen etter, da vi
egentlig skulle planlegge ny sprint, var Emilie på casedag hos Accenture så planleggingen
måtte utsettes nok en dag. Vi tok igjen avgjørelsen å gjøre resten av uka til en del av 2. sprint.
Det «eneste» store vi har igjen er søkedelen, og det burde være i en samlet sprint.
Vi utsatte altså vår 3. og siste sprint med tilsammen tre uker; én fordi vi så at vi hadde for mye
gjenstående kodearbeid, én til grunnet annet forefallende arbeid, mest dokumentasjon, og én
for påskeferie. Dette medførte at vi i stor grad hang bak, og vi innså at siste sprint ville bli meget
stressende og kanskje umulig å gjennomføre. Vi følte et stort behov for å kutte mer
funksjonalitet.
7.4
Nødvendig med videre funksjonalitetskutt
Vi sjekket litt nærmere definisjonen av og eksempler på et proof of concept. Vi kom fram til at vi
har jobbet mer mot en prototype enn et proof of concept. Et POC trenger ikke å være like ferdig,
like fungerende, eller ha like flott brukergrensesnitt som det en prototype må. Vi hadde jo et
ønske om å lage noe mer ferdig, men innså nå at vår oppgave var et POC av en grunn.
Ekstremt mye tid går med på å sette rammer, endre funksjonalitet og generelt bestemme
hvordan oppgaven skal bli ettersom vi begynte med kun en idé; et uferdig konsept.
Vi innså at det måtte noen drastiske kutt til for å komme i mål. Dette skulle vi gjøre på slutten av
uka når vi hadde gjort unna det vi absolutt måtte gjøre ferdig. Vi bestemte at vi måtte begynne å
sette funksjonalitet på en liste over “dette skal den ferdige versjonen inneholde”.
29
7.5
Retrospektiv
(Figur 7.5 A - “Retrospektiv for 2. sprint”)
2. sprint endte opp med å bli mye lenger enn planlagt. Selv om vi var nærmere med
tidsestimeringen denne gangen, endte det opp med å gå for sakte framover. Dette hadde med
fravær i gruppa å gjøre, men også dårlig kommunikasjon:
Et større problem i 2. sprint var at vi ikke var flinke nok til å fortelle hverandre om eventuelle
endringer som ble gjort av hver enkelt. Enten dette var endring i et use case, eller nye oppgaver
som ikke ble lagt inn i Agilefant. Dette medførte forvirring og dårlig samarbeid, fordi planen ble
endret uten at gruppa hadde blitt enige. Mye av dette var funksjonalitet som trengtes og uansett
måtte gjøres, vi hadde bare ikke tenkt på det under planlegging. Vi innså likevel at hvordan det
skulle utføres måtte tas opp i plenum.
7.5.2 Hva fungerte?
Agilefant virket til det vi trengte programmet til, og vi hadde en ordentlig oversikt over
oppgavene, hvor lang tid det skulle ta, hvem som skulle gjøre hva, og hva som var påbegynt
eller ferdig. Vi hadde færre diskusjoner som tok opp mye tid, dog som nevnt i avsnittet over
hadde flere diskusjoner kanskje vært gunstig for samarbeidet denne sprinten.
30
8.
Tredje sprint (08. apr - 01. mai)
8.1
Planlegging
Ettersom dette var vår siste sprint, bestemte vi oss for å planlegge på denne måten:
-
Skrive opp alle oppgaver som gjensto
- inkludert det som var uferdig eller utsatt fra forrige sprint
Sette viktighet på hver oppgave
- lav, middels, høy
Dele opp hvem som skulle gjøre hva
Vi satte det inn i Agilefant og resultatet ble som i figur 8.2 A på neste side. Her brukte vi ikke
story points som forklarte hvor lang tid hver oppgave ville ta, men tallene fra 1-3 som respektivt
symboliserte lav til høy viktighet.
Et unntak var “Bruker får forslag på band og konserter etter område og sjanger” som fikk tallet 5
for å symbolisere at det tross alt er det viktigste. Semitone er jo en anbefalingsmotor i all
hovedsak, så anbefalingene er avgjørende for appen.
8.2
Valget om ikke å estimere tid
Det var mye arbeid igjen, og vi ikke hadde tid til å fullføre alt. Mange av funksjonalitetene måtte
kuttes, og vi var nødt til å bestemme oss for hva og hvordan. Vi var også klar over at vi ville bli
nødt til å jobbe mye mer per uke enn tidligere. Det handlet ikke nå om å finne ut hva vi rekker
på et satt antall timer - det handlet om å få gjort så mye som mulig innen 1. mai.
Av disse grunnene valgte vi å sette prioritet på oppgavene fremfor å estimere tiden de ville ta. Vi
var nødt til å sette målet om å få ferdig et proof of concept som viser vår idé, foran hvor mange
timer vi ønsket å jobbe. På denne måten kunne vi være sikre på at funksjonene vi
implementerte ville være de viktigste for appen. I tillegg ville det uunngåelige, voldsomme
funksjonalitetskuttet skje automatisk når vi ikke rakk å gjøre mer.
Under i figur 8.2 A er oversikt over oppgavene i Agilefant før vi begynte på vår siste sprint. Flere
av disse oppgavene var overført fra 2. sprint; disse er merket med “2. sprint” (se boksene etter
navnet på oppgaven), og hvis de var påbegynt vil de i tillegg ha en gul “I” som står for “in
progress”. Resten er “not started”.
31
(Figur 8.2 A - “Screenshot fra Agilefant den 08.04”)
32
8.3
Underveis
Valget om ikke å estimere tid fungerte for oss; vi visste alltid hva vi burde gjøre, og ønsket om å
bli ferdig med så mye som mulig drev oss videre.
Allikevel var vi ikke ferdige til fredag 1. mai som planlagt. Vi ble nødt til å bruke mer tid på de
siste nødvendige detaljene for å få et fungerende produkt.
8.3.1 Tekniske grunner til at vi ikke ble ferdige
Dagene som ledet opp til 1. mai var fremgangsmessig ineffektive på grunn av problemer som
tok mye tid. Spesielt skapte datautveksling fra mobilapplikasjonen til serveren trøbbel. Om det
var spesialtegn i URLen som ble sendt, avviste serveren requesten, og spørringene mislyktes. I
tillegg var det objekter som ble sendt inn via url som inneholdt mer enn 12 parametere. Ikke
pent designmessig, og upraktisk i forhold til implementering.
På grunn av dårlig tid hadde vi satt oss veldig overfladisk inn i Spring-rammeverket for Android,
og når det kom til objekter hadde vi så langt kun klart å implementere henting fra server. Etter å
ha satt oss bedre inn i rammeverket fant vi ut hvordan vi kunne mappe objektene til JSON og
legge inn disse i kroppen til en HTTP POST. Dette gjorde at vi ble kvitt de lange parameterne,
og problemene med spesialtegn i disse.
Vi hadde fremdeles metoder der det ikke ga mening å bruke JSON-objekter, og var nødt til å
finne ut hva som skjedde. Etter endring av innstillingene for URLer i web.config-fila fungerte det
å sende inn de fleste spesialtegn, men ikke punktum. Uansett hva vi gjorde i web.config-fila fikk
vi en «404 not found» tilbake fra server.
Etter sinte utrop og tanngnissing gikk det opp for oss:
Punktumet «i /api/[email protected]» gjorde at server leste det som en fildestinasjon, ikke en
spørring. Løsningen var enkel; vi la til en «/» på slutten av spørringene og problemet var løst.
8.3.2 Andre grunner til at vi ikke ble ferdige
Fremdeles var kommunikasjon i gruppa et problem. Selv om vi fortsatte med stand-up i Scrumstil hver gang vi møttes, ble det for lang tid mellom torsdags- og tirsdagsmøtene våre. Nå som vi
alle jobbet mye hver dag, klarte vi ikke holde hverandre oppdatert på hva vi holdt på med over
helgene. På den lyse siden fikk vi allikevel gjort veldig mye, men bedre kommunikasjon kunne
gjort arbeidet mer effektivt. Større bruk av online kommunikasjon på slutten gjorde ting enklere
og mer oversiktlig.
8.4
Etter sprint
Noe som ble tydelig for oss i etterkant var at vi burde ha tatt hensyn til alt som måtte gjøres for å
lage et fungerende produkt. Med andre ord burde vi tidligere ha sluttet å ta inn nye oppgaver
slik at vi hadde rukket å sy alt sammen og finpusse produktet.
Likevel fikk vi gjort det aller meste på lista vår for sprinten. I figur 8.4 A under er en liste over
oppgavene vi ikke fikk gjort.
33
(Figur 8.4 A – «Screenshot fra Agilefant 13.05, filtrert til å vise deferred oppgaver»)
Vi har planer om å fortsette arbeidet med appen, så vi valgte å sette disse oppgavene til
«utsatt» (deferred, svart «D») istedenfor «blocked» eller noen av de andre valgene Agilefant
hadde. Noe av det første vi ble enige om å ikke fullføre for denne gang var streaming av
musikk, og innlogging med Googlekonto (for mer om hvorfor se 9.4 Oppfyllelse av krav til
funksjonalitet). Dette var de to viktigste og største use casene som står i vår endelige
kravspesifikasjon som vi ikke rakk å få ferdig.
Andre ting vi prioriterte bort var redigering av konserten etter at de har blitt opprettet, og at man
kunne velge bakgrunnsbilde. Vi lagde en løsning for at konserter ikke skulle være uten bilde;
hvis bandet som skal holde konserten har et opplastet bilde vil dette settes som bakgrunn, ellers
benyttes et default bilde som ble stemt fram som favoritt under brukertesting.
Vi hadde også planer om å legge inn brukerinstruksjoner i appen som viser hvordan den funker
første gang den åpnes. Vi innså at dette ikke er viktig for et proof of concept, og droppet det.
Generelt er vi fornøyde med det vi oppnådde. Vi fikk implementert all funksjonalitet som var
nødvendig for å vise fram idéen vår.
34
8.5
Retrospektiv
(Figur 8.5. A – «Retrospektiv for 3. sprint»)
Som nevnt brukte vi ikke vanlig Scrum-planlegging denne sprinten, og dette var mye fordi vi var
stresset. Planleggingen førte til at vi fikk kommet rett i gang med programmering og jobbet
effektivt, men siden det ikke var satt noen rammer sleit vi med organisering og å slutte tidsnok.
Vi jobbet individuelt veldig bra, men det krever mye samarbeid når man skal knytte deler
sammen. Vi kunne ha gjort dette bedre på begynnelsen av sprinten, men de siste ukene ble vi
flinkere til å kommunisere over nett mellom møtene. Dette gjorde at vi alltid var oppdatert på
hva alle drev med, og det ble lettere å jobbe mot slutten.
Mye av tiden gikk med til dokumentasjonen. Vi undervurderte hvor mye tid vi kom til å bruke.
Planen var å jobbe oss ferdige med rapporten etter vi var ferdig med kodingen, men når vi gikk
over den planlagte kodesluttdatoen måtte vi jobbe med begge deler parallelt. Vi fikk muligheten
til å få rapporten vår sett over av en ekstern person flere ganger før endelig innlevering. Vi satte
datoer for hvilke dager vi skulle sende den inn, og disse datoene måtte holdes for at vi skulle
rekke å få tilbakemelding og gjøre endringer før innlevering av prosjektet. Derfor ble kodingen
nedprioritert dagene før disse fristene og det gikk masse tid uten at vi fikk ferdigstilt vårt proof of
concept.
35
8.5.2 Hva fungerte?
Som nevnt var vi veldig effektive denne sprinten. Presset fra den oppkommende innleveringen
og vår frykt for ikke å bli ferdig fikk oss gjennom svært lange dager med mye jobbing. Vi ville
ikke at vår dårlige planlegging i begynnelsen av prosjektet skulle ødelegge for produktet vårt. Vi
hadde fremdeles stor tro på appen, og vi ville gi andre mulighet til å se dette selv, istedenfor å
måtte ta vårt ord for det.
Siden vi hadde jobbet relativt individuelt gjennom prosjektet hadde vi ikke alltid oversikt over alle
teknologiene som var i bruk. I tillegg tok det tid for alle å få tilgang til Visual Studio og server.
Dette var den første sprinten der alle hadde tilgang til alt fra starten av. Nå som vi i tillegg
generelt skjønte mer av teknologiene, ble det lettere å arbeide effektivt.
Vi ble også bedre på å prioritere tid. Det virker kanskje ikke sånn, ettersom vi også denne
gangen sprengte tidsskjemaet vårt, men vi klarte å sjonglere dokumentasjon og programmering,
og hadde relativt klare planer for hva vi skulle gjøre hver dag.
36
9.
Resultater
9.1
Kravspesifikasjon
Følgende er kravspesifikasjonen for produktet for dette prosjektet. Videre idéer og ønsker for
videreutvikling av appen er ikke inkludert i denne kravspesifikasjonen. Vi valgte heller å
samkjøre den med vår product backlog5 og hvordan vi lå an underveis, og derfor ikke inkludere
flere funksjoner enn vi kunne få implementert i løpet av prosjektet. Vi jobbet altså med
kravspesifikasjonen vår fram til begynnelsen av 3. sprint.
Gruppa eier kildekoden og konseptet, og ingen andre skal jobbe videre på prosjektet. En
kravspesifikasjon som inneholder informasjon om videreutvikling er altså ikke nødvendig. På
denne måten var vi også sikre på at alt i spesifikasjonen var gjennomførbart og gjennomtenkt.
9.1.1 Overordnet systembeskrivelse
Appen skal gi bruker anbefalinger til konserter og band basert på deres geografiske område og
sjangerpreferanser. Det skal være mulig å opprette bandprofiler og konserter, og legge til band
og konserter man liker i sine lister.
9.1.2 Funksjonelle egenskaper og brukergrensesnitt
Bruker:
●
●
●
●
●
●
5
Innlogging i systemet
○ med brukerkonto laget i appen
○ med Facebook-konto
○ med Google-konto
Sette og redigere informasjon om seg selv:
○ brukernavn
○ profilbilde
○ foretrukne sjangre
○ geografisk lokasjon
○ radius rundt gitte lokasjon
Få anbefalinger av band og konserter basert på område og foretrukne sjangre
Legge til andre brukere som venn
○ kun hvis man vet brukernavnet, ingen åpne søk med auto-fullfør i søkefeltet
Se profilene til sine venner
Se liste over sine venner
Denne product backlogen ligger som vedlegg «2.3.2 Product backlog ved slutten av prosjektet»
37
Band:
●
●
●
●
●
●
●
●
Se sin bandliste
Legge til et band i sin bandliste
Fjerne band fra sin bandliste
Sende venner bandforslag
Opprette band
Se liste over sine opprettede band
Sette og redigere informasjon om bandene sine:
○ bandnavn
○ bilde
○ linker
■ til Facebook
■ til SoundCloud
■ til annen nettside
○ sjangre
○ område
○ sang
Offentlig profil for band som inneholder informasjonen over
Konserter:
●
●
●
●
●
●
●
Se sin konsertliste
Legge til en konsert i sin konsertliste
Fjerne konserter fra sin konsertliste
Sende venner konsertinvitasjon
Opprette konsert om man har et band
Sette og redigere informasjon om konsertene sine:
○ Tittel på konserten
○ Bandnavn (automatisk, ikke-redigerbart)
○ Dato og tid
○ Sted
○ Bilde
Offentlig plakat for konsert som inneholder informasjonen over, samt
○ hvor mange venner som skal på konserten/har lagt den til i sin liste
○ hvem av sine venner som skal på konserten
38
Notifikasjoner inne i appen:
●
●
Får varsel når man mottar
○ venneforespørsel
■ Man får valget om å godta eller avvise
○ konsertinvitasjon
■ Man får mulighet til å legge til konserten i sin liste direkte
○ bandforslag
■ Man får mulighet til å legge til bandet i sin liste direkte
Får varsel når et band man har i sin liste legger ut en ny konsert
○ Man får mulighet til å legge til konserten i sin liste direkte
Brukergrensesnitt:
Vi valgte å ikke sette noen konkrete krav for ferdig design ettersom dette er et proof of concept,
og det viktigste er at vi får vist idéen vår. Allikevel hadde vi noen ønsker for det ferdige
produktet som vi gjerne kunne jobbe mot under utvikling:
●
●
●
●
Det skal være veldig visuelt i bruk, og simplistisk
Bruk heller bilder enn tekst
○ Eks. band- og konsertbilder for anbefalinger, ikke tekst
Lite farger, ta heller i bruk brukernes bilder for farger
Grunnleggende brukervennlighet
○ Ryddig oppsett og selvforklarende linker, knapper og informasjon
39
9.2
Teknisk beskrivelse av produktet
Nå som vi har vist kravspesifikasjonen vi kom fram til, er det på tide å vise det tekniske
produktet vi faktisk utviklet. Det gås ut i fra at leser av denne delen har grunnleggende
kunnskap om teknologiene vi har benyttet. I de følgende kapitlene har vi beskrevet systemets
løsninger.
For en utfyllende beskrivelse av funksjonalitet sett fra brukers perspektiv med skjermbilder fra
appen, se vedlegg «6. Brukerveiledning».
For en beskrivelse av web API-referansene vi har brukt, se vedlegg «7. HTTP API References».
For å se oversikt og beskrivelse av alle klassene se vedlegg «8. Klasseoversikt – applikasjon»
og «9. Klasseoversikt – server».
9.2.1 Systemets hovedkomponenter
● En Androidapplikasjon i frontend
■ kodet i Java med Android SDK
■ bruker Spring-rammeverkets REST-klient for å kommunisere med server
● REST API
■ tilbyr ressurser til frontend i form av JSON-objekter via URIer
■ kodet i ASP.NETs web-API, med attribute routing
● Database
■ SQL database, cloud service fra Windows, basert på SQL Server
(Figur 9.2.1 A – ‘‘Systemets hovedkomponenter’’)
9.2.2 Frontend: Androidapplikasjon
Applikasjonen som helhet har tre hovedfunksjoner
1. Gi bruker forslag til artister
2. Gi bruker forslag til konserter
3. Opprette artistprofiler
Her følger en teknisk beskrivelse av applikasjonen.
40
Følgende rutiner og sider i appen forklares:









Explore
o Explore bands
o Explore concerts
Innstillinger
o Settings
o Location chooser
o Genre chooser
Band/artister
o Band list
o Band profiles
Konserter
o Concert list
o Concert poster
Bandadministrasjon
o Your bands
o Edit band
o Add concert
Venner
o Your friends
Notifikasjoner
o Notifications
Registrering/innlogging
o Register
o Login
Mer om frontend-teknologier
o Robospice
o Trådprogrammering
o Caching
o Bildehåndtering
o Cachinghåndtering og oppdateringer
o SharedPreferences
o Bruk av BroadcastReceiver
o Skriving til cache
41
Explore
Navn: Explore bands
Formål:
Gir brukere en mulighet til å finne nye band i sitt nærområde. Hvis en bruker vil ha mer
informasjon om et band så er det bare å trykke seg inn på bandet. Brukere kan selv oppdatere
listen ved å swipe nedover og få ut nye forslag.
Hva rutinen gjør:
Explore er siden bruker først kommer til etter å ha logget inn. En ny tråd startes som sjekker om
det er noe i cachen, og eventuelt oppdaterer den. På explore-siden har bruker mulighet til å se
hvilke band som er i sitt nærområde. Når man først oppretter en bruker vil man ikke ha noe
området spesifisert, og derfor er det satt et standardområde. Dette er Oslo Sentralstasjon
ettersom appen vår i førsteomgang er beregnet på Oslo (ettersom det er et proof of concept).
På Explore-siden vil det for band være bandets bilde, samt navnet på bandet og hvor langt unna
brukeren de er, enten i meter eller kilometer avhengig av avstanden. Det vil være 3 band per
rad, og hvis bruker har nok band i området sitt vil det vises 15 band, randomisert. For å
oppdatere listen og vise nye band kan bruker swipe nedover. Da vil loadingsymbolet vises og
en ny spørring blir kjørt til serveren. Hvis requesten lykkes vil 15 nye band vises.
Når bruker forlater Explore-listen blir den cachet, eller cachen oppdateres om den eksisterende
listen er ulik den i cache. Derfor er bruker nødt til å manuelt oppdatere explore-siden hvis det er
gjort endringer i settings for at disse endringene skal ta effekt. Hvis listen din ikke har noe
innhold (ikke noe å cache) vil listen prøve å oppdatere seg selv hver gang du går inn på
explore.
Navn: Explore concerts
Formål:
Gir brukere en mulighet til å finne nye konserter i sitt nærområde. Hvis en bruker vil ha mer
informasjon om en konsert så er det bare å trykke seg inn på konserten. Brukere kan selv
oppdatere listen ved å swipe nedover og få ut nye forslag.
Hva rutinen gjør:
Tilsvarende som på banddelen.
42
Innstillinger
Navn: Settings
Formål:
Gir brukeren en mulighet til å endre innstillingene sine. Her kan en bruker endre profilbildet sitt,
velge sjangre de liker, sette sin geografiske posisjon og bestemme hvor mange km rundt denne
lokasjonen de vil ha forslag fra.
Hva rutinen gjør:
Når en bruker først kommer inn på Settings-siden vil det kjøres en ny spørring mot serveren.
Spørringen vil prøve å hente brukeren sitt område, sjangere, radius og profilbilde. Hvis
forespørselen gjennomføres som den skal, vil dataene bli satt inn på sine respektive steder på
siden. Hvis brukeren ikke har nett eller forespørselen ikke går, så vil brukeren få en toastmelding om dette. Bruker kan også endre sine innstillinger. Når en bruker har endret
innstillingene sine vil det først sjekkes om brukeren har nett og deretter bli sendt en ny
forespørsel mot serveren. Et loadingsymbol vil kjøre ved siden av elementet bruker prøver å
oppdatere. Når forespørselen er håndtert vil loadingsymbolet forsvinne og bruker vil få en
melding om at elementet er oppdatert. Hvis elementet ikke klarte å oppdateres vil bruker få en
toast-melding om dette isteden, og hvis bruker ikke har nett vil en toast forklare dette.
Oppdatering av radiusen skjer ved at du drar eller trykker på seekbaren. Når seekbaren stoppes
vil appen merke det og sende en ny forespørsel til serveren for å oppdatere radiusen.
Oppdatering av bilde skjer ved at du trykker på bildet. Du får herfra mulighet til å velge et bilde
fra galleriet ditt. Når du har valgt et bilde vil det sendes en ny forespørsel til serveren for å prøve
å oppdatere bildet.
Navn: Location chooser
Formål:
Gi bruker mulighet til å velge område ved hjelp av en autocomplete-funksjon
Hva rutinen gjør:
Nå bruker trykker på områdeikonet enten i Settings, Add Concert eller i Edit Band opprettes et
fragment med et AutoCompleteTextView. Via forespørsler til Google Places API, mottar appen
JSON-objekter som brukes for å gi bruker forslag basert på input.
Når bruker trykker på tekstområdet vises det en knapp. Når denne trykkes på startes en
spicerequest til server om å oppdatere brukers, konsertens eller bandets område.
43
Navn: Genre chooser
Formål:
Gir bruker mulighet til å velge sjangre for seg selv og for sitt band. Sjangrene er predefinerte for
nå.
Hvordan rutinen kjører:
To lister sendes med inn som argumenter til fragmentet; en liste med valgte sjangre, og en med
tilgjengelige sjangre hentet fra server.
Disse listene vises på skjermen med plussikon for mulige sjangre som kan legges til, og
minussymbol for de som kan fjernes. Når bruker trykker på et av elementene med plussikon,
legges denne til i lista over valgte sjangre, og fjernes fra lista over tilgjengelige sjangre. Når
bruker trykker på et av elementene med minussymbol, fjernes denne fra lista over valgte
sjangre og legges til i lista over tilgjengelige sjangre. Når bruker trykker på ok-knappen nederst i
fragmentet, startes en spicerequest for oppdatering av brukers sjangre på server.
Band/artister
Navn: Band list
Formål:
Gir brukeren mulighet til å se listen over band de liker og har lagt til i listen sin. I tillegg kan en
bruker søke etter band basert på bandnavn. En bruker kan også gå inn på et band for å få mer
informasjon, og eventuelt legge eller fjerne band fra bandlisten sin.
Hvordan rutinen kjører:
Når du først går inn på «Your bands» så vil en ny tråd kjøres for å sjekke om det finnes noen
band i cachen og deretter oppdatere listen.
Søking etter band skjer helt øverst til høyre ved å trykke på forstørrelsesglasset. Når en bruker
begynner å skrive inn noe her vil det bli sendt en ny spørring til server, så listen oppdateres
fortløpende mens brukeren skriver. Hvis spørringen gir resultat og noen bandnavn inneholder
det bruker søker på, vil disse vises i listen. Ellers vil listen bli tom med en melding om at det ikke
finnes noen band med det navnet.
Hvis bruker har lyst til å gå tilbake fra søk til sin opprinnelige liste så kan brukeren enten hviske
ut teksten, eller trykke på kryss-tegnet til høyre for søkefeltet for å viske ut. Hvis bruker trykker
to ganger på søkefeltet så vil søkeviewet lukke seg.
Når brukeren trykker seg ut av bandlisten vil en ny tråd kjøre som sjekker om listen er ulik den
som allerede finnes i cachen. Hvis listen er forskjellig så vil listen bli cachet på nytt.
44
Navn: Band profile
Formål:
Gir brukeren informasjon om et spesifikt band, og mulighet til å legge til bandet i sin bandliste
om hen ønsker det. Informasjon som vises er bandnavn, område, og link til Facebook- og
SoundCloudside, samt en generell internettlink om disse finnes.
Hva rutinen gjør:
Når aktiviteten starter setter applikasjonen i gang en spicerequest som henter bandobjektet fra
server basert på ID. En annen request settes i gang, og blir lagt i spicemanagerkøen, som
henter informasjon om hvorvidt bruker har lagt til bandet i sin liste. Når bandet er hentet settes
denne requesten i gang, og en knapp i høyre hjørne blir synlig når denne er utført.
Om bruker ikke har lagt til bandet i sin liste, er knappen grå. Om bruker trykker på knappen
sendes en request til server om å legge til dette bandet i brukers liste. Om bandet allerede
ligger i brukers liste, er knappen i en annen farge. Hvis brukeren nå trykker på knappen sendes
en request til server om å fjerne bandet fra brukers liste.
I tillegg til informasjon om bandets sjangre og tilholdssted, er det tre link-knapper. En til bandets
Facebookside, en til bandets SoundCloudside, og en til en valgfri nettside. Når bruker trykker på
en av disse fører linkene deg videre; om bruker har SoundCloud eller Facebookapplikasjonen
på sin mobil åpnes lenkene i de tilhørende applikasjonene.
Konserter
Navn: Concert list
Formål:
Gir brukeren mulighet til å se de konsertene de har tenkt til å gå på. I tillegg til at man kan søke i
sine egne konserter eller etter nye konserter. Man kan i tillegg gå inn på konserter hvis man vil
ha mer informasjon om en spesifikk konsert.
Hva rutinen gjør:
Når en først går inn på «Concert list» så vil en ny tråd startes som sjekker cachen og
oppdaterer listen. Søking etter konserter skjer helt øverst til høyre når en trykker på
forstørrelsesglasset. Når en bruker begynner å skrive inn noe her vil det bli sendt et request til
serveren på spørringen. Listen oppdateres hele tiden mens brukeren skriver. Hvis spørringen
gir resultat vil disse vises i listen. Ellers vil listen bli tom med en melding om at det ikke finnes
noen konserter med den tittelen.
I motsetning til søk på personer vil konsertsøk vise alle konserter der tittelen inneholder
spørringen. Hvis en har lyst til å komme tilbake til sin opprinnelige liste så kan en enten hviske
ut informasjonen som er i søkefeltet eller trykke på kryss-tegnet til høyre for søkefeltet. Ved å
trykke to ganger på krysstegnet til høyre for søkefeltet vil søkeviewet lukkes.
45
Når en trykker seg videre ut av «Concert list», enten i form av å trykke på en konsert eller gå inn
på en annen fane, vil en ny tråd kjøre som sjekker om listen er forskjellig fra den som allerede
finnes i cachen. Hvis listen er forskjellig så vil listen bli cachet på nytt.
Navn: Concert poster
Formål:
Gir brukeren mulighet til å se all informasjon om en konsert. Profilen til en konsert, om man vil.
Bruker kan legge til konserten i sin liste og invitere vennene sine.
Hva rutinen gjør:
Når bruker trykker på en konsert vil ConcertActivity kjøres og all informasjon om konserten
hentes fra server. Bandets navn hentes fra bandid’en som ligger lagret på konserten og en tråd
vil også hente alle brukerens venner. Hvis bandet har et bilde, vil dette være lagret på
konserten. Hvis bildeURL for konserten er tom, betyr det at bandet ikke hadde bilde da de
opprettet konserten, og et standard bilde benyttes. Det vil også kjøres en spørring til server som
sjekker om denne konserten ligger i brukerens liste allerede. Et loadingsymbol vil kjøre, og ved
positivt svar fra nevnte spørring vil det i høyre hjørne stå «Remove from list» og ved negativt
svar «Add to concert list». Loadingsymbolet endres til passende ikoner; henholdsvis et grønt
«check»-symbol og et plusstegn. Når man legger den til, lagres konsertid og brukerid sammen
på server, og brukers «concert list» vil bli oppdatert når man besøker den neste gang.
Bruker kan invitere venner ved å trykke på konvolutten i nedre høyre hjørne. Dette åpner en
liste over vennene til brukeren, og når noen inviteres vil bruker få tilbakemelding om requesten
gikk bra eller ikke. Mottaker vil få opp invitasjonen under sine notifikasjoner.
En egen tråd sjekker hvor mange av brukerens venner som skal på konserten, og legger ut
dette tallet på plakaten foran teksten «friends are going».
Bandadministrasjon
Navn: Your Bands
Formål:
Gir brukeren oversikt over sine bandprofiler, og mulighet til å redigere bandenes profiler og
legge til konserter.
Hva rutinen gjør:
Når en bruker først går inn på bandadminsiden sendes det en ny forespørsel til server for å
hente alle bandene brukeren er administrator for. Hvis spørringen ble vellykket vil listen bli satt
inn, og det vil for hvert av bandene startes en egen tråd for å dekode URL’en om til bilde. Hvis
spørringen ikke gikk vil personen få en feilmelding om dette.
46
Når brukeren trykker på et av listeelementene, sjekker applikasjonen om bandet ligger i listen av
bandobjekt som er hentet fra server. Hvis dette er tilfellet opprettes ett fragment som viser en
oppsummering av informasjonen til bandet og to knapper: «Edit Profile» og «Add concert».
Hvis bandet ikke finnes i listen, setter applikasjonen i gang en spicerequest til server. Når
bandet er hentet fra server, legges det i listen, og oppsummeringsfragmentet vises.
Om bruker trykker på «Edit Profile»-knappen i oppsummeringsfragmentet, startes en ny «Edit
Band»-aktivitet. Bandobjektet blir sendt med som et serialisert objekt til aktiviteten. Om bruker
trykker på «Add Concert»- knappen i oppsummeringsfragmentet startes en ny «Create
Concert»-aktivitet.
Navn: Edit band
Formål: Gir bruker mulighet til å redigere sine bandprofiler.
Hva rutinen gjør:
1. Navn
Et tekstfelt i hovedvinduet
2. Bilde
Når en bruker trykker på «bilde»-knappen kan brukeren velge bilder fra galleriet sitt. Hvis
et bilde blir valgt vil det bli laget en fil basert på bildepathen, og det blir sendt en
HttpPost request opp mot serveren med denne filen. Hvis filen klarer å bli opplastet vil
brukeren få en toast-melding om at opplastingen var vellykket. Hvis filen ikke klarte å bli
opplastet vil brukeren få melding om dette.
3. Posisjon
Se «Location Chooser»
4. Linker
Når bruker trykker på link-knappen åpnes et dialogfragment med tre tekstfelt. Ett for
Facebook, ett for SoundCloud og ett for en link til en hvilken som helst nettside.
5. Genre
Se «Genre Chooser»
For alle tekstfelt gjelder samme prosedyre. Når bruker trykker på et tekstfelt, blir en knapp i
høyre hjørne synlig. Når bruker trykker på denne sendes en spicerequest til server for
oppdatering av verdien i tekstfeltet.
Navn: Add Concert
Formål:
Bruker får mulighet til å opprette en konsert hvis hen allerede har opprettet et band.
47
Hva rutinen gjør:
Aktiviteten «Crater Concert» startes. Layoutene er lagt opp til å ligne på «Concert poster» slik at
bruker skal få best inntrykk av hvordan den kommer til å se ut. Ved start av aktiviteten hentes
det valgte bandets ID med inn fra «Your Bands» slik at bandnavnet står ferdigskrevet. Det
kjøres også en request som sjekker om bandet har et bandbilde. I så fall hentes bilderuten som
dekodes og settes som bakgrunn. Hvis bandet ikke har et bilde settes et defilet bilde som
bakgrunn. Hvorvidt bandet har et bilde sendes med som en Boleyn til serversiden når konserten
lagres. Hvis true hentes bandets bildeURL og lagres med konserten. Hvis false settes URL’en til
å være tom. Ved en sjekk på dette under «Concert Poster» vet applikasjonen om den må hente
ut et bilde, eller sette default.
Lokalet eller adresse for konserten velges via location chooser som er beskrevet tidligere. Når
brukeren trykker på «Post concert»-knappen kjøres en request for å lagre dataene. Om
resultatet er positivt, vil brukeren tas tilbake til «Your concerts» og få en melding om at
konserten ble publisert.
Venner
Navn: Your friends
Formål:
Den gir brukeren mulighet til å se hvilken venner de har lagt til. En kan også gå inn på profilene
til vennene sine og se de hva slags konserter de skal gå på. En bruker kan også bruke
søkesymbolet øverst til høyre for å finne nye venner, eller fjerne sine gamle venner.
Hva rutinen gjør:
Når bruker først går inn på «Your Friends» vil en ny tråd startes som sjekker cachen og
oppdaterer listen (mer om dette kan ses under «cachinghåndtering og oppdateringer»).
Hvis en bruker begynner å skrive inn i søkesymbolet vil en ny aktivitet startes. Hver gang en ny
bokstav blir skrevet inn i tekstfeltet vil en ny countdown kjøres. Hvis brukeren ikke skriver inn
noe på 1 sekund vil det sendes en request til serveren basert på spørringen.
Et loadingsymbol vil kjøre mens brukeren skriver inn teksten. Hvis spørringer som sendes til
serveren gir et positivt svar vil loadingsymbolet ved siden av navnet bli byttet ut med et hvitt
hjerte hvis bruker ikke er venn med personen, og et rødt hjerte hvis bruker er venn med
personen.
Hvis hjertet er hvitt kan du trykke på det for å sende en vennerequest til personen, og da vil
loadingsymbolet starte. Hvis requesten din ble vellykket vil hjertet bli rødt. Hvis du ikke klarte å
legge til personen vil du få en toast-melding om dette og loadingsymbolet vil forsvinne. Hvis
hjertet er rødt kan du trykke på det for å fjerne vennen. Da vil også loadingsymbolet starte og
requesten utføres. Hjertet blir hvitt igjen hvis det var vellykket.
For å gå tilbake til sine venner fra «Your friends» kan man trykke på tilbakepilen øverst til
venstre. Når man går vekk fra vennelisten vil en ny tråd kjøres for å sjekke om listen er
annerledes. Hvis listen er annerledes vil cachen oppdateres.
48
Notifikasjoner
Navn: Notifications
Formål:
Gir brukeren en mulighet til å kunne se notifikasjonene sine. Her vil en bruker få informasjon om
nye venneforespørsler, få informasjon om en bruker har akseptert en venneforespørsel, se
invitasjoner til konserter som venner har sendt og se om en venn har akseptert en
konsertinvitasjon.
Hva rutinen gjør:
Man kommer seg til notifikasjonene sine ved å trykke på bjellen som ligger i actionbar. Bjellen
vil være tilgjengelig på alle hovedaktivitetene. Når man først går inn på notifikasjonsaktiviteten
vil et loadingsymbol starte, og det sendes en forespørsel til serveren for å hente alle
notifikasjonene til brukeren. Når appen får svar vil loadingsymbolet fjernes.
Hvis spørringen ble vellykket vil listen bli oppdatert til den nye listen. Brukeren vil også få en
melding på at listen har blitt oppdatert. Siden bildene kommer tilbake som url’er vil bildene bli
dekodet fortløpende.
Når man får inn den oppdaterte listen vil notifikasjoner man ikke har sett før ha en lysegrå
bakgrunn. Det vil også til høyre være spesifisert hvor lenge det er siden notifikasjonen ble sendt
til brukeren; «just now», «x m», «x h» eller «x d». Hvis en bruker har lyst til å oppdatere
notifikasjonene sine så kan de selv swipe nedover for å kjøre spørringen på nytt. Hvis listen ikke
klarer å bli oppdatert så vil man få en melding som dette i form av en toast.
Det er flere forskjellige notifikasjoner man kan få:
Venneforespørsel: hvis noen har søkt etter ditt eksakte navn så kan de legge deg til som
en venn. Bruker vil da få opp en venneforespørsel i notifikasjonsaktiviteten. Denne kan bruker
enten si ja eller nei til.
Hvis brukeren sier nei vil loadingsymbolet komme opp igjen og et nytt request mot server vil
kjøre. Hvis requesten lykkes vil venneforespørselen vil bli fjernet.
Hvis brukeren sier ja vil loadingsymbolet komme opp igjen og et nytt request vil bli kjørt mot
serveren. Hvis det lykkes er bruker nå venn med personen.
Venneaksept: hvis en bruker aksepterer en venneforespørsel vil avsender få en
notifikasjon på at vennen har akseptert. Brukeren selv vil få en ny notifikasjon som bekrefter at
de nå er venner. Hvis bruker ikke aksepterer venneforespørselen vil ikke avsender få noen
informasjon om dette.
Konsertinvitasjon: bruker kan få invitasjoner til konserter fra sine venner. Bruker kan som
med venneforespørsler enten si ja eller nei til invitasjonen. Ved aksept vil konserten legges til i
brukers concert list.
49
Konsertaksept: hvis en bruker aksepterer en konsertinvitasjon, så vil avsender få en
notifikasjon på at brukeren har akseptert. Bruker får selv en bekreftelse på at hen har godtatt.
Hvis bruker avslår får ikke avsender noen notifikasjon.
Bruker kan forlate notifikasjonslisten enten ved å trykke på tilbakepilen øverst til venstre eller
ved å trykke på en av notifikasjonene. Hvis bruker trykker på en konsertinvitasjon eller
konsertakseptnotifikasjon vil hen komme til konserten det gjelder. Bruker kan også trykke på en
venneakseptnotifikasjon og få opp vennens profil, men ikke en venneforespørsel som ikke er
godtatt. Man skal ikke kunne se profilen til noen man ikke er venn med.
Registering/innlogging
Navn: Register
Formål:
La en bruker registrere seg med mail, brukernavn og passord så de kan ta i bruk appen.
Hva rutinen gjør:
En bruker kan registrere seg med mail ved å trykke på «Or register»-teksten på
innloggingssiden. Når en bruker kommer til registeringssiden må de skrive inn mail, brukernavn
og passord. De kan deretter trykke på «registrer» knappen.
En ny spørring blir så sendt til server for å prøve å registrere personen. Hvis mailen eller
profilnavnet allerede er tatt vil ikke registreringen gjennomføres, og brukeren vil få melding om
dette i appen. Hvis i midlertidig registreringen var vellykket vil brukeren bli logget inn i appen og
sendt rett til explore-siden.
Navn: Login
Formål:
la en bruker logge seg inn med enten Facebook eller vanlig email innlogging
Hva rutinen gjør:
En bruker kan logge seg inn i appen enten ved å trykke på Facebook-knappen «Log in with
Facebook» eller ved å skrive inn mail og passord og trykke på «log in» knappen. En bruker kan
registrere seg med vanlig mail ved å trykke på register-knappen.
Hvis en bruker ikke har nett når de trykker på «log in» vil de få en melding(toast) om at de ikke
har nett. Hvis en bruker derimot har nett så vil det komme opp et loadingsymbol ved siden av
«log in»-knappen og en ny forespørsel vil bli sendt til serveren. Hvis innloggingen var vellykket
vil brukerens id bli lagret i en sharedpreferences og brukeren vil deretter bli logget inn. Hvis
brukernavnet eller passordet var feil får brukeren en toast-melding om feilen. Hvis det skjedde
en annen uventet feil på serveren får brukeren også melding om dette.
Hvis brukeren derimot har lyst til å logge seg inn med Facebook kan de trykke på «Log in with
Facebook»-knappen. Man vil da bli logget rett inn, med mindre det er første gang brukeren
50
logger inn med Facebook; brukeren blir nødt til å godta at Facebook kan brukes som innlogging.
Hvis innloggingen ikke går vil man få feilmelding om dette.
For å bruke Facebooks API, krever Facebook at applikasjonen er registrert hos dem. For å
verifisere dette brukes nøkkelhasher. Siden Semitone fortsatt er under utvikling har vi kun
debugnøkler, og disse er knyttet til hver enkelts utviklermiljø. Facebookinnlogging vil derfor
midlertidig kun fungere med versjoner av applikasjonen som er installert fra en av
gruppemedlemmenes datamaskiner.
Mer om frontend-teknologier
Robospice
Ved håndtering av webserverforespørsler har vi tatt i bruk Robospice på appsiden av produktet.
Trådprogrammering
Data som hentes fra serveren blir alltid kjørt på en ny tråd for at det ikke skal forstyrre
hovedprogrammet. I tillegg blir data som hentes fra cachen kjørt på en ny tråd. Dette fører til at
appen ikke stopper i utførelsen når cachen hentes inn eller lagres. Eksempel på trådstarting ved
start og slutt av en aktivitet/fragment kan ses i figur 9.2.2 A.
(Figur 9.2.2 A – onStop- og onStart-metodene i BandActivityList.class tar og starter en ny tråd for å hente
ut og for å lagre listen (caching). Ved å bruke trådprogrammering her så unngår man at hovedtråden må
vente på at cachen skal lastes og lagres. Dette fører til en bedre flyt i programmet og gjør opplevelsen
bedre for brukeren)
51
Caching
Ettersom nedlasting av bilder tar relativt lang tid, er appen bygd opp slik at listene til en bruker
caches når de forlater siden. Lagring av bilder tar også litt tid (ca. 1-2 sek), så dette gjøres på
en egen tråd. Denne tråden startes når onStop-metoden blir kalt og lagrer hele listen til en
bruker. Når en bruker da går inn igjen på listen sin, blir det i onStart-metoden kalt en ny tråd
som laster inn dataene fra cachen. Etter at dataene er lastet inn, vil tråden kjøre en forespørsel
mot server der den ber om listen til brukeren. Når appen får svar, vil den sjekke om listen som
kom fra serveren stemmer med den listen som ble hentet fra cachen. Hvis listen ikke stemmer
vil elementene som er ulike bli oppdatert. Slik vil bruker kunne se sine opprinnelige lister selv
om hen ikke har internettilgang. Metoden for lagring av hele vennelisten kan ses i figur 9.2.2 B.
(Figur 9.2.2 B - metode i som tar inn vennelisten til en bruker. Metoden lagrer hele vennelisten på pathen
som er medsendt. Ettersom bildene ikke kan lagres sammen med listen (fordi de lagres som bitmap) så
blir disse først lagret for seg selv, så blir det satt inn i objektene før hele listen lagres)
Bildehåndtering
Ettersom appen henter ut alle bildene i form av URLer, kjøres det egne tråder for å dekode
disse om til bilder(bitmap). Alle listene som bruker bilder vil starte en egen tråd for hvert bilde
som må dekodes. Bildene vil derfor bli dekodet fortløpende og man trenger ikke vente på at alle
bildene blir omgjort før de kan bli vist.
Cachinghåndtering og oppdateringer
“Explore concerts”, “Explore bands”, “Concert list”, “Band list” og “Your friends” bruker alle
caching av lister. Når brukeren først går inn på en av disse listene vil en ny tråd startes som
sjekker om det er noen objekter i cachen. Mens dette pågår starter et loadingsymbol som viser
at appen jobber. Hvis tråden finner noen objekter i cachen vises disse for brukeren og
52
loadingsymbolet vil avsluttes. Hvis det ikke finnes noen objekter i cachen så vil loadingsymbolet
fortsette.
På Explore-sidene vil listen bare prøve å oppdatere seg hvis brukeren ikke har noen objekter i
listen. På de andre listene vil derimot tråden alltid starte en nettverksrequest til serveren for å få
tak i den oppdaterte listen. Hvis dette ikke går vil en feilmelding vises. Hvis requesten lykkes vil
det skje en forward og reverse lookup av listen, som sjekker at den nåværende listen hentet fra
cachen er oppdatert. Hvis den nye listen fra serveren har noen objekter som listen i cachen ikke
har så blir disse satt inn. Objekter som kun er i cache blir fjernet, og objekter der dataene er
endret blir oppdatert.
Når du trykker deg videre ut av disse listene vil en ny tråd kjøre som vil sjekke om listen er
forskjellig fra den cachen som allerede finnes. Hvis listen er forskjellig så vil listen bli cachet på
nytt. Hvis listene ikke er forskjellige trenger ikke listen bli cachet på nytt.
SharedPreferences
På applikasjonssiden brukes sharedpreferences til å holde på IDen til brukeren. Når en bruker
logger inn, lagres brukerIDen. Hver gang en bruker bytter mellom aktiviteter(sider) vil metoden
getUser sjekke om det finnes en brukerID. Hvis det ikke gjør det blir brukeren sendt ut til logg
inn-siden.
Bruk av sharedpreferences fører til at en bruker ikke trenger å logge inn hver gang de skal inn
på appen; når en bruker åpner appen sjekkes det om IDen ligger i sharedpreferences, og hvis
dette er tilfelle sendes brukeren rett til explore-siden.
Bruk av BroadcastReceiver
Når man først logger seg inn i appen så vil appen starte en ny broadcast kalt
NotificationsBroadReceiver. BroadcastReceiveren vil starte en ny service kalt SendNotifications.
Denne servicen gjør slik at en ny service kalt MyService vil bli kjørt hvert 20 sekund. Hver gang
denne servicen blir kjørt, vil det gjøres en spørring mot serveren som sjekker om personen har
nye notifikasjoner.
Hvis personen har nye notifikasjoner så stoppes servicen og det lagres en sharedpreferences
på at brukeren har nye notifikasjoner. Når en bruker da enten bytter aktivitet eller kommer
tilbake til appen så vil da bjellen helt øverst farges rød for å vise at brukeren har nye
notifikasjoner.
Hvis du går inn i notifikasjonsaktiviteten så vil bjellen bli sin normale farge igjen og myService vil
igjen bli kjørt hvert 20 sekund igjen for å sjekke etter nye notifikasjoner.
Skriving til cache
ObjectOutputStream-klassen kan bli brukt til å skrive primitive datatyper og Java-objekter til en
OutputStream. Den klarer i midlertid ikke å skrive bilder til strømmen sammen med objektene.
For å unngå at bildene må lastes inn på nytt hver gang blir bildene skrevet til fil hver for seg.
Deretter blir pathen til bildet satt inn i objektene. For eksempel på konserter vil hele
53
konsertlisten skrives til fil der hver konsert har en filpath til bildet sitt. Eksempel på skriving av
hele listen til fil kan ses i figur 9.2.2 C.
(Figur 9.2.2 C - viser metoden storeConcerts. Metoden tar imot konsertlisten som skal caches og pathen
til hvor dataene skal bli lagret. ObjectOutputStream blir brukt til å lagre filen på pathen som er sendt med,
og det returneres true hvis listen klarte å lagre og false hvis listen ikke klarte å lagre. SharedPreferences
brukes til å lagre pathen til konsertlisten, og denne pathen vil bli hentet ut når en bruker går inn på sin
konsertliste for å så bruke ObjectOutputStream til å lese inn konsertlisten.)
54
9.2.3 Backend
Serversiden er bygget opp i flere lag, dette er for å dele de forskjellige logiske delene av
serveren og gjøre det enklere å endre på én del av programmet uten at det har noen effekt på
resten. Det er brukt trådprogrammering og caching for å gjøre serveren så pålitelig og rask som
mulig, samtidig som det er brukt hashing på kritiske deler av databasen for å øke sikkerheten.
Følgende skal beskrives for backend:










Oppbygning
Trådprogrammering
Caching
Den ferdige databasen
LINQ
Komprimering på server
Opplasting til serveren
Blob
Routing
Oppbygning
Serversiden vår er altså bygd opp i flere lag. Vi har basert oppbygningen på designmønsteret
model-view-controller, men serveren vår har ikke noe view så vi har ikke en komplett MVCstruktur. Vi har prøvd å bygge modellen på MVC for å kunne dele opp og kategorisere delene
så bra som mulig. Webserveren er bygd opp slik at en controller tar imot forespørslene og
sender disse videre inn (se figur 9.2.3 A). Dataen vil bli hentet ut fra databasen, og hvis mer enn
én parameter skal tilbake, vil dataen bli mappet over til et objekt (model) og deretter sendes
tilbake til controlleren som gir svar til applikasjonen.
(Figur 9.2.3 A – Viser hvordan serveren vår er oppbygd for forespørsler som angår band.
Først mottar en bandcontroller forespørsler fra applikasjonen og sender disse videre til
bandmanager. Bandmanager håndterer caching og fjerning av cache når data endres.
Hvis bandmanager ikke har noe i cachen på det som blir forespurt så sendes
forespørselen videre til dbBand som kommuniserer med databasen)
55
Vi har 5 hovedcontrollere på serversiden. Disse er UserController, BandController,
ConcertController, FriendsController, og GenreController. Hver controller tar imot kall som
omhandler sine «temaer». Dette gjør strukturering på serversiden mye mer oversiktlig. Ved å
basere serveren på model-view-controller øker vi i tillegg sikkerheten og unngår risikoer som vi
ville hatt hvis appen fikk tilgang til å manipulere databasen direkte istedenfor å gå igjennom flere
lag med kommunikasjon.
Trådprogrammering
I tillegg til å basere serveroppbyggingen på model-view-controller så er trådprogrammering
implementert på serversiden. Ved hjelp av trådprogrammering vil serveren bruke mindre RAM,
og generelt utføre forespørslene raskere. Et eksempel på oppsett av tråder på serversiden kan
ses i figur 9.2.3 B. Vi har på serveren brukt trådtypen Task. Task er en asynkron operasjon som
kan bli sett på som en smart tråd, bare at den har ett høyere nivå av abstraksjon. Å bruke Task
istedenfor Thread gir mer effektiv og skalerbar bruk av systemressursene. I tillegg får man mer
kontroll enn man får med en tråd. Det er bygd et rikt sett med API’er rundt Task, som gjør det
friere og enklere å håndtere for eksempel at en tråd skal vente på at noe skal skje.
(Figur 9.2.3 B – metode i bandcontroller som tar imot en parameter og venter på svar fra Bandmanager.
Await gjør at metoden venter på at den får svar fra bandmanager, og Async task gjør at metoden kjører
som en tråd asynkront. Når den mottar et svar, returnerer den en liste med bandobjekter.)
På grunn av dette så er det Task som er det foretrukket API’et i .NET-rammeverket for å skrive
flertrådet, asynkron og parallell kode. Og vi har bestemt oss for å følge disse anbefalingene.
Caching
I tillegg til trådprogrammering, hjelper caching til å øke responstid på serveren. Et eksempel på
hvordan caching brukes kan ses i figur 9.2.3 C. Hvordan oppdateringer på data som er i cachen
håndteres kan ses i figur 9.2.3 D.
56
(Figur 9.2.3 C – Viser hvordan caching gjøres når det hentes ut et band. Metoden i bandmanager lager
en cache-nøkkel basert på id’en til bandet og sjekker deretter om dette objektet finnes i cachen. Hvis
objektet finnes, returneres objektet; ellers sendes forespørselen videre til en metode i dbBand som
utfører forespørselen mot databasen. Hvis forespørselen gir et objekt tilbake, caches dette før svaret
sendes tilbake til controlleren som igjen sender informasjonen videre til applikasjonen.)
(Figur 9.2.3 D – når noe i cachen skal oppdateres, hentes cachenøkkelen til dette objektet for å fjerne det
fra cachen før man oppdaterer dataen i databasen.)
Ved å cache objekter ved hjelp av IDen til bandet, gjør vi systemet mer skalerbart. Det vil føre til
at mange brukere kan få tak i et objekt uten at alle må spørre serveren hver gang, selv om de
skal ha samme objekt. Vi har midlertidig også cachet mer brukerspesifikke ting som bandlisten
og konsertlisten til en bruker.
For oppbygningen av selve databasen brukes Entity Framework Code First. Et eksempel på
hvordan en modell er oppbygd kan ses i figur 9.2.3 E.
57
(Figur 9.2.3 E – Viser bruker domeneklassen der [key] definerer primærnøkkelen og public virtual List<x>
definerer mange-relasjon til de andre domeneklassene. Vanlig public virtual x definerer en relasjon til
domeneklassene.)
Bruk av Entity Framework Code First gir oss enklere kontroll over databasen. Det gjør det
enklere å holde styr på domeneklassene våre, og vi trenger ikke å bekymre oss over automatisk
generert kode. Code first gjør det også enklere å oppdatere databasen, noe som vi har hatt
behov for etterhvert som prosjektet har utviklet seg.
Den ferdige databasen
Figur 9.2.3 F viser det ferdige databaseoppsettet. Alle tabellene som vises er konstruert ved
hjelp av Code First-tilnærmingen og har derfor egne domenemodeller.
58
(Figur 9.2.3 F – Viser den ferdige databasen og relasjonene mellom de forskjellige objektene.
“*” representerer en primærnøkkel mens “(FREM)” representerer en fremmednøkkel. Hovedtabellene i
databasen er Band, Concert, User, Genre og Notifications, og resten er koblinger mellom disse.)
LINQ
For å håndtere dataforespørsler mot serveren så bruker vi LINQ. Et eksempel på en LINQ
forespørsel kan ses i figur 9.2.3.G.
(Figur 9.2.3 G – viser en typisk LINQ-forespørsel, der alle notifikasjonene til en bruker hentes ut.
Listen blir sortert etter datoen så den nyeste notifikasjonen ligger først. Listen hentes asynkront, og
en await er brukt slik at task’en venter på at forespørselen gjør seg ferdig.)
59
Komprimering på server
For å unngå at bildene tar alt for lang tid å laste inn så komprimeres bildene på serversiden.
Ettersom vi har fokusert på det visuelle i Semitone så har vi en del bilder. For å unngå at dette
tar alt for langt tid, har vi i databasen én url for de store bildene og én for de små bildene.
De små bildene til en bruker (brukerprofil) blir minket til 50*50 og komprimert ned til 20l. De små
bildene som brukes av band og konserter i listene blir minket ned til 100*100 og til 25l. (100l er
størst kvalitet og 0l er lavest kvalitet)
Opplasting til serveren
Opplasting av bilder skjer ved
at applikasjonen sender filer
til serveren. Serversiden vil
deretter motta filen og
konvertere filen til et bilde før
dette bildet sendes videre
innover. Bildet vil deretter bli
komprimert og gitt ny
størrelse, og deretter
opplastet ved hjelp av
Microsoft Azure Blob
Storage. URLen blir returnert
og blir så lagret i databasen
på den medsendte
brukerIDen. Mottakelsen av
en fil kan ses i figur 9.2.3 H.
Blob
(Figur 9.2.3 H - metoden ChangePic i UserController tar imot en
parameter og sjekker om en fil har blitt opplastet. Filen blir deretter hentet
ut og konvertert til et bilde før bildet sendes videre inn til Usermanager for
opplasting. Usermanager kontakter deretter UploadImage(Image) i
BaseManager.)
Bildeopplastning på server skjer ved hjelp av Blob lagring fra Microsoft Azure. Azure Blob er en
tjeneste for lagring av store mengder ustrukturerte data. .NET Azure Blob Storage gir oss en
måte å ha et filsystem lett tilgjengelig fra skyen. Bruk av Azure Blob lagring gjør at bildene til
appen enkelt kan aksesseres fra over alt i verden ved hjelp av RESTful API. Opplasting av
bilder til serveren kan ses i figur 9.2.3 I.
60
(Figur 9.2.3 I. Metoden UploadImage i BaseManager tar imot et bilde for opplasting til server.
Storage-informasjonen hentes fra Azure, en referanse til containerne gfx hentes, bildet
opplastes på denne containeren ved hjelp av en blob og URLen til blob’en returneres.)
Routing
For routing av spørringene opp mot server har vi brukt ASP.NETs Web API 2.
(Figur 9.2.3 J - RegisterRoutes setter opp routingen i applikasjonen. Når en URL kommer inn til server
sjekkes {controller}-parameteren og deretter {action}-parameteren i den spesifiserte Controlleren)
(Figur 9.2.3 K - {action}-parametritt sjekkes i Controllerklassen, i [Route]-attributtet)
61
9.3
Proof of concept
Fordi oppgaven er et proof of concept, har vi stått friere til å definere de oppgavene som må
implementeres. Vi har valgt å ikke ta med alle våre idéer og ønsker inn i kravspesifikasjonen, til
fordel for en bedre implementasjon av de viktige oppgavene for å demonstrere konseptet på en
god måte.
Med andre ord har vi for eksempel latt være å legge inn ikke-funksjonelle krav for prosjektet i
kravspesifikasjonen. Med ikke-funksjonelle krav mener vi for eksempel skalering, pålitelighet,
robusthet, sikkerhet og ytelse. Dette vil gi et bedre, mer velfungerende produkt, men det har
ikke noe med selve funksjonene til produktet å gjøre. Vi har i liten grad tatt hensyn til dette
under utviklingen. Uansett ville vi ikke sette noen krav for dette, men heller implementere det vi
underveis mente var nødvendig for de funksjonelle kravene.
Et godt eksempel er at vi, som nevnt, har brukt caching og trådprogrammering for å øke ytelse
og hastighet i systemet. Det eneste punktet hvor vi har tenkt på sikkerhet i denne omgang, var
ved lagring av passord. På alle passordene legges det til et salt, før det så hashes, og deretter
lagres.
Det var altså flere aspekter vi ikke tok med i kravspesifikasjonen, men hvordan klarte vi å utføre
det vi faktisk tok med?
9.4
Oppfyllelse av krav til funksjonalitet
Vår kravspesifikasjon var skreddersydd til prosjektet, så den besto kun av det vi håpet å få
ferdig. I tillegg var den under kontinuerlig forandring for å tilpasses prosjektet. Alle funksjonelle
krav vi fikk implementert gjør nøyaktig det vi planla. Vi ble likevel ikke helt ferdig med det
planlagte arbeidet. Enkelte teknologier var ikke så lette å implementere, og grunnet tiden det tok
måtte vi prioritere funksjonalitet som var viktig og helt nødvendig for appen. Dette er en liste
over punkter fra kravspesifikasjonen som ikke ble gjennomført:
Bruker:


Innlogging med Google-konto
Redigering av brukernavn
Band:
● Sende venner bandforslag
● La band laste opp sang
Konserter:
●
●
●
Redigere informasjon om konsertene sine
Laste opp bakgrunnbilde
Se hvem av sine venner som skal på konserten
Notifikasjoner:
● Får varsel når et band man har i sin liste legger ut en ny konsert
○ Man får mulighet til å legge til konserten i sin liste direkte
62
Vi rakk altså ikke å fullføre innlogging med Google-konto, men vanlig registrering i appen
fungerer, og innlogging med Facebook vil fungere for alle6. Vi ble heller ikke ferdige med
streaming av musikk, så per i dag kan ikke band legge ut en låt på profilen sin. Det ligger lenker
til artistens SoundCloud-side på profilen, så muligheten for å sjekke ut musikken til en artist
finnes allikevel.
Noe som har forblitt en placeholder er for eksempel hvem av vennene til en bruker som skal på
en konsert. Det er også andre småting vi blir nødt til å fikse på etter hvert, som at ved invitasjon
til en konsert vises alle brukerens venner, selv de som allerede har konserten i sin liste. Dette
kan føre til at man mottar invitasjon til en konsert man allerede har i lista si.
Det var et punkt i kravspesifikasjonen som vi fullførte, men som ikke ble som forventet:
“Få anbefalinger av band og konserter basert på sine preferanser”.
Her hadde vi planer om å ha to måter å vise forslagene på; enten som en liste, eller én og én
profil med mulighet for å swipe til neste. Vi innså at en vanlig liste ville være kjedelig, men at å
kun vise én om gangen ikke ville gi brukeren noen oversikt. Derfor kom vi fram til rutenettet av
bilder vi nå har på explore-siden. Vi ville fremdeles la brukeren klikke seg inn på en konsert fra
rutenettet og deretter kunne swipe mellom alle forslagene, men dette fikk vi ikke tid til å
gjennomføre.
9.5
Søkekriterier
Bruker får forslag på band basert på to kriterier
●
●
Område
Sjanger
9.5.1 Om geografisk område som søkekriterie
Bruker definerer selv område. I tillegg får brukeren mulighet til å velge hvor langt hen er villig til
å reise for en konsert, basert på radius.
Å kunne definere hvor langt en er villig til å reise er viktig for at applikasjonen skal fungere godt
for alle lokasjoner. Om en bor i en by, vil en gjerne ikke reise mer enn en halvtime for å gå på
konsert. Bor en i områder med færre mennesker kan det godt hende at en er villig til å reise
lenger.
9.5.2 Om sjanger som søkekriterie
Hvordan sjanger skal defineres har vært et tema vi har fått mange forslag på. Både under
brukertesting, fra veiledere og på presentasjoner. Noe problematikk er hvordan man skal
definere sjanger, mengden sjangre som finnes, og at begrepet i seg er i oppløsning.
Vi har valgt å bruke brede sjangerbegreper. Sjanger er ikke bare en beskrivelse av musikk, men
også en identitetsmarkør, og vi mener derfor at det er en god begynnelse. Andre aktører i
markedet, som SoundCloud, har også valgt denne tilnærmingen.
6
Forklaring under teknisk beskrivelse av login i del «9.2.2 Fronteend: Androidapplikasjon»
63
9.5.3 Videreutvikling av søkekriterier
På lengre sikt ønsker vi å gi artister mer makt over beskrivelse av musikken sin. En artist vil
fortsatt måtte velge en eller flere overordnede sjangre, men vi vil i tillegg gi mulighet for å legge
til egendefinerte sjangre. Om en artist mener at musikken hens er indie-danse-pønk, så er den
indie-danse-pønk. På denne måten kan vi gi musikere større definisjonsmakt over egen musikk.
For at bruker skal få bedre forslag ønsker vi også å lage et referansesystem der band legger til
band de mener de ligner på. Bruker vil deretter få flere og bedre anbefalinger basert på band
hen har i lista si.
9.6
Sammenlignet med konkurrerende løsninger
Bandsintown: Bandsintown er en app som gir bruker mulighet til å følge forskjellige band.
Basert på de bandene bruker følger vil hen få forslag til andre band hen kanskje liker. Hen vil
også kunne få informasjon om konserter i sin by. Bandsintown har ingen oversikt over de små
scenene og de ukjente bandene.
Timbre: Timbre er en iOS-app som finner konserter i brukers geografiske område. Timbre har
fokus på store konserter, og har ikke oversikt over de minste scenene. Timbre handler kun om
konserter, så band har ingen egen rolle i appen. Appen er heller ikke tilgjengelig i alle byer, kun
de det er lagt opp til. Timber gir ikke bruker mulighet til å lage egendefinerte lister over de
konsertene hen skal gå på, og dette kan føre til mye unødvendig informasjon og at det blir
uoversiktlig.
Jukely: Jukely foreslår konserter i nærheten av bruker, i et visst antall byer som er lagt inn.
Jukely er veldig fokusert rundt betalingsmåte; bruker må blant annet kjøpe billetter for å invitere
venner på konserter. Jukely har heller ikke fokus på små band og konserter, og bruker kan ikke
opprette sitt eget band eller legge ut konserter.
Et trekk som går igjen i disse appene er at informasjon om konserter og band hentes fra
eksterne steder. Dette medfører at appene ikke vil fungere overalt, og at ukjente band ikke får
delt informasjonen sin. Vi distanserer oss godt fra disse appene ved å gi band en egen rolle i
appen, og dermed sette lokal musikk i fokus fremfor de store og kjente artistene.
Vi gir også brukeren kontroll ved at de kan definere sin radius, og dermed selv velge
betydningen av lokal musikk. Semitone er mer enn kun en informasjonsapp; den vil kunne
skape et forhold mellom de lokale bandene og publikum.
64
10.
Brukertesting
10.1 Om undersøkelsene: Kvalitativ forskningsmetode
Brukertestingen bestod av dybdeundersøkelser på et mindre antall personer. Vi prøvde å åpne
for lengre svar, og alltid la testpersonene si alt de tenkte om appen uavhengig av hva vi testet.
Alle temaene vi testet og spørsmålene vi stilte kan leses i vedlegg 4. Brukertester.
10.2 Forhold rundt testingen
Vi snakket i størst grad med folk vi kjenner, men spurte også nye bekjente når vi fikk sjansen. Vi
prøvde å variere både i alder, grad av musikkinteresse, sosiale miljøer og IT-kyndighet. Siden vi
testet såpass mange ganger, passet vi på å alltid inkludere nye personer i hver test, men også
teste noen som allerede var kjent med idéen.
Alle undersøkelsene ble lagt opp slik at vi hadde spesielle temaer, og eventuelt et par åpne
spørsmål. Vi prøvde i størst mulig grad å tilpasse undersøkelsen til personen slik at vi skulle få
mest mulig nyttig informasjon ut av dem, for eksempel ved å stille videre spørsmål basert på det
som ble sagt. Selv om vi noen ganger hadde planlagte spørsmål, var dette ofte bare forslag; det
viktigste var alltid å få meninger om temaet vi undersøkte.
10.3 Hva undersøkte vi?
●
●
●
●
●
●
●
●
●
Generelt om appidéen - Hvilke deler er uviktige for bruker og hva bør fokuseres på?
○ Utført flere ganger i løpet av prosessen etter hvert som oppgaven ble mer
konkret og ting ble kuttet bort
■ Basert på forklaring av idé
■ Basert på elevator pitch
○ Førsteinntrykk og om de ville ha brukt appen
Kommunikasjon mellom brukere - Er disse funksjonene ønsket eller i veien?
○ Å legge til venner
○ Meldingsfunksjonen
○ Sende konsertinvitasjoner og bandforslag
Betalingsfunksjon – Ønsker brukerne å kjøpe billetter gjennom appen?
Liste eller swipe-funksjon for anbefalingene - Hvordan skal vi presentere data?
Innlogging - Hvordan foretrekker flest å logge inn og hvorfor?
○ Vanlig bruker
○ Facebook-konto
○ Google-konto
Mengden personlig informasjon - Vil brukere dele mer om seg selv?
Mengden informasjon om band - Holder det med informasjonen vi har bestemt?
○ Fa musikeres synspunkt
○ Fra publikums synspunkt
Notifikasjoner i appen - Hva vil brukere ha varsel på?
Design og brukergrensesnitt - Hvordan burde appen se ut?
65
10.4 Resultater
10.4.1 For mye funksjonalitet
Vi fikk mye kommentarer på at appen hadde for mange funksjoner, og at det gjorde det
vanskelig å skjønne hva appen egentlig gjorde; hva som var hovedfokus. Likevel var folk
generelt svært positive til idéen, men de hadde kommentarer som fikk oss til å innse at vi måtte
gjøre noen endringer.
“Det høres ut som en kul app. Min første frykt er om jeg må være veldig aktiv for at den skal
fungere for meg”
-del av et undergrunnsmiljø i Oslo, 20-30 år, sånn passe interessert i musikk
10.4.2 Kommunikasjon mellom brukere
Testgruppen var ikke interessert i meldingsfunksjonen. Den ble beskrevet som “malplassert” og
“unødvendig”. Vi fikk få positive tilbakemeldinger.
“Det er som om man skulle avtale med venner hvilket tog en skal ta inne i NSB-appen”
-del av et undergrunnsmiljø i Oslo, 20-30 år, opptatt av det sosiale aspektet ved konserter
Vennefunksjonene fikk blandede tilbakemeldinger. Noen var interessert i dette, andre var
likegyldige. Det var også positivitet rundt at man kun kunne legge til venner om man kjente til
brukernavnet. Dette gjør at man slipper forespørsler fra fremmede.
10.4.3 Billettkjøp
Funksjonen for kjøp av billetter var testpersonene generelt negative til, og syns det var
unødvendig å implementere.
“Jeg trodde denne appen var for små artister som sannsynligvis ikke har billetter på
billettservice”
-hyppig konsertgåer, 20-30 år
10.4.4 Liste vs. swipefunksjon
Under testen for liste eller swipe-funksjon for anbefalinger, fikk vi ikke et godt svar. Mange var
usikre, og de fleste sa ja til at de ville ha begge deler. Vi fikk inntrykk av at de ikke var helt
fornøyde med løsningen, som noen også sa fra om.
10.4.5 Innlogging
Rundt innloggingsspørsmålet viste det seg å være veldig delte meninger. Det var omtrent like
mange som foretrakk hver av løsningene, men ingen hadde noe i mot at alle mulighetene var til
stede.
10.4.6 Mengden informasjon
Mange likte den minimale mengden personlig informasjon. Enkelte skulle gjerne kunne dele mer
om seg selv, men flertallet var for å ha lite informasjon. De så ikke nødvendigheten i å ha mer i
en app som denne, hvor man uansett kjenner personene man legger til fra før av.
66
Basert på undersøkelsen om mengden bandinformasjon som skulle deles, viste det seg at folk
også her foretrakk lite informasjon, heller enn mye. Selv artistene skjønte hvorfor det var såpass
lite, og var ok med det ettersom de kunne linke til andre nettsider.
Notifikasjoner var en funksjon svært mange stilte seg likegyldig til.
“Det ville selvfølgelig vært praktisk, men det er ikke så viktig for meg”
-glad i å gå på konserter, 30-40 år, bor i storby
Samtidig er notifikasjoner et nyttig grep for å fremme aktiv bruk av appen.
10.4.7 Brukergrensesnitt
Vi viste fram en del design av brukergrensesnitt underveis. Vi gjorde dette spesielt på mindre
detaljer, men også for hele appen for å se om den var forståelig og lett å bruke. De siste
versjonene av appen virket greie å forstå for de fleste. Noe vi testet ganske nøye var
bakgrunnsbilde på innloggingssiden. Vi hadde valgt ut en rekke alternativer individuelt, som vi
presenterte for brukerne og ba dem velge sin favoritt. Det viste seg at det var svært viktig for
brukerne at bildet tydelig representerte både musikk og konserter.
10.5 Innvirkninger av testresultat på produktet
Mange av testene fikk resultater som stemte med avgjørelser vi allerede hadde tatt. Det var
allikevel viktig å gjennomføre alle disse testene, ettersom de styrket vår tro på valgene vi tok.
Noen av testene førte også til endringer, eller hjalp oss med å bestemme oss når vi var usikre.
De store funksjonalitetskuttene i begynnelsen av prosjektet var delvis inspirert av resultatet fra
de første brukertestene. Da vi spisset målgruppen vår ble det ganske tydelig hva som kunne
fjernes, men flere av disse kuttene føltes tryggere å gjennomføre når vi visste at det var
usikkerhet blant brukere om disse funksjonene.
Det var uenighet innad i gruppa om hvor mye vennefunksjonalitet som skulle være en del av
appen. Ved hjelp av undersøkelsen om dette fant vi helt konkret ut hva som var ønskelig blant
brukerne. Derfor kuttet vi åpenbart meldingsfunksjonen. NSB-sammenligningen ble spikeren i
kista for den.
Liste/swipe-debatten for Explore-sidene endte for oss i å lage et nytt design. Dette var i stor
grad på grunn av brukertesten og utilfredsheten vi oppfattet fra testpersonene. Vi viste det nye
rutenettdesignet til flere av de samme menneskene, og de var mer positive til dette.
Innloggingen løste seg selv. Ingen hadde noe i mot at alle mulighetene fantes, og alle
mulighetene ville bli benyttet. Vi beholdt alle tre i kravspesifikasjonen.
67
Avslutning
11.
Konklusjon
Bak applikasjonen Semitone ligger det en mye større idé. Utgangspunktet for applikasjonen var
et ønske om å endre hvem som får definere hva musikk er, hvem som får mulighet til å utøve
musikk, hvem som får mulighet til å delta i mindre miljø, og hvem som får mulighet til å bli hørt.
Dette er ikke noe som gjøres over natta, og vi lærte vel også etter hvert at det ikke er gjort i en
app laget i løpet av 5 måneder. Men et sted må en begynne, og det har vi tro på at Semitone
kan være en del av.
En mobilapplikasjon kan kanskje ha nok funksjoner som løser mange av problemene på en
gang, men hvor bra ville den applikasjonen egentlig blitt? Vi har valgt å gå bort fra en slik
løsning, og heller fokusere på å lage en app som løser ett av problemene på en god måte.
Når en problemstilling er for stor for én løsning, er det bedre å begynne i et hjørne. Når en liten
del er løst bra, blir det lettere å fikse på resten. Semitone er enkel og gjør akkurat det den skal
gjøre. Ikke mer, ikke mindre.
11.1 Egenevaluering
11.1.1 Gjennomføring
Vi undervurderte mengden tid og arbeid utvikling fra idé til konsept ville ta. Vi burde brukt mer
tid på dette i begynnelsen av prosjektet. Endringene som skyldtes mangel på planlegging
underveis, medførte en del ekstraarbeid. Samtidig førte det til at vi fikk prøvd ut ulike måter å
implementere idéene teknisk og ulike måter å utføre planlegging og endringer, og vi har tatt
med oss verdifulle erfaringer fra dette.
Som beskrevet i prosessdokumentasjonen har vi flere ganger sprukket tidsplanene våre. Vi var
nok litt for optimistiske med tanke på mengden arbeid som det var mulig å utføre i hver sprint,
og kunne vært bedre på å se tegnene på dette og justert sprint backlogs deretter.
11.1.2 Samarbeid/gruppeprosessen
Samarbeidet i gruppa har vært preget av miljø hvor det var helt åpent for å si sine meninger,
eller spørre hverandre om hjelp. Alle uenigheter som oppsto ble løst uten å skape ondt blod,
selv om diskusjonene til tider var intense.
Vi har i løpet av halvåret hatt perioder med dårlig kommunikasjon, men har tatt tak i det og
jobbet mot tettere samarbeid igjen. Alle medlemmene føler eierskap til idéen og produktet – noe
som var svært viktig for oss – og slik har alle opprettholdt engasjementet gjennom hele
prosessen.
68
Det har vært viktig for oss å ta hensyn til hverandre. Et godt eksempel er kjernetiden. Vi er en
gruppe med forskjellige måter å jobbe på, og forskjellige døgnrytmer, noe som krever justering
for at alle skal ha det bra.
Vi synes vi har hatt et godt samarbeid med veilederne våre. Vi har møttes med alle våre
veiledere én gang i uka, og de har alltid vært tilgjengelige for oss. De har kommet med
spørsmål og tatt opp temaer som vi ikke hadde tenkt på, og Semitone hadde nok ikke blitt så
bra som det er uten dem.
11.1.3 Læringsutbytte
Nye teknologier
Vi måtte sette oss inn i en del nye teknologier for å gjennomføre prosjektet. Både overfladisk
kunnskap for å sette ulike teknologier opp mot hverandre for å ta riktige valg, og dypere
forståelse for å ta det i bruk på best mulig måte.
Både .NET og Java for Android var kjent for oss, men samtidig har vi lært å ta i bruk mer av det
rammeverkene har å tilby, og også utvide disse med tilleggsrammeverk.
Scrum
Vi var ikke veldig kjent med Scrum, så læringskurven har vært stupbratt. Scrum som
utviklingsmetodikk er mye brukt, og det vil definitivt komme godt med å ha erfaring med dette.
Planlegging
Når du tror du er ferdig med planlegginga; planlegg et par timer til.
Gruppearbeid i større prosjekter
Vi lærte en god del om gruppearbeid i større prosjekter, og spesielt i prosjekter der man selv
skal lage oppgaven og bestemme rammene. Dette var noe vi ikke hadde erfaring med fra
tidligere, og læringsprosessen var bratt. Nødvendigheten av kommunikasjon og kontinuerlig
samarbeid ble tydelig for oss, dog dessverre litt senere enn vi hadde foretrukket. Vi føler at vi
samarbeidet veldig godt helt på tampen av prosjektet, og merket at det var mer flyt når vi fikk til
dette.
Elevator pitches og presentasjoner
Gjennom arbeid med elevator pitches lærte vi hvordan vi skulle identifisere og presentere det
viktigste med en idé eller et produkt. Dette var en viktig lærdom med tanke på presentasjoner
og videre arbeid med appen, hvor vi sannsynligvis vil bli nødt til å presentere Semitone mange
ganger. Dette har også gjort at vi har blitt flinke til å forklare kort og spennende om
bachelorprosjektet vårt til venner og bekjente.
Vi lærte også en del om presentasjoner og presentasjonsteknikk. Dette er lærdom vi vil ta med
oss resten av livet. Vi fant ut hvordan man legger opp en presentasjon for å få best flyt og for å
69
fange interessen til publikum. Gjennom tilbakemeldinger fikk vi også vite hva hver og en av oss
burde tenke på mens vi holder presentasjoner.
11.2 Videre arbeid
Nå som vi er ferdige med bachelorprosjektet, har vi fremdeles mulighet til å videreutvikle appen
og dette har vi planer om. Vi eier selv både konsept og kildekode. Vi har underveis kommet opp
med nye idéer som vi kunne tenke oss å ha implementert i en ferdig utgave av appen. Enkelte
idéer hadde vi helt fra starten, men grunnet tidsrammene valgte vi å ikke ta dette med i
kravspesifikasjonen.
Den “ferdige” applikasjonen vil kunne inneholde følgende funksjonalitet i tillegg til det som står i
kravspesifikasjonen:
●
●
●
●
●
●
●
●
Man kan opprette koblinger mellom band som har lignende musikk, noe vi har kalt
“referanser”
Med utgangspunkt i band og konserter i brukerens lister, og basert på referansene, vil vi
kunne forbedre anbefalingene og gjøre det mer tilpasset hver enkelt person. Altså vil vi
lage en algoritme som lærer
En bruker skal kunne swipe mellom band- og konsertprofiler
○ For anbefalte band og konserter
○ I konsertliste
○ I bandliste
La bruker hindre uønskede anbefalinger fra å dukke opp flere ganger
En cross-platform-løsning
Lage en nettside der band kan registrere seg, konsertlokaler kan legge til konserter osv.
Dette for å forenkle bandadministrasjonen og åpne for mer detaljert redigering av
utseende på bandprofiler og konsertplakatene deres
Band skal kunne legge til brukere som bandmedlemmer, som da også vil få
adminrettigheter på bandet
Et mer gjennomtenkt, sammenhengende og finpusset brukergrensesnitt, som både ser
penere ut og er så intuitivt som mulig å benytte
70
Om vi hadde hatt en tidsmaskin og dratt tilbake for å vise våre august-oss applikasjonen vi
endte opp med å lage, hadde vi nok ikke kjent den igjen. Det hadde nok også blitt noen sinte
innvendinger når august-oss oppdaget at musiker-finner-musiker-funksjonen var borte, og
muligens en og annen beskyldning om ødeleggelse av en fantastisk fin idé.
Men som våre august-selv etterhvert har fått lære: å kutte en funksjon gjør deg ikke til en sellout. Det kan derimot sørge for at produktet du utvikler blir bedre. Mai-oss er stolte av det vi har
laget, men vi har også lært at å bli for knyttet til en enkelt funksjon eller en spesifikk del av
konseptet er ufruktbart. Vi regner med at det kommer til å komme nye korsveier der kjepphester
må kastes; om ikke smertefritt, så i hvert fall med viten om at det lønner seg i lengden.
Én kjepphest kommer vi likevel til å beholde. Idéen som ligger i bunnen; musikk skal ikke være
avhengig av store plateselskaper og A-spillelister. Det skal ikke være utilgjengelig fordi du ikke
kjenner de rette personene eller de riktige stedene, eller fordi du ikke orker å lese igjennom 35
poster fra et band på Facebook for å finne ut når konserten deres er. Det skal rett og slett være
no fuss, just music.
Oslo, 26. mai 2015
______________________
__________________
______________________
Madeleine V. K. Rønning
Emilie Strand
Rannveig A. Skjerve
71
12.
Referanser
Artikkel
Nettside
Forfatter
Tilgjengelig på
Sist
besøkt
Om Høgskolen i
Oslo og Akershus
HiOA
-
http://www.hioa.no/Om-HiOA
05.05.15
Fakultet for
teknologi, kunst og
design (TKD)
HiOA
-
http://www.hioa.no/OmHiOA/Fakultet-for-teknologikunst-og-design-TKD
05.05.15
App Spotlight:
Bandsintown
Spotify
Katz, Candice
https://news.spotify.com/us/20
13/02/05/bandsintown/
02.05.15
What happened to
the Spotify app?
Songkick
-
http://help.songkick.com/custo
mer/portal/articles/1671555what-happened-to-the-spotifyapp-
02.05.15
Proof of Concept
(POC)
Technopedia
Janssen, Cory
http://www.techopedia.com/defi
nition/4066/proof-of-conceptpoc
02.05.15
Accenture
-
http://www.accenture.com/noen/company/Pages/index.aspx
04.05.15
6 steg til hvordan
du legger opp en
effektiv “elevator
pitch”
Left Brain
Marketing
Stegane, Are
http://leftbrainmarketing.NET/bl
ogg/2012/04/6-steg-tilhvordan-du-legger-opp-eneffektiv-elevator-pitch/
05.05.15
Scrum (software
development)
Wikipedia
-
http://en.wikipedia.org/wiki/Scr
um_%28software_developmen
t%29
14.05.15
Android software
development
Wikipedia
-
http://en.wikipedia.org/wiki/And
roid_software_development
05.05.15
About Accenture
72
Tidligere
prosjekter
HiOA
-
http://www.cs.hioa.no/data/bac
helorprosjekt/TidligereProsjekt
er.php
14.05.15
Introducing
RoboSpice:
Introducing
RoboSpice: A
Robust
Asynchronous
Networking Library
for Android
YouTube
YouTube user
Chariot
Solutions
https://www.youtube.com/watc
h?v=ONaD1mB8r-A
04.05.15
JSON Tutorial
w3schools.com
-
http://www.w3schools.com/JS
ON/
05.05.15
XML Tutorial
w3c.org
-
http://www.w3schools.com/xml/
02.05.15
Getting Started Git Basics
git
-
http://gitscm.com/book/en/v2/GettingStarted-Git-Basics
29.04.15
Spring for Android
spring
-
http://projects.spring.io/springandroid/
03.05.15
Native Android
Development with
Spring
YouTube
YouTube user
Spring
Developer
h?v=kvPpu-pTTMY
03.05.15
Learn REST: A
Tutorial
rest.elkstein.org
Dr. Elkstein, M.
http://rest.elkstein.org/2008/02/
what-is-rest.html
01.05.15
ASP.NET
Wikipedia
-
http://en.wikipedia.org/wiki/AS
P.NET
05.05.15
-
Agilefant
-
http://agilefant.com/
14.05.15
(Video)
(Video)
73
API - application
program interface
Webopeida
Beal, Vangie
http://www.webopedia.com/TE
RM/A/API.html
14.05.15
Visual Studio
Visual Studio
-
https://www.visualstudio.com/
14.05.15
Entity Framework
Data Developer
Center
-
https://msdn.microsoft.com/enus/data/ef.aspx
14.05.15
Intro to Entity
Framework 5.0
YouTube
YouTube User
Fabio Scopel
h?v=EPXFc6pAnMs
14.05.15
How to use Blob
storage from .NET
Microsoft Azure
Tamram
http://azure.microsoft.com/nbno/documentation/articles/stora
ge-dotnet-how-to-use-blobs/
14.05.15
Android Shared
Preferences
Tutorial
Tutorialspoint
-
http://www.tutorialspoint.com/a
ndroid/android_shared_prefere
nces.htm
14.05.15
Understanding
Routing in
ASP.NET MVC
Dotnetcurry
Sumit Maitra
http://www.dotnetcurry.com/sh
owarticle.aspx?ID=814
19.05.15
Apache Harmony
Wikipedia
-
http://en.wikipedia.org/wiki/Apa
che_Harmony
19.05.15
Pinstripe Limo
dafont.com
Designer:
Lauren
Thompson
(Nymphont)
http://www.dafont.com/pinstrip
e-limo.font
22.05.15
Terms of Use/End
User License
Nymphont
Lauren
Thompson
(Nymphont)
http://www.nymfont.com/2009/
07/terms-of-useend-userlicense-agreement.html
22.05.15
Bildet fra forsiden,
brukt med tillatelse
Miriam Namork
Photography
Foto: Miriam
Namork
http://miriamnamork.tumblr.co
m/
Kontakt:
[email protected]
22.05.15
(Video)
(Font benyttet på
forsiden)
74
Vedlegg
1. Ordliste
2. Styringsdokumenter
2.1. Fremdriftsplan
2.2. Risikoanalyse
2.3. Product backlogs
2.3.1. Ved begynnelsen av prosjektet
2.3.2. Ved slutten av prosjektet
3. Elevator Pitch
4. Brukertester
5. Prosjektskisse
6. Brukerveiledning
7. HTTP API References
8. Klasseoversikt – applikasjon
9. Klasseoversikt – server
75
1.
Ordliste
Apache Harmony: Apache Harmony var en åpenkildekode-implementasjon av Java, utviklet av
Apache Software Foundation. Prosjektet ble avsluttet 16. november 2011.
API (Application Program Interface): API er et sett rutiner, funksjoner, protokoller og verktøy
for å bygge programvare. APIet spesifiserer hvordan programvarekomponentene burde
kommunisere, og APIer brukes under programmering av grafiske
brukergrensesnittkomponenter.
Backend: Den «usynlige» delen. Består typisk av servere og applikasjoner som prosesserer
forespørsler fra frontend, og databaser.
BroadcastReceiver: En BroadcastReceiver i Android er en komponent som gjør det mulig for
en applikasjon å lytte etter bestemte hendelser i systemet.
Caching: Caching er en komponent som lagrer data slikt at identiske forespørsler i fremtiden
kan leveres fortere. I databaseøyemed betyr dette at identiske fremtidige forespørsler kan
gjøres uten å måtte spørre databasen. Ettersom databaseforespørsler er trege vil dette føre til
at responstiden fra for eksempel en server blir raskere. Vi har brukt caching på serveren for å
øke ytelsen og responstiden.
Cross-platform: At en applikasjon kan kjøre på flere forskjellig plattformer; i vårt tilfelle gjelder
dette først og fremst om appen skal kunne kjøres på både iOS og Android.
Frontend: Den delen av et system som er synlig for bruker
Hashing (av passord): For å beskytte et passord vil det ofte bli enveis-hashet. Selv om en
person klarer å få tilgang til databasen vil de ikke ha tilgang til passordene i vanlig tekst. De blir
nødt til å prøve alle mulige passordkombinasjoner for å finne ut det originale passordet. Et
passord vil ofte bli hashet sammen med et salt for å gjøre det enda vanskeligere å bryte
passordene.
Integrated Development Environment (IDE): Integrated Development Environment, eller
integrert utviklingsmiljø på norsk, er et program som brukes til utvikling og koding av andre
programmer.
Minimal Viable Product (MVP): Et MVP inneholder kun den nøkkelfunksjonaliteten som gjør at
produktet kan brukes, og ikke mer. Det brukes typisk for testing mot kunder eller potensielle
kunder. For oss betyr dette at vi ville lage et teknisk proof of concept som viser idéen vår, men
som inneholder så lite funksjonalitet som mulig grunnet mangel på tid.
Model, View, Controller (MVC): Et designmønster for programutvikling. Programmet deles opp
i dataenheter, visuell del og logikk som utføres på disse.
Object Relational Mapper: En programmeringsteknikk som brukes for å konvertere
inkompatible typer, f.eks. JSON-data eller relasjonell data fra database, til objekter som kan
brukes av programmeringsspråk.
76
Open source: Kildekode som er gjort tilgjengelig.
Routing: I denne konteksten er routing-prosessen å mappe en URL til en handler på
serversiden.
Salt (passord): Et salt lagres ofte i forbindelse med et passord. Salting gjør slik at selv om to
passord er like så vil hashing av disse passordene være forskjellige ettersom saltet er random
generert.
Services i Android: En service i Android er en applikasjonskomponent som kan utføre
langvarige bakgrunnsoperasjoner uten tilknytning til brukergrensesnitt. En annen komponent
kan starte en service, men servicen kjører videre selv om komponenten som startet den
avsluttes.
Toast: En midlertidig melding i appen som dukker opp nederst på skjermen, ofte for å informere
om det som skjer i applikasjonen som bruker ikke kan se (f.eks. «Konserten ble lagret»).
Tråder/Trådprogrammering: En tråd er utførelsen av den minste sekvensen av programmerte
instruksjoner som kan håndteres uavhengig av andre instruksjoner i et program. En tråd kan
ses på som en lettvektprosess; oppgavene i programmet fordeles, men en tråd krever mindre
ressurser enn det en prosess gjør. Trådprogrammering refererer til bruken av tråder i
programmering og brukes for å øke ytelsen til applikasjoner.
Tråder kan bli brukt på en server til å behandle hver forespørsel med en ny tråd, i stedet for
med en ny prosess. For hver forespørsel som kommer inn er det en egen tråd som utfører
denne spesifikke forespørselen. Hvis forespørselen er en databaseforespørsel som databasen
må utføre, men som den ikke må vente på, så kan tråden bare kjøre videre mens
databaseforespørselen foregår samtidig.
Use case: En use case er en beskrivelse av et system i form av «historier» om hva systemet
skal kunne gjøre. Eksempel: En bruker henter kakao fra maskinen.
77
2.
Styringsdokumenter
Styringsdokumentene i forprosjektrapporten ble utarbeidet i midten av januar, og baserte seg på
kunnskap vi hadde om lignende dokumenter fra tidligere. Etter ønske fra Accenture valgte vi å
bruke rammemodellen Scrum for utviklingen, og gikk derfor raskt over til å bruke product
backlog til planlegging av arbeid. Vi brukte allikevel fremdriftsplanen fra forprosjektrapporten
som veiledning til oppsett av 1. sprint og som en generell oversikt over hvilken rekkefølge
funksjoner burde implementeres.
2.1
Fremdriftsplan
Figur 2.1 A - Fremdriftsplan fra forprosjektet (januar 2015)
Å planlegge ut i fra product backlog fungerte mye bedre for oss enn om vi skulle forholdt oss til
en statisk milepælsplan. I milepælsplanen er det mange fastsatte funksjoner som vi kuttet på
grunn av tilbakemelding fra potensielle brukere, så denne planen ble fort unøyaktig. Det viste
seg også etterhvert at planen var i overkant ambisiøs i forhold til hva som faktisk var mulig å få
gjennomført.
78
2.2
Risikoanalyse
Risikoanalyse fra 01.februar 2015
Risiko
Sannsynlighet
Risikograd
Forebygging
Utfall
Sykdom
Høy
Middels
Enighet; ved
sykdom slappe av,
ta igjen resten når
en er blitt frisk
Influensa
Mangelfull
scoping
Høy
Høy
Se over use
cases, legge en
klar plan
For mye diskusjoner,
uenigheter og
forvirring underveis
ettersom alle
oppgaver ikke var
satt ordentlig nok
For stor
arbeidsmengde
Høy
Høy
Dynamisk
utvikling; kutte
unødvendige
funksjoner så fort
de blir identifiserte
En mindre app, men
arbeidsmengden
førte likevel til at vi
måtte utsette
kodestopp
Intern uenighet
Middels
Middels/høy
Åpen
kommunikasjon, ta
tak i konflikter når
de oppdages
Godt håndterte
konfliktsituasjoner,
Dropbox, google
docs, lokale kopier
og git
Ingen data evig tapt
(midlertidig borte pga
git-problemer)
Tap av data
Middels
Høy
Tekniske
problemer
Middels
Lav
men det har krev tid
Git failures
I etterpåklokskapens lys må det innrømmes at vi undervurderte hvor mye av oppgaven vår som
skulle komme til å omhandle selve utviklingen av konseptet. Vi har stort sett jobbet på prosjekter
med klart definerte oppgaver og tekniske spesifikasjoner, altså prosjekter der det er mulig å
79
bruke mer tid på å programmere hver for seg og mindre tid på å diskutere. Det er en klar
svakhet i planleggingen vår, og har gitt utslag i en del beslutninger tatt av enkelte i stedet for
gruppa som helhet.
Etterpåklokskapens risikoanalyse
Mangelfull
kommunikasjon om
status på
programmering fra
hver enkelt
Høy
Høy
Stand-ups på alle
møtedager
Fungerte godt i
begynnelsen, men
ble dårligere på
slutten. Dette førte til
at vi ikke klarte å
samkjøre den siste
innsatsen og var en
av hovedgrunnene til
at vi ble nødt til å
utsette kodestopp en
uke
’’Diskusjonstrøtthet’’
Høy
Høy
Brukertesting
Brukertesting ble
innført etter første
‘‘diskusjonsrunde’’
og var til god hjelp
for å minimere
mengden
diskusjoner. Men det
var fremdeles en
faktor som var med
oss resten av
semesteret, og var
nok en av
hovedgrunnene til
den manglende
kommunikasjonen
som har oppstått til
tider.
80
2.3
Product backlogs
Vi hadde allerede gjort de fleste funksjonalitetskuttene da vi begynte å bruke Scrum, så vår
første product backlog er ikke så veldig annerledes fra vår siste. Vi gjorde allikevel noen
endringer på underveis så vi har lagt ved både vår første og siste versjon.
2.3.1 Ved begynnelsen av prosjektet
 Brukerkonto
o Som bruker kan jeg logge meg inn med en brukerkonto laget i appen
o Som bruker kan jeg logge meg inn med min Facebook-konto
o Som bruker kan jeg logge meg inn med min Google-konto
o Som bruker kan jeg sette og redigere følgende informasjon om meg selv:
 Brukernavn
 Profilbilde
 Passord
 Hvilke notifikasjoner jeg skal få fra appen
 Hvilke sjangre jeg liker
 Hva som er mitt lokale område
o Som bruker kan jeg søke på en sjanger og få opp konserter eller band under
valgte sjanger
o Som bruker kan jeg swipe mellom anbefalingene jeg får til konserter og band
 Vennefunksjonalitet
o Som bruker kan jeg sende venneforespørsler
 Gitt at jeg kjenner til brukernavnet til mottaker
o Som bruker kan jeg motta, og godta eller avslå, venneforespørsler
o Som bruker kan jeg se mine venner i en venneliste
o Som bruker kan jeg fjerne mine venner fra min venneliste
o Som bruker kan jeg sende mine venner meldinger
 Bandfunksjonalitet
o Som bruker får jeg anbefalinger av band basert på mitt satte område og
foretrukne sjangre
o Som bruker kan jeg legge til et band i min bandliste
o Som bruker kan jeg fjerne et band fra min bandliste
o Som bruker kan jeg se min bandliste
o Som bruker kan jeg søke i min bandliste
o Som bruker kan jeg sende forslag om band til mine venner
o Som musiker kan jeg opprette en bandprofil
o Som musiker med bandprofil kan jeg sette og redigere følgende informasjon om
bandet mitt:
 Bandnavn
 Hvilke sjangre bandet identifiserer seg som
 En sang som streames i appen
 Medlemmer av bandet
 Linker til SoundCloud, Facebook og hjemmeside
 Referanser til andre band i appen
81

 Kjøp av CD/utgivelser
 Hva som er bandets lokale område
o Som musiker med bandprofil kan jeg informere mine følgere om:
 Nye konserter
 Nye musikalske utgivelser
o Som bruker kan jeg se et band sin profil
o Som bruker skal jeg få notifikasjon når et band i min bandliste legger ut en ny
konsert
o Som bruker kan jeg kjøpe CD’er fra bandet om muligheten er tilstede
Konsertfunksjonalitet
o Som bruker får jeg anbefalinger av konserter basert på mitt satte område og
foretrukne sjangre
o Som bruker kan jeg legge til en konsert til min konsertliste
o Som bruker kan jeg fjerne en konsert fra min konsertliste
o Som bruker kan jeg se min konsertliste
o Som bruker kan jeg søke i min konsertliste
o Som bruker kan jeg sende mine venner invitasjon til en konsert
o Som musiker med bandprofil kan jeg opprette nye konserter
o Som musiker som kan opprette en konsert kan jeg sette og redigere følgende
informasjon om konserten:
 Tittel på konserten
 Bandnavn
 Dato og klokkeslett
 Navn på konsertlokalet
 Adresse til konsertlokalet
 Billettkjøp
o Som bruker kan jeg se en «konsertplakat»
o Som bruker kan jeg se hvor mange av mine venner som skal på en gitt konsert
o Som bruker kan jeg se hvem av mine venner som skal på en gitt konsert
o Som bruker kan jeg kjøpe billetter til en konsert hvis muligheten er tilstede
o Som bruker kan jeg søke på en dato og få opp konserter på denne datoen
82
2.3.2 Ved slutten av prosjektet
 Brukerkonto
o Som bruker kan jeg logge meg inn med en brukerkonto laget i appen
o Som bruker kan jeg logge meg inn med min Facebook-konto
o Som bruker kan jeg logge meg inn med min Google-konto
o Som bruker kan jeg sette og redigere følgende informasjon om meg selv:
 Brukernavn
 Profilbilde
 Foretrukne sjangre
 Geografisk lokasjon
 Radius rundt gitte lokasjon
o Som bruker kan jeg velge å swipe mellom eller se liste over anbefalingene jeg får
til konserter og band
 Vennefunksjonalitet
o Som bruker kan jeg sende venneforespørsler
 Gitt at jeg kjenner til brukernavnet til mottaker
o Som bruker kan jeg motta, og godta eller avslå, venneforespørsler
o Som bruker kan jeg se mine venner i en venneliste
o Som bruker kan jeg fjerne mine venner fra min venneliste
 Bandfunksjonalitet
o Som bruker får jeg anbefalinger av band basert på mitt satte område og
foretrukne sjangre
o Som bruker kan jeg legge til et band i min bandliste
o Som bruker kan jeg fjerne et band fra min bandliste
o Som bruker kan jeg se min bandliste
o Som bruker kan jeg sende forslag om band til mine venner
o Som bruker kan jeg godta eller avslå bandforslag fra mine venner
o Som musiker kan jeg opprette en bandprofil
o Som musiker kan jeg se en liste over alle mine opprettede band
o Som musiker med bandprofil kan jeg sette og redigere følgende informasjon om
bandet mitt:
 Bandnavn
 Bilde
 Hvilke sjangre bandet identifiserer seg som
 En sang som streames i appen
 Medlemmer av bandet
 Linker til SoundCloud, Facebook og hjemmeside
 Hva som er bandets lokale område
o Som musiker med bandprofil kan jeg informere mine følgere om:
 Nye konserter
o Som bruker kan jeg se et band sin profil
o Som bruker skal jeg få notifikasjon når et band i min bandliste legger ut en ny
konsert
 Konsertfunksjonalitet
83
o
o
o
o
o
o
o
o
o
o
o
o
Som bruker får jeg anbefalinger av konserter basert på mitt satte område og
foretrukne sjangre
Som bruker kan jeg legge til en konsert til min konsertliste
Som bruker kan jeg fjerne en konsert fra min konsertliste
Som bruker kan jeg se min konsertliste
Som bruker kan jeg sende mine venner invitasjon til en konsert
Som bruker kan jeg godta eller avslå konsertinvitasjoner fra venner
Som musiker med bandprofil kan jeg opprette nye konserter
Som musiker som kan opprette en konsert kan jeg sette og redigere følgende
informasjon om konserten:
 Tittel på konserten
 Bandnavn
 Dato og klokkeslett
 Navn på konsertlokalet
 Adresse til konsertlokalet
 Bilde
Som bruker kan jeg se en «konsertplakat»
Som bruker kan jeg se hvor mange av mine venner som skal på en gitt konsert
Som bruker kan jeg se hvem av mine venner som skal på en gitt konsert
Som bruker kan jeg søke på en dato og få opp konserter på denne datoen
84
3.
3.1
Elevator pitch
To musicians
If you feel like your music won’t get heard because of the bigger bands and artists, this is for
you. We want to make a no fuss music app where you can let people know of your concerts and
new music without it drowning in spam from other bands' shameless self-promotion.
This app doesn’t care how many followers you have, or what people follow you; this is all about
music. Let people in your area know you exist, what you sound like and when your next concert
is. That’s it; you’ll have a real chance of being heard.
3.2
To the music enthusiasts
I have a hard time keeping track of local musicians. Especially in Oslo, this seems like an
impossible task. Wouldn’t it be great to have an easy way of doing this, connect with your
friends and find concerts to attend together?
We are making an app which will give you suggestions for underground bands and concerts in
your area. Find a concert for Friday night, or check out where your friends are going and join
them! No spammy invites to events totally uninteresting to you, or unnecessary promotion from
bands. In short: no fuss, just music.
3.3
To investors
There are many music apps out there, music streaming apps, music discovery apps, concert
tracking apps, and they all have the same flaw; they don’t focus on the local music scene. Our
app’s head cornerstone is the love for local music and underground scenes, and our aim is to
make those scenes available for more people. Users will get suggestions for bands and
concerts happenings in their area based on their taste in music. Bands can add their profiles
and make themselves known, without having to fight of the jammer and fuss from the big names
in the industry.
85
4.
Brukertester
Tabell over temaene vi undersøkte underveis, og spørsmålene vi stilte
86
5.
Prosjektskisse
Oslo,
4. desember 2014
Prosjektskisse for hovedprosjekt, dataingeniørfag og informasjonsteknologi ved HiOA
våren 2015
Gruppemedlemmer:
Rannveig A. Skjerve, Emilie Strand, Madeleine Rønning
Oppdragsgiver:
Accenture Norge
Rolfsbuktveien 2, 1364 Fornebu
P.O. Box 363
N-1326 Lysaker
Foreløpig tittel: Sosial media app for musikere, musikkengasjerte og arrangører
Beskrivelse
Accenture er et av verdens ledende konsulentselskaper. De leverer tjenester innenfor
rådgivning, teknologi og outsourcing. Vår oppgave vil bli gjennomført som et proof of conceptoppdrag i regi av Accenture Norge.
Appen skal kunne samle musikere, musikkengasjerte og arrangører. Brukere skal kunne fylle ut
profiler, og basert på profilen skal appen finne, og foreslå, andre musikere, konserter, band eller
konsertarenaer som matcher med brukerens preferanser.
Use cases
1. En bruker har lyst til å finne en konsert å gå på i en gitt uke, eller dato. Brukeren kan bla
igjennom konserter innenfor sine sjangere og sitt område. Brukeren velger konsert og
blir eventuelt sendt videre til billettbooking.
2. Et band trenger en trommeslager. Gjennom applikasjonen kan de finne trommeslagere
innenfor samme sjanger og område som leter etter band.
87
3. En musiker trenger andre å spille med. Gjennom appen kan musikeren finne andre
innenfor samme sjanger som spiller de instrumentene musikeren leter etter.
4. Bruker skal ha fest og ønsker å hyre et liveband. Ved å gå inn i appen og lete blant de
etablerte bandene innen for en gitt sjanger, kan de finne et som passer til eventet og ta
kontakt.
5. En konsertarena har en ledig kveld for et band/en musiker. Som i use caset over, kan de
finne et band som passer til stedet og booke dem.
6. Bruker har funnet seg et band og de ønsker seg spillejobber. De kan lage en profil for
bandet og slik gjøre seg tilgjengelig for alle som ønsker å booke.
88
6.
Brukerveiledning
6.1
Login/register
Når brukeren åpner appen kommer de til innloggingssiden (figur 6.1 A).
(Figur 6.1 A – «login»)
(Figur 6.1 B – «Register»)
Hvis de allerede har en brukerprofil, kan de logge inn med den. Om det er første gang brukeren
åpner appen, må det opprettes en brukerprofil. Dette gjør de ved å trykke på «or register»7. Her
må brukeren fylle inn valgfritt brukernavn, sin emailadresse og et passord (figur 5.1 B). Når
brukeren trykker på «register»-knappen blir de logget inn i appen.
7
Som nevnt under teknisk beskrivelse funker ikke Facebook-innlogging for andre enn utviklerne før
appen har blitt publisert.
89
6.2
Meny
Hovedmenyen i appen er en navigation drawer. Denne ligger til venstre i appen og dukker opp
når brukeren drar fingeren, eller swiper, helt fra venstre på skjermen og mot høyre. Denne
menyen er tilgjengelig overalt bortsett fra på konsertplakat, bandprofiler og ved redigering av
band.
(Figur 6.2 A – «Menu»)
Denne menylista vil nå gjennomgås og forklares.
90
6.3
Explore bands
Dette er den første siden bruker ser etter innlogging. Her dukker det opp anbefalinger av band
basert på brukerens valgte område og foretrukne sjangre (figur 6.3 A). Ved å swipe nedover på
listen, vil den oppdateres. Om det er første gang bruker logger inn, må preferansene settes
under «settings» før anbefalingene blir skreddersydd til brukeren.
(Figur 6.3 A – «Explore bands»)
(Figur 6.3 B – “Band profile”)
Bruker kan trykke på et band for å se deres bandprofil (figur 6.3 B). Her ser man bandets navn,
sjangre og posisjon, og det er linker til deres Facebookside, SoundCloudprofil og et annet
nettsted bandet har valgt. Disse linkene vil åpnes ekstern når de trykkes på, og hvis brukeren
har SoundCloud- eller Facebook-appen på sin mobil vil linkene åpnes i disse.
Hvis brukeren er interessert i bandet, vil knappen «add to your list» øverst til høyre legge til
bandet i brukerens bandliste (figur 6.5 B). Når knappen blir trykket på, endres den til å si
«remove from list» og hjertet endrer farge (figur 6.3 C). Ved å trykke på denne fjernes bandet
fra brukerens liste. Det kommer en melding som bekrefter at bandet er lagt til eller fjernet.
(Figur 6.3 C – “Remove from list”)
91
6.4
Explore concerts
Denne siden er tilsvarende «explore bands» for konserter. Her dukker det opp anbefalinger av
konserter basert på brukerens valgte område og foretrukne sjangre (figur 6.4 A). Ved å swipe
nedover vil listen oppdateres. Om brukeren ikke har satt preferansene sine, må dette gjøres
under «settings» før anbefalingene blir skreddersydd til brukeren.
(Figur 6.4 A – «Explore concerts»)
(Figur 6.4 B – “Concert poster”)
Bruker kan trykke på en konsert for å se konsertplakaten med all informasjon (figur 6.4 B). På
konsertplakaten vises tittelen på konserten, bandet som holder konserten, dato, klokkeslett og
sted. Brukeren vil også se hvor mange venner som skal på konserten.
Brukeren kan trykke på knappen «add to concert list» for å legge konserten inn i konsertlisten
sin. Da vil knappen endres (figur 6.4 C). Konserten fjernes fra listen ved at å trykke på knappen
igjen. Brukeren får en melding når konserten har blitt lagt inn eller fjernet fra listen.
(Figur 6.4 C – “Remove from list”)
92
Bruker har også mulighet til å invitere sine venner til en konsert. Ved å trykke på konvolutten
nederst til høyre vil brukeren få opp en liste over sine venner.
(Figur 6.4 D – «Invite friends»)
Deretter kan brukeren velge ønsket venn og bekrefte sendelsen, og vennen vil motta
invitasjonen i sin notifikasjonsliste. Applikasjonen sier fra når invitasjonen er sendt.
6.5
Concert list & Band list
Disse listene inneholder konserter og band som brukeren selv har lagt dit. Her kan brukeren
trykke på et band eller en konsert og få opp profilene på samme måte som i Explore-sidene.
(Figur 6.5 A – «Concert list»)
(Figur 6.5 B – «Band list»)
93
Øverst til høyre i listene er det forstørrelsesglass som er søkeikon. Når brukeren trykker på
dette vil det dukke opp et søkefelt hvor brukeren kan søke etter konserter hvis de er inne i
konsertlista, og band inne i bandlista. Etter hvert som brukeren skriver vil søkeresultatene
oppdatere seg og alle konserttitler eller bandnavn som inneholder søkefrasen vil vises (figur 6.5
C). Slik kan dette feltet brukes til å finne en spesiell konsert eller et band, men også til å finne
tilfeldige nye band eller konserter. Brukeren kan trykke på et resultat for å få opp profilen.
(Figur 6.5 C – «Søk inne i bandliste der en bruker har søkt på frasen band»)
94
6.6
Your friends
Dette menyvalget viser listen over brukerens venner (figur 6.6 A). Når brukeren trykker på en
venn vil de få opp profilen (figur 6.6 B). På brukerprofilen får brukeren se de siste konsertene
vennen har lagt til i sin konsertliste. På denne måten kan brukere lett finne ut hvor vennene
skal, og møte dem på konsert.
(Figur 6.6 A – «Vennelisten»)
(Figur 6.6 B – «Venneprofil»)
Øverst til høyre i vennelisten har brukeren mulighet til å søke etter nye venner. For å legge til
noen, må brukeren kjenne til vennens brukernavn. Hvis brukeren skriver inn noe som ikke er et
brukernavn, vil det ikke gå an å legge dem til (figur 6.6 C). Hvis det derimot er et brukernavn, vil
det dukke opp et hjertesymbol ved siden av navnet (figur 6.6 D).
(Figur 6.6 C – «Ingen ved dette navnet»)
(Figur 6.6 D – «Funnet venn»)
95
Brukeren kan legge til denne personen som venn ved å trykke på hjertet. Hjertet vil bli rødt (figur
6.7 E), og en melding vil fortelle at venneforespørselen ble sendt (figur 6.7 F). Hvis personen og
brukeren er venner før brukeren søker, vil hjertet være rødt når det dukker opp i søkeresultatet.
Bruker kan fjerne personen som venn ved å trykke på hjertet igjen.
(Figur 6.7 E – «Venn lagt til»)
6.7
(Figur 6.7 F – «Bekreftelse på at forespørsel ble sendt»)
Your bands
Her kan man opprette band, redigere sine band og opprette konserter (Figur 6.7 A).
(Figur 6.7 A – «Your bands»)
(Figur 6.7 B – «Opprett band»)
For å opprette band kan brukeren trykke på plussknappen øverst til høyre. Dette vil enkelt la
brukeren opprette et band ved å kun skrive inn bandnavnet og trykke på knappen (Figur 6.7 B).
Det nye bandet vil da dukke opp i listen over brukerens band. Ved å trykke på et band får man
opp informasjonen om bandet på den nedre halvdelen av siden (Figur 6.7 C).
96
(Figur 6.7 C – «Ingen info ligger inne enda!»)
(Figur 6.7 D – «Edit band»)
Edit band profile
For å redigere informasjonen om bandet eller legge til informasjon på nye band må brukeren
trykke på «Edit profile». Brukeren blir da tatt til en ny side for redigering (Figur 6.7 D).
Endre bandnavn: Brukeren kan gjøre endringene i tekstboksen øverst, og slik endre
bandnavn.
Endre bakgrunnsbilde: Når brukeren trykker på det øverste symbolet åpnes galleriet på
mobilen til brukeren. Når et bilde er valgt vil det settes som bakgrunn. Det kommer en melding
som bekrefter endringen når den er gjennomført (Figur 6.7 E).
Endre posisjon: Ikon nummer to endrer bandets område. Dette er hvor bandet holder til, og det
vil la brukere i nærheten finne dem i sine anbefalinger. Ved et trykk på knappen dukker det opp
en tekstboks. Når brukeren begynner å skrive inn vil det dukke opp forslag basert på søkefrasen
(Figur 6.7 F). Når det ønskede stedet dukker opp i listen, kan brukeren klikke på dette for å
velge det. Det kommer en melding som bekrefter endringen når den er gjennomført.
97
(Figur 6.7 E – «Bakgrunnsbilde valgt»)
(Figur 6.7 F – «Posisjonsvelger»)
Endre linker: Den tredje knappen lar brukeren redigere bandets linker (figur 6.7 G). Bruker får
mulighet til å sette inn link til bandets Facebookside, deres SoundCloud-profil, og en hvilken
som helst annen nettside. Det kommer en melding som bekrefter endringen når den er
gjennomført.
Endre sjangre: Den siste knappen lar brukeren sette og endre bandets sjangre (figur 6.7 H).
Ved å trykke på sjangrene sine til venstre, vil de fjernes og dukke opp i listen over tilgjengelige
sjangre til høyre. For å legge til flere sjangre må brukeren trykke på en av disse til høyre som
har et pluss. Når brukeren er ferdig med endringene, vil den bekreftende knappen som dukker
opp lagre det. Det kommer en melding som bekrefter endringen når den er gjennomført.
Deretter kan bruker gå tilbake til «Your bands» og se endringene som ble gjort på bandet (figur
6.7 I).
98
(Figur 6.7 G – «Endre bandlinker») (Figur 6.7 H – «Endre sjangre»)
(Figur 6.7 I – «Endringer er lagret»)
Add concert
Når brukeren velger et band under «Your bands» og så trykker
på «Add concert» vil en side for oppretting av konserter dukke
opp. Her vil allerede bandnavnet være fylt ut, samt
bakgrunnsbildet satt lik bandets bilde. Hvis bandet ikke har noe
bandbilde, vil bakgrunnsbildet bli et standard bilde.
Brukeren kan legge inn en tittel på konserten, sette dato og tid,
samt velge stedet med samme posisjonsvelger som på «edit
profile». Så er det bare å trykke på «post concert»-knappen, og
konserten vil bli publisert. Brukeren får informasjon når
lagringen av konserten er gjennomført.
(Figur 6.7 J – «Add concert»)
99
6.8
Settings
Dette er siden der brukeren kan endre informasjon om seg selv.
(Figur 6.8 A – «Settings»)
Endre profilbilde: Ved å trykke på «change profile picture» får brukeren opp sitt galleri på
mobilen, og kan velge et bilde. Det kommer en melding som bekrefter endringen når den er
gjennomført.
(Figur 6.8 B – «Det vises at applikasjonen jobber med å lagre bildet gjennom en «loading circle»)
Endre posisjon: Posisjonen til bruker har standardverdien «Oslo Sentralstasjon». For å gjøre
endring må bruker trykke på den. Da dukker det opp en posisjonsvelger.
(Figur 6.8 D – «valgt posisjon»)
(Figur 6.8 C – «Posisjonsvelger»)
(Figur 6.8 E – «Bekreftende melding»)
Ved å skrive inn stedet brukeren bor eller vil finne band og konserter, vil det for hvert nye tegn
dukke opp nye forslag (Figur 6.8 C). Når det ønskelige alternativet dukker opp, vil brukeren
kunne trykke på det. For å lagre endringene må brukeren trykke på den bekreftende knappen
(Figur 6.8 D). Det kommer en melding som bekrefter endringen når den er gjennomført (Figur
6.8 E).
100
Endre radius: Her setter brukeren størrelsen på sitt lokale område. Det er kun innenfor dette
området at brukeren får anbefalinger av band og konserter. Radiusen er rundt posisjonen
brukeren har satt. Brukeren velger radius ved å dra på sirkelen på stripa. Det kommer en
melding som bekrefter endringen når den er gjennomført.
Endre sjangre: Brukeren kan her velge sine foretrukne sjangre. Brukerens valgte sjangre står i
listen til venstre, og resten av de mulige valgene til høyre. For å legge til flere sjangre trykker
man på sjangrene man vil ha, og på samme måte fjerner man sjangre man ikke vil ha. Når
brukeren er ferdig må endringene lagres ved å trykke på knappen nederst (figur 6.8 F)t. Det
kommer en melding som bekrefter endringen når den er gjennomført.
(Figur 6.8 F – «Sjangervelger»)
6.9
About
Her står det kort om appen.
6.10 Log off
Dette valget logger deg ut av appen.
101
6.11 Notifications
Man kommer til denne siden ved å trykke på bjelleikonet øverst til høyre i appen. Denne
inneholder en liste over venneforespørsler og konsertinvitasjoner brukeren har sendt og mottatt.
Nye, usette notifikasjoner vil ha en mørkere bakgrunn enn resten.
(Figur 6.11 A – «Notifications»)
Når det kommer inn en ny notifikasjon blir brukeren varslet ved at bjelleikonet blir rødt.
(Figur 6.11 B – «Bjellen er rød = nye notifikasjoner»)
Venneforespørsler
Når en bruker sender en venneforespørsel, har mottakeren to valg; godta eller avslå. Hvis
mottakeren avslår vil ikke avsender få noen informasjon om det. Hvis mottakeren derimot godtar
vil avsenderen få en notifikasjon om at brukerne nå har blitt venner (figur 6.11 C).
102
(Figur 6.11 C – «Venneforespørsel godtatt»)
Når en bruker mottar en venneforespørsel ser den slik ut:
(Figur 6.11 D – «Venneforespørsel mottatt»)
Hvis brukeren trykker «decline» vil notifikasjonen bli borte, og ikke noe mer skje. Hvis brukeren
trykker på «accept» vil notifikasjonen endre seg og fortelle at de to brukerne har blitt venner.
Brukerne vil nå havne i hverandres venneliste.
(Figur 6.11 E – «Brukeren har godtatt en venneforespørsel»)
Konsertinvitasjoner
Når en konsertinvitasjon blir sendt, vil mottakeren ha de samme valgene som for
venneforespørsler; godta eller avslå. Hvis brukeren godtar vil begge parter få en notifikasjon
som forteller at invitasjonen ble godtatt, og konserten havner i mottakerens konsertliste.
(Figur 6.11 F – «Konsertinvitasjon mottatt»)
(Figur 6.11 G – «Konsertinvitasjon godtatt»)
103
7.
HTTP API References
Band
GET api/Band/Random/{userid}
GET api/Band/IsAdded/{userid}
Returnerer en tilfeldig generert liste av
band som passer til brukers preferanser
Returnerer hvorvidt et band er i en brukers
liste eller ikke
GET api/Band/Query/{query}
Returnerer en liste av band som matcher
tekststrengen {query}
GET api/Band/GetUsersList/{id}
Returnerer brukers bandliste
GET api/Band/Get/{id}
Returnerer band med id {id}
GET api/Band/GetProfiles/{userId}
Returnerer bandene bruker har opprettet
GET api/Band/GetAllGenres/{id}
Returnerer en liste med alle sjangre og
informasjon om hvilke bandet har i sin liste
Returnerer hvorvidt et band er lagt til i en
brukers liste eller ikke
GET api/Band/IsAdded/{userId},{bandId}
POST api/Band/Add/{name},{userId}
Legg til band
POST api/Band/updateName/{name},{bandId}
Oppdater bandnavn
POST api/Band/UpdateLocation/
Oppdater bandets posisjon
POST api/Band/UpdateWwwLink/
Oppdater link til bandets webside
POST api/Band/UpdateFbLink/
Oppdater bandets Facebook link
POST api/Band/UpdateScLink/
Oppdater bandets Soundcloud link
POST api/Band/ChangePic/{bandid}
Oppdater bandets bilde
POST "api/Band/UpdateGenres"
Oppdater bandets sjangre
POST
api/Band/AddToUserList/{userid},{bandid},{ok}
Legg til, eller ta bort band fra bruksers
liste
104
Concert
GET
api/Concert/GetRandom/{userid}
GET
api/Concert/Get/{id}
GET
api/Concert/Query/{query}
Returnerer en tilfeldig generert liste av
konserter som passer til brukers
preferanser
Returnerer et konsertobjekt med
concertid={id}
Returnerer en liste av band som matcher
tekststrengen {query}
GET
api/Concert/GetUsersList/{userid}
Returnerer brukerens konsertliste
GET
api/Concert/ GetFriendsAttendanceNumber
/{concertId},{userId}
GET
"api/Concert/GetAttendingFriends/{concertId},{
userId}"
Returnerer antall venner av bruker som
har konserten i sin liste
POST
api/Concert/AddToUserList/{concertId},{userId}
,{ok}
POST
api/Concert/SendInvitation/{from},{to},{concerti
d}
Legg til/fjern konserter fra en brukers liste
POST
api/Concert/AcceptInvitation/{id},{ok}
Aksepter invitasjon til konsert fra en av
brukers venner
Returnerer en liste med venner av bruker
som har konserten i sin liste
Send invitasjon til konsert til en av brukers
venner
Genre
GET
api/User/GetAll/{id}
Returnerer alle sjangre fra server
Friends
GET api/Friends/GetList/{userid}
GET api/Friends/Query/{name},{userid}
Returnerer en liste over brukerens venenr
Returnerer et venneobjekt om det finnes
en bruker hvis {name} matcher eksakt
med brukerens brukernavn
POST
api/Friends/SendRequest/{userId},{friendId}
POST api/Friends/Respond/{requestId},{ok}
POST api/Friends/Remove/{userid},{friendId}
Send venneforespørsel
Svar på venneforespørsel
Fjern venn fra brukers venneliste
105
User
GET api/User/Get/{userid}
GET api/User/CheckName/{name}
GET api/User/CheckEmail/{email}
GET api/User/GetAllGenres/{id}
GET api/User/GetNotifications/{id}
POST api/User/ChangePic/{userid}
POST api/User/ChangeRadius/{radius},{userId}
POST
api/User/RegisterFacebook/{uid},{profilename},
{path}
POST api/User/Login/{pass},{email}
POST api/User/Register
POST api/User/UpdateGenres
POST api/User/UpdateLocation
Returnerer en en bruker
Returnerer hvorvidt {name} finnes som et
brukernavn i databasen
Returnerer hvorvidt {email} finnes som en
brukers email i databasen
Returnerer en liste med alle sjangre og
informasjon om hvilke bruker har i sin liste
Returnerer en liste med alle
notifikasjonene til en bruker
Oppdaterer brukers bilde
Oppdaterer brukers radius
Registrerer bruker med Facebookkonto
Logg inn bruker
Registrer ny bruker
Oppdaterer brukers sjangre
Oppdaterer brukers posisjon
106
8.
Klasseoversikt – applikasjon
(Figur 8 A – «Skjermbilde fra Android Studio, mappeoversikt»)
Adapter
Klassene i denne mappen håndterer listene. Hvordan listene vises, hva slags layout som vises,
hva som skjer når man klikker på listene og hvilken informasjon som blir satt inn hvor.
Klasse
MyAdminAdapter.java
MyConcertAdapter.java
MyExploreBandAdapter.java
MyExploreConcertAdapter.java
MyFriendsAdapter.java
MyNotificationsAdapter.java
Forklaring
Adapter som tar for seg håndtering av bandene som
en bruker administrerer
Adapter som tar for seg håndtering av konsertene
som en bruker følger
Adapter som tar for seg håndtering av listen der
tilfeldige band vises
tilfeldige konserter vises
Adapter som tar for seg håndtering av listen av
venner som en bruker har
notifikasjoner til en bruker vises
107
Band
Alle View klasser for Band
BandActivityList.java
Fragment som viser listene med band som en bruker
følger eller søker etter.
BandActivity.java
BandAdminFragment.java
Aktivitet som viser en bandprofil
Fragment med liste over brukers bandprofiler, og
informasjon om disse
Fragment som viser bandinfo. Brukes i BandActivity.
Fragment som viser en oppsummering av
informasjon om bandet. Brukes i
BandAdminFragment.
Aktivitet for redigering av bandprofiler
DialogFragment for redigering av bandlinker. Brukes
i EditBandActivity
BandContainerFragment.java
BandSummaryFragment.java
EditBandActivity.java
EditBandLinksFragment.java
Concert
Alle View klasser for Concert
ConcertActivity.java
ConcertActivityList.java
CreateConcertActivity.java
Aktivitet som viser en konsertprofil; plakaten til en
konsert
Fragment som viser listene med konserter som en
bruker følger eller søker etter
Aktivitet der bruker kan opprette en konsert
Explore
Viewklassene for explore
ExploreBands.java
ExploreConcerts.java
Fragment som viser en liste av tilfeldige band som er
innenfor en bruker sin rekkevidde og lokasjon.
Fragment som viser en liste tilfeldige konserter som
er innenfor en bruker sin rekkevidde og lokasjon.
Friends
Viewklassene for venner
FriendActivity.java
FriendsFragment.java
SearchActivity.java
Aktivitet som viser en venn sine 5 nyeste konserter
og band som de følger.
Fragmentet som viser listen av personer som
brukeren er venn med. Håndterer henting av en
bruker sine venner og caching av dette.
Aktiviteten håndterer at brukeren kan søke etter
personer/venner og legge til eller fjerne disse.
108
Login
Viewklassene for login
LoginActivity.java
RegisterActivity.java
Aktivitet som lar en bruker logge seg inn med
Facebook eller vanlig innlogging.
Aktivitet som lar en bruker registrerer seg med vanlig
mail.
Main
MainActivity.java
NavigationDrawerFragment.java
Dette er hovedaktiviteten som tar for seg
navigeringen mellom de forskjellige fragmentene i
navigasjonsskuffen.
Fragment som viser navigasjonsskuffen/menyen
Models
Alle modellklasser
Undermappe: Args
Mappe med modeller som brukes for mapping av JSON objekt som ikke er en del av
domenemodellen
AddConcert.java
GenreArgs.java
Modell for mapping av verdier som brukes i
oppretting av konserter
Modell for mapping av en sjangerliste med markering
av valgte sjangre
Undermappe: Calculations
Mappe med modeller for kalkulasjoner
Distance.java
Kalkulering av avstand mellom to geografiske
punkter
Undermappe: Comparison
Mappe som tar for seg sammenligning av om objektene er like. Brukes mest i henhold til om
data skal caches eller ikke.
BandsComparison.java
ConcertsComparison.java
FriendsComparison.java
ImagesComparison.java
NotificationsComparison.java
En klasse som sammenligner bandobjekter.
En klasse som sammenligner konsertobjekter
En klasse som sammenligner venneobjekter
En klasse som sammenligner bildeobjekter.
En klasse som sammenligner notifikasjonsobjekter.
109
Undermappe: Save
Mappe som tar for seg håndtering av lagring av data.
SaveData.java
En klasse som tar for seg lagring av lister og lagring
av bilder.
Undermappe: List
Mappe med modeller for lister fra server
AdminList.java
BandList.java
ConcertList.java
FriendsList.java
GenreArgsList.java
NotificationsList.java
ImageList.java
Liste med brukers
Liste med Band
Liste med konserter
Liste med venner
Liste med sjangre, med markering av valgte
Liste med notifikasjoner
Liste med thumbnails til Explore-sidene
Undermappe: Model
Modeller som speiler modellene på serverside, brukes for JSONmapping og som objekter i
applikasjonen
Band.java
Concert.java
ConcertInfo.java
Friends.java
Genre.java
Images.java
BandProfile.java
Notifications.java
User.java
Modell for band
Modell for konserter
Modell med informasjon om hvem som deltar på
konsert
Modell for en venn
Modell for sjanger
Modell med informasjon som brukes på explore
sidene.
Modell for objekter i listen over brukers bandprofiler
Modell for notifikasjoner
Model for bruker
Undermappe:Shape
Denne mappen håndterer egenlagde figurer i bilde.
RoundedImageView.java
Klasse som gjør et bilde rundt.
Notifications
Mappe som håndterer notifikasjoner. Håndterer om brukeren har fått nye notifikasjoner og vising
av disse til brukeren.
MyService.java
NotificationsActivity.java
Service som sjekker om en bruker har nye
notifikasjoner.
Aktivitet som håndterer visning av alle
notifikasjonene til en bruker.
110
NotificationsBroadReceiver.java
SendNotifications.java
BroadcastReceiver som starter
SendNotificationServicen
En service som starter myService vært 20 sekund.
Request
Mappe for alle requests mot server
AddBandToListRequest.java
AddConcertNotificationRequest.java
AddConcertToListRequest.java
AddFriendRequest.java
AddNewBandRequest.java
AddNewConcertRequest.java
BandListRequest.java
BandProfilesRequest.java
BandQueryRequest.java
CheckNotificationsRequest.java
ConcertListRequest.java
ConcertQueryRequest.java
ExploreRequest.java
FaceLoginRequest.java
FindConcertRequest.java
FindFriendRequest.java
FriendListRequest.java
GetAllFriendsGoingConcert.java
GetBandWithIdRequest.java
GetFriendsToConcert.java
GetGenresRequest.java
GetUserRequest.java
IsBandAddedRequest.java
LoginRequest.java
NotificationResponseRequest.java
NotificationListRequest.java
ProfilePicRequest.java
RadiusRequest.java
Request for å legge et band inn i brukers bandliste
Request for å sende en konsertinvitasjon
Request for å legge en konsert inn i brukers
konsertliste
Request for å legge til en bruker som venn
Request for å opprette et nytt band
Request for å legge til en ny konsert
Request for å hente ut brukerens bandliste
Request for å hente ut alle brukerens opprettede
band
Request for å hente ut bandene som matcher med
en brukers søkefrase
Request for å sjekke om brukeren har nye
notifikasjoner
Request for å hente ut brukerens konsertliste
Request for å hente ut konsertene som matcher med
en brukers søkefrase
Request for å hente ut bilder til Explore-sidene
Request for å få logget inn med Facebook
Request for å hente ut informasjon om en konsert
basert på konsertID
Request for å finne en bruker basert på søk under
venneliste
Request for å hente ut brukerens venneliste
Request for å hente hvor mange av brukerens
venner som skal på en gitt konsert
Request for å hente ut informasjon om et band
basert på bandID
Request for å hente alle brukerens venner som skal
på en gitt konsert
Request for å hente ut alle sjangre på et band eller
en bruker
Request for å hente ut all informasjon om en bruker
basert på brukerID
Request for å sjekke om et band er lagt til i en
brukers bandliste
Request for å få logget inn
Request for å svare på en notifikasjon
Request for å hente ut en brukers notifikasjoner
Request for å sette profilbilde for en bruker
Request for å sette radius for en bruker
111
RegisterRequest.java
UpdateBandImageRequest.java
UpdateBandLinksRequest.java
UpdateBandNameRequest.java
UpdateGenreRequest.java
UpdateLocationRequest.java
Request for å registrere en bruker i appen
Request for å oppdatere bilde på et band
Request for å oppdatere linkene på et bands profil
Request for å oppdatere navnet til et band
Request for å oppdatere sjangrene til et band eller
en bruker
Request for å oppdatere posisjonen til et band eller
en bruker
Settings
Viewklasse for brukerinnstillinger
SettingsFragment.java
Klassen som håndterer brukerinnstillingene til en
bruker.
Utils
View og interface for valg av sjangre og posisjon
ChooseGenreFragment.java
GenreChooser.java
LocationFragment.java
LocationChoooser.java
Fragment med mulighet til å velge sjangre
Interface for valg av sjanger
Fragment med mulighet for å velge sjanger
Interface for valg av posisjon
Res
Mappe for alle ressurser
anim
drawable,
drawable-hdpi,
drawable-mdpi,
drawable-xhdpi,
drawable-xxhdpi
layout
menu
values
values-w820dp
AndroidManifest.xml
I denne mappen ligger slide-animasjonene
I disse mappene ligger alle bilder, ikoner og knapper
i ulike oppløsninger
I denne mappen ligger alle layout-filene for
aktiviteter, fragmenter, lister, dialoger og actionbar
I denne mappen finnes layouts for menyvalg i
actionbar
I denne mappen ligger alle String-verdier,
dimensjoner, farger og styles
I denne mappen ligger dimensjoner for horisontal
layout
Manifestet til prosjektet
112
9.
Klasseoversikt – server
Controller
Kontrolleren mappen håndterer alle kontrollerne. Det er metodene i disse klassene som
kontaktes av applikasjonen.
BandController
ConcertController
FriendsController
GenreController
UserController
Controller som håndterer bandforespørsler
Controller som håndterer konsertforespørsler
Controller som håndterer det som omhandler
venner.
Controller som håndterer det som omhandler
sjangere.
Controller som håndterer det som omhandler user.
Managers
Managermappen håndterer sending av forespørsler mellom kontrollere og db klassene i tillegg
til håndtering av caching og bildeopplastning i manager.
BaseManager
BandManager
ConcertManager
FriendManager
GenreManager
ManagerFactory
UserManager
En basemanager som håndterer opplastning av
bilder og caching
En manager som håndterer bandforespørsler.
En manager som håndterer konsertforespørsler.
En manager som håndterer venneforespørsler.
En manager som håndterer sjanger forespørsler.
Returnerer managere som kontrolleren bruker til å
sende forespørselen videre.
En manager som håndterer bruker forespørsler.
Models
Args
Models
Klasse som brukes til mapping av objekter som kun
brukes i datautveksling mellom applikasjon og
server
Class
Mappen som har alle klassene som skal sendes tilbake til applikasjonen. Når et objekt hentes
fra databasen så
BandClass
ConcertClass
ConcertInfoClass
FriendsClass
Klasse som brukes til mapping av bandobjekter
Klasse som brukes til mapping av konsertobjekter
Klasse som brukes til mapping av hvor mange
venner som skal gå og om en spesifikk bruker skal
gå.
Klasse som brukes til mapping av venneobjekter
113
GenreClass
ImageClass
MemberClass
NotificationsClass
Klasse som brukes til mapping av sjangerobjekter
Klasse som bruker til mapping av objektene i
explore listen.
Klasse som brukes til mapping av hvilke band en
person er medlem i
Klasse som brukes til mapping av notifikasjoner.
Db
Mappen som håndterer alle Db forespørslene i tillegg til domenemodellene for databasen.
DbBand
DbConcert
DbFriends
DbGenre
DbUser
IdentityModels
Utfører db forespørsler for band
Utfører db forespørsler for konserter
Utfører db forespørsler for venner
Utfører db forespørsler for sjanger
Utfører db forespørsler for bruker
Klassen som inneholder modellene som gjør opp
databasen.
114

Sluttrapport - Høgskolen i Oslo

Transcription

Similar documents

Fra binært til desimalt. La a = 1011011100101102. Hvert siffer

HITACHI LR – 135 / 35A & LR – 155 / 55A

Oblig 5

DAVID OFTEDAL - 01101001.net

Eksempler på nasjonale API

minside - Norgesgruppen

HITACHI LR – 135 / 35A & LR – 155 / 55A

Program Skisprinten 11. mars - FIS WorldCup Sprint Drammen