Applikation för Android i ett klient/server system : Utveckling av en mobilapplikation med syfte att tjäna som en plattform för försäljning av varor och tjänster

(1)

Datateknik C, Examensarbete, 15 högskolepoäng

A

PPLIKATION

FÖR

A

NDROID

I

ETT

KLIENT

/

SERVER

SYSTEM

Utveckling av en mobilapplikation med syfte att tjäna som en plattform för

försäljning av varor och tjänster

Markus Kjellrup Dataingenjörsprogrammet, 180 högskolepoäng Örebro vårterminen 2016 Examinator: Martin Magnusson

CURRENT & ABLE

Örebro universitet Örebro University

Institutionen för naturvetenskap och teknik School of Science and Technology 701 82 Örebro SE-701 82 Örebro, Sweden

(2)

Sammanfattning

Denna rapport beskriver utvecklandet av en applikation till operativsystemet Android. Här sätts utvecklingen av applikationen i förhållande till god användbarhet och hantering av resurser på en mindre plattform. En server med tillhörande databas kommunicerar med applikationen som klient. De båda utgör tillsammans helheten i ett system designat för ett bokningsbolag verksamt i Sverige som önskar presentera sitt utbud av exklusiva varor och tjänster direkt till fans av bolagets artister. I projektet avhandlas grundläggande klasser och komponenter för utveckling av applikationer till Android och hur de bäst samverkar för att optimera användandet av resurser. Java användes huvudsakligen som programmeringsspråk. På serversidan utvecklades ett gränssnitt i PHP mot en MySQL databashanterare.

Abstract

This study describes the development of an application for the operating system Android. We consider the developing of the application in relation to a good user experience and the managing of resources on a smaller device. A server with an appurtenant database communicates with the application as a client. Together they constitute a unity in a system designed to serve a managing and booking music agency in Sweden who whishes to offer their supply of goods and services to the fans of their related artists. In this project we deal with basic classes and components regarding development of Android applications and how they interact to achieve the best possible performance when using system resources. Java was the main programming language used. On the server side we developed a graphical user interface in PHP, targeting a MySQL database management system.

‘

(3)

Förord

Jag skulle vilja tacka min handledare Lars Karlsson på Örebro Universitet som har hjälpt mig att skriva denna rapport. Jag vill även tacka organisationen Udacity vars utförliga kurser på ett pedagogiskt och metodiskt sätt förklarat standardmetoder avseende programmering för Android.

Innehållsförteckning

(4)

1 Inledning ………... 1.1 Bakgrund ………... 1.2 Projekt ………... 1.3 Syfte ………... 1.4 Krav ………...

5 5 5 5 5 2 Metoder och Verktyg ……….... 2.1 Visuell och arkitekturell design ....……….... 2.1.1 Användarcentrerad design ………... 2.1.2 Mobilapplikationens struktur ..……….... 2.2 Programmeringsspråk ……….... 2.3 Android och dess fundamentala delar ………... 2.3.1 Activities, Fragments och Intents ...………. 2.3.2 Content Providers, Loaders och Syncadapters ……….... 2.3.3 Resources ………. 2.3.4 Layouts ……….... 2.3.5 Drawables ……….... 2.4 Verktyg ………... 2.5 Projektets övriga resurser ………..

7 7 7 7 8 8 8 9 10 10 11 11 11 3 Genomförande ……….. 3.1 Initial design och framtagning av prototyp ………... 3.2 Navigering ..………... 3.2.1 Struktur med tillhörande activities ...……….. 3.2.2 Fragments ...……….... 3.2.3 Intents ………. 3.3 Resources ……….. 3.4 Serverns databas med tillhörande gränssnitt ..………... 3.4.1 ER modell ………... 3.4.2 Databasens gränssnitt ..………... 3.4.3 REST i kombination med JSON ..……….. 3.5 Synkronisering, lagring och uppdatering av data ……….. 3.5.1 Responsiv användarupplevelse ……….. 3.5.2 Content Providers ………... 3.5.3 Loaders ………... 3.5.4 Synkronisering med server ………. 3.6 Användaruppgifter ………... 3.7 Fortlöpande återkoppling samt test av gränssnitt och funktion ………. 3.8 Betalningsmodell ………... 3.8.1 Swish ……….. 3.8.2 Integrerad modell ………... 3.8.3 Mobila betaltjänster ……….... 12 12 12 12 14 14 14 15 15 16 17 18 18 18 19 19 21 22 23 23 24 24 4 Resultat ………. 4.1 Serverns gränssnitt ……….... 4.2 Mobilapplikationens gränssnitt ………. 4.2.1 Startvy ……….... 4.2.2 Produktvy ………... 25 25 26 26 27

(5)

4.2.3 Detaljvy ……….. 4.2.4 Användaruppgifter ………. 4.2.5 Bekräfta order ……….

27 27 27 5 Diskussion ……….... 5.1 Uppfyllande av projektets krav ………. 5.2 Speciella resultat och slutsatser ………. 5.3 Projektets utvecklingspotential ………. 5.4 Reflektion kring eget lärande ……….... 5.4.1 Kunskap och förståelse ……….. 5.4.2 Färdighet och förmåga ………... 5.4.3 Värderingsförmåga och förhållningssätt ………....

