HOVEDPROSJEKT 2014-28. Studieprogram: Informasjonsteknologi. Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo

1

PROSJEKT NR. Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo 2014-28 TILGJENGELIGHET Åpen HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Webgrensesnitt og Android applikasjon for Oslo Fight Center DATO 27.5.2014 ANTALL SIDER / BILAG Telefon: 22 45 32 00 Telefaks: 22 45 32 05 PROSJEKTDELTAKERE Olav Ro s169537 Robin Berg Jønsson s181102 Vizllim Rustemi s181121 Mariusz Krzysztof Zych s181122 INTERN VEILEDER Omar al-khayat OPPDRAGSGIVER OFC Oslo Fight Center KONTAKTPERSON Ole Boe SAMMENDRAG Webgrensesnitt og Android applikasjon for Oslo Fight Center, er en mobil applikasjon og et webgrensesnitt som kommuniserer med hverandre. Brukeren av applikasjonen finner generell informasjon som blir lagt ut fra webgrensesnittet. 3 STIKKORD Mobil applikasjon og webgrensesnitt Android, PHP & Query Oslo Fight Center 2

Forord Dette er en hovedoppgave i bachelor for ingeniør, teknologi og data linjen høgskolen i Oslo og Akershus våren 2014. Denne oppgaven er laget for Oslo Fight Center (OFC). Dette er et sammensatt dokument av prosessdokumentasjon, produktdokumentasjon, testdokumentasjon og brukermanual. Prosessdokumentasjon utdyper prosessutviklingen av prosjektet, mens produktdokumentasjonen beskriver selve produktet. Testdokumentasjonen består av ulike tester vi har kjørt på produktet, og brukermanualen tar for seg brukerveiledning for produktet. Hovedprosjektet er beregnet for arbeidsgiver og sensor, men vil også være tilgjengelig for dem som ønsker å videreutvikle produktet ved forespørsel til gruppen som har utviklet dette. Dokumentformatet er PDF og er tilgjengelig for de fleste plattformer. Vedlagt følger stikkordsliste og kildeliste Takk til Vi ønsker å takke Oslo Fight Center og Ole Boe for å ha gitt oss denne oppgaven. Takk til Omar al-khayat for veildening og hjelpen under hele arbeidsprosessen. Takk til Amir Maqbool Ahmed for hjelp til oppsett av server. Takk til Tor Krattebøl for å ha hjulpet oss med bytting av oppgave. 3

Innholdsfortegnelse HOVEDPROSJEKT...2 Forord...3 Takk til...3 Presentasjon...8 Android applikasjon og webgrensesnitt for Oslo Fight Center...8 Prosessdokumentasjon...11 1. Innledning...12 1.1 Bakgrunn for valget av plattform: Android og webgrensesnittet... 12 1.2 Om gruppen... 13 Navn... 13 Studie... 13 Studentnummer... 13 Vizllim Rustemi... 13 Robin Berg Jønsson... 13 Olav Ro... 13 Mariusz Krzysztof Zych... 13 1.3 Om Oslo Fight Center... 14 1.3.1 Oslo Fight Center (OFC)... 14 1.3.2 Krav Maga... 14 1.3.3 K1... 14 1.3.4 Submission wrestling... 14 1.3.5 MMA... 14 1.3.6 Om OFC og registrering... 15 1.3.7 Dagen situasjon... 15 1.3.4 Begrensninger... 18 2. Planleggingsfasen...19 2.1 Begynnelsen av prosjektet... 19 2.2 Planleggingsprosessen... 19 2.3 Arbeidsfordeling... 20 2.4 Møtereferat... 20 2.5 Gant-diagram... 21 2.6 Milepæler... 22 2.8 Verktøy... 23 2.8.1 Litt om verktøyene... 23 2.9 Ny kunnskap... 26 3. Utviklingsprosessen...27 3.1 Arbeidsmetode... 27 3.2 Faser... 27 3.2.1 Research... 27 3.2.2 Gjennomføring... 27 4

3.2.3 Avslutningsfasen... 28 3.3 Utviklingsprosessen: Utfordringer... 28 3.3.2 PHP og jquery... 28 3.3.3 Sikkerhet... 29 3.4 Oppbygging og funksjon... 30 3.4.1 Bruk av versjonskontroll(tls)... 30 3.4.2 Design... 30 3.4.3 Utelate funksjoner... 32 3.5 Oppdragsgiver under prosessen... 32 3.6 Tilbakemeldingen av oppdragsgiveren... 33 3.7 Kravspesifikasjon... 34 3.7.1 Endelig kravspesifikasjon... 34 3.7.2 Endringer... 35 3.7.3 Samsvar mellom kravspesifikasjoner og produkt... 36 3.8 Om resultatet... 37 3.8.1 Oppsummering... 37 3.8.2 Konklusjon... 37 3.9 Avslutning... 38 3.9.1 Videreutvikling... 38 Produktdokumentasjon...40 4.1 Innledning... 41 4.1.1 Applikasjonens hensikt... 41 4.1.2 Beskrivelse av applikasjonen... 41 4.1.2 Beskrivelse av webgrensesnittet... 41 4.1.3 Mål og rammebetingelser... 41 4.2 Teknologi... 42 4.2.1 Java / Eclipse / JDK/ADK... 42 4.2.2 Emulator... 43 4.2.3 PHP / HTML / CSS /MySQL/... 43 4.2.4 JSON/Android... 44 4.3 Beskrivelse av webgrensesnittet... 45 4.3.1 Innlogging... 45 4.3.2 Hjem... 46 4.3.3 Kalender... 47 4.3.4 Kurs... 48 4.3.5 Utstyr... 49 4.3.6 Medlem... 50 4.3.7 Instruktør... 51 4.4 Beskrivelse av applikasjon... 52 4.4.1 Logg inn... 52 4.4.2 Hjem... 53 4.4.3 Min trening... 54 4.4.4 Instruktør... 55 4.4.5 Trening og hendelser... 56 5

4.4.6 Kurs... 57 4.4.7 Utstyr... 58 4.4.8 Om oss... 59 4.4.9 Logg ut... 60 4.5 Diagrammer & Klasser (webgrensesnitt)... 61 4.5.1 Use Case... 61 4.5.2 Klassediagram... 63 4.5.3 Tilstandsdiagram(webgrensesnitt)... 65 4.5.4 Aktivitetsdiagram... 65 4.5.4 Sekvensdiagram... 67 4.5.6 Database... 68 4.6 Klasser & diagrammer (Applikasjonen)... 69 4.6.1 Use Case... 69 4.6.2 Klassediagram... 70 4.6.3 Aktivitetsdiagram... 72 4.6.4 Sekvensdiagram... 73 4.6.5 Database... 73 4.7 Views modeller av webgrensesnittet... 74 4.7.1 Ansatt... 74 4.7.2 Instruktør... 75 4.7.3 Instruktør (tabell du ville hatt i virkeligheten)... 76 4.7.5 Reservasjon... 78 4.8 Oppbygging og virkemåte... 79 4.9 Driftsmiljø... 81 4.9.1 Utviklingsmiljø... 81 4.9.2 Server... 81 5. Installasjon og kjøring på maskiner...82 5.1 Oppsett av databasen og tabell i MySQL... 82 5.2 Feilsøking... 84 5.3 Oppsett og installering av Android ADT... 85 6. Grafisk brukergrensesnitt...87 6.1 De syv designprinsippene... 87 7. Gjenstående arbeid...88 Testdokumentasjon...89 8. Testdokumentasjon for webgrensesnittet...90 8.1 Innledning... 90 8.2 Tester... 90 8.2.1 Test (webgrensesnitt): Legge til, endre og slette medlemmer... 90 8.2.2 Test: Legge til, endre og slette instruktør... 92 8.2.3 Test: Legge til, endre og slette utstyr... 93 8.2.4 Test: Legge til, endre og slette Kurs... 94 8.2.5 Test: Legge til, rediger og slett en ny hendelse i kalender... 95 8.3 Applikasjon tester... 96 6

8.3.1 Test: Logg inn, kurs, hjem, min trening, kalender, kurs, varer, om oss og logg ut.... 96 8.3.2 Test knapper... 98 8.3.4 Test responstid... 99 8.3.5 Skjermstørrelse... 101 Brukermanual... 103 Generelt... 104 Webgrensesnittet og installasjon... 104 Hovedsiden... 104 Hjem... 105 Kalender... 106 Kurs... 108 Utstyr... 110 Medlem... 112 Instruktør... 114 Android applikasjonen... 117 Hovedsiden... 117 Logg inn... 118 Hjem... 119 Min Trening... 120 Instruktør... 121 Trening og hendelser... 122 Kurs... 123 Utstyr... 124 Om oss... 125 Logg ut... 125 Stikkordliste... 126 Kildeliste... 127 Vedlegg... 130 Vedlegg 1 Kravspesifikasjon... 130 3.7.2 Endringer... 130 Vedlegg 2 SQL... 132 7

Presentasjon Android applikasjon og webgrensesnitt for Oslo Fight Center Oslo Fight Center (OFC) er et treningssenter med mange ulike kampsport og vokser stadig. Vi skal lage en applikajson som skal hjelpe medlemmene til å ha informasjon om senteret på mobilen. Målet vårt er å lage en Android applikasjon som skal kunne gi medlemmene informasjonen som trengs rett på mobilen, lett og enkelt. Det å ha en applikasjon hvor man kan få informasjon om blant annet om OFC, timeplaner, utstyr, hvilken type kampsport som er tilgjengelig å trene hos dem, kontakt informasjon, nyheter og kalender for ulike hendelser som er relevant for dem. Veldig mange bruker smarttelefoner og dette har tatt over markedet, folk ønsker ting lett tilgjengelig og ved å lage en mobilapplikasjon gjør vi nettopp dette, gjør det enklere. Oppgaven vår er å kunne ha mange ulike løsninger, vi fikk ingen spesifikke krav om hvordan vi skulle gjøre ting, siden oppdragsgiver ikke hadde den tekniske forståelsen over hvordan man programmerer og hva som er mulig til å få til og ikke mulig, derfor fikk vi velge løsning selv. Dette gir oss friheten til å være selvstendige, og ettersom to av medlemmene i gruppen har kampsportbakgrunn og er instruktører som har jobbet lenge med dette, føler vi at vi kan tilfredsstille en god del av behovene som et vanlig medlem vil trenge. Vi valgte en Android løsning siden dette er det mest voksende operativsystemet for smarttelefoner, Android finnes i ca. 80 % av smarttelefonene ute i markedet. 1 Dette er en av grunnene, den andre grunnen er at flere gruppemedlemmer har hatt Androidprogrammering som fag og kan en god del om Android. Vi håper denne applikasjonen vil være til god hjelp for medlemmene og gjøre det enklere for alle. Webgrensesnittet var noe vi lagde først for å kommunisere med Android applikasjonen, men utviklet seg til å være en muligens løsning for administrasjonen for Oslo Fight Center. Webgrensesnittet er for å registrere medlemmer og instruktører, men skal kunne legge til nye 1 http://www.phonearena.com/news/android-is-taking-over-the-world-80-of-all-smartphones-run- Googles-OS_id46001 8

varer, kurs og hendelser. Webgrensesnittet er blitt laget til for å kommunisere med mobilapplikasjonen. 9

10

Prosessdokumentasjon 11

1. Innledning I høst møttes vi og diskuterte sammen om hva vi skulle gjøre og hvem vi kunne tenke oss å ha oppgave for. En av oss jobbet i OFC og dette var en av oppgavene vi tenkte på, samtidig tenkte vi at det ville ha vært en god erfaring å ta en oppgave som er levert av skolen, den oppgaven var: K-SPICE App for Android/iOS platforms, Kongsberg Oil & Gas. Vi hadde møter med dem og brukte mye tid på å finne mulige løsninger. Dessverre tok det tid før vi fikk hjelp, blant annet OPC-server løsning tok en del tid før vi fikk svar på. Vi hadde ikke noe kompetanse med OPC-Servere og vi klarte heller ikke å finne god nok dokumentasjon på hvordan det fungerte, eller noen som kunne hjelpe oss med dette. Dermed endte det med at vi ønsket å trekke oss fra oppgaven før det var for sent, vi følte at vi ikke kunne levere et produkt som vi var godt nok tilfredsstilte med. Dette medførte til at vi mistet nesten to måneder med arbeid, og vi endret til slutt oppgave og startet med løsningen for OFC. Valget endte på oppgaven om å lage en mobilapplikasjon og et webgrensesnitt for Oslo Fight Center dette er noe kampsportsenteret manglet og vi syntes det virket som et spennende prosjekt. Hovedprosjektoppgaven er ikke utlyst fra skolen, men er en oppgave hvor en i gruppen har forhørt seg med en mulig prosjektoppgave fra våres side. Vi fikk grønt lys fra kampsport senteret om at vi kunne lage en mobil applikasjon og frie tøyler til å lage noe mer vi så de kunne ha behov for. 1.1 Bakgrunn for valget av plattform: Android og webgrensesnittet Vi har lenge før bacheloroppgaven snakket om å lage en applikasjon sammen som en gruppe og nå som vi hadde muligheten valgte vi Android som plattform for mobilapplikasjonen. Dette er et av de største mobil OS-ene og siden to medlemmer av gruppen også hadde hatt Androidprogrammering som programfag ble dette et naturlig valg. Metodene vi bruker for å løse denne oppgaven skal også være enklere for oss eller andre som senere skulle komme og ta prosjektet til videreutvikling, eller for å få det ut i andre plattformer som ios og Windows Phone. 12

