Infotainment System HPR/D-2015/001

Transkript

1 Infotainment System HPR/D-2015/001 av Christian K Haraldseid, Mikal Svendsen Bachelorrapport for DAT 304 våren 2015 Veileder: Christian Auby, Halvard Øysæd Fakultet for teknologi og realfag Universitetet i Agder Grimstad, Mai 2015 Status: Endelig Nøkkelord: Android, Fjernstyring, GPS, Mobilt internett, Informasjonstavle Resymé: Prosjektet tar sikte på å lage en komplett løsning for et informasjonssystem til bruk i transportsektoren, primært til bruk i buss. Løsningen skal presentere brukeren med informasjon naturlig for reisen, slik som rutetider, ankomst og posisjon. I tillegg skal løsningen være modulbasert slik at andre tilleggsfunksjoner som nyheter, reklame og lignende kan implementeres. Løsningen er utviklet for Android-plattformen, og skal kjøres på større skjermer i kjøretøyet. Ingen interaksjon er krevd av bruker, og systemet er designet for ekstern styring. Større utfordringer som variabel internett- og GPS-tilgang har vært fokusområde. Forskjellige strategier er tatt i bruk, blant annet bytting av nevnte moduler i områder uten god dekning, samt mellomlagring og utnyttelse av variabler som allerede er kjent. Resultatet er en løsning som effektivt håndterer nevnte problemer på en grei måte uten at brukeren selv opplever utfall av tjenester. Side 1

2 Forord Denne rapporten er skrevet som hovedoppgave (bachelor-oppgave) i faget DAT304 ved Universitet I Agder, på linjen Datateknikk. Oppgaven, og/eller problemstillingen er levert av Red Rock A/S som en konseptutredelse, for å utforske mulighetene for å utvide et allerede eksisterende billettsystem kalt «TOGITAL». Infotainment-System (dette prosjektet) er da en tiltenkt utvidelse av det eksisterende systemet som en totalløsning beregnet mot transportsektoren. Utviklingen foregår primært på Universitetet / Privat under oppfølging av oppdragsgiver. Prosjektdeltagerne ønsker å rette en spesiell takk til Chief International Officer Eirik Vika og Chief Project Officer (IT & Consulting) Morten Rønning ved RedRock for god veiledning, og anskaffelse av nødvendig utstyr i prosjektperioden. En takk rettes også til universitetslektor Christian Auby og universitetslektor Halvard Øysæd, for god veiledning under hele prosjektperioden. I tillegg ønsker gruppen å takke Espen R Nedrebø for retting og korrekturlesning. Grimstad 27 Mai 2015 Christian K Haraldseid Mikal Svendsen Side 2

3 Innhold 1 Innledning Bakgrunn Problemdefinisjon Mål Detaljspesifiserte mål Forutsetninger og begrensninger Avgrensninger Forutsetninger Problemløsning Prioritet A (Høy) Prioritet B (Middels) Prioritet C (Lav) Verktøy Løsningsstrategi Rapportstrukturen Teknisk bakgrunn Android Grunnprinsipper Rammeverk og innebygde funksjoner Løsningsforslag Hardware Produktdesign Løsning Enhet / Hardware Applikasjon Kartmodul Teknologi Krav Komponenter Virkemåte Forbedringer Drøfting Rutemodul Teknologi Krav Komponenter Virkemåte Forbedringer Drøfting og testing Nyhetsmodul Teknologi Krav Komponenter Virkemåte Drøfting og testing Mediamodul Teknologi Krav Komponenter Virkemåte Forbedringer Server Teknologi Krav Virkemåte Side 3

4 4.7.4 Komponenter Forbedringer Drøfting og testing Diskusjon Konklusjon Bibliografi Figurer Vedleggs liste Vedlegg A - Terminlogi Vedlegg B - Designutvikling Vedlegg C - Møtereferater Vedlegg D - Gannt Vedlegg E - Timelister Vedlegg F - Forstudierapport Vedlegg G - Pressemelding Vedlegg H - Bidragsytelse Eksterne ressurser Simple-Rss2-Android Bootstrap Vedlegg Side 4

5 1 Innledning Prosjektet ble i Januar 2015 tildelt undertegnede studenter av RedRock. Målet med prosjektet var å utvikle en plattform for visning av informasjon til brukere av offentligtransport, og spesielt tiltenkt busstransport. RedRock er allerede godt inne i markedet IT og transport, og ønsket å utvide et eksisterende billettsystem med «infotainment-muligheter», altså presentasjon av informasjon under transport. I dette tilfelle gjaldt det visning av informasjon på en større skjermflate fastmontert i kjøretøyet. Lignende løsninger finnes allerede, men et av hovedmålene ved prosjektet var at det skulle være kostnadseffektivt. Dette betød at enhetene som skulle brukes måtte være billige, samtidig som de måtte tilfredsstille kravene som ble satt for systemet. Eksisterende systemer var gjerne dyre, og RedRock ønsket å kunne tilby kundene sine et rimeligere alternativ for å oppnå et konkurransefortrinn i markedet. I oppgaveutlysningen ble det også satt krav til funksjoner som burde implementeres, blant annet var det ønskelig med sporing på kart, estimat mellom rutepunkter (holdeplasser), nyheter, reklame og fjernstyring. Det ble tidlig klart at systemet måtte kunne operere uten tilsyn, slik at unødvendige utgifter til teknikere kunne unngås. Dette betød i praksis at systemet måtte ha en form for styring eksternt, altså en eller annen form for kontrollpanel. Løsningsstrategien ble utformet på bakgrunn av kravene som ble stilt, et av hovedkravene var kostnad. Det ble tidlig klart at en normal datamaskin var uaktuelt, da prisen for slikt utstyr ble for høy per enhet. Løsningen måtte da være mindre kostbare enheter, gjerne minimaskiner som «Raspberry-pi» og lignende. Prisen per enhet ville da synke betraktelig. Utviklingen innen dette segmentet med teknologi har utviklet seg mye den siste tiden, og markedet har mange løsninger som gjør utførelse av prosjektet mulig. Side 5

6 1.1 Bakgrunn Infotainment er et utbredt konsept, vi finner det i fly, buss, tog og holdeplasser med mer. Det finnes utallige løsninger på markedet i mange kategorier, fra totalløsninger til simple reklameskjermer. Når det kommer til funksjonalitet, er mange av løsningene like, som hovedkategori kan en forvente å finne reklame, rute-informasjon og eventuelt instruksjonsvideo / underholdning. I forprosjektperioden har gruppen slitt med å finne fullgode norske alternativer. Dette har gjort det vanskelig å sammenligne kostnader, funksjonalitet og tilpasning da en eventuell utenlandsk versjon må importeres, oversettes og installeres. I Danmark finnes et selskap ved navnet «adibus» [1] som leverer en løsning tilsvarende det vi ønsker. Selskapet har ikke oppgitt priser på sin løsning, og heller ikke hvilken maskinvare som brukes. En løsning som beskrevet blir for vår del et prosjekt startet med blanke ark, det finnes ingen god bransjestandard eller løsning som kan benyttes. Det gir oss derfor full frihet til å finne, implementere og utvikle en egen løsning. Teknologimarkedet har lenge beveget seg mot mindre enheter, mer kraft og større fleksibilitet innen programvare og operativsystem. I takt med økende valgfrihet i markedet har også prisene på mindre datamaskiner stupt. [2] IoT eller «Internet of Things» er stikkord som er verdt å merke seg. Drøyt oppsummert snakker vi om intelligente sensorer og mindre maskiner som samler data og er koblet til internett. En av hovedformålene med IoT er billige enheter med lavt forbruk. Eksempler varierer fra en enkel internett-tilkoblet temperatursensor, til kraftigere alternativer som Raspberry- PI og HummingBoard [3]. Sistnevnte enheter er mindre datamaskiner som har støtte for større operativsystemer som Android, Ubuntu og lignende [4]. De støtter skjerm, har USB muligheter, og annet du forventer av en moderne maskin, dog med mindre kraft og fysisk størrelse. Da prosjektet tar sikte på å benytte en enhet som beskrevet over, åpner dette en diskusjon vedrørende teknologien som skal brukes i utviklingen. Gruppens medlemmer har i tidligere prosjekter utviklet kart og sporingsløsninger ved hjelp av Google sitt Android operativsystem. Android er et operativsystem basert på Linux-plattformen, primært utviklet av Google sammen med mange store telekommunikasjons-leverandører og er primært et operativsystem for mobiltelefoner. I senere tid har Android også beveget seg inn i andre markeder, som bil (Android Auto), smartklokker (Android Wear), og TV-løsninger (Android TV). [5] [6] [7] Dette skaper et økosystem som bør passe vårt prosjekt ypperlig. Android gir utviklerne tilgang til veletablerte rammeverk og funksjonaliteter når det kommer til GPS, Internett, grensesnitt med mer. Side 6

7 1.2 Problemdefinisjon Prosjektet har som mål å utvikle et totalt informasjonssystem til bruk i transportsektoren. Produktet har som mål å tilby kunden et rimelig, enkelt og effektivt system. Prosjektet bygges rundt små enheter (SoC 1 ) som skal plugges i en TV-skjerm i det aktuelle kjøretøyet og skal informere passasjerene om ting som: Neste holdeplass, kart med estimert rute, reklame, video med mer. Det er plukket ut noen moduler som en ønsker å få ferdig innen prosjektperiodens slutt. Dette er beskrevet mer utdypende i et senere avsnitt (ref kap 3). Systemet er planlagt integrert med Red Rock sitt eksisterende billettsystem Mål MÅL Problemdefinisjon ML1 Finne en enhet som har riktig pris og kvalitet. Dette er et viktig tema da prosjektets eksistens baserer seg på et billig produkt som kan konkurrere i et allerede eksisterende marked. ML2 Utvikle en komplett prototype basert på kravspesifikasjonen, modulbasert utvikling klar til prototype-test for å bevise at konseptet er mulig å gjennomføre. ML3 Holde kodebasen ryddig, strukturert, kommentert og effektiv. ML4 Holde Jira oppdatert med problemer / oppgaver samt følge scrum-metodikken og bruke mulighetene verktøyene gir. (ML1 og ML2 er satt av Red Rock, ML3 og ML4 er definert av prosjektdeltagerne) Detaljspesifiserte mål ML1 Et av hovedformålene med prosjektet er muligheten til å føre prisgunstig konkurranse mot andre aktører på markedet. Det finnes lite informasjon rundt lignende løsninger, men Ruter med flere har lignende løsninger i sine kjøretøy. Det er etterspørsel fra det eksisterende kundenettverket til RedRock som sammen ber om en billig, men funksjonsrik løsning. Dette er motivasjonen bak hele prosjektet, samtidig som det passer godt med det eksisterende økosystemet RedRock har etablert innen billett- og rutesystem. For å kunne realisere ambisjonene trengs nytenking på området, en kan ikke bruke dyrere fastvare som en x86 prosessor med masse kraft, minne og ressurser. For at prosjektet skal lykkes må det finnes en enhet som kan gi grei ytelse til en billig penge. ML2 I løpet av prosjektperioden tar gruppen sikte på å utvikle en løsning fra start til slutt, produktet skal være klart for fremvisning og inneha basisfunksjoner som kan bevise til oppdragsgiver at konseptet fungerer, selv på lav-kostnads enheter. Det er et ønske at funksjonene skal være modulbaserte. På denne måten kan løsningen enkelt utvides med ny funksjonalitet uten at dette krever en større omskriving av koden. ML3 Prosjektdeltagerne ønsker en oversiktlig kodebase, som enkelt kan utvides ved senere anledning. Om konseptet skal bygges videre på senere, er det en stor fordel om koden er strukturert ryddig og grei. For å nå dette målet skal gruppen holde seg til standarder innen språket, slik som navnekonvensjoner, derunder funksjonsnavn, variabelnavn og så videre. Kommentarer skal brukes på en god måte, det skal forklares hvordan og ikke hvorfor. Det er også et delmål at kodebasen skal holdes effektiv, dette for å kompensere for manglende kraft i enhetene som skal brukes. Side 7

8 ML4 Som utviklingsverktøy brukes Atlassian JIRA og Atlassian STASH. Dette er prosjektplanleggingverktøy som gir utvikleren god kontroll over flyten i prosjektet. STASH er egentlig bare et GIT repository, lignende GitHub 2 og andre sider basert på GIT-systemet. GIT er et kontrollversjonssystem, det holder kontroll på filene i prosjektet, og lar deg hente tilbake gamle versjoner av filer, samtidig som det effektivt lar deltagere i et prosjekt dele endringer med hverandre. Fordelen med dette er at det er mulig for flere å jobbe sammen på samme prosjekt uten at en manuelt må holde kontroll på alle endringer. Det gir også mulighet for å gå tilbake til eldre versjoner, blande sammen to ulike versjoner, eller opprettholde ulike versjoner for ulike formål innenfor den samme kodebasen. JIRA er et kontrollsystem for feil, forbedringer og endringer. En kan se på JIRA som en elektronisk liste over ting som skal gjøres med et prosjekt. Listen har gjerne en dato for når en gitt oppgave skal være ferdig, samtidig som den støter delegering av problemer til hver enkelt i gruppen. JIRA gir en også mulighet til å overvåke produktiviteten i gruppen gjennom estimater, grafer og statistikk. Det finnes flere bruksmønstre en kan benytte sammen med JIRA, i dette prosjektet skal en bruke Scrum, som er en utviklingsmetodikk tett integrert i JIRA. En typisk Scrum-sesjon foregår på følgende måte: Gruppen setter en Sprint, en sprint er et sett med oppgaver som skal utføres på en gitt tid, i Scrum er dette typisk 1-4 uker. Når en ny Sprint lages diskuterer prosjektgruppen hva som skal være med av oppgaver. Oppgavene legges i en «backlog» i prioritert rekkefølge og dras opp i den aktive Sprinten. Sprinten får så en sluttdato og prosjektperioden begynner. I perioden drar utviklerne de ulike oppgavene fra «Start» til «I arbeid» og slutter med «Ferdig». Målet er å ferdigstille alle oppgavene i «Start-kolonnen» innen den inneværende Sprinten er ferdig. Oppgaver som ikke er utført går tilbake i «backlog» og tas med på nesten Sprint. På denne måten deles store oppgaver inn i flere små over en kort tidsperiode. Slik fortsetter utviklingen til produktet er ferdig. Figur 1: Illustrasjon over SCRUM arbeidsteknikk. [8] Side 8