28 28 29 29 29 29 29 29 6 Referenser ………...

31 Bilaga A: Gränssnitt mot Mobiltelefon Bilaga B: Master Detail Navigation Flow Bilaga C: Gränssnitt mot Serverns Databas

(6)

1 Inledning

1.1 Bakgrund

Current & Able är ett bokningsföretag inom musikbranschen. Man hanterade i skrivande stund en handfull artister. Bokning av artister fungerade tillfredsställande. Däremot fanns en önskan om att kunna erbjuda ett enkelt och lättillgängligt sätt för intressenter att köpa exklusiva produkter direkt av företaget. Exempel på sådana kunde vara exklusiva spelningar, exklusiva album i samband med release event, övrig merchandise etc. En applikation till mobiltelefoner ansågs kunna lösa det problemet.

1.2 Projekt

Projektet bestod av att utveckla ett system där användare kunde köpa produkter med hjälp av sina mobiltelefoner, eller andra handhållna enheter, med Android operativsystem. Systemet skulle bestå av an klient i form av en Android applikation utvecklad i programspråket Java för Android. Denna klient skulle kunna kommunicera via internet med en server innehållandes en databas med företagets produkter. Under arbetets gång uppkom ett behov av ett egenutvecklat gränssnitt mot databasen. Dock har tyngdpunkten hela tiden legat på den mobila applikationen och dess kommunikation med servern.

1.3 Syfte

Syftet med projektet var att kunna förenkla en tjänst som tidigare erbjudits på ett mindre systematiserat sätt. Önskvärt skulle den fungera i kommersiellt syfte. De slutgiltiga användarna av applikationen var speciellt fans av bolagets artister som skulle kunna erbjudas en plattform för utbudet av bolagets produkter. Men bolaget själva skulle också använda systemet i avseendet att hantera databasen och få besked om beställningar.

1.4 Krav

Nedan utsatta krav på projektet formulerades på eget initiativ. Kraven har dock diskuterats med företaget. Sammanfattningsvis ska projektet uppfylla en enkel applikation för Android innehållandes varor och tjänster. Användbarhetsmål: ● Enkel att förstå ● Effektiv, dvs underlätta för användaren att utföra sina ärenden ● Förhållandevis snabb rent tekniskt ● Felsäker ● Fungera tillfredsställande på handhållna mobiltelefoner med Androids operativsystem

(7)

Upplevelsemål: ● Ett trevligt och inbjudande grafiskt gränssnitt som relaterar till företagtes redan fastslagna profil ● Ge ett seriöst intryck Klienten skulle kunna: ● Välja en artist ● Se ett utbud av produkter som fanns tillgängliga för aktuell artist ● Se detaljerad information för vald produkt ● Köpa en produkt genom att bekräfta köp i applikationen ● Få information om hur denne skulle betala för produkten. Användaren skulle inte kunna genomföra en ekonomisk transaktion integrerat i appen. Det skulle lösas genom befintliga medel utomstående applikationen. Därutöver skulle systemet hantera: ● Upprättande av databas på server innehållandes det tilltänkta utbudet ● Hämtning av aktuella varor och tjänster till applikation från databas på server ● Modifiering av databas vid köp Rapporten hade därutöver som krav att översiktligt undersöka och beskriva existerande mobila betalningsmetoder. Önskemål utifall tid fanns: ● Införa ett sätt att registrera användaruppgifter och logga in med dessa ● Enkelt gränssnitt för administratör att hantera databasen

(8)

2 Metoder och verktyg

2.1 Visuell och arkitekturell design

Det är mycket lättare att rekonstruera och ändra på ett system i designfasen snarare än när systemet är implementerat [1, s 37]. Fokus lades i huvudsak på programmering i detta projekt. En utgångspunkt togs dock ur några grundläggande principer vad gäller interaktionsdesign.

2.1.1 Användarcentrerad design

Centralt vid skapande av informationssystem är användarens upplevelse av systemet. Man kan dela in det i användbarhetsmål och upplevelsemål. Dessa kan dock gå in i varandra. Vad gäller användbarhet så kollar man bla på effektivitet, säkerhet, inlärningskurva och komplexitet [1, s 1219]. Upplevelsemål kan vara mer subjektiva än användbarhetsmål [1, s 23]. Det handlar om att framkalla positiva känslor vid användning av systemet/produkten. Som beskrivet under kapitel 1.4 hade projektet följande krav gällandes design: Användbarhetsmål: ● Enkel att förstå ● Effektiv, dvs underlätta för användaren att utföra sina ärenden ● Förhållandevis snabb rent tekniskt ● Felsäker ● Fungera tillfredsställande på handhållna mobiltelefoner med Androids operativsystem Upplevelsemål: ● Ett trevligt och inbjudande grafiskt gränssnitt som relaterar till företagtes redan fastslagna profil ● Ge ett seriöst intryck I en användarcentrerad design är det är viktigt att förstå varför man skapar en produkt och för vem. I detta projekt var syftet att skapa en lättillgänglig plattform för försäljning av specifika varor och tjänster. Dessa produkter var förhållandevis homogena i relation till varandra. Dvs utbudet av produkter höll sig inom ett relativt smalt område. Det var varor och tjänster kopplade till varsin specifik artist. Applikationen riktar sig till en målgrupp bestående av fans av artisterna.

