Hovedprosjekt ved institutt for Informasjonsteknologi. Høgskolen i Oslo og Akershus våren Emilie Strand, Informasjonsteknologi

Transkript

1 Hovedprosjekt ved institutt for Informasjonsteknologi Høgskolen i Oslo og Akershus våren 2015 Madeleine V. K. Rønning, Informasjonsteknologi Emilie Strand, Informasjonsteknologi Rannveig A. Skjerve, Dataingeniør

2 PROSJEKT NR Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Offentlig BACHELORPROSJEKT Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL Semitone DATO ANTALL SIDER / BILAG 114 PROSJEKTDELTAKERE Rannveig A. Skjerve Madeleine Victoria Kongshavn Rønning Emilie Strand INTERN VEILEDER G. Anthony Giannoumis OPPDRAGSGIVER Accenture Norge AS KONTAKTPERSONER 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

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

4 Innhold Innledning og bakgrunn 1. Presentasjon Innledning Involverte aktører Studentgruppen Intern veileder fra HiOA Veiledere fra Accenture Presentasjon av de involverte aktørene Studentgruppa HiOA Accenture Oppgaven Hva slags oppgave er det? Mål for oppgaven Bakgrunn Behovet Eksisterende løsninger Avgrensning...11 Faglig bakgrunn Proof of concept Scrum Sprinter Roller i Scrum Valget av Scrum Scrum vs fossefallsmetoden Elevator pitch...13 Teknologier EXtensible Markup Language(XML) JavaScriptObjectNotation (JSON) REpresentional State Transfer (REST) Java for Android Dalvik VM

5 3.4.2 Valg av programmeringsspråk ASP.NET Web API Utviklingsmiljøer Android Studio Visual Studio Eksterne biblioteker og APIer Spring for Android Robospice Google Places API Git Azure-server Entity Framework Microsoft Azure Blob Shared preferences Valg av ulike teknologier Java for Android Valg av Azure Webserver...17 Prosessdokumentasjon 4. Innledning av samarbeid Samarbeid i gruppa Samarbeid med oppdragsgiver Samarbeid med veiledere Intern veileder ved Høgskolen Veiledere ved Accenture Utvikling av kravspesifikasjonen Første utkast No fuss, just music Spesifisering av målgruppe Funksjonalitetskutt Diskusjoner etter funksjonalitetskutt Use case etter funksjonalitetskuttene Brukertestingens innvirkning på oppgaven

6 6. Første sprint (03. feb feb) Oppstart med Scrum Estimering Problemer med Scrum Realiseringer etter 1. sprint Retrospektiv Hva fungerte dårlig, og hvorfor? Hva fungerte? Presentasjoner Styringsgruppen i Accenture Veilederen på høyskolen og andre interessenter Andre sprint (24. feb apr) Planlegging Diskusjoner underveis Avslutting av 2. sprint Første utsettelse av sluttdato på 2. sprint Andre utsettelse av sluttdato på 2. sprint Nødvendig med videre funksjonalitetskutt Retrospektiv Hva fungerte dårlig, og hvorfor? Hva fungerte? Tredje sprint (08. apr mai) Planlegging Valget om ikke å estimere tid Underveis Tekniske grunner til at vi ikke ble ferdige Andre grunner til at vi ikke ble ferdige Etter sprint Retrospektiv Hva fungerte dårlig, og hvorfor? Hva fungerte?

7 Produktdokumentasjon 9. Resultater Kravspesifikasjon Overordnet systembeskrivelse Funksjonelle egenskaper og brukergrensesnitt Teknisk beskrivelse av produktet Systemets hovedkomponenter Fronteend: Androidapplikasjon Backend Proof of concept Oppfyllelse av krav til funksjonalitet Søkekriterier Om geografisk område som søkekriterie Om sjanger som søkekriterie Videreutvikling av søkekriterier Sammenlignet med konkurrerende løsninger...64 Brukertesting Om undersøkelsene: Kvalitativ forskningsmetode Forhold rundt testingen Hva undersøkte vi? Resultater For mye funksjonalitet Kommunikasjon mellom brukere Billettkjøp Liste vs. swipefunksjon Innlogging Mengden informasjon Brukergrensesnitt Innvirkninger av testresultat på produktet...67 Konklusjon Egenevaluering Gjennomføring Samarbeid/gruppeprosessen

