Hovedprosjekt Gruppe 13

Transkript

1

2 PROSJEKT NUMMER Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Mobil billettapplikasjon i HTML5 PROSJEKTDELTAKERE Atle Fjellang Sæther (s161905) Gisle Bøhn Hagen (s161889) Ludvig Hummelvoll Hillestad (s161887) Alexander Bakke (s161864) DATO ANTALL SIDER / BILAG 98 / 4 INTERN VEILEDER Geir Skjevling Telefon: Telefaks: OPPDRAGSGIVER Intelecom Group AS KONTAKTPERSON Sven Ståle Osa SAMMENDRAG Prosjektet har resultert i en mobil billettapplikasjon i HTML5. Prosjektets formål har vært å avdekke om en applikasjon i HTML5 per i dag er et reelt alternativ til en applikasjon kodet i programmeringsspråk som f.eks. Objective C, Java eller.net, spesielt med tanke på utfordringer knyttet til åpne data og datasikkerhet. Applikasjonen ble utviklet på oppdrag fra Intelecom Group AS. 3 STIKKORD HTML5 PHP Mobilapplikasjon

3 Hovedprosjekt Gruppe 13 Forord Denne rapporten skal beskrive de forskjellige prosessene som inngår i arbeidet med hovedprosjektet ved Høgskolen i Oslo og Akershus, avdeling for ingeniørutdanning, våren Rapporten omhandler en mobil billettapplikasjon utviklet i HTML5, JavaScript, CSS og PHP. Oppgaven er gitt av Intelecom, som er en leverandør av kommunikasjonsløsninger til bedriftsmarkedet. Sluttrapporten er beregnet for sensor, veileder, oppdragsgiver, administrasjonen ved HIOA, samt andre som vil finne den interessant. Dokumentet er delt inn i fire deler: Prosessdokumentasjon - Dokumentasjon for oppdragsgiver, sensor(er), veileder. Produktdokumentasjon - Dokumentasjon for den som skal vedlikeholde og modifisere systemet Produkttesting - Dokumentasjon av tester utført på produktet Vedlegg - Kilder, brukerveiledning, prosjektbeskrivelse, planer, filstruktur og modeller Hver del kan leses som et selvstendig dokument. Produktrapporten er skrevet for de som skal overta systemet og det forventes derfor at leseren har grunnleggende kunnskap innen informasjonsteknologi. Prosessrapporten inneholder bakgrunnsinformasjon om prosjektet og skal derfor kunne leses av alle interesserte. Dette dokumentet er optimalisert for papir. Vi vil rette en stor takk til vår kontaktperson for Intelecom Group AS, Sven Ståle Osa for et godt samarbeid gjennom prosjektprosessen.

4 Del 1: prosessdokumentasjon ~ 1 ~

5 1 Forord Denne rapporten tar for seg prosessen vi har vært igjennom i løpet av prosjektet. Dokumentet viser hvordan vi har jobbet, hvilke utviklingsmetoder vi har benyttet oss av, prosjektets rammebetingelser og krav, utviklingsverktøy, utfordringer og problemer, samt beskrivelse av hvordan vi har løst disse. Rapporten er i hovedsak skrevet for oppdragsgiver, sensor(er), veileder, men også andre interessenter. Rapporten består av flere kapitler. For å få en helhetlig forståelse bør rapporten leses fra start til slutt. ~ 2 ~

6 2 Innholdsfortegnelse 1 Forord Innledning Om gruppa Om oppdragsgiver Bakgrunn «Native» applikasjoner Hybride applikasjoner Dedikert mobil web applikasjon Generisk mobil applikasjoner Sammenligning Nytt i html 5 og CSS QR kode Baksystemer Trafikanten API Intelecom API Situasjonen i dag Mål med oppgaven Rammebetingelser Brukergrensesnitt Telefonens funksjoner Lokal lagring og HTML5 Manifest Sikkerhet Tilpassning av rammebetingelser Aksessering uten nettilgang RSS feed for avviksinformasjon Planlegging og metode Fremdriftsplan Arbeidsplan Milepælsplan Kommunikasjon med oppdragsgiver Utviklingsmetode Testing Verktøy ~ 3 ~

7 7.1 Utviklingsverktøy Notepad++ og phpdesigner FileZilla Firebug Poster Prosessverktøy Facebook Dropbox Gmail Microsoft Office Word Adobe Photoshop CS Gliffy Resultat Kilder ~ 4 ~

8 3 Innledning 3.1 Om gruppa Prosjektgruppen består av fire studenter fra Anvendt Datateknologi ved HIOA bestående av Ludvig Hummelvoll Hillestad, Alexander Bakke, Gisle Bøhn Hagen og Atle Fjellang Sæther. Gruppen har jobbet sammen ved flere tidligere anledninger og kjenner derfor hverandre godt fra før. Gruppemedlemmene kjenner hverandres styrker og svakheter, noe som har gitt oss en fordel ved fordeling av arbeidsoppgaver. 3.2 Om oppdragsgiver Intelecom er en av landets ledende leverandører innenfor utvikling, integrasjon, levering og sammensetning av kommunikasjonsløsninger til bedriftsmarkedet. Intelecom Group AS har datterselskaper i Danmark, Sverige, Storbritannia og Norge, mens de i Norge har åtte avdelinger i henholdsvis Oslo, Kristiansand, Arendal, Stavanger, Haugesund, Bergen, Trondheim og Tromsø. (Intelecom, 2010) Intelecom har også implementert løsninger på mobil innenfor transportsegmentet. De har blant annet levert NSBs nye billettapplikasjon for smarttelefoner. (Intelecom, 2012) 3.3 Bakgrunn Applikasjonsutvikling kan deles opp i fire hovedkategorier bestående av «native», hybride, dedikerte, og generiske applikasjoner. Nedenfor følger en forklaring på hver av kategoriene «Native» applikasjoner Denne kategorien består av applikasjoner utviklet med et spesifikt programmeringsspråk (f.eks. Objective C for iphone, Java for Android og.net for Windows Phone). Disse applikasjonene er raske, stabile og føles som en naturlig del av telefonen med tanke på brukeropplevelse. Det er denne kategorien som i dag er mest utbredt i applikasjonsutvikling. Ulempen med denne type utvikling er at det må utvikles en applikasjon i sin helhet for hvert enkelt av operativsystemene applikasjonen skal benyttes på. Det fører igjen til at bedrifter som arbeider med utvikling må ivareta kompetanse på mange ulike programmeringsspråk og rammeverk. For å få tak i applikasjonen må brukeren som regel finne og laste ned denne via en «app store», som er en markedsplass for applikasjoner. Dette byr på utfordringer knyttet til distribusjon for bedrifter som trenger applikasjonen til en lukket brukergruppe (som f.eks. internt i et helseforetak). Slike applikasjoner må også for enkelte av operativsystemene, som ios og Windows Phone, godkjennes av operativsystemets produsent før de blir tilgjengelige for nedlastning. ~ 5 ~

9 3.3.2 Hybride applikasjoner Hybride applikasjoner er utviklet via et tredjeparts rammeverk (som f.eks. PhoneGap, Sencha eller Titanium). Her benytter man seg av rammeverk og utviklingsmiljøer fra leverandører hvor man som regel koder utseendet til applikasjonen som en webside. Forskjellen er at man har mulighet til å legge en «native ramme» rundt applikasjonen og via den kalle på funksjoner som f.eks. kontaktliste, kamera, kalender og lignende. Ulempen er at en slik applikasjon gjerne vil ha en annerledes brukeropplevelse enn det som forventes når man laster ned en «native» applikasjon og den krever også at utvikleren har inngående kunnskap om de enkelte plattformene for å kunne utnytte telefonens funksjoner. På samme måte som «native» applikasjoner må de hybride applikasjonene gjennom en godkjenningsprosess før de blir tilgjengelige i en «app store» Dedikert mobil web applikasjon Applikasjonene i denne kategorien kjøres som en vanlig nettside på en ekstern server og tilgjengeliggjøres via mobilens nettleser. En dedikert mobil web applikasjon er skreddersydd for spesifikke operativsystemer eller telefontyper og vil ikke fungere for eldre mobile nettlesere. Ofte vil slike sider enten sperre ute de telefonene eller nettleserne som ikke støttes eller sende disse videre til en egen side tilpasset slike terminaler. Fordelen med en mobil web applikasjon er at man ikke trenger å kunne alle de ulike programmeringsspråkene og rammeverkene som er nødvendige for å utvikle en «native» applikasjon. Det er ikke mulig å distribuere slike applikasjoner via en «app store» fordi applikasjonen er et nettsted. Men dette gir i stedet en mulighet for enklere distribusjon for bedrifter med behov for lukkede brukergrupper (som f.eks. internt i et helseforetak). Rammeverk slik som jquery Mobile gjør det raskere og enklere å lage gode brukergrensesnitt på touch skjermer. En ulempe er derimot at tilgangen på telefonens hardware er svært begrenset per i dag. Det finnes muligheter for geolokasjon, men utover dette er det begrensede muligheter for å utnytte hardware knapper, kamera, kontaktlister og lignende. Det er ventet at dette skal bli langt bedre støttet i fremtiden Generisk mobil applikasjoner Dette er mobile nettsider som skal fungere på enhver mobil enhet med en nettleser. Per i dag består dette av svært tradisjonelle mobile nettsider for å vise informasjon og kan derfor knapt kalles en mobil applikasjon. ~ 6 ~

10 3.3.5 Sammenligning Figur 1 - Sammenlikning av ulike metoder for utvikling av mobile applikasjoner (Kilde: Worklight) Figur 1 viser en oversikt over i hvilken grad funksjoner er tilgjengelig innen de tre mest brukte metodene for utvikling av applikasjoner i dag, bestående av «native», hybride og dedikerte web applikasjoner. (Strandskogen, 2011) Vår applikasjon skal inngå i kategorien dedikert mobil web applikasjon. 3.4 Nytt i html 5 og CSS3 I HTML5, som er siste revisjon av HTML-standarden, innføres det en rekke nye elementer og funksjoner som gjør det lettere for utviklere å publisere på nett. Noen nyvinninger i HTML5 er: Innebygget støtte for lyd og video HTML5 innfører to nye elementer, video og audio, for avspilling av bilde og lyd. Bedre webskjema Tilgang på nye funksjoner som tilgjengeliggjør datovelger, interaktiv meny og validering av gyldig e-postadresse. Lokal lagring HTML5 spesifiserer en standard for lokal lagring av data hos brukeren. Tidligere har det kun vært mulig å lagre små informasjonskapsler kalt cookies. Nå er det mulig å lagre noe større datamengder. Canvas Muligheten for å definere et tegneområde med det nye CANVAS -elementet er en av de delene av HTML5-standarden som er best implementert foreløpig. Det er også den delen av standarden hvor vi kan regne med at det vil skje minst endringer før den endelige standarden foreligger. ~ 7 ~