2.1.2 Mobilapplikationens struktur

Det finns olika sätt att bygga strukturen på. I en artikel på uxbooth.com, skriven av Elaine McVicar 2012, skiljer sig förväntningarna i användandet av mobila enheter med små skärmar, såsom mobiltelefoner, från större datorer. Man förväntar sig ofta enklare och mindre strukturer. McVicar presenterar sex populära modeller för byggandet av struktur i mobila enheter. Alla med sina för respektive nackdelar:

(9)

Hierarchy ; Navigation sker enligt en hierarkisk modell. Bra vid komplicerade och större strukturer. Svårare att implementera på mindre skärmar. Hub & spoke ; Utgår från en första sida som länkar utåt. Användaren måste gå tillbaka till första sidan för att navigera runt hela tiden. Bra för att presentera applikationer med många spridda funktioner. Nested doll ; En nästlad modell där användaren går antingen fram eller tillbaka. Bra för applikationer med enstaka eller nära besläktade ämnen. Tabbed view ; Ger en översiktlig bild av vilka flikar användaren kan välja genom att presentera sk tabs . Användaren kan hoppa mellan vyerna genom att klicka på den tab som denne önskar. Bra för översiktliga strukturer med nära besläktade ämnen. Bento Box/Dashboard ; Liknar Hub & spoke men är tänkt att användas på en större skärm som kan presentera ett större utbud av valmöjligheter. Filtered view ; Tänkt till större skärmar för att presentera en lista av val tillsammans med en detaljerad beskrivning av varje val på en och samma skärm. [2]

2.2 Programmeringsspråk

I arbetets början planerades att använda framförallt Java för Androidapplikationen. Angående serversidan var PHP det tänkta språket tillsammans med MySQL databashanterare. Java är huvudsakligen det programmeringsspråk som används vid utveckling av applikationer till Android [3]. Dessutom hade jag viss förkunskap i Java så det valet var självklart. PHP går under Open Source License [4] och var vid skrivande stund det mest använda språket för serverprogrammering världen över [5]. Företaget hade redan en serverlösning som använde sig av PHP med MySQL. Detta tillsammans motiverade valet av den lösningen.

2.3 Android och dess fundamentala delar

Android är ett operativsystem designat för att hantera mindre enheter med mindre minne och utrymme än en persondator. Android baseras på en linuxkärna men har för övrigt inte så mycket mer gemensamt med en vanligt förekommande linuxdistribution till persondatorer[6]. Android har fyra essentiella komponenter som tillsammans utgör grundbulterna i systemet. Dessa är Activities , Services , Content Providers och Broadcast Recievers [7]. I detta projekt behandlas alla delar förutom broadcast recievers , som inte varit aktuellt att implementera.

2.3.1 Activities, Fragments och Intents

Activities kan liknas vid fönster mot användaren. Varje applikation består av ett antal activities som alla har sin egen livscykel. När användaren först öppnar en applikation öppnar denne också en speciell activity , en sk launcher activity . Denna activity har programmerats till att vara den activity som startar applikationen. Detta bestäms i manifestet. Från denna activity kan användaren navigera sig till andra activities inom den aktuella applikationen. En activity har en livscykel med olika systemmetoder som anropas vid början och slut, visualiserad i figur 1 [8]. Dessa sk callback methods använder man sig med fördel av för att

(10)

utföra grundläggande moment vid valda tillfällen. Till en början vill man ofta initiera fragments , länka till xmlfiler innehållandes information om layouten mm. Vid avslutande av en activity vill man ofta spara aktuell status för att kunna återvända senare till samma tillstånd man lämnade i. Android introducerade fragments tillsammans med lanseringen av Android 3.0 (API 11). Den främsta fördelen med fragments är att man kan hantera olika skärmstorlekar på ett bättre sätt. Ett fragment är som ett inre lager av en activity och kan läggas till antingen dynamiskt från en activity eller statiskt i tillhörande layoutfil. [9] Ett fragment har precis som en activity en livscykel, om än något mer komplicerad. Den har samma systemmetoder som en activity med tillägg för några fler. Eftersom en fragment är en view har den en systemmetod, OnCreateview() , som anropas så fort fragmentet blir synlig visuellt. Här initieras med fördel variabler, adapters, listor mm. [9] Android använder sig av sk intents för att kommunicera mellan de olika centrala komponenterna. Den enda centrala komponenten som inte använder intents är content providers . Intents kan ses som ett objekt innehållandes syftet med transaktionen. Det finns explicita och implicita intents . Explicita intents används när man vill specificera exakt vilken komponent som ska aktiveras, ofta inom den egna applikationen. Implicita intents används när man vet vad man vill utföra men där man lämnar det år systemet att erbjuda alternativ för mottagandet. Detta används med fördel för kommunikation appar emellan. [10] Figur 1: Livscykel hos en activity. Diagrammet är baserat på [8].