For at det skulle fungere optimalt, er det nødvendig med et webgrensesnitt som er et kommunikasjonsledd mellom databasen og applikasjonen. Webgrensesnittet brukes til å legge til informasjon i databasen som applikasjonen vil hente ut ifra. 1.2 Om gruppen Navn Studie Studentnummer Vizllim Rustemi Robin Berg Jønsson Olav Ro Mariusz Krzysztof Zych Bachelor Ingeniørfag(Data) Bachelor Ingeniørfag(Data) Bachelor Informasjonsteknologi Bachelor Ingeniørfag(Data) s181121 s181102 s169537 s181122 Vi er fire studenter hvor tre av oss går ingeniørfag (data) og en går informasjonsteknologi linjen. Gruppen har jobbet sammen siden studiestart, og har jobbet mye som en gruppe siden. Gruppemedlemmene har blitt godt kjent med hverandre i løpet av de tre årene. Vi kjenner hverandres styrker og svakheter og føler at som en gruppe dekker vi hverandres svakheter. Gruppesamarbeidet har fungert bra og vi har felles mål og ambisjoner som får hvert enkelt av oss til å jobbe mot vårt ytterste. 13

1.3 Om Oslo Fight Center 1.3.1 Oslo Fight Center (OFC) Oslo Fight Center er et av Norges største treningssentre som tilbyr kampsport- og selvforsvarstrening. I dag er det rundt 500 medlemmer i OFC. Som medlem i OFC kan man fritt velge å trene hvilken kampsport man velger å trene. 1.3.2 Krav Maga Krav Maga-trening er selvforsvarstrening. Man lærer effektive slag og spark, og hvordan man kan forsvare seg mot en eller flere angripere, også dersom de har våpen. Treningen foregår som regel inne, men vi arrangerer også utendørs treninger; i buss, i nattklubber og andre realistiske omgivelser. Krav Maga passer alle. 1.3.3 K1 K1 ligner thaiboxing og kickboxing, og inkluderer slag-, spark- og kneteknikker. K-1 gir deg utholdenhets og teknikktrening med mye "padwork" og oppgavesparring som alle har godt av, uavhengig av treningsnivå. OFC har eget konkurranselag for de som ønsker å konkurrere. 1.3.4 Submission wrestling Denne kampsporten kombinerer de fleste teknikker innen bryting/grappling, og man skal prøve å kontrollere motstanderen ved å låse ledd eller ved kvelninger. Det setter store krav til teknikk og evne til å holde hodet kaldt, så det er ikke alltid den sterkeste som vinner. OFC har eget konkurranseteam i submission wrestling. 1.3.5 MMA Mixed Martial Arts er verdens raskest voksende kampsport! MMA kombinerer både stående slag og spark med liggende teknikker likt submission wrestling med slag av ulike typer. Treningen passer for alle som har noe erfaring fra stående og liggende kampsport fra før. OFC har et konkurranseteam. 14

1.3.6 Om OFC og registrering OFC har en hjemmeside som inneholder generell informasjon om senteret. Her finner man nyheter om nye hendelser, timeplan for medlemmene og informasjon for de som ønsker å starte. OFC bruker Excel for å registrere medlemmer og for registrering av oppmøte på treningene. Oppmøte registreres på bakgrunn av gradering, man må møte et viss antall ganger for å kunne gradere seg. 1.3.7 Dagen situasjon OFC har bare en hjemmeside og ingen mobilapplikasjon. De bruker Excel til å registrere nye brukere og til eventuelle oppmøter. Vi har kommet fram til å programmere backenden på applikasjonen. Det trengs en database og webgrensesnitt til å dekke de behovene OFC kan trenge. Disse Figur 1 viser innloggingsiden, guiden og hovedmenyen pr dags dato. Figur 1 Prototype av innloggingssiden, guide og hovedmenyen. 15

1.3.7.1 Oppgavens mål Det ble laget en kravspesifikasjon som ble vist frem til OFC under det første møtet. Under møtet fikk vi beskjed om at siden de ikke viste hvor komplekst det ville være å lage programmet, ville det være opp til oss hvordan vi skulle gå fram med oppgaven. Det var som mål å lage et webgrensesnitt og mobilapplikasjon som kommuniserer med hverandre og som OFC kunne bruke. 16

1.3.7.2 Krav og rammebetingelser En applikasjon som gir kundene informasjon over treningssenterets tilbud. Applikasjonen skal gjerne ha informasjon om treningstider, terminplaner/stevner, ulike typer kampsport og informasjon om OFC som f.eks. beliggenhet, åpningstider og om OFC. Mulighet for å få kontaktinformasjon til senteret skal også være mulig. Applikasjonen skal være to-delt: 1. Informasjon til medlemmene 2. Personlig bruk Med personlig bruk menes det at applikasjonen skal ha en funksjon hvor brukeren, kan skrive treningsnotater i applikasjonen og bruke dette som treningsdagbok. Samtidig ulike øvelser som nybegynnere kan bruke til å trene på dersom de ikke vet helt hvor de skal starte. 1. Informasjon til medlemmene: - Om OFC - Timeplaner - Priser - Hvilke typer kampsport - Kontakt - Nyheter - Blogg - Kalender for ulike hendelser som er relevant for senteret - Notat - Ulike treningsøkter (for nybegynnere, On-The-Go) 17

2. Personlig bruk/instruktør: - Logg inn - Din timeplan(instruktør kan redigere/endre timeplan?) - Poste events (I dag har vi ) - Øvelser(Øvelser spesialisert til deg) - Din tid(du har ikke trent på 17 Dager) Ting vi diskuterte: - Server til å hente data fra nettsiden direkte - Dekke øvrige kampsport (Krav maga, MMA, k1, submission wrestling) - Vise hvordan man tar øvelsen riktig? (Instruks) Dette er kravspesifikasjonen for hoveddelen av applikasjonen. Teknologi brukt: Vi har valgt MySQL for databaseprogrammeringen og kjører dette på skoleserveren via XAMPP. Siden vi har brukt MySQL på skolen så velger vi dette ettersom vi har litt kjennskap til dette tidligere. 1.3.4 Begrensninger Vi begrenser mobilapplikasjonen til Android, og webapplikasjonen til nettlesere som Google Chrome og Opera. Vi har valgt å optimalisere for disse nettlesere av statistiske undersøkelser som viser tydelig hva brukermassen bruker til daglig 2. 2 http://www.w3schools.com/browsers/browsers_stats.asp 18

2. Planleggingsfasen 2.1 Begynnelsen av prosjektet Gruppen hadde allerede startet tidlig i semesteret med å diskutere hva vi hadde lyst til å jobbe med. Som gruppe har vi hatt kurs i ulike programmeringsspråk og markeringsspråk, med blant annet, HTML, CSS, Java, MySQL, PHP, C# (C-sharp), Android-programmering. Noen av gruppemedlemmene har også vært igjennom andre språk også, blant annet jquery og JSON. Vi sendte mail til ulike firmaer vi kunne tenke oss å ha en oppgave for, men flere svarte ikke. Høgskolen hadde lagt ut ulike arbeidsgivere/oppgaver, men vi fant ingen spesielle som vi følte var tiltrekkende. Etter en stund med diskusjoner kom vi fram til og fant fram til en arbeidsgiver, OFC. En av medlemmene i gruppen foreslo denne oppgaven, han trener og er instruktør i OFC og mente det kunne være nyttig for OFC. Vi hadde et møte med Ole (kontaktperson for OFC) og diskuterte kravspesifikasjonen for applikasjonen, om hva som var ønskelig. Han ville at vi skulle komme med forslag for hva vi skulle ha med. Det var ikke noe konkret han kom med og var litt usikker siden han ikke viste hvor komplekst dette kunne bli. Vi hadde en kravspesifikasjon som vi hadde tenkt på forhånd, siden to av gruppemedlemmene er instruktører i to ulike treningssenter. Den ene jobber på et treningssenter hvor han har vært daglig leder. Sammen kunne vi som en gruppe komme frem til hva vi burde ha med. Siden alle gruppemedlemmene har trent og vært elever gjør dette at vi har en tanke over hva applikasjonen burde dekke. 2.2 Planleggingsprosessen Planleggingen av prosjektet startet i januar, hvor vi hadde en del diskusjoner og møter om hvordan vi ser for oss applikasjonen. Vi snakket om hvilke type programmeringsspråk det kunne hende vi skulle bruke, og flere av disse hadde vi gått igjennom, men om det dukket opp noe nytt skulle vi bare sette oss inn i det. Siden to av gruppemedlemmene jobber som instruktører og ene har jobbet som daglig leder på et treningssenter, hadde vi en ganske god 19

bakgrunn og kunne enklere se for oss hva vi burde ha med i applikasjonen. Dette gav oss mye bedre oversikt slik at vi kan dekke behov fra både medlemmene sin side og senteret sin side. Etter at vi hadde møtet med OFC så satte vi i gang med programmering av backenden og applikasjonen. 2.3 Arbeidsfordeling Vi valgte å fordele arbeidsoppgave slik at vi får et felt der vi er best, og hjelpe hverandre dersom vi følte at det er noe vi ikke fikk til. Vi hadde ulike arbeidsoppgaver, som dokumentasjon, design og programmering. Navn Robin Olav Vizllim Mariusz Arbeidsoppgaver Koding og design Dokumentasjon og koding Design, dokumentasjon og prosjektets hjemmeside Dokumentasjon og holdt kontakt med OFC Vi valgte en slik arbeidsfordeling etter å ha diskutert sammen, slik at vi kunne jobbe mest effektivt. 2.4 Møtereferat Møtereferat ble skrevet hver dag når vi møttes og jobbet sammen. Dette er for å gi en oversikt over hva vi gjorde når, deretter kunne vi se om vi har klart å holde oss til fremdriftsplanen. Møtereferat er også viktig for å vite hva vi har blitt enige i tilfelle det skulle oppstå problem eller misforståelser om hva vi har sagt eller hva vi har valgt ha med. Møtereferatet er lagt ut på gruppens hjemmeside: http://student.cs.hioa.no/~s181121/motereferat.html. 20

2.5 Gant-diagram Vi satt opp gant-diagram(se figur 2) for hvordan vi skulle jobbe mot innleveringen av hovedprosjekt. Gant-diagrammet viser starttidspunkt og sluttidspunkt for hver av oppgavene, dette gjorde vi for å ha et klart mål på å fullføre hva vi har startet på. Figur 2 Gant-diagram 21

2.6 Milepæler Hva? Når? Forprosjekt rapport 08.02.2014 Kravspesifikasjoner 10.02.2014 Ferdig med web-grensesnitt 20.04.2014 Ferdig med applikasjon 18.05.2014 Testing/forbedring 15.05.2014 Ferdig produkt 23.05.2014 Prosjektrapport 27.05.2014 Presentasjon 11.05.2014 22

2.8 Verktøy Vi har brukt ulike verktøy i denne oppgaven for å få utviklet applikasjonen slik vi ønsker og med de verktøyene vi føler vi får best mulig utnyttelse av slik at det dekker våres behov. 2.8.1 Litt om verktøyene Eclipse XAMPP Vi brukte Eclipse til å kode, vi har brukt Eclipse før og har blitt godt kjent med den og den dekker våres behov. Den har også Android emulator hvor vi testet applikasjonen. Dette programmet brukes også i Androidprogrammerings kurset. Vi bruker XAMPP, som er vår webserver. Denne gir oss muligheten til å bruke Apache, MySQL, PHP og Pearl uten å måte laste ned hver av dem enkeltvis og sette dem opp og konfigurere dem Microsoft Word Microsoft Word brukte vi til å skrive dokumentasjon, referater, tester osv. Dette er den mest brukte programmet til å skrive dokumenter. Vi har alle brukt dette programmet og kjenner godt til det. Skype Vi brukte Skype til å holde kommunikasjonen når noen var borte slik at vi kunne snakke sammen og jobbe videre. Skype var veldig nyttig siden vi ikke ble handlingslammet når vi ikke hadde møte, vi kunne sitte og jobbe hjemmefra også. 23

Dropbox Vi brukte Dropbox til å ha et felles lagringsområde hvor alle hadde tilgang til alt. Dette gjorde dokumenter og andre filer letter tilgjengelig for gruppen. Siden alle hadde Dropbox og vi har brukt dette gjennom studietiden så var det veldig enkelt og en av de første tingene vi gjorde, lage felles mappe. Vi tok også backup underveis for å unngå at vi mistet viktige dokumenter og filer. WhatsApp Messenger Remote desktop Vi valgte å bruke WhatsApp Messenger som er et gratisprogram for å sende tekstmeldinger med hverandre, vi lagde en gruppe hvor alle medlemmene var lagt til og kunne kommunisere med hverandre hvor vi oppdaterte gruppen om hva vi hadde gjort osv. Vi brukte Remote desktop for å få tilgang til serveren på skolen. Adobe Photoshop CS6 Photoshop CS6 ble brukt til å designe bilder, som forsidebildene i dokumentasjonene. 24