11 Dokumentstruktur HTML5 har en rekke nye elementer for å strukturere websiden som f.eks ARTICLE, SECTION, HEADER, NAV, FOOTER og ASIDE. Disse er ment å erstatte den utbredte bruken av DIV elementet som vi finner på dagens websider. Et eksempel på dette vises i Figur 2 og Figur 3. (NRK, 2010) Figuren nedenfor (Figur 2) viser to nettsider med samme utseende. Siden til venstre er kodet i HTML4.01 STRICT, mens siden til høyre er kodet i HTML5. Figur 2 - Sammenligning av HTML4.01 STRICT (til venstre) og HTML5 Selv om sidene ser ut som om de er like, er kildekodene på de to sidene svært forskjellige. Figuren nedenfor (Figur 3) illustrerer mengden med kode som skal til for å generere sidene i de to HTML versjonene. HTML5 sidens kildekode er flere linjer kortere enn den tidligere revisjonen av HTML, HTML 4.01 STRICT. (Sharp, 2010) ~ 8 ~

12 Figur 3 - Sammenligning av HTML4.01 STRICT (til venstre) og HTML5 - koder CSS3 CSS (Cascading Style Sheet) er et språk som brukes til å definere utseende på filer skrevet i HTML. Nyvinninger i CSS3 er: Gjennomsiktige elementer Rotering av bilder Fargegradering Skyggeeffekter på skrift og elementer Animasjoner (Canvas) Avrundede hjørner (NRK, 2010) ~ 9 ~

13 3.5 QR kode I applikasjonen ble billettene vist som en QR- kode (Quick Response - kode). Billetten skulle kunne skannes av en kontrollør, som straks ville se om billetten er gyldig eller ikke. En QR- kode er en todimensjonal strekkode. I strekkoden kan det lagres alt fra tall til japanske bokstaver som hvem som helst kan lese ut med kameraet på en smarttelefon. (Rockberry, 2011) 3.6 Baksystemer Figur 4 - QR- kode API (Application Programming Interface) er et grensesnitt for kommunikasjon mellom programvare. Et API fungerer som en regelbok for forespørsler til applikasjonen. (Wikipedia, 2012) Trafikanten API Alle data i applikasjonen som har med trafikkinformasjon kom fra Trafikantens API. Gruppen benyttet Trafikantens API til å skrive ut resultatet av brukerens stasjonssøk, samt informasjon som ruteforslag, stasjoner i nærheten, reisetid og transportmiddel Intelecom API Oppgradsgiver opprettet et API som skulle brukes til å lagre kundedata, billettbestillinger og selve billettene. 3.7 Situasjonen i dag Per i dag utvikles de aller fleste mobilapplikasjonene «native». Denne metoden er både tidsog ressurskrevende fordi det må kodes en versjon for hver enkelt av plattformene hvor applikasjonen skal brukes. Prosjektgruppa skal derfor, på oppdrag fra Intelecom, finne ut om en dedikert mobil web applikasjon er et reelt alternativ til native utvikling. HTML5 er en standard som fremdeles er under utvikling. Den inneholder mange nye funksjoner som tilbyr blant annet lokal lagring, «offline» aksessering av data og element tager for nytt og forbedret utseende. Ved hjelp av disse funksjonene skal gruppen i løpet av prosjektperioden finne ut om HTML5 er et reelt alternativ til «native» koding, spesielt med tanke på sikkerhet. (Wikipedia, 2012) ~ 10 ~

14 3.8 Mål med oppgaven Målet med oppgaven var å utvikle en prototype av en dedikert mobil billettapplikasjon ved hjelp av HTML5, CSS3, PHP og JavaScript. (Intelecom, 2012) Resultatmål Utvikle en prototype på en mobil billettapplikasjon i HTML5. Prototype og dokumentasjon skal leveres 30. mai 2012 til arbeidsgiver og HIOA Billetter skal krypteres og lagres lokalt Nærmeste fem stasjoner skal skrives ut ved hjelp av geolokasjon Vise billetter i frakoblet modus Holde arbeidsgivers tidsfrister og krav Effektmål Økt kunnskap om webapplikasjonsutvikling og tilhørende rammeverk som jquery Lære å samarbeide med en profesjonell aktør 4 Rammebetingelser Oppdragsgiver ønsket at applikasjonen skulle inneholde: En side for registrering av fornavn, etternavn, e-post og passord En side med innstillinger som lar brukeren administrere valg knyttet til applikasjonen (informasjon om bruker og applikasjon, samt slette bruker) Mulighet til å finne og kjøpe en bestemt reise. Billetten skal vises som en QR- kode. Vise kjøpte billetter Applikasjonen skulle fungere på følgende plattformer: ios (iphone / ipad) OS versjon 4 og nyere Android OS versjon 2.2 og nyere Windows Phone 7 Versjon 7.5 (Mango) og nyere Applikasjonen skal ha spesielt fokus på fire områder som anses som utfordringer i en dedikert web applikasjon: Brukergrensesnitt Telefonens funksjoner Lokal lagring Sikkerhet Nedenfor følger mer informasjon om disse områdene. (Se vedlegg X) ~ 11 ~

15 4.1 Brukergrensesnitt Applikasjonen skal ha et brukergrensesnitt som fungerer godt for de tre primære plattformene som er utbredt i Norge: ios (iphone og ipad), Android og Windows Phone 7. Ved hjelp av Java biblioteket jquery Mobile skal det vises hvilke muligheter en dedikert web applikasjon har for å gjøre tilpasninger til operativsystemet som brukeren kommer fra. Spesielt med tanke på generell «look and feel» eller spesifikke kontrollere, som for eksempel egne datovelgere for de ulike operativsystemene. 4.2 Telefonens funksjoner I Applikasjonen, hvor brukeren velger avreisestasjon, skal det implementeres geolokasjon. Geolokasjon er en funksjon som tar for seg mobiltelefonens geografiske posisjon ved hjelp av et JavaScript bibliotek. Dette gjøres ved å finne mobilens koordinater ved hjelp av WIFI signaler. Med utgangspunkt i disse koordinatene skal gruppen benytte Trafikantens API og finne de fem holdeplassene som er nærmeste brukerens posisjon. 4.3 Lokal lagring og HTML5 Manifest For en billettapplikasjon er det kritisk at bruker har tilgang til visse deler av innholdet, spesielt billetten, om man befinner seg på steder uten mobil dekning. Med lokal lagring er det mulig å lagre billetter, bruker- og reiseinformasjon i telefonens nettleser, samt hente det ut igjen. Det skal ikke være mulig å kjøpe nye billetter uten nettilgang, men allerede kjøpte billetter skal kunne vises. Oppdragsgiver ville ha HTML5 Manifest implementert i applikasjonen slik at det skulle være mulig å se kritiske data (billettene) i frakoblet modus. Manifest gjør at sider kan aksesseres uten nettilgang. (Wikipedia, 2012) 4.4 Sikkerhet Applikasjonen skal benytte seg av lokal lagring. Innholdet i denne databasen skal være sikret på en slik måte at det ikke er rett frem å hente ut innholdet og derfor må billettene krypteres før de lagres. JavaScript kodene skal obfuskeres(gjøres uleselig) slik at kildekodene ikke kan leses av andre. ~ 12 ~

16 5 Tilpassning av rammebetingelser Det viste seg etter hvert at det var mer å sette seg inn i enn det gruppen i utgangspunktet hadde trodd og at det dermed ikke var nok tid til å innfri alle oppgavene som ble gitt av oppdragsgiver. Det ble derfor nødvendig å gjøre tilpassninger av oppgaven. Nedenfor følger en forklaring på disse tilpassningene. 5.1 Aksessering uten nettilgang HTML5 manifest, som gjør at deler av applikasjonens sider lagres lokalt på brukerens telefon, skulle benyttes. Prosjektgruppen prøvde å bruke denne funksjonen på skolens server, men innstillinger og regler på skolens nettverk hindret lagring av sider. Etter å ha brukt mye tid på å få applikasjonens kritiske deler til å fungere uten nettilgang ble det derfor bestemt at andre funksjoner var viktigere å prioritere og at gruppen måtte gå bort fra kravet om HTML5 Manifest. 5.2 RSS feed for avviksinformasjon RSS feed var i utgangspunktet utenfor prosjektets rammer, men gruppen ønsket å lære mer om denne typen kommunikasjon og valgte derfor å implementere det i applikasjonen. Prosjektgruppen valgte å benytte seg av Trafikantens offentlige RSS feed (Really Simple Syndication) som nyheter eller materiale fra Internet fortløpende og automatisk. Trafikantens RSS tilbyr daglig oppdaterte meldinger om avviksinformasjon om kollektivtransporttilbudet på Østlandet. 6 Planlegging og metode 6.1 Fremdriftsplan Fremdriftsplanen ble laget for å holde oversikt over arbeidsoppgaver og tidsfrister. Det var viktig å lage en fremdriftsplan med realistiske tidsfrister, spesielt fordi gruppen ikke hadde så mye erfaring med så store prosjekter. Planen ble delt opp i tre deler, bestående av aktiviteter, møter og milepæler. Den ble kontinuerlig fulgt opp for å ha en oversikt over hvor mye tid som var igjen innen hver aktivitet. Planen ble oppdatert ofte for å opprettholde fremgangen i prosjektet. (Difi, 2010) For fremdriftsplan, se vedlegg 1 A. 6.2 Arbeidsplan Arbeidsplanen ble laget for å beskrive ansvarsfordelingen av oppgaver gjennom prosjektperioden og gi gruppens medlemmer en oversikt over hva de andre gruppemedlemmene arbeidet med. Applikasjonen inneholder så mange separate funksjoner at arbeidsplanen var svært viktig for utførelsen av prosjektet. Arbeidsplanen har blitt kontinuerlig oppdatert gjennom hele prosjektet. Oppgavene ble fordelt slik at hver og en hadde hovedansvaret for gjennomføringen av hver sin del av oppgaven. (Utdanningsforbundet) ~ 13 ~

17 For arbeidsplan, se vedlegg 1 B. 6.3 Milepælsplan For å ha en oversikt over milepælene i prosjektet ble det laget en milepælsplan. Milepælsplanen beskrev gruppens interne mål for prosjektet. Gruppen valgte å dele opp prosjektet i fem hovedmilepæler. Disse inneholdt blant annet tidsfrister for ferdigstillelse av funksjonalitet, fullført implementering og rapportskrivning. Milepælsplanen ble brukt svært ofte i gruppens daglige møter for å ha en oversikt over fremgangen i forhold til de interne fristene gruppen hadde satt. Planen var et fint redskap for gruppen. Noen av gruppens frister måtte flyttes underveis i prosjektet. Det skyldtes enten feil estimering av tid på aktiviteten eller innleveringer i semesterets andre fag. (Difi, 2011) For fullstendig milepælsplan, se vedlegg 1 C. 6.4 Kommunikasjon med oppdragsgiver Figur 5 - Milepælsplan Prosjektgruppen og oppdragsgiver hadde jevnlig kontakt helt fra starten av prosjektet. I tillegg til e-postkorrespondanse ble det holdt møter mellom representanter fra oppdragsgiveren og prosjektgruppen. Møtene ble brukt til å vise hva som hadde blitt gjort og hvilke utfordringer gruppen sto ovenfor. Oppdragsgiver innehar mye kompetanse på de feltene gruppen sto fast, og kunne derfor tilby hjelp og veiledning de gangene det var behov for det. Gruppen opprettet en egen e-post bruker hos Gmail for å forenkle kommunikasjonen med oppdragsgiver. Samarbeidet bygget på tillit ved at gruppen tok kontakt om de sto fast eller trengte faglig veiledning. Dette samarbeidet fungerte godt og ga gruppen rom til selv å styre egne interne frister og arbeidstider. ~ 14 ~