2.3.2 Content Providers, Loaders och Syncadapters

Rekommenderat i samband med ej omedelbar nätverkskommunikation från en androidapplikation är att använda syncadapters . Dessa gör det möjligt att synkronisera nätverksuppkopplingar och därmed optimera användandet av systemets resurser. Dessutom kan man med fördel mellanlagra data lokalt i sin enhet. Detta underlättar åtkomst till data även i situationer utan nätverkstäckning samt borgar för en bättre användarupplevelse genom snabb uppdatering av gränssnittet. Loaders implementeras i en activity eller i ett fragment och hanterar automatiskt kommunikation med den lokala databasen. En content provider är navet

(11)

i detta system och fungerar som en abstraktion mellan lokalt lagrad data och aktörer som på något sätt antingen önskar lagra eller hämta data. Content providers , loaders och syncadapters gås igenom grundligare i kapitel 3.5.2 3.5.4.

2.3.3 Resources

En applikation byggs upp av i huvudsak Javaklasser. Android använder sig dock av sk resources för delar i applikationen som inte definieras av programmeringskod. Sådana resurser är bla bilder, ikoner, texter, menyer, färger, stilar och de centrala sk layouts . Genom att lagra gemensamma resurser på detta sätt kan referera till dem var som helst i koden. Det är rekommenderat att inte hårkoda texter i programmeringskoden, utan att skriva alla texter i en speciell fil där de lätt kan ändras vid behov. Denna fil blir en resource . Dessutom öppnar det för integrering av olika språk i applikationen. Det går att införa en textfil för varje språk som man väljer att implementera. Systemet kan då automatiskt välja den fil med texter som motsvaras av det inställda språkvalet i enheten.

2.3.4 Layouts

En viktig och central del av ovan nämnda resources är layouts . Det är xmlfiler som innehåller information om hur det grafiska gränssnittet ska se ut. Det går att definiera det grafiska gränssnittet enbart i Java, men det rekommenderas att separera innehållet från layouten i dessa xml filer [11]. Android använder sig av en hierarki bestående av views och viewgroups för att skapa en layout (se figur 2). En viewgroup är en underklass till view . Däremot innehåller, i modellen för gränssnittshierarkin, en viewgroup en eller flera views . En viewgroup är med andra ord ett sätt att organisera innehållet. Figur 2: Förhållandet mellan views och viewgroups

(12)

2.3.5 Drawables

Bildfiler, lagras i form av drawables , kan hanteras på olika sätt. Antingen kan man spara bilder som tillgångar i det statiska minnet. Då ges möjligheten att spara bilder i olika format under samma namn och skilda mappar. Det gör det möjligt för Android att välja den bild som passar aktuell skärmstorlek bäst. Ett annat sätt att hantera bilder är att använda ett tredje parts bibliotek. Det finns olika bibliotek för att hantera bilder som var och en passar bäst i olika sammanhang. I detta projekt används biblioteket Glide . Bilden laddas ned på kommando från servern via den sökväg som sparats i databasen. Glide cachar bilden i minnet och borgar således för en snabb uppladdning till gränssnittet samt en dynamisk hantering av minnet. Det går också att hantera nedladdning av bilder manuellt med egendefinierade javaklasser.

2.4 Verktyg

Android Studio användes som utvecklingsmiljö för androidapplikationen. Android Studio föregicks av Eclipse men lanserades 2015 som Googles egna alternativ. I Android Studio, som är fritt att ladda ned från internet, finns stöd för hantering av projekt, editering av kod, rendering av grafik, interaktion med diverse systemprocesser och mycket mer. När det gällde serversidan användes Notepad++ för att skriva PHP script. Angående serverlösningen var det enklaste och mest praktiska alternativet att installera en lokal server på en windows baserad dator. Tidigare erfarenhet av wamp server fanns. Wamp är en nedladdningsbar helhetslösning för PHPscript, MySQL databas och Apache webserver. Därav valdes därför den konstellationen. Detta var dock bara en lösning under merparten av utvecklingen. I slutskedet av projektet användes en webserver istället för en lokal server. På denna webserver ligger också den färdiga databasen med tillhörande PHPscript. Till en början, och mestadels under utvecklingen, användes en extern handhållen enhet (mobiltelefon) att testa applikationen i. När man arbetar mot en webserver kan en handhållen enhet, såsom en mobiltelefon, kommunicera med servern via internet. När en lokal server används, som alltså installerats på en dator som ej kan nås via internet, uppstår problemet hur man når servern från en annan enhet än själva datorn. En lösning är att använda ett eventuellt lokalt nätverk som både den handhållna enheten och datorn är uppkopplade mot. Den lösningen passade detta projekt. Dock uppstod problem då den lokala servern inte var inställd på att ta emot anrop från annat än den dator den var installerad på. För att lösa det gick jag in i serverns konfigureringsfil httpd.conf. Den filen innehåller flertalet direktiv för hur servern ska fungera. Under tagen <Directory> ändrade jag värdet på parametern från Require local till Require all granted. På så sätt får man servern att godkänna anrop även från utomstående enheter, såsom i detta fallet en mobiltelefon i det lokala nätverket. Javadoc har använts för att dokumentera koden under utvecklingen på ett standardiserat sätt.

