Hovedprosjekt 2012 - Gruppe 13 - HiOAstudent.cs.hioa.no/hovedprosjekter/data/2012/13/Prosjekt... · 2012-06-03 · Hovedprosjekt 2012 - Gruppe 13 ~ 2 ~ 1 Forord Denne rapporten tar

Hovedprosjekt 2012 - Gruppe 13


HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL

Mobil billettapplikasjon i HTML5

DATO

30.05.2012

31.05.2011 kl. 12:00

ANTALL SIDER / BILAG

98 / 4

PROSJEKTDELTAKERE

Atle Fjellang Sæther (s161905)

Gisle Bøhn Hagen (s161889)

Ludvig Hummelvoll Hillestad (s161887)

Alexander Bakke (s161864)

INTERN VEILEDER

Geir Skjevling

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

Studieprogram: Anvendt Datateknologi

Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo

PROSJEKT NUMMER

2012 - 13

TILGJENGELIGHET

Åpen

Telefon: 22 45 32 00 Telefaks: 22 45 32 05



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

2012. 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.


~ 1 ~

Del 1: prosessdokumentasjon


~ 2 ~

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.


~ 3 ~

2 Innholdsfortegnelse

1 Forord .................................................................................................................................................. 2

3 Innledning ........................................................................................................................................... 5

3.1 Om gruppa.................................................................................................................................... 5

3.2 Om oppdragsgiver ........................................................................................................................ 5

3.3 Bakgrunn ...................................................................................................................................... 5

3.3.1 «Native» applikasjoner .......................................................................................................... 5

3.3.2 Hybride applikasjoner ............................................................................................................ 6

3.3.3 Dedikert mobil web applikasjon ............................................................................................ 6

3.3.4 Generisk mobil applikasjoner ................................................................................................ 6

3.3.5 Sammenligning ...................................................................................................................... 7

3.4 Nytt i html 5 og CSS3 .................................................................................................................... 7

3.5 QR – kode ................................................................................................................................... 10

3.6 Baksystemer ............................................................................................................................... 10

3.6.1 Trafikanten API .................................................................................................................... 10

3.6.2 Intelecom API ...................................................................................................................... 10

3.7 Situasjonen i dag ........................................................................................................................ 10

3.8 Mål med oppgaven ..................................................................................................................... 11

4 Rammebetingelser ............................................................................................................................ 11

4.1 Brukergrensesnitt ....................................................................................................................... 12

4.2 Telefonens funksjoner ................................................................................................................ 12

4.3 Lokal lagring og HTML5 Manifest ............................................................................................... 12

4.4 Sikkerhet..................................................................................................................................... 12

5 Tilpassning av rammebetingelser ...................................................................................................... 13

5.1 Aksessering uten nettilgang ................................................................................................... 13

5.2 RSS feed for avviksinformasjon .............................................................................................. 13

6 Planlegging og metode ...................................................................................................................... 13

6.1 Fremdriftsplan ............................................................................................................................ 13

6.2 Arbeidsplan ................................................................................................................................ 13

6.3 Milepælsplan .............................................................................................................................. 14

6.4 Kommunikasjon med oppdragsgiver .......................................................................................... 14

6.5 Utviklingsmetode ....................................................................................................................... 15

6.6 Testing ........................................................................................................................................ 15

7 Verktøy .............................................................................................................................................. 16


~ 4 ~

7.1 Utviklingsverktøy ........................................................................................................................ 16

7.1.1 Notepad++ og phpDesigner 7 .............................................................................................. 16

7.1.2 FileZilla................................................................................................................................. 18

7.1.3 Firebug................................................................................................................................. 19

7.1.4 Poster .................................................................................................................................. 21

7.2 Prosessverktøy ........................................................................................................................... 22

7.2.1 Facebook ............................................................................................................................. 22

7.2.2 Dropbox ............................................................................................................................... 23

7.2.3 Gmail ................................................................................................................................... 23

7.2.4 Microsoft Office Word ......................................................................................................... 23

7.2.5 Adobe Photoshop CS3 ......................................................................................................... 23

7.2.6 Gliffy .................................................................................................................................... 23

8 Resultat ............................................................................................................................................. 24

9 Kilder ................................................................................................................................................. 25


~ 5 ~

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.

3.3.1 «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.


~ 6 ~

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».

3.3.3 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.

3.3.4 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.


~ 7 ~

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.


~ 8 ~

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)


~ 9 ~

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)


~ 10 ~

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)

Figur 4 - QR- kode

3.6 Baksystemer

API (Application Programming Interface) er et grensesnitt for kommunikasjon mellom

programvare. Et API fungerer som en regelbok for forespørsler til applikasjonen. (Wikipedia,

2012)

3.6.1 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.

3.6.2 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 tids-

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


~ 11 ~

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)


~ 12 ~

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.


~ 13 ~

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)


~ 14 ~

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)

Figur 5 - Milepælsplan

For fullstendig milepælsplan, se vedlegg 1 C.

6.4 Kommunikasjon med oppdragsgiver

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.


~ 15 ~

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.


~ 16 ~

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.

7.1.1 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


~ 17 ~

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.


~ 18 ~

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


~ 19 ~

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


~ 20 ~

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


~ 21 ~

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


~ 22 ~

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.

7.2.1 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.


~ 23 ~

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.

7.2.3 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.

7.2.4 Microsoft Office Word

Microsoft Office Word er et tekstbehandlingsprogram som ble brukt til å skrive

dokumentasjon som prosjektrapporten, møtereferater og dagbok.

7.2.5 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.

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


~ 24 ~

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.


~ 25 ~

9 Kilder

Difi. (2010, 12 16). www.anskaffelser.no. Retrieved 2012, from

http://www.anskaffelser.no/strategi/anskaffelsesstrategi/oppstart/utarbeide-fremdriftsplan

Difi. (2011, 12 01). www.anskaffelser.no. Retrieved from

http://www.anskaffelser.no/strategi/dokumenter/milepaelsplan

Firebug. (n.d.). getfirebug.com. Retrieved 2012, from http://getfirebug.com/whatisfirebug

Gliffy. (n.d.). gliffy.com. Retrieved 2012, from http://www.gliffy.com/about-us/

html5media. (n.d.). html5media.info. Retrieved 2012, from http://html5media.info/

Intelecom. (2012, 02 02). Intelecom nsb mobilapplikasjon. Retrieved 2012, from

http://www.intelecom.no/default.aspx?m=6&amid=11338

Intelecom. (2010, 03 25). Nettside om Intelecom. Retrieved 2012, from

http://www.intelecom.no/article.aspx?m=14&amid=2404

Intelecom. (2012, 01 23). Prosjektbeskrivelse. Oslo: Intelecom.

Mozilla. (n.d.). addons.mozilla.org. Retrieved 2012, from https://addons.mozilla.org/en-

US/firefox/addon/poster/

