Infotainment System

Transcription

Infotainment System

HPR/D-2015/001 INFOTAINMENT-SYSTEM
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
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
Innhold
1 Innledning ................................................................................................................................................... 5
1.1 Bakgrunn .............................................................................................................................................. 6
1.2 Problemdefinisjon ................................................................................................................................. 7
1.2.1 Mål ................................................................................................................................................ 7
1.2.2 Detaljspesifiserte mål .................................................................................................................... 7
1.3 Forutsetninger og begrensninger ......................................................................................................... 9
1.3.1 Avgrensninger ............................................................................................................................... 9
1.3.2 Forutsetninger ............................................................................................................................... 9
1.4 Problemløsning..................................................................................................................................... 9
1.4.1 Prioritet A (Høy) ............................................................................................................................. 9
1.4.2 Prioritet B (Middels) ...................................................................................................................... 9
1.4.2 Prioritet C (Lav) ............................................................................................................................. 9
1.4.3 Verktøy ........................................................................................................................................ 10
1.5 Løsningsstrategi ................................................................................................................................. 10
1.6 Rapportstrukturen ................................................................................................................................11
2 Teknisk bakgrunn .................................................................................................................................... 12
2.1 Android ............................................................................................................................................... 12
2.2 Grunnprinsipper .................................................................................................................................. 12
2.3 Rammeverk og innebygde funksjoner ................................................................................................ 13
3 Løsningsforslag ....................................................................................................................................... 15
3.1 Hardware ............................................................................................................................................ 15
3.2 Produktdesign .................................................................................................................................... 16
4 Løsning ..................................................................................................................................................... 19
4.1 Enhet / Hardware ............................................................................................................................... 19
4.2 Applikasjon ......................................................................................................................................... 20
4.3 Kartmodul ........................................................................................................................................... 22
4.3.1 Teknologi ..................................................................................................................................... 22
4.3.2 Krav ............................................................................................................................................. 22
4.3.3 Komponenter............................................................................................................................... 23
4.3.4 Virkemåte .................................................................................................................................... 24
4.3.5 Forbedringer................................................................................................................................ 25
4.3.6 Drøfting ....................................................................................................................................... 25
4.4 Rutemodul .......................................................................................................................................... 26
4.4.1 Teknologi ..................................................................................................................................... 27
4.4.2 Krav ............................................................................................................................................. 27
4.4.3 Komponenter............................................................................................................................... 28
3.4.4 Virkemåte .................................................................................................................................... 30
4.4.5 Forbedringer................................................................................................................................ 31
4.4.6 Drøfting og testing ....................................................................................................................... 31
4.5 Nyhetsmodul....................................................................................................................................... 32
4.5.1 Teknologi ..................................................................................................................................... 32
4.5.2 Krav ............................................................................................................................................. 32
4.5.3 Komponenter ............................................................................................................................... 32
4.5.4 Virkemåte .................................................................................................................................... 33
4.6 Mediamodul ........................................................................................................................................ 34
4.6.1 Teknologi ..................................................................................................................................... 34
4.6.2 Krav ............................................................................................................................................. 35
4.6.3 Komponenter............................................................................................................................... 35
4.6.4 Virkemåte .................................................................................................................................... 38
4.6.5 Forbedringer................................................................................................................................ 39
4.7 Server ................................................................................................................................................. 40
4.7.1 Teknologi ..................................................................................................................................... 40
4.7.2 Krav ............................................................................................................................................. 40
4.7.3 Virkemåte .................................................................................................................................... 40
Side 3
4.7.4 Komponenter............................................................................................................................... 41
4.7.5 Forbedringer................................................................................................................................ 43
5 Diskusjon .................................................................................................................................................. 45
6 Konklusjon ............................................................................................................................................... 46
Bibliografi .................................................................................................................................................... 47
Figurer.......................................................................................................................................................... 49
Vedleggs liste .............................................................................................................................................. 50
Vedlegg A - Terminlogi .............................................................................................................................. 50
Vedlegg B - Designutvikling...................................................................................................................... 50
Vedlegg C - Møtereferater ........................................................................................................................ 50
Vedlegg D - Gannt .................................................................................................................................... 50
Vedlegg E - Timelister .............................................................................................................................. 50
Vedlegg F - Forstudierapport................................................................................................................... 50
Vedlegg G - Pressemelding...................................................................................................................... 50
Vedlegg H - Bidragsytelse ........................................................................................................................ 50
Eksterne ressurser ..................................................................................................................................... 51
Simple-Rss2-Android ........................................................................................................................... 51
Bootstrap .............................................................................................................................................. 51
Vedlegg ........................................................................................................................................................ 52
Side 4
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
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 RaspberryPI 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
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 (SoC1) 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.
1.2.1 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)
1.2.2 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
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 GitHub2 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
1.3 Forutsetninger og begrensninger
1.3.1 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.
1.3.2 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.
1.4.1 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
1.4.2 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.
1.4.2 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
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
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
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
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å knappen.
@Override
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
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
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-otg3, USB, HDMI)
Side 15
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
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
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
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.
Ourspop MK808B
HummingBoard i2 - SolidRun
CPU
RAM
Å¨¨STORAGE
GPU
‘ Wifi
BT
4G
MemoryConfig
Android
Pris ca (NOK)
Cortex A9
1 GB
MicroSD
GC880
Ja
Ja
Ja
64-bit
4.4.4
650
CPU
RAM
STORAGE
GPU
Wifi
BT
4G
Memory config
Android
Pris ca (NOK)
Cortex A5
1GB
8 GB
Mali 450
Ja
Ja
Nei
32 – bit
4.4.2
350
Figur 12 MK808B – Ourspop [17]
Figur 11 i2 Solidrun [16]
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 GPU4 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
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
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
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
4.3.1 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.
4.3.2 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
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
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
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.
4.3.6 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
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
2
3
4
Holdeplassnavn: Feltet viser navnet på en holdeplass. Navnet hentes fra rutelisten som er
definert for enheten.
Estimert tid: Feltet viser estimert tid til ankomst for markert holdeplass.
Neste holdeplass: Det midterste feltet viser alltid nestkommende holdeplass, dette gir en
enkel oversikt over hvilke som er neste i rekken.
Lukket liste: Listen inneholder alle holdeplasser som er passert. Alle passerte holdeplasser
innehar tidspunkt for passering.
Side 26
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.
4.4.2 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
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
JSON6 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
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
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
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.
4.4.5 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.
4.4.6 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
4.5 Nyhetsmodul
4.5.1 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.
4.5.2 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.
4.5.3 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 RSS5 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
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.
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
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
4.6.1 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
JSON6 – Vi bruker JSON-formatet for utveksling av informasjon mellom applikasjonen og server
backend
SHA-17 – For å verifisere filer litt mer grunnleggende enn ved å bare sjekke filnavn bruker vi SHA1
hash8 checksum9
Side 34
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.
4.6.2 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.
4.6.3 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
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 30-35 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
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
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.
4.6.4 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
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.
4.6.5 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
4.7 Server
4.7.1 Teknologi
Utviklingsarbeidet ble gjort ved hjelp av CSS10, HTML11, PHP12, MySQL13 og JavaScript14.
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.NET16. 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.
4.7.2 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.
4.7.3 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
4.7.4 Komponenter
Figur 24: Illustrasjon av innloggingsportalen
Løsningen er beskyttet med passord, den benytter en modifisert versjon av PHP-sessions17, for å
holde på innloggede brukere. Denne funksjonen er modifisert, slik at bakmenn ikke kan få tak i
cookie18 som blir lagret i nettleseren ved hjelp av et XXS19-angrep. Det regenereres også
sesjons-ID for hver unike side for å unngå overtagelse av brukerens sesjon. I tillegg er det lagt
inn en «bruteforce20-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 «salt21» 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
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
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å.
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
RESPONSTEST GOOGLE GCM
Forsøk 5
Forsøk 4
Forsøk 3
Forsøk 2
Forsøk 1
Forsinket levering
GSM
WCDMA (3G)
LTE (4G)
0
Forsøk 5
2
LTE (4G)
0,6
4
WCDMA (3G)
0,5
6
8
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
GSM
0,5
10
Forsinket levering
9
12
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
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
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
Bibliografi
[1] A. management, «Adibus,» -, - - -. [Internett]. Available: http://adibus.dk/en-produkter.html.
[Funnet 13 04 2015].
[2] A. Bender, «Computerworld,» 27 Oktober 2014. [Internett]. Available:
http://www.computerworld.com.au/article/558239/teched-developing-internet-things-cheapchips/.
[3] «Wikipedia,» Wikimedia Foundation, 12 04 2015. [Internett]. Available:
http://en.wikipedia.org/wiki/Raspberry_Pi. [Funnet 13 04 2015].
[4] E. Brown, «Linux.com,» Linux Fundation, 02 Februar 2015. [Internett]. Available:
https://www.linux.com/news/embedded-mobile/mobile-linux/807087-faster-raspberry-pi-2says-yes-to-ubuntu-and-windows-but-wheres-android. [Funnet 13 04 2015].
[5] G. Android, «Android.com,» Google, - - 2015. [Internett]. Available:
http://www.android.com/wear/. [Funnet 13 04 2015].
http://www.android.com/auto/. [Funnet 13 04 2015].
http://www.android.com/tv/. [Funnet 13 04 2015].
[8] F. Velloso, «http://fabiovelloso.com.br/,» 05 05 2014. [Internett]. [Funnet 20 05 2015].
[9] Google, «Android Developers - Input Controls,» Google, - - -. [Internett]. Available:
https://developer.android.com/guide/topics/ui/controls.html. [Funnet 16 05 2015].
[10] Google, «developer.google.com,» 2015. [Internett]. Available:
http://developer.android.com/. [Funnet 06 05 2015].
[11] Google, «developer.google.com/maps,» 2015. [Internett]. Available:
https://developers.google.com/maps/documentation/android/. [Funnet 23 04 2015].
[12] Google, «developers.google.com - LocationManager,» 2015. [Internett]. Available:
http://developer.android.com/reference/android/location/LocationManager.html. [Funnet 10
05 2015].
[13] Google Sketchup, «3DWarehouse - 3D Bus model by Asiastar bus,» Caulan, - - -. [Internett].
Available: https://3dwarehouse.sketchup.com/model.html?id=u3b7b7188-54b4-4295-92be363bb3fe9d1c. [Funnet 16 01 2015].
[14] Google, «Developers Google,» 2015. [Internett]. Available:
https://developers.google.com/maps/documentation/directions/. [Funnet 2015].
[15] OpenStreetMap, «OpenStreetMap Android,» 2015. [Internett]. Available:
http://wiki.openstreetmap.org/wiki/Android. [Funnet 05 05 2015].
[16] SolidRun, «SolidRun Products I2,» 10 05 2015. [Internett]. Available: https://www.solidrun.com/product/cubox-i2/. [Funnet 20 05 2015].
[17] DX, «DealExtreme OursPop,» 2015. [Internett]. Available: http://www.dx.com/p/mk8080bdual-core-android-4-1-google-tv-player-w-bluetooth-1gb-ram-8gb-rom-tf-hdmi-black175870#.VWRkp0_tlBc. [Funnet 20 05 2015].
Side 47
Side 48
Figurer
Figur 1: Illustrasjon over SCRUM arbeidsteknikk. [8] .................................................................... 8
Figur 2 En samling av kompontenter fritt tilgjengelig i Android. [9] ............................................. 12
Figur 3 Illustrasjon av "callbacks" / "interfaces" sin virkemåte. .................................................... 13
Figur 4: Illustrasjon av tiltenkt løsning montert i en buss. [13] ...................................................... 16
Figur 5: Montering av enhet på baksiden av monitor. .................................................................... 16
Figur 6 Hoved-node med integrert mobildata. ................................................................................ 17
Figur 7: Ekstern WiFi-enhet med moduler over WiFi. ................................................................... 17
Figur 8: Flere moduler på samme skjermflate. ............................................................................... 17
Figur 9: Rutemodul (venstre) kombinert med kartmodul. .............................................................. 18
Figur 10: Eksempel på en toast. ...................................................................................................... 18
Figur 11 i2 Solidrun [16] ................................................................................................................ 19
Figur 12 MK808B – Ourspop [17] ................................................................................................. 19
Figur 13: Figuren simulerer virkemåten til "LocationService" ...................................................... 20
Figur 14: MapModule vist til høyre ................................................................................................ 22
Figur 15 Oversikt over virkemåten til kartmodulen. ...................................................................... 24
Figur 16: Illustrasjon av rutemodulen. Nummerert for henvisninger i teksten............................... 26
Figur 17: Figur som forklarer virkemåten til klassen "GetRouteData" .......................................... 28
Figur 18 Figur som forklarer virkemåten til "GeoDirection" klassen. ........................................... 29
Figur 19: Figur som illustrerer sammenhengen mellom alle komponentene i modulen. ............... 30
Figur 20: Figur som forklarer virkemåten til nyhetsmodulen. ........................................................ 33
Figur 21: MediaModule som spiller av et klipp med UiA logoen .................................................. 34
Figur 22: Figuren forklarer virkemåten til Media-modulen. .......................................................... 38
Figur 23: Illustrasjon over hvordan Google GCM fungerer. .......................................................... 40
Figur 24: Illustrasjon av innloggingsportalen ................................................................................. 41
Figur 25: Illustrasjon av innloggingsportalen ................................................................................. 41
Figur 26: Illustrasjon over konfigurasjon av enhet. ........................................................................ 42
Figur 27: Test av responstid GCM .................................................................................................. 44
Side 49
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:
http://d.uia.io/Forprosjekt_f.pdf
Vedlegg G – Pressemelding
En pressemelding tilhørende oppgaven.
Vedlegg H - Bidragsytelse
Deltagernes fordeling av oppgaver.
Side 50
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: https://github.com/salendron/Simple-Rss2-Android
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: http://getbootstrap.com/
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: https://github.com/google/gson/blob/master/LICENSE
Side 51
Vedlegg
Vedlegg A
1 – SoC
2 – GitHub
3 – USB-otg
4 – GPU
5 – RSS
6 – JSON
7 – SHA-1
8 – Hash
9 – Checksum
Terminologi
En datamaskin som har alle funksjoner integrert på en
enkelt chip.
http://en.wikipedia.org/wiki/System_on_a_chip
GitHub er en webbasert GIT-repository tjeneste som
tilbyr mulighet for gratis lagring av åpen kildekode ved
bruk av GIT som verktøy.
http://en.wikipedia.org/wiki/GitHub
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.
http://en.wikipedia.org/wiki/USB_On-The-Go
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.
http://en.wikipedia.org/wiki/Graphics_processing_unit
RSS som er forkortelsen for «Really Simple
Syndication» er XML dialekt, basert på RDF. RSS
brukes mest til å videreformidle innhold fra en nettside.
http://no.wikipedia.org/wiki/RSS
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.
http://nettutvikler.com/ordbok/forklaring/json/
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.
https://norsis.no/leksikon/secure-hash-algorithm/
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.
http://en.wikipedia.org/wiki/Checksum
(Se 8-Hash)
Side 52
10 – CSS
11 – HTML
12 – PHP
13 – MySQL
14 – JavaScript
15 – C#
16 – ASP.NET
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.
http://no.wikipedia.org/wiki/Cascading_Style_Sheets
Et markeringsspråk for formatering av nettsider.
http://no.wikipedia.org/wiki/HTML
PHP er et dynamisk tolket og løst typet
programmeringsspråk hovedsakelig brukt for å utvikle
dynamiske nettsider.
http://no.wikipedia.org/wiki/PHP
MySQL er en GPL lisensiert
databaseadministrasjonssystem mye brukt i LAMP.
http://no.wikipedia.org/wiki/MySQL
JavaScript er en implementasjon av ECMAScriptet,
skriptsspråk best kjent for å tilføre dynamiske elementer
til nettsider.
http://no.wikipedia.org/wiki/JavaScript
C# eller (C Sharp) er et objektsorientert
programmeringsspråk utviklet av Microsoft som en del
av ASP.NET rammeverket.
http://no.wikipedia.org/wiki/C_Sharp
ASP.NET er en del av ASP-rammeverket utviklet av
Microsoft, ment primært brukt til å lage nettsider.
http://no.wikipedia.org/wiki/ASP.NET
17 – PHP-sessions
18 - Cookies
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.
http://en.wikipedia.org/wiki/Session_(computer_science)
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.
https://norsis.no/leksikon/informasjonskapsel/
Side 53
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.
https://norsis.no/leksikon/cross-site-scripting/
20 - 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
10.000 kombinasjonene.
https://norsis.no/leksikon/bruteforce/
21 - 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.
https://norsis.no/leksikon/salt/
Side 54
Vedlegg B Designutvikling
Vedlegg B 1: Første designutkast
Vedlegg B 2: Rutemodul-konsept
-- Side --
Vedlegg B 3: Kart og rutemodul endelig versjon
Vedlegg B 4: Kart, rutemodul og nyhetsmodul.
-- Side --
Vedlegg B 5: Kartmodul byttet ut med rutemodul
-- Side --
Vedlegg C Møtereferater
Møtereferat 13.01.2015
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 --
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øtereferat03.02.2015
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.
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 --
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.
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 --
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 --
Vedlegg D Gannt
-- Side --
Vedlegg E Timelister
Christian K Haraldseid.
Issue
Key
IFS-54
IFS-54
IFS-54
Issue summary
Writing on final report
8
6
8
2015-5-24
2015-5-23
2015-5-23
IFS-54
IFS-54
IFS-54
IFS-54
8
10
8
5
2015-5-22
2015-5-20
2015-5-19
2015-5-18
IFS-54
IFS-54
IFS-61
General bugfixing and
polishing
Meetings and research
week 19
Meetings and reasearch week 18
8
10
8
2015-5-18
2015-5-16
2015-5-14
4
2015-5-5
4
2015-4-28
10
2015-5-12
Build dummy-data into
solution. (GPS)
Continue improving
the BusRoute-Module
4
5
5
7
2015-5-1
2015-5-4
2015-5-7
2015-4-30
Routemodule, formatting, reposistion of
example text, minor fixes, proofreading,
finishing server, writing chapter guide, formatting of changelog.
Intro, abstract, proof reading, meeting
Graphics
Structure, server, graphics
Adapt Route module to dummy
7
2015-4-15
Route objects rewrite
6
5
0,067
7
2015-5-11
2015-5-10
2015-5-8
2015-5-6
Adapt RouteModule
for LiveGPS data
Mock Location Provider
Adapt web for custom
RSS and custom
routes.
2
2015-5-5
4
3
2015-5-5
2015-4-27
2
2015-4-23
IFS-38
Adapt RouteModule
for LiveGPS data
6
2015-4-23
IFS-44
IFS-42
IFS-39
IFS-42
IFS-42
IFS-42
Start writing report
News Module
Meetings week 12
News Module
News Module
News Module
5
2
1,5
3
5
5
2015-4-12
2015-3-24
2015-3-17
2015-3-22
2015-3-23
2015-3-20
IFS-60
IFS-59
IFS-54
IFS-54
IFS-54
IFS-54
IFS-27
IFS-30
IFS-54
IFS-54
IFS-54
IFS-54
IFS-38
IFS-54
IFS-48
IFS-49
Hours
Work date
Work Description
Finalizing for delivery
Edits, typos, formatting
Editing, finializing for last edit by external
helpers.
Editing
Proof-reading / Rewriting.
Proof reading, restructering, meeting.
Toast Module, Integrating Mikals modules.
Discussion, Conclusion, ToastModule
See changelog.
Fixing routemodule, internet dependencies, caching of routes, proximity
Meetings and discussion
Backend / Server + tools section. Testing
of Google GCM.
Marker, switch on event
Created program to create mock-routes
from Grimstad.
- Local routes in backend.
- RSS test function, for local rss.
-- Side --
- Demo purposed changes.
Fixed route module, working towards
functioning routes. Fixed several minor issues, added local route for testing purposes.
Pre report template, see v.01 changes.
Integrated with backend
IFS-40
1
2015-3-18
2
2015-3-9
Trying to read url from backend, (route).
2
2015-3-9
5
2015-3-8
Singelton, Sync, Interfaces and service to
class communication.
Implementing backend comp.
IFS-12
IFS-9
week 12
Continue improving
the BusRoute-Module
week 9
Continue improving
the BusRoute-Module
Work on pre-report.
Server side of things.
3
5
2015-3-1
2015-2-27
IFS-12
Work on pre-report.
6
2015-2-28
IFS-34
Start prototyping
backend / basic pages.
Start prototyping
Start prototyping
Continue pre-report
work.
Start prototyping
Continue pre-report
work.
Continue improving
the BusRoute-Module
week 8
Continue improving
the BusRoute-Module
Create backbone for
BusRoute - Module
Create the top-most
view with basic activity
functions
Create backbone for
BusRoute - Module
ToastModule
8
2015-2-26
6
2015-2-25
3
2015-2-24
2
2015-2-24
4
2015-2-24
2
2015-2-19
Div
2
2015-2-20
Improved listivew (stack, pop etc)
2
2015-2-23
RedRock meeting
4
2015-2-16
5
2015-2-14
3
2015-1-29
5
2015-2-15
4
2015-2-3
ToastModule
ToastModule
Work on pre-report.
Create backbone for
BusRoute - Module
Work on pre-report.
Work on pre-report.
Research
Research
Research
Start with prototyping
of fragment lifecycle
4
4
2
2
2015-2-5
2015-2-11
2015-1-26
2015-2-13
2
1
2
3
0,05
2
2015-2-2
2015-2-6
2015-2-9
2015-2-13
2015-2-13
2015-2-12
3
2015-2-12
2
2015-2-10
2
2015-1-21
IFS-30
IFS-33
IFS-30
IFS-34
IFS-34
IFS-19
IFS-34
IFS-19
IFS-30
IFS-29
IFS-30
IFS-22
IFS-13
IFS-22
IFS-24
IFS-24
IFS-24
IFS-12
IFS-22
IFS-12
IFS-12
IFS-20
IFS-20
IFS-20
IFS-15
IFS-22
IFS-15
IFS-12
Create backbone for
BusRoute - Module
Work on pre-report.
-- Side --
Progress meeting.
Proof-reading structuring.
Working impl of GCM server side and client side.
Techincal description formatting and suggestions based on Auby's comments.
Device page, config retrival and saving. +
GCM sender backend.
Database setup, gcm connection and registration process.
Database setup, gcm connection and registration process.
Added some info about state of the art,
and techincal design.
Fixed a V1-design for the BusRoute Module.
Design, responsiveness.
Working with intergration of the Google
Places API.
Basic strcuture, and overall design concept.
Worked with queuing and async tasking.
Fixed documentation, and queuing.
Intro, Goals, Solution
Fixed listview, and design.
Consept explanation
Div
ListViews and custom adapters
ndroid Studio
Fragment / Activity lifecycle
Documentation on the work done on the
toast module, also fixed some bugs. And
created a Word document describing the
module, combined with JavaDoc.
Experimenting with layouts, and listview
possibillities.
Trying to implement seamless interaction
between main activity and fragments.
Pre planning, system architecture, overall
design.
IFS-12
IFS-12
IFS-12
IFS-12
Work on pre-report.
Work on pre-report.
Work on pre-report.
Work on pre-report.
3
4
3
3
2015-2-8
2015-2-8
2015-2-4
2015-1-23
IFS-10
Overall planning state.
5
2015-1-23
TOTAL
Similare systems, architecture.
Product description, illustrations.
Gannt, Timeschedules, tasks.
Wrote Summary, Product design, Hardware..
Overall-designs, mocups drawing done,
and components.
302,6
Mikal Svendsen
Issue
Key
IFS-66
IFS-65
IFS-55
IFS-55
IFS-55
IFS-57
IFS-56
IFS-56
IFS-56
IFS-56
IFS-55
IFS-53
IFS-53
IFS-52
IFS-51
Issue summary
Hours
Work date
Work Description
Report - LocationService
Report - MapModule
Write report for playback system
2
2015-5-18
done
5
5
2015-5-16
2015-5-14
5
2015-5-13
done
Finished a first version of the module report, made flow chart
Wrote report
2
2015-5-12
Testing and bugfixing
week 20
MediaManger play
video on event
MediaManger play
video on event
MediaManger play
video on event
MediaManger play
video on event
Report - Sync system
Report - Sync system
Make MediaModule
and MediaManager
use pictures aswell
4
2015-5-12
5
2015-5-11
4
2015-5-9
2
2015-5-8
Finished playback on event, still need to
have it fetch playlist from backend
parsing
4
2015-5-7
prototyping
2
2015-5-6
writing report
1
5
5
2015-5-6
2015-5-5
2015-5-4
done
Wrote report
Research and testing
Map movement
smoothing
4
2015-5-1
it seems that the videoview we have been
using can not display photos, may have to
use a different playback option
Fixed latency issues
Change in report setup, covering several
internal components under broader module names
Proximity and video playback testing / fixing
done
IFS-51
Map movement
smoothing
6
2015-4-30
Calling this task finished now, there are
improvements to be done but we can not
prioritize them now
Implemented smooth movement
IFS-51
Map movement
smoothing
Map movement
smoothing
5
2015-4-29
working on latency fix
started from scratch on MapManager
5
2015-4-28
more prototyping
Map movement
smoothing
Broadcasting for Media and Sync system
5
2015-4-27
testing
Design and research
1
2015-4-24
IFS-51
IFS-51
IFS-47
-- Side --
Sync service responds to broadcasts from
DownloadManager
IFS-50
IFS-48
IFS-45
Debug LocationService
LocationService
2
2015-4-24
fixed
0,5
2015-4-23
Done
6
2015-4-23
Wrapped up, quick testing
IFS-45
LocationService
2
2015-4-22
IFS-48
3
2015-4-22
IFS-48
6,5
2015-4-21
IFS-48
LocationService
LocationService
Meetings week 16
Meetings week 16
LocationService
Meetings week 12
6
2015-4-20
5
3
2
1
8
3
2015-4-18
2015-4-16
2015-4-16
2015-4-14
2015-4-15
2015-4-9
IFS-43
MediaManager Service
8
2015-4-8
IFS-43
6
2015-4-7
IFS-43
3
2015-4-3
IFS-45
IFS-45
IFS-46
IFS-46
IFS-45
IFS-39
Needs some field testing but otherwise
complete
onLocationChanged callback from android would not fire, spent 2 hours debugging (I had to delete my emulator and create a new one)
Wrapped up, still need to make sure it
sorts location objects properly leaving the
last 30 minutes for that
Testing and fixing parsing
A lot of debugging
MockProvider class more or less ready,
started working on xml parser soon done
callback and broadcasting
research, programming
Meeting with red rock
Meeting with Auby
Design, prototyping
Researching broadcast receivers, planning ahead
Wrapped up, tested, fixed, etc.
Done
Created functionality to create playlists
based on set duration, need one more
day to finish the public playback method
Restructured (removed) threading code
Made some design changes, new interfaces, deleted some
IFS-43
5
2015-4-2
Started on playback implementation
Added errorhandling
some structure changes
start on public methods
spawns background thread properly
IFS-43
6
2015-4-1
bugfixes / debugging
Working with threading
A lot of time spent on research and testing
IFS-43
4
2015-3-31
Will probably need more time but it is
soon usable
Created service
Prototyping
Reading android documentation
-- Side --
IFS-41
Advertise module
1
2015-3-31
Added some interface and helper classes
for threading
Troubleshooting
IFS-41
IFS-39
IFS-41
Advertise module
Meetings week 12
Advertise module
3
2
5
2015-3-30
2015-3-30
2015-3-25
Added background thread
Ad module plays videos
setup new computer with tools and project
Prototyping
Debugging and fixing merge related errors
Meeting
Exception handling
IFS-39
IFS-37
IFS-39
IFS-41
IFS-37
IFS-41
IFS-39
IFS-37
Meetings week 12
Fix, small errors and
bugs in SyncAdapter
Meetings week 12
Advertise module
bugs in SyncAdapter
Advertise module
1
3
2015-3-24
2015-3-24
1
3
4
2015-3-23
2015-3-23
2015-3-23
5
2015-3-19
Merging and conflic resolving
research, prototyping
Trying to fix app crashing on connection
refused
research and prototyping
Meetings week 12
bugs in SyncAdapter
1
3
2015-3-18
2015-3-18
Weekly meeting with Halvard and Auby
testing with large amount of files
error fixing
IFS-31
Design and implement
SyncAdapter
3
2015-3-17
IFS-31
SyncAdapter
SyncAdapter
5
2015-3-16
5
2015-3-13
IFS-31
IFS-31
IFS-31
SyncAdapter
SyncAdapter
7
5
Fixed a few bugs
Testing
Functionality completed, need to handle
errors and clean up code
SyncService now starts download
properly, stores to SD card, started working on logic to deal with finished downloads and failed downloads
2015-3-12
Have to extend estimate even further,
main functionality will be done soon but
need alteast a full day to clean up code
and handle errors properly
Backend and client
2015-3-11
Client is now able to determine what files
to download and queue them, will not
download duplicates
JSON parsing
Lot of research
IFS-31
SyncAdapter
8
-- Side --
2015-3-10
Client now receives JSON from server,
and checks its own content
I have deemed Android's sync adapter
framework useless for our application,
poorly documented and impossible to debug. Discarding all current work, and
starting over with our own framework for
sync. This means more time.
IFS-31
SyncAdapter
7
2015-3-9
IFS-31
SyncAdapter
8
2015-3-7
Working on syncadapter implementation.
Will take longer than initially estimated.
Extending remaning estimate to 2 days
learning php
IFS-35
mediaplayer module
mediaplayer module
SyncAdapter
Create the Live-view
map fragment.
3
2015-3-5
prototyping sync adapter backend
more prototyping
5
2015-3-4
Research, prototyping
5
2015-3-5
Research and sketching
2
2015-2-27
IFS-35
IFS-31
IFS-25
Trying to solve authentication problem
Added moving marker and camera to map
fragment
fixing some bugs
IFS-29
IFS-32
IFS-25
IFS-25
week 8
RouteHandler
map fragment.
map fragment.
1
2015-2-27
3,5
2015-2-26
5
5
2015-2-26
2015-2-25
can not test anything right now
Cleaning my office
Created singleton class, with subscribe
and notify system
Should be able to receive location updates from local gps unit now
Debugging map and asynctask, skipping
smooth movement for now
Moved all relevant prototyping code to the
project repository, map now works except
for auth issues with google.
Moving prototype over to the actual project
implemented location queue system with
delay
IFS-25
IFS-33
map fragment.
week 9
7
2015-2-24
1
2015-2-24
Changed the remaining estimate, this will
require a lot more work than previously
estimated
Designed smooth movement function.
Todo: implement it, implement route trail
Working on getting git project to work
creating sprint
IFS-29
IFS-25
IFS-25
week 8
map fragment.
1
2015-2-17
2
2015-2-19
map fragment.
4
2015-2-18
-- Side --
etc
Meeting with auby, then with Kråkevik
Experimenting with movement interpolation for smooth movement on lower location update frequencies
Debugging and solved maptype.NORMAL
crashing emulator (it just doesnt work on
emulator, solution: dont use it)
IFS-23
IFS-25
Prototyping map module
8
2015-2-17
IFS-20
IFS-20
Research
5
2015-2-12
Android location API and examples
IFS-15
Meetings and discussion week 7
Research
Research
2
2015-2-10
Testing fragments
1
2015-2-10
Weekly meeting with Auby
5
4
2015-2-10
2015-2-8
lynda.com video on fragments
Setting up work environment
IFS-23
IFS-21
IFS-20
IFS-20
2015-2-16
1
2015-2-13
6
2015-2-13
4
2015-2-9
A lot of testing, so far map only works
properly in satellite mode and crashes in
all other modes after a certain zoom level,
need to debug this more
Still experimenting with android lifecycles
etc.
video tutorial about maps API
map fragment.
Research
IFS-23
4,5
Working on design for smooth scrolling
map
Added more functionality, marker that
moves with onlocationchanged and camera
Figuring out google maps API and access. Map now working in app
Watching lynda.com android developing
tutorial
(installing tools etc)
TOTAL
322
-- Side --
Vedlegg E Pressemelding
Det er utviklet en Infortainment prototype som demonstrerer et infotainment-system til bruk I
transportsektoren kjørende på lavkostnads-enheter. Dette gjør det mulig å selge billigere systemer
for kundegrupper som ønsker et større antall enheter i sin flåte av kjøretøy. Et infotainment system
kan også åpne opp for mange nye muligheter da kjøretøyet er koblet opp mot internett. En kan da
tenke seg statistikk med mye annet. Produktet er et resultat av en bacheloroppgave utlyst av Red
Rock A/S.
-- Side --
Vedlegg E Bidragsytere
Som nevnt i rapporten er bidragsyterne Christian K Haraldseid og Mikal Svendsen. Oppgavene er
gjennom hele perioden fordelt rettferdig mellom deltagerne og arbeidsmengden / timelistene
reflekterer dette. Under prosjektet føler deltagerne at oppgavemengden og arbeid mellom deltagere
tilfredsstiller målsetningen om en rettferdig fordeling. Noen nøkkelfordelinger i arbeidet:
Mikal Svendsen
- Kartmodul
- Reklamemodul
- LocationManager
- Syncservice
- Git-ansvar
Christian K Haraldseid
- Rutemodul
- Nyhetsmodul
- Backend
- Jiira Ansvar
-- Side --

Infotainment System

Transcription

Similar documents

Infobrev til lærestedene turnuslisens 2014.pdf

TIMEPLAN - Fagerlia VGS

Axdata Timeregistrering.pdf

Forprosjektrapport

Litt nyttig informasjon før du starter

Brosjyre om E-tiq

GLEDER DU DEG TIL Å KOMME HJEM

Skolebevis - PocketID AS