GIMP GIMP ble brukt til å skalere og fikse på ikoner som er brukt på hjemmesiden og applikasjonen Visio 2013 Professional Visio 2013 ble brukt til å lage de ulike diagrammene, som tilstandsdiagram, sekvensdiagram, klasser osv. Nettlesere Google Chrome og Opera er nettleserne som er brukt. Notepad++ Notepad++ er brukt til å lage klasser i webgrensesnittet, brukt mest på server og er brukt til å lage gruppens hjemmeside. Bitbucket Vi testet Bitbucket med versjonskontroll (TLS), men det tok for lang tid, for hver gang vi skulle pushe (laste opp noe), måtte vi skrive begrunnelse også. 25

2.9 Ny kunnskap Vi fikk ny kunnskap innenfor jquery, PHP og Androidprogrammering. Noe kunnskap hadde vi allerede med noen av disse språkene, men vi har lært oss mer object-orientert programmering innenfor PHP. Samtidig lærte vi oss å programmere API med JSON til å kommunisere mellom Android applikasjonen, webapplikasjonen og server databasen. JSON konverterer Java koden til plain-text og sender parameteren til PHP scriptet. Vi har fått et bedre bilde over hvordan Android kan kommunisere med server og webapplikasjonen. 26

3. Utviklingsprosessen 3.1 Arbeidsmetode Gruppen har valgt å bruke Kanban inspirert arbeidsmetode. Dette er et rammeverk som er tilegnet seg for utvikling av programvarebaserte systemer, vi bruker just-in-time prinsippet som er å overbelaste gruppen med arbeid til å levere til rett tid. Vi har som regel fordelt arbeidsoppgaver i gruppen til å jobbe fullt fokusert med de ulike oppgavene. Vi hadde som mål med å bli ferdig med visse arbeidsoppgaver innen gitt periode. Vi hadde møter med veileder for å spørre om råd og tilbakemeldinger underveis i prosessen. Når gruppen møttes på skolen for å jobbe, hadde vi ofte diskusjon om hvordan vi lå an i forhold til tidskjema, hva vi manglet og hva vi burde ha hovedfokus på slik at vi kunne starte på nye oppgaver. 3.2 Faser 3.2.1 Research Første fasen i denne oppgaven var research. Vi satte oss ned og søkte litt over mulige løsninger på oppgaven, hvilke teknologier vi eventuelt måtte bruke og hvordan vi kan gå fram for å løse oppgaven. Med dette fikk vi en viss oversikt over hvordan det kunne se ut og hvordan vi kunne gå fram. At det ville dukke opp problemer underveis var vi helt klare på, derfor var det veldig viktig at vi diskuterte hvordan vi kunne gå fram, hva som kunne dukke opp og hvordan vi kunne løse dette. 3.2.2 Gjennomføring Gjennomføringsfasen startet vi med når vi var klare med kravspesifikasjon. Vi jobbet hver dag med oppgaven, og lagde en plan for når vi burde være ferdig med ulike deler. Vi hadde en idé, et bilde av hvordan vi så for oss oppgaven og resultat, men ettersom vi kom dypere i oppgaven ble noen ting endret ettersom at vi følte at vi kom med bedre løsninger en det som var planlagt på forhånd 27

3.2.3 Avslutningsfasen I avslutningsfasen jobbet vi intenst med applikasjonen og webgrensesnittet, samtidig drev vi med testing av de ulike funksjonene som vi har utviklet. Dette var svært viktig for oss ettersom vi ville levere et sluttprodukt i samsvar med kravspesifikasjonen. Når vi var ferdig med testene og var godt fornøyde med resultatet vi hadde oppnådd under testingen og sluttproduktet, var vi klar for levering av hovedoppgaven. 3.3 Utviklingsprosessen: Utfordringer 3.3.1 Android & JSON I Android hadde vi stor utfordring med å kommunisere med server, ettersom vi skulle hente informasjon fra databasen måtte vi finne en måte til å hente ut dataen fra. For at applikasjonen skal hente ut data måtte vi bruke JSON objekt for å innpakke data som vi skulle hente fra server, via HTTP protokollen sendes det en forespørsel til server som sender dataene tilbake innpakket som et JSON objekt tilbake til applikasjonen. Utfordringen var at vi måtte sette oss inn i hvordan man programmerer et sånn JSON objekt og http protokoll, dette var et av de mest tidskrevende og omfattende å beherske. 3.3.2 PHP og jquery I PHP og jquery hadde vi utfordringer med å sette sammen alt på plass, vi hadde utfordring med å programmere først i PHP og html, så skulle vi bruke jquery til å få til en dynamisk side for så style det med CSS. Vi fikk noen utfordringer med server ettersom vi selv måtte oppdatere server på grunn av Heartbleed 3. Vi løste utfordringen med kodingen med at vi fordelte oppgaven mellom hver av oss, en tok for seg programmering i PHP, en annen for styling og for jquery. Vi satt programmeringsdelene sammen tilslutt. 3 http://heartbleed.com/ 28

3.3.3 Sikkerhet Passord på webside og applikasjon: Når man oppretter en bruker så genereres det et salt som er unikt for den brukeren, saltet er random tegn som settes foran passordet før det hashes (SHA MD5). Alle passord som lagres i våre databaser krypteres (hashes) ved hjelp av en algoritme kalt SHA512, et tilfeldig "salt" kodet med base-64. SSL Hva er SSL? SSL står for Secure Sockets Layer som betyr at data som sendes mellom bruker og tjener sendes kryptert. Grunnen til at det sendes kryptert er at det ikke skal være mulig å sniffe over nettverket for å hente ut informasjonen som sendes mellom bruker og tjener. Tjeneren har krypteringsnøkkel med to passord, hvor den ene brukes til å kryptere innhold, mens den andre brukes til å dekryptere innhold (må være kjent for eieren). Nøkkelen for å kryptere innhold kalles for en offentlig nøkkel, mens nøkkelen for dekryptering kalles for en privat nøkkel. En måte å se om nettsiden benytter seg av SSL kan man se på nettadressen, SSL bruker https:// i stedet for http://. SSL- sertifikat er et digitalt sikkerhetssertifikat som er utstedt til et domene, en organisasjon eller privatperson for å bevise at nettstedet er ekte. SSL-sertifikat pleier vanligvis å inneholde: - Identitet til den/det sertifikatet skal identifisere - Gyldighetsperiode - Unik ID-nummer som identifiserer sertifikatet - Sertifikatets anvendelsesområder - En offentlig nøkkel (Public Key) Utsteder av sertifikatet har signert sertifikatet og kan bekrefte sertifikatets gyldighet. Vi har ikke brukt SSL sikkerheten i vårt webgrensesnitt. Grunnen til dette er at det koster å få SSL sertifisering. Vi valgte å ikke gjøre dette siden vi ikke har et webhotell noe som ville ha vært naturlig, i stedet for at vi setter det opp på egen server. 29

Hvis OFC velger å sette dette i produksjon må vi undersøke om det er mer lønnsomt å sette opp en server hos dem eventuelt kjøpe et webhotell. 3.4 Oppbygging og funksjon 3.4.1 Bruk av versjonskontroll(tls) Vi tok i bruk Bitbucket som vårt versjonskontrollsystem. Et slikt system gir mer kontroll over på hvem som redigerer/endrer og for å se hvem som har kodet siste versjon. Vi som gruppe har ikke brukt versjonskontrollsystem før, men ble anbefalt av veileder til å bruke dette. Med dokumentasjon har vi valgt å bruke versjonskontrolleren til Dropbox ettersom dette var noe alle i gruppen brukte ofte. 3.4.2 Design Arbeidsgiveren stilte ingen krav når det gjaldt design, og lot gruppen selv bestemme hvordan dette skulle utføres. Webgrensesnitt: Vi har valgt en design på webgrensesnittet som er enkelt og oversiktlig (se figur 3). Knappene er store og oversiktlige slik at man ser godt både med illustrasjon og tekst hva de ulike knappene på siden er. Fargevalget er hvitt og sølv, som gir et veldig enkel og stilren design vi fikk litt inspirasjon fra fargen til iphone 5s (sølv versjonen). Fargen på teksten er mørkegrått, noe som gir god lesbarhet. 30

Figur 3 Illustrasjon av webgrensesnittet, kalendersiden Applikasjonen: Designen på applikasjonen er veldig simpel, fargevalget er nesten det samme som på webgrensesnittet. Bakgrunnsfargen er lysegrå, og mørkegrå tekst (som på websiden). Designen på webgrensesnittet og applikasjonen speiler hverandre slik at man skal få litt av den samme følelsen ved designen. Figur 4 illustrerer matching av webgrensesnittet med blant annet bruk av like ikoner. Figur 4 Illustrasjon av applikasjonen, menyen på applikasjonen 31

3.4.3 Utelate funksjoner Underveis i prosessen kom vi frem til at vi måtte prioritere hvilke funksjoner som skulle programmeres først. Applikasjonen ble ikke todelt som var tanken i starten, med en personlig del og en informasjonsdel i selve applikasjonen. - Blogg - Notat - Endring av timeplan i applikasjonen - Øvelser - Ulike treningsøkter for nybegynnere Er funksjoner som ble endret/fjernet ettersom vi valgte å gjøre en del endringer. Mer om disse utelatte og endrede funksjoner står i avsnitt 3.7.2. 3.5 Oppdragsgiver under prosessen Oppdragsgiver under prosessen har vært veldig lett å jobbe med. Ole Boe er sjefsinstruktør og deleier av Oslo Fight Center, og er personen vi har hatt møte med i starten og fått tilbakemelding fra. Sammen under det første møtet diskuterte vi oppgaven og ble enige om visse kriterier som skulle være med. Vi ble enige om å lage en Android applikasjon for OFC. Oppdragsgiver har alltid vært tilgjengelig for oss da vi har hatt noen spørsmål rundt for eksempel OFC, eller ønsker fra dem angående applikasjonen. Vi hadde en kontaktperson fra gruppen, Mariusz, som hadde jevnlig kontakt med Ole Boe. 32

3.6 Tilbakemeldingen av oppdragsgiveren Underveis i utviklingsprosessen kom vi frem til at det være nødvendig med et webgrensesnitt (backend-løsning). Hovedgrunnen til at vi valgte å ha et webgrensesnitt er for å gjøre det enklere å endre innhold i applikasjonen for de som jobber der. Det skal ikke være nødvending med programmeringskunnskaper for å endre innhold i applikasjonen, som for eksempel legge til kurs, instruktør, medlemmer osv. Vi fikk positiv tilbakemelding på webgrensesnittet fra oppdragsgiver, de var fornøyde over hvor oversiktlig og enkelt det var å bruke samtidig ble de overasket over designen, noe de likte. De mente det er veldig bra at applikasjonen kommuniserer med webgrensesnittet på så enkelt måte, noe som gjør det blir enklere for dem å endre innhold. 33

3.7 Kravspesifikasjon 3.7.1 Endelig kravspesifikasjon Kravspesifikasjonen ble en del endret underveis, grunnen er at vi fant nye løsninger som gir et bedre resultat enn det vi først så for oss. Vi var klare over at det måtte bli endringer underveis, og var nødt til å finne andre løsninger som er bedre enn det vi hadde først planlagt. Applikasjonen vil ikke bli i to, men fant et bedre løsning med å hente ut data fra en nettside (server). Dette skal være en backend løsning, å lage et webgrensesnitt som kommuniserer med applikasjonen. Ting skal være med: 1. Applikasjonen: Logg inn Hjem Min trening Instruktør Trening og hendelser Kurs Utstyr Om oss (OFC) Logg ut 2. Webgrensesnitt: Logg inn Hjem Kalender Kurs Utstyr Medlem Instruktør Logg ut 34