NRK. (2010). nrkbeta.no. Retrieved 2012, from http://nrkbeta.no/2010/01/22/litt-om-html5-og-kva-det-betyr-

for-nrk/

Rockberry. (2011, 06 23). www.detmektigeintet.no. Retrieved 2012, from

http://www.detmektigeintet.no/2011/06/hva-er-egentlig-en-qr-koder-og-hva-skal.html

Sharp, R. L. (2010). Introducing HTML5. New Riders forlag.

Strandskogen, N. K. (2011, 03 22). iallenkelhet.no. Retrieved 2012, from

http://iallenkelhet.no/2011/03/22/app-eller-webapplikasjon/

Utdanningsforbundet. (n.d.). www.utdanningsforbundet.no. Retrieved 2012, from

http://www.utdanningsforbundet.no/upload/Bedre%20Skole/BS_nr_3_10/Dalland_og_Bergem_BedreSkole-3-

10.pdf

Wikipedia. (2012, 03 12). en.wikipedia.org. Retrieved 2012, from

http://en.wikipedia.org/wiki/Cache_manifest_in_HTML5

Wikipedia. (2012, 04 09). no.wikipedia.org. Retrieved 2012, from

http://no.wikipedia.org/wiki/API_(programmering)

Wikipedia. (2012, 05 18). no.wikipedia.org. Retrieved 2012, from http://no.wikipedia.org/wiki/HTML

Wikipedia. (2012, 05 14). no.wikipedia.org. Retrieved 2012, from http://no.wikipedia.org/wiki/Scrum


~ 1 ~

Del 2: Produktdokumentasjon


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


~ 3 ~

Innholdsfortegnelse

1 Forord .................................................................................................................................................. 2

3 Innledning ........................................................................................................................................... 5

3.1 Hensikt med prosjektet ................................................................................................................ 5

3.2 Kort beskrivelse av resultat .......................................................................................................... 5

4 Presentasjon av applikasjonen ............................................................................................................ 6

4.1 Applikasjonens hoveddeler .......................................................................................................... 6

4.1.1 Hovedsiden ............................................................................................................................ 7

4.1.2 Ny reise .................................................................................................................................. 8

4.1.3 Innstillinger ............................................................................................................................ 9

4.1.4 Registrering ........................................................................................................................... 9

4.1.5 Trafikkinformasjon ................................................................................................................ 9

4.2 Applikasjonens brukergrensesnitt .............................................................................................. 10

4.2.1 Skalering .............................................................................................................................. 10

4.2.2 Ikoner .................................................................................................................................. 11

4.2.3 Plassering............................................................................................................................. 11

4.2.4 Farger .................................................................................................................................. 12

5 Teknologi ........................................................................................................................................... 12

5.1 Utviklingsmiljø ............................................................................................................................ 12

5.1.1 jQuery Mobile ...................................................................................................................... 12

5.1.2 jSon ...................................................................................................................................... 12

5.1.3 HTML ................................................................................................................................... 12

5.1.4 PHP ...................................................................................................................................... 12

5.1.5 JavaScript ............................................................................................................................. 12

5.2 Tilpassninger for iOS ................................................................................................................... 13

5.2.1 Ikon på skrivebordet ............................................................................................................ 13

5.2.2 Skjule adresselinje ............................................................................................................... 13

5.2.3Tall tolkes som telefonnummer ............................................................................................ 13

6 Baksystemer ...................................................................................................................................... 14

6.1 Oppdragsgivers API .................................................................................................................... 14

6.1.1 /authenticationtoken (POST) ............................................................................................... 14

6.1.2 /purchase (POST) ................................................................................................................. 15

6.1.3 /orders/{authenticationToken} (GET) .................................................................................. 15

6.1.4 /ticket/{orderId}?authenticationToken={authenticationToken} (GET) ................................ 15


~ 4 ~

6.2 Trafikantens API ......................................................................................................................... 15

6.2.1 /Place/GetClosestStopsByCoordinates/?coordinates=(X={X},Y={Y})&proposals=5 ............. 15

6.2.2 /Travel/GetTravelsAfter?time={time}&from={fromStopID}&to={toStopID} ........................ 15

7 Funksjonalitet .................................................................................................................................... 16

7.1 Geolokasjon ................................................................................................................................ 16

7.2 Lokal lagring ............................................................................................................................... 18

7.3 Operativsystem detektor ............................................................................................................ 19

7.4 Input validering .......................................................................................................................... 20

7.5 RSS feed for avviksinformasjon .................................................................................................. 21

7.6 Sjekke om det allerede eksisterer en bruker .............................................................................. 21

7.7 Url_safe ...................................................................................................................................... 22

8 Datovelgere ....................................................................................................................................... 22

8.1 iOS .............................................................................................................................................. 23

8.2 Android ....................................................................................................................................... 24

8.3 Windows Phone ......................................................................................................................... 24

9 Sikkerhet ........................................................................................................................................... 25

9.1 Obfuskere kildekode................................................................................................................... 25

9.1.1 Sikkerhet gjennom hemmelighold ....................................................................................... 25

9.2 Lokal lagring ............................................................................................................................... 26

10.0 Utfordringer ................................................................................................................................. 26

10.1 Geolokasjon .............................................................................................................................. 26

10.2 QR- kode ................................................................................................................................... 26

10.3 Kommunikasjon med API.......................................................................................................... 27

10.4 Unngå søk på område ............................................................................................................... 28

10.5 Tidsformat ................................................................................................................................ 28

10.6 Håndtering av feilmeldinger ..................................................................................................... 30

10.7 Tegnsett.................................................................................................................................... 30

11 Kilder ............................................................................................................................................... 31


~ 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å HTML5.

3.2 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.


~ 6 ~

4 Presentasjon av applikasjonen

4.1 Applikasjonens hoveddeler

Nedenfor følger en presentasjon av applikasjonens hoveddeler.

Figur 1 - Strukturkart


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


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


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

Figur 3 - Innstillinger

4.1.4 Registrering

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.

4.1.5 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.


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

4.2.1 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


~ 11 ~

Figur 5 - Bred skjerm

4.2.2 Ikoner

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.

Figur 6 - Applikasjonens ikoner

4.2.3 Plassering

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.


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

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

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

5.1.3 HTML

HTML (HyperText Markup Language) er et programmeringsspråk som brukes til å lage

strukturen på en nettside. (Wikipedia, 2012)

5.1.4 PHP

PHP (PHP: Hypertext Preprocessor) er et programmeringsspråk som utføres på serversiden.

(itpro.no, 2003)

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


~ 13 ~

5.2 Tilpassninger for iOS

Applikasjonen inneholder noen tilpassninger spesielt for iOS. Nedenfor følger en beskrivelse

av disse tilpassningene.

5.2.1 Ikon på skrivebordet

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å Hjem-

skjerm".

5.2.2 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.

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" />