18 6.5 Utviklingsmetode Vi bestemte oss tidlig i prosjektet for at vi ønsket å bruke en iterativ utviklingsmetode, som betyr at det hele tiden arbeides med å videreutvikle forrige versjon fremfor å forkaste og starte forfra. Vi valgte derfor å bruke en tilpasset versjon av utviklingsrammeverket Scrum. Dette rammeverket brukes ofte der utvikling av komplekse informasjonssystemer står i sentrum. Modellen baserer seg på faser med lengde fra en uke og helt opp til en måned. Hver fase kalles en sprint. For hver sprint blir det satt krav til hva som skal implementeres i løpet av perioden slik at man har klare mål til neste sprint skal påbegynnes. Prosjektgruppen gjennomførte daglige møter slik at hver og en fikk en oversikt over hvordan det gikk med de forskjellige arbeidsmålene. Samtidig ga dette gruppemedlemmene en mulighet til å ta opp problemer og utfordringer som krevde en samlet avgjørelse. Gruppa utnevnte en Scrum Master før hvert møte som skulle fungere som en ordstyrer og sørge for at alle på gruppa besvarte tre viktige spørsmål: Hva var gjort siden forrige Scrum møte? Hva skulle gjøres før neste møte? Hva hadde (eventuelt) vært til hinder for at gruppemedlemmet var effektivt i implementeringen av funksjonalitet? (Wikipedia, 2012) Det var tidlig klart at programmeringsdelen av prosjektet var stor. Gruppen ble gitt en konkret kravspesifikasjon med mange funksjoner prosjektgruppen ikke hadde kjennskap til fra før. Vi valgte derfor og ikke å bruke så mye tid på UML modellering verken i starten eller i prosjektet forøvrig. Vi hadde en konkret plan alle gruppemedlemmene var inneforstått med og kunne raskt fordele og begynne på programmeringen. E/R modellering er også naturlig utelatt fordi det ikke skal opprettes en database i løpet av prosjektet. 6.6 Testing Tester på applikasjonen ble utført fortløpende slik at man kunne sikret at det som hadde blitt utviklet fungerte slik det skulle på alle plattformene. Det ble gjort tester på forskjellige mobile enheter slik at man kunne se hvordan applikasjonen ble seende ut på ulike skjermstørrelser. Applikasjonen skulle kunne fungere på plattformene som var spesifisert i rammebetingelsene og det var derfor viktig at testingen ble utført på telefoner med Android, ios og Windows operativsystem. Ved å utføre disse testene avdekket gruppen feil og mangler i applikasjonen som måtte ordnes. ~ 15 ~

19 7 Verktøy Fra prosjektets start i januar til prosjektets slutt i mai benyttet gruppen seg av ulike verktøy for utvikling, dokumentasjon og planlegging. Oppdragsgiver hadde ingen ønsker eller krav til hvilke verktøy som skulle brukes. Prosjektgruppen valgte derfor utviklingsverktøy de kjente til fra før. 7.1 Utviklingsverktøy Nedenfor følger en kort beskrivelse av de verktøy prosjektgruppen har benyttet seg av Notepad++ og phpdesigner 7 Både Notepad++ og phpdesigner 7 er PHP-, HTML-, CSS- og JavaScripteditorer som er laget for å forenkle programvareutviklingen for programmerere. phpdesigner 7 er et praktisk utviklingsverktøy som inneholder hjelpefunksjoner som f.eks. autocomplete og tekstfarge ut ifra hvilken datatype teksten er. Programmet kan håndtere flere dokumenter samtidig ved å plassere de i faner. Øverste delen av programmet inneholder verktøylinjer med funksjoner for testing, analyse og utvikling. Figur 6 - Skjermdump av phpdesigner 7 ~ 16 ~

20 Notepad++ er bygget opp på samme måte som phpdesigner 7. Øverste delen av programmet består av verktøylinjer med forskjellige utviklingsverktøy. Også Notepad++ kan håndtere flere dokumenter samtidig. Ved hjelp av faner, vil det til enhver tid være et ryddig skjermbilde. Figur 7 - Skjermdump av Notepad++ Det at programmene var såpass like gjorde at gruppen ikke ville ha noe krav til valg av utviklingsverktøy. Det ble derfor opp til hvert enkelt gruppemedlem å benytte seg av det verktøyet de foretrakk. ~ 17 ~

21 7.1.2 FileZilla FileZilla er en FTP- klient som ble benyttet til publisering av applikasjonen på Internet. Programmet ble brukt til å overføre applikasjonens filer fra gruppemedlemmets datamaskin til skolens webserver. Figur 8 viser et skjermdump av FileZilla. Til venstre i skjermbildet vises filtreet til datamaskinen programmet er installert, mens høyre side viser filene som ligger på gruppemedlemmets område på skolens webserver. Øverst i bildet må brukeren logge inn på serveren for å kunne begynne overføringen. Figur 8 - Skjermdump av FileZilla ~ 18 ~

22 7.1.3 Firebug Firebug er et webutviklingsverktøy installert som et programtillegg i nettleseren. Programmet lot gruppen feilsøke kildekode fortløpende. Kildekodene kunne endres i nettleseren, for så å se hvordan ting ble endret før kodene ble endret lokalt. Dette sparte gruppen for mye tid som ville blitt brukt om filene måtte lastes opp hver gang de skulle testes. (Firebug) Figuren nedenfor (figur 9) viser hvordan sidens kildekode kan vises i Firebug. Disse kodene kan endres og endringene vil straks vises på siden. Figur 9 - Skjermdump av Firebug ~ 19 ~

23 Firebug inneholder også en JavaScript konsoll (figur 10) som viser feil i koden som kjøres. Denne funksjonen har gruppen benyttet seg av mye gjennom prosjektet. JavaScript gir ofte ingen eller dårlige feilmeldinger, så et slikt utviklingsverktøy forenkler feilsøkingsjobben svært mye for utvikleren. Figur 10 - Skjermdump av konsollen i Firebug ~ 20 ~

24 7.1.4 Poster Poster ble brukt i starten av prosjektet til å se om det var mulig å koble seg opp mot oppdragsgivers API og se at alt fungerte slik det skulle. Poster er et programtillegg i Firefox som er laget for å kunne kommunisere med webtjenester. Det kan blant annet simulere en HTTP forespørsel mot et API (Figur 11) og vise resultatet av spørringen (Figur 12). (Mozilla) Figur 11 - Poster - Forespørsel mot API ~ 21 ~

25 Figur 12 - Poster - Kvittering 7.2 Prosessverktøy Nedenfor følger en kort beskrivelse av de prosessverktøy prosjektgruppen har benyttet seg av i løpet av prosjektperioden Facebook På Facebook ble det opprettet en hemmelig gruppe slik at kun gruppens medlemmer hadde tilgang til informasjonen som ble lagt ut. Der ble det utvekslet informasjon om tidspunkter og oppmøtesteder relatert til prosjektet, som f.eks. møter med oppdragsgiver eller veileder. Gruppen ble også benyttet til utveksling av korte koder og dokumentasjon. Denne gruppen fungerte samtidig som et kommunikasjonsverktøy de tidene gruppen ikke arbeidet sammen på skolen. ~ 22 ~

26 7.2.2 Dropbox Dropbox er programmet gruppen brukte til å synkronisere filer mellom flere datamaskiner. I stedet for å sende filer til seg selv med e-post eller bære det med seg på en minnepenn legges filene på en ekstern server hele gruppen har tilgang til. Gruppen brukte Dropbox til deling av bilder, dokumenter, kildekoder og notater. Programmet ble brukt til daglig sikkerhetskopiering av koder og dokumenter og ga gruppen mulighet til å gå tilbake til tidligere versjoner om det var behov for det. Spesielt i situasjoner hvor det ble problemer med kodene var det nyttig å kunne gå tilbake til tidligere sikkerhetskopier som fungerte Gmail For at hele gruppen skulle ha tilgang til all informasjon og alle avtaler med oppdragsgiver, veileder og andre involverte i prosjektet ble det opprettet en e- post bruker hos Gmail. Gruppen ble enig om et passord slik at all e-post var tilgjengelig for de som trengte tilgang. Denne e-post brukeren var spesielt praktisk ved prosjektstart fordi oppdragsgiver ga informasjon om hvordan baksystemet var bygget opp Microsoft Office Word Microsoft Office Word er et tekstbehandlingsprogram som ble brukt til å skrive dokumentasjon som prosjektrapporten, møtereferater og dagbok Adobe Photoshop CS3 Adobe Photoshop CS3 er et bilderedigeringsprogram. Det ble brukt til å designe og utforme elementer som knapper, ikoner og bilder som skulle brukes i applikasjonen Gliffy Gliffy er et nettbasert verktøy som gjør det mulig å lage diagrammer, flytskjemaer og tegninger. Det ble brukt i prosjektet som et verktøy for å lage UML diagrammer som use case og Aktivitetsdiagram. (Gliffy) ~ 23 ~

27 8 Resultat Gruppen er fornøyd med resultatet av prosjektet. Arbeidet har vært utfordrende og spennende og resultert i en dedikert mobil web applikasjon i HTML5. Prosjektet har vært lærerikt både med tanke på de faglige utfordringene knyttet til selve utviklingen av produktet, men også samarbeidsprosessen med oppdragsgiver. Det er første gang gruppen har utført et reelt oppdrag gitt av en ekstern bedrift, noe som har gitt gruppen verdifull erfaring. Oppdragsgiver har gjennom hele prosjektet gitt konstruktive tilbakemeldinger på produktet og vært behjelpelig om gruppen har ønsket faglig veiledning. Prosjektet har resultert i økt kompetanse for gruppen. Utførelsen av prosjektet krevde at gruppen måtte sette seg inn i nye funksjoner og rammeverk som f.eks. json, jquery, lokal lagring, geolokasjon og programmering mot API. Gruppen hadde kjennskap til programmeringsspråkene som ble benyttet i applikasjonen fra tidligere, men prosjektet har gitt større innsikt i mulighetene knyttet til denne typen programmering. Gruppen har tilegnet seg faglig kunnskap om webapplikasjonsutvikling som vil være nyttig å ta med seg videre ut i arbeidslivet. ~ 24 ~

28 9 Kilder Difi. (2010, 12 16). Retrieved 2012, from Difi. (2011, 12 01). Retrieved from Firebug. (n.d.). getfirebug.com. Retrieved 2012, from Gliffy. (n.d.). gliffy.com. Retrieved 2012, from html5media. (n.d.). html5media.info. Retrieved 2012, from Intelecom. (2012, 02 02). Intelecom nsb mobilapplikasjon. Retrieved 2012, from Intelecom. (2010, 03 25). Nettside om Intelecom. Retrieved 2012, from Intelecom. (2012, 01 23). Prosjektbeskrivelse. Oslo: Intelecom. Mozilla. (n.d.). addons.mozilla.org. Retrieved 2012, from US/firefox/addon/poster/ NRK. (2010). nrkbeta.no. Retrieved 2012, from Rockberry. (2011, 06 23). Retrieved 2012, from Sharp, R. L. (2010). Introducing HTML5. New Riders forlag. Strandskogen, N. K. (2011, 03 22). iallenkelhet.no. Retrieved 2012, from Utdanningsforbundet. (n.d.). Retrieved 2012, from Wikipedia. (2012, 03 12). en.wikipedia.org. Retrieved 2012, from Wikipedia. (2012, 04 09). no.wikipedia.org. Retrieved 2012, from Wikipedia. (2012, 05 18). no.wikipedia.org. Retrieved 2012, from Wikipedia. (2012, 05 14). no.wikipedia.org. Retrieved 2012, from ~ 25 ~