3.7.2 Endringer Vi valgte å fjerne/endre disse delene: - Notat * - Blogg * - Din timeplan(instruktør kan redigere/endre timeplan?) ** - Poste hendelser (I dag har vi ) *** - Øvelser(Øvelser spesialisert til deg) * - Din tid(du har ikke trent på 17 Dager) * - Ulike treningsøkter (for nybegynnere, On-The-Go) * Forklaringer: *(ikke tatt med) **(endret, kan kun endres i webgrensesnitt og ikke i applikasjonen) ***(endret til hendelser i kalender) Vi valgte å ikke ta med disse delene fordi vi føler at det er små endringer som kan gjøres/legges til ved senere utvikling, men at vi nå lager et produkt som kan brukes og har fokus på viktige funksjoner. Det at vi valgte å utvikle webgrensesnitt gjorde at vi måtte gjøre om prioriteringer og hadde mer å gjøre enn å bare lage en Android applikasjon. Ut i utviklingen fant vi fort ut at det måtte gjøres noen grep for at det skulle bli best mulig løsning, derfor valgte vi å kjøre cirka lik design på både applikasjonen og webgrensesnittet som for eksempel fargebruk, innhold, og ikoner. Vi har prøvd å gjenspeile webgrensesnittet i applikasjonen. Det at vi har et webgrensesnitt gjør det enklere for brukeren å endre innhold i selve applikasjonen. Brukeren trenger ikke programmeringskunnskaper i Android for å kunne endre innholdet i applikasjonen. Dette gir også OFC et bedre system som de kan bruke, det vil gi dem en bedre oversikt over medlemmer og instruktører enn å føre det på Excel. Webgrensesnittet er bygget opp med tanke på en fleksibel applikasjon som skal kunne møte de endringene OFC kan få i fremtiden, som for eksempel nye medlemmer, instruktører, nye kurs, oppdatering av utstyr, endring av kontaktinformasjon, sted m.m. Dette er ikke hardkodet i applikasjonen, og en trenger derfor ikke programmeringskunnskaper for å oppdatere og 35

gjøre endringer i applikasjonen. Dette var baktanken med webgrensesnittet, for å gjøre det enklere for brukeren av systemet. Dette kan i fremtiden erstatte den nåværende løsningen de bruker. 3.7.3 Samsvar mellom kravspesifikasjoner og produkt Av kravspesifikasjonen vi leverte under førprosjekt, har vi utvidet og endret en god del på. Av førprosjekt har vi samsvar av funksjonalitet tatt med: mobil applikasjon - Om OFC - Timeplaner - Priser(endret til utstyr) - Hvilke typer kampsport - Nyheter - Kalender - Server løsning og MySQL (utvidet funksjonalitet) Av endelig kravspesifikasjon har vi alt overens med kravspesifikasjonen og produkt se punkt 3.7.1 i prosessdokumentasjon. 36

3.8 Om resultatet 3.8.1 Oppsummering Etter en god del arbeid har vi kommet frem til et resultat som vi føler oss veldig fornøyd med og som vi tror at OFC vil også bli. Resultatet ble mye bedre enn hva vi først så for oss da vi startet med dette prosjektet. Vi valgte å gjøre endringer i kravspesifikasjonen, noe som gjorde at selve løsningen ble bedre enn hva vi først så for oss. Det at vi har klart å lage en helhetspakke som kan med få utvidelser settes i bruk av OFC. Det har vært en lang prosess hvor vi har vært igjennom oppturer og nedturer, men hvor vi har klart å levere et godt produkt som vi selv er fornøyd med. 3.8.2 Konklusjon Dette har vært en lærerikt, omfattende periode hvor vi har tilegnet oss mye nyttig kunnskap og erfaringer som vil være veldig viktig for oss i fremtiden. Vi har utfordret oss selv med tanke på omfang av prosjekt, utfordringer og er derfor veldig fornøyde med at vi har kommet til veis ende. Gjennom arbeidet har vi også fått erfare hvor nyttig fagene på skolen har vært, vi har blant annet fått nytte og bruk for fag som systemutvikling, web-prosjekt, webprogrammering, menneske maskin interaksjon, applikasjonsutvikling, prototyping og datasikkerhet. Vi har prøvd mest mulig å ta i bruk alle fagene vi har lært og binde det til prosjektoppgaven for å reflektere våre ferdigheter og hva vi har lært gjennom studiet. Når vi først satt oss ned for å starte på denne oppgaven, hadde gruppen allerede mindre tid på grunn av en annen oppgave. Erfaringsnivået vi sitter igjen med etter et sånt omfattende prosjekt er både positive og negative, vi opplevde at prosjektplanleggingen var det som tok mest tid. Vi hadde regnet ut at vi kommer til å bruke lengere tid på oppgaver som vi ikke hadde muligheter å gjøre, vi hadde allerede estimert tid at vi skulle være ferdig med prosjektet i begynnelsen av mai, men måtte jobbe utover det for å få alt ting på plass. Det gruppen sitter igjen med er erfaringer som vi kan ta med oss videre inn i arbeidslivet med, prosjektplanlegging og prosjektstyring har kommet godt med. Vi føler at det er veldig viktig å planlegge et så omfattende prosjekt veldig godt for å få en smidig gjennomføring, det som kommer godt med er at vi hadde tatt høyde for at kravspesifikasjonen kunne endres under veis så vi kunne få med de viktigste kravene til å bli implementert først. Vi føler vi nå kan se tilbake på arbeidsperioden og være godt fornøyde med resultatet av prosjektoppgaven. 37

3.9 Avslutning 3.9.1 Videreutvikling 3.9.1.1 Sosiale medier Vi har alle snakket sammen om integrasjon av sosiale medier i applikasjonen. Dette er noe de aller fleste applikasjonene har i dag for å øke brukeropplevelsen. Man kunne for eksempel dele sine treninger, eller dele utstyr en synes er kule eller ønsker osv. Områder man kan dele dette ville vært de mest populære sosiale mediene i dag, som for eksempel Facebook, Twitter, Google+ etc. 3.9.1.2 Utvidelse i applikasjon En tanke vi hadde var at trenerne kan for eksempel logge inn og ha mulighet til å legge ut nyheter, og administrere privattimer osv. 3.9.1.3 Forum / Chat En chat eller forum funksjon, hvor medlemmer kan snakke med hverandre. Egen gruppe for instruktører hvor de kan diskutere med hverandre, som for eksempel om noen kan bytte timen eller forslag til øvelser. 3.9.1.4 Regex Det er en feil i regex i blant annet om feltet på registrering av Instruktør, som vi ikke er fornøyd med og har kommentert ut. Vi var nødt til å prioritere og valgte å ikke bruke mye tid på regexen. 3.9.1.5 Bildefunksjon I webgrensesnittet kan man ikke legge til bilder i utstyrsmenyen, kursene og instruktør. Knappene for å laste opp bilde er skjult grunnen til dette er at koden mangler. Dette kan lett ordnes opp i fremtiden. 38

39

Produktdokumentasjon 40

Innledning 4.1 Innledning 4.1.1 Applikasjonens hensikt Målet med oppgaven er å levere et produkt som kan brukes av medlemmene til å få tilgang til timeplaner, informasjon om OFC, priser, hvilke typer kampsport, kontaktinformasjon og nyheter. Vi lager en applikasjon med mulighet til videre utvidelse og implementasjon. 4.1.2 Beskrivelse av applikasjonen OFC applikasjonen for Android skal brukes for å gi medlemmene lettere tilgang til informasjon om OFC senteret. En slik applikasjon vil gjøre det lettere og mer tilpasset til en mobiltelefon, en å måtte besøke en webside som ikke er helt tilpasset en mobiltelefon. Det mest relevante informasjonen for et medlem er timeplaner, informasjon om OFC, priser, hvilke typer kampsport, kontaktinformasjon og nyheter. Dette er hva vi ønsker minimum skal være ferdig til fristen, og ønsker å ha med flere funksjoner om vi har tid. 4.1.2 Beskrivelse av webgrensesnittet Webgrensesnittet skal brukes for å gi de ansatte i OFC en enklere hverdag. De skal på en enkel og effektiv måte kunne kommunisere med sine medlemmer gjennom webgrensesnittet som oppdaterer applikasjonen hos medlemmene. Der skal de ha muligheten til å legge til instruktører, medlemmer, utstyr, treninger, hendelser og nyheter. Grensesnittet skal ha en enkelt og selvforklarende oppbygging med god farge og kontrast. Det er viktig med et selvforklarende utseende slik at brukeren av webgrensesnittet føler at valgene en tar samstemmer med det som skjer. 4.1.3 Mål og rammebetingelser Kravspesifikasjonen opplyser om funksjonelle- og tekniske krav til produktet. Prosjektgruppen har i stor grad bestemt kravene selv. Oppdragsgiver har kommet med veiledninger i løpet av prosjektet. De kravene som ikke har blitt oppfylt i sin helhet er omtalt i prosessdokumentet. I prosessdokumentasjonen finner man en mer utfyllende kravspesifikasjon eller se vedlegg 1 kravspesifikasjon. 41

Funksjonelle krav: 1. Webgrensesnittet leses på nettleser på datamaskinen helst Chrome. a. Systemet skal kunne nåes fra en URL. b. Webgrensesnittet lagrer informasjonen til en database(xampp). c. Registreringene sorteres på alfabetisk rekkefølge. d. Systemet skal kunne hente og endre data. 2. Applikasjonen leses på smarttelefoner som bruker Android operativsystemet a. Skjermvindu er maksimert. b. applikasjonen har navigeringsmuligheter, en navigasjondrawer 4 på hovedsiden. c. Systemet skal kunne sende informasjon til brukere d. Systemet skal kunne hente ut informasjon fra databasen Ikke-funksjonelle krav Webgrensesnittet kan settes opp lokalt eller eksternt Webgrensesnittet er bare kompatibelt med installasjon av XAMPP på server Applikasjonen støtter Android versjonen Ice Cream Sandwich 4.0 og oppover. Må ha internett tilgang for å bruke applikasjonen Optimalisert til å kjøres på smarttelefoner 4.2 Teknologi 4.2.1 Java / Eclipse / JDK/ADK Java er et objekt orientert programmeringsspråk. Java Development Kit (JDK) brukestil å utvikle Javaprogrammer. Android Software Development Kit (Android SDK) brukes til å utvikle Android applikasjoner, dette bygger seg på Java (JDK), og har debugger og ulike dokumentasjoner og veiledninger for Android utvikling. En Android applikasjon er hovedsakelig bygget opp av.xml filer(figur 6) og.java filer(figur 5). 4 https://developer.android.com/design/patterns/navigation-drawer.html 42

Figur 5 Dette er et eksempel på en.java fil Figur 6 Dette er et eksempel på en.xml fil i Android 4.2.2 Emulator Emulatoren kommer med Android SDK, som brukes i Eclipse til å teste programmet. Dette er en stor fordel når det kommer til testing. Her kan vi sette opp ulike profiler på emulatoren og teste applikasjonen på ulike skjermstørrelser for å se at det fungerer på ulike enheter. 4.2.3 PHP / HTML / CSS /MySQL/ Vi lagde et webgrensesnitt for å ha en bedre kommunikasjon, og bedre løsning for vår applikasjon. Webgrensesnittet gir administratoren mulighet til å legge ut nyheter, ulike funksjoner for medlemmer (lage, endre, slette) og andre funksjoner. HTML og CSS er brukt for å lage denne siden. HTML er selve teksten og innholdet i siden, CSS er brukt for å forme siden sånn den ser ut, design. Vi har satt opp databasen i MySQL som vi har hatt i faget databaser. PHP har vi brukt for å kommunisere med websiden og databasen og for å sende spørringer til databasen. 43

4.2.4 JSON/Android JSON bruker vi for å konvertere og generere utfyllingsfeltene over til vanlig tekst for eksempel innloggingen til applikasjonen. 44

4.3 Beskrivelse av webgrensesnittet 4.3.1 Innlogging Når vi kommer til administrator siden så får vi opp logo av Oslo Fight Center og et vindu hvor vi skal skrive inn brukernavn og passord. (Illustrasjon figur 7 innlogging) Figur 7 Innlogging 45

4.3.2 Hjem Etter å ha tastet et gyldig brukernavn og passord får vi opp hjem siden på webgrensesnittet som ser sånn ut. Se figur 8. Figur 8 Hovedsiden for webgrensesnittet Her på siden har vi flere kategorier som kalender, kurs, utstyr, medlem, instruktør. I tillegg så er det en logg av knapp og en hjem knappen hvor vi kan komme tilbake på hjemmesiden. På høyre siden ser vi kalender med fin oversikt over hendelser som foregår den valgte måneden. Øverst i høyre hjørne har vi navnet på hvem som er logget inn. I forsiden skal man kunne skrive inn teksten som vil dukke opp på mobilapplikasjonen som en push melding. 46

4.3.3 Kalender Ved å trykke på kalender ikonet får vi opp et vindu med kalender (Illustrasjon figur 9). Figur 9 Kalender på webgrensesnittet, ny hendelse legger til i kalenderen som illustrert. Her ser vi alle hendelsene som er satt opp. Man kan bla gjennom dag for dag, ukentlig eller månedlig. Vi kan hva slags hendelse det er, i hvilket tidspunkt den er og hvilken sal det er plassert. Figur 10 Ny hendelse Når vi trykker på ny hendelse dukker opp vinduet hvor vi kan opprette en ny hendelse. Her kan vi velge blant annet emna, type, sted og tiden på hendelsene vi vil opprette. 47

4.3.4 Kurs Ved å trykke på kurs ikonet får vi opp et vindu med forskjellige kurs. Her kan vi opprette nytt kurs, endre eller slette. Hvis vi vil opprette nytt kurs kan vi finne vår eget navn for kurset, velge en instruktør, antall Figur 11 Kurs på deltakere og beskrivelse. Det vil bli plassert i vinduet til høyre. Etter å ha opprettet kurset kan vi der etter sette opp kurset i hendelsene så vil den dukke opp i kalenderen for alle medlemmer. 48

