FriSats Kommunikasjon med Web-API for Android-enheter...

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

mailto:[email protected]

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.


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.


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


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


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.


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.


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.


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.


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


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


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


Rev: v1.0 13(38) 01.06.16

Automatisk konvertering til POJO

God dokumentasjon

- Mindre tilpasningsmuligheter enn Volley


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.


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


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.


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

http://www.jsonschema2pojo.org/


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

http://frisats3.azurewebsites.net/

http://frisats3.azurewebsites.net/api/customers/

http://frisats3.azurewebsites.net/api/customers

http://frisats3.azurewebsites.net/api/groups

http://frisats3.azurewebsites.net/api/orders

http://frisats3.azurewebsites.net/api/providers

http://frisats3.azurewebsites.net/api/orders


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);


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.


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...");}


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.


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


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.


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.


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


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


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


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.


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


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


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


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


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.


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.


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


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


Rev: v1.0 37(38) 01.06.16

Appendiks C Kildekode Vedlagt ligger Frisats.zip

Monitoreringsapplikasjon.zip


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

https://developer.android.com/guide/index.html

http://www.asp.net/

https://www.google.com/design/spec/patterns/navigation-drawer.html

https://lovdata.no/dokument/NL/lov/2000-04-14-31

https://msdn.microsoft.com/en-us/library/Aa374909.aspx

http://www.asp.net/web-api/overview/security/individual-accounts-in-web-api

https://developer.android.com/reference/android/os/AsyncTask.html

https://developer.android.com/reference/java/net/HttpURLConnection.html

https://developer.android.com/training/volley/index.html

https://www.google.com/intl/en/about/

http://square.github.io/okhttp/

http://square.github.io/retrofit/

http://square.github.io/

https://developer.android.com/studio/intro/index.html

https://eclipse.org/

https://git-scm.com/

https://www.visualstudio.com/

https://www.microsoft.com/en/server-cloud/products/sql-server-2016/

https://github.com/

http://gradle.org/

http://www.androidwarriors.com/2015/08/retrofit-android-example-web-services.html

https://www.google.com/maps

https://en.wikipedia.org/wiki/JSON

FriSats Kommunikasjon med Web-API for Android-enheter...

Documents

Transcript of FriSats Kommunikasjon med Web-API for Android-enheter...