9 1.3 Forutsetninger og begrensninger Avgrensninger - Større modifisering i eksterne biblioteker for å optimalisere visuell design er ikke noe deltagerne ønsker å fokusere på. Målet med prosjektet er å produsere er produkt som beviser at den tiltenkte løsningen er mulig å realisere. Et brukergrensesnitt som er hundre prosent feilfritt er ikke ett av målene, selv om det er ønskelig. Denne avgrensningen er lagt til i etterkant av forstudierapporten Forutsetninger - Et fullført prosjekt på nevnt enhet krever at en slik enhet kan oppdrives. Det krever også at RedRock har mulighet til å bestille en slik enhet, samtidig som den må kunne oppdrives i god tid før presentasjon av det endelige produktet. Det kan også ende med at enheten som velges er noe dyrere enn det som var utgangspunktet. - En live visning av produktet krever tilgang på live data, det er ikke sikkert dette er mulig å skaffe i løpet av prosjektperioden. - Montasje i kjøretøy krever tilgang på strøm, dette må være tilgjengelig ved eventuell installasjon av produkt. 1.4 Problemløsning Prosjektet tar sikte på å utvikle en komplett prototype, målene kan oppsummeres i problemstillingen: Kan et komplett Infotainment-system utvikles på lavkostnads fastvare? Spørsmålet skal besvares ved å utvikle en prototype som skal kjøres på en slik enhet ved hjelp av Android som operativsystem. Selve oppgaven løses stegvis, i starten ligger mye av fokus i planlegging. En egen forstudierapport ligger vedlagt, denne tar sikte på å planlegge oppgaven løst, velge verktøy og diskutere ulike løsningsmetoder. Det er satt en liste med oppsatte løsningsmål, målene er fordelt i ulike kategorier basert på prioritet, og vil utføres utfra hvor mye tid gruppen har tilgjengelig Prioritet A (Høy) - IFS-1 : Skallet rundt selve systemet, et ferdig basissystem klart for ulike moduler. - IFS-2 : Kartmodul, skal vise kjøretøyet på et kart, slik at brukeren kan se hvor en befinner seg. - IFS-3 : Rutemodul, skal vise neste holdeplass, tidsestimat basert på GPS-koordinater. - IFS-4 : Nyhetsmodul, vise meldinger til brukeren. Ligger over alle andre moduler. - IFS-5 : Innebygget funksjoner for å håndtere tap av internett / GPS. - IFS-6 : Integrasjon med back-end som kan sende og holde orden på klienten Prioritet B (Middels) - IFS-9 : Integrasjon av SIM (datanett til enhetene). - IFS-10 : Integrasjon av GPS i selve enheten, og bruk av denne kontra data fra eksisterende system. - IFS-11 : Nyhets modul, viser nyheter fra eksempelvis RSS. - IFS-12 : Reklame modul, viser video, reklame eller andre typer media Prioritet C (Lav) - IFS-14 : Endre start-up logoen i Android til RedRock. - IFS-15 : Implementere støtte for personteller. - IFS-16 : Animasjon ved bytte av moduler. Side 9

10 1.4.3 Verktøy Under utviklingen er det benyttet ulike verktøy. Nedenfor følger en oversikt over hvilke programmer, verktøy og ressurser som er brukt under prosjektperioden. Navn Bruksområde Microsoft Office Word Rapportskriving Microsoft Office Visio Figurer og diagrammer Microsoft Office Excel Grafer Android Studio (IntelliJ) Utvikling IDE for Java og Android Git Versjonskontroll IRC Samhandling og koordinering Skype Samhandling og koordinering Brackets Tekstbehandling / utvikling av HTML, CSS, JS. Sublime Text Tekstbehandling / utvikling av HTML, CSS, JS. KiTTY SSH tilgang til webserver. WinSCP SSH overføring av filer via SCP. VmWare ESXi Virtualisering av webserver VmWare vsphere Client Håndtering av virtuelle servere Atlassian Jira Planlegging, Scrum og feilhåndtering Asus Nexus 7 Nettbrett, til utvikling og testing Atlassian Stash Lagring av kildekode StackOverflow Nettsted for tekniske spørsmål Photoshop CS6 Editering av bilder og grafikk ClickCharts NHC Flytskjema 1.5 Løsningsstrategi I dette prosjektet er det bestemt at en skal kjøre Sprinter som går over èn uke. Startdagen for hver Sprint er Søndag. Under prosjektet brytes delmålene ned i mindre kategoriserte mål, og legges til på den fortløpende JIRA Sprinten. På denne måten utvikles produktet gradvis etter målene over hele perioden. Diskusjon vedrørende valg av teknologi og hjelpemidler tas på søndagsmøtene når ukens Sprint planlegges. Oppgavene internt er fordelt slik at Christian K Haraldseid er «Scrum Master», dette betyr i hovedsak at han skal holde kontroll på at utviklingen går etter planen, som «Scrum Master» har han også et overstående ansvar for å løse problemer som blokkerer videre utvikling. Mikal Svendsen er tildelt GIT ansvaret, og skal sørge for at det er orden i versjonskontroll systemet. Prosjektet skal utvikles i samråd med oppdragsgiver, det er også satt opp periodiske veiledningsmøter en gang i uken sammen med Christian Auby eller Halvard Øysæd. Side 10

11 1.6 Rapportstrukturen Rapporten er strukturert etter malen som er gjort tilgjengelig for faget DAT304, denne er modifisert for å passe bedre til oppgaven den er brukt til. Kapittel en og to er en mer teoretisk bakgrunn for prosjektet. Kapittel tre presenterer planlegging og løsningsforslag som ble utviklet før selve utviklingen startet. Kapitlene prøver også å gi leseren en innføring i teknologien som skal brukes videre i prosjektet, samt nødvendig bakgrunnsinformasjon om gruppens kvalifikasjoner og erfaringer. Rapporten prøver å oversette engelskspråklige ord som «Activity» og «Fragments» til fungerende norske ord. Slike ord er markert med kursiv skrift for å illustrere at det har en spesiell mening. Leseren skal først presenteres for den engelskspråklige varianten før denne oversettes til norsk. I rapporten finnes også navn på teknologier som ikke er beskrevet i samme avsnitt. Slike ord er markert med et opphøyd navn. Alle ord som har en slik opphøying er nærmere beskrevet i terminologilisten som finnes under referanselisten. Hoveddelen av rapporten er kapittel tre som tar for seg løsningen, og utførelsen av denne. Produktet er strukturert opp i flere deler, noe som gjør at rapporten tar for seg de ulike delene i detalj separat, helheten presenteres løsere uten de store tekniske forklaringene. Om leseren ønsker detaljert oversikt over løsningen skal svarene finnes i underkapitlene som forklarer hver enkelt komponent. Kapittelet er fordelt inn i seks underoverskrifter. Hver enkelt underoverskrift har et fast antall punkter som blir gjennomgått, punktene er som følger: - Teknologi Beskriver den viktigste teknologien som er brukt i utviklingen av modulen / prosjektdelen. - Krav Beskrive spesifikke krav satt på grunnlag av valgt teknologi. - Komponenter Beskriver alle komponenter som blir brukt i modulen / prosjektdelen. (Klasser, funksjoner, objekter) - Virkemåte Forklarer virkemåten til løsningen med alle komponentene, altså funksjonene til modulen i sin helhet. - Forbedringer Forbedringer som prosjektgruppen ønsker å utføre, men som ikke er gjort. - Drøfting og testing Drøfting av funksjon sett opp mot valgt teknologi og krav. Testing som er gjort for å validere funksjon og ytelse. Ikke alle moduler har alle underkategorier da det ikke er alle moduler som er hensiktsmessig å vurdere ved hjelp av alle punkter. Det siste kapittelet «Konklusjon» tar for seg resultatet som en helhet, i kombinasjon med kapittelet «Diskusjon» som reflekterer over resultat og valg som ble tatt under prosjektet. Side 11

12 2 Teknisk bakgrunn 2.1 Android Kapittelet tar sikte på å innføre leseren i en forenklet forklaring av Android som utviklingsplattform. Kapittelet forklarer også noen av hovedprinsippene / teknologiene som er brukt under utviklingen. Utviklingen av prosjektet skal skje med Java / Android som plattform. Android er et operativsystem utviklet av Google og er den største mobile plattformen på markedet. Operativsystemet er bygget på toppen av Linux, det har derfor en Linux-kjerne. På toppen av dette kommer Androidrammeverket som gir utviklere tilgang til et omfattende sett av verktøy og funksjoner til utvikling. Fordelen med systemet er at det er godt dokumentert, er optimalisert og åpent samtidig som det er gratis i bruk. 2.2 Grunnprinsipper En applikasjon utviklet for Android består i sin minste form av en layout og en «Activity». Videre i rapporten oversetter en engelske betegnelser til en tilsvarende norske ord. «Activity» blir derfor aktivitet videre i rapporten. Aktivitet-klasser interagerer med brukeren, derfor tar denne klassen seg av å lage vinduer og andre visuelle ting som trengs for å vise brukeren layouten som er den andre separate tingen som trengs for en enkel applikasjon. Layouten definerer den visuelle strukturen til et brukergrensesnitt. Android har mange innebygde UI-komponenter som fritt kan benyttes. Figur 2 En samling av kompontenter fritt tilgjengelig i Android. [9] Bildet over illustrerer noen av komponentene som er tilgjengelig for utvikleren. I tillegg til komponentene vist på bildet over finnes det mange andre komponenter, som for eksempel bildefremvisning, ulike typer layout-holdere for vertikal / horisontalt design, kalender, klokke med mer. Det er også mulig å lage egne komponenter om det skulle være behov for dette. Når en komponent plasseres på layouten får denne en unik ID, som refereres med et navn satt av utvikler. Når dette er gjort refereres layouten fra aktiviteten, utvikleren kan da fritt manipulere komponentene gjennom kode. Dette innebærer muligheten til å endre tekst, lese input med mer. I dette prosjektet planlegges det å utvide den simple layout aktivitet strategien med Fragments. Et fragment kan sees som en porsjon av brukergrensesnittet, altså en oppstykket del. Fordelen ved å bruke fragments er at en kan inneha en aktivitet som holder kontroll på flere fragments, disse kan benyttes fritt innenfor gitt aktivitet. På denne måten kan en kjøre en helhetlig løsning selv om porsjoner av programmet, (i vårt prosjekt definert som moduler), skal byttes ut / endres. [10] Side 12

13 2.3 Rammeverk og innebygde funksjoner Som nevnt tidligere har Android mange tilgjengelige løsninger ut av esken, dette betyr i praksis at en slipper å skrive egen kode for mange av de underliggende operasjonene, da funksjoner som ofte benyttes gjerne finnes innebygd i systemet. Eksempler på slike funksjoner som er brukt i løsningen er beskrevet i dette kapittelet. I tillegg til en lett innføring i dette kapittelet er noen av ressursene som er brukt beskrevet i detalj under delen hvor komponenten benyttes. Event / Callback Events blir mye brukt i Android, dette er en lytter i en klasse som har som oppgave å respondere på en handling gjort av bruker, systemet eller koden. Et eksempel på et «callback» er når brukeren trykker på en knapp. Det går da et «callback» via Android-rammeverket til funksjonen som lytter til Konteksten til aktiviteten som kjører applikasjonen har lagt seg selv til som en lytter på public void onclick(view view) { Toast.makeText(MainActivity.this, "Button Clicked", Toast.LENGTH_SHORT).show(); } }); Når knappen da blir trykket på, vil funksjonen som er definert over bli kalt. Dette gjør at applikasjonen kan respondere på for eksempel brukerinput. I løsningen er «callbacks» og «interfaces» brukt mye for å gi applikasjonen oversikt over hva som skjer internt. «Interfaces» er i denne konteksten ment som en datamodell for hva som skal sendes med «callbacket» tilbake til funksjonen som implementerer det. Se for deg en applikasjon som presenterer pristilbud til brukene. Denne applikasjonen består av en aktivitet som presenterer tilbudene i samråd med en layout og en bakomliggende klasse som sjekker for nye tilbud. Det er da naturlig å implementere en handling for nye tilbud. Dette kan implementeres på følgende måte ved bruk av «callbacks» og «interfaces»: Figur 3 Illustrasjon av "callbacks" / "interfaces" sin virkemåte. Klassen som tar seg av sjekken for nye tilbud kan da lage en ny instans av DiscountListener, og gi denne konteksten til applikasjonen. Når nye data er klar kan den enkelte gi beskjed til hovedklassen gjennom «interfacet». Side 13

14 Google Maps Google Maps er et separat API tilgjengelig på Android levert av Google. Denne API-løsningen er en implementasjon av Google sin kartløsning tilgjengeliggjort for utvikling på Android. En får her tilgang til en komplett kartløsning, med tilhørende funksjoner som markører, bevegelse og oppdatering. [11] Google Location Manager Innebygget mulighet for å få tak i enhetens posisjon, via denne klassen kan en også få tak på periodiske oppdateringer, eller få varsler om enheten beveger seg innenfor en gitt posisjon. Klassen bruker ulike måter for å håndtere posisjonsvarsler, dette inkluderer GPS, WiFi eller en egen variant. [12] Side 14