4.3.5 Utstyr Ved å trykke på utstyr ikonet får vi opp et vindu med utstyr. Her kan vi legge til nytt utstyr, endre eller fjerne fra lageret. På høyre siden har vi vinduet med alt utstyret som er på lageret. Alt som er har er tilgjengelig for medlemmer på applikasjonen. Figur 12 Utstyr Når vi skal legge til nytt utstyr kan vi definere kategori utstyret skal ligge i, legge til en beskrivelse og pris. Etter som vi legger til utstyret vil den være tilgjengelig til alle våre medlemmer og alle kan bla gjennom produktene på sin applikasjon. 49

4.3.6 Medlem Ved å trykke på medlem ikonet får vi opp et vindu med registret av alle medlemmene. Her har vi muligheten til å behandle medlem register. Vi kan legge til nytt medlem, endre eller slette den. Figur 13 Medlem som har blitt registrert Når vi skal legge til nytt medlem til registret må vi innføre noe viktig informasjon om medlemmet. Medlems navn, passord, adresse, kontakt og fødselsår, bosted og kontakt. Etter det vil det bli legget inn i registret. Figur 14 Regestrasjon av ny medlem 50

4.3.7 Instruktør Når vi trykker på instruktør ikonet kommer vi oss på instruktør registret. Her har vi muligheten til å behandle informasjon om instruktørene. Vi kan legge til nytt medlem, endre eller slette. Figur 15 Instruktører som har blitt lagt til, legges i en tabell. Her kan man markere instruktøren man ønsker å redigere, slette eller hente informasjonen om Når vi skal legge til ny instruktør til registret må vi innføre noe viktig informasjon om instruktøren. Instruktørens navn, passord, adresse, kontakt og fødselsår, bosted, kontakt og litt om instruktøren. Etter det vil det bli legget inn i registret. Vi har kommentert ut regex koden fra server siden vi følte at den ikke var god nok, og hadde litt dårlig tid til å fikse på den. Figur 16 Ny instruktør 51

4.4 Beskrivelse av applikasjon Mye av koden vår kunne ha blitt generalisert for å gjøre tin enklere, men på grunn av litt dårlig tid, var ikke dette hovedfokuset vårt. Applikasjonen er delt i disse delene: 4.4.1 Logg inn På første side (når man åpner applikasjonen) får man et skjema hvor man skal fylle inn brukernavn og passord, som sjekker opp mot databasen om det stemmer og finnes. Hvis ikke får du en feilmelding. Figur 17 Logg inn (applikasjonen) Figur 18 Kodesnutt av logg inn 52

4.4.2 Hjem Her vil nyhetene dukke opp på første siden. Nyhetene legges ut på webgrensesnittet som applikasjonen henter via try-catch metoder. Figur 19 Hjem (applikasjonen) Figur 20 Kodesnutt fra hjem 53

4.4.3 Min trening Min trening henter opp informasjon fra databasen vi try-catch metoder. Her henter den opp treninger du er på meldt, og treninger du har vært påmeldt på. Man har også mulighet til å melde seg på en time i dette vinduet. Bilder: Figur 21 Min trening (applikasjonen) Figur 22 Kodesnutt fra min trening 54

4.4.4 Instruktør Her henter applikasjonen det som står i databasen i instruktør. Den lister ut instruktører med navn og bilde. Figur 23 Instruktør (applikasjonen) Figur 24 Kodesnutt fra instruktør 55

4.4.5 Trening og hendelser Informasjonen om de ulike treningene og hendelsene som er lagt til i databasen via webgrensesnittet blir hentet her. Klikker man på en trening kan man velge om å legge den til i kalender eller bli påminnet av applikasjonen. Figur 25 Treninger og hendelser (applikasjonen) Figur 26 Kodesnutt fra trening og hendelser 56

4.4.6 Kurs Det listes ulike kurs som er lagt til i webgrensesnittet, man kan klikke på dem for å få en beskrivelse av kurset. Kursene listes ut navn og bilde. Figur 27 Kurs (applikasjonen) Figur 28 Kodesnutt fra kurs 57

4.4.7 Utstyr Det er en liste som viser ulike utstyr under hverandre. Man har bilde av utstyret, pris og klikker man på en av dem vil det dukke opp en beskrivelse av produktet. Figur 29 Utstyr (applikasjonen) Figur 30 Kodesnutt fra utstyr 58

4.4.8 Om oss Om oss henter informasjon direkte fra databasen, på grunn av tidsproblemer så valgte vi å gjøre dette. Figur 31 Om oss (applikasjonen) 59

4.4.9 Logg ut Denne funksjonen logger deg ut av applikasjonen, dette er kodesnutten: Figur 32 Kodesnutt for logg ut 60

4.5 Diagrammer & Klasser (webgrensesnitt) 4.5.1 Use Case Vi benyttet oss av usecase for å dele inn de forskjellige rollene systemet skulle bygge på. Usecasene ga oss en felles forståelse for hvordan vi skulle få til en interaksjonen mellom aktørene og systemet, usecasene ble brukt tidlig i prosjektet og ga oss en stor nytteverdi av en fellesforståelse i hvordan slutt produktet skulle intragere med hverandre. Beskrivelse: Kommunikasjon mellom webgrensesnitt og mobilapplikasjon Hovedaktør: Medlemmer og Ansatte Prebetingelser: Enhetene må ha tilgang til internett. Postbetingelser: applikasjonen lister ut informasjon fra databasen, webapplikasjonen legger inn informasjon inn på databasen. Hovedscenario: Webgrensesnittet legger inn informasjon i databasen eks: varer og kurs, det blir listet ut til mobilapplikasjonen. Applikasjonen sender forespørsel til server og lister ut resultat Mulige utvidelser: mulige utvidelser er å utvide web- og mobilapplikasjonen med blogg sende push melding til medlemmer eller instruktører som man velger å huke av. Beskrivelse: Applikasjonen Hovedaktør: Medlemmer og Instruktører Prebetingelser: Enheten må ha tilgang til internett, må være medlem eller instruktør på Oslo Fight Center. Postbetingelser: Brukeren er logget inn Hovedscenario: Brukeren skriver inn brukernavn og passord Applikasjonen sender forespørsel til server og bekrefter betingelsene Sendes videre inn til Min Side på applikasjonen. Brukeren kan velge mellom eventer, varer, kurs og om oss. Mulige utvidelser: 61

Blogg for å poste hva som har skjedd den siste tiden Pushmelding til alle som har meldt seg på kurset. Figur 33 Use Case Diagrammet viser til krav som skal kunne implementeres i systemet og samhandlingen mellom kravene. Aktørene i use casene er administrasjonen og medlemmer på Oslo Fight Center. 62

4.5.2 Klassediagram I planleggingsfasen fant vi fort ut at det ville bli mange klasser, vi opprettet et klassediagram for å få en oversikt over hvordan vi skulle implementere webgrensesnitt. Etter hvert som vi kom lenger i programmeringen, kom vi borti tekniske utfordringer og behov vi hadde for å opprette flere klasser og endre klasser. Diagrammet ble ekspandert og revidert med de nye klassene. Figur 34 Klassediagram for webgrensesnittet, klassene er delt opp i Interface og vanlige klasser. Bilde illustrerer hvordan hver klasse er koblet mot hverandre og hvordan mekanismen fungerer. 63

Webgrensesnitt: Klassediagram for webgrensesnitt Antall klasser: 12 Klassenavn: Main(Index) Instructor Member Person Post Item Calendar Course Home InstructurRegistration ItemRegistration MemberRegistration Kort beskrivelse: Instructor Klassen er satt sammen av Person Member Klassen er satt sammen av Person Person Klassen Person er koblet til MemberRegistration, InstructorRegistration og Post Item Klassen Item er koblet til ItemRegistration Calendar Klassen er koblet sammen til Course og Main Course Klassen er koblet sammen til Calender og Main 64

4.5.3 Tilstandsdiagram(webgrensesnitt) Vi har valgt å lage et tilstandsdiagram for webgrensesnittet for å vise en oversikt og helhetlig bilde over kontrollflyten(overgangene) i webgrensesnittet. En kan tenke seg at dette tilstandsdiagrammet viser tilstandene til webgrensesnittet i sekvensdiagrammet. Figur 35 Tilstandsdiagram(webgrensesnitt), viser hvilken tilstand systemet har til enhver tid. 4.5.4 Aktivitetsdiagram For å hjelpe oss med å se gangen i databehandlingen internt i webapplikasjonen tegnet vi opp et aktivitetsdiagram. Dette er for å få en oversikt over alle funksjoner webapplikasjonen har og for at vi kunne få en felles forståelse for hva målet skulle være. Dette er aktivitetsdiagram over Hjem siden på webgrensesnittet: 65

Figur 36 Aktivitetsdiagram på webgrensesnittet viser hvordan oppgaven løses ved å gå fra den ene aktiviteten til den andre. Dette er aktivitetsdiagram over innlogging på webgrensesnittet og applikasjonen: Figur 37 Aktivitetsdiagram over innlogging på webgrensesnittet og applikasjonen 66

4.5.4 Sekvensdiagram I forhold til å få en oversikt over klassene laget vi sekvensdiagram for å illustrere logiske sammenhengen mellom programmet og bruker. Sekvensdiagramet har en stor nytte verdi for nye utviklere som ønsker å utvikle dette videre. Figur 38 Sekvensdiagram viser til use casene fra figur 33, flyten og tidsrekkefølgen for meldingene mellom objektene. Flyten i webgrensesnittet Hovedaktør: Bruker(ansatt eller instruktør) Beskrivelse: Viser sekvensene mellom: Login Varer Kurs Kalender Medlemmer 67

Instruktører 4.5.6 Database Dette er vår database for mobil- og webapplikasjonen, databasen er et bindeledd mellom registreringssystemet og mobilapplikasjonen. Applikasjonen henter informasjon av databasen om hvilken priser det er i butikken, ulike kurs som blir holdt og progresjon av sine graderinger. Webapplikasjonen holder styr på registreringer av brukere, varer, kurs og hendelser, hendelser er kurs og arrangeringer som blir holdt. Figur 39 Database strukturen for mobil applikasjonen og webgrensesnittet, databasen inneholder alt som blir registrert i applikasjonen og webgrensesnittet samt endringer som blir foretatt. 68

4.6 Klasser & diagrammer (Applikasjonen) 4.6.1 Use Case Dette er Use Case for mobilapplikasjonen. Figur 40 Use Case (applikasjon), kravene til hva mobilapplikasjonen skal ha. 69

4.6.2 Klassediagram Figur 41 Klassediagram (applikasjonen), klassediagrammet illustrerer alle klassene i Android applikasjonen, vi har MainActivity som er koblet til alle fragmentene, fragmentene er koblet til sin respektive klasser og adapter. Klassediagram for mobilapplikasjon Antall klasser: 28 Klassenavn: DrawerItem DrawerAdapter MainActivity GenericMethods IntroductionActivity MemberFunctions MemberAreaActivity FragmentEquipment FragmentCourse FragmentFindUs 70

FragmentHome FragmentMyTraining FragmentTrainingAndEvents FragmentBookPT Equipment EquipmentAdapter CourseAdapter Course News NewsAdapter MyTraining TrainingAndEventsAdapter MemberEvent Event BookPTAdapter Insturctor MemberEventAdapter Person og Member Kort beskrivelse: DrawerItem Klassen er koblet til MainActivity klassen. DrawerAdapter Klassen er koblet til MainActivity klassen. MainActivity Klassen er koblet til DrawerItem, DrawerAdapter, GenericMethods og MemberAreaActivity klassen. GenericMethods Klassen er koblet til MainActivity klassen. IntroductionActivity Klassen er koblet til MemberAreaActivity klassen. MemberFunctions Klassen er koblet til MemberAreaActivity klassen. MemberAreaActivity Klassen er koblet til IntroductionActivity, MainActivity, MemberFunctions, FragmentFindUs og FragmentHome klassen. FragmentEquipment Klassen er koblet til MemberAreaActivity, EquipmentAdapter og Equipment klassen. FragmentCourse Klassen er koblet til MemberAreaActivity, CourseAdapter og Course klassen. FragmentFindUs Klassen er koblet til MemberAreaActivity klassen. FragmentHome Klassen er koblet til MemberAreaActivity, News og NewsAdapter klassen. FragmentMyTraining Klassen er koblet til MemberAreaActivity, MemberEventAdapter og MyTraining klassen. FragmentTrainingAndEvents Klassen er koblet til MemberAreaActivity og Event klassen. FragmentBookPT Klassen er koblet til MemberAreaActivity, BookPTAdapter og Insturctor klassen. Equipment Klassen er koblet til MemberAreaActivity klassen. EquipmentAdapter Klassen er koblet til FragmentEquipment klassen. CourseAdapter Klassen er koblet til FragmentCourse klassen. Course Klassen er koblet til FragmentCourse klassen. News Klassen er koblet til FragmentHome klassen. NewsAdapter Klassen er koblet til FragmentHome klassen. MyTraining Klassen er koblet til FragmentMyTraining og Person og Member klassen. TrainingAndEventsAdapter Klassen er koblet til FragmentTrainingAndEvents klassen. MemberEvent Klassen er koblet til FragmentTrainingAndEvents klassen. Event Klassen er koblet til FragmentTrainingAndEvents klassen. BookPTAdapter Klassen er koblet til FragmentBookPT klassen. Instructor Klassen er koblet til FragmentBookPT klassen. MemberEventAdapter Klassen er koblet til MemberAreaActivity klassen. Person og Member Klassen er koblet til MyTraining klassen. 71