29 Del 2: Produktdokumentasjon ~ 1 ~

30 1 Forord Dette dokumentet er en produktrapport for en mobil billettapplikasjon i HTML5. Rapporten skal redegjøre for applikasjonens funksjonalitet, virkemåte og tekniske oppbygning. Rapporten er skrevet for den som skal vedlikeholde og modifisere systemet og det forutsettes derfor at leseren har grunnleggende forståelse innen informasjonsteknologi. ~ 2 ~

31 Innholdsfortegnelse 1 Forord Innledning Hensikt med prosjektet Kort beskrivelse av resultat Presentasjon av applikasjonen Applikasjonens hoveddeler Hovedsiden Ny reise Innstillinger Registrering Trafikkinformasjon Applikasjonens brukergrensesnitt Skalering Ikoner Plassering Farger Teknologi Utviklingsmiljø jquery Mobile json HTML PHP JavaScript Tilpassninger for ios Ikon på skrivebordet Skjule adresselinje Tall tolkes som telefonnummer Baksystemer Oppdragsgivers API /authenticationtoken (POST) /purchase (POST) /orders/{authenticationtoken} (GET) /ticket/{orderid}?authenticationtoken={authenticationtoken} (GET) ~ 3 ~

32 6.2 Trafikantens API /Place/GetClosestStopsByCoordinates/?coordinates=(X={X},Y={Y})&proposals= /Travel/GetTravelsAfter?time={time}&from={fromStopID}&to={toStopID} Funksjonalitet Geolokasjon Lokal lagring Operativsystem detektor Input validering RSS feed for avviksinformasjon Sjekke om det allerede eksisterer en bruker Url_safe Datovelgere ios Android Windows Phone Sikkerhet Obfuskere kildekode Sikkerhet gjennom hemmelighold Lokal lagring Utfordringer Geolokasjon QR- kode Kommunikasjon med API Unngå søk på område Tidsformat Håndtering av feilmeldinger Tegnsett Kilder ~ 4 ~

33 3 Innledning 3.1 Hensikt med prosjektet Prosjektets formål er å avdekke om HTML5 per i dag er et reelt alternativ til «native» applikasjoner på mobil. Spesielt knyttet til åpne data, betaling, datasikkerhet, lagring på enhet og raske brukergrensesnitt. HTML5 og underliggende spesifikasjoner som CSS3 ser ut til å bli spesifikasjonen som de fleste aktørene kommer til å benytte seg av i fremtiden. Oppdragsgiver har ikke hatt ressurser til å gjøre konkret arbeid på disse spesifikasjonene og gruppen har derfor fått som oppgave å lage en prototype av en mobil billettløsning basert på HTML Kort beskrivelse av resultat Prosjektet resulterte i en fungerende prototype utviklet som en dedikert web billettapplikasjon. Applikasjonen kan brukes til å kjøpe billetter, se avviksinformasjon, samt vise kjøpte billetter. I prototypen ble det implementert lokal lagring, geolokasjon og tilpassninger for hver enkelt plattform (som f.eks. datovelgere). HTML5, CSS3, JavaScript, jquery mobile og PHP ble sammen benyttet for å utvikle produktet. ~ 5 ~

34 4 Presentasjon av applikasjonen 4.1 Applikasjonens hoveddeler Nedenfor følger en presentasjon av applikasjonens hoveddeler. Figur 1 - Strukturkart ~ 6 ~

35 4.1.1 Hovedsiden Applikasjonens hovedside(figur 2) består av fire knapper plassert midt på siden. Knappene lar brukeren navigere rundt i applikasjonen slik at det er mulig å kjøpe billetter, se kjøpshistorikk, forandre på innstillinger og se trafikkinformasjon. For å kunne bruke applikasjonen må en bruker være registrert på den aktuelle telefonen. Er det ingen registrerte brukere, blir brukeren automatisk sendt fra hovedsiden til et registreringsskjema hvor en bruker må registreres. Om det allerede er registrert en bruker vil hovedsiden være første siden som vises. Figur 2 - Applikasjonens hovedside For utvidet brukerveiledning og skjermbilder, se vedlegg 3. ~ 7 ~

36 4.1.2 Ny reise I denne delen må brukeren velge avreise- og ankomststasjon, samt tidspunkt for avreise. På bakgrunn av disse valgene skrives det ut de fem nærmeste reiserutene i tid. Først må brukeren velge hvor reisen skal starte. Det er to måter å søke på en stasjon. Enten ved manuelt å skrive inn stasjonen og trykke søk, eller ved å trykke på knappen "I nærheten". Denne knappen skriver ut de fem nærmeste stoppestedene basert på brukerens geografiske lokasjon (geolokasjon). Etter å ha valgt avreisepunkt sendes brukeren videre til neste side hvor ankomststasjon må velges. Denne siden er lik som forrige, men uten "I nærheten" knappen. Her skrives det samtidig ut avreisestasjon slik at brukeren kan se hva som har blitt valgt så langt. Etter å ha valgt hvor brukeren skal reise fra og til, må det velges avreisetidspunkt. Dette gjøres i en datovelger spesielt tilpasset brukerens plattform. Det er implementert en datovelger for hver av plattformene (ios, Android og Windows Phone 7) applikasjonen skal fungere på. På bakgrunn av disse tre valgene (avreise- og ankomststasjon, samt tidspunkt) viser neste side de fem neste avgangene i tid. Her vises avreise- og ankomsttidspunkt, avreise- og ankomststasjon, reisetid, transportmiddel og eventuelt linjenavn. Om brukeren av en eller annen grunn har valgt feil, eller ønsker å endre noen av de valgene som har blitt gjort på foregående sider, er det en egen knapp hvor brukeren kan velge å begynne på nytt. Etter å ha valgt et av ruteforslagene blir brukeren sendt videre til neste side hvor billetten må bekreftes. Her blir alle valgene brukeren har gjort så langt, samt en pris på reisen presentert på siden. Brukerens passord må skrives inn for å bekrefte kjøpet. Når passordet er godkjent blir brukeren sendt til en ny side. Her vises en kvittering for kjøpet. Kunden kan her enten velge å trykke på hjem knappen og bli sendt til startsiden, eller "Mine billetter", som vil sende brukeren til listen over alle billetter som er kjøpt. Mine billetter viser en oversikt over alle billettene en bruker har kjøpt. Har ikke brukeren kjøpt noen billetter, men allikevel går inn på mine billetter vil man få beskjed om at kjøpshistorikken er tom og et ikon for ny reise vil vises slik at brukeren enkelt kan kjøpe en billett. Alle kjøpte billetter blir lagret i mine billetter automatisk. For at brukeren skulle ha oversikt over alle ordrene ble det lagt til informasjon om hver enkelt billett og om den er gyldig. Brukeren får se billetten ved å trykke på bildet av QR- koden. For use case diagram, tekstlig use case og aktivitetsdiagram, se vedlegg 2. ~ 8 ~

37 4.1.3 Innstillinger Under innstillinger (Figur 3) har brukeren tre valg. Se personalia og informasjon om applikasjonen, samt mulighet til å slette brukeren med tilhørende billetter. Profilsiden, som viser personalia, skriver ut navnet og e-post adressen brukeren registrerte seg med. Denne informasjonen blir automatisk skrevet ut av lokal lagring når siden lastes. Knappen "Slett bruker" gir mulighet til å slette seg selv. Dette gjør applikasjonen ved å fjerne all informasjon som er lagret lokalt. Tredje valget under innstillinger er "info". Her gis det en kort presentasjon av applikasjonen Registrering Figur 3 - Innstillinger Om det ikke allerede er registrert en bruker vil brukeren automatisk komme til denne siden. For å registrere seg må det oppgis fornavn, etternavn, e-post og passord. Etter at brukeren har bekreftet informasjonen som er skrevet inn, blir dette sendt til, og lagret, i oppdragsgivers API i tillegg til lokalt lagret. Oppdragsgivers API vil da returnere en unik tekststreng som skal være brukerens identifikasjon når billetter skal kjøpes Trafikkinformasjon Fjerde valg på applikasjonens hovedside er å se avvik i trafikken. Denne informasjonen blir hentet med RSS feed fra trafikantens nettsider og viser trafikkavvik for kollektivtransport på Østlandet. ~ 9 ~

38 4.2 Applikasjonens brukergrensesnitt Applikasjonens brukergrensesnitt skulle fungere på enheter med ulik skjermstørrelse, noe som gjorde brukervennlighet og plassering av elementer svært viktig. Den skulle kunne brukes av alle brukergrupper, og det var derfor viktig at den ikke inneholdt overflødige elementer eller unødvendig funksjonalitet. Nedenfor følger en kort forklaring på de viktigste bestanddelene i applikasjonens brukergrensesnitt Skalering Et av kravene som ble gitt til applikasjonen var at den skulle fungere på smarttelefoner med svært stor variasjon i skjermstørrelse (fra Sony Ericsson Xperia Mini til Samsung Galaxy). Applikasjonen ble derfor gitt en dynamisk design som tilpasser seg selv ut ifra skjermens størrelse og i hvilken retning telefonen holdes. Alle knappene ble definert med en prosentvis bredde, noe som gjorde at knappene tilpasset seg avhengig av skjermens størrelse (Figur 4 og 5). Figur 4 - Smal skjerm ~ 10 ~

39 4.2.2 Ikoner Figur 5 - Bred skjerm Applikasjonens ikoner (Figur 6) ble valgt med utgangspunkt i hva som skulle oppleves mest intuitivt for brukeren. I tillegg til forklarende bilder ble det lagt til tekst på ikonene som forklarte hvor brukeren sendes ved å trykke på ikonet Plassering Figur 6 - Applikasjonens ikoner Elementenes plassering var svært viktig i forhold til brukerens inntrykk av applikasjonen. Fordi det også er begrenset med plass på en mobilskjerm måtte sidene ikke inneholde flere elementer enn nødvendig. Gruppen valgte derfor å plassere en hjem knapp på venstre side av et felt i toppen av siden. Andre elementer som inputfelt og tekstlig informasjon ble sentrert for å gjøre sidene oversiktlige. ~ 11 ~