15 3 Løsningsforslag Nedenfor følger en oversikt over den tiltenkte løsningen i et høyere perspektiv. Under denne fasen av planleggingen er ingen viktige tekniske valgt tatt, og oversikten er mer ment som et utgangspunkt som ble tatt med videre inn i løsningen. Mye av informasjonen som finnes i dette kapittelet kommer fra forstudierapporten som finnes i vedleggene. Delkapittelet fungerer som en innledning i kravspesifikasjonene og som en forklaring på hvordan løsningen skal fungere når den er ferdig. 3.1 Hardware Et viktig aspekt med prosjektet er å finne en enhet som er innenfor kriteriene prosjektet stiller. Den riktige enheten må være kraftig nok til å kunne gi brukerne en sømløs opplevelse uten «hakking». Den optimale enhet bør kunne tilfredsstille følgende krav: - Bør være av tilstrekkelig kvalitet, den må være robust da bytte av klienter etter montering fort blir forbundet med store kostnader. - Må ha innebygget støtte for trådløst nettverk, da en ikke ønsker å ha for mange «ekstraenheter» koblet til via USB-grensesnittet. - Bør ha valgfri mulighet for integrasjon med en SIM-leser. På denne måten kan en enhet i kjøretøyet oppføre seg som en «moder-klient» som deler mobilt internett med resten av enhetene. - Bør ha innebygget GPS, til bruk ved kart og holdeplassinformasjon. Det er også en mulighet å lese dette fra busser som allerede har Togital billettsystemet integrert. Det kan også være en mulighet at bare en av klientene har GPS muligheter, og deretter deler sine koordinater til alle klientene i samme sone. - Må ha en sterk nok CPU, kombinert med riktig mengde minne, lagringsplass og tilkoblingsmuligheter (USB-otg 3, USB, HDMI) Side 15

16 3.2 Produktdesign Kort oppsummert ser gruppen for seg følgende løsninger. Et selskap bestiller løsningen og oppgir hvor mange noder som trengs, altså hvor mange skjermer som skal settes opp i kjøretøyet. Hver skjerm må ha sin egen node som viser informasjon definert fra serveren, dette kan være nyheter, ruteinformasjon, vær, holdeplasser med mer. Basissystemet skal være modulbasert, slik at nye moduler kan legges til ved behov. Figur 4: Illustrasjon av tiltenkt løsning montert i en buss. [13] Figur 5: Montering av enhet på baksiden av monitor. Side 16

17 Løsningsforslag 1 Innebygget modul for mobilkommunikasjon. Et kjøretøy har en moder-klient som har innebygget støtte for mobilkommunikasjon. Løsningen kjører med Android som grunnsystem og kan derfor ta nytte av den innbygde støtten for deling av data-tilkobling. Ved bruk av dette forslaget kan en node da stå for all kommunikasjon med omverden, og dele dette til andre noder i samme installasjon. På denne måten slipper man ekstra utstyr, og ekstra kostnader ved å ha en separat ferdigløsning som «Huawei 4G modem» eller lignende. Kostnadsmessig vil dette utgjøre at hovednoden vil bli litt dyrere, men den totale kostnaden vil bli mindre, samtidig som installasjon forenkles. Figur 6 Hoved-node med integrert mobildata. Løsningsforslag 2 Ekstern enhet for mobil-kommunikasjon I denne varianten har vi en ekstern enhet for kommunikasjon som nodene kobler seg opp mot. Denne enheten står da for nettverkskommunikasjon mellom alle nodene. En kan da bruke billigere noder på hver skjem, men er avhengig av utstyr levert av en tredjepart, som igjen må integreres inn i løsningen. Figur 7: Ekstern WiFi-enhet med moduler over WiFi. Moduler Systemet skal som nevnt tidligere støtte ulike moduler. En modul skal kunne kjøres uavhengig av andre moduler, og målet er at disse også skal kunne skaleres etter hvor stor skjermflate som er tilgjengelig. En blanding av moduler skal kunne vises samtidig. (Se bildet under for en illustrasjon på dette.) Modulene skal være bygget som et fragment, som tidligere nevnt er fragment en modulær del av en aktivitet som kan byttes ut mens selve applikasjonen kjører. På denne måten får en muligheten til å bytte mellom moduler mens programmet kjører. Figur 8: Flere moduler på samme skjermflate. Side 17

18 Rutemodul En av hovedmodulene er rutemodulen. Denne har som oppgave å vise informasjon om holdeplasser langs ruten. Denne modulen skal benytte GPS-koordinater for å lokalisere seg langs ruten. Alle koordinater for rutestopp finnes allerede i Red Rock sine systemer, og disse skal integreres i løsningen. Eksisterende koordinater brukes så i modulen for å regne ut estimerte tidspunkt for ankomst til neste holdeplass. Modulen skal også vise estimerte tider fremover langs ruten og oppdatere seg når kjøretøyet har kjørt forbi en holdeplass. Figur 9: Rutemodul (venstre) kombinert med kartmodul. Kartmodul Kart-modulen har som oppgave å vise brukeren hvor kjøretøyet befinner seg. For å lage modulen benyttes Android sin integrasjon mot Google Maps. Dette verktøyet har alle muligheter en trenger for å lage en «live sproingsløsning». Ved å vise kjøretøyets nøyaktige posisjon på kartet har brukeren hele tiden oversikt over hvor kjøretøyet befinner seg i forhold til destinasjon. Kombinert med «rutemodulen» (se figur over) er dette en veldig enkel oversikt over kjøretøyets fremgang. Reklamemodul Modulen skal kunne vise reklame / media på skjermene. Det skal være støtte for både bilde og video. Modulen skal selv stå ansvarlig for å hente / slette filer lokalt. For å unngå problemer med tap av internett skal alle filer hentes fra den sentrale serveren og lagres lokalt på enheten. Ved oppdatering skal gamle filer slettes og nye lastes ned. Nyhetsmodul Android har en native «toast» mulighet, og det er denne en ønsker å etterligne med denne modulen. En toast er egentlig bare en tekstlinje som legger seg over skjermen for å vise brukeren informasjon. En modul av samme type ønskes integrert i prosjektet. Denne kan nyttes til å vise viktig informasjon til brukerne, samtidig som den kan brukes som en «rullende nyhetsløsning» i kombinasjon med nyhetsmodulen. Figur 10: Eksempel på en toast. Side 18

19 4 Løsning 4.1 Enhet / Hardware Ut fra kravene som ble definert tidligere i rapporten kom gruppen frem til to ulike kandidater. Begge er gode muligheter, men den dyreste er vurdert best egnet for oppgaven. Kandidat nummer to er rimeligere, og derav også nærmere det oppdragsgiver ønsker. Dog er et viktig aspekt pris / kvalitet / brukeropplevelse, og dette er viktig å ta med i betraktningen av det endelige valget. HummingBoard i2 - SolidRun Ourspop MK808B CPU Cortex A9 RAM 1 GB Å STORAGE MicroSD GPU GC880 Wifi Ja BT Ja 4G Ja MemoryConfig 64-bit Android Pris ca (NOK) 650 CPU Cortex A5 RAM 1GB STORAGE 8 GB GPU Mali 450 Wifi Ja BT Ja 4G Nei Memory config 32 bit Android Pris ca (NOK) 350 Figur 11 i2 Solidrun [16] Figur 12 MK808B Ourspop [17] Enhetene som er valgt har litt fundamentale forskjeller, det dyreste alternativet i2 er vurdert som den beste kandidaten. Denne maskinvaren koster en del mer enn det billigste alternativet men veier opp for dette i en kraftigere prosessor, bedre GPU 4 og flere funksjoner. Blant annet støtter i2 integrert SIM kort og har også støtte for en separat GPS-modul. Dette er egenskaper MK808B ikke innehar, noe som gjør den mindre aktuell da løsningen ikke kan benyttes i busser som ikke har en eksisterende GPS modul. Forskjellen i ytelse er også ganske markant, samt at kvalitetsforskjellene er store. En mulig løsning er å bruke i2 som en hoved-node og om kunde ønsker flere skjermer kan MK808B blir brukt som barne-noder av i2. På denne måten kan en ha en dyrere hoved-node med flere billige barne-noder. Dette innebærer dog at det utvikles en måte der hoved-noder kan utveksle GPS-data med barnenoder. Dessverre var det ikke mulig for RedRock å skaffe enhetene for testing innen fristene som var definert i Gannt diagrammet (tilgjengelig som vedlegg), det ble derfor besluttet å fortsette testing og utvikling på Nexus 7 nettbrett som prosjektgruppen fikk disponere av RedRock. Dette ble ansett som en grei løsning da ytelsen på nevnte nettbrett er tilsvarende lik ytelsen på «HummingBoard I2». Testing og fremvisning er også enklere ved bruk av nettbrett da skjerm og WIFI er innebygget i enheten, kombinert med et eget batteri. Selv om løsningen ikke er testet på aktuelle enheter er fremdeles nettbrett en høyst aktuelt og realistisk kandidat, da spesifikasjoner og operativsystem er identisk til enhetene systemet skulle ha kjørt på. Side 19

20 4.2 Applikasjon Applikasjonen i seg selv har noen overordnede funksjoner. Blant annet er det applikasjon, eller hovedaktiviteten som har ansvaret for å koordinere samkjøringen av ulike moduler. Applikasjonen kommuniserer med serveren via Google GCM (videre forklaring i kap 4.7), alle meldinger som blir mottatt fra serveren kommer via applikasjonens «GcmIntentService» og blir delt ut til alle moduler som trenger informasjon om ny data. Tap av internett er også noe hoved aktiviteten holder styr på. Denne har implementert en funksjon som gir beskjed til alle moduler om internett går tapt, det er så hver enkelt modul sitt ansvar å holde applikasjonen kjørende i perioden tilkobling er utilgjengelig. I tillegg til dette er applikasjonen bygget ut med funksjoner for falsk posisjonering. Komponentene som håndterer dette er beskrevet under. LocationService Kort oppsummert er LocationService en tjeneste som distribuerer lokasjonsdata til resten av applikasjonen. Tjenesten er en Android Service som kjører så lenge applikasjonen kjører. Tjenesten fungerer på en slik måte at andre komponenter i applikasjonen kan binde seg opp mot tjenesten, når en komponent binder seg opp vil den motta all data som sendes fra komponenten. Det første tjenesten gjør når den starter er å sjekke at den er koblet til internett. Om internett er tilgjengelig laster den ned riktig rute, basert på innstillingene satt i applikasjonen. Når ruten er lastet ned gir den beskjed til alle komponenter som er bundet opp til applikasjonen. Den behandler så ruten og laster inn alle holdeplasser til systemet. Holdeplassene blir så lagt i Android sitt «Proximity Alert» rammeverk. Dette er en innebygget funksjon som tar inn en posisjon. Posisjoner som er lagt inn overvåkes av systemet slik at tjenesten får beskjed når enheten befinner seg innenfor posisjonen definert i hver enkelt holdeplass. Når enheten når en holdeplass gir tjenesten beskjed til alle abonnenter. Tjenesten har også ansvar for å supplere applikasjonens komponenter med posisjonsdata, dette kan være fra enhetens GPS eller en ekstern kilde. Et eksempel på en slik kilde er test-klassen «MockProvider». Figur 13: Figuren simulerer virkemåten til "LocationService" Side 20

21 MockProvider MockProvider er en klasse utviklet for testing. Den henter posisjonsdata i XML-format. Et posisjonsdokument i XML inneholder posisjoner for en rute med et tidspunkt for hver enkel posisjon. Klassen tar da et gitt XML-dokument og bruker dette som en posisjonskilde til LocationService. På denne måten kan vi teste applikasjonen uten å kjøre ruten som skal testes. I Android leveres posisjonsdata av en «Location Provider». Denne leverandøren gir systemet oppdaterte koordinater med et gitt intervall, i MockProvider leveres dataen i hastigheten som er definert i XML-filen ved hjelp av tidspunkt. Det er også bygget inn en funksjon for å øke hastigheten, på denne måten kan en kjøre gjennom en rute i høyere hastighet. Side 21

22 4.3 Kartmodul MapModule er en modul som forsøker å kontinuerlig vise en oppdatert posisjon av bussen på et kart, og jevne ut bevegelsen mellom posisjonsoppdateringene fra Androidenhetens GPS. For at modulen skal kunne tilby en jevn flyt i bevegelse må den enten ofre tid ved å kjøre på en liten forsinkelse, eller presisjon ved å gjette neste steg. Figur 14: MapModule vist til høyre Teknologi Den viktigste teknologien i MapModule er Google Maps. MapModule er bygget rundt Google Maps og dens funksjonalitet. I tillegg brukes Android LocationManager, og enhetens innebygde GPSmaskinvare for oppdatering av GPS-posisjon. Det ble valgt å bruke Google Maps; dette fordi det er innebygget i Android, og dokumentasjonen er god Krav Med Google Maps for Android får en benyttet seg av mye ferdig funksjonalitet, det finnes også dessverre en del begrensninger både teknisk og i henhold til Google sin «Terms of Service». Det er for eksempel ikke lov å mellomlagre kartet lokalt på enheten, noe som gjør at kartet krever internett tilgang for å fungere. Google tillater heller ikke bruk av Google Maps til navigasjon, heller ikke kommersiell bruk, men spesifisert i brukeravtalen står det at det er greit å bruke kartet til visning av informasjon for kollektiv transport. Det er uansett et krav at vår applikasjon holder seg til Google sin avtale. Side 22