4.6.3 Aktivitetsdiagram Dette er et aktivitetsdiagram Figur 42 Aktivitetsdiagram (applikasjonen), viser flyten fra aktivitet til aktivitet i applikasjonen. En aktivitet er en pågående ikke atomisk eksekvering innen en tilstandsmaskin 5 5 http://home.online.no/~moestboe/uml_oversikt.htm 72

4.6.4 Sekvensdiagram Dette er sekvensdiagrammet for mobilapplikasjonen. Figur 43 Sekvensdiagram (applikasjonen), viser flyten i applikasjonen mellom systemets objekter og kant(kontroller) objektet, samt meldinger mellom dem. 4.6.5 Database Se kapittel 4.5.6 og figur 39, bruker samme database struktur. 73

4.7 Views modeller av webgrensesnittet Et view er en sammenslåing av flere tabeller til en tabell hvor man kan kjøre spørringer mot viewet og få ut all info, i stedet for å kjøre spørring mot flere tabeller. Her er viewene grafisk illustrert. 4.7.1 Ansatt Figur 44 View modell av ansatt (webgrensesnitt) 74

4.7.2 Instruktør Figur 45 View modell av instruktør (webgrensesnitt) 75

4.7.3 Instruktør (tabell du ville hatt i virkeligheten) Figur 46 View modell av instruktør, illustrasjon av hvordan det hadde vært i virkeligheten se webgrensesnitt. 76

4.7.4 Medlem Figur 47 View modell av medlem (webgrensesnitt) 77

4.7.5 Reservasjon Figur 48 View modell av reservasjon (webgrensesnitt) 78

4.8 Oppbygging og virkemåte Dette bildet viser hvordan applikasjonen kommuniserer med databasen. Figur 49 Oppbygning og virkemåte (applikasjonen), bilde illustrerer oppbygging og mekanismen bak mobil applikasjonen. Oppbyggingen har tre hovedpunkter, App som sender data wrapet i JSONObjekt til php som igjen sender data til databasen og tilbake. Når applikasjonen skal kommuniserer med databasen lages det en JSON objekt som pakkes inn i en PHP, en API som vi har laget som gjør SQL spørring til databasen. Deretter behandler den svaret og sender det som PHP, og applikasjonen tolker dette som JSON objekt. 79

Webgrensesnittet fungerer som illustrert nedenfor: Figur 50 Oppbygning og virkemåte (webgrensesnittet), oppbyggingen til webgrensesnittet er satt sammen av web Interface, java script og PHP, samt databasen som for data fra PHP scriptet. Når webgrensesnittet skal kommunisere med databasen, sender den en forespørsel i JavaScript (JavaScriptet henter all den informasjonen den trenger). Det sendes som et JSON objekt pakket inn i PHP kode, og blir gjort om til SQL spørringer. Databasen behandler svaret og svarer i PHP. JavaScripten tolker JSON objektet og oppdaterer viewet i webgrensesnittet. 80

4.9 Driftsmiljø - XAMPP 1.8.2 & 1.8.3 - Windows Server 2012 - MySQL 5.0.27- standard - PHP-server 5.5.11 - jquery 1.9.1 - Android API Level 19 version code KITKAT - Fiber linje 60/50 mbps Uninett. 4.9.1 Utviklingsmiljø - Windows 7, Mac OS X Mavericks v10.9.3 - XAMPP 1.8.2 - Notepad++ - Android ADT 4.9.2 Server - Windows 7 Enterprise - Quad-Core AMD Opteron prosessor 2376 2.46 GHz - 4 gb ram - 64-bit operativsystem 81

5. Installasjon og kjøring på maskiner Denne installasjonsveiledningen forutsetter at XAMPP( X(any operating systems), Apache, MySQL, PHP and Perl) er installert på datamaskinen som skal tjene nettstedet 6. Det spiller ingen rolle hvilken operativsystem du velger, men denne installasjonsguiden er for Windows. Se gjennom systemkravene og sørg for at like eller nyere versjoner av Apache, MySQL og PHP er installert på maskinen. Installerer man Windows server 2012 finner man allerede PHP 5.5.11 inkludert i XAMPP når man installerer det på maskinen. Som et generelt sikkerhetstiltak er det god skikk i å opprette flere dedikerte brukere med ulike rettigheter og passord. Dette finner du XAMPP konfigurasjonen, som nåes ved å skrive localhost i nettleseren. Veiledningen går ut fra at følgende stier finnes for Apache: Webserverens dokument-rot: C:\programs\xampp\htdocs I stien over legger du til mappen til webgrensesnittets prosjekt dokument. Når prosjekt dokumentet har blitt lagt til, slår man på Apache serveren. Start MySQL Database og Apache Web Server, test om alt fungerer. Bruk stien localhost/mappenavn/index.php for test. Om du har domene følg stien under: I nettleseren domene/mappedokukmentetsnavn/index.php Det anbefales å laste opp filene og databasen på et web domene. 5.1 Oppsett av databasen og tabell i MySQL 1. Opprett en MySQL database med navnet OFC i enten phpmyadmin eller åpne cmd i Windows. I Windows 7 klikker man start kjør og søker cmd og i Windows 8 i Metro menyen eller søk funksjon cmd. Vi tar for oss oppsett i cmd for dem som ønsker å gjøre det manuelt i phpmyadmin ler det bare å starte Apache og skrive inn localhost i nettleseren. 6 dfdf 82

2. Gå inn på kjør og legg til denne kommando for å åpne databasen: c:\xampp\mysql\bin\mysql.exe p u root 3. Create database OFC; 4. Eksempel på å legge inn tabeller. Gå inn på sql.txt filen og hent ut alle tabellene du skal legge til i databasen vi tar for oss en tabell eksempel, men metoden gjelder for alle. Se vedlegg 2 SQL for alle kommandoene, eller prosjektmappen SQL.txt Her legger vi til post tabellen som skal inneholde alle postbokser i landet. Når du har opprettet denne tabellen legger du til filen Postnummer.txt, åpner filen ctrl-c og ctrl-v i cmd så enter. Da har man lagt til alle postnummer i landet CREATE TABLE Post( PostalCode CHAR(4) NOT NULL, Post VARCHAR(100) NOT NULL, CONSTRAINT PostalCode PRIMARY KEY(PostalCode) ); Her opprettes person tabellen, det er viktig at vedkomne legger inn tabellene i kronologisk rekkefølge som tekstdokumentet følger, dette for å unngå komplikasjoner. CREATE TABLE Person( PNr INT AUTO_INCREMENT NOT NULL, Firstname VARCHAR(100) NOT NULL, Lastname VARCHAR(100) NOT NULL, Height INT NOT NULL, Weight INT NOT NULL, Address VARCHAR(100) NOT NULL, PostalCode CHAR(4) NOT NULL, Birthday date NOT NULL, 83

Mobile CHAR(8) NOT NULL, Phone CHAR(8) NOT NULL, Email VARCHAR(100) NOT NULL, Password CHAR(128) NOT NULL, Salt CHAR(128) NOT NULL, CONSTRAINT PersonPN PRIMARY KEY(PNr), CONSTRAINT PersonPostalCode FOREIGN KEY (PostalCode) REFERENCES post(postalcode) ); 5. Her er eksempel på hvordan man legger inn data i tabellene, etter man har opprettet dem så klart. Husk at tabellene må være opprettet før du kjører denne kommandoen i cmd: insert into person values( '', 'Donald', 'Duck', 'Apalveien 111','0501','1932-05-13', '12345678','donald@duck.no', Password( 'Donald123' ) ); 5.2 Feilsøking Hvis man bare ser en tom side eller kommer ikke seg på, tyder det på at det enten er noe feil med PHP/database-delen eller systemet. For å forenkle søkingen etter feil hjelper det å aktivere feilmeldinger for å finne ut av hva som kan ha godt galt: 1. kommenter ut følgende linjer i fila / php.ini error_reporting = E_ALL & -E_DEPRECATED display_errors = Off html_errors = Off Kommenter ut ved å skrive *;* foran hver linje, slik: ;error_reporting = E_ALL & -E_DEPRECATED ;display_errors = Off 84

;html_errors = Off 2. legg til følgende linjer under hver respektive utkommenterte linje: error_reporting = E_ALL & -E_STRICT display_errors = On html_errors = On 3. Restart Apache-serveren manuelt ved å få opp programmet og slå det av å på. Grønn farge er på og rød farge er av. Nå vil man kunne se HTTP- og PHP-feilmeldinger på siden for å kunne feilsøke problemet. 5.3 Oppsett og installering av Android ADT 1. Første man må gjøre er å søke for Android SDK på Google eller gå inn på denne linken http://developer.android.com/sdk/index.html?hl=sk hvis den fremdeles fungerer. Der laster man ned verktøyet, som er tilgjengelig for Mac OS X og Windows. 2. Når man har lastet ned ADT/SDK er det gå og finne mappen hvor man har lastet den ned på i mitt tilfelle er det c://nedlastinger/adt-bundle-windows-x86_64-20140210. 3. I mappen går vi på Eclipse og finner programmet Eclipse grønn ikon med krøllparenteser og dobbelt klikker. 4. Når man starter for første gang spør Eclipse om workspace, det er opptil dem selv hvor man vil lagre prosjektene sine, i min tilfelle opprettet jeg meg en mappe som heter AndroidProsject hvor jeg har lagt til prosjekt oppgaven, anbefaler at du gjør det også. Huk av (use this as default and do not ask again) for å slippe om samme spørsmål neste gang du kjører. 5. Når man har lagt til prosjektet i mappen hvor workspace er satt til, i min tilfelle c://androidprosject, velger man å klikke File->Import->Android->Existing Android Code 85

Into Workspace også tar man Browse finner prosjektet i prosjekt mappen og klikker på next og går igjennom det som står der eller rett og slett finnish. 6. Første gang man kjører må man sette opp emulator, eller koble til en Android enhet. Vi tar for oss emulator i dette eksempelet, men om du kobler til mobil klikker du på run->run as-> Android application også velger du enheten din, det forutsetter at man har mobil driverne installert på pc, søk Google hvis det oppstår problemer for å finne lignende problemer og løsninger. 7. Oppsett av emulator run->run configurations..->target->automatically pick compatible device >Manager->new fyller ut feltene og klikker ok. Nå kan du markere emulatoren og klikke start vil den sakte men sikkert komme opp. 8. Marker prosjektet klikk ->run->run as->android application. Vent til emulatoren får kjørt prosjektet og at applikasjoen kommer opp. 9. Der har du det! Hvis applikasjonen ikke kommer opp eller at det av en eller annen grunn krasjer, er det best å oppsøke en programmerer eller lese gjennom feilmeldingene på hva som har gått galt. 10. Problem som kan oppstå applikasjonen er koblet til Høgskolen i Oslo og Akershus sin server, endre url til installasjonens server domene. Applikasjonen er laget for API level 19 versjons navn KitKat, sørg for at API level fra og med versjon 4.0 Ice Cream sandwich er med. 11. Noen tips som kan få prosjektet til å fungere hvis det skulle oppstå komplikasjoner, test på mobil som kjører Android. I ADT Eclipse marker prosjektet og gå inn på Source->clean up->finnish. 86

6. Grafisk brukergrensesnitt Vi har valgt å lage brukergrensesnittet ut i fra de syv designprinsippene, og googles retningslinjer for design på Android. Det var også viktig å tenke på brukervennlighet, siden det skulle kunne brukes av mange på senteret. 6.1 De syv designprinsippene De syv designprinsippene er structure, simplicity, consistency, tolerance, visibility, affordance og feedback. Dette er prinsippene for hva som er god design. Structure structurert og organisert innhold Symplicity informasjonen skal vises tydelig og være lett å finne frem til Consistency går på at designet er gjennomgående i applikasjonen og webgrensesnittet. Tolerance konsekvenser av brukerfeil. Visibility at det er tydelig på hva de forskjellige funksjonene gjør Affordance dreier seg om hvorvidt det er opplagt på hvordan man bruker funksjonalitet. Feedback tilbakemelding fra brukeren om hva som er bra og hva som kan forbedres Det er få mulighet for brukeren å gjøre feil enten i applikasjonen eller i webgrensesnittet, ettersom programmet er bygget på akkurat de funksjonaliteten man trenger er det vanskelig å ta feil og ikke finne frem til riktig funksjonalitet man leter etter. Man får klare tilbakemeldinger enten man bruker applikasjonen eller webgrensesnittet. For eksempel så har vi regulære uttrykk 7 for hvordan man skal skrive i feltene, brukeren får klar tilbakemelding om han/hun har skrevet noe feil på en av feltene og for hvordan man skal skrive det riktig. I applikasjonen har vi lagt til toast 8 som viser til for brukeren står. 7 Valideringskontroller for hva hvordan man skal skrive i feltene 8 Toast er en funksjon som er en forklarende skjermelding 87