2.5 Projektets övriga resurser

Mot slutet av projektet erhölls tillgång till företagets server med tillhörande databas.

(13)

3 Genomförande

3.1 Initial design och framtagning av prototyp

Projektet startades med att gå igenom de krav som ställts upp på systemet. Se kapitel 1.4. Enligt Sharp, Preece och Rogers [1] är nästa steg, efter att krav specificerats, att ta fram en prototyp. En prototyp kan vara flera olika saker, allt från avancerad mjukvara till pappersbaserade skisser [1, s 386]. Jag valde att börja med att skissa upp det grafiska gränssnittet på papper där de olika vyerna presenterades. Att använda sig av penna och papper för att simulera ett systems funktionalitet faller inom kategorin lowfidelity prototyping [1 s389] . På detta sätt kan man snabbt och enkelt ta fram prototyper för att utforska idéer och lösningar på problem [1, s 389]. Enligt denna modell tog jag först fram skisser föreställandes en genomsnittlig mobiltelefons (vilket var den primärt tänkta enheten att utveckla till) vyer och navigering dem emellan. Dessa skisser fungerade sedan som underlag i den initiala programmeringen. Huvudsyftet med mobilapplikationen var att presentera ett utbud av varor och tjänster samt ge detaljerad information om dessa så att användaren kunde beställa en produkt. De första vyerna som implementerades var därför listan med företagets utbud samt navigeringen till den vy som skulle presentera detaljerad information om vald produkt. Mobiltelefoner har vanligtvis små skärmar jämfört med laptops och stationära datorer. Det gäller därför att noggrant planera användandet av gränssnittet [1, s193]. Med detta i åtanke valdes en modell där varje vy motsvarade en funktion i systemets flöde; scrollbara listor för att presentera artister och produkter, samt stora och tydliga klickbara avdelningar för varje handling som skulle kunna utföras. Vid möte med företaget visades sedan dessa skisser upp tillsammans med de två vyerna som dittills hade implementerats. Representant från företaget fick ge feedback som sedan togs med i det fortsatta arbetet med applikationen. Överlag var företaget nöjda med det tänkta upplägget.

3.2 Navigering

3.2.1 Struktur med tillhörande activities

Som beskrivet i 2.1.2 fanns olika modeller att välja mellan för att bygga en struktur. Detta projekt skulle presentera ett antal artister tillsammans med deras relaterade produkter samt detaljerad information om dessa produkter. Därutöver även ett sätt att lägga en order på vald produkt. Applikationens olika delar hade tillsammans endast ett slutmål; att göra det möjligt för användaren att beställa en produkt. Valet av modell för struktur föll således på en nästlad sådan, beskrivet i 2.1.2 som Nested doll . Ett alternativ hade varit Tabbed view. Denna modell föll dock snabbt bort eftersom användaren inte skulle kunna hoppa mellan tex betalning och listan av artister. Tanken var att användaren skulle komma närmre slutmålet steg för steg. En beställning kan ej ske utan att en produkt först har valts. Se figur 3 för en illustration över applikationens struktur byggd på Nested doll . Vid presentation av listan innehållandes produkter och dess detaljerade information för större skärmar (läs tablets) passade modellen

(14)

Filtered view . Google kallar denna modell för Multi pane/Two pane layout [13]. Jag valde denna modell specifikt för presentation av företagets produkter tillsammans med den detaljerade informationen om varje produkt vid design för större skärmar. Fem olika activities implementerades. Alla är ansvariga för en speciell del i applikationens flöde. Rapporten går in mer i detalj ang utseende och funktion i kapitel 4. Här beskrivs koncentrerat de tekniska detaljerna. För att förtydliga menas med en activity, i denna rapport, en speciell modul i android os. Applikationens olika vyer motsvarar användarens fönster ur ett visuellt perspektiv. Dock motsvaras en activity alltid av en vy med undantag från MainActivity och DetailActivity som är en vy i läget Two Pane Mode för tablets . Då användaren startar applikationen möts denne av en startvy innehållandes en lista av artister att välja mellan. I listan finns även alternativet “alla artister”. Denna startvy är en activity . Vid start av denna activity laddas de tillhörande xmlfilerna som definierar denna activitys layout. Dessutom laddar den ett fragment . I detta fragment finns en lista som laddas med innehåll från en loader . (Se avsnitt 3.5.3 för mer information om loaders .) När användaren klickar på ett av alternativen tas denne till nästa activity som är en annan lista bestående av utbudet för aktuellt val. Här får användaren välja en produkt i utbudet som denne är intresserad av. När användaren valt en produkt från listan startar en tredje activity som innehåller detaljerad information om produkten. Användaren kan alltid backa till föregående activity närhelst denne önskar. Ifall användaren är intresserad av att beställa aktuell produkt klickar denne sig vidare till nästa activity där användaren kan fylla i sina personuppgifter. Därefter startar den sista activityn där användaren får se en sammanfattning av sin beställning och ges möjlighet att bekräfta ett köp. Tillslut tas användaren tillbaka till startvyn igen. Se figur 3. I fallet med en skärm störren än sex tum exkluderas DetailActivity från navigeringen och ersätts istället med två fragments i MainActivity som nämnt ovan. Se kaptiel 3.2.2 för beskrivning av hantering av större skärmar. Figur 3: Illustration över mobilapplikationens olika activities och navigering dem emellan i enheter med skärmstorlek under sex tum. Navigeringen bygger på den sk Nested doll modellen. Sammanfattningsvis består applikationen av följande activities : ● StartActivity ● MainActivity ● DetailActivity ● PurchaseActivity ● ConfirmationActivity