23 4.3.3 Komponenter MapManager MapManager inneholder all logikken som brukes til oppdatering av kartposisjon og interpolering av bevegelse. Den har ingen UI komponenter internt, men krever at en kallende komponent supplerer et Google Map. MapManager er ikke en service, men dens livstid i applikasjonen er som regel fra applikasjonsstart til slutt. Det er ikke kritisk at den holder sin tilstand fra start til slutt, derfor er den kun opprettet som et vanlig objekt Android kan midlertidig slette den om den trenger å frigjøre ressurser. MapManager abonnerer alltid på posisjonsoppdateringer fra Android, om den ikke har et aktivt Google Map ignorerer den oppdateringene. Så fort en komponent sender et kart til MapManager, opprettes det en Map Marker på kartet som representerer kjøretøyet. Deretter begynner applikasjonen å lagre posisjonsoppdateringene i et mellomlager. MapManager prøver hele tiden å være én oppdatering på etterskudd, slik at når mellomlageret bare er av størrelse en, flyttes ikke kjøretøyet. Så fort den er av størrelse to eller mer, tar den de to eldste oppdateringene i mellomlageret og interpolerer bevegelsene mellom de. Frekvensen på ekte oppdateringer fra Android-enheten er nesten alltid på et sekund eller mer, som oftest opp imot eller over to sekunder. Dette gir en veldig hakkete opplevelse, så for å få flyt i dette må klassen interpolere mellom punktene. Så fort MapManager har to ekte punkter, sjekker den tiden det tok mellom punkt A og punkt B, den forfalsker så et antall punkter mellom hovedpunktene basert på hvilken oppdateringsfrekvens som kjører. Siden det alltid er snakk om relativt korte avstander brukes det lineær interpolasjon. For hvert punkt som lages flyttes Map Marker og kamera samtidig, Google Maps tilbyr allerede glatte animasjonsfunksjoner for å flytte kameraet, men det var vanskelig å synkronisere dette med bevegelsen til Map Marker. Derfor flyttes begge deler steg for steg. MapManager sjekker også konstant hvor langt den ligger på etterskudd, og spoler fremover om den ligger lenger bak enn planlagt. Side 23

24 4.3.4 Virkemåte Diagrammet under viser flyten mellom de forskjellige komponentene i MapModule. Figur 15 Oversikt over virkemåten til kartmodulen. ModuleHandler, som representerer en komponent med kontroll over UI oppsettet, oppretter en instans av MapManager ved oppstart. Når ModuleHandler vil vise kart, oppretter den også et GoogleMap, og sender en referanse av denne til MapManager. MapManager abonnerer på posisjonsoppdateringer med en gang den blir opprettet, når den så får et GoogleMap begynner den å oppdatere dette. Side 24

25 4.3.5 Forbedringer Kartmodulen er kanskje den mest visuelle og synlige modulen i applikasjonen, og står derfor for mye av helhetsinntrykket. Siden den bygger på en tilnærming av virkeligheten ved interpolering og relativt grove posisjonsestimater, er det mye rom for forbedring. For eksempel om en oppdatering i posisjon er litt sent ute og ikke er ankommet før interpolasjon mellom de to siste punktene er ferdig, vil markøren stoppe helt opp. Dette fordi den ikke har noe mer data å gå på. En ting som kunne utbedret dette er å gjette hva som vil skje, slik som for eksempel online spill gjør, ved å se hvor bussen var på vei ved siste oppdatering, fart, og posisjon. Om bussen er på en holdeplass kan en anta at bussen stopper, om bussen var på vei en retning i 80km /t er det naturlig å anta at den fremdeles er i bevegelse. Videre er det også mulig å kunne få til en finere kartmodul ved å bruke et annet API enn Google Maps. Det ble dessverre gjort lite mangelfulle undersøkelser på alternativene til Google Maps før utviklingen startet. Google Maps var det mest tilgjengelige og velkjente API-et og det ble derfor også valgt. Det er et par problemer med Google Maps som gjør at kanskje andre alternativ hadde vært mer passende. For det første får en ikke lov å mellomlagre kartdata, for det andre har en ikke tilgang til informasjon om hvor veiene ligger, det vil si «snap to road-funksjonalitet» uten å gå gjennom Google sitt online API. Sistnevnte tjeneste koster penger, og krever kontinuerlig internett tilgang. Dette synes gruppen er en dårlig løsning for et system som krever redundans med tanke på tilgang til internett Drøfting Om en hadde mer tid er nok MapModule den modulen som hadde sett mest forbedringer. En innså tidlig i prosjektperioden at det kunne bli en stor jobb å gjøre den skikkelig, derfor var MapModule også en av de siste modulene som ble utviklet. Alt i alt er gruppens deltagere fornøyd med modulen, men det skulle spesielt her vært gjort et mer grundig forarbeid med tanke på valg av teknologi. Mangel på «snap to road-funksjonalitet» kan se litt rart ut, men det ble valgt å ikke inkludere dette fordi det vil kreve veldig mange API-kall til Google, noe som koster penger. I tillegg har modulen synlige «artifacts» i form av hvite striper under tegning og animering av kartet, dette er noe som ikke er sett nærmere på fordi rendering-funksjonalitet er ute av vår kontroll. Et mulig svar på dette kan være at en oppdaterer kameravisningen på en høyere frekvens enn tiltenkt av Google. Modulen fungerer dog fint, og som en informasjonskilde for passasjerer gjør den jobben sin, det er endringer av kosmetisk art som eventuelt drar ned helhetsinntrykket. Side 25

26 4.4 Rutemodul Rutemodulen er en av hovedmodulene i applikasjonen. Denne knytter sammen GPS / Lokasjonsdata med rutedata. Poenget med modulen er å gi brukeren en visuell visning på hvilken holdeplass / målplass som kommer, samtidig som den gir informasjon om estimert tidspunkt for ankomst. En visuell fremstilling av endelig design følger: Figur 16: Illustrasjon av rutemodulen. Nummerert for henvisninger i teksten. 1 Holdeplassnavn: Feltet viser navnet på en holdeplass. Navnet hentes fra rutelisten som er definert for enheten. 2 Estimert tid: Feltet viser estimert tid til ankomst for markert holdeplass. 3 Neste holdeplass: Det midterste feltet viser alltid nestkommende holdeplass, dette gir en enkel oversikt over hvilke som er neste i rekken. 4 Lukket liste: Listen inneholder alle holdeplasser som er passert. Alle passerte holdeplasser innehar tidspunkt for passering. Side 26

27 4.4.1 Teknologi Rutemodulen er bygget opp ved hjelp av flere ulike hjelpemidler. Sentralt i utviklingen står bruken av Google Directions API som er ryggmargen i modulen. Dette API-et fra Google regner ut tidsbruk mellom to punkter ved hjelp av parameter satt av utvikler. I vårt eksempel sendes et ruteobjekt gjennom en parser, som deretter lager en forespørsel mot Google Directions API. I denne forespørselen sender en enhetens posisjon, samt posisjon for målet. Forespørselen inneholder også type transportmiddel. I vår løsning er dette transportmiddelet satt til buss, men dette kan enkelt endres i konfigurasjonsfilene. Beslutningen om å benytte Google Directions API var relativt enkelt, Google er en stor aktør med et godt datagrunnlag for beregning. Dette kombinert med bruken av Google Maps gjør Directions API til et naturlig valg i løsningen. Et problem med dette API-et er restriksjonene på bruk. Uten å betale for en lisens kan en gratis konto kun utføre 2,500 spørringer over en 24 timers periode. [14] Under utviklingsperioden er dette en helt OK grense, problemene oppstår først når flere enheter på samme konto skal kjøre døgnet rundt langs landets mange veier. Det neste alternativet er Google Maps API for Work. Ved bruk av denne lisensen øker antall spørringer fra 2,500 til 100,000. Applikasjonen vår er derfor designet for å bruke en utvidet lisens. Ved å øke antall spørringer kan en effektivt minke feilmarginen så mye som mulig, uten å overdrive antallet. En annen teknologi som blir brukt mye i modulen er GPS, denne teknologien er essensiell da nåværende posisjon hele tiden er utgangspunktet for de estimerte tidene til ankomst. Heldigvis er denne godt implementert i Android-økosystemet, og gir oss grei tilgang til nøyaktige posisjoner selv i høy fart Krav De viktigste kravene til modulen er satt med hensyn på den valgte teknologien, samtidig er noen krav satt med hensyn på det interne økosystemet i applikasjonen. Det viktigste kravet er å oppnå høy grad av presisjon i utregningen av tidsbruk til målet, dette må også gjøres på en måte med minst mulig spørringer til Google Directions API. Side 27

28 4.4.3 Komponenter I komponentseksjonen av beskrivelsen blir hver enkelt komponent som sammen utgjør modulen beskrevet. Etterfølgende kapittel tar for seg virkemåten sammen, slik at leseren kan få en presentasjon av hele systemet. Ruteobjekt Ruteobjektet er et objekt som inneholder informasjon om ett enkelt punkt langs ruten. Listen en ser i designet (fig.13) består av syv ulike ruteobjekter satt sammen i en liste. Ruteobjektene blir sendt gjennom flere ulike moduler og brukes flere plasser i løsningen. Objektene oppstår først når applikasjonen laster ned en rute fra serveren. Koden som så går igjennom alle de forskjellige rutepunktene har som oppgave å opprette en liste ruteobjekter som så blir sendt videre inn i løsningen. I løpet av livsløpet til et ruteobjekt mottar det flere viktige parametere. En liste over tilgjengelige parametere følger. Id Name Position esttime queryurl waypoints En unik ID for hvert stopp langs ruten. Navn på holdeplass Posisjon for holdeplass Siste estimerte tid tilgjengelig Spørre-URL som sendes til Google. Andre holdeplasser før denne i den samlede ruten. Ruteobjekter er designet for å være frittstående, med mye informasjon. På denne måten kan objektet benyttes flere plasser i løsningen, dette fordi objektet inneholder de fleste funksjoner som trengs. Livsløpet til ruteobjektet er beskrevet videre i komponentene under. Rutehåndtering Det er også laget et interface for rutehåndtering. Dette er en hjelpeklasse som er laget som en AsyncTask, dette står for «Asynchronous Task» eller en asynkron oppgave. Ved å kjøre denne i bakgrunnen hindrer en at applikasjonens UI-thread fryser når en intensiv jobb utføres. UI-thread er en samlebetegnelse for tråden bruker-interfacet kjører på, altså det brukeren ser. Hjelperen sin oppgave er å hente riktig definert rute for enheten. Riktig rute er satt på server av operatør, og er lastet inn i konfigurasjonen til enhet ved hjelp av instruksjoner fra serveren. Dette er beskrevet i detalj i serverkapittelet. Oppgaven henter så ruten ved bruk at et http kall, ruten lastes ned i JSON 6 format og blir omgjort til RuteObjekter. Når denne prosessen er ferdig sendes en liste med objekter via LocationManager til modulen for visning og videre prosessering. Prosessen er beskrevet grafisk under. Figur 17: Figur som forklarer virkemåten til klassen "GetRouteData" Side 28

29 Estimering av rutetider Hovedpoenget med modulen er estimering av tidsbruk mellom nåværende posisjon og neste mål definert i ruten. For å utføre beregningene er det også laget en AsyncTask for dette formålet, denne er navngitt «GeoDirection» og har som oppgave å estimere tid mellom nåværende posisjon, og posisjonen som er angitt i ruteobjektet den håndterer. Som i alle andre hjelpeklasser behandles ruteobjektene individuelt, dette betyr at modulen sender inn ett enkelt objekt, «GeoDirection» utfører så utregningene og returnerer dette objektet til modulen. Hjelpeklassen benytter seg som nevnt tidligere av Google Directions API, og har implementert et interface. Dette interfacet tar seg av callback, og levering av resultater til klassen som abonnerer på dette. I vårt tilfelle er dette selve rutemodulen. Selve spørringen mot Google utførers som et ett http kall. Syntaksen på spørringen eksisterer allerede i objektet, så oppgaven til hjelperen er relativt simpel. Send spørringen, motta svar, tolk svar, oppdater objekt og send tilbake. Diagramoversikten under illustrerer virkemåten. Figur 18 Figur som forklarer virkemåten til "GeoDirection" klassen. I diagrammet kan en også se GeoCoderException dette er en egen klasse designet spesifikt for bruk med Google Direction API. Selve spørringen mot Google kan gi mange ulike resultater, feilmeldinger er kamuflert med ulike statusmeldinger og kan være vanskelige å tyde. For å gjøre testing lettere ble det laget en egen exception klasse, denne klassen gir god informasjon i loggen om hva som gikk galt, på denne måten blir det lettere å fikse eventuelle feil. Et eksempel kan være at en sender inn en spørring som har for mange veipunkter i forespørselen, Google vil da svare : «MAX_WAYPOINTS_EXCEEDED». Dette er i og for seg en grei melding, men for å gjøre det lettere er det i vår egen exception lagt til litt mer informasjon. Tilsvarende eksempel med vår egen klasse gir følgende resultat. Dette gjør det lett å få en oversikt over hvorfor en fikk feil, og hva som må gjøres for å utbedre feilen. Side 29