<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; maximum-

scale=1.0; user-scalable=no" />

Figur 7 -

Applikasjons ikon <link rel="apple-touch-icon" href="bilder/icon.png" />


~ 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: http://lavkarbo.intele.com/ticketmock/

Støtter følgende tjenester:

6.1.1 /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&[email protected]&password=test123}

http://lavkarbo.carrot.no/ticketmock/

mailto:[email protected]


~ 15 ~

6.1.2 /purchase (POST)

For å kjøpe en ny billett. Returnerer en kvitteringsmelding.


{fromStop=Nydalen&toStop=Arendalsgaten&departureTime=2012-02-

15T08:05:04Z&authenticationToken=574bf7c0-8ebe-4a51-9746-

97f2e0074b85&password=test123}

6.1.3 /orders/{authenticationToken} (GET)

For å liste ut alle ordrer knyttet til denne brukeren.


/orders/574bf7c0-8ebe-4a51-9746-97f2e0074b85

6.1.4 /ticket/{orderId}?authenticationToken={authenticationToken} (GET)

Returnerer en billett.


/ticket/1?authenticationToken=574bf7c0-8ebe-4a51-9746-97f2e0074b85

6.2 Trafikantens API

Ligger bak: http:// api-test.trafikanten.no/

Støtter blant annet følgende tjenester:

6.2.1 /Place/GetClosestStopsByCoordinates/?coordinates=(X={X},Y={Y})&proposals=5

Returnerer fem nærmeste stoppestedene.


/Place/GetClosestStopsByCoordinates/?coordinates=(X=593918,Y=6644077)&proposals=7

6.2.2 /Travel/GetTravelsAfter?time={time}&from={fromStopID}&to={toStopID}

Returnerer de fem neste ruteforslagene i tid.


/Travel/GetTravelsAfter?time=220320110934&from=3011320&to=3010013


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

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.

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

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];

}

if (navigator.geolocation)

{

navigator.geolocation.getCurrentPosition(success, error);

}

else

{

error('Geolokasjon støttes ikke av din nettleser.');

}


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

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.

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.

<?php

$url="http://api-test.trafikanten.no/Place/GetClosestStopsByCoordinates/?coordinates=(X=".

$_REQUEST["X"].",Y=".$_REQUEST["Y"].")&proposals=5";

$data=file_get_contents($url);

echo utf8_decode($data);

?>

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

}


~ 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 email, 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, email) 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.

Tekstboks 1

$("#lokal_lagring").click(function()

{

var newDate = new Date();

var itemId = newDate.getTime();

var values = new Array();

var result ="<? print @$_SESSION['AT']; ?>";

var firstName = "<? print utf8_decode($_REQUEST["firstName"]); ?>";

var lastName = "<? print utf8_decode($_REQUEST["lastName"]); ?>";

var email = "<? print $_REQUEST["email"]; ?>";

values.push(result);

values.push(firstName);

values.push(lastName);

values.push(email);

try

{

localStorage.setItem(itemId, values.join(";"));

}

[...........]

});


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

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.

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.

Mozilla/4.5 [en] (X11; U; Linux 2.2.9 i586)

$agent = $_SERVER['HTTP_USER_AGENT'];

$osArray = array(

'Windows' => '(Win)',

'Linux' => '(X11)|(Linux)',

'MacOS' => '(Mac)'

);

foreach ((array) @$osArray as $os => $v)

{

if (preg_match("/$v/", $agent))

{

break;

}

else

{

$os = "Unknown OS";

}

}


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

Tekstboks 3

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;

}


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

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.

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.

if(localStorage.length > 0)

{

var localStorageArray = new Array();

for (i=0;i<localStorage.length;i++)

{

localStorageArray[i] = localStorage.getItem(localStorage.key(i));

}

}

else

{

window.location.href = 'registrer.php';

}

<script type="text/javascript">

$(document).ready(function ()

{

$('#trafikkflyt').rssfeed('http://devi.trafikanten.no/rss.aspx',

{

header: false

});

});

</script>


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

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.

function url_safe($input)

{

$letters = array(" ", "æ", "ø", "å", "Æ", "Ø", "Å");

$hexval = array("%20", "%E6", "%F8", "%E5", "%C6", "%D8", "%C5");

return $url = str_replace($letters, $hexval, "http://api-test.trafikanten.no" . $input);

}


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

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)

if($os == 'Windows')

{

echo "<a href='datepickerWindows.php...

}

if($os == 'Linux')

{

echo "<a href='datepickerAndroid.php...

}

if($os == 'MacOS')

{

echo "<a href='datepickerIos.php...

}


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

Figur 11 - Datovelger for Android

8.3 Windows Phone

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)


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

9.1.1 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


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

10.0 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.

10.1 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.

10.2 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 å tolke QR-

koden som et bilde.

iVBORw0KGgoAAAANSUhEUgAAAJYAAACWCAIAAAC

zY+a1AAAABmJLR0QA/wD/AP+gvaeTAAACgUlE\r\nQV

R4nO3dwW6jMBRA0WE0///L6aI7NKUlNoZbnbONEqW6s

vrkGNher9cfyv7e/QUYJWGehHkS5kmY\r\nJ2GehHkS5k

mYJ2GehHkS5kmYJ2GehHkS5kmYJ2GehHkS5kmY92/8

I7ZtG/+Qnzh12G73rXbvPfXq\r\ndaYcH7QK8yTMkzBPwr

wJ48zOxBP+I2PFxK/xkL/oK1ZhnoR5EuZJmDd/nNk59Q9

82f7LyIRy3V/0\r\nHqswT8I8CfMkzLt8nLnO8aRw/OrxsN

NiFeZJmCdhnoR54XFm5yHHYdazCvMkzJMwT8K8y8eZ

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.

Tekstboks 8

10.3 Kommunikasjon med API

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

<img src='data:image/png;base64," . $result->qrCode . "' alt='QRcode' width='65%' />


~ 28 ~

Tekstboks 9

10.4 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.

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.

10.5 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

foreach ($obj as $key)

{

if(strpbrk(utf8_decode($key->Name), '#') == null)

{

echo "...

}

}

$data = http_build_query(

array(

'firstName' => $_REQUEST['firstName'],

'lastName' => $_REQUEST['lastName'],

'email' => $_REQUEST['email'],

'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('http://lavkarbo.intele.com/ticketmock/authenticationtoken', false, $context);

$_SESSION['AT'] = $result;


~ 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. 240520121144).

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.

Tekstboks 10

iOS

I datovelgeren for iOS var datoformatet 01 Feb. 2012. Det måtte derfor kodes en funksjon

som gjorde om datoen til riktig format. Nedenfor følger denne koden.

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.

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";

}

[....]

}

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;

}


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

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 en @, 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.

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 inn @ 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.

Tekstboks 12

10.7 Tegnsett

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