40 4.2.4 Farger I applikasjonen er det funksjonaliteten som skal trekke til seg brukerens oppmerksomhet. Det ble derfor valgt nøytrale farger med høy kontrast. Feltet i toppen av siden skulle designes med utgangspunkt i oppdragsgivers overordnede grafiske profil. Den fikk derfor fargen grønn, som ble hentet fra oppdragsgivers logo. 5 Teknologi 5.1 Utviklingsmiljø Applikasjonen ble utviklet ved hjelp av en kombinasjon av HTML5, CSS, PHP og JavaScript. Nedenfor følger en kort forklaring på de ulike programmeringsspråkene og rammeverkene som ble brukt under utviklingen av applikasjonen jquery Mobile jquery Mobile er et HTML5 basert grensesnitt som bygger på JavaScript biblioteket jquery. Biblioteket er utviklet for å forenkle klientskripting av HTML. jquery Mobile inneholder en rekke valg knyttet til en applikasjons design. Det kan enten velges et forhåndsdefinert tema eller det kan defineres en egen design. (jquerymobile) json Oppdragsgivers og Trafikantens API er REST like API, som definerer hvordan man adresserer og overfører ressurstilstander. For å adressere en ressurs brukes gjerne en URL. Begge programmeringsgrensesnittene benytter seg av json(javascript Object Notation) som er en enkel tekstbasert standard for datautveksling. Applikasjonen gjør spørringer mot de to APIene og mottar et svar i json som et array med objekter. (Bekk, 2009) HTML HTML (HyperText Markup Language) er et programmeringsspråk som brukes til å lage strukturen på en nettside. (Wikipedia, 2012) PHP PHP (PHP: Hypertext Preprocessor) er et programmeringsspråk som utføres på serversiden. (itpro.no, 2003) JavaScript JavaScript er mest kjent for å tilføre dynamiske elementer til nettsider. Kodene kjøres lokalt i nettleseren, automatisk eller som reaksjon på brukervalg på siden. (kodehjelp) ~ 12 ~

41 5.2 Tilpassninger for ios Applikasjonen inneholder noen tilpassninger spesielt for ios. Nedenfor følger en beskrivelse av disse tilpassningene Ikon på skrivebordet Figur 7 - Applikasjons ikon Den ene tilpassningen består av en kodelinje (nedenfor) som legger et ikon (Figur 7) på mobilens hjem- skjerm. For å benytte seg av denne muligheten må brukeren manuelt gå inn i nettleserens meny og velge "Legg til på Hjemskjerm". <link rel="apple-touch-icon" href="bilder/icon.png" /> Skjule adresselinje Brukeren må først legge applikasjonen på telefonens hjem- skjerm. Ved å legge til kodelinjene nedenfor vil ikke adresselinjen vises når applikasjonen aksesseres fra ikonet på hjem- skjermen. <meta name="apple-mobile-web-app-capable" content="yes" /> <meta name="apple-mobile-web-app-status-bar-style" content="default" /> <meta name="viewport" content="width=device-width; initial-scale=1.0; maximumscale=1.0; user-scalable=no" /> 5.2.3Tall tolkes som telefonnummer Kodelinjen nedenfor ble lagt til for å unngå at nettleseren automatisk tolker serier med tall som et telefonnummer. Applikasjonen inneholdt avreise- og ankomsttider, noe det ikke var ønskelig å vise som en link til et telefonnummer. <meta name="format-detection" content="telephone=no" /> ~ 13 ~

42 6 Baksystemer Figuren nedenfor (Figur 8) viser applikasjonens systemarkitektur. Her er oppdragsgivers og Trafikantens API tegnet inn som henholdsvis web tjenestelag og sanntidsdata. Den mobile klienten er ikke koblet direkte til tjenestelaget, men må gå gjennom skolens web server hvor applikasjonens filer er lagret. Baksystemene kan ikke kommunisere direkte med hverandre. Figur 8 - Systemarkitektur To APIer ble benyttet i applikasjonen. Det ene er utviklet av Trafikanten, mens det andre ble satt opp av gruppens oppdragsgiver i sammenheng med dette prosjektet. 6.1 Oppdragsgivers API Ligger bak: Støtter følgende tjenester: /authenticationtoken (POST) Oppretter en ny bruker og returnerer en token som kan brukes i kallene mot de andre tjenestene. Eksempel på inn-parametere: {firstname=ola&lastname=normann& =ola.normann@mail.com&password=test123} ~ 14 ~

43 6.1.2 /purchase (POST) For å kjøpe en ny billett. Returnerer en kvitteringsmelding. Eksempel på inn-parametere: {fromstop=nydalen&tostop=arendalsgaten&departuretime= T08:05:04Z&authenticationToken=574bf7c0-8ebe-4a f2e0074b85&password=test123} /orders/{authenticationtoken} (GET) For å liste ut alle ordrer knyttet til denne brukeren. Eksempel på inn-parametere: /orders/574bf7c0-8ebe-4a f2e0074b /ticket/{orderid}?authenticationtoken={authenticationtoken} (GET) Returnerer en billett. Eksempel på inn-parametere: /ticket/1?authenticationtoken=574bf7c0-8ebe-4a f2e0074b Trafikantens API Ligger bak: api-test.trafikanten.no/ Støtter blant annet følgende tjenester: /Place/GetClosestStopsByCoordinates/?coordinates=(X={X},Y={Y})&proposals=5 Returnerer fem nærmeste stoppestedene. Eksempel på inn-parametere: /Place/GetClosestStopsByCoordinates/?coordinates=(X=593918,Y= )&proposals= /Travel/GetTravelsAfter?time={time}&from={fromStopID}&to={toStopID} Returnerer de fem neste ruteforslagene i tid. Eksempel på inn-parametere: /Travel/GetTravelsAfter?time= &from= &to= ~ 15 ~

44 7 Funksjonalitet Applikasjonen inneholder mange funksjoner. Nedenfor følger en teknisk presentasjon med et utdrag kildekoder av applikasjonens viktigste funksjoner. 7.1 Geolokasjon Geolokasjon bruker koordinater til å vise brukerens geografiske posisjon. Funksjonen nedenfor (navigator.geolocation) ble brukt for å finne ut om brukerens nettleser støttet geolokasjon. if (navigator.geolocation) { navigator.geolocation.getcurrentposition(success, error); } else { error('geolokasjon støttes ikke av din nettleser.'); } Om geolokasjon ikke var støttet ble det skrevet ut en beskjed om dette. Finnes det støtte for dette i telefonens nettleser vil funksjonen forsøke å finne telefonens koordinater ved hjelp av funksjonen nedenfor. function success(position) { var testl = position.coords.latitude; var testb = position.coords.longitude; var kordinater = new LatLng(testl, testb); var utm = kordinater.toutmref(); del1 = utm.tostring().split(" ")[1]; kordl = del1.tostring().split(".")[0]; } del2 = utm.tostring().split(" ")[2]; kordb = del2.tostring().split(".")[0]; Her legges først lenge- og breddegrad i hver sin variabel (testl og testb) ved hjelp av to individuelle metoder (position.coords.latitude og position.coords.longitude). Deretter legges de to variablene sammen til en variabel (kordinater). Dette måtte gjøres fordi koordinatenes format måtte endres før det ble sendt til Trafikantens API. Funksjonen toutmref() bruker et eget JavaScript bibliotek kalt JScoord for å endre formatet. Denne funksjonen krever at begge koordinatene blir lagt inn i en variabel før de skal endres til UTM format. toutmref() returnerer lengde- og breddegrad som kommatall sammen i en tekststreng. Derfor måtte gruppen bruke funksjonen split() for igjen å separere ~ 16 ~

45 lenge- og breddegrader, samt fjerne alle tall etter komma. De ferdig formaterte koordinatene legges til slutt i hver sin variabel (kordl og kordb) Alle disse funksjonene blir kjørt automatisk når brukeren går inn på siden. Men det er først når brukeren trykker på "I nærheten" knappen at de nærmeste stasjonene blir skrevet ut. Koden nedenfor er det som blir utført når denne knappen trykkes på. function hent_data() { var X = kordl; var Y = kordb; var request = new XMLHttpRequest(); var url = "hentdata.php?x="+x+"&y="+y; request.open("get",url,false); request.onreadystatechange = function () { if (request.readystate == 4 && request.status == 200) { var resultat = JSON.parse(request.responseText); var utdata = ""; for(var i=0; i<resultat.length; i++) { utdata+="<a href='til.php?fromid="+resultat[i].id+"&fromname="+resultat[i].name+"' class='button'><div id='linjelink'>"+resultat[i].name+"</div></a><hr />"; } document.getelementbyid('utdata').innerhtml += utdata; } } request.send(null); } koordinatene blir gitt nye variabelnavn (X og Y) før de blir sendt til Trafikantens API gjennom en funksjon i filen "hentdata.php". Nedenfor er funksjonen som utfører spørringen mot Trafikantens API. <?php?> $url=" $_REQUEST["X"].",Y=".$_REQUEST["Y"].")&proposals=5"; $data=file_get_contents($url); echo utf8_decode($data); I denne funksjonen sendes lengde- og breddegrader inn til Trafikanten som returnerer de fem nærmeste holdeplassene med utgangspunkt i disse koordinatene. Deretter blir disse skrevet ut i variabelen $data. ~ 17 ~