30 3.4.4 Virkemåte En forenklet oversikt skal gi et inntrykk av hvordan de ulike komponentene jobber sammen for å lage rutemodulen. Figur 19: Figur som illustrerer sammenhengen mellom alle komponentene i modulen. Selve modulen starter med å få en gyldig rute ved hjelp av rutehåndtereren. Modulen mottar som nevnt tidligere en liste med ruteobjekter fra denne tjenesten. Det neste som gjøres internt i modulen er å legge alle rutepunktene inn i en liste, eller ListView som er en visuell komponent som presenterer listedata for brukeren. Rutemodulen består av to ulike lister (2) og (4) i designpresentasjonen av modulen. Den åpne listen består av ruteobjekter vi enda ikke har nådd, og den lukkede listen inneholder ruteobjekter som er passert. Naturligvis vil alle ruteobjekter ligge i den åpne listen ved starten av en ny rute. Når alle objektene er lastet inn i listen går en videre til estimering av tid. Før dette kan gjøres må det bygges opp et knutepunktregister i hvert enkelt ruteobjekt. GeoDirection tjenesten returnerer alltid raskeste vei fra A til B. Dette passer dårlig da bussen kan ta mange ulike veier mellom rutene, derfor er det laget en funksjon som tar hensyn til ruten ved hjelp av knutepunkter. Funksjonen legger til posisjonen til objektene foran den i listen, slik at rutepunkt nummer tre i listen går via to og en. Dette sørger for at ruten som blir forespurt av Google, er den riktige ruten, og ikke raskeste vei mellom nåværende posisjon og neste stopp. Når knutepunkter er lagt til i ruteobjektene sendes de inn i GeoDirection-hjelperen. Det er en referanse som sendes videre, slik at når objektene oppdateres asynkront i hjelperen vil de automatisk oppdatere seg i listen. På denne måten slipper modulen å oppdatere / legge til objektene i listen en gang til for hver gang de blir endret. På dette tidspunktet er listen oppdatert med estimerte tidspunkter og ruten er klar til å brukes. Etter hvert som bussen / kjøretøyet beveger seg langs ruten er det LocationManager sin oppgave å holde styr på om bussen nærmer seg et punkt langs ruten som er av interesse, som for eksempel en holdeplass. Når en når et nøkkelpunkt langs ruten får modulen beskjed om dette via et interface som kaller «onevent-funksjonen». Denne finner ut hvilken holdeplass handlingen gjelder, og utfører riktig oppgave basert på dette. En av grunnene til at den sjekker holdeplass mot handling er for å dobbeltsjekke at ruten holdes konsekvent riktig langs hele reisen. Når bussen når en holdeplass flyttes nåværende holdeplass ned i den lukkede listen, neste kandidat blir hentet fra den åpne listen og lagt i «neste holdeplass-kolonnen». Side 30

31 Rutinen fortsetter slik langs hele ruten. Tiden oppdateres også konstant, og en intern klokke holder kontrollen på å trekke fra minutter på alle rutepunktene. Det er også mulig å sette en oppdateringsfrekvens, på denne måten kan modulen sjekke nåværende posisjon opp mot de eksisterende rutepunktene via Google, dette for å justere for eventuelle feil langs ruten som har oppstått mellom start og punktet en befinner seg nå. Om denne funksjonen aktiveres, resulterer dette i en høyere nøyaktighet, samtidig som det øker antall spørringer mot Google Forbedringer Modulen har flere områder der den kan forbedres. Dette er en modul som skal estimere tidsforbruk, og det er derfor naturlig at dette som regel kan forbedres. Google Directions API er i utgangspunktet en relativt god tjeneste til å estimere tid mellom to punkter, tester mot «1881.no» og «Gulesider» viser tilsvarende resultater med Google Directions sine estimater. Dog er det ikke alltid dette er helt korrekt, og for å forbedre modulen kan det være en mulighet å utvide den med flere kilder for estimering, for eksempel kunne det bygges inn ordinære rutetider. Rutetidene kunne brukes sammen med Google for å estimere tiden bedre, eventuelt som en feilsjekk og justeringsløsning. En annen forbedring som kunne utvikles er en mellomlagringsløsning for estimert tidsforbruk tilknyttet aktiv rutedata. På denne måten kan antall API-spørringer mot Google reduseres da en buss ofte kjører samme ruten over lengre tid. Ved færre spørringer kan nøyaktigheten i løsningen økes, da flere spørringer på gunstige tidspunkt vil være mulig for å oppdatere listen over estimater Drøfting og testing Rutemodulen er en litt vanskelig modul å teste da den er veldig avhengig av andre systemer i løsningen. Dette kombinert med mangel på ekte test-scenarioer har laget noen problemer for gruppen. Som nevnt tidligere ble det utviklet en falsk tilbyder av GPS koordinater. Dette ga oss muligheten til å spille av en rute, eller lure enheten til å tro at den var i bevegelse. Dette fungerte greit for grovtestingen, men for finjusteringer opplevdes oppdateringene som litt grove. Dette medførte at for eksempel LocationManager sin onevent ikke ble kalt opp med den nøyaktigheten som var ønsket. Dette fungerte mye bedre når en faktisk tok enheten med ut på en runde langs ruten, som da er tilfelle for en buss. Rutemodulen håndterer greit utfall av tjenester, den er avhengig av internett for å oppdatere tidspunkter da en mellomlagring av tidsdata ikke eksisterer. Selve ruten blir mellomlagret, slik at en rute fint kan starte uten internett. Om en rute ikke er mellomlagret (for eksempel ved første oppstart) venter enheten til den får internett og oppdaterer ruten så fort som mulig. Dette gjør til at modulen fint tåler utfall av internett. Når ruten først er startet er rutemodulen helt uavhengig av internettoppkobling, dog kan den bli litt mindre presis. Det er sjeldent modulen er uten internett i lengre perioder (en time pluss) så i realiteten skal ikke dette være et problem når det kommer til nøyaktighet. Side 31

32 4.5 Nyhetsmodul Teknologi Sentralt i nyhetsmodulen står det innebygde rammeverket «Toast», i Android er en «Toast» en måte å vise brukeren en rask melding på skjermen. Nyhetsmodulen er inspirert av denne «Toastfunksjonen», og bygger videre på prinsippene bak denne Krav En kopiering av Toast virkemåten medfører et krav for håndtering av meldinger sendt samtidig. Modulen trenger en mellomlagrinsfunksjon, slik at ikke to meldinger vises på skjermen samtidig Komponenter Toastobjekt En klasse som representerer hver enkelt melding, denne har et par satte attributter som kan defineres. Selve objektet har felt for meldingstekst og varighet, varighet settes for å bestemme tiden meldingen skal være synlig for bruker. Tre ulike lengder er forhåndsdefinert i koden med variabelnavn. Dette gjør koden mer ryddig da intervallene for visning gjerne er like for samme operasjon. I tillegg til tid og meldingstekst er det lagt til en egen variabel for tekstfarge. Et kodeeksempel for opprettelse av en ny melding kan da se ut som følgende: new Toast("Melding", Toast.MEDIUM, Color.BLACK); Klassen har også to konstruktører, dette betyr i praksis at en også kan lage nye meldinger ved å bruke : new Toast("Melding", Toast.MEDIUM); En slipper da å spesifisere en farge (da dette kan være forbeholdt spesielle meldinger). ToastQueueHandler Dette er en kø-håndterer som er ansvarlig for å sørge for å opprette nye meldinger i riktig rekkefølge. Den skal også sørge for at to meldinger ikke vises samtidig på skjermen. Selve klassen opprettes som en instans i starten av applikasjonen, og kjører så lenge applikasjonen er aktiv. Hjelperen inneholder en liste av Toasts, og kjører gjennom denne i rekkefølgene de ble lagt til i. Når en melding vises på skjermen går hjelperen i dvale, her blir den liggende til aktiv melding har brukt opp sin tid på skjermen, den går så videre med neste melding. Nyhetsmodul Nyhetsmodulen er den delen av systemet som brukeren ser, det er denne som har ansvaret for presentasjonen av meldinger på skjermen. Modulen består av en enkel layout, denne har en rektangulær boks med en tekstbeholder. Tekstbeholderen endres ved mottak av en ny melding. Modulen har også en «rullende» effekt for meldinger som har flere tegn enn det som er plass til på skjermen. Dette betyr at når en større melding kommer inn til modulen, vil den rulle over skjermen slik som en ofte kan se på nyhetssendinger på NRK og lignende kanaler. NewsFetcher Dette en hjelper som sjekker etter oppdateringer. Den består av en RSS 5 parser da nyhetskilden er en ekstern RSS-strøm definert på serveren. Applikasjonen lagrer så adressen til nevnte RSSstrøm sammen med en variabel som definerer hvor ofte den skal sjekke etter oppdateringer. Når applikasjonen starter leses så nevnte variabler og hjelperen starter jobben. For å forhindre at samme melding vises flere ganger mellomlagres innholdet i kilden lokalt. Den lokale kopien blir så sjekket mot den nye kopien hver gang en sammenligning av gammelt / nytt innhold blir utført. Ved en eventuelt ny melding sender hjelperen denne videre. Side 32

33 4.5.4 Virkemåte Figur 20: Figur som forklarer virkemåten til nyhetsmodulen. Selve virkemåten i modulen som en enhet er beskrevet av diagrammet over. «NewsFetcher» sjekker den eksterne strømmen av nyheter for endringer. Ved en eventuelt endring sender denne meldingen videre til «ToastQueueHandler» som et «Toast» objekt. «ToastQueueHandler» tar seg så av visningen av dette ved å sende meldingen videre til nyhetmodulen Drøfting og testing Modulen har vist seg robust og stabil i testene som er utført. Blant annet er modulen kjørt over en lengre tidsperiode på to til tre dager. I denne perioden har tilgang på internett blitt kuttet periodevis, modulen har da fungert som forventet og hentet seg inn igjen. Selv om modulen kjøres på en timer kan en ikke se at dette påvirker ytelsen av selve applikasjonen, det er ingen tegn til hakking når modulen kjøres asynkront med resten av applikasjonen, selv under mer krevende omstendigheter (bytting fra mediamodul til kartmodul og så videre). I en test sendes femten meldinger samtidig, modulen viste da innholdet korrekt ved å ikke duplisere meldinger på skjermen. Modulen dropper også meldinger om det er et stort antall meldinger som blir sendt på en gang, dette for å ikke oversvømme brukere i informasjon, ved mye informasjon på et kort tidsrom er årsaken mest sannsynlig en feil. Det er da unødvendig å vise et stort antall meldinger over en større tidsperiode. Modulen viser da første melding, men venter med neste til køen av meldinger får litt mellomrom. Side 33

34 4.6 Mediamodul MediaModule er en komponent i applikasjonen som gir mulighet til å spille av media, som for eksempel reklame. Visuelt representert er modulen bare et svart vindu som spiller av film, men internt har den mange flere oppgaver, som synkronisering av filer og avspillings-logikk. Figur 21: MediaModule som spiller av et klipp med UiA logoen Teknologi Medieavspiller Android sitt multimedia-rammeverk tilbyr mange ferdige muligheter for avspilling av media. Android MediaPlayer klassen dekoder og spiller av de mest brukte videoformatene, så dette ble et naturlig valg i prosjektet. Det brukes en klasse som heter VideoView som er et ferdig Android view knyttet til en MediaPlayer, noe som gjør det enklere og kjappere for oss å ta det i bruk. Nedlasting / synkronisering Android har allerede funksjonalitet for nedlastninger via sin DownloadManager-tjeneste. DownloadManager bruker http protokollen for nedlasting, og derfor ble http et lett valg. Android tilbyr også et rammeverk for synkronisering «Android SyncAdapter Framework». SyncAdapterrammeverket sørger for at synkronisering blir gjort i en bakgrunnsprosess, og tilbyr i tillegg løsninger for blant annet tidsbestemt synkronisering. Oppkopling til server og sammenligning av data er overlatt til bruker av rammeverket. Det ble tatt en avgjørelse om å ikke bruke SyncAdapter rammeverket, da dette sparte gruppen veldig lite tid. Dataformater JSON 6 Vi bruker JSON-formatet for utveksling av informasjon mellom applikasjonen og server backend SHA-1 7 For å verifisere filer litt mer grunnleggende enn ved å bare sjekke filnavn bruker vi SHA1 hash 8 checksum 9 Side 34

35 Lagring SharedPreferences Android sitt SharedPreferences grensesnitt blir brukt for lagring av opplysninger i JSON-format. Parsing I prosjektet nyttes GSON (se liste over biblioteker) til å håndtere JSON. GSON ble brukt fordi dette egnet seg godt til lagring av data i et bestemt format, i vårt tilfelle JSON. Fordelen med å bruke JSON til lagring er at en da kan lagre verdiene i et objekt som en JSON tekst. En kan da senere gjenopprette tilstanden til dette objektet ved å lese tekstinformasjonen som JSON Krav Da det brukes Android DownloadManager som krever HTTP-nedlastninger, må server backend tilby nedlasting via HTTP-protokollen. Videofiler som ønskes å spilles av må være enkodet i et format som støttes av Android MediaPlayer Komponenter SyncService SyncService er en service med ansvar for å holde applikasjonens lokale mediedata oppdatert i forhold til serveren. SyncService er nærmere bestemt en IntentService, den kjører ikke i bakgrunnen hele tiden, men i stedet blir den kjørt hver gang noe oppdateres i server backend og ved applikasjons start. Når SyncService startes kontakter den server backend for en liste over filer som den er forventet å ha lagret lokalt. Den mottar et JSON objekt med en rute ID, og en liste over filnavn / sha1 checksum par. Det er nødvendig å sjekke på checksum hash i tillegg til filnavn, fordi det er veldig vanlig at man trenger å gjøre en endring på en eksisterende fil, som da får det samme navnet. I tillegg har noen filer som synkroniseres alltid samme navn, en er da nødt til å vite mer om filen enn bare navnet. SyncService sjekker så tilsvarende liste lokalt på enheten, og sammenligner disse. Det sjekkes hvilke filer som finnes eksklusivt lokalt, disse skal slettes, mens filer som eksklusivt finnes på server skal nedlastes. Når SyncService har en liste over filer som skal nedlastes kan en forberede nedlasting, til dette brukes Android sin egen tjeneste DownloadManager. SyncService sender en forespørsel til server backend med filnavn og sha1 hash, og får tilbake den riktige filen fra serveren, som DownloadManager setter til nedlasting. Når en nedlasting startes i DownloadManager returneres en ID som brukes som en referanse mot DownloadManageren. DownloadManager håndterer nedlastninger asynkront og uavhengig av vår applikasjon, og derfor må det finnes en måte å bokføre nedlastninger til senere tidspunkt. SyncService vil avslutte sitt arbeid så fort nedlastninger er sendt til DownloadManager, i tillegg kan det hende at applikasjonen resettes før alle nedlastninger er ferdig. En må da lagre tilstand om nedlastninger på langtidsminnet. Det er opprettet en klasse QueuedDownload som holder informasjon om filnavn, Sha1 hash, tidspunkt for oppstart, og nedlastings ID. Det lagres en liste med QueuedDownload i Android SharedPreferences, slik at neste gang SyncService kjører så kan den sjekke status for nedlastninger. Til slutt lytter applikasjonen på broadcasts fra DownloadManager, slik at når en nedlasting har en statusoppdatering kjører SyncService i en spesiell modus der den bare forespør DownloadManager om nedlastninger, og sjekker om dette gjelder en av nedlastningene på sin egen liste. Side 35

