Hovedprosjekt Gruppe 13. Del 3: Vedlegg ~ 1 ~

Transkript

1 Del 3: Vedlegg ~ 1 ~

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

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

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

5 Forminsket skjermdump av prosjektets fremdriftsplan ~ 5 ~

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

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

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

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

10 2 Modeller 2 A- Use case ~ 10 ~

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

12 2 C - Aktivitetsdiagram ~ 12 ~

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

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

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

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

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

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

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

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

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

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

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

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

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

27 4 Prosjektbeskrivelse C Versjon 1.0 Sist endret January 2012 Endret av Sven Ståle Osa Contact Information: Sven Ståle Osa sven.stale.osa@intele.com ~ 27 ~

28 Innholdsfortegnelse 1 Innholdsfortegnelse Innledning Bakgrunn Oppgaven Krav til operativsystem / plattformer Systemarkitektur Mobil klient Web Server Sanntidsdata Tjenestelag Funksjonalitet Utseende Registering Navigasjon Ny reise Velg fra-stasjon Velg til-stasjon Velg tidspunkt Vis rute Kvittering Billetter Ordreliste Vis billett Kontaktinformasjon Intelecom ~ 28 ~

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

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

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 og Geolokasjon er en egen arbeidsgruppe i W3C som også tar for seg mobiltelefonens orientering (se: 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: 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 ( 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: 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 ~ 31 ~

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 ( 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: URL til å sende forespørsler mot: ~ 32 ~

33 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, , 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 headerelement 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 ~ 33 ~

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

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 Samme som 4.4.1, men uten «stasjoner i nærheten». Velg tidspunkt 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= )&proposals=7", koordinatene man må sende inn koordinatene i UTM32. Dersom det er nødvendig å konvertere mellom systemene så kan f.eks JSCoord benyttes ( ) 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: f.eks. 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 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: eller (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. ~ 35 ~

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

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

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 Sven.osa@intele.com Gunnar Grenlee Tjenestelag / baksystem Gunnar.grenlee@intele.com Thomas Tretli Android Thomas.tretli@intele.com Morten Trydal ios / WP Morten.trydal@intele.com Ronald Kløverød Database / andre avklaringer Ronald.kloverod@intele.com 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 ~ 38 ~

39 ~ 39 ~