46 7.2 Lokal lagring Funksjonen nedenfor (Tekstboks 1) benytter seg av en av de nye funksjonene i HTML5, lokal lagring. Funksjonen legger først inn nåværende tidspunkt i en variabel (itemld). Deretter ble det opprettet et array (values) hvor verdiene senere skulle legges inn. Variablene result, firstname, lastname og , tilegnes henholdsvis brukerens unike ID (AuthenticationToken), fornavn, etternavn og e-post adresse som er hentet fra skjemaet på forrige side i applikasjonen. Funksjonen push() er den neste som brukes. Denne funksjonen legger de fire variablene (result, firstname, lastname, ) inn i values. Til slutt legges values inn i nettleserens lokale database ved hjelp av metoden setitem. Gruppen valgte å legge inn verdiene etter hverandre med ";" mellom hver variabel for lettere å kunne dele opp verdiene når de skal hentes ut. $("#lokal_lagring").click(function() { var newdate = new Date(); var itemid = newdate.gettime(); var values = new Array(); var result ="<? var firstname = "<? print utf8_decode($_request["firstname"]);?>"; var lastname = "<? print utf8_decode($_request["lastname"]);?>"; var = "<? print $_REQUEST[" "];?>"; [...] }); values.push(result); values.push(firstname); values.push(lastname); values.push( ); try { localstorage.setitem(itemid, values.join(";")); } Tekstboks 1 ~ 18 ~

47 7.3 Operativsystem detektor Applikasjonen inneholder en datovelger for hver av plattformene den skal brukes på. Det ble laget en funksjon (Tekstboks 2) for å finne ut hvilken plattform brukeren benytter seg av og på bakgrunn av dette resultatet sende brukeren til riktig datovelger. $agent = $_SERVER['HTTP_USER_AGENT']; $osarray = array( 'Windows' => '(Win)', 'Linux' => '(X11) (Linux)', 'MacOS' => '(Mac)' ); foreach as $os => $v) { if (preg_match("/$v/", $agent)) { break; } else { $os = "Unknown OS"; } } Tekstboks 2 Funksjonen $_SERVER['HTTP_USER_AGENT'] ble brukt til å finne informasjon om brukerens nettleser og operativsystem. Den returnerer for en Android bruker med Firefox nettleser en tekststreng lik den nedenfor. Mozilla/4.5 [en] (X11; U; Linux i586) Deretter benyttet gruppen seg av funksjonen preg_match() for å sjekke den returnerte strengen for spesifikke tegn. Disse tegnene bestod av operativsystemnavn. Om tekststrengen for eksempel inneholdt ordet "Mac" betød det at brukeren befant seg på en ios plattform og at denne brukeren dermed skulle sendes til ios datovelgeren. ~ 19 ~

48 7.4 Input validering Når en bruker skal registrere seg på applikasjonen må informasjonen som blir skrevet inn valideres. Dette ble gjort ved hjelp av et JavaScript i samme side som registreringsskjemaet brukeren fyller inn. Nedenfor (Tekstboks 3) er funksjonen som ble brukt til å validere brukerens fornavn. Funksjonen består av en variabel (validregexp) hvor det er definert hvilke tegn som er godtatt. Deretter tilegnes variabelen strfirstname verdien som er skrevet inn i input feltet med ID "firstname". Til slutt sjekker funksjonen om strfirstname inneholder tegnene i validregexp. Hvis fornavnet inneholder andre tegn enn disse, returnerer funksjonen en feilmelding på skjermen som beskriver hva som er feil. function isvalidfirstname(strfirstname) { validregexp = /[ÆØÅæøåA-Za-z]{2,}$/i; strfirstname = document.forms[0].firstname.value; } if (strfirstname.search(validregexp) == -1) { alert('ikke et gyldig fornavn.'); return false; } return true; Tekstboks 3 ~ 20 ~

49 7.5 RSS feed for avviksinformasjon For å vise avviksmeldingene benyttet gruppen seg av JavaScript biblioteket jquery. Nedenfor er funksjonen som ble kodet for å skrive ut meldingene. Utskriften har egentlig en overskrift, men på grunn av plassmangel og ønske om selv å velge overskrift, valgte gruppen å legge til regelen "header: false" som betyr at samlingen av meldinger ikke skal ha en overskrift. <script type="text/javascript"> $(document).ready(function () { $('#trafikkflyt').rssfeed(' { header: false }); }); </script> 7.6 Sjekke om det allerede eksisterer en bruker For å kunne kjøpe en billett måtte det først registreres en bruker. Når en person registrerer seg blir brukeren lagret i oppdragsgivers API og lokalt i brukerens nettleser. For å unngå at flere brukere ble lagret på samme telefon, ble det laget en funksjon (Tekstboks 4) som skulle sjekke om det allerede eksisterte en bruker. if(localstorage.length > 0) { } var localstoragearray = new Array(); for (i=0;i<localstorage.length;i++) { } else { } localstoragearray[i] = localstorage.getitem(localstorage.key(i)); window.location.href = 'registrer.php'; Tekstboks 4 Funksjonen ovenfor benyttet seg av en if-setning for å sjekke om det fantes data lokalt lagret på telefonen. Variabelen localstorage.length inneholder all lokalt lagret data. Ved å sjekke om denne inneholder mer enn ingenting (localstorage.length > 0) kunne applikasjonen se om det allerede fantes en bruker. Om den er tom ble brukeren sendt til registreringsskjemaet. ~ 21 ~

50 Det ble også lagt inn en funksjon som returnerte en varselboks om en brukere forsøker å gå direkte inn på registreringssiden og allerede har en bruker registrert. I varselboksen må personen velge mellom enten å slette brukeren eller og fortsette å kjøpe billetter med den nåværende brukeren. (Figur 9). Figur 9 - Varselboks 7.7 Url_safe Det ble laget en funksjon (Tekstboks 5) for å bytte ut tegn som æ, ø, å og mellomrom i sidens adresse. Funksjonen inneholder to arrays, hvorav det ene ($letters) inneholdt tegn som ikke skulle godtas og det andre ($hexval) inneholdt tegnene disse skulle erstattes med. Tegnene erstattes og adressen lagres på nytt i $url. function url_safe($input) { } $letters = array(" ", "æ", "ø", "å", "Æ", "Ø", "Å"); $hexval = array("%20", "%E6", "%F8", "%E5", "%C6", "%D8", "%C5"); return $url = str_replace($letters, $hexval, " $input); Tekstboks 5 8 Datovelgere For å kjøpe en billett må brukeren angi avreisested, ankomststed og avreisetidspunkt. Tidspunkt for avreise velger brukeren i en datovelger. I datovelgeren må det velges måned, dag, time og minutt for avreise. Når brukeren går inn på siden vises dagens dato og nåværende tidspunkt. Applikasjonen inneholder tre forskjellige datovelgere, bestående av en for hver av de tre mest utbredte plattformene som brukes på mobile enheter per i dag. ios, Windows Phone og Android. Dette har blitt gjort for å gi brukeren en mer «native» følelse av applikasjonen. ~ 22 ~

51 Alle tre datovelgerne har utgangspunkt i ferdige koder funnet på Internet. Derfor måtte det også gjøres en del endringer for å tilpasse dem vårt prosjekt. Blant annet hadde datovelgerne i utgangspunktet mulighet for å velge år, noe som ikke er nødvendig i en applikasjon hvor billetter kun skal kunne kjøpes for nærmeste fremtid. if($os == 'Windows') { echo "<a href='datepickerwindows.php... } if($os == 'Linux') { echo "<a href='datepickerandroid.php... } if($os == 'MacOS') { echo "<a href='datepickerios.php... } Tekstboks 6 Applikasjonen inneholder en funksjon (Operativsystem detektor) som finner ut hvilken plattform brukeren benytter seg av. Funksjonen over (Tekstboks 6) skriver på bakgrunn av dette resultatet ut en link til en av de respektive datovelgerne. Hver datovelger er helt separate sider som vises på grunnlag av hvilken plattform funksjonen returnerer. 8.1 ios Datovelgeren for ios er utviklet av Matteo Spinelli's cubiq.org. Den er designet med samme utseende som datovelgeren som finnes på ipad og iphone for å gi nettsidene en følelse av å være en «native» applikasjon utviklet spesielt for Apple. Datovelgeren er kodet i ren JavaScript hvor metodene befinner seg i en separat JavaScript fil. Disse funksjonene blir kalt på og skrevet ut i et annet PHP dokument. Ved hjelp av JavaScript er det mulig å lage en dynamisk applikasjon. Hvert av valgene (dag, måned, time, minutt) blir vist på et hjul brukeren kan snurre rundt for å finne ønsket verdi (Figur 10). (Cubiq, 2009) ~ 23 ~

52 Figur 10 - Datovelger for ios 8.2 Android Datovelgeren for Android (Figur 11) er på samme måte som ios generert ved hjelp av en separat JavaScript fil. I PHP filen som viser datovelgeren, kalles det på JavaScript funksjoner som skriver til HTML elementer på siden. Datovelgeren består av knapper for enten å flytte verdien i et felt opp eller ned til neste verdi. Angitt tidspunkt vises i et eget felt på toppen av velgeren. (Horst, 2010) 8.3 Windows Phone Figur 11 - Datovelger for Android Datovelgeren for Windows Phone (Figur 12) er utviklet av Kevin Liew, som blant annet arbeider med utvikling av jquery plugins, for Mobiscroll. Velgeren er optimalisert for berøringsskjermer på mobile enheter som smarttelefoner og nettbrett og utviklet for å kunne tilpasses eventuelle egendefinerte verdier. Det er mulig å endre utseende ved å bytte til et av de andre forhåndsdefinerte temaene som ligger klare i kodene. Den er, på samme måte som de andre datovelgerne, designet for å brukes som et intuitivt alternativ til telefonens standard datovelger. Tid og dato velges på samme måte som i ios datovelgeren ved hjelp av hjul som snurres rundt til ønsket verdi. (Mobiscroll) ~ 24 ~

53 Figur 12 - Datovelger for Windows Phone 9 Sikkerhet 9.1 Obfuskere kildekode Oppdragsgiver ønsket svar på om applikasjonens kildekode kunne obfuskeres (skjules) slik at den ikke var tilgjengelig for brukeren. Dette er ønskelig i en slik applikasjon fordi billetter og brukerinformasjon er sårbart når det ligger lagret i variabler. Applikasjonens PHP kode er ikke nødvendig å skjule fordi PHP er et serverside programmeringsspråk som ikke er synlig for brukeren. HTML og CSS kodene er det ikke mulig å skjule, noe som heller ikke er nødvendig fordi sensitiv informasjon ikke håndteres av disse programmeringsspråkene. Ved hjelp av forumer og nettsteder om obfuskering av kildekode, spesielt med tanke på JavaScript, har gruppen kommet fram til at dette ikke er mulig. Problemet er at nettleseren, naturlig nok, håndterer kodene på samme måte som de blir skrevet. Om brukeren går inn i nettleserens meny og velger "vis kildekode" vil personen se kildekoden nettleseren bruker for å generere siden som vises. Om kildekoden krypteres, eller på en annen måte gjøres uleselig for denne personen, vil kodene samtidig være uleselig for nettleseren. Det ville derfor vært fornuftig å kode applikasjonen i PHP eller et baksystem. Men fordi produktet inneholder funksjoner som kun kan utføres hos klienten (brukeren), som f.eks. lokal lagring, må noe av kodene være skrevet med JavaScript. Noe av applikasjonen, f.eks. å vise kjøpte billetter, skulle også kunne gjøres uavhengig om brukeren er tilkoblet Internet. Dette krevde igjen at informasjonen som skulle vises måtte være lagret lokalt på brukerens telefon når de ble kjøpt og at de kunne vises igjen når brukeren ba om det. Dette måtte derfor gjøres på brukerens telefon og kunne ikke blitt gjort verken ved hjelp av PHP eller et baksystem Sikkerhet gjennom hemmelighold Selv om obfuskering av JavaScript ikke er mulig, finnes det andre metoder for å øke applikasjonens sikkerhet. En strategi som er mye brukte er sikkerhet gjennom hemmelighold ~ 25 ~

54 (Security through obscurity). Tankegangen er at ingen vil prøve å åpne døren fordi ingen vet at den er ulåst. Ved å unngå å vise sikkerhetshull, f.eks. ved å navngi en variabel som holder på et passord for noe annet enn nettopp passord, vil noe av sikkerheten økes. Sikkerhet gjennom hemmelighold alene er ikke sett på som en god sikkerhetsløsning, men det kan være et godt supplement i tillegg til andre sikkerhetsløsninger. (Wikipedia, 2012) 9.2 Lokal lagring Alle billetter kjøpt på applikasjonen lagres lokalt. For å forhindre at disse lagres i klartekst og kan duppleseres eller missbrukes benyttet gruppen seg av et JavaScript bibliotek som krypterer billetten, representert som en base-64 streng, før den lagres lokalt. JavaScript biblioteket som ble benyttet er kodet av Stanford Computer Security Lab og betegnes som SJCL(Stanford JavaScript Crypto Library). Dataene krypteres ved hjelp av et passord, salt og IV. Passordet som brukes til kryptering er samme passord som brukeren skrev inn når brukeren ble opprettet. Når billetten skulle vises frem fra lokal lagring, måtte brukeren igjen skrive inn samme passord. Om dette er riktig, blir billettene dekryptert og vist på skjermen Utfordringer Prosjektet møtte på flere utfordringer i løpet prosjektperioden. Spesielt har mangelen på en felles standard for de forskjellige funksjonene og rammeverkene vært til hodebry Geolokasjon Geolokasjon og innsending mot Trafikantens API er et eksempel på en situasjon en felles standard ville spart gruppen for mye tid. Funksjonen geolokasjon returnerer et tall som inneholder brukerens lengde- og breddegrad. Trafikantens API krever derimot at koordinatene for lengde- og breddegrad gis separat og at de er omgjort til UTM. Gruppen måtte derfor, ved hjelp av JavaScript, dele opp tallet i de to koordinatene og endre tallenes format før de kunne sendes videre til Trafikanten QR- kode En annen utfordring var å vise frem base64 streng, returnert fra oppdragsgivers API, som en QR- kode. Den todimensjonale strekkoden skulle vises som et bildeelement i applikasjonen. Oppdragsgivers API returnerte en streng som inneholdt linjeskift (Tekstboks 7), noe som gjorde at bildeelementet ikke klarte å ivborw0kggoaaaansuheugaaajyaaacwcaiaaac tolke QRkoden som zy+a1aaaabmjlr0qa/wd/ap+gvaetaaacgule\r\nqv et bilde. R4nO3dwW6jMBRA0WE0///L6aI7NKUlNoZbnbONEqW6s vrkgnher9cfyv7e/quyjwgehhks5kmy\r\nj2gehhks5k myj2gehhks5kmyj2gehhks5kmyj2gehhks5kmy92/8 I7ZtG/+Qnzh12G73rXbvPfXq\r\ndaYcH7QK8yTMkzBPwr wj48zoxbp+i2pfxk/xkl/ok1zhnor5euzjmdd/nnk59q9 82f7LyIRy3V/0\r\nHqswT8I8CfMkzLt8nLnO8aRw/OrxsN NiFeZJmCdhnoR54XFm5yHHYdazCvMkzJMwT8K8y8eZ ~ 26 ~ uzy+\r\njuexkw/1tk0cqzbpwjwj8ytmmz/olnshmxjt0ql fpp7gksytme/cpanzjowzt9ut+imrczdpyxxm\r\nszgn YZ6EeavvO/OQI

55 Tekstboks 7 - QR- kode representert som base64 streng Problemet lå i APIet og i samarbeid med oppdragsgiver ble tegnene fjernet. Etter det var gjort kunne base64 strengen legges inn i et bildeelement (Tekstboks 8) og på den måten vises til brukeren som en billett. <img src='data:image/png;base64,". $result->qrcode. "' alt='qrcode' width='65%' /> 10.3 Kommunikasjon med API Tekstboks 8 For å opprette en bruker eller kjøpe en billett måtte informasjon sendes til og mottas fra oppdragsgivers API. Det ble brukt en GET metode (file_get_contents()) for å hente ut data fra APIet (Tekstboks 9). Denne metoden returnerer svaret fra APIet som en lang tekststreng. For å kunne lagre informasjon ble det brukt en POST metode (Tekstboks 9). Figuren nedenfor viser de kodene som skal til for å utføre en slik metode. Først legges informasjonen som skal lagres (fornavn, etternavn, e-post adresse, passord) inn i et array ($data). Dette arrayet legges deretter inn i metoden http_build_query() som generer en URL med innholdet i arrayet. I tillegg lages det et array ($options) med definering av valg knyttet til spørringen, som f.eks. hva slags innhold som skal lagres. Deretter kjøres metoden stream_context_creat, som gjør informasjonen klar til å sendes inn til APIet. Til slutt kjøres metoden file_get_content() som returnerer, i dette tilfelle, brukerens ID (autheticationtoken). ~ 27 ~

56 $data = http_build_query( array( 'firstname' => $_REQUEST['firstName'], 'lastname' => $_REQUEST['lastName'], ' ' => $_REQUEST[' '], 'password' => $_REQUEST['password'] ) ); $options = array('http' => array( 'method' => 'POST', 'header' => 'Content-type: application/x-www-form-urlencoded', 'content' => $data)); $context = stream_context_create($options); $result = file_get_contents(' false, $context); $_SESSION['AT'] = $result; Tekstboks Unngå søk på område Applikasjonen skulle være en billettapplikasjon som på bakgrunn av avreisestasjon, ankomststasjon og tidspunkt skulle vise brukeren reiseruter knyttet til disse valgene. Metoden gruppen benyttet for å søke etter stasjoner i Trafikantens API returnerte alle stasjoner og områder som inneholdt den teksten brukeren søkte etter. Derimot ville ikke metoden som ble benyttet for å beregne en rute fungere om stedet brukeren valgte å reise fra eller til var et område. Det måtte derfor ikke være mulig for brukeren å søke på et område. foreach ($obj as $key) { } if(strpbrk(utf8_decode($key->name), '#') == null) { } echo "... Kodene ovenfor skriver ut alle objektene (reiserutene) Trafikanten returnerer. For å utelukke områder ble det brukt en PHP metode for å sjekke om svaret inneholdt et "#". "#" definerte at det var et område, og det holdt derfor bare å utelukke alle svar som inneholdt dette tegnet Tidsformat De tre datovelgerne som ble benyttet i applikasjonen ble lastet ned ferdige utviklet fra Internet. Fordi gruppen selv ikke hadde utviklet disse fra bunn av, ble det derfor brukt svært mye tid på å sette seg inn i kodene. Spesielt tidsformatet var utfordrende fordi alle datovelgerne benyttet seg av helt forskjellige format for å skrive den valgte datoen til neste ~ 28 ~

57 side. Tidsformatet datovelgerne skrev ut var ulikt det som måtte sendes til Trafikantens API. Trafikantens API måtte ha datoen skrevet DDMMYYYYHHMM (f.eks ). Android I datovelgeren for Android definerte gruppen selv hvordan tiden skulle presenteres ved hjelp av metoden dateformat() (Tekstboks 10). Det gjorde at formatet enkelt kunne settes til formatet som krevdes av Trafikantens API. Funksjonen updatef ble kjørt hver gang brukeren endret dato i datovelgeren. function updatef() { $('#mon').val(dateformat(cd, "mmm")); $('#day').val(dateformat(cd, "dd")); $('#dstr').html(dateformat(cd, "")); $('#hour').val(dateformat(cd, "HH")); $('#min').val(dateformat(cd, "MM")); var timestamp = dateformat(cd, "ddmmyyyyhhmm"); document.getelementbyid('time').value = timestamp; } Tekstboks 10 ios I datovelgeren for ios var datoformatet 01 Feb Det måtte derfor kodes en funksjon som gjorde om datoen til riktig format. Nedenfor følger denne koden. if($_request['timeios']!= null) { $date = $_REQUEST['timeIos']; list($day, $month, $hour, $minute) = preg_split('/ /', $date); [...] if($month == "jan.") { $monthnum = "01"; } if($month == "feb.") { $monthnum = "02"; } Datoen som ble hentet fra datovelgeren ble lagt inn i variabelen $date. Kodens oppgave var å oversette månedens navn til månedens nummer, samt legge til årstallet som manglet. Det ble løst ved at $date ble delt opp i deler separert av mellomrom. På den måten ble datoen fordelt på fire variabler ($day, $month, $hour og $minute). Dermed kunne månedens navn oversettes til tall ved å gi måneden et spesifikt tall("01") for et spesifikt navn(f.eks. "jan."). Resultatet ble lagt i variabelen $monthnum. ~ 29 ~

58 Deretter brukes funksjonen date("y") for å finne inneværende år. Til slutt settes de nye variablene sammen til formatet som stemmer med det som kreves av Trafikanten. Det ble gjort slik: $_SESSION['time'] = $day. $monthnum. date("y"). $hour. $minute; 10.6 Håndtering av feilmeldinger Om det ble sendt en ugyldig forespørsel mot et API ville applikasjonen returnere en feilmelding. Disse feilmeldingene var ikke nødvendig å vise til brukeren fordi det allerede var implementert tilbakemelding til brukeren om det ble skrevet inn ugyldig informasjon eller på annen måte utført en feil av brukeren. Gruppen valgte derfor å legge inn en PHP "Error Control Operator". Operatoren ble betegnet med og plasseres den foran et PHP uttrykk ble det ikke skrevet ut feilmeldinger. (PHP, 2012) Figuren (Tekstboks 11) nedenfor viser hvordan operatoren ble brukt i applikasjonen. Det ble skrevet en "@" foran funksjonen file_get_contents($url), som gjør at feil fra denne funksjonen ignoreres. $url = " $time. "&from=". $fromid. "&to=". $toid; $obj = json_decode(@file_get_contents($url)); Tekstboks 11 I figuren nedenfor (Tekstboks 12) brukes også operatoren. Operatoren ble også lagt til på funksjonen krsort() som ble brukt for å sortere billettene i "Mine billetter". Dette ble implementert fordi man har mulighet til å gå inn på mine billetter før det har blitt kjøpt noen billett. Ved å sette unngår man feilmeldinger om ingen billetter er kjøpt. Det er også her kodet inn en egen feilmelding som gir beskjed om at brukeren ikke har noen billetter. $obj = if($obj==false) { } echo "Du har ingen billetter! ; 10.7 Tegnsett Tekstboks 12 Visning av tegn som Æ, Ø og Å har vært en utfordring. For å kunne vise de norske bokstavene måtte applikasjonens sider tolkes med riktig tegnsett. Tegnsettet som brukes i ~ 30 ~

59 Norge er ISO Trafikantens API returnerer stasjoner og annen trafikkinformasjon i UTF-8, som er et tegnsett som ikke støtter de tre norske bokstavene. I stedet for de vanlige bokstavene ble det skrevet ut uleselige tegn (f.eks. blir Å til à ). Gruppen løste dette ved å legge inn en PHP funksjon som konverterer en UTF-8 streng til ISO Figuren nedenfor (Tekstboks 13) viser at funksjonen brukes i utskriften av stasjonsnavn. { } echo "<a href='datepickerwindows.php?toid=". $key->id. "&toname=". utf8_decode($key->name). "'class='button'><div id='linjelink'>". utf8_decode($key->name). "</div></a><hr />"; Tekstboks Kilder Bekk. (2009, 10 14). Hentet 2012 fra Cubiq. (2009). cubiq.org. Hentet 2012 fra Horst, T. M. (2010, 12 30). toddmhorst.wordpress.com. Hentet 2012 fra itpro.no. (2003, 08 21). itpro.no. Hentet 2012 fra jquerymobile. (u.d.). jquerymobile.com. Hentet 2012 fra kodehjelp. (u.d.). Hentet 2012 fra Mobiscroll. (u.d.). blog.mobiscroll.com. Hentet 2012 fra PHP. (2012, 05 25). php.net. Hentet 2012 fra Wikipedia. (2012, 05 15). en.wikipedia.org. Hentet 2012 fra Wikipedia. (2012, 05 18). no.wikipedia.org. Hentet 2012 fra ~ 31 ~

60 Del 3: Vedlegg ~ 1 ~

61 Innhold 1 Planer A- Fremdriftsplan B - Arbeidsplan C - Milepælsplan Modeller A- Use case B - Detaljert use case beskrivelse - kjøp av billett C - Aktivitetsdiagram Brukerveiledning Ny reise Mine billetter Innstillinger Trafikkinformasjon Prosjektbeskrivelse Innholdsfortegnelse Innledning Bakgrunn Oppgaven Krav til operativsystem / plattformer Systemarkitektur Mobil klient Web Server Sanntidsdata Tjenestelag Funksjonalitet Utseende Registering Navigasjon Ny reise Velg fra-stasjon Velg til-stasjon Velg tidspunkt Vis rute ~ 2 ~

62 Kvittering Billetter Ordreliste Vis billett Kontaktinformasjon Intelecom Nyttige linker Emulatorer / verktøy: Annet ~ 3 ~

63 Milepæler Møter Testing Programmering Aktiviteter Planlegge videre fremgang Finne oppdragsgiver Hovedprosjekt Gruppe 13 1 Planer 1 A- Fremdriftsplan Det ble laget en fremdriftsplan, men grunnet planens størrelse viser vi planen for første to uker og et forminsket skjermdump av planen i sin helhet. Før jul Uke 1 Uke 2 Oppgave M T O T F M T O T F Kontakte bedrifter Avtale møte Finne prosjekt til gruppen avtale med arbeidsgiver Lage prosjektskisse Forprosjekt rapport Arbeidsplan Fremdriftsplan Milepælsplan Prosjektrapport Geolokasjon Kjøpe billett fra API Reisplanlegger fra trafikanten Kryptering Bestille QR- billett Lokal lagring Implementering Teste på mobiltelefoner Teste på emulatorer Teste funksjoner Statusmøte med intelecom Daglig møte med gruppa Planleggingsmøte Oppsumeringsmøte Forprosjekt V: 0128 V: 0256 V: 0512 V: 1024 Ferdig applikasjon Muntlig presentasjon ~ 4 ~

64 Forminsket skjermdump av prosjektets fremdriftsplan ~ 5 ~

65 1 B - Arbeidsplan Ansvarlig Aktivitet Beskrivelse Planlagt Utført Gruppen ble opprettet og meldt inn på Opprette gruppe prosjektsiden Atle og Alexander Ludvig og Atle Alexander Atle og Alexander Ludvig Gisle + gruppa Atle Statusrapport Prosjektskisse Forprosjektrapport Programmering Geolokasjon Lokal lagring QR-billett Registrering av bruker Kryptering jquery Mobile Trafikkinformasjon Beskrivelse av hva gruppen har gjort, og status på hva som skal gjøres Beskrivelse av prosjektet med så mange detaljer som mulig. Skolen skal godkjenne prosjektet på grunnlag av dette Definere prosjektet. Sette opp rammer og gjøre klar for arbeidet Geolokasjon skal være ferdig utviklet i applikasjonen slik at det vil være mulig for en bruker å kunne finne de fem nærmeste holdeplassene Applikasjonen skal kunne bruke lokal lagring til å lagre bruker og billett i nettleseren Det skal være mulig for applikasjonen å kunne hente ned en QR billett Få applikasjonen til å lagre en bruker gjennom oppdragsgivers API JavaScript koden skal obfuskeres og billetter skal være kryptert i lokal lagring jquery Mobile skal være brukt som et rammeverk rundt applikasjonen slik at det blir en «native» følelse Applikasjonen skal kunne hente trafikkinformasjon fra trafikantens API Gisle Implementering Implementere alle de ferdige funksjonene inn i versjonen med jquery Design Gruppa Tema og farger Lage en design til applikasjonen Gisle Implementere Sette inn ferdig funksjoner i versjon med design ~ 6 ~

66 Ludvig Gisle Dokumentasjon Milepælsplan Arbeidsplan Sette opp milepæler som gruppa skal følge Fordele oppgaver blant gruppemedlemmene Alexander Fremdriftsplan Planlegging av fremdriften til gruppa Gruppa Rapport Den avsluttende rapporten som skal leveres inn Testing Programmerings Teste om applikasjonens funksjoner Gruppa testing kjører slik de skal. Kontinuerlig Kontinuerlig Testing på forskjellige Teste på ulike mobile enheter for å sikret at applikasjonen kjører på de forskjellige Gruppa mobile enheter operativsystemene ~ 7 ~

67 1 C - Milepælsplan Versjon: V:0.128 Start: Slutt: Beskrivelse: Geolokasjon funksjonen skal være ferdig. Design: Knapper og farger på plass. Kunne bestille enkel billett med QR-kode. Versjon: V:256 Start: Slutt: Beskrivelse: Bruker skal kunne klare å registrere seg. Design: Skalerer riktig i forhold til enhet. Lokal lagring av QR-kode. Lokal lagring av kritisk data. Versjon: V:0.512 Start: Slutt: Beskrivelse: Design: Native feel på enheter. Obfuskere (skjule) Javascript. ~ 8 ~

68 Versjon: V Start: Slutt: Beskrivelse: Fullt fungerende applikasjon Beta testing(debugging) Versjon: Ferdig Applikasjon Start: Slutt: Beskrivelse: Alle kravene fra rammebetingelsen skal være oppnådd. ~ 9 ~

69 2 Modeller 2 A- Use case ~ 10 ~

70 2 B - Detaljert use case beskrivelse - kjøp av billett Use Case Mål Aktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt (normale transaksjoner) Kjøp av billett Få kjøpt en ny billett Bruker Brukeren trenger en billett for å bruke kollektivtransport Kunden er registrert og har tilgang til en mobil med nettilgang og nettleser Kunden får kjøpt billett 1. Brukeren går inn på applikasjonen 2. Trykker på Ny Reise og velger fra og til stasjon. 3. Angir avreisetidspunkt. 4. Velger en rute. 5. Bekrefter billetten. 6. Får en elektronisk kvittering som består av QR kode. UC relatert til hovedløpet Kansellere billett. Registrere ny bruker. Variasjoner <En liste med beskrivelser av mulige transaksjonsvariasjoner til den normale flyten i use caset> 1. Mangler nettverk 2. Stasjonen finnes ikke 3. Får ikke åpnet applikasjonen på mobilen, eller mobilen er tom for strøm 4. Kunde godkjenner ikke kjøpet. 5. Baksystemet er nede. Relatert informasjon ~ 11 ~

71 2 C - Aktivitetsdiagram ~ 12 ~

72 3 Brukerveiledning Dette er en brukerveiledning for "Mobil billettapplikasjon i HTML5" Når applikasjonen brukes for første gang, vil brukeren bli sendt til en registreringsside med et registreringsskjema (Figur 1) som må fylles inn. I dette skjema må det fylles inn fornavn, etternavn, e-post adresse og passord. Figur 1 - Registreringsside ~ 13 ~

73 Etter å ha fylt inn informasjonen og trykket "Registrer" blir brukeren sendt til neste side(figur 2), hvor informasjonen må bekreftes før brukeren blir lagret. Figur 2 - Bekreft bruker Etter at en ny bruker er registrert kommer brukeren inn på hovedsiden (Figur 3). Det er denne siden brukeren vil komme tilbake til hvis det blir trykket på hjem knappen. Hjem knappen er lokalisert øverst til venstre i skjermbildet på alle sidene. På hovedsiden er det fire forskjellige valg. Ny reise, billetter, informasjon og innstillinger. Figur 3 - Startsiden ~ 14 ~

74 Ny reise For å kjøpe en ny billett trykker man på Ny reise. Brukeren blir da sendt til første side i billettbestillingen, hvor avreisestasjon må velges (Figur 4). For å velge en stasjon kan brukeren enten skrive inn et stasjonsnavn i søkefeltet og trykke på søk knappen, eller trykke på "I nærheten" knappen. Denne knappen finner og skriver ut de fem nærmeste stasjonene ut ifra brukerens geografiske posisjon. Figur 4 - Avreisestasjon ~ 15 ~

75 Etter å ha valgt avreisestasjon blir brukeren sendt til neste side hvor brukeren må velge ankomststasjon (Figur 5). Denne siden er lik som forrige side, men uten mulighet til å skrive ut stasjonene i nærheten. Figur 5 - Ankomststasjon Etter å ha valgt både fra og til stasjon må brukeren velge dato og tid for avreise i en datovelger. Applikasjonen inneholder tre datovelgere. Brukeren blir, avhengig av hvilket operativsystem som benyttes, sendt til en datovelger tilpasset deres plattform (Figur 6,7 og 8). Figur 6 - Datovelger for ios ~ 16 ~

76 Figur 7 - Datovelger for Windows Phone Figur 8 - Datovelger for Android ~ 17 ~

77 Neste side brukeren kommer til inneholder ruteforslag (Figur 9). På bakgrunn av valgene brukeren har gjort så langt, avreisestasjon, ankomststasjon og tidspunkt, vises de fem nærmeste reiserutene i tid. Brukeren kan enten velge et av ruteforslagene, eller om noe ikke er riktig, ombestemme seg og trykke på knappen "Ny reise" nederst på siden som vil sende brukeren tilbake til siden for valg av avreisestasjon. Ruteforslagene vises med avreise- og ankomsttidspunkt, avreise- og ankomststasjon, hvilke transportmidler som må benyttes, samt reisetid. Figur 9 - Ruteforslag ~ 18 ~

78 Etter å ha valgt en spesifikk reise vises all informasjon knyttet til denne reisen i en ny side (Figur 10). Brukeren må her skrive inn passordet som ble skrevet inn når brukeren ble opprettet for å bekrefte billettkjøpet. Figur 10 - Bekreft billett ~ 19 ~

79 Om brukeren skriver feil passord vil en melding vises med beskjed om feilen (Figur 11). Figur 11 - Bekreft billett - feil passord ~ 20 ~

80 Om passordet er riktig vil brukeren bli vist en kvittering (Figur 12). Kvitteringen inneholder informasjon om reisen. Brukeren har nå kjøpt en billett og kan her velge enten å gå til "Mine billetter" for å se billetten som akkurat ble kjøpt, eller gå til applikasjonens hovedside. Figur 12 - Kvittering ~ 21 ~

81 Mine billetter På denne siden vises alle kjøp knyttet til brukeren og informasjon om hver av disse(figur 13). Ved å skrive inn brukerens passord kan sist kjøpte billett hentes ut fra lokal lagring og vises uten nettilgang. Figur 13 - Mine billetter Om brukeren ikke har kjøpt noen billetter vil det vises en side med beskjed om at det ikke er noen billetter lagret på telefonen(figur 14). Figur 14 - Ingen billetter ~ 22 ~

82 For å se billetten må brukeren trykke på QR- koden i høyre kolonne i mine billetter. Det vil da vises en større billett med den viktigste informasjonen knyttet til reisen (Figur 15). Figur 15 - Billett (QR- kode) ~ 23 ~

83 Innstillinger I innstillinger(figur 16) har brukeren tre valg. Se profil, informasjon om applikasjonen og slett bruker. Figur 16 - Innstillinger Profilsiden (Figur 17) viser informasjon (navn og e-post adresse) om brukeren som er lagret på den telefonen. Figur 17 - Profil ~ 24 ~

84 Informasjonssiden (Figur 18) viser en kort beskrivelse av applikasjonen. Figur 18 - Informasjon om applikasjonen Siste funksjonen i innstillinger er å slette brukeren og alle billetter knyttet til denne. Slettingen må godkjennes av bruker (Figur 19) før den utføres. Figur 19 - Slett bruker ~ 25 ~

85 Trafikkinformasjon Siste valget i hovedmenyen er "informasjon" (Figur 20). Denne siden viser uregelmessigheter i trafikken og viser forsinkelser og annen viktig informasjon for den reisende. Ved å trykke på en av overskriftene vil brukeren bli sent til Trafikantens nettsider hvor hele meldingen kan bli sett. Figur 20 - Trafikkinformasjon ~ 26 ~

86 4 Prosjektbeskrivelse Versjon 1.0 Sist endret January 2012 Endret av Sven Ståle Osa Contact Information: Sven Ståle Osa ~ 27 ~