36 Om en nedlasting er ferdig vil SyncService flytte den fra en midlertidig nedlastningsmappe til den designerte mediemappen, sammen med andre mediefiler. Om nedlastingen feilet så slettes den, og kjører en ny synkronisering mot server. Uansett om nedlastingen feilet eller ble fullført, så kan SyncService fjerne den fra sin interne liste over nedlastninger. Siden SyncService hele tiden sjekker både filnavn og sha1 checksum, vil korrupte nedlastninger bli håndtert automatisk. Dette fordi en korrupt nedlasting ikke vil ha samme checksum som originalfilen. MediaManager MediaManager er en service med ansvar for å styre medieavspilling i applikasjonen. Den holder orden på hvilke filer som er nedlastet av SyncService, hvilke filer som er mediefiler, og i tillegg tilbyr den viktig logikk for selve avspillingen. MediaManager kjøres i bakgrunnen så lenge applikasjonen lever. MediaManager tilbyr to ulike måter å spille av media; tidsbestemt avspilling, og forhåndsbestemt avspilling. Begge metodene krever at den kallende komponenten gir MediaManager en MediaPlayerModule som den kan spille til. Tidsbestemt avspilling Tidsbestemt avspilling var den første avspillingsmetoden som ble laget til MediaManager, denne tilbyr en enkel «on demand» måte å spille vilkårlig media på. Tanken bak dette var at under strekninger i ruten der kartinformasjon ikke er viktig for passasjerer, kan det spilles av reklamesnutter i en bestemt tid. Om en for eksempel har ca. 45 sekunder til neste stopp, kan en vise sekunder reklame uten at viktig informasjon blir utelatt. Denne metoden krever at en kallende komponent tar seg av logikken. MediaManager ordner selv en passende spilleliste og spiller denne av. Når MediaManager mottar en forespørsel om å spille i en bestemt tid, sjekker den lokal lagring for mediefiler, og sorterer disse basert på tid. Deretter plukker den ut en etter en fil, og sjekker hele tiden at en ikke overgår ønsket tid. I så fall prøver den en annen fil i stedet inntil den finner en liste over film der totaltiden ikke overgår ønsket tid. Som standard plukker metoden ut filmer fra midten av søkelisten, altså den plukker ut filen med median lengde. Om filmen er for lang hopper den et hakk mot starten av søkelisten der en kortere film ligger. Problemet som oppstår da er at det som oftest velges de samme filene hver gang. Det ble lagt til to ekstra moduser, en der metoden begynner fra slutten av søkelisten, og dermed velger færre men lengre filmer, og en der en begynner fra starten av søkelisten, og dermed velger flere men kortere filmer. Dette ble gjort fordi funksjonen var enkel, samtidig så en fikk litt variasjon i spillelistene. Grunnen til at det ikke bare ble kjørt helt tilfeldig utvalg var fordi at i en sortert søkeliste kan metoden effektivt finne en film av passende lengde. Dette er ikke tilfelle i en usortert liste, og funksjonen hadde da brukt lengre tid for å finne en passende fil. Til slutt ble det lagt inn en modus der modulen hele tiden velger en vilkårlig film fra søkelisten. Den sjekker så om den er innenfor tidsrammen. Om spillelisten ikke er passende, fjernes den fra søkelisten slik at neste søk ikke prøver det samme om igjen. Side 36

37 Forhåndsbestemt avspilling Forhåndsbestemt avspilling er en avspillingsmetode som lar brukere av applikasjonen definere en forhåndsbestemt liste av mediefiler som skal spilles av ved bestemte punkter langs ruten. Den abonnerer på «proximity alerts» fra LocationService-tjenesten for å vite når et spesifikt punkt er nådd. Denne metoden håndterer selv logikk for bytting av moduler. Når MediaManager mottar en forespørsel om å spille rutens forhåndsbestemte liste av mediefiler krever den et «callback interface» som den kan bruke for å kommunisere med den kallende klassen. På denne måten kan MediaManager gi beskjed om når avspilling skal starte, og dermed kan den kallende komponenten klargjøre for avspilling. Selv om metoden inneholder logikken for bytting av moduler, så krever den at den kallende komponenten selv utfører selve byttingen av modulen når den ber om det. Dette er først og fremst fordi bytting av moduler kan innebære flere prosedyrer som ikke ligger innen omfanget av MediaManager. Metoden registrerer seg deretter hos LocationService for «proximity alerts». Fra nå av vil MediaManager motta en beskjed hver gang kjøretøyet nærmer seg forhåndsbestemte punkter langs ruten. Når MediaManager mottar kall om at et punkt er nådd, sjekker den en intern liste som inneholder parvis punkt-id, og en tilhørende liste over eventuelle filer som skal avspilles. Om det finnes filmer som skal avspilles, sender den en forespørsel til komponenten som kalte avspillingsmetoden om å forberede seg for avspilling. Siden dette skjer på UI tråden, altså asynkront for MediaManager, og siden MediaManager trenger en MediaPlayerModule å vise film på, så registrerer MediaManager enda et «callback interface» hos UI komponenten, som igjen sender tilbake MediaPlayerModule når den er klar for å starte avspilling. Deretter kan MediaManager spille av listen som vanlig. Når avspilling av en punkt-spesifikk spilleliste er ferdig, sender MediaManager en beskjed til UI komponenten om at avspilling er ferdig, og UI komponenten kan bytte tilbake til ønsket modul. Denne prosessen kjøres om igjen for hvert punkt i ruten som nås. Om modulen når et punkt med planlagt avspilling, mens en tidligere avspilling fortsatt holder på ignorerer MediaManager forespørselen. Dette først og fremst fordi proximity alerts ofte kan trigge flere ganger for et punkt, og duplikater i køen kan oppstå. Alternativet hadde vært å lage en sjekk for dette, og lage en kø over lister / filmer som skal spilles av, men overlapping av avspilling i dette tilfellet er et tegn på dårlig design av den forhåndsbestemte listen, eller teknisk feil. Det er også om mulig ønsket å la avspillingsmetoden bruke tidsbestemt avspilling for å spille av vilkårlige filmer med en viss lengde på bestemte punkter, når det ikke er viktig hva som blir avspilt. Skanning for filer MediaManager må holde seg oppdatert over hvilke filer som finnes lokalt på enheten for å kunne vite hva som skal spilles av. Hver gang en avspillingsmetode blir kalt, skanner MediaManager den designerte mediamappen for filer, og sjekker om de er en mediefil. Om filen er en video, opprettes et objekt av MediaFile klassen, som wrapper en Java File men i tillegg legger til videolengde. Det var planlagt at en også skulle ta hensyn til bildefiler, men siden Android VideoView ikke har ferdigbygd funksjonalitet for å vise bilde i en gitt tid, så ble dette nedprioritert. I tillegg til å skanne for mediefiler, sjekker også MediaManager for en spilleliste for ruten. Denne spillelisten blir brukt i forhåndsbestemt avspilling. MediaPlayerModule MediaPlayerModule er en simpel wrapper rundt et Android VideoView. Dette er selve spilleren som blir synlig i modulvinduet når applikasjonen skal spille film. Side 37

38 Backend Server / backend delen av MediaModule består av noen simple PHP skript som lar applikasjonen sjekke hvilke filer som finnes, og be om nedlasting. Først et skript kalt getcontentinfo.php som tar en rute ID som parameter, og sjekker en tilsvarende mappe spesifikk for ruten. Hver rute har en egen mappe med forskjellige mediefiler, og en spilleliste om dette skal brukes. Skriptet returnerer så et JSON objekt for ruten, som inneholder en liste over filnavn og sha1 checksum par. Deretter tar et skript kalt Downloader.php, inn et filnavn og en sha1 hash som parameter, og returnerer filen man spør etter Virkemåte Sammen jobber de forskjellige komponentene for å kunne vise oppdaterte reklamesnutter på fornuftige tidspunkt. Diagrammet under viser en typisk flyt i det som til sammen utgjør MediaModule. Figur 22: Figuren forklarer virkemåten til Media-modulen. SyncService sjekker innholdet på både backend og den lokale mediamappen, så velger den ut eventuelle filer som skal nedlastes, og delegerer nedlastingen til DownloadManager. DownloadManager laster ned filene fra backend, og lagrer disse i en midlertidig nedlastingsmappe. Når DownloadManager er ferdig med en nedlasting sjekker SyncService filene, og flytter de til den designerte mediamappen. ModuleHandler ber MediaManager om å kjøre forhåndsbestemt avspilling for ruten. Side 38

39 MediaManager abonnerer så på proximity alerts fra LocationService, og sjekker innholdet i den designerte mediamappen. Her ser den også etter en spillelistefil som den parser og beholder for å sjekke opp mot. Når en proximity alert blir sendt, og MediaManager har en spilleliste for punktet, ber MediaManager ModuleHandler om å gjøre seg klar for avspilling. Det vil si at den oppretter en MediaPlayer, samt gjør denne synlig, og sende en referanse til MediaManager. Deretter kan MediaManager spille av spillelisten til MediaPlayer. Når den er ferdig sendes det en beskjed til ModuleHandler om at avspilling er ferdig, og dermed kan MediaPlayer modulen byttes ut med noe annet inntil videre Forbedringer Selv om det hele tiden ble forsøkt å gjøre et solid grunnarbeid og lagt til rette for fremtidig utvidelse av applikasjonen, finnes det alltid rom for forbedringer. Noen steder måtte en ofre kvalitet på grunn av tidsmangel, og andre steder ble det gjort ikke-optimale designvalg fordi deltagerne manglet erfaring. MediaModule baserer seg på oppkopling til en ekstern server for å holde seg oppdatert på mediafiler, og en har i prosjektets periode ikke tatt hensyn til sikkerhet med tanke på dataoverføring. Det betyr ikke at modulen er designet på en slik måte at dette ville være vanskelig å gjøre noe med, men det har ikke vært en prioritet. Dette er noe en absolutt måtte ha tenkt på om applikasjonen skulle blitt brukt i praksis, siden det er kritisk at ingen lett kan laste opp uønsket innhold til enhetene. Modulen skulle også ideelt sett ha kunnet vise bildefiler likt som film, om et selskap ønsker reklame i applikasjonen med bruk av et bilde må en gjøre bildet om til en film-fil. Grunnen til bilder ikke kan vises for øyeblikket er at Android VideoView som brukes til avspilling av media, ikke har en innebygget metode for å vise bilder. Det ble derfor valgt å ikke bruke tid på dette. Mange innstillinger og variabler må endres i koden, for de fleste innstillinger brukes det statiske konstanter. Dette fordi en ikke har hatt tid til å binde disse opp mot backend. Dette er noe som er lett å endre på, men det tar tid og er ikke blitt prioritert. Side 39

40 4.7 Server Teknologi Utviklingsarbeidet ble gjort ved hjelp av CSS 10, HTML 11, PHP 12, MySQL 13 og JavaScript 14. Systemet ønskes kjørt på en Linux tjener, og da er Microsoft sin teknologi ikke hensiktsmessig. Prosjektdeltagerne har fra studiene mest erfaring innen Microsoft sine produkter for webutvikling som C# 15 og ASP.NET 16. Det er derfor en overgang for deltagerne å få prøve seg på teknologier som PHP og JavaScript. Den tekniske utfordringen var av moderat karakter, noe som var en fin begynner-utfordring for gruppen Krav Systemet er ment å være vedlikeholdsfritt i den grad at teknikere ikke skal måtte rykke ut for å utføre arbeid på selve enheten. Dette innebærer i praksis at fjernstyring må være mulig. Innhold må også kunne byttes ut, samtidig som status og innstillinger må kunne leses og settes fra en ekstern lokasjon. Nevnte krav ga grunnlag for å lage et felles kontrollsenter for alle enhetene i systemet. Et webgrensesnitt er en universalt lett og grei måte for operatøren og holde kontroll på systemet uten installasjon av ekstern programvare Virkemåte Systemet fungerer ved hjelp av Google GCM og webteknologien nevnt ovenfor. Google GCM er Google sitt API for Cloud Messaging for Android. Dette er et system for samhandling av data mellom flere enheter fra en sentral server. Dette fungerer ved hjelp av et sentralt register, der alle enheter har en unik adresse. Fordelen med dette systemet er at en som utvikler ikke trenger å holde kontroll på IP-adresser for å kunne utveksle informasjon fra server / klient. Dette er særs gunstig i vår situasjon, da enheten bruker en mobil oppkobling, og faste IP adresser er vanskelig å få til. Figur 23: Illustrasjon over hvordan Google GCM fungerer. En kan da si at GCM er bindeleddet mellom applikasjon og server. I selve løsningen brukes GCM hyppig til alt av kommunikasjon mellom server og klient. Hovedfunksjonene i administrasjonsdelen består av konfigurasjon og mediehåndtering. Innstillinger blir sendt via GCM til enheten, og lagret der til senere bruk, det er også bygget inn mulighet for nedlasting av nytt mediainnhold til bruk i reklamemodulen. En snakker da om bilder, film og eventuelt musikk. Side 40