7. Gjenstående arbeid Selv om OFC Oslo Fight Center Android applikasjon er tilnærmet ferdig er det små ting som er igjen. Det gjenstår å kjøpe/leie inn server for Oslo Fight Center slik at man kan bruke dette videre, ettersom vi benytter skolens server til å kjøre applikasjonen og webgrensesnittet fra. Det bør også foretas flere brukertester av medlemmer på senteret, for å se om at applikasjonen ikke krasjer når flere brukere er på osv. Dette vil hjelpe til å få en bedre brukeropplevelse av applikasjonen. Det er også noen bugs og småjusteringer som gjenstår, blant annet oppdateringer av noen funksjoner i webgrensesnittet og noen få funksjoner i Androidapplikasjonen. Bugs som trolig må fikses er regex funksjoner og noen sql setninger på web grensesnittet, på Android applikasjonen kan det gjenstå noen funksjoner for påmelding på kurs og valg av instruktør, det er implementert, men kan ha noen bugs, nyttig med flere tester. 88

Testdokumentasjon 89

8. Testdokumentasjon for webgrensesnittet 8.1 Innledning Vi foretok enhetstesting 9 av systemet og testet ulike funksjoner som vi hadde implementert. 8.2 Tester 8.2.1 Test (webgrensesnitt): Legge til, endre og slette medlemmer Formål Målet med denne testen er å se om funksjonene: Nytt medlem, vis, rediger og slett fungerer. Hvordan teste funksjonene I hjemmesiden går vi inn i medlem (direkte link: http://opc.vlab.cs.hioa.no/ofc/member.php) og legger til et testmedlem som vi tester de ulike funksjonene på. Mål Nytt medlem skal kunne legge til medlem Vis skal kunne vise medlemsinformasjon av det markerte medlemmet Rediger skal kunne redigere medlemsinformasjon Slett skal slette medlemmet fra listen 9 http://kvalitet.underlupen.no/2008/11/hva-er-egentlig-en-enhetstest.html 90

Resultat Nytt medlem funksjonen gir ønskede resultater, den legger til medlem med den gitte informasjon. Vis funksjonen fungerer som ønsket. Ved å klikke på et medlem i feltet og klikke på vis får vi medlemsinformasjonen. Slett funksjonen fungerer, ved å markere et medlem og klikker på slett vil medlemmet slettes. Konklusjon Det er tenkt at rediger funksjonen skal endre adresse, vekt og tlf. nummer ved å endre disse funksjonene vil det fungere. Hvis en skal endre alt, til og med navn, etternavn osv. er det bedre å legge til en helt ny person. 91

8.2.2 Test: Legge til, endre og slette instruktør Formål Målet med denne testen er å se om funksjonene: legge til Instruktør, vis, rediger og slett fungerer som de skal. Hvordan teste funksjonene I hjemmesiden går vi inn i Instruktør (direkte link: http://opc.vlab.cs.hioa.no/ofc/instructor.php ) og legger til et testperson som vi tester de ulike funksjonene på. Mål Legge til Instruktør Vis skal kunne vise personinformasjon av den markerte instruktøren i tabellen Rediger skal kunne redigere personinformasjon Slett skal slette personen fra listen Resultat Legge til en ny instruksjon funksjonen gir ønskede resultater. Vis funksjonen fungerer etter å ha oppdatert siden, viser tomme felter på informasjonen om instruktør hvis ikke en oppdaterer siden. Rediger gir en feilmelding når man skal lagre, men det blir oppdatert. For at rediger og vis funksjonen skal fungere må siden oppdateres, og når man da klikker på rediger eller vis dukker feltene opp. Slett funksjonen fungerer. Konklusjon Vi har kommentert ut regex koden fra server siden vi følte at den ikke var god nok. Før man bruker vis og rediger funksjonen etter at man har lagt til en instruktør, må siden oppdateres for at feltene skal dukke med registrert informasjon. Selv om man får feilmelding så oppdateres informasjonen seg. 92

8.2.3 Test: Legge til, endre og slette utstyr Formål Målet med denne testen er å se om funksjonene: legge til, vis, rediger og slett utstyr fungerer som de skal. Hvordan teste funksjonene I hjemmesiden går vi inn på utstyr (direkte link: http://opc.vlab.cs.hioa.no/ofc/utstyr.php NB: Du må være pålogget for å komme inn på siden) og legger til et testutstyr som vi tester de ulike funksjonene på. Mål Legge til Utstyr Vis skal kunne vise utstyr informasjon enten i tabell eller i feltene Rediger skal kunne redigere utstyr informasjon Slett skal slette utstyret fra listen Resultat Legge til nytt utstyr gir ønskede resultater. Endre utstyr fungerer, den endrer verdier. Slett fungerer, den sletter utstyr. Konklusjon Legge til, vis, endre fungerer som det skal. 93

8.2.4 Test: Legge til, endre og slette Kurs Formål Målet med denne testen er å se om funksjonene for kurs: legge til, vis, rediger og slett fungerer som de skal. Hvordan teste funksjonene I hjemmesiden går vi inn på kurs (direkte link: http://opc.vlab.cs.hioa.no/ofc/course.php ) og legger til testkurs som vi tester de ulike funksjonene på. Mål Legge til kurs Redigere kurs Vise kurs informasjon og liste dem ut i tabell Slett kurs fra listen Resultat Resultatet ble som ønsket. Man kan legge til kurset, og får det i tabellen ved siden av. Klikker man på det kurset og velger rediger, kan man endre feltene Slette kurset fungerer, man klikker på kurset man ønsker å fjerne, og klikker på slett. Konklusjon Knappene fungerer som ønsket, de legger til, redigerer og sletter. 94

8.2.5 Test: Legge til, rediger og slett en ny hendelse i kalender Formål Målet med denne testen er å se om funksjonene: legge til, slett og rediger en ny hendelse i kalender fungerer og at den kommer opp som en ny hendelse. Hvordan teste funksjonene I hjemmesiden går vi inn på Kalender (direkte link: http://opc.vlab.cs.hioa.no/ofc/calendar.php ) og legger til nye hendelser som vi tester på de ulike funksjonene på. Mål Legge til Hendelse Vis skal kunne vise informasjonen som har blitt lagt til Rediger skal kunne redigere informasjonen som har blitt satt inn i kalender Slett skal slette hendelsen fra listen Resultat Får ingen feilmeldinger når vi legger til hendelse i kalender. Man må oppdatere siden og klikke seg til den gitte datoen for at det skal dukke opp. Denne delen er ustabil, noen ganger dukker ikke hendelsen man legger til opp der og da, det kan ta tid. I et tilfelle dukket ikke hendelsen opp før dagen etter at vi testet funksjonen. Konklusjon Det er noe som ikke stemmer i koden her, ellers så er det serveren som er feil. Her er det mulighet til å rette opp funksjonen. 95

8.3 Applikasjon tester Testene blir testet på en Android mobil med Android versjon 4.1 og skjerm størrelse 4.3. Merke på mobilen er en Xiaomi MI2s 8.3.1 Test: Logg inn, kurs, hjem, min trening, kalender, kurs, varer, om oss og logg ut. Formål Målet med denne testen er å se om å logge inn på applikasjonen fungerer som den skal og at vi får opp ønskede resultater som vi har implementert. Det er viktig og se at applikasjonen henter ut alt av sqlen som ligger i databasen på server. Hvordan teste funksjonene For å teste funksjonen må man laste ned OsloFightCenter.apk, som kjøres på en Android telefon, eller at man åpner prosjekt mappen i Android ADT og kjører det i en emulator, men vi tester den på telefonen. Send forespørsel eller kontakt oss på email adressen under: Olav Ro <s169537@stud.hioa.no>, Vizllim Rustemi <s181121@stud.hioa.no>, Mariusz Krzysztof Zych <s181122@stud.hioa.no>, Robin Berg Jønsson <s181102@stud.hioa.no> for å få tilsendt apk, eller prosjektet. Mål Logge seg inn på applikasjonen Velge kurs fra applicationdrawer og velge forskjellige kurs Gå inn på utstyr og bla seg igjennom forskjellige utstyr. Gå inn på min trening og se om oppmeldte kurs kommer opp. Om oss informasjonen kommer opp fra databasen Hjem lister ut dagensnyheter Kalender med treninger og eventer kommer opp Logg ut 96

Resultat Logg inn ga ønskede resultat, man fikk logget seg inn og applikasjonen fungerte ikke uten internett tilgang. Inn på kurs gikk det fint å bla seg igjennom kurs og applikasjonen responderte. Ønskede resultater ble listet ut når man klikket på kurset man var interessert i også ble det listet ut som vi ønsket. Utstyr fungerte og ga like ønskede resultater som kurs. Logg ut fungerte, man fikk logget ut. Om oss hentet ut sqlen fra databasen og gps/kart fungerte Hjem viser dagens nyheter og lister ut dagens trening. Min trening viser påmeldte treninger Instruktør lister ut instruktører på senteret og man kan velge hvilke instruktør man ønsker. Kalender og eventer viser kalender med forskjellige kurs på forskjellige dager. Konklusjon I denne testen la vi til først få dummy data for å se om applikasjonen bruker kort, eller langt tid på å hente nylig lagt inn data i databasen. Når vi så at responstiden var så raskt at vi ikke la merke til at applikasjonen, faktisk henter sql fra databasen på skole server, testet vi at innlogging, utstyr, kurs og om oss fungerte som de skulle. Alt i alt fikk vi ønskede resultater som er beskrevet under resultater. Når vi testet de opplagte funksjonene som henter ut data fra databasen, gikk vi på de mer krevende oppgavene applikasjonen gjør og som er selve målet med applikasjonen, De mer krevende oppgavene applikasjonen gjør utenom å liste ut fra databasen, er at man kan velge forskjellige kurs man kan melde seg opp på. Kursene man har meldt seg på legges under min trening, om det er privattime man ønsker så er det bare velge instruktør man ønsker å trene med til hvilken dato. 97

8.3.2 Test knapper Formål Få tilgang til alle knapper så lett som mulig Plassering Plasseringer på hvor lett valgmulighetene er tilgjengelig Test enheter Mobile enheter som blir testet på er Samsung Galaxy s3 og Xiaomi mi 3. Test metode Teste med en hånd, slik at jeg rekker alle funksjonene i applikasjonen: Knapper Valgmuligheter Application drawer Resultatet En hånd Knapper Valgmuligheter Application drawer Godkjent Ok Ok Ok Kommentar til resultatet Med en hånd, har vi plassert knappene og ikonene, slik at man skal kunne holde telefonene og rekke fram til alle funksjoner med tommelen, det forutsetter at skjermstørrelsen ikke er større enn 4.3. Konklusjon Testingen viser at det er lett å navigere seg rundt i applikasjonen som forventet. 98

8.3.4 Test responstid Formål Finne ut om applikasjonen har noen forsinkelser når det gjelder å finne sql fra databasen, kart på om oss, Instruktør, kalender, min trening, utstyr og hjem. Responstid Funksjonene i applikasjonen skal ha minst mulig responstid helst under 1 sekund Alle funksjoner som omhandler databasen må ikke ha for lang responstid helst under 3 sekunder. Test enheter Mobile enheter (Samsung S3 eller Xiaomi mi 3) En stoppeklokke Testmetode Teste de generelle funksjonene i applikasjonen alle funksjonene omhandler databasen. 1. Logg inn 2. Hjem 3. Min trening 4. Instruktør 5. Trening og hendelser 6. Kurs 7. Utstyr 8. Om oss Forventet resultat Forventer at funksjonene skal kunne bruke mindre enn sekundet 99

Resultatet Funksjoner Logg inn Hjem Min trening Instruktør Kalender Kurs Utstyr Om oss Responstid 0.7-0.9 sek 1.1-1.3 sek 1.3-1.5 sek 1.2-1.5 sek 1.2-1.5 sek 1.2-1.4 sek 1.2-1.5 sek 1.1-1.3 sek Kommentar til resultat For de generelle funksjonene i applikasjonen, var det som forventet med resultat på responstiden. Vi registrerte at applikasjonen ga varierende resultater på responstiden, så det ikke var så lett å måle helt nøyaktig. Derfor har vi har satt opp cirka tall, siden det varierer med tiden det tar for å hente ut informasjon fra databasen på server på grunn av båndbredde og trafikk. Konklusjon Det som ble forventet på forhånd, stemte ganske godt med testingen. Det var sånn gjennomsnittlig 1-2 sekunder responstid fra server. 100

8.3.5 Skjermstørrelse Formål Formål med testen er å teste ut forskjellige skjermstørrelser på mobil og se om alle skjermstørrelser er kompatible. Test enheter Vi har testet det på tre forskjellige mobiltyper som alle har forskjellige skjerm størrelser, mobilenhetene er: Xiaomi mi2s 4.3, Samsung S3 og Samsung S4. Resultater Alle skjermløsningene på test enhetene var kompatible. Se også resultat under. Skjermst ørrelse Logg inn Home My training Instructor s Trainin g & Course s Equipmen t Abou t us Events 4.3 OK OK OK OK OK OK OK OK 4.8 OK OK OK OK OK OK OK OK 5.0 OK OK OK OK OK OK OK OK 101

102

Brukermanual 103

Generelt Denne brukermanualen retter seg mot sluttbrukere av webgrensesnittet og Android applikasjonen for Oslo Fight Center. Formålet med brukermanualen er å veilede brukeren av webapplikasjonen og applikasjonen til å forstå hvordan systemet fungerer. Forkunnskapene forutsettes av at leserne og brukerne har grunnleggende forståelse av bruken av et webgrensesnitt og mobil applikasjoner. Webgrensesnittet er laget spesielt rettet mot applikasjonen, endringer som blir endret i webgrensesnittet blir også endret i applikasjonen. Webgrensesnittet og installasjon Installasjonen av webgrensesnittet skjer med at Oslo Fight Center bestiller et webhotell, og hvor vi foretar installasjon av de nødvendige tingene for dem. OFC kan også gjøre det på egenhånd ved å leie inn folk som foretar installasjonen med CD-en som blir gitt fra oss til dem, installasjonsprosessen er for komplisert til å installeres uten forkunnskaper. Webgrensesnittet hostes på skolens servere på: http://opc.vlab.cs.hioa.no/ofc/index.php. Det er bare å gå på siden å logge seg på. Hovedsiden Webgrensesnittet inneholder seks(syv) hovedsider. Disse er: 1. Hjem 2. Kalender 3. Kurs 4. Utstyr 5. Medlem 6. Instruktør 7. Mobil 104

Hjem Webapplikasjonen er laget for dem som sitter i resepsjonen og skal interagere med mobilapplikasjonen, når man logger seg på webgrensesnittet kommer de til hovedsiden som er hjem. Hjem inneholder informasjon om dagens trening i hvilket kurs og hvem som har meldt seg på. Figur 51 Hjem (webgrensesnitt) Hjem viser dato og dagens trening Dagens trening er klikkbar og viser hvem som har meldt seg på treningen. Man kan bla frem og tilbake i dato og se foregående eller kommende treninger og hvem som har meldt seg på i de forskjellige treningene. Man kan legge til en nyhet 105

Kalender I kalender kan man legge til nye hendelser og bla seg igjennom dem om man skulle ville endre eller slette dem. Kalender har knapper som i dag som viser dagens treninger, dag som endrer datoen til dager, uke som endrer datoen til uker og måned som endrer datoene til måneder. Hendelse er der for å legge til nye hendelser som treninger, møter og samlingspunkter osv. Hendelsene blir lagt til i kalenderen systematisk. Figur 52 (Bilde av kalender siden: http://opc.vlab.cs.hioa.no/ofc/calendar.php) 106

Hendelse må fylles inn på denne måten: Emne tittel på hva det gjelder som kurs, utetrening og møter osv. Type type trening, kurs eller møte. Sted møtested. Kapasitet hvor mange det er plass til og antall deltagere, fylles ut i siffer. Start tid start tidspunktet, dato og klokkeslett fylles ut på denne måten dd:mm:åååå, tt:mm. Slutt tid slutt tidspunktet, dato og klokkeslett fylles ut på denne måten dd:mm:åååå, tt:mm. Kalender viser dato og har funksjoner som i dag, dag, uke og måned. Funksjonene endrer dato. Hendelse legger til en hendelse i kalenderen. Hendelsene er klikkbare og kan endres slettes. Figur 53 (Bilde av ny hendelse i kalender, siden: http://opc.vlab.cs.hioa.no/ofc/calendar.php) 107

Kurs Kurs legger til nye eller redigerer gamle kurs. Kursene som blir lagt til legges til i en liste på høyre side i et skrål vindu. Kursene på høyre side er klikkbare og kan endres om man klikker på dem. Endringer og nye kurs som blir foretatt legges inn automatisk til applikasjonen. Figur 54 (Bilde av kurs siden: http://opc.vlab.cs.hioa.no/ofc/equipment.php) 108

Hvordan man fyller ut feltene på kurs: Navn Navnet på kurset fylles ut med tekst Max deltakere max antall deltagere det er plass til i kurset fylles ut med max tre siffere. Beskrivelse en kort beskrivelse om kurset fylles ut Priser - priser kan legges til for ulike grupper etc studenter priser, junior og senior. I feltet kan man skrive studenter pris 200kr eksempel og legge til flere i samme kurs. Instruktører klikk på instruktører som holder kurset, de valgte instruktøren blir flyttet over i listen over valgte instruktører. Figur 55 (Bilde av nytt kurs, siden: http://opc.vlab.cs.hioa.no/ofc/equipment.php) 109

Velger man kurs på høyre siden for man valgene mellom å redigere og slette kurset. Klikker man på slett slettes kurset, endrer man på noen av feltene og klikker rediger blir valgte kurset redigert. Nytt kurs vil si å opprette et nytt kurs, feltene må fylles og opprettes. Alle kursene som har blitt opprettet legges i listen på høyre side Utstyr Utstyr legger til nye eller redigerer utstyr som allerede ligger i listen. Utstyret som blir lagt til legges til i en liste på høyre side i et skrål vindu. Utstyret på høyre side er klikkbare og kan endres om man klikker på dem. Endringer og utstyr som blir lagt til, blir også lagt systematisk inn i applikasjonen. Figur 56 (Bilde av utstyr siden: http://opc.vlab.cs.hioa.no/ofc/equipment.php) 110

Hvordan man fyller ut feltene på utstyr: Navn navn på utstyret man skal legge til Kategori i hvilken kategori utstyret tilhører Pris prisen på utstyret fylles ut slikk med siffer xx.xx Beskrivelse beskrivelse av varen Figur 57 (Bilde av ny utstyr, side: http://opc.vlab.cs.hioa.no/ofc/equipment.php) Velger man varer på høyre side får man valgene mellom å redigere og slette varen. Klikker man på slett så slettes varen, endrer man på noen av feltene og klikker rediger blir valgte varen redigert. Ny vare vil si å opprette et ny vare, feltene må fylles og opprettes. Alle varene 111

Medlem Medlem er laget for å registrere nye medlemmer, man kan også redigere, slette eller vise informasjonen til medlemmer man velger. Medlemmene som blir registrert vises i en tabell så man har alle medlemmene lett tilgjengelige. Medlemmer som blir lagt til får automatisk tilgang til applikasjonen med epost de oppgir og passord de selv velger. Figur 58 (Bilde av medlem, side: http://opc.vlab.cs.hioa.no/ofc/member.php) 112

Hvordan man fyller ut feltene på medlem: Fornavn navn på medlemmet. Etternavn etternavn på medlemmet Passord passord må være minst 8 tegn, noen store og små bokstaver og må inneholde minst et siffer. Adresse fylles med medlemmets hjem adresse. Postnr postnr må inneholde 4 siffer og være en gyldig postnr i Norge, stedsnavnet dukker opp automatisk etter at man har tastet inn postnr. Høyde høyden på medlemmet må være 3 sifferet. Født fødselsdato på vedkomne, fylles ut slik dd.mm.åååå Mobil mobilnummer, 8 siffer. Telefon hjem telefon nummer 8 siffer. E-post e-post adresse på vedkomne, fylles ut med text @ text. domene Figur 59 (Bilde av Nytt medlem, siden: http://opc.vlab.cs.hioa.no/ofc/member.php) 113

Nytt medlem: registrer ny medlem, hvert nye medlem som blir lagt til legges i tabellen over. Vis: fungerer på den måten at man velger en medlem fra tabellen som man vil hente ut informasjon fra. Rediger: velger en medlem fra tabellen og klikker rediger for å redigere medlemmet, når man har redigert eller endret på noen av feltene, så avslutter man med å klikke oppdater. Slett: velger en medlem fra tabellen og klikker slett. Instruktør Instruktør er laget for å registrere instruktører på senteret. Registrerte instruktører kan også redigeres, slettes eller vise kontakt informasjonen til instruktøren man velger fra tabellen. Instruktørene som blir registrert vises i en tabell så man har alle instruktørene lett tilgjengelige. Instruktørene som blir lagt til, får automatisk tilgang til applikasjonen med eposten de oppgir og passord de selv velger. Figur 60 (Bilde av instruktør, siden: http://opc.vlab.cs.hioa.no/ofc/instructor.php) 114

Hvordan man fyller ut feltene på Instruktør: Fornavn navn på instruktør. Etternavn etternavn på instruktør Passord passord må være minst 8 tegn, noen store og små bokstaver og må inneholde minst et siffer. Adresse fylles med instruktørens hjemadresse. Postnr postnummer må inneholde 4 siffer og være en gyldig postnummer i Norge, stedsnavnet dukker opp automatisk etter at man har tastet inn postnummeret. Mobil mobilnummer, 8 siffer. Telefon hjem telefon nummer 8 siffer. E-post e-post adresse på vedkomne, fylles ut med text @ text. domene Om meg fyller ut informasjon om instruktøren, må inneholde en viss lengde informasjon. Høyde høyden på instruktøren må være 3 sifferet. Vekt vekt er i kg og fylles ut med siffer Født fødselsdato på vedkomne, fylles ut slik dd.mm.åååå Vi har kommentert ut regex koden fra server siden vi følte at den ikke var god nok, og hadde litt dårlig tid til å fikse på den. 115

Figur 61 (Bilde av registrer instruktør, siden: http://opc.vlab.cs.hioa.no/ofc/instructor.php) Ny instruktør: registrer ny instruktør, hver ny instruktør som blir lagt til legges i tabellen over. Vis: fungerer på den måten at man velger en instruktør fra tabellen som man vil hente ut informasjon fra. Rediger: velger en instruktør fra tabellen og klikker rediger for å redigere instruktøren, når man har redigert eller endret på noen av feltene, så avslutter man med å klikke oppdater. Slett: velger en instruktør fra tabellen og klikker slett. 116

Android applikasjonen For å kjøre Android applikasjonen må den først lastes ned og installeres på mobilen. Husk: man trenger Android versjon 4.0 og oppover for å kjøre applikasjonen, applikasjonen er ikke testet på tidligere Android versjoner. Hovedsiden Applikasjonen inneholder seks(syv) hovedsider. Disse er: 1. Logg inn 2. Hjem 3. Min trening 4. Instruktør 5. Trening og hendelser 6. Kurs 7. Utstyr 8. Om oss 9. Logg ut 117

Logg inn Man må ha et brukernavn og passord gitt ut av OFC for å kunne logge inn. vi har laget en testbruker med brukernavn: donald@duck.no og passord: Donald123. Figur 62 Logg inn (applikasjonen) 118

Hjem Figur 63 Hjem knapp i applikasjonen I denne siden så har man nyheter som er gitt ut av OFC. Her vises de siste nyhetene, antallet varierer etter hvor stor teksten er og skjermen på din telefon er. For å navigere rundt i applikasjonen, swiper du fingeren fra venstre side av skjermen til høyre side, eller klikker øverst til venstre på dette ikonet for å få opp menyen. Da vil du få opp denne menyen: Figur 64 Hjem (applikasjonen) Figur 65 Meyen i applikasjonen 119

Min Trening Figur 66 Min trening knapp i applikasjonen Under min trening vil det dukke opp treningene du har meld deg på, og de treningene du har vært på. For å melde deg på en trening klikker du på påmelding, velger deretter kurs og dag. Dette blir lagt til på kommende treninger som er under min trening siden. Figur 67 Min trening siden i applikasjonen 120

Instruktør Figur 68 Instruktørknappen i applikasjonen Her vil instruktørene listes med bilde og navn, klikker du på en av instruktørene vil det dukke opp mer informasjon om dem. Klikker man på select vil de dukke opp en kalender hvor du velger hvilken dag du ønsker en privat time og dette sendes som en mail til instruktøren. Figur 69 Instruktør siden i applikasjonen Figur 70 Popup vinduet etter å ha klikket på en instruktør 121

Trening og hendelser Figur 71 Trening og hendelses knapp Her listes ut treninger og hendelser. Klikker man på en av hendelsene så vil det dukke opp en dialog hvor du kan enten legge til i kalender eller fjerne (avhengig av om det ligger der fra før av). Man kan velge om å be applikasjonen påminne deg, og du kan legge til i min trening. Figur 72 Trening og hendelsessiden i applikasjonen 122

Kurs Figur 73 Kurs knappen I kurs vil man kunne se de ulike kursene som holdes i OFC. Klikker man på en av kursene vil man få mer informasjon om kurset. Figur 74 Kurssiden i applikasjonen Figur 75 Popup vindu etter klikk på et kurs 123

Utstyr Figur 76 Utstyrsknappen Her vil man kunne se de ulike utstyrene som selges i OFC sine lokaler. Klikker man på et av utstyrene vil man få en beskrivelse. Figur 77 Ustyrssiden Figur 78 Popup vindu etter klikk på et av utstyrene 124