8 Læringsutbytte Videre arbeid...70 Referanser...72 Vedlegg 1. Ordliste Styringsdokumenter Elevator pitch Brukertester Prosjektskisse Brukerveiledning HTTP API References Klasseoversikt applikasjon Klasseoversikt server

9 Innledning og bakgrunn 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, s Dataingeniør s126247@stud.hioa.no Madeleine Victoria Kongshavn Rønning, s Informasjonsteknologi madekoro@hotmail.com Emilie Strand, s Informasjonsteknologi stremilie@gmail.com Intern veileder fra HiOA G. Anthony Giannoumis george.giannoumis@gmail.com Veiledere fra Accenture Jonas Korssjøen jonas.korssjoen@accenture.com Henrik Bjerke henrik.bjerke@accenture.com 9

10 1.3 Presentasjon av de involverte aktørene 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 HiOA Høgskolen i Oslo og Akershus (HiOA) er landets største statlige høgskole, med ca 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 Accenture Accenture er et globalt konsulentselskap som leverer tjenester innenfor rådgivning, teknologi og outsourcing, og har ca 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 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 Mål for oppgaven Å utvikle en applikasjon som 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 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

11 mindre man kan de «riktige» ordene. Subkulturer har dermed ingen plattform for enkelt å nå et interessert publikum utenfor sin egen omgangskrets 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

12 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 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 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 Roller i Scrum 12

13 Utviklingsteam: Et utviklingsteam er et tverrfaglig team som står for selve produksjonen i hver sprint 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 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

14 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

15 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 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) 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 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 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 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 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

16 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 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 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 Azure-server Microsoft Azure er en cloud computing platform, og er integrert med Visual Studio 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 A «Entity Framework Mapping») 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 A «Blob») 16

17 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 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 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 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 A Entity framework ) 17

18 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

19 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 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 , 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 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 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

20 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

21 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 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

22 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? Use case etter funksjonalitetskuttene 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

23 6. Første sprint (03. feb 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

24 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 ) 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

25 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 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 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 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

26 7. Andre sprint (24. feb 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: 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

27 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 ) 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

28 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 ) 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

29 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 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

30 7.5 Retrospektiv (Figur 7.5 A - Retrospektiv for 2. sprint ) Hva fungerte dårlig, og hvorfor? 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 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