(15)

3.2.2 Fragments

I Current and Able mobilapplikation kommer användaren att bli presenterad med en lista av aktuellt utbud. När användaren väljer en produkt visas en vy med detaljerad information. Detta kallas ofta för Master Detail Navigation Flow [12]. Så som beskrivet i kapitel 2.3.1 används fragments med fördel vid design för olika skärmstorlekar. På en enhet med en större skärm, tex en sk tablet , kan och bör man, enligt Google, använda utrymmet på ett optimerat sätt där användaren får båda vyer presenterade på samma gång, dvs i samma activity [13]. Därmed uppstår inte långa avstånd i listor som kan vara svåra att följa visuellt. Om användaren har en skärm som är större eller lika med sex tum (i skrivand stund motsvaras detta i flesta fall av en tablet ) adderas i denna applikation automatiskt två fragments i samma activity . Utifall att användaren har en mindre skärm, dvs en mobiltelefon, används två olika activities med varsitt fragment istället. Detta för att höja användarupplevelsen. I detta projekt har stöd för tablets implementerats i form av två fragments under samma vy som presenterar en Master/Detail Navigation Flow. En annan fördel med fragments är att de är återanvändbara. I detta projekt har varje activity ett tillhörande fragment . Undantaget är alltså MainActivity i Two Pane Mode på större skärmar som har två fragments i samma activity .

3.2.3 Intents

Som beskrivet i kapitel 2.3.1 använder Android sig av sk intents för att kommunicera mellan de olika centrala komponenterna. Ett intent bär, just som ordet antyder, syftet med den aktuella förfrågan. I detta projekt användes intents för att starta nästa activity i kedjan av vyer. Med ett intent kan man skicka riktad information som mottagaren tar emot och behandlar. När användaren valt en produkt ur produktvyn skickas produktens id med i det intent som startar detaljvyn. I detaljvyn kan tillhörande fragment använda sig av detta id för att ladda upp produktens uppgifter i syfte att fylla gränssnittet. Intent intent = new Intent(this, DetailActivity.class).setData(productUri); startActivity(intent); Intents användes även i applikationen för att initiera syncadaptern och därmed starta en service som synkroniserar med servern. Se kapitel 3.5.4 för mer information om syncadapters kopplade till en service .

3.3 Resources

Current and Able Mobilapplikation separerar innehåll från utseende i form av xmlfiler under mappen layouts . En speciell xmlfil för hantering av större skärmstorlekar, tablets , skapades för MainActivity . Detta för att hantera Two Pane Mode . För startvyn skapades dessutom en layout för mobiltelefoner i landskapsläge. Detta för att bilderna i listan, vilka sattes till att fylla enhetens bredd i porträttläge, skulle ha passande proportioner även i landsskapsläge. Logotyp, launcher icons samt listikoner lagrades som resources. Det ger en fördel i snabb åtkomst av objekten samt att ingen nätverksuppkoppling heller behövs. För att stödja olika skärmstorlekar och pixeldensiteter lagrades bilderna i flera storlekar under respektive mapp såsom rekommenderat. Då avgör Android själv vilken storlek av bild som passar till den

(16)

aktuella enheten. Detta går bra att göra så när man inte anser sig behöva byta bilder och ikoner fortlöpande. Bilder på artister hämtade från servern laddas upp på gränssnittet med biblioteket Glide . Sökvägen till bilderna laddas ned från serverns databas. Bilderna cachas i minnet och därmed låser inte bilderna statiska resurser. Dessutom är det fritt för företaget att byta bilder när så önskas. Eftersom utbudet av artister i företaget förändras med jämna mellanrum skulle en lösning med bilder lagrade som resources inte vara möjlig här. För att inte ta upp alltför mycket minne visas en rekommendation i gränssnittet mot databasen angående bildernas format och pixelstorlek. Allt för stora bilder skulle kunna innebära att användaren inte finner applikationen värd gentemot de resurser som används av systemet. Övriga resources som utnyttjades i utvecklandet var xmlfiler för menyer, strängar, färger, stilar och standardiserade dimensioner. För syncadaptern implementerades dessutom två speciella xmlfiler enligt praxis.

3.4 Serverns databas med tillhörande gränssnitt

3.4.1 ER Modell