$obj = json_decode(@file_get_contents($url));

@krsort($obj);

if($obj==false)

{

echo "Du har ingen billetter!”;

}

$url = "http://api-test.trafikanten.no/Travel/GetTravelsAfter?time=" . $time . "&from=" . $fromID . "&to=" .

$toID;

$obj = json_decode(@file_get_contents($url));

$_SESSION['time'] = $day . $monthNum . date("Y") . $hour . $minute;


~ 31 ~

Norge er ISO-8859-1. 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-8859-1. Figuren nedenfor (Tekstboks 13) viser at funksjonen brukes i utskriften av

stasjonsnavn.

Tekstboks 13

11 Kilder

Bekk. (2009, 10 14). http://open.bekk.no. Hentet 2012 fra http://open.bekk.no/json-ressurser-og-eksempel-

javascript-kode/

Cubiq. (2009). cubiq.org. Hentet 2012 fra http://cubiq.org/spinning-wheel-on-webkit-for-iphone-ipod-touch

Horst, T. M. (2010, 12 30). toddmhorst.wordpress.com. Hentet 2012 fra

http://toddmhorst.wordpress.com/2010/12/30/android-like-date-picker-with-jquery-mobile-2/

itpro.no. (2003, 08 21). itpro.no. Hentet 2012 fra http://itpro.no/artikkel/4098/definisjon-hva-er-php/

jquerymobile. (u.d.). jquerymobile.com. Hentet 2012 fra http://jquerymobile.com/

kodehjelp. (u.d.). www.kodehjelp.no. Hentet 2012 fra http://www.kodehjelp.no/opplaring/javascript-

nybegynner.aspx

Mobiscroll. (u.d.). blog.mobiscroll.com. Hentet 2012 fra http://blog.mobiscroll.com/

PHP. (2012, 05 25). php.net. Hentet 2012 fra http://php.net/manual/en/language.operators.errorcontrol.php

Wikipedia. (2012, 05 15). en.wikipedia.org. Hentet 2012 fra

http://en.wikipedia.org/wiki/Security_through_obscurity

Wikipedia. (2012, 05 18). no.wikipedia.org. Hentet 2012 fra http://no.wikipedia.org/wiki/HTML

{

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 />";

}


~ 1 ~

Del 3: Vedlegg


~ 2 ~

Innhold 1 Planer .................................................................................................................................................. 4

1 A- Fremdriftsplan............................................................................................................................. 4

1 B - Arbeidsplan ................................................................................................................................ 6

1 C - Milepælsplan .............................................................................................................................. 8

2 Modeller ............................................................................................................................................ 10

2 A- Use case .................................................................................................................................... 10

2 B - Detaljert use case beskrivelse - kjøp av billett .......................................................................... 11

2 C - Aktivitetsdiagram ..................................................................................................................... 12

3 Brukerveiledning ............................................................................................................................... 13

Ny reise ............................................................................................................................................ 15

Mine billetter ................................................................................................................................... 22

Innstillinger....................................................................................................................................... 24

Trafikkinformasjon ........................................................................................................................... 26

4 Prosjektbeskrivelse ............................................................................................................................ 27

Innholdsfortegnelse ........................................................................................................................... 28

Innledning ........................................................................................................................................... 29

Bakgrunn......................................................................................................................................... 29

Oppgaven ......................................................................................................................................... 30

Krav til operativsystem / plattformer ............................................................................................... 31

Systemarkitektur .................................................................................................................................. 32

Mobil klient ...................................................................................................................................... 32

Web Server ....................................................................................................................................... 32

Sanntidsdata..................................................................................................................................... 32

Tjenestelag ....................................................................................................................................... 33

Funksjonalitet ....................................................................................................................................... 34

Utseende .......................................................................................................................................... 34

Registering ....................................................................................................................................... 34

Navigasjon ........................................................................................................................................ 34

Ny reise ............................................................................................................................................ 35

Velg fra-stasjon............................................................................................................................. 35

Velg til-stasjon .............................................................................................................................. 35

Velg tidspunkt .............................................................................................................................. 35

Vis rute ......................................................................................................................................... 35


~ 3 ~

Kvittering ...................................................................................................................................... 36

Billetter............................................................................................................................................. 36

Ordreliste ..................................................................................................................................... 36

Vis billett ...................................................................................................................................... 36

Kontaktinformasjon Intelecom ............................................................................................................. 38

Nyttige linker ........................................................................................................................................ 38

Emulatorer / verktøy: ....................................................................................................................... 38

Annet ................................................................................................................................................ 38


~ 4 ~

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.

Oppgave

Før jul Uke 1 Uke 2

M T O T F M T O T F

Akt

ivit

eter

Fin

ne

op

pd

rags

give

r

Kontakte bedrifter

Avtale møte

Finne prosjekt til gruppen

avtale med arbeidsgiver

Lage prosjektskisse

Forprosjekt rapport

Pla

nle

gge

vid

ere

frem

gan

g Arbeidsplan

Fremdriftsplan

Milepælsplan

Prosjektrapport

Pro

gram

mer

ing

Geolokasjon

Kjøpe billett fra API

Reisplanlegger fra trafikanten

Kryptering

Bestille QR- billett

Lokal lagring

Implementering

Test

ing Teste på mobiltelefoner

Teste på emulatorer

Teste funksjoner

Mø

ter

Statusmøte med intelecom

Daglig møte med gruppa

Planleggingsmøte

Oppsumeringsmøte

Mile

pæ

ler

Forprosjekt

V: 0128

V: 0256

V: 0512

V: 1024

Ferdig applikasjon

Muntlig presentasjon


~ 5 ~

Forminsket skjermdump av prosjektets fremdriftsplan


~ 6 ~

1 B - Arbeidsplan

Ansvarlig Aktivitet Beskrivelse Planlagt Utført

Opprette gruppe Gruppen ble opprettet og meldt inn på prosjektsiden 15.09.2011

Statusrapport Beskrivelse av hva gruppen har gjort, og status på hva som skal gjøres 25.10.2011 28.10.2011

Prosjektskisse

Beskrivelse av prosjektet med så mange detaljer som mulig. Skolen skal godkjenne prosjektet på grunnlag av dette. 30.11.2011 02.12.2011

Forprosjektrapport Definere prosjektet. Sette opp rammer og gjøre klar for arbeidet. 25.01.2012 27.01.2012

Programmering

Atle og Alexander Geolokasjon

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. 10.02.2012 05.04.2012

Ludvig og Atle Lokal lagring

Applikasjonen skal kunne bruke lokal lagring til å lagre bruker og billett i nettleseren. 15.03.2012 20.04.2012

Alexander QR-billett Det skal være mulig for applikasjonen å kunne hente ned en QR billett. 25.02.2012 12.03.2012

Atle og Alexander Registrering av bruker

Få applikasjonen til å lagre en bruker gjennom oppdragsgivers API. 20.03.2012 15.03.2012

