frisats kommunikasjon med web-api for android-enheter...
TRANSCRIPT
FriSats – Kommunikasjon med Web-API
for Android-enheter
FriSats – Communication with Web-API
for Android devices
Kommunikasjonssystemer
Institutt for elektrofag
Avdeling for ingeniør- og økonomifag
01.06.2016
Antall ord: 7199
Marita Sofie Furnes
Sondre Svendsen
Kristoffer Z Rye
Marius Forsberg Aasbak
Jeg bekrefter at arbeidet er selvstendig utarbeidet, og at referanser/kildehenvisninger til alle kilder som er brukt i arbeidet er oppgitt, jfr. Forskrift om studier og eksamen ved Høgskolen i
Bergen, § 9-1.
Dokumentkontroll
Rapportens tittel:
FriSats – Kommunikasjon med Web-API for Android-enheter Dato/Versjon
01.06.16/v1.0 Rapportnummer:
Forfatter(e):
Marita Furnes,Sondre Svendsen, Marius Aasbak, Kristoffer Rye Studieretning:
HKOM12/13 Antall sider m/vedlegg
38 Høgskolens veileder:
Knut Øvsthus Gradering:
Eventuelle Merknader:
Oppdragsgiver: Teknisk Informatikk AS
Oppdragsgivers referanse:
Oppdragsgivers kontaktperson(er) (inklusiv kontaktinformasjon): Lars Edgar Berg [email protected] Tlf: 91 88 23 39
Revisjon Dato Status Utført av
v.0.11 25.01.16 Første utkast, punkt 1 og 2 Marius Aasbak
v.0.12 27.01.16 Del3 ferdig, første versjon av ferdig forprøve Marius Aasbak
v.0.13 01.02.16 Kravspesifikasjon, flytskjema, problemstilling oppdatert
Marita Furnes
v.0.14 01.02.16 Bakgrunn, Oppgave, Problemstilling Kristoffer Rye
v.0.15 28.03.16 Midtveispresentasjon, hovedidé for løsning Marita Furnes
v.0.16 14.04.16 Midtveispresentasjon ferdig Kristoffer Rye
v.0.17 20.05.16 Funksjonalitet Kristoffer Rye
v.0.18 22.05.16 Sikkerhet og personvern Sondre Svendsen
v.0.19 24.05.16 Problemstilling, mulige løsningsforslag Marita Furnes
v.0.20 24.05.16 Brukergrensesnitt Marita Furnes
v.0.21 24.05.16 Testing Sondre Svendsen
v.0.22 27.05.16 6 Evaluering Marius Aasbak
v.0.23 30.05.16 Evaluering revisjon Sondre Svendsen
v.0.24 30.05.16 Kravspesifikasjon, utføring Marita Furnes
v.1.0 31.05.16 Ferdigstilling Alle
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 3(38) 01.06.16
Forord
Denne bacheloroppgaven er skrevet i forbindelse med et prosjekt som Lars Edgar Berg har laget. Vi er
veldig glad for å kunne bidra i utviklingen av dette prosjektet og setter pris på det forarbeidet som Lars
har gjort for oss. Vi vil derfor takke han for en meget god innsats og at vi fikk jobbe med denne
oppgaven.
Bacheloroppgaven har vært både utfordrende og lærerik. Mange av utfordringene vi støttet på
underveis har vært restriksjoner i databasen, men vi har med dette funnet gode løsningsmetoder i
selve kildekoden som gjør at applikasjonen vil fungere som en mobil plattform for bestilling av
tjenester.
Underveis i oppgaveløsningen har vi tilegnet oss mye kunnskap, både når det gjelder teknisk
funksjonalitet i hvordan sosiale mobile grensesnitt fungerer, og hvordan man samarbeider om å skape
et felles produkt.
Vi vil takke Høgskolen i Bergen for at vi fikk muligheten til å skrive denne bachelor oppgaven og bruke
deres lokaler.
Vi vil også rette en takk til Knut Øvsthus som har vært vår veileder underveis. Takk for god veiledning
og støtte! Å skrive denne bacheloroppgaven har vært en lærerik opplevelse. Selve programmeringen
og problemløsningen har vært både krevende og vanskelig, men vi har hatt god hjelp av internett
underveis. Vi vil derfor benytte denne anledningen til å takke internett for utrolig bra hjelp. Uten
internett hadde vi ikke klart å gjennomføre denne oppgaven.
Til slutt vil vi få lov til å takke oss selv i denne bachelorgruppen for god innsats og viljestyrke.
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 4(38) 01.06.16
Sammendrag
Oppgaven gikk ut på å lage en applikasjon for Android enheter for bestilling av tjenester.
Kommunikasjon med databasen for tjenestene foregår via et Web-API som leverer og tar imot JSON
script. Tilbydere legger ut oppdrag de er tilgjengelige for og brukere kan så bestille disse.
I forbindelse med oppgaven ble det laget to applikasjoner:
Monitor applikasjon som inneholder alle funksjoner som Web-API har tilgjengelig. Dvs.
opprette(POST), slette(DELETE), oppdatere(PUT) og hente(GET). Denne var kun ment for
testing av funksjoner og for å legge inn test-data i databasen.
Bruker applikasjon som har grensesnitt og funksjoner beregnet på brukere av tjenesten.
Bruker applikasjonen har en del mangler i forhold til kravspesifikasjon. Disse stammer i hovedsak fra
mangler ved serversiden og inntil denne oppdateres er det ikke mulig å ferdigstille en applikasjon.
Dette er nærmere forklart i kapittel 6.2.
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 5(38) 01.06.16
1 Innhold Dokumentkontroll ................................................................................................................................... 2
Forord ...................................................................................................................................................... 3
Sammendrag ........................................................................................................................................... 4
1 Innledning ........................................................................................................................................ 7
1.1 Oppdragsgiver ......................................................................................................................... 7
1.2 Problemstilling ......................................................................................................................... 7
1.2.1 Brukergrensesnitt ........................................................................................................ 7
1.2.2 Kommunikasjon ........................................................................................................... 7
1.3 Hovedidé for løsningsforslag ................................................................................................... 8
1.3.1 Teknologi og funksjonalitet ......................................................................................... 8
1.3.2 Brukergrensesnitt ........................................................................................................ 8
2 Kravspesifikasjon ............................................................................................................................. 9
2.1 Krav til brukergrensesnitt ........................................................................................................ 9
2.2 Krav til funksjoner ................................................................................................................... 9
3 Analyse av problemet .................................................................................................................... 10
3.1 Kommunikasjon mot server .................................................................................................. 10
3.2 Brukergrensesnitt .................................................................................................................. 10
3.3 Sikkerhet og personvern ....................................................................................................... 10
3.3.1 Personvern................................................................................................................. 10
3.3.2 Kommunikasjon ......................................................................................................... 10
3.4 Utforming av mulige løsninger .............................................................................................. 11
3.4.1 Innhold, metode og funksjonalitet ............................................................................ 11
3.4.2 Kommunikasjon mot server ...................................................................................... 12
3.4.3 Brukergrensesnitt ...................................................................................................... 13
3.4.4 Vurderinger i forhold til verktøy ................................................................................ 14
4 Realisering av valgt løsning ........................................................................................................... 16
4.1 Kommunikasjon mot server .................................................................................................. 16
4.1.1 Oppbygging av kode som kommuniserer med serveren........................................... 17
4.1.2 Algoritme for innlogging ............................................................................................ 19
4.1.3 Oppbygning av koden bak hovedaktiviteten ............................................................. 21
4.1.4 Opprette en ny tjeneste ............................................................................................ 21
4.1.5 Logg fragmentet ........................................................................................................ 23
4.1.6 Registrering av ny bruker .......................................................................................... 23
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 6(38) 01.06.16
4.1.7 Begrensninger i serveren ........................................................................................... 24
4.2 GUI – Brukergrensesnitt ........................................................................................................ 25
4.2.1 Funksjoner ................................................................................................................. 25
4.2.2 Oppbygging av oppsettet .......................................................................................... 28
5 Testing ........................................................................................................................................... 29
5.1 Brukstest ................................................................................................................................ 29
5.2 Feiltesting .............................................................................................................................. 31
6 Evaluering ...................................................................................................................................... 32
6.1 Utføring ................................................................................................................................. 32
6.1.1 Utforming av eventuelle løsninger ............................................................................ 32
6.1.2 Generell utføring og hendelser underveis ................................................................. 32
6.2 Konklusjon og ettertanker ..................................................................................................... 34
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 7(38) 01.06.16
1 Innledning
1.1 Oppdragsgiver Teknisk Informatikk AS er et aksjeselskap som driver konsulentvirksomhet innen programvareutvikling
for tekniske anvendelser. Selskapet ble stiftet i 1988 av hovedaksjonær og daglig leder, Lars Edgar Berg.
1.2 Problemstilling Oppdragsgiver ønsker en applikasjon for mobil og nettbrett som kan knytte sammen tjenester fra en
tilbyder til en bruker. Oppdragsgiver har opprettet en database som inneholder ulike tjenestegrupper
og vil i fremtiden stå for opprettelsen og vedlikeholdet av tilbydere og de ulike tjenestegruppene.
Brukerdelen skal kunne opprettes i applikasjonen og brukerdata skal sendes til databasen. Brukere
med fullstendig profil skal kunne bestille tilgjengelige tjenester fra databasen. Applikasjonen
oppdateres direkte fra databasen og ikke lokalt. Applikasjonen skal benyttes på mobiltelefon og
nettbrett som har Android operativsystem. Applikasjonen skal ha et enkelt brukergrensesnitt tilpasset
brukergruppen og programmeres for at videreutvikling enkelt kan overtas av nye oppdragsgivere.
Tjenestene skal være gratis og basere seg på frivillighetsprinsippet.
Formålet med prosjektet er at applikasjonen skal kunne brukes i praksis av ulike offentlige instanser.
1.2.1 Brukergrensesnitt
Utvikle en slik applikasjon som oppfyller oppdragsgivers kriterier og kravspesifikasjoner. Applikasjonen
skal fungere som et verktøy for brukergrupper som ønsker å bestille tjenester etter behov.
Brukergruppen vil primært være under kommunal helsetjeneste og applikasjonen må derfor utvikles
med et brukergrensesnitt som kan passe for alle.
1.2.2 Kommunikasjon
Applikasjonen skal snakke med databasen i reell tid og all informasjon om brukere, tilbydere og
tjenester ligger på serveren. Programmet må derfor utvikles for å kunne oppdateres uten at det går på
bekostning av brukeropplevelsen og grensesnittet. Oppkoblingen mot serveren skal være sikker og
pålitelig.
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 8(38) 01.06.16
1.3 Hovedidé for løsningsforslag
1.3.1 Teknologi og funksjonalitet
Applikasjonen skal kodes i Android Studio. Metoder og funksjoner kodes i Java og oppbyggingen av
oppsettet gjøres med XML. For å kommunisere med serverer benyttes det ferdig implementerte
biblioteket Retrofit
Systemets oppgave er å finner en eller flere tilbydere som kan være aktuelle og sender en forespørsel
til disse basert på brukerens valg. Brukeren kan hente tilgjengelige tjenester og tjenestegrupper fra
databasen og opprette en bestilling direkte på en tjeneste. Når brukeren har opprettet tjenesten skal
bestillingen sendes til databasen som en ny ordre med ordrenummer.
Databasen skal inneholde oversikt over alle ordrer fra alle brukere. Hver bruker skal kunne hente frem
en oversikt over egne ordrer og få de presentert i en oversiktlig logg. Hver ordre identifiseres med et
ordrenummer.
Kjernen i systemet er en ASP.NET iweb-applikasjon som administreres gjennom en separat applikasjon
og Web-GUI som blir installert hos systemeier og i utviklingsfasen også hos utvikler.
1.3.2 Brukergrensesnitt
Applikasjonen skal ha et enkelt brukergrensesnitt. Navigeringen skal være enkel og ikke kreve at bruker
på trykke mye for å komme til ønsket tjeneste.
Tenkt flytdiagram for applikasjonens virkemåte
Figuren over viser flytdiagram for hvordan applikasjonen er tenkt å bygges opp. Navigeringen i
applikasjonen gjøres med en Navigation Drawer ii som presenterer en menyliste over tilgjengelige
tjeneste som bruker kan hente ved å swipe fra venstre mot høyre i telefonen eller trykke på
hamburgerikonet øverst i venstre hjørnet.
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 9(38) 01.06.16
2 Kravspesifikasjon Oppdragsgivers krav til oppgaven er en applikasjon som kan kommunisere med Android-enheter via
internett med en nettleser. Programmet skal snakke med en ekstern database på en ekstern
webserver. Applikasjonen skal kunne hente, opprette og endre relevant data fra serverer og
presentere disse på enheten til brukeren. Data som opprettes av brukeren skal formidles til databasen.
Kode og struktur skal beskrives på en slik måte at systemet senere kan videreutvikles av andre
Server struktur og kobling til Android
2.1 Krav til brukergrensesnitt Applikasjonen brukergruppe er fra oppdragsgivers side tenkt å brukes av mennesker med behov for
ulike tjenester som kan utføres på frivillighetsbasis. Applikasjonen må derfor ha et brukervennlig
brukergrensesnitt som er tilpasset en generasjon som ikke er kjent med mobilteknologi. Applikasjonen
skal ha oversikt presentasjon av innholdet og bør ikke ha mye skrift med liten skriftstørrelse.
2.2 Krav til funksjoner En ekstern database vil inneholde liste over tilbydere, tilgjengelige tjenester og informasjon om
brukere. Applikasjonen skal inkludere en aktivitet for å opprette bruker og for å logge inn i
applikasjonen.
Etter innlogging skal bruker ha tilgjengelig en profilside som skal inkludere følgende punkter;
- Profilinformasjon
o Mulighet å se og endre dataen som er registrert om brukeren
- Tilgjengelige tjenester
o Bestille ny tjeneste
Opprette tjeneste direkte fra menyen
Hurtigbestilling via handlingsknapp
o Se oversikt over bestillinger
o Meldingssenter
Lagre kontaktinformasjonen til tilbyder
Sende og motta meldinger fra tilbyder
o Rating/Log av utførte tjenester
Bruker får tilgang til å rate tjenesten ved å markere et antall stjerner fra null
til fem, samt en tekstboks med mulighet for å skrive en kommentar.
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 10(38) 01.06.16
3 Analyse av problemet
3.1 Kommunikasjon mot server For at applikasjonen skal fungere optimalt må den til enhver tid kunne kommunisere med databasen.
Dersom nye tjenestegrupper, brukerdata eller andre funksjoner i databasen opprettes, endres eller
slettes skal applikasjonen oppdatere innholdet automatisk. Databasen ligger på en skytjeneste og
kommuniserer via Web-APIer. For å kommunisere med databasen via Web-APIer brukes noen
standard metoder, de som er relevante er POST, GET, PUT og DELETE.
POST – Oppretter ny oppføring i databasen
GET – Henter en oppføring fra databasen
PUT – Oppdaterer en oppføring i databasen
DELETE – Sletter en oppføring i databasen
Informasjonen som utveksles mellom applikasjon og database forgår i JSON-format. Applikasjonen må
konvertere og sortere denne informasjonen.
3.2 Brukergrensesnitt Applikasjonen skal etter all sannsynlighet benyttes av mennesker uten dyp teknisk forståelse. Det er
derfor viktig at navigeringen i applikasjonen er informativ og enkel å bruke for alle. For å gi mest mulig
brukeropplevelse vil en lett gjenkjennelig applikasjon være den beste løsningen. Layout og navigering
baseres derfor på kjente applikasjoner med funksjoner som de fleste kan håndtere.
3.3 Sikkerhet og personvern
3.3.1 Personvern
Det stilles krav til behandling av personopplysningeriii, dette ivaretas på serversiden.
3.3.2 Kommunikasjon
En av grunnene til at Web-APIer benyttes er sikkerhet. Kommunikasjon med disse foregår ved at når
bruker logger inn med riktig brukernavn og passord vil den motta en kode (tokeniv) som benyttes for å
kommunisere med databasen. Denne koden har en begrenset gyldighet bestemt av administrator.
Sikker kommunikasjon over httpsv
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 11(38) 01.06.16
3.4 Utforming av mulige løsninger
3.4.1 Innhold, metode og funksjonalitet
For å få tilstrekkelig oversikt over hvordan kommunikasjon med Web-API ble det utviklet en
monitorapplikasjon med metoder for å logge inn, registrere brukere, hente oversikt over registrerte
brukere, hente gruppeoversikt, opprette grupper, hente oversikt over tilbydere, opprette nye
tilbydere, oversikt over tjeneste og tjenestegrupper, opprette ny ordre og hente oversikt over ordrer.
Applikasjonen ble utviklet med hensyn på metoder, funksjonalitet og kommunikasjon med databasen.
Applikasjonen har et enkelt brukergrensesnitt der eneste hensikt er å bekrefte eller avkrefte
kommunikasjonen mot databasen og teste diverse funksjoner.
Denne monitorapplikasjonen inneholder funksjoner og tjenester som skal være tilgjengelig i den
ferdige applikasjonen. I tillegg er funksjoner og tjenester på tilbydersiden opprettet. Den er laget med
tanke på å ha full oversikt og tilgang til å opprette, endre og slette variabler i serveren for testing. I
tillegg til de vanlige funksjonene i det ferdige produktet, er det i monitorapplikasjonen mulighet for å
opprette nye tilbydere, tjenester og tjenestegrupper. Dette er funksjoner som ikke er tenkt å være
tilgjengelig i den endelige applikasjonen. Opprettelse av tilbydere foregår under restriksjoner og krav
som oppdragsgivers samarbeidspartnere utformer.
Monitorapplikasjonen ble utviklet som en del forstudien for å utforske og eksperimentere ulike
løsninger for å kunne utvikle en applikasjon med et resultat som tilfredsstiller kravene til både
kommunikasjonen og brukergrensesnittet på en balansert måte. For å nå det målet er det
hensiktsmessig å opprette funksjoner fra tilbydersiden for å få et fullstendig overblikk over nødvendige
informasjon og kunnskap som kreves for å lage den ferdige applikasjonen.
MonitorApp
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 12(38) 01.06.16
3.4.2 Kommunikasjon mot server
3.4.2.1 AsyncTaskvi med HttpURLConnectionvii
Standard implementert i Android for bakgrunns operasjoner. All JSON script må manuelt konverteres
til Java-objekter(POJO).
Fordeler og ulemper
Innebygget, trenger ikke implementering av nye biblioteker
- Kjører i serie som standard, ikke parallell
- Manuell konvertering til POJO
- Knyttet til aktivitet, kan forårsake memory leaks
- Uoversiktelig kode
- HttpURLConnection
3.4.2.2 Volleyviii
Et bibliotek utviklet av Google ix med innebygget nettverksprotokoll (HttpURLConnection), som
automatisk konverterer til POJO. Volley støtter og OKHttpx med mer konfigurering.
Fordeler og ulemper
Oversiktlig
Kjører i parallell som standard
Ikke knyttet til aktiviteter
Automatisk konvertering til POJO
- Dårlig dokumentert
- HttpURLConnection (standard, krever mer konfigurasjon for å benytte OKHttp)
3.4.2.3 Retrofitxi
Et bibliotek utviklet av Square xii med innebygget nettverksprotokoll (OkHttp), som automatisk
konverterer til POJO.
Fordeler og ulemper
Oversiktlig
Kjører i parallell som standard
OKHttp
Ikke knyttet til aktiviteter
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 13(38) 01.06.16
Automatisk konvertering til POJO
God dokumentasjon
- Mindre tilpasningsmuligheter enn Volley
3.4.3 Brukergrensesnitt
For å gjøre applikasjonen attraktiv for tenkt brukergruppe må brukergrensesnittet være enkelt å forstå.
Det bør være tilstrekkelig informasjon i programmet uten at dette går ut over brukervennligheten eller
navigeringsmuligheter. For å oppnå dette er det vurdert ulike løsninger som eksisterer i dag ettersom
mange brukere allerede er kjent med bruken. Målet vårt er å skape et produkt som har et visuelt språk
som er lett gjenkjennelig for de fleste.
3.4.3.1 Vurderinger i forhold til oppsett og navigering
Monitorapplikasjonen gav en indikasjon på hvordan applikasjonen fungerer ved å bruke en ny aktivitet
for hver funksjon. Dette viste seg å være upraktisk som et brukergrensesnitt. Det kreves mye koding
og programmet blir uoversiktlig for brukeren. Ved å opprette nye aktiviteter vil navigeringen kreve at
brukeren må trykke mer for å komme til ønsket funksjon. Det kan i tillegg være vanskelig å vite
posisjonen i applikasjonen og dermed blir navigeringen vanskelig å håndtere for bruker. Ettersom
brukervennligheten er et viktig punkt i utviklingen av applikasjonen må brukergrensesnittet endres en
del.
Google har publisert et bibliotek som inneholder beskrivelser, dokumentasjoner og nyttig informasjon
om ulike stilarter og funksjoner som kan implementeres i applikasjoner. Selve innloggingsaktiviteten
vil fremstå som forholdsvis enkel med tekstfelter for brukernavn, passord og en knapp for å logge inn,
samt mulighet for å registrere ny bruker.
Aktiviteten for opprettelse av ny bruker gjøres med samme type layout som innlogging. Tekstfelter for
innfylling av brukerdata og en knapp for å sende dataen til serveren.
3.4.3.2 Hierarki
For at bruker skal få en effektiv og enkel brukeropplevelse av applikasjonen er hierarkiet i oppsettet
en viktig faktor. For å unngå at brukeren må bruke tilbakeknappen i flere omganger for å for eksempel
returnere til hovedsiden må det vurderes om en spesifikk aktivitet skal fungere som overordnet mens
fragmentaktiviteter blir underordnet, eller om alle aktivitetene skal sidestilles.
3.4.3.3 Kommunikasjon mellom bruker og tilbyder
Behovet for kommunikasjon mellom tilbyder og bruker kan være til stede. En bruker kan ha behov for
tilrettelegging ut over det applikasjonen tilbyr. Det må derfor vurderes om en slik kommunikasjon skal
foregå i applikasjonen eller om dette gjøres via andre kanaler.
3.4.3.4 Navigering mellom tjenester
Fra Google sitt designbibliotek tenkes en Navigation Drawer å være et alternativ til navigering mellom
de ulike tjenestene i applikasjonen.
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 14(38) 01.06.16
Bildet her hentet fra Google sitt designbibliotek og viser topologien
i en Navigation Drawer.
1. Brukers navn
2. Brukers e-postadresse
3. Liste over menyvalg
4. Utvidet meny
Menyen deles opp slik at en del er informasjon om bruker,
innstillinger og eventuelt opplysninger om FriSats. I utvidet meny
plasseres bestillinger, meldinger og eventuelt annet som kan
utføres.
3.4.3.5 Programlinje
I tillegg til Navigation Drawer vurderes det om en programlinje kan være aktuelt. Denne kan plasseres
øverst i vinduet eller bunnen. En programlinje vil typisk bestå av bare ikoner eller ikoner og sidetittel.
Sidetitler vil mest sannsynligvis ha veldig liten skrift og tenkt brukergruppe er ikke nødvendigvis kjent
med hva de ulike ikonene står for.
3.4.4 Vurderinger i forhold til verktøy
3.4.4.1 Android Studioxiii
Android studio er et verktøy for utvikling av Android-applikasjoner. Utforming av layout programmeres
med XML og aktiviteter programmeres i Java.
3.4.4.2 Eclipsexiv
Eclipse er et Verktøy for utvikling av applikasjoner med en plugin for Android utvikling. Utforming av
layout programmeres med XML og aktiviteter programmeres i Java
3.4.4.3 Gitxv
Git er et revisjonskontrollsystem som lagrer koden på nettet. Her kan flere brukere jobbe samtidig med
samme koden, eksisterende kode kan kjøres sammen med ny kode for testing. Etter ny kode er lastet
opp, blir versjonsnummer oppdatert og ny kode tilgjengelig for alle brukerne.
Navigation Drawer
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 15(38) 01.06.16
3.4.4.4 Visual Studioxvi
Visual Studio er et verktøy fra Microsoft for programutvikling.
3.4.4.5 Microsoft SQL Server 2016xvii
MS SQL Server er en database server.
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 16(38) 01.06.16
4 Realisering av valgt løsning Resultatet av monitorapplikasjonen viste at Retrofit er den mest oversiktlige og tilrettelagte metoden
for kommunikasjon med Web-API i dette prosjektet. Retrofit er godt dokumentert og mye nyttig
informasjon og hjelpemidler er lett tilgjengelig på Internett. Android Studio er det mest praktiske
verktøyet å bruke for å utvikle applikasjoner for Android-enheter og krever lite implementasjon av
plug-ins eller andre utvidelser som for eksempel Eclipse krever på et slikt prosjekt. Android Studio
inkluderer flere typer aktivitetsoppsett og Navigation Drawer aktiviteten inkluderer flere ferdig
genererte metoder og valget falt på denne for navigering mellom menyvalg. Githubxviii ble brukt for Git
revisjonskontroll.
4.1 Kommunikasjon mot server Implementeringen av Retrofit i applikasjonen inkluderer:
klassen RestAdapter – Innebygget adapter klasse for å hente URL til serveren
RestInterface – Interface som inneholder kommunikasjons metoder med serveren
POJO Java variabler
For at Retrofit skal fungere i Android Studio ble det implementert to biblioteker i Gradlexix filen:
Retrofit bibliotek: compile 'com.squareup.retrofit:retrofit:1.9.0'
OKhttp bibliotek: compile 'com.squareup.okhttp:okhttp:2.4.0'
For å generere objekter fra API er det brukt JSON-konverteren fra http://www.jsonschema2pojo.org/.
Retrofits virkemåtexx
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 17(38) 01.06.16
4.1.1 Oppbygging av kode som kommuniserer med serveren
Webgrensesnittet på http://frisats3.azurewebsites.net/ har støtte for GUI, men i de spesielle URL-ene
som for eksempel http://frisats3.azurewebsites.net/api/customers/ er det kun et JSON script som blir
vist. JSON script er en åpen standard som bruker tekst for å sende data objekter fra en API til en
bestemt tjeneste. JSON script bruker et såkalt «tekstpar» som beskriver hver variabel av objektet der
den første delen av dette paret er navnet på variabelen og den andre delen er verdien til variabelen. I
en nettleser har man mulighet til å se dette JSON scriptet når man besøker en webside som støtter
JSON script. Nedenfor ser man et eksempel av JSON scriptet til en bestemt kunde som er lagret i
databasen.
{
CustomerId: 12,
UserID: 123,
FirstName: "Olga",
LastName: "Olgersen",
Address: "Solgaten 123",
PostNo: "5080",
Location: "Soldalen",
Telephone: "12345678",
Latitude: 0,
Longitude: 0,
Email: "[email protected]",
Rating: 0
},
For å kunne dra nytte av JSON scriptet fra websiden er det blitt brukt en online JSON konverterer som
gjør om JSON script til en POJO klasse. Alle variabler i klassen blir med dette auto generert med GET –
og SET-funksjoner og er klar til å bli implementert i koden. Det er laget en POJO klasse for hver av API-
ene tilgjengelig fra websiden til Azure. POJO klassene som er med i koden er:
Customers - http://frisats3.azurewebsites.net/api/customers
Groups - http://frisats3.azurewebsites.net/api/groups
Orders - http://frisats3.azurewebsites.net/api/orders
Providers - http://frisats3.azurewebsites.net/api/providers
Services - http://frisats3.azurewebsites.net/api/orders
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 18(38) 01.06.16
Under er det tatt med et forenklet utklipp av hvordan POJO klassen Customers er bygget opp.
public class Customers { @SerializedName("CustomerId") @Expose private Integer CustomerId; @SerializedName("UserID") @Expose private Object UserID; public Integer getCustomerId() { return CustomerId; } public void setCustomerId(Integer CustomerId) { this.CustomerId = CustomerId; } }
Alle metoder som har med kommunikasjon med serveren å gjøre er definert i en egen Interface klasse
som er kalt for «RestInterface». Her ble Retrofit biblioteket importert, som brukes når det skal
kommuniseres med serveren.
import retrofit.Callback; import retrofit.http.Body; import retrofit.http.DELETE; import retrofit.http.GET; import retrofit.http.POST; import retrofit.http.PUT;
Inne i RestInterface klassen er metodene bygget opp av merknader (@) av type @POST, @GET, @PUT
og @DELETE. Hver av disse peker til en bestemt sti i web-grensesnittet på frisats3.azurewebsites.net
og inneholder en bestemt metode som inneholder et objekt av den bestemte klassen fra POJO. Hver
av disse merknadene har forskjellig virkemåte og metode-oppbygning. @POST merknaden brukes til å
opprette variabler i serveren, @GET er for å hente ned variabler fra serveren, @PUT er for å oppdatere
allerede eksisterende variabler i serveren og @DELETE er for å slette variabler. Disse metodene er kun
støttet ved importering av Retrofit. Under ser man et utklipp av hvordan metodene i RestInterface
klassen er bygget opp for POJO-klassen «Customers».
@POST("/api/customers") void createNewCustomer(@Body Customers newCustomer, Callback<Customers> cb); @GET("/api/customers") void getCustomers(Callback<List<Customers>> response); @PUT("/api/customers/{id}") void updateCustomer(@Path("id")int userId, @Body Customers putCustomer, Callback<Customers> callback); @DELETE("/api/customers/{id}") void deleteCustomer(@Path("id")long userId, Callback<Customers> callback);
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 19(38) 01.06.16
I de forskjellige aktivitetsklassene er URL lagt inn til det Web-API det kobles mot:
private String url = "http://frisats3.azurewebsites.net";
For å kunne utnytte URL brukes det en innebygget klasse (RestAdapter) i Java som oppretter et nytt
objekt som inkluderer samme URL. Deretter opprettes et objekt fra Interface-klassen
«RestInterface». Dette objektet har tilgang til å kalle på alle metodene fra denne klassen.
RestAdapter adapter = new RestAdapter.Builder().setEndpoint(url).build(); final RestInterface restInterface = adapter.create(RestInterface.class);
Metodene fra RestInterface hentes i hver aktivitet ved å bruke RestInterface objektet og fylle inn
parameterne til metoden i klassen «RestInterface». Denne metoden kan kun brukes ved
implementering av Retrofit og krever implementering av en «success» metode og en «failure» metode.
Hvis serveren er oppe og parameterne i RestInterface metoden er riktig vil da suksessmetoden kjøre
og kommunikasjon med serveren er da opprettet. Nedenfor vises et utklipp av hvordan liste over
brukere hentes fra en aktivitet ut i fra denne fremgangsmåten.
restInterface.getCustomers(new Callback<List<Customers>>() { @Override public void success(List<Customers> list, Response response) { //Henter kundene inn I en liste } @Override public void failure(RetrofitError error) { errorText.setText("En feil oppstod :("); } });
4.1.2 Algoritme for innlogging
I virkeligheten er det normalt å ha en egen server der brukere av en applikasjon er lagt inn i en egen
database. Her vil da vanligvis brukernavn og passord være lagret. I dette tilfellet er det bare én server
som inneholder variabler for kundens personalia og ikke felter for brukernavn og passord. Det ble
derfor bestemt at ved innlogging benyttes fornavnet til kunden som brukernavn og passordet vil da
være etternavnet til kunden.
Den første siden som vises når man åpner applikasjonen første gang er innloggingssiden. Her har man
enten muligheten til å klikke på «Registrer ny bruker» knappen som tar deg med til en aktivitet der
man kan opprette en ny bruker i serveren, eller logge inn med brukernavn og passord. På
innloggingsskjermen er det to tekstfelt som må være utfylt for at en bruker av applikasjonen kan logge
seg inn. Disse to tekstfeltene må inneholde verdiene som er lagt inn i databasen. Kriteriene for at man
skal kunne logge seg inn er at man har skrevet inn en bruker som eksisterer i databasen og at passordet
man har skrevet er det riktige passordet til denne brukeren.
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 20(38) 01.06.16
Måten koden ved innlogging er bygget opp på er som følger:
1. Hente ned en oversikt over alle brukerne i databasen.
2. Sjekke at i tekstfelt 1 står det en bruker som eksisterer i databasen. Hvis dette ikke er tilfelle
får man en feilmelding på skjermen som sier «Denne brukeren eksisterer ikke» og man kan
ikke logge seg inn.
3. Sjekke at det passordet som er skrevet i tekstfelt 2 er det samme passordet som brukeren har
i databasen. Hvis passordet ikke samstemmer får man en feilmelding på skjermen som sier
«Passordet er feil» og man kan ikke logge seg inn.
4. Hvis begge tekstfeltene blir godkjent, åpnes hovedaktiviteten i applikasjonen og all
informasjonen og variablene til brukeren blir overført til denne aktiviteten.
public void loggInn() { restInterface.getCustomers(new Callback<List<Customers>>() { @Override public void success(List<Customers> list, Response response) { customersList = list; String[] items = new String[customersList.size()]; String[] passordItems = new String[customersList.size()]; for (int i = 0; i < customersList.size(); i++) { items[i] = customersList.get(i).getFirstName(); passordItems[i] = customersList.get(i).getLastName(); if (brukernavnEditText.getText().toString().equals(items[i])) { brukerNummer = i; klar = true; break; } else {errorText.setText("Denne brukeren finnes ikke");klar = false;}} if (klar == true) { if (passordEditText.getText().toString().equals(passordItems[brukerNummer])) { startActivity(intent); } else { errorText.setText("Feilt passord...");}
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 21(38) 01.06.16
4.1.3 Oppbygning av koden bak hovedaktiviteten
Hovedaktiviteten er den første aktiviteten man kommer til etter innlogging på appen. Denne
aktiviteten er kalt for NavigationDrawerActivity og inneholder alle variablene til brukeren. Oppå denne
aktivitetsklassen ligger det forskjellige underfragmenter som brukeren har muligheten til å navigere
mellom ved hjelp av en «Slide-meny». I denne menyen finnes det:
Hjem
Profil
Innstillinger
Ny tjeneste
Kontakter
Meldinger
Logg
Av disse er det «Hjem», «Profil» og «Logg» som fører til et underfragmet av NavigationDrawerActivity-
klassen. «Hjem» fragmentet er det første som vises på skjermen etter innlogging. Her står det generell
informasjon om applikasjonen og hvordan den skal brukes. Når navigeringsmenyen er synlig vil og
bruker trykker på «Profil» knappen, blir Profil fragmentet vist på skjermen der all informasjon om
brukeren blir hentet fra den nåværende aktiviteten (NavigationDrawerActivity) og vist på skjermen.
Menyknappene «Innstillinger», «Kontakter» og «Meldinger» er ikke i bruk, men er nyttig å ha med for
videreutvikling av applikasjonen. Til nå har ikke serveren hatt støtte for at en kunde kan ha et felt som
heter «Kontakter». Den har heller ikke støtte for meldinger med kontakter, men ble opprettet for å
vise muligheten for senere implementering.
Håndteringen av fragmentoverføringen i en aktivitet er kalles en fragment-transaksjon. I hovedmenyen
er det en boolsk variabel (onNavigationDrawerSelected) som sjekker om det klikkes på en av knappene
i menyen og kjører så «if» og «else if» uttalelser for å sjekke hvilken knapp som ble klikket på. Inne i
disse uttalelsene ligger det metoder for å veksle mellom de forskjellige fragmentene som overfører
parameterne fra NavigationDrawerActivity til det utvalgte fragmentet.
4.1.4 Opprette en ny tjeneste
Ved klikk på «Ny tjeneste» knappen i menyen åpnes en ny aktivitet som viser en oversikt over alle
tjenestegruppene som finnes i serveren som en ListView (standard liste å bruke i Android). Her er det
gruppenavnet til gruppen som blir vist i listen. All informasjon om brukeren er overført som en intent
til denne aktiviteten fra NavigationDrawerActivity til videre bruk. Brukeren har muligheten til å klikke
på en av tjenestegruppene i listen og dermed åpnes en ny aktivitet som inneholder en ny liste med alle
tjenestenavnene som tilhører denne gruppen. Måten dette ble gjort på er som følger:
1. Ta vare på den verdien som brukeren klikker på i ListView (gruppenavnet) og overføre det til
neste aktivitet.
2. Hente ned en liste over alle tilgjengelige tjenester i serveren.
3. Sjekke hver eneste tilgjengelige tjeneste om de har det samme gruppenavnet som brukeren
klikket på.
4. Vise alle tjenestene som har det samme gruppenavnet i den nye listen.
Her har brukeren mulighet til å velge tjenesten som skal bestilles. Ved klikk på en av tjenestene i listen,
åpnes en ny aktivitet som er kalt for BestillingsActivity.
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 22(38) 01.06.16
For at bestillingen skal gå igjennom er serveren lagt opp på en måte at den ikke kan motta feile verdier
for variablene. Det vil si at i en @PUT funksjon som skal opprette en order må inneholde variabler av
riktig verdi, ellers blir ikke bestillingen godkjent av serveren. For å unngå at brukere oppgir feile verdier
som fører til at serveren ikke får prosessert bestillingen er det lagt inn bestemte tekstfelt der det kun
kan skrives inn en tekst-verdi for datafeltet «Location» og kun tallverdier i feltet «Unit Price».
Serveren krever også et bestemt oppsett på hvordan tidspunktet i tjenesten er lagt opp. Serveren
bruker dette tidsformatet:
2000-01-01T00:00:00
For å gjøre det enkelt for brukere å legge inn tidspunkt på tjenesten i dette formatet er det brukt noen
innebygde klasser i Android som gir ut klokkeslett og dato på denne formen. Når en bruker klikker på
tekstfeltet for klokkeslett, kommer det opp en innebygget dialog fra Android som kalles for en
TimePickerDialog. Her har brukeren mulighet til å velge et nøyaktig tidspunkt for tjenesten. På samme
måte får brukeren opp en DatePickerDialog når tekstfeltet for dato blir trykket på. Denne måten å
velge tidspunkter på er en god standard å bruke for Android applikasjoner fordi de tvinger brukere til
å velge tidspunkter i riktig format. Det er avhengig av hvilken Android versjon som brukes hvordan
TimePickerDialog og DatePickerDialog ser ut. Under ser man hvordan de ser ut i appen når den kjøres
på et Android KitKat 4.4.2 system:
Timepicker & Datepicker
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 23(38) 01.06.16
4.1.5 Logg fragmentet
Fra hovedmenyen har brukeren tilgang til en knapp som heter logg. Klikkes det på denne knappen
skiftes det daværende fragmentet til et fragment som viser loggen til brukeren. Loggen til brukeren er
alle de bestillingene som brukeren har opprettet. Disse bestillingene blir vist etter ordre ID i en ListView
i Logg fragmentet. Brukeren har herifra mulighet til å scrolle nedover listen over alle sine bestillinger
og klikke på en av dem for å vite mer informasjon om dem.
Datafeltene til klassen «Orders» inneholder flere felter som beskriver bestillingen. Et av feltene er et
objekt av klassen «Services» som inneholder all informasjon om tjenesten, inkludert tilbyderens ID for
å vite hvem som leverer tjenesten. Denne ID-en heter «ProviderID» og er den samme som ID-en til en
tilbyder i «Provider»-klassen. Dermed er det ganske enkelt å finne ut hvem som er tilbyder for en
hvilken som helst tjeneste og få ut informasjon om tilbyderen.
For å vite hvilken kunde som har bestilt en tjeneste brukes det i stedet: «UserID». Hver kunde som er
lagret på serveren har en bestemt UserID. For at loggen til kun brukeren skal vises i Logg-fragmentet
brukes følgende framgangsmåte:
1. Overfører informasjon om kunden til Logg-fragmentet.
2. Henter ned en liste over alle eksisterende bestillinger fra serveren.
3. Sjekker om de forskjellige bestillingene inneholder et «UserID»-felt som er det samme som
kunden sin «UserID».
4. Viser alle de matchende bestillingene i en ListView.
For at kunden skal kunne trykke på en av bestillingene i listen og vise informasjon om de, må verdien
av den bestillingen som kunden klikket på overføres til bestillingsinformasjon aktiviteten. Denne
verdien blir så hentet i den neste aktivitetsklassen. Herifra må alle Ordre hentes igjen i bakgrunnen og
sjekkes opp mot denne verdien. Når dette er gjort blir så all informasjon om bestillingen skrevet ut på
skjermen.
4.1.6 Registrering av ny bruker
Fra innloggingssiden har man mulighet til å klikke på teksten der det står: «Registrer ny bruker». Dette
åpner en helt ny aktivitet der 7 tekstfelt med personalia om kunden må fylles ut. Deretter kan det
klikkes på «REGISTRER» knappen og brukeren vil bli opprettet i serveren.
Det er tenkt over at det finnes mennesker med samme navn, samme adresse og samme sted, så alle
disse skal kunne få opprettet seg en bruker på serveren. Det aksepteres ikke i registreringen at det er
telefonnummer eller e-postadresse som eksister i databasen allerede. Forsøk på å registrere et
eksisterende telefonnummer eller e-postadresse vil ikke vil gi en feilmelding på skjermen om hva som
gikk galt. Det er ingen restriksjoner i serveren som gjør at man ikke kan opprette en bruker med samme
telefonnummer og e-postadresse og derfor er disse restriksjonene lagt i applikasjonen.
Koden for å registrere en ny bruker er som følger:
1. Det sjekkes først hva som står i tekstfeltene som brukeren har fylt ut.
2. Deretter hentes en liste med alle eksisterende brukere i databasen.
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 24(38) 01.06.16
3. Det sjekkes så om det er noen av brukerne i databasen som allerede har telefonnummeret
eller e-posten som brukeren skrev inn.
4. Er det en av disse som matcher, blir registreringen mislykket og en feilmelding blir vist på
skjermen.
5. Hvis ikke går koden inn i Retrofit sin suksessmetode og registreringen blir vellykket.
4.1.7 Begrensninger i serveren
På grunn av en feil på serversiden fungerer ikke funksjonene PUT og DELETE. PUT-funksjoner
oppdaterer eksisterende variabler av et objekt og DELETE-funksjoner sletter dem. Dette kan kun
utføres direkte fra grensesnittet på Azure via en nettleser. GET- og POST-funksjoner fungerer.
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 25(38) 01.06.16
4.2 GUI – Brukergrensesnitt
4.2.1 Funksjoner
Når brukeren laster ned og åpner applikasjonen for første gang vil en innloggingsside komme opp.
Fra den kan brukeren enten logge inn med brukernavn og passord eller opprette ny bruker
Bruker registrerer sin informasjon ved å trykke på «REGISTRER» under skjema og sendes tilbake til
introduksjonsskjermen. Når bruker har logget inn vil Navigation Drawer aktiviteten starte og brukerens
hovedside vises. Bak Navigation Drawer vil «Hjem»-aktiviteten være standardfragmentet etter
innlogging.
Innlogging og Registrering
Meny og Hjem
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 26(38) 01.06.16
«Profil»-fragmentet i Navigation Drawer henter informasjonen om brukeren fra databasen. Det
presenteres som en tekst for bruker og er ment som informasjon. «Instillinger»-fragmentet er tenkt å
inkludere muligheten for å endre på profildata. I dette fragmentet er det også tenkt at bruker kan
personalisere utseende på applikasjonen (forstørre skrift, endre farger osv.). Dette står foreløpig tomt
For å bestille en ny tjeneste kan brukeren enten trykke på «Ny tjeneste» direkte fra Navigation
Drawer eller bruke «+»-knappen nederst i høyre hjørnet. Bruker blir da sendt videre til gruppe-
fragmentet. Innholdet i dette blir hentet direkte fra databasen og dermed oppdatert ut i fra den.
Bildet under viser hvordan dette vil kunne ses ut for bruker.
Profil og Innstillinger
Bestilling og Tilbyderinformasjon
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 27(38) 01.06.16
Når bruker har valgt sin tjeneste åpnes aktiviteten for å bestille. Bruker kan i tillegg her trykke på
«KONTAKT INFORMASJON» for å se utfyllende informasjon om tilbyderen.
Fra Navigation Drawer kan bruker hente frem en logg over aktive og fullførte oppdrag. Loggen henter
informasjon direkte fra databasen og presenterer de som en liste. Bilde under viser hvordan dette
fremstilles for bruker. Hver ordre får tildelt et ordrenummer etter den er opprettet og denne listen vil
inneholde ordrenummeret til bestillingen og ikke antall bestillinger. Ved å trykke på et ordrenummer
vil ordredetaljene vises.
Navigation Drawer inkluderer også «kontakter» og «Meldinger». Disser er laget med hensikt å gjøre
det mulig å lagre kontaktinformasjonen til tilbyder. Vi har valgt å lage det som et alternativ ettersom
en bruker kan ha behov eller ønske om å kontakte tilbyder for å informere om ytterligere behov eller
annen informasjon som kan være nyttig for tilbyder under oppdraget. Brukeren kan opprette ny
melding direkte fra «Kontakter» eller fra «Meldinger»-aktiviteten. I tillegg til dette vil bruker kunne
opprette en ny melding til tilbyder direkte fra aktiviteten som viser detaljer om tilbyder ved å bruke
mail-knappen nederst i høyre hjørnet.
Gruppe og Tjenestevalg
Logg og Detaljer
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 28(38) 01.06.16
4.2.2 Oppbygging av oppsettet
Oppsettet til Navigation Drawer består av flere XML ressursfiler. Oppsettet for selve
navigeringsmenyen blir automatisk opprettet når Navigation Drawer aktiviteten opprettes. Den har
støtte for Android DrawerLayout og definerer hvordan menyen skal se ut og hvilke funksjoner eller
navigeringsmuligheter som skal være tilgjengelig. Videre utforming av oppsettet gjøres lagvis.
XML ressursfilen app_bar_navigation_drawer.xml definerer posisjonen til fragmentinnholder og
ActionButton. I den filen inkluderes en ressursfil for programlinjen (toolbar_layout.xml). I
programlinjen kan sidetittelen på det fragmentet som er valgt vises. Faner og andre funksjoner som
kan være nyttig kan defineres her og derfor har den fått en egen ressursfil.
XML-filen til Navigation Drawer (activity_navigation_drawer.xml) defineres med modulen som støtter
navigering (NavigationView). I samme fil inkluderers app_bar_navigation_drawer.xml-filen som da
plasseres bak NavigationView
Når bruker velger fra menyen vil innholdet i det fragmentet som representerer menyvalget erstatte
det fragmentinnholdet som bruker var i.
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 29(38) 01.06.16
5 Testing
5.1 Brukstest Ved brukstest er det opprettet en ny bruker, og denne er logget inn.
Inlogget bruker
Etter innlogging er alle menyvalg testet.
Innstillinger, Kontakter og Meldinger er ikke implementert i applikasjonen så disse valgene gjør
ingenting.
Profil viser informasjon om pålogget bruker
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 30(38) 01.06.16
Logg side og informasjon om utført tjeneste
Det ble så testet å bestille en ny tjeneste.
Bestilling av tjeneste
Her ble og informasjon om tilbyder testet.
Tilbyder informasjon
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 31(38) 01.06.16
5.2 Feiltesting Etter brukstest med korrekt informasjon ble det prøvd ut forskjellige metoder å få applikasjonen til å
slutte å fungere.
Det var ønskelig å teste med en null/null bruker ved innlogging, men det eksisterer en kunde i
databasen med null verdier for navn/etternavn som forhindrer dette.
Ved innlogging av en bruker der det eksisterer flere med samme navn/etternavn vil den logge inn den
første brukeren (sortert etter CustomerID), men årsaken for det er at det måtte opprettes en
midlertidig metode for innlogging som må ferdigstilles før applikasjonen tas i bruk.
Ved bestilling av en tjeneste, dersom det fylles med ut null-verdier - vil applikasjonen slutte å virke.
Dette må endres ved videreutvikling av applikasjonen.
Hardfeil
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 32(38) 01.06.16
6 Evaluering
6.1 Utføring
6.1.1 Utforming av eventuelle løsninger
I denne fasen ble det lagt mye fokus på å bli kjent med oppbyggingen av databasen og hvordan
datafelter og variabler er plassert i forhold til hverandre. Kjennskap og kunnskapsnivået til databasen
og funksjonsområder i databaser generelt var ulikt for gruppemedlemmene og mye forstudie og
innhenting av informasjon måtte til. Denne kunnskapen var viktig å ha med seg videre til
programmeringen av selve applikasjonen opp mot databasen.
Visual Studio og Microsoft SQL Server for å simulere databasen lokalt da serveren ikke var operativ
enda. Databasen var ikke ferdig i denne prosessen og manglet et par funksjoner. Her ifra ble det tenkt
ut muligheter for å hoste serveren ved hjelp av «Port Forwarding» og «NAT-ting». Dette gjør det mulig
for at andre personer utenfor det lokale nettverket kan koble seg opp mot serveren. Dette ble ikke
iverksatt fordi alle på gruppen hadde tilgang til serveren lokalt på sin egen datamaskin. På grunn av at
databasen kun fantes lokalt på datamaskinen oppstod det vanskeligheter for å teste
oppkoblingsfunksjoner via mobilapplikasjoner. Det ble prøvd ut å kjøre databasen på en egen port i
datamaskinen som mobile enheter kunne kobles mot, men for at dette skulle fungere måtte man ha
egne sikkerhet sertifikater for oppkobling, noe som ikke var lagt inn i databasen enda.
En egen database for å behandle personvern og datasikkerhet er planlagt å benyttes for innlogging av
brukere. Denne ble det gitt beskjed om at ikke ville bli tilgjengelig i løpet av oppgavetiden, og det ble
jobbet rundt dette.
Gruppen brukte flytdiagram og pseudokoder som utgangspunkt for utforming av applikasjonen og for
å teste virkemåter og funksjonsmuligheter ble monitorapplikasjonen utviklet. Å utvikle denne
applikasjonen har vært lærerikt og nødvendig. Utviklingen av sluttproduktet bygger derfor mye på
oppsettet og metodebruken i monitorapplikasjonen.
6.1.2 Generell utføring og hendelser underveis
9. mars ble serveren operativ på Azure, men med mangler på hvilke APIer som var fungerende. Et par
test variabler ble så lagt inn i databasen. Det ble brukt mye tid på å teste kode før det ble funnet ut at
det var API som ikke fungerte.
13. mars ble API-ene oppdatert. Det ble da lagt ned mye fokus på oppkobling mot serveren. Gruppen
kom fram til at en av de beste bibliotekene i Android for oppkobling mot Web-API var Retrofit. Dette
biblioteket var ukjent for hele gruppen og det gikk mye tid på å studere og innhente informasjon om
dette. Det ble prøvd ut flere forskjellige måter å koble seg opp server i selve koden. Som et resultat av
disse prøvene ble monitorapplikasjon brukt for testing av tilgjengelige funksjoner på serveren.
21. mars var alle API-ene fungerende. Denne oppdateringen inkluderte mulighet for å oppdatere og
slette objekter i databasen. Det ble da utviklet flere funksjoner i monitorappen. Dette utgjorde mange
sider med koding og var en krevende prosess der prøving og feiling måtte til for å få funksjoner til å
fungere. Mye tid ble også brukt på å opprette og oppdatere objekter i databasen uten hell grunnet
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 33(38) 01.06.16
restriksjoner og endringer fra databasesiden. Endringene resulterte i at DELETE og PUT funksjoner ikke
fungerte helt skikkelig fra server siden. Dette ble meldt ifra til oppdragsgiver 1. april.
14. april ble det gjort et par endringer i serveren for at PUT og DELETE funksjoner skulle fungere. Dette
fungerte lokalt på datamaskinen til oppdragsgiver, med var ikke tilgjengelig for oppkobling til API mot
Azure. Tidligere fungerende POST og PUT funksjoner fungerte ikke nå lenger. Mye forvirring, prøving
og feiling i koden måtte til for å finne ut at det var en feil på server siden som vi ikke kunne gjøre noe
med. Dette ble meldt ifra til oppdragsgiver 18. april.
19. april ble gruppen informert at feilen i databasen ikke ville være i orden før etter 10. mai. Det ble
derfor bestemt å fokusere videre på designdelen av det ferdige grensesnittet.
Til midtveispresentasjonen (15. April) var monitorapplikasjon med kode for alle funksjonene ferdig.
Noen av disse funksjonene fungerte ikke på grunn av serveren, men var altså klar for bruk.
22. mai hadde feilen i serveren blitt rettet opp igjen. POST funksjoner fungerte igjen som vanlig, men
PUT og DELETE funksjoner fungerte enda ikke. Det ferdige grensesnittet var for lengst påbegynt og
dette har blitt tatt hensyn til i den ferdige versjonen av applikasjonen.
25. mai var den siste versjonen av det ferdige grensesnittet ferdig. Denne applikasjonen inneholder
alle funksjoner i forhold til kravspesifikasjonen og har mulighet for videreutvikling. Arbeidet om å
fullføre rapporten ble deretter påbegynt.
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 34(38) 01.06.16
6.2 Konklusjon og ettertanker Applikasjonen er per i dag ikke et ferdig produkt da det er flere mangler som må utbedres.
Serveren er fortsatt ikke operativ med funksjoner som er nødvendige. Dette setter begrensninger i
applikasjonens funksjonalitet og fullstendig testing lar seg derfor ikke utføres. Aktiviteten for
innlogging er avhengig av en fungerende server som er utarbeidet for å håndtere sikker innlogging og
ivareta personvern. Løsningen som er opprettet i applikasjonen i dag er derfor ikke som ønsket
ettersom databasen ikke inneholder nødvendige felter og variabler for brukernavn og passord.
Rating av tjenester er ikke opprettet ettersom serveren ikke har støtte for dette heller. Andre felter i
databasen som har satt begrensninger i utviklingen er felter for kommentering og kommunikasjon
mellom tilbyder og bruker. For å ferdigstille applikasjonen må sikkerhet og personvern ivaretas og
prioriteres fra databasesiden i første omgang. En slik applikasjon bør ha sikker autentisering ved hjelp
av token. Server bør i tillegg støtte kryptert overføring av informasjon(HTTPS)
Videreutvikling av applikasjonen forutsetter noe kjennskap til Retrofit-biblioteket da applikasjonen er
bygget rundt dette. Brukergrensesnittet er bygget opp for å enkelt kunne videreutvikles enten ved å
erstatte eller legge til/fjerne tjenester og aktiviteter. Applikasjonens innhold styres primært av
databasens innhold og er derfor utviklet for å hente dataen fra databasen og ikke lagret lokalt i
applikasjonen.
For å gi en fullstendig brukeropplevelse anbefales det å implementere støtte for Google Mapsxxi og
chatte-tjenester for å gi bruker og tilbyder mulighet å kommunisere ut over bestillingsaktiviteten. Det
anbefales også å gi bruker mulighet å registrere inn behov og la tilbyder registrere sin ledige tid på
grunnlag av behov som dukker opp. Betalingstjeneste for kommersielt bruk kan utvikles da
databasen allerede inkluderer felter for prising.
Dersom applikasjonen blir ferdigstilt og inkluderer god sikkerhet vil det ferdige programmet være et
nyttig produkt for tenkt brukergruppe. For å ta i bruk alle funksjoner og samtidig oppfylle brukerens
behov for tjenester må kravspesifikasjoner utformes og inkludere krav for personvern, bruk av
applikasjonen og overføring av data.
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 35(38) 01.06.16
Appendiks A Forkortelser og ordforklaringer
API Application Program Interface
GUI Graphical User Interface
JSON JavaScript Object Notation
NAT Network Address Translation
POJO Plain Old Java Object
URL Uniform Resource Locator
XML Extensible Markup Language
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 36(38) 01.06.16
Appendiks B Prosjektledelse og styring
B.1 Prosjektorganisasjon Gruppeleder – Marita Furnes
Dokumentansvarlig – Marius Aasbak
Kodeansvarlige – Kristoffer Rye & Sondre Svendsen
B.2 Fremdriftsplan
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 37(38) 01.06.16
Appendiks C Kildekode Vedlagt ligger Frisats.zip
Monitoreringsapplikasjon.zip
FriSats – Kommunikasjon med Web-API for Android-enheter
Rev: v1.0 38(38) 01.06.16
Appendiks D Litteraturliste
https://developer.android.com/guide/index.html
i http://www.asp.net ii https://www.google.com/design/spec/patterns/navigation-drawer.html iii https://lovdata.no/dokument/NL/lov/2000-04-14-31 iv https://msdn.microsoft.com/en-us/library/Aa374909.aspx v http://www.asp.net/web-api/overview/security/individual-accounts-in-web-api vi https://developer.android.com/reference/android/os/AsyncTask.html vii https://developer.android.com/reference/java/net/HttpURLConnection.html viii https://developer.android.com/training/volley/index.html ix https://www.google.com/intl/en/about/ x http://square.github.io/okhttp/ xi http://square.github.io/retrofit/ xii http://square.github.io/ xiii https://developer.android.com/studio/intro/index.html xiv https://eclipse.org/ xv https://git-scm.com/ xvi https://www.visualstudio.com/ xvii https://www.microsoft.com/en/server-cloud/products/sql-server-2016/ xviii https://github.com/ xix http://gradle.org/ xx http://www.androidwarriors.com/2015/08/retrofit-android-example-web-services.html xxi https://www.google.com/maps https://en.wikipedia.org/wiki/JSON