41 4.7.4 Komponenter Figur 24: Illustrasjon av innloggingsportalen Løsningen er beskyttet med passord, den benytter en modifisert versjon av PHP-sessions 17, for å holde på innloggede brukere. Denne funksjonen er modifisert, slik at bakmenn ikke kan få tak i cookie 18 som blir lagret i nettleseren ved hjelp av et XXS 19 -angrep. Det regenereres også sesjons-id for hver unike side for å unngå overtagelse av brukerens sesjon. I tillegg er det lagt inn en «bruteforce 20 -funksjon», som hindrer brukeren i å prøve mange forskjellige passord. En bruker stenges automatisk ute av systemet etter at den har skrevet feil passord fem ganger. Alle passord er «hashet» og kryptert, ved hjelp av en unik «salt 21» i databasen. Dette hindrer administratorer og andre å se passord i klartekst. Dette betyr også at et eventuelt innbrudd, og dumping av databasen, ikke gir angriperen en database full av passord i klartekst. Figur 25: Illustrasjon av innloggingsportalen Det første som møter brukeren er en oversikt over alle enhetene i systemet. Hver enkelt enhet har som «1» (ref fig. 21) viste en unik ID, det er på denne måten systemet skiller de forskjellige enhetene fra hverandre. Enheten har også en lokal kopi av sin ID, slik at denne vet hvilken enhet den er i forhold til serveren. Side 41

42 I listen kan brukeren få en rask oversikt over navn, rute og selskap enheten hører til. Ved hjelp av «Edit-knappen» «2», kan brukeren justere innstillinger per enhet. Statusikonet «3» fungerer som en markør på om enheten er funksjonell eller ikke. Enheten registreres i listen ved første oppstart automatisk, dette betyr i praksis at installatør ikke trenger gjøre noe mer enn å installere applikasjonen på enheten den skal kjøre på. Registrering gjøres automatisk, deretter kan operatør konfigurere enheten fra en hvilken som helst plassering Figur 26: Illustrasjon over konfigurasjon av enhet. Videre i løsningen er konfigurasjonen for hver enkelt enhet. Ovenfor er et skjermbilde av enhetsinnstilingene på serveren. Det er her operatøren kan sette spesifikk konfigurasjon for hver enkelt enhet. 1. Innstillinger: I panelet kan en juster forskjellige innstillinger per unike enhet. En kan gi enheten et unikt navn, slik at denne lett kan identifiseres i senere tid. Et logisk eksempel, kan her være «Tide, Buss 26 bak». En kan også definere hvilket selskap enheten tilhører, og derav kan en også sette en unik rute tilhørende valgt selskap. På denne måten kan en enkelt skille mellom ulike selskap, dette gir rom for å utvide løsningen med for eksempel ulike reklame-tilbud per busselskap. I innstillingene kan en også bestemme hvilke moduler applikasjonen skal benytte, samt sette hvilken kilde som skal brukes til nyheter. 2. Sende innstillinger: Etter en har endret innstilingene bruker man lagre-knappen for å enkelt sende konfigurasjonen til enheten. Når enheten mottar en ny konfigurasjon vil den automatisk starte på nytt, slik at endringene trer i kraft med en gang. 3. Sende ny media: Om en har endret reklametilbudet, ved å for eksempel legge til en ny reklamefilm kan en enkelt fortelle enheten at den skal oppdatere seg ved hjelp av «Resync media» knappen. Denne ber enheten sjekke lokale filer mot eksterne filer på serveren ved neste anledning. 4. Sende melding: Enheten støtter nyhetsmeldinger på skjermen, dette kan enten settes som en RSS-strøm, eller eventuelt brukes som et meldingssystem der en operatør kan sende inn viktige meldinger til brukere. Boksen på bildet er en test-funksjon for demonstrasjon av løsningen. Side 42

43 4.7.5 Forbedringer Om produktet skal brukes i et aktivt system må det gjøres en del tekniske endringer. Blant annet bør det være mulig å definere selskaper, ruter og mediehåndtering internt i løsningen. I dag løses dette ved å editere databasen, dette fungerer utmerket for vår prototype, men er ikke en god løsning for et produkt i produksjon, der operatør enkelt skal kunne håndtere systemet. Designet legger også opp til status på ulike funksjoner som mobil-oppkobling, sync-status, GPSog API-tilkoblinger. Disse er ikke implementert i løsningen på grunn av prioriteten satt opp i forstudieprosjektet. Det kan også være aktuelt å implementere et styringssystem for applikasjonen på nett, slik at ulike selskaper kan ha ulike profiler for visning. For eksempel ønsker kanskje et selskap å ha reklame før hver holdeplass, og ikke vise så mye kart. Dette bør kunne settes på enhet eller selskaps-nivå Drøfting og testing I utviklingen av løsningen ble det valgt Google GCM for utveksling av informasjon mellom klient / server. Det var flere ulike måter dette problemet kunne blitt løst på, for eksempel kunne en valgt direkte kommunikasjon mellom server klient, men dette hadde ikke resultert i en like enkel løsning. En måtte da selv holdt kontroll på IP-adresser og endringer her. Samtidig måtte en ha utviklet en metode for å håndtere leveringer som ikke gikk gjennom, ved for eksempel utfall av internett. Selve designet er basert på Bootstrap (se liste over biblioteker), dette er en «mal» som er responsiv, enkel i bruk og innehar gode elementer for et ryddig og pent design. Ved å bruke en ferdig løsning designmessig, ble det spart mye tid som ga oss muligheten til å fokusere på utviklingsaspektet. I testene deltagerne har utført på løsningen har den fungert ypperlig, blant annet er løsningen testet mot enheter med og uten internett for å sjekke at alt fungerer etter spesifikasjonene. Alle GCM-meldinger som ble sendt fra serveren kom frem til enheten så fort denne fikk tilgang på internett. I praksis vil dette bety at endringer gjort på serveren kan bli noe forsinket, men dette bør ikke være et stort problem. Det kan også være aktuelt å utvikle et system for feilhåndtering, der oppringning eller SMS kan tvinge enheten til å resette seg, for eksempel kan dette være aktuelt om enheten henger seg og ikke kobler seg på nett automatisk. Testen av løsningen tar sikte på å avdekke avvik, eller forsinkelser i leveranse av meldinger mellom server / klient. I testen kobles enheten opp mot en mobiltelefon. Denne telefonen deler internett via et trådløst aksesspunkt. Dette skal simulere en mobil-oppkobling. For å få testet ulike dekningsforhold som oppstår langs en rute, tvinges mobiltelefonen over på ulike nettverksmoduser som: GSM, WCDMA (3G) og LTE (4G). Det ble også testet hvor lang tid det tar for Google å levere en melding etter et utfall av tjenestene. I diagrammet under kan en se resultatet fra teksten. Alle tall er oppgitt i sekunder. Side 43

44 Forsinket levering RESPONSTEST GOOGLE GCM Forsøk 5 Forsøk 4 Forsøk 3 Forsøk 2 Forsøk 1 GSM WCDMA (3G) LTE (4G) LTE (4G) WCDMA (3G) GSM Forsinket levering Forsøk 5 0,6 0,5 0,5 9 Forsøk 4 0,5 0,5 0,6 8 Forsøk 3 0,5 0,6 0,5 10 Forsøk 2 0,5 0,5 0,5 11 Forsøk 1 0,5 0,5 0,5 8 Figur 27: Test av responstid GCM Utfra diagrammet kan en se at svartiden er svært lav, under alle moduser leverer GCM meldingene raskt og effektivt. Ved forsinket levering er løsningen også svært raskt, her forsvinner mesteparten av tiden til å registrere seg på nettverket, noe som vil variere fra enhet til enhet. Testene er gjort under gode dekningsforhold, så en må forvente en noe lengre responstid om dekningen er dårlig. Meldingene som sendes mellom server / klient er små, dette medfører at selv GSM dekning gir gode resultater. Side 44

45 5 Diskusjon Generelt sett er prosjektdeltagerne fornøyd med det ferdige produktet. Applikasjonen møter alle krav satt opp i kravspesifikasjonen. Løsningen leverer også alle funksjoner som er definert som ønsker i forstudierapporten. I utgangspunktet sto deltagerne fritt i valg av plattform, Android var da systemet som ble valgt av flere ulike grunner. Android er et rammeverk som var kjent for gruppen, og en hadde allerede en oversikt over mulighetene som var tilgjengelige her. Dette kombinert med et økende marked for billig fastvare avgjorde valget. Alternativene var mange, en kunne utviklet noe i C++ kjørende på Linux, eventuelt kunne en laget en ren Java applikasjon eller en applikasjon i et hvilket som helst annet språk. Fordelen ved å velge et rammeverk som Android var at mange avanserte oppgaver allerede er ferdiglaget i, en snakker da om oppkobling mot WIFI, mobilnett, GPS, design og layoutverktøy. Dette kombinert med en veldig god dokumentasjon gjorde Android til et godt valg. Gruppen er veldig fornøyd med valg av plattform, og mener den er særs godt egnet til den type arbeid som er gjort i dette prosjektet. I prosjektperioden har deltagerne økt sin kompetanse innen programvareutvikling, da spesielt innenfor Android. Deltagerne har blitt godt kjent med virkemåten til operativsystemet, og har spesielt lært mye om nettverk, kart og GPS. Feilsøking, virkemåte og struktur er også områder hvor deltagerne føler de har utviklet seg. Serversiden av produktet er utviklet i PHP noe som var helt nytt for alle deltagere. Her er gruppen veldig godt fornøyd med resultatet, da en har lært veldig mye nytt om syntax, struktur og oppbygning av nettsider ved hjelp av PHP. Gruppen har også lært mye om prosjektplanlegging, derav Scrum og arbeidsmetodene tilhørende dette. Deltagerne er svært fornøyd med JIRA som arbeidsverktøy, og ser fordelene et slikt system gir prosjektet. Det tok også litt tid for prosjektgruppen å oppdrive nødvendig fastvare, samt koordinater / GPSdata til testing. Vår veileder hos Red Rock gikk ut i pappapermisjon, derfor var det i denne perioden redusert kommunikasjonen mellom oppdragsgiver og prosjektgruppe. Vi ble da tildelt en ny veileder, og ting løste seg. Om gruppen skulle startet prosjektet på nytt ville ting sett relativt likt ut. En ting som ble oppdaget litt sent er at Google Maps er litt problematisk da det blant annet ikke støtter mellomlagring av kart lokalt på enhet, dette betyr i realiteten at alt av kart må lastes ned i det øyeblikk det skal brukes, dette fungerer dessverre dårlig på et system som ikke alltid har garantert tilgang på internett. I tillegg gjør det også at innlastningen av kartet går litt sent når en beveger seg langs en rute. Selve kartet består av «firkanter», hver firkant er en del av kartet som vises på bildet. Når dette er i bevegelse gjør hentingen av nye kartdata at en får hvite streker som blinker raskt når kartet oppdaterer seg, dette da fordi systemet bruker litt tid på å hente ned siste kartdata som er nødvendig. Dette går utover helhetsinntrykket av løsningen. Alternativer som OpenStreetMap [15] kan gjøre en bedre jobb her, og bør være en kandidat for å forbedre dette problemet. Nevnte løsning åpner også opp for å mellomlagre kartdata. Side 45

46 6 Konklusjon Problemet som ble løst var å utvikle et infotainment system til bruk i buss eller lignende kjøretøyer. Systemet skulle benytte lavkost fastvare, og derfor være billigere å produsere enn alternative løsninger med kraftigere maskinvare. Løsningen som ble utviklet er skrevet for bruk med operativsystemet Android, den er skalerbar og modulbasert. Den fungerer godt på testenheten som skal simulere den faktiske enheten som er valgt til bruk sammen med prosjektet. En av utfordringene var å finne en enhet som tilfredsstilte alle krav til fastvare, dette mener prosjektgruppen at den har funnet. Løsningen er kapabel til å servere brukerne nyheter, kart og rutedata samt reklame og media. Testene som er utført av produktet viser at det er en fungerende prototype. Dette mener prosjektdeltagerne beviser at et komplett Infotainment-system er fullt mulig å utvikle ved hjelp av Android og billig fastvare. Problemeier RedRock kan nytte dette som et konkurransefortrinn i markedet, billige enheter gir mer fortjeneste og/eller flere kunder. Videre arbeid kan blant annet ta sikte på å integrere en annen kartløsning som støtter mellomlagring av data, samtidig som det kan gi brukeren en visuelt bedre opplevelse. Design kan også dra nytte av litt oppgradering, samtidig som rutemodulen gjerne kan implementeres sammen med faktiske rutedata for mer nøyaktig ruteinformasjon. Side 46

47 Bibliografi [1] A. management, «Adibus,» -, [Internett]. Available: [Funnet ]. [2] A. Bender, «Computerworld,» 27 Oktober [Internett]. Available: [3] «Wikipedia,» Wikimedia Foundation, [Internett]. Available: [Funnet ]. [4] E. Brown, «Linux.com,» Linux Fundation, 02 Februar [Internett]. Available: says-yes-to-ubuntu-and-windows-but-wheres-android. [Funnet ]. [5] G. Android, «Android.com,» Google, [Internett]. Available: [Funnet ]. [6] G. Android, «Android.com,» Google, [Internett]. Available: [Funnet ]. [7] G. Android, «Android.com,» Google, [Internett]. Available: [Funnet ]. [8] F. Velloso, « [Internett]. [Funnet ]. [9] Google, «Android Developers - Input Controls,» Google, [Internett]. Available: [Funnet ]. [10] Google, «developer.google.com,» [Internett]. Available: [Funnet ]. [11] Google, «developer.google.com/maps,» [Internett]. Available: [Funnet ]. [12] Google, «developers.google.com - LocationManager,» [Internett]. Available: [Funnet ]. [13] Google Sketchup, «3DWarehouse - 3D Bus model by Asiastar bus,» Caulan, [Internett]. Available: 363bb3fe9d1c. [Funnet ]. [14] Google, «Developers Google,» [Internett]. Available: [Funnet 2015]. [15] OpenStreetMap, «OpenStreetMap Android,» [Internett]. Available: [Funnet ]. [16] SolidRun, «SolidRun Products I2,» [Internett]. Available: [Funnet ]. [17] DX, «DealExtreme OursPop,» [Internett]. Available: dual-core-android-4-1-google-tv-player-w-bluetooth-1gb-ram-8gb-rom-tf-hdmi-black #.VWRkp0_tlBc. [Funnet ]. Side 47