Ludvig Kryptering JavaScript koden skal obfuskeres og billetter skal være kryptert i lokal lagring. 20.03.2012 15.04.2012

Gisle + gruppa jQuery Mobile

jQuery Mobile skal være brukt som et rammeverk rundt applikasjonen slik at det blir en «native» følelse. 02.05.2012 10.05.2012

Atle Trafikkinformasjon Applikasjonen skal kunne hente trafikkinformasjon fra trafikantens API. 01.04.2012 15.04.2012

Gisle Implementering Implementere alle de ferdige funksjonene inn i versjonen med jQuery. 05.05.2012 15.05.2012

Design

Gruppa Tema og farger Lage en design til applikasjonen 01.03.2012 15.03.2012

Gisle Implementere Sette inn ferdig funksjoner i versjon med design. 20.03.2012 28.05.2012


~ 7 ~

Dokumentasjon

Ludvig Milepælsplan Sette opp milepæler som gruppa skal følge. 15.02.2012 20.02.2012

Gisle Arbeidsplan Fordele oppgaver blant gruppemedlemmene 15.01.2012 20.02.2012

Alexander Fremdriftsplan Planlegging av fremdriften til gruppa. 15.01.2012 25.01.2012

Gruppa Rapport Den avsluttende rapporten som skal leveres inn. 01.04.2012 28.05.2012

Testing

Gruppa Programmerings testing

Teste om applikasjonens funksjoner kjører slik de skal. Kontinuerlig Kontinuerlig

Gruppa Testing på forskjellige mobile enheter

Teste på ulike mobile enheter for å sikret at applikasjonen kjører på de forskjellige operativsystemene. 20.03.2012 25.05.2012


~ 8 ~

1 C - Milepælsplan

Versjon: V:0.128

Start: 14.02.2012

Slutt: 01.03.2012

Beskrivelse: Geolokasjon funksjonen skal være ferdig.

Design: Knapper og farger på plass.

Kunne bestille enkel billett med QR-kode.

Versjon: V:256

Start: 01.03.2012

Slutt: 20.03.2012

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: 20.03.2012

Slutt: 10.04.2012

Beskrivelse:

Design: ”Native” feel på enheter.

Obfuskere (skjule) Javascript.


~ 9 ~

Versjon: V 1.024

Start: 10.04.2012

Slutt: 01.05.2012

Beskrivelse: Fullt fungerende applikasjon

Beta testing(debugging)

Versjon: Ferdig Applikasjon

Start: 01.05.2012

Slutt: 15.05.2012

Beskrivelse: Alle kravene fra rammebetingelsen skal være oppnådd.


~ 10 ~

2 Modeller

2 A- Use case


~ 11 ~

2 B - Detaljert use case beskrivelse - kjøp av billett

Use Case Kjøp av billett

Mål Få kjøpt en ny billett

Aktør Bruker

Trigger Brukeren trenger en billett for å bruke kollektivtransport

Pre-betingelser Kunden er registrert og har tilgang til en mobil med nettilgang og

nettleser

Post-betingelser Kunden får kjøpt billett

Normal hendelsesflyt

(normale transaksjoner)

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

variasjoner 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


~ 12 ~

2 C - Aktivitetsdiagram


~ 13 ~

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


~ 14 ~

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


~ 15 ~

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


~ 16 ~

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


~ 17 ~

Figur 7 - Datovelger for Windows Phone

Figur 8 - Datovelger for Android


~ 18 ~

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


~ 19 ~

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


~ 20 ~

Om brukeren skriver feil passord vil en melding vises med beskjed om feilen (Figur 11).

Figur 11 - Bekreft billett - feil passord


~ 21 ~

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


~ 22 ~

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


~ 23 ~

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)


~ 24 ~

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


~ 25 ~

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


~ 26 ~

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


~ 27 ~

4 Prosjektbeskrivelse

Versjon 1.0

Sist endret January 2012

Endret av Sven Ståle Osa

Contact Information:

Sven Ståle Osa [email protected]

C



~ 28 ~

Innholdsfortegnelse

1 Innholdsfortegnelse ...................................................................................................................... 28

2 Innledning ..................................................................................................................................... 29

2.1 Bakgrunn ................................................................................................................................. 29

2.2 Oppgaven ............................................................................................................................ 30

2.3 Krav til operativsystem / plattformer .................................................................................. 31

3 Systemarkitektur ........................................................................................................................... 32

3.1 Mobil klient ............................................................................................................................. 32

3.2 Web Server ......................................................................................................................... 32

3.3 Sanntidsdata ....................................................................................................................... 32

3.4 Tjenestelag .......................................................................................................................... 33

4 Funksjonalitet................................................................................................................................ 34

4.1 Utseende ............................................................................................................................. 34

4.2 Registering .......................................................................................................................... 34

4.3 Navigasjon ........................................................................................................................... 34

4.4 Ny reise ............................................................................................................................... 35

4.4.1 Velg fra-stasjon ............................................................................................................... 35

4.4.2 Velg til-stasjon ................................................................................................................ 35

4.4.3 Velg tidspunkt ................................................................................................................. 35

4.4.4 Vis rute............................................................................................................................ 35

4.4.5 Kvittering ........................................................................................................................ 36

4.5 Billetter ............................................................................................................................... 36

4.5.1 Ordreliste ........................................................................................................................ 36

4.5.2 Vis billett ......................................................................................................................... 36

5 Kontaktinformasjon Intelecom ..................................................................................................... 38


~ 29 ~

Innledning

Bakgrunn

Intelecom har jobbet med å tilrettelegge kommunikasjon mellom bedrifter og kunder i gjennom mange faser av

mobiltelefonens historie. Mobil tjenesteutvikling for Intelecom sin del startet med enkle tale og SMS tjenester

på slutten av 1990 tallet og har i løpet av de siste årene endret seg i takt med markedet mot mobile

applikasjoner.

I starten av 2012 står man ovenfor mange alternativer når det gjelder hvordan man utvikler mobile

applikasjoner:

«Native» applikasjoner - som er 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

naturlig som en del av operativsystem med tanke på brukeropplevelsen. Ulempen er at man må utvikle

hver applikasjon i sin helhet for hvert operativsystem og bedriften må ivareta kompetanse på mange

ulike programmeringsspråk og rammeverk. For å få tak i applikasjonen må kunden som regel finne og

laste ned denne via en «app store». Dette byr på utfordringer knyttet til distribusjon for bedrifter som

trenger å installere applikasjonen til en lukket brukergruppe (som f.eks en intern applikasjon for et

helseforetak). Slike applikasjoner må også for enkelte av operativsystemene, som iOS og Windows

Phone, godkjennes av produsentene av operativsystemene før de blir tilgjengelige for nedlastning.

Hybrid applikasjoner – som er applikasjoner utviklet via tredjeparts rammeverk som PhoneGap, Sencha

