Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
Hovedprosjekt 2012 - Gruppe 13
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
Hovedprosjekt 2012 - Gruppe 13
Hovedprosjekt 2012 - Gruppe 13
Forord
Denne rapporten skal beskrive de forskjellige prosessene som inngår i arbeidet med
hovedprosjektet ved Høgskolen i Oslo og Akershus, avdeling for ingeniørutdanning, våren
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.
Hovedprosjekt 2012 - Gruppe 13
~ 1 ~
Del 1: prosessdokumentasjon
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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)
Hovedprosjekt 2012 - Gruppe 13
~ 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)
Hovedprosjekt 2012 - Gruppe 13
~ 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)
Hovedprosjekt 2012 - Gruppe 13
~ 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)
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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)
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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)
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 1 ~
Del 2: Produktdokumentasjon
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 6 ~
4 Presentasjon av applikasjonen
4.1 Applikasjonens hoveddeler
Nedenfor følger en presentasjon av applikasjonens hoveddeler.
Figur 1 - Strukturkart
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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)
Hovedprosjekt 2012 - Gruppe 13
~ 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" />
Hovedprosjekt 2012 - Gruppe 13
~ 14 ~
6 Baksystemer
Figuren nedenfor (Figur 8) viser applikasjonens systemarkitektur. Her er oppdragsgivers og
Trafikantens API tegnet inn som henholdsvis web tjenestelag og sanntidsdata. Den mobile
klienten er ikke koblet direkte til tjenestelaget, men må gå gjennom skolens web server hvor
applikasjonens filer er lagret. Baksystemene kan ikke kommunisere direkte med hverandre.
Figur 8 - Systemarkitektur
To APIer ble benyttet i applikasjonen. Det ene er utviklet av Trafikanten, mens det andre ble
satt opp av gruppens oppdragsgiver i sammenheng med dette prosjektet.
6.1 Oppdragsgivers API
Ligger bak: 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}
Hovedprosjekt 2012 - Gruppe 13
~ 15 ~
6.1.2 /purchase (POST)
For å kjøpe en ny billett. Returnerer en kvitteringsmelding.
Eksempel på inn-parametere:
{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.
Eksempel på inn-parametere:
/orders/574bf7c0-8ebe-4a51-9746-97f2e0074b85
6.1.4 /ticket/{orderId}?authenticationToken={authenticationToken} (GET)
Returnerer en billett.
Eksempel på inn-parametere:
/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.
Eksempel på inn-parametere:
/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.
Eksempel på inn-parametere:
/Travel/GetTravelsAfter?time=220320110934&from=3011320&to=3010013
Hovedprosjekt 2012 - Gruppe 13
~ 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.');
}
Hovedprosjekt 2012 - Gruppe 13
~ 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);
}
Hovedprosjekt 2012 - Gruppe 13
~ 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(";"));
}
[...........]
});
Hovedprosjekt 2012 - Gruppe 13
~ 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";
}
}
Hovedprosjekt 2012 - Gruppe 13
~ 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;
}
Hovedprosjekt 2012 - Gruppe 13
~ 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>
Hovedprosjekt 2012 - Gruppe 13
~ 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);
}
Hovedprosjekt 2012 - Gruppe 13
~ 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...
}
Hovedprosjekt 2012 - Gruppe 13
~ 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)
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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%' />
Hovedprosjekt 2012 - Gruppe 13
~ 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;
Hovedprosjekt 2012 - Gruppe 13
~ 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;
}
Hovedprosjekt 2012 - Gruppe 13
~ 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;
Hovedprosjekt 2012 - Gruppe 13
~ 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 />";
}
Hovedprosjekt 2012 - Gruppe 13
~ 1 ~
Del 3: Vedlegg
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 3 ~
Kvittering ...................................................................................................................................... 36
Billetter............................................................................................................................................. 36
Ordreliste ..................................................................................................................................... 36
Vis billett ...................................................................................................................................... 36
Kontaktinformasjon Intelecom ............................................................................................................. 38
Nyttige linker ........................................................................................................................................ 38
Emulatorer / verktøy: ....................................................................................................................... 38
Annet ................................................................................................................................................ 38
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 5 ~
Forminsket skjermdump av prosjektets fremdriftsplan
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 10 ~
2 Modeller
2 A- Use case
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 12 ~
2 C - Aktivitetsdiagram
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 17 ~
Figur 7 - Datovelger for Windows Phone
Figur 8 - Datovelger for Android
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 20 ~
Om brukeren skriver feil passord vil en melding vises med beskjed om feilen (Figur 11).
Figur 11 - Bekreft billett - feil passord
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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)
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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).
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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:
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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.
Hovedprosjekt 2012 - Gruppe 13
~ 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://mobilehtml5.org/
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
Hovedprosjekt 2012 - Gruppe 13
~ 39 ~