Del 2: Produktdokumentasjon

Transkript

1 Del 2: Produktdokumentasjon ~ 1 ~

2 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 ~

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

4 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 ~

5 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 ~

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

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

8 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 ~

9 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 ~

10 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 ~

11 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 ~

12 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 ~

13 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 ~

14 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 ~

15 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=test /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 ~

16 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 ~

17 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 ~

18 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 ~

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

20 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 ~

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

22 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 ~

23 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 ~

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

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

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

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

28 $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 ~

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

30 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 ~

31 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 ~