48 Side 48

49 Figurer Figur 1: Illustrasjon over SCRUM arbeidsteknikk. [8]... 8 Figur 2 En samling av kompontenter fritt tilgjengelig i Android. [9] Figur 3 Illustrasjon av "callbacks" / "interfaces" sin virkemåte Figur 4: Illustrasjon av tiltenkt løsning montert i en buss. [13] Figur 5: Montering av enhet på baksiden av monitor Figur 6 Hoved-node med integrert mobildata Figur 7: Ekstern WiFi-enhet med moduler over WiFi Figur 8: Flere moduler på samme skjermflate Figur 9: Rutemodul (venstre) kombinert med kartmodul Figur 10: Eksempel på en toast Figur 11 i2 Solidrun [16] Figur 12 MK808B Ourspop [17] Figur 13: Figuren simulerer virkemåten til "LocationService" Figur 14: MapModule vist til høyre Figur 15 Oversikt over virkemåten til kartmodulen Figur 16: Illustrasjon av rutemodulen. Nummerert for henvisninger i teksten Figur 17: Figur som forklarer virkemåten til klassen "GetRouteData" Figur 18 Figur som forklarer virkemåten til "GeoDirection" klassen Figur 19: Figur som illustrerer sammenhengen mellom alle komponentene i modulen Figur 20: Figur som forklarer virkemåten til nyhetsmodulen Figur 21: MediaModule som spiller av et klipp med UiA logoen Figur 22: Figuren forklarer virkemåten til Media-modulen Figur 23: Illustrasjon over hvordan Google GCM fungerer Figur 24: Illustrasjon av innloggingsportalen Figur 25: Illustrasjon av innloggingsportalen Figur 26: Illustrasjon over konfigurasjon av enhet Figur 27: Test av responstid GCM Side 49

50 Vedleggs liste Vedlegg A Terminlogi Forklaring av begreper, ord og uttrykk. Vedlegg B - Designutvikling Oversikt over designendringer fra utkast til ferdig versjon. Vedlegg C - Møtereferater Møtereferater fra veiledningstimer med veileder. Vedlegg D Gannt Gannt diagram som viser fristende i prosjektet. Vedlegg E Timelister Timelister illustrer tid brukt på spesifikke oppgaver i prosjektperioden. I tillegg til listen i dokumentet er det vedlagt to komplette lister med navnet «uia-brukernavn_timeliste_complete.xls» for hver deltager. Vedlegg F Forstudierapport Forstudierapporten er vedlagt som et eget dokument ved navnet «Forstudierapport.pdf» Om denne ikke er vedlagt for deg som leser, kan den også hentes elektronisk her: Vedlegg G Pressemelding En pressemelding tilhørende oppgaven. Vedlegg H - Bidragsytelse Deltagernes fordeling av oppgaver. Side 50

51 Eksterne ressurser Simple-Rss2-Android En RSS 2.0 Parser for Android. Denne brukes i helper/newsfetcher.java for å tyde RSS dataen som blir brukt i forbindelse med nyhetsmodulen. Biblioteket er laget av Bruno Hautzenberger som har gjort det tilgjengelig på GitHub under brukernavnet salendron. Biblioteket og koden finnes her: Bootstrap Bootstrap er brukt til designet tilhørende serveren (websiden). Bootstrap ble laget av en designer for Twitter.com og er blitt et av de mest populære «open-source» front-end rammeverkene i verden. Les mer om Boostrap, og se kildekoden her: Gson Gson er et Java bibliotek som kan brukes til å konvertere Java-objekter til en JSON string, og omvendt. I prosjektet er dette biblioteket brukt som en metode og lagre objekter lokalt på disk. Gson er laget av Google og er frigitt under «Apache License, Version 2.0». Biblioteket og koden finnes her: Side 51

52 Vedlegg Vedlegg A Terminologi 1 SoC En datamaskin som har alle funksjoner integrert på en enkelt chip. 2 GitHub GitHub er en webbasert GIT-repository tjeneste som tilbyr mulighet for gratis lagring av åpen kildekode ved bruk av GIT som verktøy. 3 USB-otg USB-otg som står for USB On-the-go er spesifikasjon laget sent i 2011 som gir enheten som innehar porten muligheten til å oppføre seg som en tjener. Dette gjør at en kan koble til eksterne apparater som digitale kameraer, tastatur med mer. 4 GPU GPU er kort for «Graphics processing unit», på norsk kjent som skjermkort. Dette er en elektronisk brikke som utfører matematiske kalkulasjoner spesielt egnet for tegning av bilder. 5 RSS RSS som er forkortelsen for «Really Simple Syndication» er XML dialekt, basert på RDF. RSS brukes mest til å videreformidle innhold fra en nettside. 6 JSON JSON kort for «JavaScript Object notation» er en måte å presentere data. JSON kan også sees på som et alternativ til XML eller YAML. JSON er bygget opp av «key, value pairs» der hvert navn har en verdi. 7 SHA-1 SHA «Secure Hash Algorithm» er en gruppe hashfunksjoner bestående av SHA-1, SHA-224, SHA-256, SHA-384, og SHA-512. SHA-1 er forventet å ta over for MD5, og er brukt i en rekke sikkerhetsapplikasjoner. 8 Hash Hash eller hashsum eller checksum er et lite utdrag fra en blokk av digital data som er lagt inn for å sjekke for feil. Checksum kan brukes til å verifisere at data ikke er korrupt, eller for å sammenligne filer med samme navn. 9 Checksum (Se 8-Hash) Side 52

53 10 CSS CSS eller «Cascade style sheets» er et språk som brukes til å definere utseende på filer skrevet i HTML eller XML. Prinsippet er at HTML eller XML dokumentet utelukkende skal beskrive struktur og semantikk, mens oppsett farger og annen stilinformasjon skal beskrives ved hjelp av CSS HTML Et markeringsspråk for formatering av nettsider PHP PHP er et dynamisk tolket og løst typet programmeringsspråk hovedsakelig brukt for å utvikle dynamiske nettsider MySQL MySQL er en GPL lisensiert databaseadministrasjonssystem mye brukt i LAMP JavaScript JavaScript er en implementasjon av ECMAScriptet, skriptsspråk best kjent for å tilføre dynamiske elementer til nettsider C# C# eller (C Sharp) er et objektsorientert programmeringsspråk utviklet av Microsoft som en del av ASP.NET rammeverket ASP.NET ASP.NET er en del av ASP-rammeverket utviklet av Microsoft, ment primært brukt til å lage nettsider PHP-sessions En PHP sesjon er en måte å lagre variabler mellom sideskifter, hovedsaklig brukt når en bruker besøker et nettsted. På denne måten kan en bruker ha en sesjon kjørende så lenge denne er på nettstedet Cookies Engelsk: cookies. En liten tekst delt av nettsiden og klienten. Informasjonskapsler brukes for å kjenne igjen brukeren mellom hvert besøk på nettsiden. Et eksempel er nettbutikker som «husker» hva du har lagt i handlekurven. Side 53

54 19 - XSS Cross-site Scripting (XSS) er en type sikkerhetshull der angriperen setter inn fiendtlig programkode i websider som kjøres når siden vises. Eksempler på slik kode er HTML og Javascript. Typisk bruk av XSS er stjeling av cookies og phishing. Cross-site scripting har også vært omtalt som CSS, men har ofte blitt forvekslet med Cascading Style Sheets og Content-Scrambling System, og er derfor mindre brukt Brute Force Metode for å knekke passord og krypteringsnøkkeler ved å prøve et stort antall muligheter. For å finne en pinkode på fire siffer må man i verste fall prøve alle kombinasjonene Salt & Hash Salt brukes i kryptografiske hash-funksjoner for å generere unike hash, salt er et tilfeldig nummer, størrelse avhenger av implementasjonen. Input er ofte salt og et passord i klartekst, dette kjøres gjennom en hash-funksjon. I hash-verdien lagres salt i klartekst ved siden av. Salt beskytter mot angrep som rainbow crack fordi det vil være for mange verdier å utarbeide på forhånd. Side 54

55 Vedlegg B Designutvikling Vedlegg B 1: Første designutkast Vedlegg B 2: Rutemodul-konsept -- Side --

56 Vedlegg B 3: Kart og rutemodul endelig versjon Vedlegg B 4: Kart, rutemodul og nyhetsmodul. -- Side --

57 Vedlegg B 5: Kartmodul byttet ut med rutemodul -- Side --

58 Vedlegg C Møtereferater Møtereferat Det ble diskutert viktige fokuspunkter for tiden fremover, stikkord for spørsmål som må besvares er: - Hvilken del av prosjektet skal hovedfokus ligge på? (Kontrolldel /input eller grafisk del / 3dmodell) - Skal det være en server / klient løsning mellom styresystem og applikasjon? o Fordel : Separat, styringssystem og modell (mindre feilkilder på kritisk infrastruktur) - Kan QT brukes også til 3D-modelering av kran-modell? - Skal det lages simulatorer når det kommer til sensor / styring, og skal disse eventuelt gå gjennom «joystick» og «kran-sensor» modulene, eller feedes rett inn i programmet? - Hva skal det bygges mot? ARM, x86 eller annet? Dette fører til restriksjoner i bruk av verktøy. - Når kan utstyr skaffes, og eventuelt hva? (Joystick, Kran-modell, 3ds max modeller). -- Side --

59 Møtereferat Det ble diskutert prognoseplan for kommende uke. Veileder kom med input på foreløpig arbeid på forstudie-rapporten. Følgende ble foreslått: - Legge til informasjon om konkurrerende løsninger. o Hva skiller vår løsning fra andre. (Pris, muligheter) - Diskutere videre rundt bruk av verktøy / Android Studio / Eclipse. - Begynne prototyping av funksjonalitet. (Vertica slice) - Vurdere prioriteringene bedre. - Skrive mer om mål (bruke Jira bedre, burndown charts osv) Deltagere : Mikal Svendsen, Christian K Haraldseid, Christian Auby. Møtereferat Diskusjon vedrørende status på satte oppgaver, i løpet av uken ble det finpusset på rapport. Veileder ønsker at gruppen skal fokusere på prototypen av løsningen, for å få nyttig erfaring ved bruk av verktøyet og plattformen. Vi skal også fokusere på å hente inn informasjon vedrørende hvorfor RedRock ønsker å utvikle produktet, samtidig som det ble etterspurt mer info om konkurrenter i markedet. Sammenslåing av DAT215 i prosjektet ble også diskutert. Deltagere : Mikal Svendsen, Christian K Haraldseid, Christian Auby. Møtereferat Det ble diskutert prognoseplan for kommende uke. Veileder kom med input på foreløpig arbeid på forstudie-rapporten. Følgende ble foreslått: - Skrive mer om design-konsept etter hva vi har lært fra prototypen. - Skaffe informasjon om konkurrenter fra Red Rock. - Starte smått videre utvikling, for å sparke i gang selve utviklingen. - Skrive gruppekontakt. - Tilegne seg en fast arbeidsmetodikk for Jira, samt bli flinkere til å føre timer. -- Side --

60 Møtereferat Det ble diskutert prognoseplan for kommende uke. Veileder pekte på viktigheten med å få unnagjort et møte med RedRock for å avklare ting som - Andre løsninger i markedet. - Google Places API - Andre ting relatert til rapport. Det er viktig å fokusere på å få ferdig rapporten innen fristen på om 3 uker. Rapporten skal også sendes til veileder, slik at han kan se over den, mens det fremdeles er tid til å gjøre endringer. Møtereferat Videre diskusjon angående forstudierapporten som snart skal leveres. Veileder ønsker spesifikke spørsmål om rapporten, så han kan fokusere på det viktigste. Videre ble følgende tema om rapporten diskutert : - State of the art kapittel, som omhandler lignende løsninger kontra vår. - Prototyping ideløsning, tiltenkt løsning i forprosjekt perioden. - Mer tekniske detaljer, oppbygging osv. - Noen sider litt tynne på tekst kontra bilder. - Ikke bruker termer før de er forklart. - Prioriteter bør merkes med kodeord, slik at en kan finne dem igjen. - Nevne litt mer om server-siden? Deltagere : Christian Auby, Chrisitan Haraldseid og Mikal Svendsen. -- Side --

61 Møtereferat Prosjektdeltagerne er snart ferdig med produktet, noe bugs og småfeil og noen justeringer igjen. Konsentrasjonen ligger i rapport. Møtet gikk mest ut på diskusjon rundt layout og konvensjoner rundt rapportskriving. Noen av temaene som ble tatt opp er : - Holde teknologi beskrivelse av XML, XSS og mindre relevante teknologier i en separat liste og henvise til denne. - Veileder synes inndeling kan fungere. Jobber litt videre med denne. - Red Rock skal nevnes som Red Rock A/S første gang, deretter Red Rock. - Veileder ønsker et utkast som han kan gå igjennom, helst med spesifikke spørsmål. Deltagere : Christian Auby, Christian Haraldseid og Mikal Svendsen. -- Side --

62 Vedlegg D Gannt -- Side --