eller Titanium. Her benytter man rammeverk og utviklingsmiljø fra leverandører hvor man som regel

koder utseendet til applikasjonen som en webside. Forskjellen er at man har muligheten til å legge en

«native ramme» rundt applikasjonen og via denne har mulighet til å kalle på «native» funksjoner som

kontaktliste, kamera, kalender osv. Den kan også distribueres via de ulike appstores. Ulempen er at en

slik applikasjon gjerne vil ha en annerledes brukeropplevelse enn det de forventer når man laster den

en native applikasjon og den krever også likevel at man har en inngående kunnskap om de enkelte

plattformene for å utnytte «native» funksjoner. Man må også installere og forholde seg til mange

forskjellige utviklingsverktøy og operativsystem (f.eks Xcode / Mac) for de ulike plattformene. Det

finnes dog cloud baserte tjenester for f.eks Phone Gap som gjør dette noe enklere (men koster penger).

Som for native applikasjoner så må også applikasjonene som lages som hybrider igjennom

godkjenningsprosessene før de blir tilgjengelige på app stores.

Dedikert mobil web applikasjon – en web applikasjon som kjører som en vanlig webside på en ekstern

server og er tilgjengeliggjort via mobilen sin nettleser. En dedikert mobil web applikasjon er

skreddersydd for spesifikke operativsystem eller telefontyper og vil ikke fungere for eldre mobile

nettlesere. Slike sider setter altså spesifikke krav til hvilken mobiltelefon man aksesserer sidene via.

Ofte vil slike sider sperre ute de telefonene som har nettlesere som ikke er støttet eller sende disse til

en egen side for slike terminaler. Fordelen med en mobil web applikasjon er at man ikke trenger å lære

seg alle de ulike programmeringsspråkene og rammeverkene som er nødvendig for native utvikling.

Det er ikke mulig å distribuere slike applikasjoner via app store, men det gir også en mulighet for

enklere distribusjon for bedrifter med lukkede brukergrupper (ref første punkt). Rammeverk slik som

jQuery mobile gjør det raskere og enklere å lage gode brukergrensesnitt mot touch skjermer. En

ulempe er at tilgangen til telefonens hardware er meget begrenset per i dag, det finnes muligheter for

geolokasjon, men utover det så det begrensede muligheter for å utnytte ting som hardware knapper,

kamera og kontaktliste. Selv om det er ventet at dette skal bli langt bedre støttet i fremtiden er det en

utfordring per i dag at det finnes for mange ulike arbeidsgrupper på dette området som jobber separat


~ 30 ~

i stedet for å jobbe mot en felles standard.

Generisk mobil applikasjoner – mobile websider som skal fungere på enhver mobil enhet med en

nettleser. Per i dag er dette svært tradisjonelle mobile websider for å vise informasjon som knapt nok

kan kalles en mobil applikasjon.

Sammenlikning av ulike metoder for utvikling av mobil applikasjoner (kilde: worklight)

En trend i markedet er at selskaper som tradisjonelt har jobbet med web utvikling har primærfokus på å utvikle

med HTML5 / jQuery mobile. På den andre siden har programvarehus / systemintegratører en tendens til å

jobbe mot native applikasjoner. Dette er naturlig opp i mot den komptetansen som slike ulike selskap ofte

besitter.

Intelecom er i den siste kategorien, som har tradisjonelt jobbet med systemintegrasjon, baksystemer og egne

native frontend produkter. Selv om Intelecom har jobbet mye på web så er dette gjerne sammen med et

webbyrå som lager frontend (HTML, CSS og Javascript), Intelecom legger så på forretningslogikken i sidene.

I 2011 har Intelecom fått store kontrakter innen mobil applikasjons utvikling, spesielt innenfor transport segmentet. Disse applikasjonene har blitt utviklet som native applikasjoner, etter kundenes krav og ønsker. Selv om Intelecom har sitt primærfokus på native applikasjoner på mobil så følger vi nøye med på hva som skjer rundt HTML5 og mobile web applikasjoner. De potensielle fordelene med HTML5 og mobile web rammeverk er mange og per i dag er som tidligere distribusjonsmodellene til appstores ikke veldige fleksible.

Oppgaven

Med utgangspunkt i Intelecom sin bakgrunn innenfor mobile applikasjoner til transportsegmentet, da spesielt innenfor løsninger for billett- salg og distribusjon, ønsker vi at prosjektet utvikler en prototype på en mobil billettautomat innenfor kategorien dedikert web applikasjon (se over).


~ 31 ~

Vi ønsker spesiell fokus på fire områder som vi anser som utfordringer i en dedikert web applikasjon:

1. Brukergrensesnitt; hvordan utvikle et grensesnitt som fungerer godt for de tre primære plattformene som er utbredt i Norge: iOS (iPhone og iPad), Android og Windows Phone 7. Hva er mulighetene i en dedikert web applikasjon for å gjøre tilpasninger til operativsystemet som bruker kommer fra? Dette med tanke på generell look and feel (se Jquery Mobile Themes) eller spesifikke kontrollere (date pickers etc.) for de ulike operativ systemene.

2. Device API; hva er mulighetene for integrasjon mot telefonens funksjoner i HTML5 per i dag. W3C har en arbeidsgruppe mot dette, se http://www.w3.org/2011/07/DeviceAPICharter og http://www.w3.org/2009/dap/. Geolokasjon er en egen arbeidsgruppe i W3C som også tar for seg mobiltelefonens orientering (se: http://www.w3.org/2008/geolocation/). Vi ønsker en implementasjon av geolokasjon i prototypen. Dersom tiden strekker til ønsker vi også en skriftlig utredning som en del av besvarelsen rundt de viktigste initiativene i W3C knyttet til integrasjon mot telefonens funksjoner. Hva jobbes det med? Hva er tidslinjene før disse rammeverkene kan tilby funksjonalitet opp mot native utvikling? Og hvilke utfordringer ser man knyttet til at mobile nettsider får tilgang til slike funksjoner(personvern, sikkerhet, brukervennlighet (får man f.eks advarsel som på geolokasjon for hver funksjon?), ulike støtte for terminaltyper etc.). Finnes det noen initativ som ser på hvordan HTML5 kan få tilgang til NFC brikker? For en oversikt over initiativer rundt HTML5 fra W3C se: http://dret.typepad.com/dretblog/html5-api-overview.html

3. Lokal lagring; hvordan sikre at kritisk data i applikasjonen er tilgjengelig selv om mobilen ikke

