Examensarbete
Dataingenjör 180hp
InStore Display Application
Datavetenskap 15hp
Halmstad 2020-12-14
some text
InStore Display Application
Anton Ebeling Juni 2020
some text
Abstract
This thesis covers the development of an application. The application is devel- oped in terms of helping sellers, who in turn help customers in, for example, a clothing store. This is done by obtaining information about the various prod- ucts of the store by means of various search functions. The result of the search is a list of products that match the search parameters the user enters, these products lead to a product page where further information about the product is displayed. The fact that a seller has the opportunity to download this applica- tion in a mobile device gives the seller a very good tool to help the customers.
This is because the seller does not have to go to a fixed computer to check prod- uct information, such as stock balance, but it is directly in the mobile device.
The result of this is that the customer gets a better experience with the seller, and that the seller can work more efficiently.
some text
Sammanfattning
Detta examensarbete omfattar utvecklingen av en applikation. Applikationen
¨
ar utvecklad i avseende f¨or att hj¨alpa s¨aljare, som i sin tur hj¨alper kunder i exempelvis en kl¨adaff¨ar. Detta genom att med hj¨alp av olika s¨okfunktioner f˚a information ang˚aende butikens olika produkter. Resultatet av s¨okningen blir en lista av produkter som st¨ammer mot de s¨okparametrar anv¨andaren matar in, dessa produkterna leder till en produktsida d¨ar vidare information om produk- ten visas. Att en s¨aljare har m¨ojligheten att ladda ner denna applikation i en mobil enhet ger s¨aljaren ett mycket bra redskap f¨or att hj¨alpa kunderna. Detta f¨or att s¨aljaren inte beh¨over ta sig till en fast dator f¨or att kolla upp produkt- information, exempelvis lagersaldo, utan det finns direkt i den mobila enheten.
Resultatet av detta ¨ar att kunden f˚ar en b¨attre upplevelse med s¨aljaren, och att s¨aljaren kan arbeta mer effektivt.
Inneh˚ allsf¨ orteckning
1 Introduktion 5
1.1 Syfte . . . . 5
1.2 Kravspecifikation . . . . 6
1.2.1 Design . . . . 6
1.2.2 Funktioner . . . . 7
1.3 Avgr¨ansningar . . . . 8
2 Bakgrund 9 2.1 Anv¨andarupplevelse . . . . 9
2.2 Programvarutestning . . . . 10
3 Metod 11 3.1 Metodbeskrivning . . . . 11
3.2 UX . . . . 11
3.2.1 Adobe XD . . . . 11
3.3 Mjukvaruutveckling . . . . 12
3.3.1 Flutter . . . . 12
3.3.2 Android Studio . . . . 13
3.3.3 Pimcore . . . . 13
3.3.4 API . . . . 13
3.4 Tester . . . . 13
3.4.1 Postman . . . . 13
3.5 Analys av resultatet . . . . 14
4 Resultat 17 4.1 Prototyp . . . . 17
4.2 Applikation . . . . 19
4.2.1 Design . . . . 19
4.2.2 Kod . . . . 21
4.2.3 Tester . . . . 24
5 Diskussion 27 5.1 Slutsats . . . . 28
Kapitel 1
Introduktion
Projektet omfattar tillverkning av en applikation som ska hj¨alpa s¨aljare i bu- tiker, som i sin tur hj¨alper kunder. Tanken ¨ar att applikationen ska m¨ojligg¨ora specifika s¨okningar p˚a exempelvis namn, artikelnummer, egenskaper och f¨arg.
Svaret ska d˚a resultera i information ang˚aende det man s¨okte p˚a, s˚a som lager- saldo, storlekar, egenskaper och f¨argval.
Relevansen bakom projektet kommer ifr˚an att n¨ar en kund i en butik fr˚agar efter storlekar eller specifika egenskaper, detta kr¨aver ofta att personalen beh¨over g˚a till lagret och sj¨alva se efter. Men med en applikation som denna s˚a hade det inte beh¨ovts, d˚a hade personalen kunnat s¨oka direkt i lagret, med applikationen, och f˚a upp allt de beh¨over veta f¨or att svara p˚a kundens fr˚agor. Detta effektivis- erar servicen i butiken, vilket kan m¨ojligg¨ora att f¨arre personal beh¨over n¨arvara.
Applikationen ¨ar utvecklad f¨or att fungera cross-platform, det vill s¨aga den fungerar p˚a b˚ade iOS (Apple) och Android (Google) enheter. Plattformar f¨or mobila enheter ¨ar i olika slag med avseende p˚a operativsystem, ramverk och programmeringsspr˚ak. F¨oljaktligen s˚a skulle portningen av en applikation till en annan plattform leda till en dyr ombyggnad fr˚an b¨orjan [1]. Cross-platform utveckling tr¨ader fram f¨or att m¨ota dessa utmaningar genom att l˚ata utvecklare implementera deras applikationer i ett steg f¨or en rad olika plattformar, medans man undviker upprepning och ¨okar produktiviteten. ˚A ena sidan, s˚a m˚aste dessa tillv¨agag˚angs¨att erbjuda l¨amplig generalitet f¨or att m¨ojligg¨ora tillhandah˚allande av applikationer f¨or flera plattformar. ˚A andra sidan m˚aste de fortfarande g¨ora det m¨ojligt f¨or utvecklare att dra f¨ordel av de specifika f¨ordelarna och m¨ojligheter som finns f¨or smartmobiler [2].
1.1 Syfte
Syftet med projektet ¨ar att minska personalkostnader samt ¨oka kundupplevelsen.
Genom att skapa en produkt som g¨or det m¨ojligt f¨or f¨oretag att effektivisera
behandlingen av kunder, s˚a ¨oppnar det m¨ojligheten att dra in p˚a personal och minska utgifterna. Detta genom att g¨ora det m¨ojligt f¨or personalen att leta och s¨oka information genom en applikation som ¨ar kopplad till f¨oretagets databas.
Genom att arbeta p˚a detta s¨attet s˚a f¨or anv¨andren ett direkt svar fr˚an databasen som st¨andigt uppdateras.
Viktiga m˚al som siktas p˚a att uppn˚as ¨ar att applikation inte ska frysa, det vill s¨aga l˚asa sig i ett l¨age och kr¨ava omstart, samt att den inte ska krascha.
Detta ¨ar de tv˚a huvudsakliga anledningarna till att anv¨andare slutar anv¨anda en applikation [3]. Med detta sagt s˚a ¨ar det viktigt att ta h¨ansyn till dessa faktorer, och utforma en applikation som ¨ar stabil och v¨al testad.
1.2 Kravspecifikation
Kravspecifikationerna ¨ar framtagna av projektets utvecklare tillsammans med handledare och designer fr˚an f¨oretaget. Detta har givit en bra bild av hur applikationen ska fungera funktionellt, samt hur den ska se ut visuellt. Inom omr˚adena design och funktionalitet f¨or applikationen ¨ar f¨oljande:
1.2.1 Design
• Anv¨andarv¨anlighet. Det ska vara instinktivt hur man r¨or sig i applika- tionen, det vill s¨aga hur man navigerar mellan sidor. Det ska ocks˚a vara simpelt att f¨orst˚a vart man ¨ar n˚agonstans i applikationen och hur man tar sig vidare d¨arifr˚an, eller g˚ar tillbaka till f¨oreg˚aende sida om m¨ojligt.
• Navigation. Det ska vara l¨att att skilja p˚a de olika funktionerna som applikationen erbjuder, det vill s¨aga vad de olika sidorna inneb¨ar och vad de erbjuder.
• Textsnitt. Det ska vara l¨att att l¨asa all text som visas i applikationen.
Detta innefattar ¨aven storleken p˚a saker som knappar och bilder, de ska ocks˚a vara tydliga.
• Responsivitet. Applikationen ska vara s˚apass responsiv att det inte spelar n˚agon roll hur stor sk¨armen ¨ar, den ska fungera lika bra p˚a alla sk¨armar.
Det ska inte vara n˚agra problem med hur det formateras p˚a sidan, utan det ska se likadant ut.
• Ut¨okningsbar. Applikationen ska vara utformat p˚a ett s¨att, ur designper- spektiv, som ¨ar l¨att att ut¨oka ifr˚an. Det vill s¨aga att det ska vara l¨att att l¨agga till fler funktioner, samt att det ska vara l¨att att bygga vidare applikationen.
• Recognition rather than recall, eller hellre igenk¨anning ¨an h˚agkomst, detta tillh¨or kategorin UX, vidare f¨orklarat under sektionen Anv¨andarupplevelse.
F¨orsta g˚angen en anv¨andare anv¨ander applikationen s˚a ska det vara up- penbart hur man hanterar den. Det ¨ar viktigt att det ¨ar l¨att att k¨anna igen hur man anv¨ander applikationen, man ska inte beh¨ova komma ih˚ag hur man gjorde sist. En ny anv¨andare ska kunna anv¨anda applikationen lika bra som en frekvent anv¨andare.
1.2.2 Funktioner
• Data. Den data som ska anv¨ands i projektet kommer till sin b¨orjan vara h˚ardkodad, f¨or att sedan anv¨anda en databas med en kopia av ett f¨oretags riktiga data.
• S¨okning. Det ska finnas tv˚a olika s¨att att s¨oka efter artiklar i applikatio- nen. Den f¨orsta ¨ar att man ska kunna s¨oka med artikelnummer, resultatet kommer enbart vara baserat p˚a likheten mellan artikelnummren. Resul- tatet ska variera beroende p˚a hur m˚anga artiklar, vars artikelnummer, inneh˚aller det man s¨okt p˚a. Ett helt artikelnummer ska enbart resul- tera i ett resultat, detta d˚a det inte ska finnas tv˚a, eller flera, artiklar med samma kompletta artikelnummer. Under artikels¨okningen s˚a ska det ocks˚a finnas en funktion som l˚ater anv¨andaren skanna en streckkod eller QR-kod, detta f¨or att mata in artikelnummret. Man ska ocks˚a kunna s¨oka med nyckelord, detta kommer att resultera i en lista av produkter, d¨ar artiklarna passar in p˚a s¨okningen. Denna lista uppdateras direkt n¨ar parametrar matas in. Dessa tv˚a varianter av s¨okning ska ligga under tv˚a olika sidor i applikationen, och vara ˚atkomliga via en startsida.
• Filtrering. Anv¨andaren ska kunna filtrera s¨okningen via en filtrerings- meny, d¨ar det ska vara alternativ f¨or att v¨alja olika egenskaper. N˚agra av dessa egenskaper kommer att vara: kategori, f¨arg, m¨arke, material storlek et cetera. Dessa filter ska d˚a direkt appliceras p˚a s¨okningen.
• Respons tid, tiden det f˚ar ta f¨or de olika funktionerna att g¨oras. Det finns tre huvudsakliga gr¨anser f¨or respons tiden, dessa best¨ams av m¨anniskans perceptuella f¨orm˚aga. Dessa tre g¨anserna ¨ar f¨oljande[4]:
– 0.1 sekund, detta ¨ar gr¨ansen f¨or att anv¨andaren ska k¨anna att svaret
¨
ar omedelbart. Med detta s˚a beh¨ovs ingen speciell feedback, det ¨ar bara att visa svaret.
– 1 sekund, h¨ar ligger gr¨ansen f¨or att anv¨andarens fl¨ode av tankar inte ska avbrytas trots att anv¨andaren m¨aker den korta f¨ordr¨ojningen.
Inte heller h¨ar kr¨avs n˚agon speciell feedback f¨or anv¨andaren. Vid reponstider mellan 0.1 sekunder och 1 sekund s˚a mister anv¨andaren k¨anslan av att arbeta direkt med datan.
– 10 sekunder, detta ¨ar gr¨ansen f¨or anv¨andaren ska beh˚alla fokuset p˚a det som h¨ander. Vid l¨angre respons tider s˚a vill anv¨andaren g¨ora n˚agot annat medans det laddar klart, s˚a det b¨or visas n˚agon typ av
feedback f¨or att ber¨atta hur l˚angt som ¨ar kvar. Feedback vid repon- stider som kan variera stort ¨ar extra viktigt, detta d˚a anv¨andaren inte vet hur l˚ang tid det kommer ta mellan g˚angerna.
S˚a att h˚alla sig inom dessa ramar ¨ar viktigt f¨or att applikationen inte ska uppfattar som l˚angam, eller att anv¨andaren inte f˚ar den information om respons tiden som beh¨ovs.
1.3 Avgr¨ ansningar
Databas & API
N¨asta steg i utvecklingen hade varit att implementera ett applikationsprogram- meringsgr¨anssnitt, Application Programming Interface (API), f¨or att m¨ojligg¨ora arbete med riktig data fr˚an ett f¨oretag. Nu arbetar applikationen enbart mot en h˚ardkodad lista av produkter, denna inneh˚aller data liknande fr˚an APIt. Tester kommer att utf¨oras mot APIt ¨aven om det inte ¨ar implementerat i koden, detta f¨or att kunna se responstiden vid olika sorters s¨okning. Dessa tester m¨ojligg¨ors med hj¨alp av tj¨anster i programmet Postman, detta d˚a Postman har funktioner som ger svar p˚a hur stort svaret ¨ar, samt hur l˚ang tid det tar att f˚a svaret.
Kapitel 2
Bakgrund
En bra applikation skall vara byggd p˚a en bra ide. En bra ide har en unik st˚andpunkt som kan skilja en specifik applikation fr˚an andra, men som ocks˚a kommer med bra utf¨orande [5]. Applikationen kommer att utvecklas som en
”native” applikation och inte som en ”webbapplikation”. Det som menas med
”native” ¨ar att det finns m¨ojlighet att anv¨anda h˚ardvarustyda system som ex- empelvis GPS, telefon och kamera. En ”webbapplikation” kan ocks˚a ha tillg˚ang till viss funktionalitet, men d˚a det st¨ods av fler plattformar s˚a saknar det ocks˚a ofta m˚anga funktionalitet som ”native” har [6].
Applikationen har utvecklats i en cross-platform milj¨o som heter Flutter d˚a efterfr˚agan f¨or applikationer som ¨ar kompatibla med b˚ada iOS och Android ¨ar stor [7]. D¨aremot s˚a kommer applikationen vara utformad f¨or Android, d˚a iOS har v¨aldigt stora och omfattande designprinciper [8]. Dessa m˚aste f¨oljas f¨or att applikationen ska f˚a lanseras i iOS AppStore [9]. Det finns ¨aven liknande riktlinjer f¨or en Android applikation, men d˚a applikationen kommer att skapas med Flutter s˚a kommer mycket att komma per automatik d˚a b˚ade Flutter och Android ¨ar skapade av Google [10]. Valet blev ¨aven Android f¨or det fr¨amst anv¨ands i mobiltelefoner. Varje Android applikation har en egen livscykel som den kontrollerar, detta d˚a varje applikation k¨ors i en egen instans i operativsys- temet [6].
2.1 Anv¨ andarupplevelse
Anv¨andarupplevelse, ¨aven kallat UX, fr˚an engelskans User Experience, handlar om designarbete som f¨orb¨attrar anv¨andarens upplevelse av en tj¨anst eller pro- dukt. Det viktiga med UX-arbetet ¨ar att det dels underl¨attar utveckling, samt hj¨alper kunden att f˚a en uppfattning av hur applikationen kommer se ut, det vill s¨aga om UX-designern arbetar med prototyper. Ett par ”best practices” f¨or UX kommer nedan[11]:
• En hemsida l¨ases inte igenom p˚a en djup niv˚a, den skannas. Detta in-
neb¨ar att det ¨ar viktigt med bilder, och tydliga knappar, s˚a man f˚angar anv¨andaren och hj¨alper anv¨andaren snabbt hittar r¨att.
• K¨ann m˚algruppen. Det ¨ar viktigt att man som UX-designer vet vad det
¨
ar f¨or m˚algrupp man ska arbeta mot, detta d˚a det kan ¨andra hur man l¨agger upp en hemsida. N¨ar man vet vad det ¨ar kunden beh¨over och vill har, s˚a kan man b¨orja tillverka en matchande design.
2.2 Programvarutestning
Programvarutestning, fr˚an engelskans Software Testing, ¨aven kallat mjukvarutest- ning, ¨ar en unders¨okning som genomf¨ors f¨or att ge utvecklare och intressenter information om kvaliteten p˚a produkten som testats [12]. Testerna kan ocks˚a ge en objektiv och oberoende bild av mjukvaran, detta f¨or att g¨ora det m¨ojligt f¨or utvecklaren att uppskatta och f¨orst˚a riskerna med mjukvaruimplementeringen.
Mjukvarutester inneb¨ar exekvering av mjukvarukomponenter eller systemkom- ponenter f¨or att utv¨ardera en eller flera egenskaper av intresse f¨or utvecklaren.
Kapitel 3
Metod
3.1 Metodbeskrivning
Datan som ska anv¨andas kommer att h¨amtas fr˚an en Pimcore databas som hanterar masterdata. Verktyg som kommer att anv¨andas ¨ar f¨oljande: Adobe XD, Flutter, Android Studio, Pimcore, ett API och Postman. Projektet i sig kommer utf¨oras utefter en standard projektuppl¨aggning, detta inneb¨ar att det kommer involvera uppf¨oljning av arbetet, samt dokumentation under projektets g˚ang.
Nedan listas de verktyg som anv¨ands i projektet. Dessa anv¨ands f¨or att uppn˚a de specifikationerna som finns. Men ocks˚a att kunna skapa de mallar och prototyper som kommer att anv¨andas under projektets g˚ang. Kategoriserat efter anv¨andningsomr˚ade.
3.2 UX
3.2.1 Adobe XD
Adobe XD ¨ar ett vektor-baserat grafikprogram som anv¨ands av UX-designers f¨or att skapa prototyper ˚at olika webbapplikationer samt mobilapplikationer.
Dessa prototyper skapas med h¨og kvalitet, precision och hastighet [13], det som skapar ¨ar inte i n˚agon form en fungerande applikation, utan enbart illusteringar av layouten. Adobe XD g¨or det ocks˚a m¨ojligt att dela de skapade prototyperna med medarbetare och kunder. Adobe XD har ungef¨ar samma syfte som det liknande programmet Sketch, dessa ¨ar b˚ada fokuserade p˚a anv¨andargr¨anssnitt, User Interface (UI). D¨aremot s˚a skiljer de sig ˚at p˚a ett par fronter. Sketch finns endast till MacOS, och kr¨aver ett plugin f¨or att kunna g¨ora prototyper.
Adobe XD finns till b˚ade Windows och MacOS och har ett verktyg f¨or att skapa prototyper inbyggt [14]. Detta resulterar i att Adobe XD har allt anv¨andaren beh¨over direkt, medans det kr¨aver extra arbete med Sketch.
3.3 Mjukvaruutveckling
3.3.1 Flutter
Flutter ¨ar en programvaruutvecklingssats f¨or anv¨andargr¨anssnitt som ¨ar skapat av Google, och anv¨ands f¨or att skapa applikationer f¨or Android, iOS, Windows, Mac, Linux, Google Fuschia samt webbapplikationer[15]. Flutter skrivs i spr˚aket Dart, och har som m˚al att ers¨atta JavaScript. Flutter inneh˚aller element from b˚ada Android och iOS, men till skillnad fr˚an React Native som ¨ar en konkur- rent, s˚a ¨ar alla element, eller Widgets, anv¨andbara i b˚ada operativsystemen.
Gradle ¨ar ett generellt lednigssytem, som st¨odjer nedladdning samt kon- figuration av Dependencies. I andra programvaruutvecklingssatser kr¨avs att man k¨or en ny Gradle Build varje g˚ang man uppdaterar koden, vilket tar runt 44.55s(eget testat), i Flutter s˚a beh¨over du enbart g¨ora detta vid f¨orsta starten.
Detta d˚a Flutter har en funktion som heter Hot Reload som k¨ors ist¨allet n¨ar man ska uppdatera koden. Hot Reload ¨okar utvecklingshastigheten signifikant, denna funktion g¨or att det enbart tar 2.26s(eget testat) att uppdatera applika- tionen med ny kod, vilket ¨ar runt 5% av tiden det tar att k¨ora en hel Gradle build. Det h¨ar minskar d˚a tiden det tar att utveckla en applikation, och uppma- nar ¨aven utvecklaren att ladda om applikationen f¨or att se ¨andringarna oftare.
Majoriteten av koden i projektet kommer vara skriven med hj¨alp av Flutter d˚a utvecklingshastigheten ¨okar, samt att m˚anga av de designkrav som finns f¨or Android applikationer st¨ods i Flutter.
Flutter anv¨ander n˚agot som heter ”Widget” och ¨ar objekt i applikationen.
Flutter kommer med en m¨angd olika sorters widgetar, som exempelvis Text-, Icon-, Image och Appbar-widget. Dessa arbetar tillsammans f¨or att skapa en applikation, d˚a dessa ¨ar f¨ardiggjorda och redo att anv¨anda s˚a underl¨attar det utvecklings arbetet medans det h˚allet en h¨og standard. Alla olika widgetar har en m¨angd olika egenskaper som utvecklaren f¨or best¨amma vid implemen- tation. Textwidgeten har exempelvis en konstruktor som heter ”Text”, d¨ar matar utvecklaren f¨orst in vad som ska st˚a i texrutan, f¨or att sedan s¨atta till egenskaper, nedan n¨amns n˚agra:
• TextStyle. Anv¨ands f¨or att ¨andra stil p˚a texten, exempelvis storlek eller f¨arg.
• TextAlign. Ger utvecklaren m¨ojlighet att placera texten d¨ar den ¨ar t¨ankt att vara placerad.
• MaxLines. Best¨amer det maximala antalet rader som widgeten ska ha, om antalet linjer skulle ¨overskrida denna gr¨ans s˚a trunkeras dem.
3.3.2 Android Studio
Android Studio ¨ar ett gratis program skapat av Google och JetBrains specifikt f¨or utveckling av Android-applikationer [16]. Detta ¨ar programmet som pro- jektet ¨ar utvecklat i. Detta f¨or att det finns m¨ojlighet att snabbt uppdatera versioner av applikationen direkt till en mobil som ¨ar kopplad till datorn. Det finns ¨aven en emulator inbyggd i programmet f¨or att skapa en virtuell Android- enhet, Android Virtual Device (AVD), som fungerar lika bra som en fysiskt enhet. I emulatorn kan man ocks˚a v¨alja vilken version av Android man vill anv¨anda, detta f¨or att l¨att kunna testa hur en applikation fungerar under olika versioner av operativsystemet.
3.3.3 Pimcore
Den data som kommer anv¨andas i applikationen h¨amtas ifr˚an ett PIM(Product Informaiton Management) system som heter Pimcore, och detta system hanterar masterdata[17]. Pimcore ¨ar ¨aven 100% API-drivet. Denna data kommer sedan att h¨amtas med hj¨alp av ett API, d¨arefter anv¨andas av applikationen f¨or att visa produkter och tillh¨orande information.
3.3.4 API
Projektet kommer att vara byggt mot ett API som i det h¨ar fallet ¨ar l¨anken mellan applikationen och databasen, detta kan f¨orklaras med en liknelse. I en restaurang s˚a har du ett bord (applikationen) och ett k¨ok (databasen), en viktig del saknas f¨or att de tv˚a delarna ska kunna kommunicera, kyparen. Kyparen tar en f¨orfr˚agan till k¨oket, och ˚aterl¨amnar sedan ett svar, i ett program s˚a ¨ar det APIt som ¨ar kyparen. APIt tar f¨orfr˚agningar, h¨amtar svar, och sedan returnerar dem. I konstruktionen av en applikation, s˚a f¨orenklar ett API programmerin- gen genom att abstrahera den underliggande implementeringen och visar bara informationen som utvecklaren beh¨over. Ett API f¨or filinmatning/-utg˚ang kan ge utvecklaren en funktion som kopierar en fil fr˚an ett st¨alle till ett annat, detta utan att utvecklaren beh¨over f¨orst˚a den underliggande logiken f¨or filsystemets operationer [18].
3.4 Tester
3.4.1 Postman
Postman ¨ar ett verktyg som l˚ater anv¨andaren skapa egna metoder och skicka f¨orfr˚agningar till ett API. Den funktion i Postman som kommer att anv¨andas mest ¨ar m¨ojligheten att inspektera svar fr˚an APIt, och det inkluderar ocks˚a statuskod, responstid och responsstorlek [19]. Under responstiden kan man ocks˚a se hur l˚ang tid de olika momenten tar, de moment som ¨ar viktiga att fokusera p˚a vid m¨atning av tiden ¨ar TCP Handshake, Transfer Start och Down- load.
• TCP Handshake, data¨overf¨oringsprotokollet Transmission Control Proto- col (TCP) anv¨ander en trev¨ags handskaking f¨or att uppn˚a en s¨aker l¨ank mellan klienten och serven, detta m˚aste g¨oras innan data skickas mellan server och klient. Anslutningen ¨ar full-duplex och b˚ada sidorna synkronis- erar och erk¨anner anslutningen f¨or varanda. Anslutningen kommer efter en tid att avbrytas, antigen av b˚ada parterna tillsammans, eller av en TimeOut. Om fler f¨orfr˚agningar utf¨ors innan anslutningen st¨angs ner s˚a beh¨over inte detta g¨oras igen. Tiden det tar f¨or anslutningen att slutf¨oras
¨
ar det som ¨ar intressant i testerna.
• Transfer Start, detta ¨ar tiden det tar f¨or serven att svara p˚a f¨orfr˚agan.
Tiden det tar inkluderar b˚ade tiden det tar att skicka till serven och till- baka, samt hur l˚ang tid som ¨ar ¨agnad till att v¨anta p˚a svaret.
• Download, h¨ar visas tiden f¨or hur l˚ang tid det tar att ladda ner datan som serven skickat. Tiden det tar att ladda ner beror p˚a svarsstorleken fr˚an serven.
3.5 Analys av resultatet
Analys och verifiering av detta projekt planerades g¨oras genom att testa flera olika scenario, och sedan se om det resulterar i vad som ¨ar f¨orv¨antat. N˚agra av testerna som var viktiga att unders¨oka ¨ar bland annat, funktionalitets-, prestanda- och integrationstester [20]. Testerna kommer att utf¨oras b˚ade f¨or hand, och med hj¨alp av olika program, detta f¨or att det kan vara sv˚art att simulera hur en m¨anniska beter sig n¨ar hen hanterar en applikation. Det finns flera olika program som kan stresstesta applikationen med en rad olika tester, vilket blir sv˚art f¨or en m¨anniska att efterlikna.
Flutter erbjuder en upps¨attning av tester, dessa tester tillh¨or tre olika kat- egorier:
• ”Unit test” testar en enda funktion, metod eller klass. M˚alet med ”Unit tests” ¨ar att testa riktigheten av logiken under olika f¨orh˚allanden. ”Unit tests” l¨aser i allm¨anhet inte fr˚an eller skriver till en disk, skriver inte heller till en sk¨arm [20].
• ”Widget test” i andra ramverk kallad ”Component test” testar en en- sam widget. M˚alet med ett ”Widget test” ¨ar att verifiera att en widgets anv¨andargr¨anssnitt ser ut och fungerar som f¨orv¨antat. Att testa en widget involverar flera olika klasser och kr¨aver en egen testmilj¨o [20].
• ”Integration tests” testar en hel applikation, eller en st¨orre del av en ap- plikation. M˚alet med ”Integration tests” ¨ar att verifiera att alla widgets och tj¨anster arbetar tillsammans som f¨orv¨antat. Med hj¨alp av ”Integration tests” s˚a kan man ¨aven testa en applikations prestanda [20]. Anv¨andaren f¨orv¨antar sig att applikationen har mjuk scrollning och n¨odv¨andiga ani- mationer, vilket inneb¨ar god prestanda [21].
En v¨al testad applikation har m˚anga unit och widget tester, plus tillr¨ackligt m˚anga integration tester f¨or att t¨acka alla viktiga fall[20]. Detta r˚ad ¨ar baserat p˚a ett det faktum att det ¨ar en avv¨agning mellan olika tester, illusterat i Tabell 3.1.
Tabell 3.1: https://flutter.dev/docs/testing
F¨or att kunna utf¨ora dessa tester s˚a kr¨avs det kunskap inom programmerings spr˚aket Dart, detta f¨or att det ¨ar det spr˚aket som anv¨ands f¨or att skriva de olika test-scenariorna. Detta beh¨over g¨oras i alla av de tre testena, dock p˚a olika vis.
Man anv¨ander ocks˚a inbyggda vektyg i Flutter f¨or ett g¨ora testningen enklare.
Kapitel 4
Resultat
4.1 Prototyp
Prototypen baseras p˚a ¨overenskommelser mellan utvecklare, handledare och UX-designer, d¨ar specifikationerna best¨amdes f¨or hur designen skulle se ut. Pro- totypen byggdes i Adobe XD f¨or en interaktiv upplevelse vid uppvisning, och
¨
aven f¨or att exemplifiera funktionerna. Resultatet efter prototyp utceklingen i Adobe XD blev f¨oljande Figur 4.1-4.2.
(a) Inloggnings sida (b) Val av s¨oktyp
Figur 4.1: Adobe XD Prototyp
I Figur 4.1-a ¨ar vyn av hur inloggningen ser ut. I Figur 4.1-b ¨ar vyn med valen av vilken typ av s¨okning som ska g¨oras. Det vill s¨aga antingen s¨okning med artikelnummer, eller s¨okning p˚a namn/egenskaper/filter.
(a) Filtrerad s¨okning (b) Artikelnummers¨okning
Figur 4.2: Adobe XD Prototyp
I Figur 4.2-a ¨ar svaret av en filters¨okning. H¨ar presenteras en lista av de resultat som passar in p˚a det som s¨oktes. I Figur 4.2-b visas svaret av en s¨okning p˚a artikelnummer, eller en avl¨asning av streckkod/QR-kod. H¨ar presenteras produkten direkt, tillsammans med lagersaldo, f¨arger, pris och ¨ovriga detaljer.
4.2 Applikation
4.2.1 Design
Applikationen har i f¨ardigt skick ett n˚agot annorlunda utseende j¨amf¨ort med hur den ser ut i prototyperna, detta som f¨oljd av hur man smidigast bygger applikationen i Flutter. Flutter har funktioner som f˚ar fl¨odet av en applika- tion att fungera b¨attre. De element som p˚averkades var listan p˚a produkter, samt produktsidan. Skillnaden blev att listan p˚a produkter har ett objekt i varje rad, Figur 4.3-a, ist¨allet f¨or tv˚a som i Figur 4.2-a. Varje objekt i lis- tan g˚ar att klicka p˚a f¨or att blir vidare dirigerad till produktsidan. Allt som pris, namn och artikelnummer kommer fr˚an samma databasobjekt, det vill s¨aga, list-objektet och produktsidan h¨amtar samma v¨arde s˚a allting kommer att upp- dateras tillsammans. Det ¨ar exempelvis inte ett pris f¨or listobjektet och ett pris f¨or produktsidan, utan det ¨ar ett gemensamt. Produktsidan blev till en egen
sida, Figur4.3-b, ist¨allet f¨or att ligga som ett resultat under s¨okf¨altet visat i Figur 4.2-b. Detta resulterar i att man f˚ar ett b¨attre ¨overblick av produkten d˚a det inte ¨ar n˚agot annat att locka fokus. Produktdetaljerna ligger som en l¨opande text under produkten f¨or att l¨att kunna h¨amta n¨odv¨andig information, storlekarna ligger bredvid f¨argvalen d˚a de h¨or tillsammans.
(a) S¨okresultat av parameter
”05”
(b) Produkt sida
Figur 4.3: Skillnader mellan applikation och prototyp
Filters¨okningssidan och artikenummers¨okningssidan ser i stora delar likadana ut och resultatet presenteras p˚a samma s¨att. Det som skiljer dem ˚at ¨ar att ar- tikels¨oknigen har en extra knapp f¨or att skanna en streckkod eller QR-kod, denna knapp ligger i sj¨alva s¨okrutan, se Figur4.3-a. Funktionaliteten bakom denna ikon ¨ar att anv¨andaren f˚ar m¨ojligheten att skanna streckkokd eller QR- kod f¨or att mata in artikelnummret. Andledingnen till att sidorna ser likadana ut ¨ar f¨or att det underl¨attar hanteringen f¨or anv¨andaren, det ¨ar d¨aremot enkelt att skilja dem ˚at d˚a det ¨ar en stor rubrik som s¨ager vilken sida du befinner dig p˚a. Det som g¨or hanteringen l¨attare ¨ar att ingen sida ¨ar sv˚arare att anv¨anda
¨
an den andra, detta resulterar i att b˚ada sidorna ¨ar lika l¨attanv¨anda vilket ger en kortare inl¨arningsperiod. De olika sidorna har i sitt navigationsf¨alt en tillbaka knapp som l˚ater anv¨andaren g˚a tillbaka till f¨oreg˚aende sida. Detta l˚ater anv¨andaren g˚a vidare till en produkt, och sedan g˚a tillbaka igen, med de s¨okparametrar och svar som matades in fr˚an b¨orjan sparade. Detta g¨or det l¨attare f¨or anv¨andaren att j¨amnf¨ora olika produkter.
4.2.2 Kod
Applikationen ¨ar uppbyggd med hj¨alp av olika widgets, olika widgets fyller olika funktioner i applikationen. En del ¨ar f¨or att visa information f¨or anv¨andaren, och en del ¨ar f¨or att utf¨ora f¨orfr˚agningar. Exempel p˚a f¨orfr˚agning som kan kallas p˚a ¨ar ”SetState()”, den anv¨ands f¨or att uppdatera ¨andrad information i exempelvis en text-widget, som i sin tur anv¨ands f¨or att visa information.
Den fungerar s˚a att den talar om f¨or ramverket att tillst˚andet har ¨andrats och beh¨over uppdateras, vilket resulterar i att informationen i applikationen
¨
andras. Flutter anv¨ander sig av n˚agot de kallar ”Navigator” f¨or att l¨agga till nya vyer, eller g˚a tillbaka till f¨oreg˚aende vyer. Navigator ¨ar byggt som en stack, det vill s¨aga att en ny sida l¨aggs ”ovanp˚a” med hj¨alp av en funktion som heter Push som kallas p˚a i koden. Funktionen Push l¨agger till en Route, eller Sida, till Stacken som Navigator tar hand om, vilket sedan blir sida som anv¨andaren ser och interakterar med. I Figur 4.4 s˚a visas kod d¨ar funktionen Push k¨ors vid en knapptryckning. Push kr¨aver tv˚a argument f¨or att fungera, dels ”Context”, som representerar var den ¨ar n˚agonstans i widgettr¨adet. Push beh¨over ocks˚a en ”Route”, utvecklaren kan skapa en egen Route, eller anv¨anda
”MaterialPageRoute”, vilket ¨ar f¨ordelaktigt d˚a den ¨overg˚ar till den sidan med en plattform-specifik ¨overg˚ang.
Figur 4.4: Bild fr˚an projektets kod av funktionen Push
Sedan f¨or att g˚a tillbaka s˚a kallas funktionen Pop, denna funktion tar bort den tillagda sidan f¨or att visa original sidan. Pop kr¨aver endast ett argument f¨or att fungera, detta ¨ar Context, visat i Figur 4.5 Hur funktionerna Push och Pop arbetar med varandra vitaliseras i Figur 4.6 med Stack format, d¨ar sidor l¨aggs till p˚a Stacken och tar bort vid Push, respektive vid Pop.
Figur 4.5: Bidd fr˚an projektets kod av funktionen Pop
Figur 4.6: Visualisering av hur Navigator fungerar [22].
De olika produkterna i applikationen ¨ar byggda som objekt i en lista av typen ProductItem, som ¨ar egenutvecklad. Varje ProductItem l¨aggs till i en huvudlista vid applikationsstart, ¨ar alla olika produkter ligger lagrade. ProductItem kr¨aver 7 argument av olika typer f¨or att fungera:
1. Produktens namn 2. Artikelnummer
3. Beskrivning av produkten 4. Filv¨ag till produktbild 5. Pris
6. Storleksomr˚ade
7. F¨argalternativ i hexadecimalt
Hur ett listobjekt med ProductItem skrivs visas i Figur 4.7.
Figur 4.7: Bild av en produkt som anv¨ands i koden
Vid s¨okning efter en produkt s˚a g¨ors det p˚a olika s¨att beroende p˚a om det ¨ar en artikels¨oknging eller en filters¨okning, men hur resultatet visas ¨ar densamma.
V¨agen till s¨okningen, vad g¨aller kod, ¨ar densamma f¨or b˚ada s¨okningarna. N¨ar inneh˚allet i s¨okf¨altet ¨andras s˚a kallas en metod som heter searchOperation, som i sin tur kallar p˚a en funktion som uppdaterar inneh˚allet i en lista som heter ” searchList”, denna lista uppdateras med de objekt som till˚ats av s¨ok- funktionerna. S¨ok-funktionern f¨or artikels¨okning visas i Figur 4.8, en lista ska- pas f¨or att lagra de produkter som ska visas, det vill s¨aga de produkter som uppfyller s¨okkriteriet.
I en loop s˚a skapas variabler, och dessa anv¨ands f¨or att kolla om produk- ten finns, f¨or att sedan ladda in nya variabler tills det att alla produkter i ursprungslistan ¨ar testade. Dessa variabler skapas f¨or att h˚alla produktv¨arden fr˚an ursprungs listan, list, som sedan anv¨ands f¨or att j¨amf¨ora med det som
¨
ar inmatat i s¨okrutan. V¨ardet av det som ¨ar inmatat i s¨okrutan ¨ar ¨ar lagrat i
” controller.text” d˚a den h¨amtar datan fr˚an s¨okrutan. J¨amf¨orelsen ¨ar det som skiljer de olika s¨okfunktionerna ˚at, artikes¨okningen kollar om det som skrivs in existerar n˚agonstans i produktens artikelnummer(ean), det st¨ammer s˚a l¨aggs produkten in i ” searchList”. Detta medans filters¨oknignen j¨amf¨or om det som skrivs in st¨ammer ¨overens med namnet eller beskrivningen, visat i Figur 4.9.
Figur 4.8: Bild fr˚an koden i artSearch.dart, artikels¨okning, hur ett objekt kollas, hur ett nytt skapar och l¨aggs in i r¨att lista
Figur 4.9: Bild fr˚an koden i filterSearch.dart, filters¨okningen. J¨amf¨orelsen f¨or filters¨okningen.
Artikels¨okningen har ¨aven m¨ojlighet att skanna en streckkod eller QR-kod f¨or att mata in artikelnumret, detta genom anv¨andning av ett Flutter paket som heter Barcode scan[23]. Detta paket l˚ater anv¨andaren skanna en strekkod eller QR-kod, det ¨anda som kr¨avs fr˚an anv¨andaren ¨ar till˚atelse att anv¨anda kameran.
N¨ar alla objekt ¨ar genomk¨orda s˚a skapas en lista med objekten i ” searchList”
som anv¨andaren ser, Figur 4.3-a, d¨ar anv¨ands data fr˚an de olika ProductItems f¨or att visa n¨odv¨andig information f¨or anv¨andaren. Dessa objekt leder till pro- duktsidan, Figur 4.3-b, d¨ar datan i den valda produkten anv¨ands f¨or att visa all information ang˚aende produkten som ¨ar relevant f¨or anv¨andaren.
4.2.3 Tester
De tester som genomf¨orst mot APIt ¨ar f¨oljande:
• S¨okning med ID, vilker resulterar i en produkt. Det som documenterats
¨
ar, reponstidssnitt vid s¨okning med TCP Handshake, utan TCP Hand- shake och ¨aven storleken av svaret.
• S¨okning d¨ar namnet ska inneh˚alla ett speciellt ord, h¨ar med en begr¨ansning p˚a hur m˚anga returer som ska skickas, b˚ade 10 och sedan 100, p˚a olika ord. Det som dokumenteras ¨ar hur m˚anga svar som kommer in, tiden det tar f¨or svaret fr˚an APIt att anl¨anda samt hur stort det svaret ¨ar.
• S¨okning d¨ar produkten ska best˚a av ett speciellt material, h¨ar med en begr¨ansning p˚a hur m˚anga returer som ska skickas, b˚ade 10 och sedan 100, p˚a samma material. Det som dokumenteras ¨ar hur m˚anga svar som kommer in, tiden det tar f¨or svaret fr˚an APIt att anl¨anda samt hur stort det svaret ¨ar.
Resultatet av dessa tester har dokumenterats och f¨orts in i tabellerna 4.1, 4.2, och 4.3, detta f¨or att f˚a en ¨overblick av resultatet.
Tabell 4.1: S¨okning p˚a ID mot API S¨okningn p˚a ID Snitt tid med
TCP (ms)
Snitt tid utan TCP (ms)
Storlek
16088 108.5 63.6 1.32KB
16119 105.7 61.6 1.31KB
Tabell 4.2: S¨okning p˚a objekt d¨ar namnet st¨ammer med en s¨ok-parameter Parameter s¨okning i
Namn
Svar (antal) Snitt tid (ms) Storlek
”hawk”, limit 10 9 104 641B
”jacket”, limit 100 33 115 713B
Tabell 4.3: S¨okning p˚a objekt d¨ar materialet st¨ammer med en s¨ok-parameter Parameter s¨okning i
Material
Svar (antal) Snitt tid (ms) Storlek
”Polyester”, limit 10 10 115 643B
”Polyester”, limit 100 56 122 775B
Det som ¨ar viktigt att l¨agga m¨arke till i dessa tester, det ¨ar att det svar som kommer fr˚an APIt n¨ar man s¨oker med parameter ¨ar i form av en lista, och inneh˚aller faktiskt inte sj¨alva produkten, utan information som i sin tur leder till produkten. Detta leder till att dessa svaren ¨ar betydligt mindre, detta kan vi se i testerna. Till exempel n¨ar vi s¨oker p˚a ”jacket” och f˚ar en lista med 33 objekt s˚a ¨ar storleken p˚a svaret endast 713B. Detta medans en s¨okning p˚a en specifik produkt har en svarsstorlek p˚a cirka 1.31KB. D˚a de individuella objekten i listorna ¨ar s˚a sm˚a s˚a ¨okar hastigheten av ¨overf¨oringen, vilket ¨ar bra f¨or prestandan.
Kapitel 5
Diskussion
De m˚al som fokuset fr¨amst l˚ag p˚a var att applikationen skulle kunna utf¨ora tv˚a sorters s¨okning, artikelnummers¨okning och filters¨okning, samt m¨ojlighet att kunna skanna en streckkod eller QR-kod. Dessa m˚al har uppfylls d˚a funktion- erna att s¨oka b˚ada via artikelnummer och med filtrering finns och fungerar som de ska. Under artikelnummers¨okning finns ¨aven m¨ojlighet att skanna en streck- kod eller en QR-kod f¨or snabb inmatning av artikelnummer till s¨okf¨altet med hj¨alp av kameran. Det enda som anv¨andaren beh¨over g¨ora f¨or att kameran ska fungera, ¨ar att ge applikationen tillg˚ang till kameran, efter det s˚a kommer kam- eran kunna anv¨andas f¨or att skanna diverse koder.
Testresultaten fr˚an APIt, ligger i samtliga mellan 0.1 sekund och 1 sekund vilket ¨ar ¨ar f¨ordelaktigt f¨or anv¨andarupplevelsen, beskrivet under Funktioner.
Inte heller applikationen har n˚agon f¨ordr¨ojning i dagsl¨aget, d¨aremot beror detta bland annat p˚a att inneh˚allet ¨ar h˚ardkodat, och ingenting h¨amtas fr˚an ett API.
Men det ¨ar en bra utg˚angspunkt vid forsatt utveckling. Tyv¨arr s˚a utf¨ordes aldrig n˚agra tester med de tester som Flutter erbj¨od, detta d˚a dessa tester framf¨orallt hade testat prestandan p˚a applikationen. Eftersom applikationen inte arbetade mot n˚agot API, s˚a fanns det inte heller n˚agon f¨ordr¨ojning i applikationen, och d˚a inte heller n˚agon anledning att k¨ora prestanda tester d˚a de inte hade repre- senterat vekligheten.
Trots avgr¨ansningarna ang˚aende databas och API, s˚a har ett antal tester utf¨orts mot APIt f¨or att kartl¨agga hur responstiden samt svarsstorleken ser ut vid olika sorters f¨orfr˚agningar. Detta har i sin tur lett till en djupare f¨orst˚aelse f¨or hur svaret fr˚an APIt ser ut, och hur man ska hantera dessa svar p˚a b¨asta s¨att.
Under r˚adande omst¨andigheter med Covid-19 pandemin, s˚a har inte app- likationen kunnat testas mot en st¨orre grupp av personer. Detta har resulterat i att en st¨orre m¨angd information inte har kunnat samlas in ang˚aende hur Anv¨andarv¨anlighet, Navigation och Textsnitt upplevs. Detta d˚a applikationen inte g˚ar att ladda ner fr˚an en app-butik, utan den laddas in i telefonen via en
dator med projektkoden, s˚a har inte applikationen kunnat spridas. D¨aremot s˚a har de personer som har haft m¨ojlighet att testa applikationen givit positiv feed- back, detta inte alltid genom att s¨aga att applikationen ¨ar bra, utan att hen har navigerat genom applikaitonen utan att st¨alla n˚agra fr˚agor om vad saker och ting g¨or, och detta bevisar att m˚alet Anv¨andarv¨alighet ¨ar uppfyllt. Applikationen
¨
ar uppbyggd med minimalism i ˚atanke, det vill s¨aga, inga avvikande/skiftande f¨arger i menyn, samt sm˚a konsisa ikoner som l¨att beskriver vad de kan t¨ankas anv¨andas till.
5.1 Slutsats
Arbetet har utf¨orts efter planering och st¨amt ¨overens med de tider som planer- ades i b¨orjan av arbetet, detta med h¨ansyn till de omst¨allnationer som kr¨avts p˚a grund av Covid-19 pandemin. De m˚al som satts har arbetats efter och har d¨armed uppfyllts, och de tester som var uppsatta har genomf¨orts p˚a f¨ardig produkt i den m˚an som varit m¨ojlig. I sin helhet s˚a ¨ar jag v¨aldigt n¨ojd med uppstart, genomf¨orandet och resultat.
Referenser
[1] Henning Heitk¨otter, Herbert Kuchen, and Tim A. Majchrzak. Extending a model-driven cross-platform development approach for business apps. Sci- ence of Computer Programming, 97:31 – 36, 2015. Special Issue on New Ideas and Emerging Results in Understanding Software.
[2] Henning Heitk¨otter, Sebastian Hanschke, and Tim A. Majchrzak. Evaluat- ing cross-platform development approaches for mobile applications. In Jos´e Cordeiro and Karl-Heinz Krempels, editors, Web Information Systems and Technologies, pages 120–138. Springer Berlin Heidelberg, 2013.
[3] Venkata N. Inukollu, Divya D. Keshamoni, Taeghyun Kang, and Manikanta Inukollu. Factors influencing quality of mobile apps: Role of mobile appde- velopment life cycle. CoRR, abs/1410.4537, 2014.
[4] Jakob Nielsen. Usability Engineering. Morgan Kaufman, San Francisco, 1993.
[5] Max. What Makes A Great Mobile App? https://www.weebpal.com/
blog/what-makes-great-mobile-app, bes¨okt augusti 2020.
[6] Bj¨orn Olsson. Porting an ios application to the android os platform. Mas- ter’s thesis, Linn´euniversitetet. Institutionen f¨or datavetenskap, fysik och matematek, 2011.
[7] Sandeep Yadav. What is the future of cross plat-
form app development? https://www.quora.com/
What-is-the-future-of-cross-platform-app-development, bes¨okt augusti 2020.
[8] Apple. iOS Design Themes. https://developer.apple.com/design/
human-interface-guidelines/ios/overview/themes/, bes¨okt augusti 2020.
[9] Apple. App Review. https://developer.apple.com/app-store/
review/, bes¨okt augusti 2020.
[10] Android. Design for Android. https://developer.android.com/design, bes¨okt augusti 2020.