Den grundläggande modellen för strukturen av systemet visas i figur 4. Bolaget har ett antal artister med produkter kopplade till varje artist. Artisterna lagras med namn, beskrivning och en bildlänk till en bild på servern. Produkterna har id, namn, tillhörande artist, kort respektive lång beskrivning, typ, pris, kvantitet, registreringsdatum samt utgångsdatum. Figur 4: ER modell Önskemålen från företaget var en applikation som skulle fungera som en plattform för fans att kunna köpa varor och tjänster kopplade till signade artister. För att skapa en god användarupplevelse, i enlighet med uppställda krav, och hjälpa användaren att sortera bland företagtes artister skapades i mobilapplikationen en klickbar lista av artister. Därav entiteten artist . Detta motiverade även en kort beskrivning av artisten samt en tillhörande bild. När det gällde produkterna var det naturligt att införa ett id som primärnyckel eftersom de till skillnad från artisterna inte nödvändigtvis har unika namn. Det var också tänkt att presentera utbudet i en lista kopplad till mer detaljerad information om varje produkt. Det motiverade en kort beskrivning i listan och en längre beskrivning i detaljvyn. Attributet typ hänvisar till huruvida produkten är en fysisk produkt som går att skicka via post eller om det är en tjänst, tex en exklusiv spelning, som hanteras annorlunda. Pris var självklart liksom kvantitet . Listan som visar utbudet sorterar produkterna efter registreringsdatum så att den nyaste visas överst. I detaljvyn visas hur länge produkten finns tillgänglig. När det datumet passerat visas inte

(17)

längre produkten för användaren i listan av utbudet. Detta gäller även när dess kvantitet gått ner till noll. Det är dock upp till administratören att antingen ta bort inaktuella produkter eller uppdatera relevant attribut. Artistnamnet är en främmande nyckel i produkttabellen. Man kan alltså inte lägga in produkter utan att de tillhör en viss artist. Därmed raderas också alla produkter tillhörande en viss artist ifall artisten tas bort ur databasen. En notering jag gjorde var att defaultinställningen i databashanteraren gjorde det möjligt att bryta referensintegriteten. Med referensintegritet i en databas menas att ett referensattribut i en tabell, dvs ett attribut som refererar till en huvudnyckel i en annan tabell, ska leda till ett existerande attribut [14]. Här var det alltså möjligt att med defaultinställningarna ha produkter som refererade till en ej längre existerande artist. För att lösa detta var jag istället tvungen att definiera databasmotorn som InnoDB för att få det att fungera. [15] Följande

SQLsats löste problemet: $sql = "CREATE TABLE artist ( artistname VARCHAR(70) NOT NULL, description VARCHAR (200) NOT NULL, img VARCHAR(70), PRIMARY KEY(artistname) ) ENGINE=InnoDB;";

3.4.2 Databasens gränssnitt

Tillsammans med MySQL fanns ett standard gränssnitt för hantering av databasen. För att öka användbarheten av systemet implementerades ett eget gränssnitt speciellt avsett för detta projekt. Användaren, i detta fall administratören av databasen, behöver då inte sålla genom överflödig information bland andra databaser. Dessutom uppkom svårigheter med att lagra svenska tecken direkt i det förinstallerade gränssnittet. Lösningen blev att koda om den inkommande textsträngen till UTF8 standard och lagra i databasen. Det var endast möjligt via ett eget gränssnitt. Gränssnittet är skrivet i PHP och omfattar tillgång till CRUD operationer av artister och produkter. Dessutom kan administratören ändra i en tredje tabell som hanterar systemrelaterad information. Denna tabell skapades för att skapa dynamik i systemet. Vissa texter som applikationen visar skulle med fördel kunna modifieras. Exempelvis visas en starttext när användaren startar applikationen. Genom att ändra den i databasen via detta gränssnitt kan företaget uppdatera starttexten med valfritt meddelande. Annan systemrelaterad information som kan modifieras är företagets emailadress, email som skickas till kunden vid avklarat köp, bekräftelse på genomförd/ej genomförd beställning samt betalinformation integrerad i applikationen. Företaget kan alltså ändra och addera betalningssätt efter behov. Gränssnittet är skyddat med användarnamn och lösenord. Detta upprätthålls med sk session variables [16]. Jag valde att använda mig av session variables då de relativt enkelt möjliggör skydd från åtkomst till databasen av en obehörig användare. När man loggat in skapas dessa session variables och upprätthålls tills dess att användaren loggat ut. För att få åtkomst till databasen måste man således ha loggat in med rätt uppgifter. Försök att nå delar av systemet utan behörighet avvisas. Administratören lägger upp bilder kopplade till varje artist när denne skapar artisten i databasen. I databasen lagras en sökväg till bildfilen som lagras på servern i mappen images . Mobilapplikationen synkroniserar med servern enligt förutbestämt mönster. Därav kan situationen uppstå när användaren försöker nå en bild på servern tillhörandes en borttagen

(18)

artist. Detta motiverade att inte ta bort tillhörande bild vid borttagande av artist. Bilden finns kvar på servern tills att administratören manuellt tar bort bilden. Detta görs från gränssnittet. PHP scriptet jämför bilderna på servern med existerande sökvägar i databasen. När en bild påträffas som inte finns i databasen raderas den.

3.4.3 REST i kombination med JSON