31 8. Tredje sprint (08. apr 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

32 (Figur 8.2 A - Screenshot fra Agilefant den ) 32

33 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 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/ @ .com» 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 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

34 (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

35 8.5 Retrospektiv (Figur 8.5. A «Retrospektiv for 3. sprint») Hva fungerte dårlig, og hvorfor? 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

36 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

37 Produktdokumentasjon 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 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 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

38 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

39 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

40 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» 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 A Systemets hovedkomponenter ) 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

41 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

42 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

43 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

44 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

45 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

46 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

47 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

48 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

49 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

50 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 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

51 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 A. (Figur 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

52 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 B. (Figur 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

53 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

54 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 C. (Figur 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

55 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 Entity Framework Code First 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 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 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

56 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 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 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 C. Hvordan oppdateringer på data som er i cachen håndteres kan ses i figur D. 56

57 (Figur 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 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. Entity Framework Code First For oppbygningen av selve databasen brukes Entity Framework Code First. Et eksempel på hvordan en modell er oppbygd kan ses i figur E. 57

58 (Figur 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 F viser det ferdige databaseoppsettet. Alle tabellene som vises er konstruert ved hjelp av Code First-tilnærmingen og har derfor egne domenemodeller. 58

59 (Figur 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 G. (Figur 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

60 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 H. Blob (Figur 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 I. 60

61 (Figur 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 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 K - {action}-parametritt sjekkes i Controllerklassen, i [Route]-attributtet) 61

62 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

63 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 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 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

64 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

65 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 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 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

66 10.4 Resultater 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, år, sånn passe interessert i musikk 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, å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 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, år 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 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 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

67 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, år, bor i storby Samtidig er notifikasjoner et nyttig grep for å fremme aktiv bruk av appen 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 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

68 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 Egenevaluering 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 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

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

70 fange interessen til publikum. Gjennom tilbakemeldinger fikk vi også vite hva hver og en av oss burde tenke på mens vi holder presentasjoner 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

71 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

72 12. Referanser Artikkel Nettside Forfatter Tilgjengelig på Sist besøkt Om Høgskolen i Oslo og Akershus HiOA Fakultet for teknologi, kunst og design (TKD) HiOA App Spotlight: Bandsintown Spotify Katz, Candice 13/02/05/bandsintown/ What happened to the Spotify app? Songkick - mer/portal/articles/ what-happened-to-the-spotifyapp Proof of Concept (POC) Technopedia Janssen, Cory nition/4066/proof-of-conceptpoc Accenture steg til hvordan du legger opp en effektiv elevator pitch Left Brain Marketing Stegane, Are ogg/2012/04/6-steg-tilhvordan-du-legger-opp-eneffektiv-elevator-pitch/ Scrum (software development) Wikipedia - um_%28software_developmen t% Android software development Wikipedia - roid_software_development About Accenture 72

73 Tidligere prosjekter HiOA - helorprosjekt/tidligereprosjekt er.php Introducing RoboSpice: Introducing RoboSpice: A Robust Asynchronous Networking Library for Android YouTube YouTube user Chariot Solutions h?v=onad1mb8r-a JSON Tutorial w3schools.com - ON/ XML Tutorial w3c.org Getting Started Git Basics git Spring for Android spring Native Android Development with Spring YouTube YouTube user Spring Developer h?v=kvppu-pttmy Learn REST: A Tutorial rest.elkstein.org Dr. Elkstein, M. what-is-rest.html ASP.NET Wikipedia - P.NET Agilefant (Video) (Video) 73

74 API - application program interface Webopeida Beal, Vangie RM/A/API.html Visual Studio Visual Studio Entity Framework Data Developer Center Intro to Entity Framework 5.0 YouTube YouTube User Fabio Scopel h?v=epxfc6panms How to use Blob storage from.net Microsoft Azure Tamram ge-dotnet-how-to-use-blobs/ Android Shared Preferences Tutorial Tutorialspoint - ndroid/android_shared_prefere nces.htm Understanding Routing in ASP.NET MVC Dotnetcurry Sumit Maitra owarticle.aspx?id= Apache Harmony Wikipedia - che_harmony Pinstripe Limo dafont.com Designer: Lauren Thompson (Nymphont) e-limo.font Terms of Use/End User License Nymphont Lauren Thompson (Nymphont) 07/terms-of-useend-userlicense-agreement.html Bildet fra forsiden, brukt med tillatelse Miriam Namork Photography Foto: Miriam Namork m/ Kontakt: miriam.semb@gmail.com (Video) (Font benyttet på forsiden) 74

75 Vedlegg 1. Ordliste 2. Styringsdokumenter 2.1. Fremdriftsplan 2.2. Risikoanalyse 2.3. Product backlogs Ved begynnelsen av prosjektet Ved slutten av prosjektet 3. Elevator Pitch 4. Brukertester 5. Prosjektskisse 6. Brukerveiledning 7. HTTP API References 8. Klasseoversikt applikasjon 9. Klasseoversikt server 75

76 1. Ordliste Apache Harmony: Apache Harmony var en åpenkildekode-implementasjon av Java, utviklet av Apache Software Foundation. Prosjektet ble avsluttet 16. november 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

77 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

78 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

79 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

80 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

81 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 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

82 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

83 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

84 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

85 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

86 4. Brukertester Tabell over temaene vi undersøkte underveis, og spørsmålene vi stilte 86

87 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

88 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

89 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 adresse 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

90 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

91 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

92 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

93 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

94 Ø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

95 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

96 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

97 (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

98 (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

99 (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

100 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

101 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 Log off Dette valget logger deg ut av appen. 101

102 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

103 (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

104 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

105 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

106 User GET api/user/get/{userid} GET api/user/checkname/{name} GET api/user/check /{ } 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},{ } 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 { } finnes som en brukers 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

107 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 Adapter som tar for seg håndtering av listen der tilfeldige konserter vises Adapter som tar for seg håndtering av listen av venner som en bruker har Adapter som tar for seg håndtering av listen der notifikasjoner til en bruker vises 107