har tilgang til mobilt data nettverk. For en applikasjon som skal fungere som en billettbærer er det kritisk at bruker har tilgang til visse deler av innholdet, spesielt billetten, dersom man befinner seg på steder uten mobil dekning. Web storage er en spesifikasjon som opprinnelig var en del av HTML5 (http://dev.w3.org/html5/webstorage/) som omhandler lokal lagring av innhold i nettleseren. Denne standarden er støttet av alle de mobile operativsystemene som vi ønsker at prototypen skal støtte (se: http://mobilehtml5.org). Web Storage skal benyttes for å lagre dynamisk innhold (som f.eks billetten) og vi ønsker at HTML app cache (cache manifest) benyttes for å lagre statisk innhold lokalt. Det er ønskelig at det utføres tester rundt hvordan applikasjonen fungerer «offline» med bruk av disse to (evt. tilsvarende) hjelpemidlene i HTML5.

4. Sikkerhet – Knyttet til lokal lagring, kan man på noen måte sikre innholdet i den lokale databasen slik at det ikke er rett frem å hente ut innholdet i databasen. Er det mulig å kryptere innholdet på noen måte? Knyttet til beskyttelse av forretningslogikken, finnes det gode måter å obfuskere javascript koden på? Er det et bedre alternativ at den delen av forretningslogikken som håndterer autentisering, kjøp etc. lages i baksystemet slik at logikken ikke sendes til klienten?

Krav til operativsystem / plattformer

Det er ønskelig at prototypen støtter følgende:

iOS (iPhone / iPad) – OS versjon 4 og nyere

Android – OS versjon 2.2 og nyere

http://www.w3.org/2011/07/DeviceAPICharter

http://www.w3.org/2009/dap/

http://www.w3.org/2008/geolocation/

http://dret.typepad.com/dretblog/html5-api-overview.html

http://dev.w3.org/html5/webstorage/

http://mobilehtml5.org/


~ 32 ~

Windows Phone 7 – Versjon 7.5 (Mango) og nyere

Systemarkitektur

Mobil klient

Mobil klienten utvikles av prosjektet. Her primært ønskes HTML5 / Jquery mobile (http://jquerymobile.com/)

benyttet til utviklingen.

Web Server

Filene til webapplikasjonen lagres på web server som for en vanlig webside. Dersom prosjektet ikke har

mulighet til å sette opp en webserver med public DNS for prosjektet så kan Intelecom være behjelpelig med

dette. Oppdragsgiver setter ingen begrensninger knyttet til hvilket programmeringsspråk som benyttes på

server siden.

Sanntidsdata

Sanntidsdata hentes fra Trafikanten sitt åpne grensesnitt:

http://labs.trafikanten.no/2011/3/22/hvordan-bruke-json-data.aspx

http://labs.trafikanten.no/2011/9/2/reiseplanlegging.aspx

URL til å sende forespørsler mot:

http://jquerymobile.com/

http://labs.trafikanten.no/2011/3/22/hvordan-bruke-json-data.aspx

http://labs.trafikanten.no/2011/9/2/reiseplanlegging.aspx


~ 33 ~

http://api-test.trafikanten.no/

Intelecom har registrert seg som bruker mot API’et, men per i dag er det ikke noen krav om autentisering

(Oauth er planlagt, men ikke implementert).

Tjenestelag

Tjenestelaget utvikles av Intelecom og tilbyr følgende metoder:

createAuthenticationToken(firstName, lastName, email, password) -> authenticationToken

purchase(fromStop, toStop, time, authenticationToken, password) -> orderId

getOrders(authenticationToken) -> order list

getTicket(authenticationToken, orderId) -> ticket (QR code)

Tjenestene er spesifisert som et REST API med JSON over HTTP. AuthenticationToken kan ligge som header-

element i metodene purchase, getOrders og getTicket.

Tjenestene knyttet til kjøp er en «mock» tjeneste og er ikke koblet opp mot noen PSP. Denne vil alltid returnere

et ok kjøp.

Tjenestene skal være ferdig utviklet medio februar 2012.

http://api-test.trafikanten.no/


~ 34 ~

Funksjonalitet

Utseende

Intelecom sin logo og overordnede grafiske profil skal benyttes.

Registering

Første gang applikasjonen tas i bruk på en mobil nettleser på en telefon så må brukeren registrere seg. Dette

gjøres ved å skrive inn:

Fornavn

Etternavn

E-post adresse

Passord

Når denne informasjonen er hentet inn fra bruker så kalles følgende metode mot tjenestelaget:

createAuthenticationToken(firstName, lastName, email, password) -> authenticationToken

Denne tjenesten returnerer en verdi som representerer denne brukeren sin «installasjon» av applikasjonen på

en enhet. Denne benyttes videre i autentisering mot de andre metodene. Verdien må lagres lokalt i

applikasjonen (via web storage) inntil den slettes. Det må gjøres en sjekk når bruker går inn på applikasjonen

om det finnes en authenticationToken allerede registrert lokalt. Dersom denne finnes så skal ikke

registreringssiden vises.

For å forenkle applikasjonen så finnes det ikke noen autentisering utover dette (ingen bruker begrep).

Det bør finnes et valg for å slette autentisering («logg ut») fra innstillinger siden (se under). Etter registrering

tas brukeren til siden for ny reise.

Navigasjon

Brukeren navigerer via en meny som gir følgende valg:

Ny reise (4.4)

Billetter (4.5)

Innstillinger (4.6)

Disse valgene bør alltid være tilgjengelige i en synlig meny eller faner uansett hvor bruker navigerer.

Alternativt kan det implementeres en «startside» eller «hovedside» som viser disse valgene og at det alltid

finnes en mulighet til å navigere tilbake til denne. Da bør i såfall dette være siden man kommer til etter første

gangs registrering.

NB: Det bør vurderes om adresselinjen i nettleseren skal skjules for å få mer plass. Se

http://www.html5rocks.com/en/mobile/mobifying.html

http://www.html5rocks.com/en/mobile/mobifying.html


~ 35 ~

Ny reise

Valget «Ny reise» benyttes for å finne en bestemt reise og alternativt kjøpe en billett til reisen. For kallene frem

til «kjøp billett» så benyttes Trafikanten sitt grensesnitt.

Velg fra-stasjon

Her må stasjoner i nærheten listes ut som muligheter for hurtigvalg. Bruk HTML5 geolokasjon for å hente

brukeren sin lokasjon og benytt metoden:

"/Place/GetClosestStopsByCoordinates/?coordinates=(X=593918,Y=6644077)&proposals=7" , koordinatene

man må sende inn koordinatene i UTM32. Dersom det er nødvendig å konvertere mellom systemene så kan

f.eks JSCoord benyttes (http://www.jstott.me.uk/jscoord/ )

I tillegg til «stasjoner i nærheten» så må brukeren ha et felt for å skrive inn en fra stasjon. Her kan auto

complete benyttes via API’et:

http://api-test.trafikanten.no/Place/Autocomplete/inntastet_tekst_fra_bruker , f.eks. http://api-

test.trafikanten.no/Place/Autocomplete/jar

Som en opsjon (hvis tid) kan «sist brukte stasjoner» vises. Disse bør hentes fra web storage (krever at siste

valgte av bruker lagres lokalt).

Velg til-stasjon

Samme som 4.4.1, men uten «stasjoner i nærheten».

Velg tidspunkt

Her velges dato / klokkeslett. Evt. bare klokkeslett. Det kan vurderes om man ser på ulike «plugins» til Jquery

Mobile for å få datovelgeren til å være native for operativsystemet som brukeren benytter. Se f.eks:

http://toddmhorst.wordpress.com/2010/12/30/android-like-date-picker-with-jquery-mobile-2/ eller

http://davidbcalhoun.com/2011/new-mobile-safari-stuff-in-ios5-position-fixed-overflow-scroll-new-input-type-

support-web-workers-ecmascript-5 (se «new input types»). Sistnevnte er HTML5 (ikke Jquery mobile, men

fungerer dog bare for iOS5).

Vis rute

Etter at man har valgt fra- stasjon, til-stasjon og tidspunkte så gjør man et søk via rutesøk API’et til Trafikanten.

Deretter får man opp et ruteforslag.

http://www.jstott.me.uk/jscoord/

http://api-test.trafikanten.no/Place/Autocomplete/inntastet_tekst_fra_bruker

http://api-test.trafikanten.no/Place/Autocomplete/jar

http://api-test.trafikanten.no/Place/Autocomplete/jar

http://toddmhorst.wordpress.com/2010/12/30/android-like-date-picker-with-jquery-mobile-2/

http://davidbcalhoun.com/2011/new-mobile-safari-stuff-in-ios5-position-fixed-overflow-scroll-new-input-type-support-web-workers-ecmascript-5

http://davidbcalhoun.com/2011/new-mobile-safari-stuff-in-ios5-position-fixed-overflow-scroll-new-input-type-support-web-workers-ecmascript-5


~ 36 ~

Bruker kan deretter trykke på en knapp for å gjøre et kjøp på en rute. Pris kan gjerne vises her, men denne kan

bare ligge hardkodet i applikasjonen.

Når bruker trykker kjøp så kalles følgende metode fra tjenestelaget:

purchase(fromStop, toStop, time, authenticationToken, password)

Kvittering

Purchase metoden fra tjenestelaget returnerer en generert ordreid. Denne kan vises sammen med

reisestrekning til sluttbruker i en kvitteringside.

Fra kvitteringssiden får man også et valg for å gå til «mine billetter». Da lastes siden som beskrevet i 4.5 (dette

er samme side som fra menyvalget «billetter»)

Billetter

Dette er sider for å hente en liste over billetter tilhørende en bruker (authenticationToken) og vise enkelt

billetter (med QR kode).

Ordreliste

Når bruker trykker på menyvalget «billetter» (evt. sendes trykker på knappen på kvitteringssiden) så skal det

vises en liste over ordre. I prototypen så har ikke billetten noen status, så det vil si at alle billetter er «aktive».

Ordrelisten hentes per bruker (authenticationToken) via følgende metode på tjenestelaget:

getOrders(authenticationToken) -> order list

Siden skal vise en liste over ordre, og her skal bruker kunne trykke på en av reisene for å hente billetten. (se

4.5.2)

Vis billett

Når bruker trykker på en billett i ordrelisten så gjøres følgende kall mot tjenestelaget:

getTicket(authenticationToken, orderId) -> ticket (QR code)

Tjenesten returnerer en objekt som inneholder QR koden (bilde) samt reisedata (fra stasjon, til stasjon og

tidspunkt).

Denne informasjonen skal presenteres til sluttbruker som en billett, altså QR kode skal vises sammen med

reisedata.


~ 37 ~

4.6 Innstillinger

Innstillinger er en enkel side som lar bruker administrere valg knyttet til applikasjonen. Utover valget for å slette

autentiseringen så står prosjektet fritt til å legge inn fornuftige valg her.


~ 38 ~

Kontaktinformasjon Intelecom

Følgende ansatte i Intelecom er tilgjengelig for prosjektgruppen i løpet av prosjektet

Navn Rolle Telefon E-post

Sven Ståle Osa Hovedkontakt 41915558 [email protected]

Gunnar Grenlee Tjenestelag / baksystem 41915590 [email protected]

Thomas Tretli Android 90645914 [email protected]

Morten Trydal iOS / WP7 47020203 [email protected]

Ronald Kløverød Database / andre avklaringer 99266320 [email protected]

Nyttige linker

Emulatorer / verktøy:

Android's Browser Emulator

iOS SDK & Simulator

Windows Phone 7 Emulator

Firefox Mobile Emulator

caniuse.com

Mobile HTML5 Boilerplate

Weinre - remote web inspector debugging

Mobile Performance Bookmarklets by Steve Souders

Jdrop

Annet

http://jquerymobile.com


http://taitems.tumblr.com/post/7240874402/ios-inspired-jquery-mobile-theme-jquery-mobile

http://www.engineyard.com/blog/2011/mobile-development-with-html5/

http://en.wikipedia.org/wiki/File:HTML5-APIs-and-related-technologies-by-Sergey-Mavrody.png

http://www.mobilehtml5.com/

http://www.jjoe64.com/2011/09/android-theme-for-jquery-mobile.html

http://www.html5rocks.com/en/mobile/

http://pinchzoom.com/posts/anatomy-of-a-html5-mobile-app/anatomy-of-a-html5-mobile-app





http://developer.android.com/guide/developing/tools/emulator.html

http://developer.apple.com/devcenter/ios/index.action

http://www.microsoft.com/download/en/details.aspx?id=27570

http://www.mozilla.org/en-US/mobile/

http://caniuse.com/

https://github.com/shichuan/mobile-html5-boilerplate

http://pmuellr.github.com/weinre/

http://stevesouders.com/mobileperf/

http://www.stevesouders.com/blog/2011/02/16/jdrop-json-in-the-cloud/

http://jquerymobile.com/


http://taitems.tumblr.com/post/7240874402/ios-inspired-jquery-mobile-theme-jquery-mobile

http://www.engineyard.com/blog/2011/mobile-development-with-html5/

http://en.wikipedia.org/wiki/File:HTML5-APIs-and-related-technologies-by-Sergey-Mavrody.png

http://www.mobilehtml5.com/

http://www.jjoe64.com/2011/09/android-theme-for-jquery-mobile.html

http://www.html5rocks.com/en/mobile/

http://pinchzoom.com/posts/anatomy-of-a-html5-mobile-app/anatomy-of-a-html5-mobile-app


~ 39 ~

Documents

Hovedprosjekt 2012 - Gruppe 13 - HiOAstudent.cs.hioa.no/hovedprosjekter/data/2012/13/Prosjekt... · 2012-06-03 · Hovedprosjekt 2012 - Gruppe 13 ~ 2 ~ 1 Forord Denne rapporten tar