Enligt Hameseder Katrin, Fowler Scott och Peterson Anders, i en forskningspublikation från 2011, är det viktigt att hitta effektiva sätt att överföra information mellan server och mobila klienter. Detta speciellt med tanke på mobiltelefoners tekniska begränsningar. I studien testades olika metoder för att kommunicera med en webserver användandes en dedikerad mobilapplikation till iPhone. Man kan använda sig av olika protokoll vid sådan kommunikation. Man jämförde här det äldre protokollet SOAP mot det nyare REST. Man fann att användandet det sk REST protokollet resulterade i den snabbaste och mest effektiva kommunikationen. [17] Vid överföring av data mellan server och klient kan man använda sig av olika standarder för strukturering av information. Man kan se det som en överenskommelse mellan sändare och mottagare som beskriver hur man ska tolka det data som överförs.Två vanliga format är XML, Extensible Markup Language , samt JSON, JavaScript Object Notation . I studien testade man dels mängden data som överfördes, responstid samt tid för serialisering och deserialisering. Sammanfattningsvis rekommenderades JSON i samband med RESTprotokollet vid kommunikation med webserver från mobilapplikation. Denna kombination gav i genomsnitt bäst resultat. [17] Valet föll därmed på RESTprotokollet tillsammans med JSON som metod för att skicka data från servern till klienten. Inkapsling av data i ett standardformat som JSON möjliggör alltså för mottagaren att extrahera data och strukturera enligt avsändarens intention. Metoden json_encode() används i PHP i syfte att formatera ett resultat av en databasfråga till JSONformat. Det gick inte att tillämpa på svenska tecken. Lösningen bestod av att skriva en egen omkodare. För att göra det möjligt att skriva in specialtecken, såsom citationstecken, adderades funktionen addslashes i omkodaren. Omkodaren visas här nedan; $jsonString = " {\"result\":["; $i = 0; while ($row = $result>fetch_assoc()) { $i++; $jsonString .= "{\"productid\":\"" . $row['id'] . "\","; $jsonString .= "\"artistname\":\"" . addslashes($row['artistname']) . "\","; $jsonString .= "\"productname\":\"" . addslashes($row['productname']) . "\","; $jsonString .= "\"shortd\":\"" . addslashes($row['shortd']) . "\","; $jsonString .= "\"longd\":\"" . addslashes( $row['longd']) . "\","; $jsonString .= "\"type\":\"" . $row['type'] . "\","; $jsonString .= "\"price\":\"" . $row['price'] . "\","; $jsonString .= "\"quantity\":\"" . $row['quantity'] . "\","; $jsonString .= "\"date\":\"" . $row['date'] . "\","; $jsonString .= "\"expire\":\"" . $row['expire'] . "\"}"; if ($i < $num_rows) { $jsonString .= ","; } } $jsonString .= "]}";

(19)

3.5 Synkronisering, lagring och uppdatering av data

3.5.1 Responsiv användarupplevelse

Enligt programmerare anställda av organisationen Udacity bör systemet, för att skapa en så bra användarupplevelse som möjligt, uppfylla följande kriterier: [18] 1. En snabb respons oavsett kvaliteten på nätverkstäckningen 2. Ekonomisk hantering av batteriet genom lagring av data lokalt 3. Undvikande av onödiga tidskrävande nätuppkopplingar 4. Sparsam användning av inkommande anrop till servern 5. Ge respons och funktionalitet även i områden utan nätverkstäckning Ett bättre alternativ till att konstant hämta data från servern är att mellanlagra data lokalt i enheten. Android erbjuder ett integrerat sätt att skapa databaser med hjälp av SQLite . Enligt Google är det rekommenderat att skapa ett kontrakt som definierar vad databasen ska innehålla [19]. Ett sådant kontrakt ger en överskådlig blick över databasens innehåll. Det är en javaklass som organiserar och standardiserar namn för databasens tabeller samt de URIs som används för sökning i databasen. Ett kontrakt skapades således i applikationen vilket hjälpklassen SQLiteOpenHelper använder när den skapar och refererar till databasen [19]. Databasen kan nås direkt från en activity eller fragment . Ett annat sätt att interagera med databasen är genom en content provider .

3.5.2 Content Providers

Google definierar content providers på Developer.android.com enligt följande: Content providers manage access to a structured set of data. They encapsulate the data, and provide mechanisms for defining data security. Content providers are the standard interface that connects data in one process with code running in another process. [20] Primärt är content providers avsedda att användas i samband med anrop från andra applikationer [21]. Men de används med fördel även med intentionen att kommunicera inom applikationen. Flera av Androids standardklasser kräver en content provider för att fungera. Content providers fungerar som en abstraktion mellan det grafiska gränssnittet och data. Genom att abstrahera åtkomsten av data kan källan bytas ut utan att påverka resten av systemet. De ger också struktur åt datahanteringen. Content providers använder sig av URI:s, Universal Resource Identifiers , för lokalisering av data. När data ska lagras kontaktas en content provider genom en sk content resolver . Data lagras enligt vald metod och sedan kan data hämtas när så önskas. Om applikationen har medgett delning av data kan andra applikationer hämta och modifiera data via en content provider. I denna applikation implementerades därför en content provider tillsammans med loaders och en syncadapter för att optimera lagring och synkronisering av data.