WEBBASERAD SMARTPHONE-APPLIKATION SOM ALTERNATIV TILL INDUSTRIHANDDATOR

Transkript

1 WEBBASERAD SMARTPHONE-APPLIKATION SOM ALTERNATIV TILL INDUSTRIHANDDATOR INOM LAGERARBETE Examensarbete Systemarkitekturutbildningen Niklas Johansson Johannes Sundqvist VT 2013:KSAI05

2 Systemarkitekturutbildningen är en kandidatutbildning med fokus på programutveckling. Utbildningen ger studenterna god bredd inom traditionell program- och systemutveckling, samt en spets mot modern utveckling för webben, mobila enheter och spel. Systemarkitekten blir en tekniskt skicklig och mycket bred programutvecklare. Typiska roller är därför programmerare och lösningsarkitekt. Styrkan hos utbildningen är främst bredden på de mjukvaruprojekt den färdige studenten är förberedd för. Efter examen skall systemarkitekter fungera dels som självständiga programutvecklare och dels som medarbetare i en större utvecklingsgrupp, vilket innebär förtrogenhet med olika arbetssätt inom programutveckling. I utbildningen läggs stor vikt vid användning av de senaste teknikerna, miljöerna, verktygen och metoderna. Tillsammans med ovanstående teoretiska grund innebär detta att systemarkitekter skall vara anställningsbara som programutvecklare direkt efter examen. Det är lika naturligt för en nyutexaminerad systemarkitekt att arbeta som programutvecklare på ett stort företags IT-avdelning, som en konsultfirma. Systemarkitekten är också lämpad att arbeta inom teknik- och idédrivna verksamheter, vilka till exempel kan vara spelutveckling, webbapplikationer eller mobila tjänster. Syftet med examensarbetet på systemarkitekturutbildningen är att studenten skall visa förmåga att delta i forsknings- eller utvecklingsarbete och därigenom bidra till kunskapsutvecklingen inom ämnet och avrapportera detta på ett vetenskapligt sätt. Således måste de projekt som utförs ha tillräcklig vetenskaplig och/eller innovativ höjd för att generera ny och generellt intressant kunskap. Examensarbetet genomförs vanligen i samarbete med en extern uppdragsgivare eller forskningsgrupp. Det huvudsakliga resultatet utgörs av en skriftlig rapport på engelska eller svenska, samt eventuell produkt (t.ex. programvara eller rapport) levererad till extern uppdragsgivare. I examinationen ingår även presentation av arbetet, samt muntlig och skriftlig opposition på ett annat examensarbete vid ett examinationsseminarium. Examensarbetet bedöms och betygssätts baserat på delarna ovan, specifikt tas även hänsyn till kvaliteten på eventuell framtagen mjukvara. Examinator rådfrågar handledare och eventuell extern kontaktperson vid betygssättning. BESÖKSADRESS: JÄRNVÄGSGATAN 5 POSTADRESS: ALLÉGATAN 1, BORÅS TFN: E-POST: INST.HIT@HB.SE WEBB:

3 Svensk titel: Webbaserad smartphone-applikation som alternativ till industrihanddator Engelsk titel: Web-based smartphone application as an alternative to an EDA Utgivningsår: 2013 Författare: Niklas Johansson, Johannes Sundqvist Handledare: Patrik Hedberg Vi vill börja med att tacka Patrik Hedberg för att ha handlett oss genom förvirring och oklarhet och fått oss att ifrågasätta vårt arbete ur alla tänkbara perspektiv. Vi vill tacka Fredrik Dahlberg och Mathias Söderqvist för väl genomförd opponering med nyttig feedback och goda synpunkter kring förbättring. Vi vill tacka Anders Gidenstam för en noggrann och detaljerad granskning av vår rapport. Slutligen vill vi tacka Pulsen Production AB som bidragit med ett intressant problemområde och därmed höjt arbetets relevans avsevärt. Niklas och Johannes III

4 Abstract The study examined the possibility of replacing an existing Enterprise Digital Assistant solution with a web-based smartphone application by developing and evaluating a prototype according to requirements set by an external constituent. Current smartphone development frameworks were examined, focusing on enterprise oriented, web-based applications. The Personal Digital Assistant is considered obsolete and has been replaced by smartphones with higher performance and better functionality. An Enterprise Digital Assistant is a related device with a more robust design that has been equipped with peripherals such as a barcode scanner. When considering cross-platform development for smartphones, there are a number of possible approaches. However, it s unclear if they are suitable for replacing an EDA. The study is conducted in collaboration with an external constituent to find an alternative to their current EDA solution. The existing solution possesses a number of problems and developers have issues in development due to the outdated platform. The study's overall research question was based on whether it was technically possible to replace the EDA with a Web-based smartphone application. In a case study with a Design Science approach, information was gathered about what functionality would be needed and how this could be achieved. Specific requirements were established during an initial meeting where the current solution was described together with general desires regarding the results of the study. Afterwards, a study tour was held with a user of the current solution to further establish the functional requirements and most important operations of the device. Based on the requirements, a set of evaluation criteria was formed and related to previous research on evaluation of handheld devices. After the development of the prototype, a demonstration was held for the previously mentioned user, followed by a unstructured interview investigating perceived areas of use and improvement. Finally, the prototype was evaluated according to the set of criteria previously formed, answering the study s main research question and demonstrating its viability. The study concluded that it is technically possible to replace an EDA solution with a web-based smartphone application based on the criteria developed by the requirements of the constituent. The solution consists of a set of hybrid frameworks and plugins for developing mobile web applications with support for bar code scanning. The study acts as decision support in further development for the constituent, Pulsen Production AB, on how they are to manage development of mobile devices in connection with the information system Harmoney. Furthermore, the study's contribution could be of interest to other types of companies and individuals that target cross-platform development or the mobile web. Keywords: Enterprise digital assistant, Personal digital assistant, Cross platform, Smartphone, Mobile Web IV

5 Sammanfattning Studien undersökte möjligheten att ersätta en befintlig industrihanddatorlösning med en webbaserad smartphone-applikation genom att ta fram och utvärdera en utvecklingsbas enligt krav och önskemål från en extern uppdragsgivare. Befintliga utvecklingsramverk till smartphones har undersökts med fokus på företagsnära webbaserade applikationer. Den traditionella handdatorn anses föråldrad och har ersatts av moderna smartphones med högre prestanda och bättre funktionalitet. En variant av handdatorn är industrihanddatorn som har en mer robust konstruktion och har försetts med extrautrustning som t.ex. streckkodsläsare. När det gäller plattformsoberoende utveckling till smartphones finns idag en mängd olika alternativ och angreppssätt, dock är det oklart ifall de går att använda för att ersätta en industrihanddator. Arbetet i denna studie har utförts i anslutning till en extern uppdragsgivare med önskemål om att hitta ett alternativ till deras befintliga industrihanddatorlösning. Den befintliga lösningen besitter ett antal problem samtidigt som utvecklare inte kommit vidare på grund av den föråldrade plattformen. Studiens övergripande frågeställning grundade sig på om det var tekniskt möjligt att ersätta en industrihanddator med en webbaserad smartphone-applikation. I en fallstudie med ett Design Science-angrepp fastställdes vilken funktionalitet som skulle behövas och hur det kunde uppnås. Specifika önskemål och krav fastställes under ett uppstartsmöte där man beskrev den befintliga lösningen och vad som önskades med studien. Därefter utfördes ett studiebesök hos användare av det befintliga systemet för att vidare fastställa applikationens krav och viktigaste operationer. Utifrån krav och önskemål utformades utvärderingskriterier som relaterades till tidigare forskning kring kravställning för handhållna enheter. Utifrån krav och önskemål utformades utvärderingskriterier som relaterades till tidigare forskning kring kravställning för handhållna enheter. Baserat på kravställningen utformades en utvecklingsbas utifrån vilken en prototyp implementerades som proof-of-concept. Efter avslutad implementation demonstrerades prototypen för tidigare nämnd användare varpå en öppet riktad intervju inleddes för att utreda synpunkter kring användningsområde och förbättring. Slutligen utvärderades utvecklingsbasen enligt de kriterier som tidigare tagits fram för att återknyta till den övergripande forskningsfrågan och påvisa studiens genomförbarhet. Utifrån studiens resultat drogs slutsatsen att det är tekniskt möjligt att ersätta en industrihanddatorlösning med en webbaserad smartphone-applikation baserat på de kriterier som utformats från uppdragsgivarens krav och önskemål. Lösningen består av en uppsättning hybrida ramverk och plugins för utveckling av mobila webbapplikationer med stöd för streckkodsläsning. Studien bidrar med ett underlag till beslut om vidare utveckling inom Pulsen Production AB och hur dessa ska hantera mobila enheter i koppling till affärssystemet Harmoney. Studiens bidrag kan vara av intresse för andra typer av företag och personer som inriktar sig på plattformsoberoende utveckling eller den mobila webben. Nyckelord: Industrihanddator, Handdator, Plattformsoberoende, Smartphone, Webbutveckling V

6 Innehållsförteckning 1.1 Introduktion Problemformulering Forskningsfrågor Avgränsning Bidrag Intressenter Etiska aspekter Disposition Enheter och hårdvara PDA EDA Smartphone Streckkodsläsare Protokoll och standarder XML XSD Web Service Google Web Toolkit Request Factory Smartphoneutveckling Plattformar Plattformsoberoende Virtuell maskin Webbutveckling Hybrida ramverk Relaterat arbete och tidigare forskning Ramverk för utvärdering av handhållna enheter Business Insider - HTML5 vs. native apps for mobile Utvärdering av utvecklingstekniker och -ramverk Designforskning Forskningsstrategier Metodaktiviteter Kunskapskaraktärer Funktionalitet i existerande mjukvara Sammanställning Utvärderingskriterier Rhodes av RhoMobile Phonegap av Adobe Titanium av Appcelerator Delresultat - Sammanställning av ramverk Val av utvecklingsbas PhoneGap och GWT Installation och konfiguration av ramverk Analys Design av domänobjekt Utformning av gränssnitt Utveckling av prototyp Delresultat Entry-point MovePanel Streckkodsläsning via kamera VI

7 VII 8.1 Demonstration av prototyp för användare Analys av utvecklingsbas enligt utvärderingskriterier Vad som uppnåtts Konsekvenser Giltighet Upprepningsbarhet Representativitet Reliabilitet Validitet Alternativ metod Vidareutveckling Figurlista Tabellförteckning Installation och konfiguration Ramverk Eclipse, GWT, Android Mgwt PhoneGap gwt-phonegap BarcodeScanner RequestFactory RequestFactory ArticleRequestFactory ArticleServiceLocator ArticleService Article ArticleProxy Klassdiagram

8 1 Inledning Kapitlet ger en kort introduktion till studiens inriktning och presenterar därefter studiens disposition 1.1 Introduktion En handdator (PDA, Personal Digital Assistant) är en typ av enhet som tidigare använts flitigt inom affärsverksamhet för att underlätta rutiner och arbetssysslor genom att erbjuda funktionalitet som anteckningar, röstinspelning, kalender och adressbok såväl som körning av lättare mjukvara och utförande av andra dagliga arbetsuppgifter (Freudenrich och Carmack 2013). Den vanliga handdatorn anses vara föråldrad och ersatt av smartphones p.g.a dess högre prestanda och bättre funktionalitet (Smith och Wempen 2011). En variant av handdatorn är industrihanddatorn (EDA, Enterprise Digital Assistans) som fortfarande används inom tyngre industri, exempelvis lagerarbete. Industrihanddatorn är byggd som en mer robust variant av den vanliga handdatorn, ofta försedd med extrautrustning som t.ex. streckkodsläsare för att underlätta relaterade rutinuppgifter (ICP-Deutschland, 2012). Då kraven på tålighet påverkar enhetens storlek och vikt kan den vid lättare användning kännas bitvis otymplig och överflödig. Även med tanke på de relativt höga priset på industrihanddatorer kan det vara intressant att utforska andra alternativ. Den globala användningen av smartphones ökar och beräknas under 2013 uppgå till i 1,4 miljarder (Pramis 2013) samtidigt som den mobila internetanvändningen ökar i rask takt (Meeker och Wu 2013). Med tanke på att smartphones ersatt den vanliga handdatorn och att webbaserade smartphone-applikationer är ett kostnadseffektivt sätt att utveckla till flera hårdvaruplattformar (Satani 2013) är det intressant att utforska om det med webbaserade smartphone-applikationer går att replikera industrihanddatorfunktionalitet. 1.2 Problemformulering Studiens utförare kom i kontakt med Pulsen Production AB i syfte att se över deras befintliga industrihanddatorlösning för lagerarbete i affärssystemet Harmoney. Kontakten initierades med ett uppstartsmöte under vilket de centrala problempunkterna för uppdragsgivaren uttalades. Dels nämndes påtryckningar från användare kring vidareutveckling av den befintliga lösningen samt att utvecklare ansåg att de i dagsläget sitter fast i utveckling på grund av användande av föråldrad hårdoch mjukvara. Här fanns en önskan om att komma vidare i utveckling i en ny miljö som inte låser utvecklarna till en specifik plattform Forskningsfrågor Då webbaserad smartphone-utveckling är ett kostnadeffektivt sätt att uppnå plattformsoberoende (Satani 2013) har denna typ av applikationer ansetts mest intressant att utforska. Valet av utveckling med webbaserad teknologi leder tillsammans med ovanstående problemformulering till följande frågeställning: Är det tekniskt möjligt att ersätta en industrihanddatorlösning i ett lagerarbetsflöde med en webbaserad smartphone-applikation? o Vilka tekniska krav ställs på lösningen? o Vilken teknologi finns tillgänglig vid utvecklingen? o Hur kan en realisering utföras i praktiken? - 1 -

9 1.3 Avgränsning Studien har vid utförandet fokuserat på att ta fram en artefakt i form av en alternativ utvecklingsbas som ger utvecklare möjlighet att skriva mjukvara till mobila enheter utan att lösningen är låst till en specifik plattform. Utifrån utvecklingsbasen implementerades en prototyp som ett proof-of-concept i syfte att demonstrera utvecklingsbasens tekniska möjligheter och studiens genomförbarhet. Således har användbarhet, säkerhet och prestanda av prototypen lämnats utanför studiens inriktning. 1.4 Bidrag Studien demonstrerar potentialen i de tekniker och ramverk som finns tillgängliga vid utveckling av webbaserade smartphone-applikationer. Specifikt bidrar studien till ökad förståelse för uppdragsgivarens befintliga problemsituation vilket tillsammans med lösningsförslaget bildar ett underlag för vidare beslutsfattande inom organisationen. 1.5 Intressenter Studien riktar sig främst mot utvecklare av webbaserade applikationer för handhållna enheter med krav på hårdvaruaccess. Även utvecklare med generellt intresse för plattformsoberoende kan ha nytta av denna rapport då flera av de tillvägagångssätt och tekniker som presenteras kan vara av nytta i liknande situationer. Studien riktar sig specifikt till de utvecklare och beslutsfattare på Pulsen Production AB som är berörda av problematiken i den befintliga industrihanddatorlösningen. 1.6 Etiska aspekter Då Pulsen Production AB i samband med sina kunder hanterar känslig data som kan påverka kundernas konkurrenskraft på marknaden har utförarna inte kunnat lämna ut information som kan identifiera och/eller skada de kunder och personer som studien varit i kontakt med. Således har denna typ av information utelämnats från rapporten. 1.7 Disposition Kapitel 1 Inledning ger en kort introduktion och presenterar studiens upplägg. Kapiter 2 Bakgrund presenterar den externa kontakt och uppdragsgivare studien har haft i sitt utförande. Kapitel 3 Teori går igenom underliggande teori och tidigare arbeten relaterade till studiens inriktningutvecklingsramverk, tidigare forskning och relaterat arbete. Kapitel 4 Metod redovisar studiens centrala forskningsstrategi, utförda aktiviteter och nyttjade metoder. Kapitel 5 Kravställning presenterar hur studiens krav och kriterier på artefakten fastställts. Kapitel 6 Tillgänglig teknologi presenterar tillgänglig teknologi för utveckling samt föreslagen utvecklingsbas. Kapitel 7 Implementation presenterar utveckling av prototypen. Kapitel 8 Demonstration och utvärdering återger resultat från demonstration av prototyp och utvärdering av utvecklingsbas. Kapitel 9 Slutsats presenterar studiens slutsatser. Kapitel 10 Diskussion återger en följande diskussion efter genomförande av studie. Kapitel 11 Referenser återger de källor och referenser som använts i studien samt en figurlista över rapportens figurer

10 2 Bakgrund Kapitlet presenterar den externa kontakt och uppdragsgivare studien har haft i sitt utförande Pulsen Production AB är ett IT-företag beläget i Borås och ett dotterbolag till Pulsen Data AB. Med ca 450 anställda, belägna i Sveriges större städer, Göteborg, Karlstad, Stockholm, Trollhättan och Malmö, är Pulsen Data AB ett av Sveriges äldsta IT-företag, grundat Pulsen Production AB erbjuder tjänster inom drift och distanshandel och levererar innovativa och skräddarsydda IT-baserade lösningar inom dessa segment. Pulsen Production AB levererar en egenutvecklad produkt, kallat Harmoney, som med fokus på detalj- och distanshandel hanterar stora datavolymer och säljs som en paketerad tjänst till Pulsens kunder. Tjänstefierandet innebär att Pulsen paketerat drift av system, utrustning och säkerhet tillsammans med Harmoney för en trygg och stabil lösning för deras kunder. Harmoney presenteras grafiskt som en desktopapplikation i en Windows-miljö, utvecklat i programmeringsspråket C#. Harmoneys kärna bygger på Linux DB2 i en stordatormiljö, körandes på IBM Z-servers. Lösningen bidrar till en stabil kärna tillsammans med ett modernt gränssnitt som kan hantera en stor mängd data för många kunder i olika delar av detalj- och distanshandelssegmentet. Harmoney levererar affärsmoduler inom dels ekonomi, inköp och lager. Detta innebär bland annat lagerföring av artiklar, bokföring av fakturor och leveranser via olika distributörer. Figur 2.1 redovisar mer detaljerat hur Harmoneys olika affärsmoduler struktureras. Figur 2.1 Harmoney affärsmoduler Studiens utförare kom i kontakt med Pulsen Production AB i syfte att se över deras industrihanddatorlösning i det lagerflöde som ingår i Harmoneys lagermodul. Industrihanddatorerna körs på Windows-plattform av typen Windows Mobile 6.5 till vilken programvaran är bunden. Utveckling sker även här i programmeringsspråket C#, dock existerar ett antal problem vid användande och vidareutveckling av mjukvara. I syfte att undersöka problemen och möjligheten för uppdragsgivaren att vidareutveckla existerande mjukvara inleddes ett projekt i vilket denna studie kommer att fungera som beslutsunderlag för vidare utveckling

11 3 Teori Kapitlet går igenom underliggande teori och tidigare arbeten relaterade till studiens inriktning 3.1 Enheter och hårdvara PDA En handdator (PDA, Personal Digital Assistant) är en mobil enhet som erbjuder funktioner för lättare arbetssysslor i det vardagliga arbetslivet (Freudenrich och Carmack 2013). Exempel på sådana funktionaliteter är anteckningar, röstinspelning, kalender och adressbok samt körning av lättare mjukvara. En stor andel handdatorer har möjlighet att ansluta till Internet via WiFi, de har ofta en stor skärm i jämförelse med äldre mobiltelefoner och vissa av dem har pekskärm (ICP-Deutschland, 2012). Trots detta anses handdatorer vara föråldrade i och med smartphone-telefoners högre prestanda och funktionalitet (Smith och Wempen 2011)och snabba tillväxt på marknaden (Pramis 2013). Handdatorer med Windows-plattform kör Windows Mobile ovanpå Windows CE-kärna (ICP- Deutschland, 2012). Windows Mobile var Microsofts huvudsakliga plattform för mobila enheter fram till lansering av Windows Phone7 under Senaste versionen av Windows Mobile är 6.5 och släpptes år EDA Industrihanddatorn (EDA, Enterprise Digital Assistant) är en vidareutveckling av den vanliga handdatorn och är en mer robust enhet med extra funktionalitet som exempelvis RFID- (Radiofrequency Identification), streck- och magnetkortsläsare. Dessa enheter används ofta inom affärsinriktade områden där denna funktionalitet krävs (ICP-Deutschland, 2012). Industrihanddatorer finns till olika plattformar och likt handdatorer kan applikationer och funktionalitet utvecklas till industrihanddatorer på Windows-plattformar genom Windows Mobile 6.5 (Enterprise digital assistant - Wikipedia, 2013) Smartphone En smartphone är en mobil enhet med ett mobilt operativsystem som ofta har högre funktionalitet och prestanda än en vanlig mobiltelefon. Redan de första smartphone-enheterna kombinerade funktionaliteten från vanliga handdatorer och mobiltelefoner. Med utökad funktionalitet som multitouch-pekskärm, högupplöst kamera/videokamera, GPS-navigation, mediaspelare och inbyggda webbläsare (Smartphone - Wikipedia, 2013) ses smartphone som en kraftfull konkurrent på den mobila marknaden vilket även syns i den mobila användningen på webben (Meeker och Wu 2013). Den snabba utvecklingen av marknaden för appar och den mobila handeln har varit starka drivkrafter i utbredningen av smartphones. Den globala försäljningen av smartphones överskred den vanliga mobiltelefonförsäljningen tidigt under 2013 (3 Newz NZ 2013) och sedan 18 juli 2013 står iphone och Android för 90% av den globala marknadsandelen (theguardian.com 2013) Streckkodsläsare Streckkoder är ett vanligt sätt att representera en identifierande sträng genom en fysisk bild innehållande data. Som exempelvis artiklar i ett lager och lagerplatsen i sig kan identifieras med hjälp av streckkoder. För att läsa streckkoder används olika sorters läsare, butiker kan ha en fysiskt dedikerad läsare kopplad till ett kassasystem, lagerpersonal kan använda någon form av mobil enhet, likt en EDA, kopplat till ett affärssystem

12 En streckkodsläsare nyttjar en teknik i form av en kombinerad lins och ljussensor som översätter optiska impulser till elektroniska. De elektroniska impulserna översätts till data som sedan skickas via läsarens utdataport. (Barcode reader Wikipedia, 2013) 3.2 Protokoll och standarder XML extensible Markup Language (XML) är ett märkspråk som definierar en uppsättning regler för att koda dokument i ett format som är läsbart av både människor och maskiner. Språket är definierat i XML 1.0 Specification (W3C 2008) samt flera andra öppna standarder. Målet vid skapandet av XML var att betona enkelhet, generalitet och användbarhet över Internet. Det är ett textbaserat dataformat med starkt stöd för världens språk via Unicode. Även om utformningen främst fokuserar på dokument används XML för att representera godtyckliga datastrukturer, t.ex. Web Services. Många ramverk har utvecklats för att underlätta hanteringen av XML-data och flera schema-system finns för att underlätta definitionen av XML-baserade språk XSD Ett XML-schema är en beskrivning över en sorts XML-dokument som vanligtvis uttrycks i termer av begränsningar på dokumentets struktur och innehåll utöver de grundläggande begränsningar som finns i XML. Dessa begränsningar uttrycks oftast med en kombination av grammatiska regler rörande ordningen på element, booleska predikat som innehållet måste uppfylla, datatyper för innehåll och attribut samt mer specifika regler som unikhet och begränsningar på referentiell integritet. Till skillnad från de flesta andra XML-scheman designades XML Schema Definition (W3C 2012) med avsikten att validering av XML skulle producera en samling information som ansluter till specifika datatyper. En sådan informationsmängd kan vara användbar vid utveckling av mjukvara för hantering av XML-dokument Web Service En Web Service är ett sätt för elektroniska enheter att kommunicera över World Wide Web, bestående av mjukvarufunktionalitet som tillhandahålls via en webbadress. W3C (2004) definierar en Web Service som: Ett mjukvarusystem designat för att stödja interoperabel maskin-till-maskin-interaktion över ett nätverk. Det har ett gränssnitt beskrivet i ett maskinläsbart formats (specifikt WSDL.) Andra system interagerar med Web Servicen på ett sätt ordinerat av beskrivningen med SOAP-meddelanden, vanligvis förmedlade över HTTP med XMLserialisering i samband andra Web-relaterade standarder. 3.3 Google Web Toolkit Google Web Toolkit (GWT) är ett ramverk skapat för att underlätta utveckling av webbapplikationer. GWT tillåter utveckling av användargränssnitt och logik i Java och kompilerar sedan koden till HTML, JavaScript och CSS vilket i sin tur körs i en webbläsare. Fördelen med att använda GWT är att en mängd optimeringar utförs automatiskt som är svåra att utföra manuellt, och att flera versioner kompileras specifikt till varje webbläsare för att garantera att applikationen ser likadan ut överallt. Detta ger utvecklaren möjlighet att förbise funktionalitetsbrister i de olika webbläsarna, vilket i många fall annars kan vara tidskrävande och kostsamt (GWTProject.org, 2013)

13 3.3.1 Request Factory RequestFactory är ett vanligt sätt att få GWT-klienten som körs i webbläsaren att kommunicera med Java-servicear på Host-maskinen. Då klienten skrivs i Java är det en fördel att kunna skicka och ta emot Java-objekt till och från den. Med RequestFactory specificeras ett gränssnitt som kapslar in de objekt applikationen ska kunna hantera, och sedan byggs nödvändig kod automatiskt vid kompileringstillfället. Här görs optimeringar genom att RequestFactory håller koll på vilka ändringar som görs i objektet och endast skickar deltan. Det är även en fördel att få tillgång till asynkrona anrop utan att behöva skriva egen JavaScript/AJAX-hantering för detta (RequestFactory - GWTProject.org, 2013). 3.4 Smartphoneutveckling Att utveckla direkt mot en smartphone-plattform görs via plattformens specifika mjukvaruutvecklingsverktyg (SDK), s.k. native-utveckling. SDKerna nås genom olika programmeringsspråk för de olika plattformarna och hanterar koden på olika sätt för att uppnå t.ex rendering av objekt och inmatningshantering. För att utveckla en applikation till flera plattformar med native-utveckling krävs det att man skriver en separat version av applikationen till varje specifik plattform (Heitkötter et al. 2012) Plattformar I dagsläget finns tre stora aktörer som med sina respektive mobila plattformar har störst andel av marknaden. Dessa tre är Google med Android, Microsoft med Windows Phone samt Apple med iosenheter. Det finns även andra aktörer som tillsammans står för en mindre del av marknaden, presenterade i delkapitlet Övriga plattformar nedan. Andriod Google lanserade år 2007 en beta-version av sin Linux-baserade mobila plattform Android (Chitu, 2007). År 2008 lanserades operativsystemet kommersiellt och sedan dess har många telefonleverantörer anslutit sig till Google och Android. I och med att plattformen är öppet tillgänglig för utvecklare finns ett enormt utbud av applikationer som nås via Google Play. Nuvarande version av Android är Jelly Bean 4.3 (Android.com 2013) Utveckling till plattformen Android görs med programmeringsspråket Java via Android SDK som erbjuder åtkomst till enhetens funktionalitet och hårdvara (developers.android.com 2013). ios Apples mobila enheter kör på ios-operativsystemet och likt Android finns här ett stort utbud av applikationer tillgängliga via Apples AppStore. Apple är till skillnad från Google hårda med kraven på de applikationer som laddas upp på AppStore, och för att kunna lansera sina applikationer som utvecklare krävs ett visst medlemskap med en årlig avgift (developer.apple.com 2013). Nuvarande version ios 6. Applikationer utvecklas till ios i Apples egna programmeringsspråk, Objective C. Windows Phone Windows Phone lanserades av Microsoft år 2010 då de lanserade Windows Phone 7. Nuvarande version Windows Phone 8. Applikationer till Windows Phone utvecklas i programmeringsspråket C# (.NET) (developer.windowsphone.com 2013) och som till ios-enheter, krävs för Windows Phone-utveckling ett visst medlemskap

14 Övriga plattformar De mindre aktörerna utgjorde tillsammans under Q mindre än 5% av marknadens sålda enheter (icharts.net, 2013). Bland dessa aktörer finns t ex det kanadensiska Research In Motion s BlackBerry, Nokias Symbian och Linux-baserade plattformar (bortsett från Android). Relativt nyligen slog sig Mozilla in på marknaden med sin webbaserade plattformslösning FirefoxOS, då de i februari 2013 lanserade version 1.0 ( 2013) Plattformsoberoende I och med de många plattformarna och utvecklingen på marknaden (Koetsier, 2013) är det önskvärt att utveckla till samtliga målplattformar utan att behöva skriva specifik kod till enskilda plattformar, så kallad plattformsoberoende utveckling. Det finns olika tekniker att använda sig av för att utveckla plattformsoberoende applikationer Virtuell maskin Java och programmeringsspråken inom.net-familjen, såsom Visual Basic och C#, använder sig av en teknik för att kompilera till olika plattformar, kallat virtuella maskiner. Konceptet innebär att kod kompileras till ett intermediärt språk, ofta bytekod, som den virtuella maskinen översätter till målplattformens specifika maskinkod (Bazzi, 1997). Språken använder olika kompilerare för att uppnå detta resultat. Javas Java Virtual Machine (JVM) interpreterar bytekod till plattformsspecifik maskinkod som värddatorns operativsystem kan tolka och exekvera (Daly, et al., 2001). Figur 3.1 visar kortfattat hur Java nyttjar en virtuell maskin, JVM, på olika plattformar. Figur 3.1 Java Virtual Machine - 7 -

15 På liknande sätt kompileras kod skriven i.net till plattformsspecifik kod för värddatorn genom att koden översätts till Common Intermediate Language (CIL-kod) via en språkspecifik kompilerare. CILkoden översätts sedan av en virtuell maskin - Common Language Runtime (CLR) - till den plattformsspecifika maskinkoden (Box och Sells, 2002), vilket presenteras i Figur 3.2. Figur 3.2.NET Common Language Runtime Webbutveckling Via HTML, CSS och Javascript, s.k. webbutveckling, kan man låta smartphone-enhetens webbläsare sköta rendering och hantering av indata. Då webben i dagsläget är högt standardiserad hanterar de flesta webbläsarna objekt på liknande vis vilket ger en relativt enhetlig design till många plattformar. Dock saknar denna teknik stöd för åtkomst av enheternas hårvara så som kamera och GPS (Heitkötter et. al. 2013) Hybrida ramverk För att lösa bristen på tillgång till hårdvarufunktionalitet, med bibehållen webbteknik, framkom hybrida tillvägagångssätt som en kombination av webbtekniker och native-utveckling (Heitkötter et. al. 2012). Hybrida ramverk ger utvecklare möjligheten att via ett API kapsla in native-funktionalitet i en webbaserad lösning

16 3.5 Relaterat arbete och tidigare forskning Ramverk för utvärdering av handhållna enheter Economides och Nikolaou (odat.) presenterar ett ramverk för utvärdering av handhållna enheter för mobil inlärning. Ramverket består av ett antal kriterier som täcker områdena användbarhet, tekniska och funktionella krav. Användbarhetskrav Användbarhetsområdet är indelat i fyra kravgrupper: Användargränssnitt, Presentation och media, Navigation och Fysiska krav. 1. Under kategorin Användargränssnitt finns t.ex. punkter för lättanvända menyer, knappar och andra grafiska komponenter samt lämplig och effektiv layout av dessa. Kategorin innefattar även flerspråkighet och stöd för personer med funktionsnedsättning. 2. Kategorin Presentation och media, behandlar i stort sett multimedia och att kunna läsa och skriva, spela in och spela upp data med lätthet och stöd för många olika multimediaformat i hög kvalitet. 3. Navigation handlar i huvudsak om hur operativsystemets gränssnitt är organiserat med hänsyn till filstruktur och mappar samt tillgång till funktionalitet som , sms och samtal. 4. De fysiska kraven täcker storlek, vikt och design och om enheten är estetiskt tilltalande. Tekniska krav Området för tekniska krav är indelat i fem grupper: Prestanda, In- och utmatning, Kompatibilitet, Säkerhet samt Tillgänglighet, pålitlighet och underhållbarhet 1. Under Prestanda finns krav på processor, RAM, utbytbar lagring och kommunikation som Bluetooth, Wi-Fi, GPS och telefoni. 2. In- och utmatning behandlar enhetens gränssnitt i form av bildskärm, högtalare, mikrofon, kamera, pekskärm, tangentbord, GPS, RFID- och streckkodsläsare. 3. Under Kompatibilitet behandlas stöd för mjukvara med öppen källkod, olika operativsystem och webbläsare. 4. Säkerhet täcker krav på certifikat, kryptering, anti-virus, lösenordskydd och låsning av skärm. 5. Tillgänglighet, pålitlighet och underhållbarhet tar upp batteritid, hantering och återhämtning av fel, lätthet att uppgradera/uppdatera enheten online samt teknisk support och dokumentation. Funktionella krav Området för funktionalitet behandlar krav under fyra grupper: Kommunikation, Information och kunskap, Organisation och förvaltning samt Underhållning och nöje. 1. Under Kommunikation finns krav på telefoni, e-post, web, chat, videokonferens, fax, m.m. 2. Information och kunskap täcker diktafon, redigering och kontorsprogram, kalkylator, ljud, bild, fotografier, konvertera text till tal och vice versa, fildelning, lexikon och översättning. 3. Organisation och förvaltning behandlar klocka, kalender, påminnelser och databashantering. 4. Under Underhållning och nöje finns spel, musik och film

17 3.5.2 Business Insider - HTML5 vs. native apps for mobile Ballve och Lee (2013) skriver i Business Insider en artikel om HTML5 och mobil utveckling till specifika plattformar, så kallad native-utveckling. De drar jämförelser mellan de båda teknikerna inom olika områden såsom prestanda, utveckling och förekomst på nätet. Att utveckla native-applikationer kommer enligt Ballve och Lee med en rad fördelar såsom direkt åtkomst till enheternas hårdvara samt den medärvda prestanda som kommer av att köra en applikation som är utvecklad och anpassad för en specifik plattform. Dock besitter HTML5 fördelar som Ballve och Lee förutspår med tiden kommer vara till dess fördel. Dessa fördelar innefattar främst kostnadseffektiviteten vid utveckling av webbapplikationer; att bara behöva skriva applikationen en gång oavsett hur många målplattformar det finns Utvärdering av utvecklingstekniker och -ramverk Heitkötter et al. (2012) utvärderar teoretiskt i en rapport tre tekniker för utveckling av plattformsoberoende applikationer för mobila enheter. Utvärderingen syftar till att utifrån ett antal kriterier och punkter fastställa teknikernas egenskaper, styrkor och svagheter. Teknikerna de utvärderar är en renodlad webbapplikation med en kombination av HTML, CSS och Javascript/JQuery Mobile, en hybridlösning med hjälp av ramverket Phonegap och till sist en fristående runtime-miljö i form av Titanium. Rapporten bedömer teknikerna utifrån ett antal kriterier gällande infrastruktur och utveckling, presenterade i tabell 3.1. Tabell 3.1 Värderingskriterier Heitkötter et. al Kriterietyp Kriterier Infrastruktur Licenskostnad Plattformssupport Stöd för plattformsspecifik funktionalitet Långsiktigt stöd och vidareutveckling (support, community etc) Utseende & Känsla Prestanda Distribution av applikationer Utveckling Utvecklingsmiljö Design av användargränssnitt Enkelhet vid utveckling Underhåll Skalbarhet Vidare utvecklingsmöjligheter Snabbhet och kostnad vid utveckling Efter genomförd utveckling av en applikation med hjälp av de tre ovan nämnda teknikerna ställs de mot ovanstående kriterier varpå en diskussion följer i rapporten. Heitkötter et al. (2012) drar sedan slutsatsen att utveckling till mobila enheter görs lättast med hjälp av det hybrida utvecklingsramverket PhoneGap

18 4 Metod Kapitlet redovisar studiens centrala forskningsstrategi, utförda aktiviteter och nyttjade metoder 4.1 Designforskning Principer och riktlinjer för utförandet av studien har hämtats ur Design Science Primer som redogör för ett ramverk av aktiviteter för problemformulering, kravhantering, utveckling av artefakt, demonstration och utvärdering (Johannesson och Perjons, 2012): Design science is the study of artefacts in an intentional context. More precisely, design science is the study of artefacts and their environment as they are developed and used by people with the goal of solving practical problems. Studies in this field do not only answer knowledge questions but also develop solutions to practical problems. Figur 4.1 illustrerar arbetsflödet i Design Science. Figur 4.1 Design Science flöde Forskningsstrategier Johannesson och Perjons (2012) förklarar att man i de olika aktiviteterna kan använda sig av olika forskningsstrategier, t.ex. kan krav insamlas i en fallstudie medan utvärdering kan utföras med hjälp av ett experiment. Studiens utförare anser att hela studien är utförd som en fallstudie där målet varit att i detalj beskriva uppdragsgivarens problemsituation och hur ett förslag till lösning tagits fram Metodaktiviteter Enligt Johannesson och Perjons (2012) har de flesta studier inte som mål att genomföra samtliga metodaktiviteter på djupet. Istället får ett fåtal aktiviteter fokus och övriga utförs endast ytligt. I den här studien har kravställning och utveckling av artefakt haft huvudfokus följt av en lättare demonstration och utvärdering för att återkoppla till den övergripande frågeställningen och påvisa studiens genomförbarhet. Kravställning Genom intervjuer, gruppdiskussioner och observationer undersöktes uppdragsgivarens befintliga lösning i syfte att fastställa nuvarande problembild. I samband med detta dokumenterades krav och önskemål på studiens artefakt vilka tillsammans med problemen omvandlades till kriterier för utvärdering av denna

19 Förutsättningar för artefakt Utifrån kravställningen inleddes en dokumentstudie i tidigare arbeten och publicerat material. Efter att ha presenterat en tänkbar utvecklingsbas som artefakt utfördes installation och konfiguration. Design och utveckling av prototyp Efter utförd installation och konfiguration inleddes design och utveckling av prototypen. Demonstration av prototyp och utvärdering av artefakt Demonstration av prototypen genomfördes under ett möte med en användare av den befintliga industrihanddatorlösningen. Med hjälp av en öppet riktad intervju utvanns ett antal potentiella användningsområden och förbättringspunkter hos prototypen. Resultatet från kravställningen användes sedan för att utvärdera artefakten utefter satta kriterier och återkoppla till studiens övergripande forskningsfråga. 4.2 Kunskapskaraktärer Studiens forskningsfrågor kan anses ge såväl karaktäriserande som vägledande och prospektiv kunskap. I tabell 4.1 ställs respektive forskningsfråga mot den kunskapskaraktär som frågan avser. Tabell 4.1 Kunskapskaraktärer Forskningsfråga Kundskapskaraktär Kan man ersätta en industrihanddatorlösning i ett lagerarbetsflöde med en webbaserad smartphone-applikation? Prospektiv kunskap o o Vilka tekniska krav finns på lösningen? Vilken teknologi finns tillgänglig vid utvecklingen? Karaktäriserande kunskap o Hur kan en realisering utföras i praktiken? Vägledande kunskap Kunskapskaraktäriseringen baseras på Göran Goldkuhls publicering Kunskapande (2011). Den kunskap som utvinns genom att svara på studiens övergripande forskningsfråga klassas som prospektiv kunskap eftersom den används till att utreda hur en framtida situation skulle kunna hanteras genom att ta fram en artefakt. De karaktäriserande frågorna besvaras under studiens inledande kravställning där krav och önskemål från uppdragsgivare inhämtas och utvärderingskriterier fastställs samt under en följande dokumentstudie där befintliga utvecklingsramverk sammanställs och jämförs. Vägledande kunskap fås genom att förslag ges på hur en webbaserad smartphone-applikation enligt kravspecifikationen kan utvecklas

20 5 Kravställning Kapitlet presenterar hur studiens krav och kriterier på artefakten fastställts I syfte att reda ut de problem Pulsen Production AB själva anser existerar i den befintliga industrihanddatorlösningen i Harmoneys lagerflöde initierades ett uppstartsmöte med ett antal personer ur Pulsens personalstyrka. Det talades här om användarupplevelser av lösningen hos befintliga kunder samtidigt som det fokuserades till stor del på vidareutveckling av mjukvara. Följande punkter kunde konstateras: Användare av de handhållna enheterna anser att programvaran varken är användarvänlig eller intuitiv. Användare anser att utförande av vissa operationer tar lång tid p.g.a gränssnittet. Användare anser att programvara behöver utökas med ny funktionalitet. Den nuvarande mjukvaran är tung att köra och tar lång tid att uppdatera på enheten. Utvecklare sitter låsta i utveckling på grund av den föråldrade plattformen. Mötet kom sedan in på uppdragsgivarens önskemål om att utföra ett förändringsarbete utifrån ovan nämnda punkter. Intresset från uppdragsgivarens sida i utförande av en studie skulle höjas om ett delresultat av studien skulle komma att vara någon form av prototyp. Prototypen i sig skulle implementera ett givet flöde i den redan existerande mjukvaran till de handhållna enheterna. Diskussionen ledde till ett antal förutsättningar och önskemål på utförandet för ett sådant arbete. Uppdragsgivarens kunder har många användare och hög omsättning på dessa varpå en eventuell applikation måste påvisa intuitivitet och användarvänlighet och samtidigt vara lättarbetad. Det finns en ovilja att på nytt låsa utvecklingen till en specifik plattform. Det finns en ovilja att modifiera redan befintlig logik i Harmoneys datalager. Utifrån ovanstående förutsättningar och önskemål kunde det fastställas att ett utvecklingsarbete av en prototyp med nutida utvecklingsramverk skall utföras. Kraven på prototypen fokuserar på att inte låsa sig till en specifik plattform samt att kunna återanvända befintlig logik och funktionalitet i Harmoneys datalager. 5.1 Funktionalitet i existerande mjukvara I syfte att utöka erhållen information från uppstartsmötet anordnades ett besök hos en av de kunder som använder den befintliga industrihanddatorn inom lagerarbete med e-handelssystemet Harmoney. Vid besöket fanns möjlighet att initialt studera enheten i några av företagets vanligaste arbetsflöden. Här kunde streckkodsläsning fastställas som handdatorns mest nyttjade hårdvarufunktion. Besöket resulterade i utpekande av Lagerflytt som det flöde prototypen skulle komma att implementera. I detta flöde används scanning av streckkoder för att mata in och söka på lagerartiklar registrerade i Harmoney. Lagerplatser är i detta flöde ytterligare en entitet som skall hanteras och kunna matas in via sträckkodsläsning. Det korta flödet fungerar enligt följande:

21 1. Inmatning av Lagerartikelvariant via streckkodsläsare. 2. Sökning i Harmoney på angiven lagerartikelvariant i ett givet fysiskt lager. 3. Resultatlista presenteras, innehållande lagerplatser där aktuell lagerartikelvariant finns. 4. Flytta på angiven lagerartikelvariant till valfri lagerplats genom att läsa in den nya lagerplatsens streckkod via handdatorns streckkodsläsare. Systemet Harmoney mottager denna information och uppdaterar data i realtid i berörda databastabeller. 5.2 Sammanställning I denna del av kapitlet sammanfattas den information som utvunnits vid de två olika tillfällen beskrivna ovan. Önskemål och krav sammanställs i Tabell 5.1 tillsammans med närmast relaterade kravområde ur ramverket som presenteras av Economides och Nikolaou (odat.). Tabell 5.1 Önskemål och krav på funktionalitet hos utvecklingsbasen Önskemål, krav och funktionalitet Område - Typ Användarvänligt och intuitivt gränssnitt Användbarhet Användargränssnitt Ovilja att låsa sig till ny hårdvaruplattform Tekniskt Kompatibilitet Vanligaste operation: Scanning av streckkoder Tekniskt In- och utmatning Lätt att utföra mjukvaruuppdateringar, klient/server-separation. Tekniskt Tillgänglighet, pålitlighet och underhållbarhet Ett utpekat flöde: Lagerflytt Funktionellt 5.3 Utvärderingskriterier Utifrån sammanställningen ovan förs här ett resonemang kring de olika kravens relevans i förhållande till dess kravområde och studiens avgränsningar. Då användbarhet ligger utanför studiens inriktning tas det inte upp som ett eget utvärderingskriterie för prototypen. Däremot kan kravet från uppdragsgivaren om ett användarvänligt och intuitivt gränssnitt konverteras till ett semitekniskt krav för utvecklingsbasen och relateras till ett av kriterierna hos Economides och Nikolaou (odat.) för användbarhet i användargränssnitt. Detta innebär att stöd ska inkluderas för lättanvända menyer, knappar och andra grafiska komponenter men att lämplig och effektiv layout av dessa inte tas upp. Det funktionella kravet om Lagerflytt som utpekat arbetsflöde för implementation skall endast användas som riktlinje under utveckling av prototypen och kommer inte användas som kriterie vid utvärdering. Detta leder till följande utvärderingskriterier: Finns lättanvända komponenter tillgängliga vid utformning av användargränssnitt? Sker utveckling på ett plattformsoberoende vis? Finns fungerande streckkodsläsare? Finns fungerande klient/server-kommunikation?

22 6 Tillgänglig teknologi Kapitlet presenterar tillgänglig teknologi för utveckling. 6.1 Rhodes av RhoMobile Motorola, genom Rhodes, erbjuder ett OpenSource-ramverk för att skapa plattformsoberoende lösningar. Detta uppnås m.h.a. Ruby, HTML5 och CSS. RhoMobile erbjuder ett antal komponenter anpassade för företagsoperativa lösningar för handhållna enheter. Rhodes kompilerar Ruby-kod till Ruby 1.9 byte-kod, som sedan interpreteras genom den virtuella maskinen YARV (Yet Another Ruby VM) på mobila enheter (Morin, 2013). För hårdvaruaccess krävs tillgång till målplattformarnas native SDK. Inbyggt i Rhodes API finns sedan möjlighet att via kameran läsa sträckkoder. De plattformar detta ramverk utger sig för att stödja är Windows Embedded Handheld, Windows CE, Windows Phone 7 Series, Apple ios, Android och BlackBerry. (Motorola Solutions 2013) 6.2 Phonegap av Adobe Figur 6.1 PhoneGaps plattformstillgänglighet PhoneGap är en OpenSource-baserad multiplattformslösning som kapslar in webbkomponenter i form av HTML5, CSS och JavaScript i ett projekt och till det erbjuder en rad trejdepartsutvecklade plugins för att ge applikationen tillgång till den handhållna enhetens hårdvara. Pluginen är plattformsspecifikt utvecklade men helheten i PhoneGap ger en plattformsoberoende lösning då den, beroende på vilken plattform som används, använder tillhörande specifikt plugin. De plattformar Adobe och PhoneGap stödjer är bland andra ios, Android, Windows Phone, webos, Symbian och Blackberry. Figur 6.1 sammanställer nuvarande status i PhoneGap s mobila hårdvarustöd fördelat per plattform. PhoneGap-applikationer tillåts att testas direkt på den handhållna enheten och samtidigt erbjuds en moln-tjänst för kompilering och paketering av applikationer. Moln-tjänsten tar in AppStore-färdiga applikationer (ioss AppStore, Androids GooglePlay etc.) och kompilerar dessa till enheter med rätt funktionalitet för den specifika enhetens plattform. (Adobe Inc. 2013)

23 6.3 Titanium av Appcelerator Appcelerator tillhandahåller ramverket Titanium vilket är ett designorienterat utvecklingsramverk som ger företagsnära funktionalitet till mobila enheter. Genom JavaScript och Titaniums egna SDK ges funktionalitet till de största plattformarna ios, Windows, Android och HTML5. Figur 6.2 Titaniums arkitektur Utvecklare erbjuds via Titaniums API att inkludera logik och data i kombination med ett JavaScriptbaserat gränssnitt paketerat med Titaniums motor. Vid körning skapar motorn sedan native-objekt utifrån interpreterad JavaScript-kod visualiserat i Figur 3.4 vilket ger applikationen ett mer plattformsspecifikt utseende (Appcelerator, 2013). Titaniums SDK använder sedan specifika API för enheters respektive plattformar (Appcelerator docs, 2013). Likt PhoneGap nyttjar Titanium tredjepartsutvecklade plugins och moduler för läsning av streckkoder. Heitkötter et. al. (2012) definierar i sin rapport inte Titanium som en hybrid-lösning utan som en fristående runtime-miljö för plattformsoberoende applikationsutveckling. Vi har ändå valt att presentera Titanium då det enligt rapporten är en av de stora konkurrenterna på marknaden för plattformsoberoende utveckling till mobila enheter

24 6.4 Delresultat - Sammanställning av ramverk Funktionalitet och tillvägagångssätt gällande utveckling av ovan nämnda ramverk sammanställs i Tabell 6.1. PhoneGap Javascript/HTML/ CSS Titanium Titanium SDK / Javascript Webbaserad. Nyttjande av plattformsspecifika plugins för hårdvaruaccess. Titanium SDK. Specifika API för specifik plattform. Tabell 6.1 Sammanställning av ramverk Ramverk Utveckling Plattformsoberoende teknik Rhodes Ruby/HTML/CSS Interpretering av Ruby 1.9 byte-kod via YARV- VM. Barcodestöd Ja. Rhodes API + native SDK. Ja. Tredjepart plugins och moduler. Ja. Tredjepart plugins och moduler. OpenSource Ja Ja Ja Mobila plattformar Windows Embedded Handheld, Windows CE, Windows Phone 7 Series, ios, Android, BlackBerry. ios, Android, Windows Phone, webos, Symbian, BlackBerry. ios, Windows, Android, HTML5 6.5 Val av utvecklingsbas Efter genomförd efterforskning av möjliga utvecklingsalternativ har studien valt att fokuserat på utveckling av prototyp med hjälp av PhoneGap. Som grund för utvecklingen av webbapplikationen valdes Google Web Toolkit (GWT). Valet har påverkats av utförarnas tidigare erfarenheter av utveckling i Java och att GWT anses vara ett lätt sätt att åstadkomma snygg och enhetlig design med hög funktionalitet inom språket. Att sedan använda PhoneGap för att nå de handhållna enheternas hårdvara är det alternativ som efter tidigare analys av befintliga ramverk ansågs vara mest fritt, flexibelt och användbart för studien. Beskrivning av hur dessa ramverk kombineras i ett utvecklingsarbete av mobila applikationer följer nedan. I Figur 6.3 visas en överblick av den slutgiltiga konfigurationen PhoneGap och GWT mgwt De grafiska komponenter som finns att tillgå i GWT är tänkta att användas till användargränssnitt utformade för arbetsstationer. Även om applikationen är webbaserad behöver gränssnittet för användbarhetens skull fungera på samma sätt som i enheten i vanliga fall. mgwt är en samling smartphone-anpassade GUI-komponenter som går att använda istället för eller tillsammans med de tillgängliga komponenterna i GWT. Ramverket är skapat av Daniel Kurka och finns tillgängligt på Google Code

25 gwt-phonegap För att kunna använda funktionaliteten PhoneGap erbjuder i GWT behövs Java-kod som kapslar in anropen till de JavaScript-anrop som senare ska köras på enheten. Ramverket är skapat av Daniel Kurka och finns tillgängligt på Google Code. BarcodeScanner Streckkodsläsare som tredjepartsplugin finns skapad av Jayson Raymond, uppladdad på GitHub (2013). Pluginet använder sig av ett native-bibliotek till respektive plattform (Android och ios) och en wrapper i form av ett JavaScript-API som kapslar in och abstraherar funktionaliteten. ZXing - Android APK Som native-version för Android behövs biblioteket ZXing läggas till i det Android-specifika PhoneGapprojektet. Vid utförandet av studien verkar det finnas två alternativ, via Intent eller med källkod. Fördelen med att använda Intents är att installation och uppdatering av streckkodsläsaren sker automatiskt och med prydlig presentation. Fördelen med att använda källkod är att funktionaliteten går att modifiera. Biblioteket är skapat av Sean Owen och finns tillgängligt på Google Code (2013). GWT-BarcodeScanner Eftersom PhoneGap drivs av JavaScript från webbapplikationen behövs ett sätt att kunna skriva kod i GWT som efter kompilering (till Javascript) kan anropa PhoneGap. Streckkodsläsaren är inget undantag och även här krävs lite extra kod skapad av Jayson Raymond, uppladdad på BitBucket (2013). PhoneGap Android APK GWT+RequestFactory mgwt gwt-phonegap Java GWT BarcodeScanner HTML + JS + CSS barcodescanner.js ZXing Figur 6.3 Överblick av setup Då applikationen skrivs i Java finns stöd för en mängd tredjepartstillverkade bibliotek. Lösningen resulterar i en plattformsoberoende webbanpassad applikation för smartphone-enheter baserat på ett populärt objektorienterat programmeringsspråk

26 6.6 Installation och konfiguration av ramverk Utvecklingen i detta arbete utfördes i huvudsak m.h.a färdiga tredjepartsramverk. Andelen egenskriven kod är marginell och majoriteten av utvecklingstiden har därför gått åt till att installera och konfigurera ramverken. Nedan listas den mjukvara och ramverk som använts. Eclipse, GWT, Android mgwt PhoneGap gwt-phonegap BarcodeScanner RequestFactory Studiens kompletta tillvägagångssätt vid installation och konfiguration av ramverk återges i appendix i syfte att ge utvecklare möjlighet att replikera studiens utveckling av prototypen

27 7 Implementation Kapitlet presenterar studiens slutsatser 7.1 Analys Efter utförd installation av utvecklingsmiljö påbörjades utvecklingen av prototypen. För att öka förståelsen för prototypens önskade funktionalitet granskades flödet Lagerflytt mer grundligt. Flödet startas med att bakomliggande databas mottager som inparameter vilket lager handenheten används på samt en lagerartikel, dess färg och storlek. Lagerartikeln tillsammans med dess färg och storlek utgör vad Pulsen kallar lagerartikelvariant. Utifrån denna kombination utförs en sökning i databasen som returnerar en lista av lagerplatser där lagerartikelvarianten ligger. Lagerplatsen innehåller information om bl.a. hur många av efterfrågad lagerartikelvariant som finns på platsen. Utifrån resultatet väljs önskad lagerplats för flytt samt antalet lagerartikelvarianter som skall flyttas. Användaren får därefter ange en destinationslagerplats till vilken lagerartikelvarianten flyttas. Denna information skickas sedan till databasen varpå en uppdatering utförs. Nedan listade objekt identifierades under analysen. Lager Lagerplats Lagerartikel(variant) I dagsläget sker kommunikation mellan Harmoney-databas och handhållna enheter via direktexekvering av operationer i systemets datalager. För kommunikation mellan prototyp och Harmoney krävdes en webbservice (se kap ) med möjlighet att exekvera motsvarande operationer i datalagret. All kommunikation mellan webbservices och Harmoney sker med hjälp av XML (se kap ). När webbservicen för det specifika flödet var uppsatt kontrollerades detta manuellt för att säkerställa funktionaliteten. Det manuella arbetet resulterade i fyra olika XML-filer, två stycken in-xml- samt två stycken ut-xml-filer: sökning, söksvar, update, update-svar. Nedan ser vi ett exempel på en in-xml för sökning. <?xml version="1.0" encoding="iso "?> <Data> <Trans> <Appl/> <AnvBehgId/> </Trans> <Sty> <!-- Autentisering --> </Sty> <LagArt> <LagId /> <LagArtNr /> <LagAttr1 /> <LagAttr2 /> </LagArt> </Data>

28 7.2 Design av domänobjekt Utifrån ovan nämnda XML-filer genererades ett XSD-schema (se kap ) som definierar XMLfilerna. XSD-schemat möjliggör automatiskt skapande av Java-klasser för att representera XML-data av rätt struktur i projektet. För att slutföra kontakten med Harmoney och därmed uppfylla full flödesfunktionalitet i applikationen behövde instanser av dessa klasser skapas med data för att utvinna rätt funktionalitet i Harmoneys datalager. En webbservice-koppling krävdes mellan prototyp och webbservice som sedan anropas med de instansierade klasserna som utvunnits från XML och dess XSD-schema. Datan i returen från webbservice-anropet utgjorde sedan underlag för att skapa nya instanser av Javaklasserna som i sin tur användes i applikationen. 7.3 Utformning av gränssnitt Skisser för användargränssnittet utformades för handhållna enheter. Resultatet av detta blev två skisser över de olika stadierna i flödet. Nedanstående bilder representerar första stadiet där användaren har scannat in en lagerartikelvariant och fått tillbaka svar innehållande ett antal lagerplatser: SearchPanel och ResultPanel, Figur 6.2. Nästa stadie representeras i flödet där användaren valt kombination av lagerartikelvariant, lagerplats och antal lagerartiklar att flytta för att sedan scanna in ny destinationslagerplats för flytten, MovePanel, Figur 6.3. Figur 7.1 GUI: SearchPanel och ResultPanel Figur 7.2 GUI: MovePanel

29 7.4 Utveckling av prototyp Då logiken för hantering av lagerartiklar ligger centralt i Harmoneys datalager krävdes liten implementering av logik i prototypen. Fokus hamnade därför på att utveckla prototypens användargränssnitt och de vyer som flödet krävde för uppfylld funktionalitet. Prototypens klassdiagram presenteras i studiens tillhörande appendix. Utveckling av prototypens användargränssnitt gjordes med hjälp av GWT kombinerat med mgwt vilket skrivs och utvecklas i programmeringsspråket Java. Biblioteken erbjuder effektiva moduler och element som snabbt möjliggör en snygg, användarvänlig och enhetlig design. mgwt-biblioteket kapslar in gwt-komponenter och lägger på ett designskikt som är anpassad för mobila enheter. mgwt anammar olika design för olika plattformar. Således ser applikationen något olika ut beroende på vilken plattform den körs på utan att funktionaliteten ändras. Nedan följer ett par skärmdumpar över den designmässiga utkomsten av prototypen på plattformarna Android samt ios. Resultatet av implementerad prototyp skiljer sig från det uppskissade användargränssnittet då mer flexibla komponenter i utvecklingsramverken används i implementationen. 7.5 Delresultat Nedan följer skärmdumpar från körning av den färdiga prototypen, startskärmen för Android i Figur 6.4 respektive ios i Figur 6.5, MovePanel för Android i Figur 6.6 respektive ios i Figur 6.7 samt slutligen streckkodsläsning med Android i Figur Entry-point Figur 7.3 Android: SearchPanel & ResultPanel Figur 7.4 ios: SearchPanel & ResultPanel

30 7.5.2 MovePanel Figur 7.5 Android: MovePanel (med siffertangentbord) Figur 7.6 ios: MovePanel Streckkodsläsning via kamera Figur 7.7 Android: BarcodeScanning

31 8 Demonstration och utvärdering Kapitlet presenterar studiens slutsatser 8.1 Demonstration av prototyp för användare Vid ett avslutande återbesök hos den tidigare besökta kunden demonstrerades prototypen. Därefter hölls en öppet riktad intervju för att tillgodogöra synpunkter och idéer kring användningsområde och vidare utveckling av prototypen. Fördelar/förbättringsområden: Att utnyttja gester för att lätt kunna växla mellan olika lägen istället för att behöva använda industrihanddatorns pekpenna. Stöd för extern handhållen streckkodsläsare istället för smartphone-enhetens inbyggda kamera t.ex. Ring Scanner (via Bluetooth) Att kunna zooma och låsa skärmens orientering för att underlätta inläsning vid rutinarbete. Anpassade färgscheman Minimera antal tryck och användarinvolvering i syfte att optimera arbetsflöde och minimera risk för handhavandefel. Sammanfattande ansåg användaren att en smartphone-lösning liknande prototypen skulle vara ett användbart komplement till deras nuvarande industrihanddatorlösning. 8.2 Analys av utvecklingsbas enligt utvärderingskriterier För att återkoppla till studiens tidigare uppsatta kriterier och krav på utvecklingsbasen följer nedan en argumentation kring dessa kriterier. Finns lättanvända komponenter tillgängliga vid utformning av användargränssnitt? Studiens inriktning har ej innefattat utveckling av ett användarvänligt gränssnitt. Huvudfokus har därför inte lagts på att utforma gränssnitt utifrån befintliga riktlinjer gällande användarvänlighet. Dock finns tillgång till grafiska moduler och komponenter som behövs för att utforma ett intuitivt och användarvänligt gränssnitt i de ramverk och plugins som nyttjats. Sker utveckling på ett plattformsoberoende vis? Då utvecklingsbasen är en hybridlösning skrivs applikationer i första hand som webbapplikationer där hårdvarufunktionalitet görs tillgänglig genom PhoneGap. Vid utförandet av studien inkluderade inte PhoneGap en färdig streckkodsläsare, däremot fanns möjlighet att tillhandahålla egenskrivna tredjepartsmoduler. Detta innebär att det för varje målplattform krävs en plattformsspecifik kodmodul för streckkodsläsning. Implementation av detta utgör dock en engångskostnad som inte påverkar utveckling av applikationer i övrigt vilket betyder att utveckling som helhet sker på ett plattformsoberoende vis. Finns fungerande streckkodsläsare? PhoneGaps struktur och arkitektur för hantering av hårdvaruaccess kräver en del plattformsspecifik tillämpning och anpassning för olika plattformar. Utvecklingsbasen har främst riktat sig mot Androidplattformen då utförarna ej haft möjlighet att uppfylla de krav Apple och Windows ställer på utveckling av mobila applikationer till dessa plattformar. Således har prototypen enbart implementerats med fungerande streckkodsläsning för plattformen Android

32 Finns fungerande klient/server-kommunikation? För att uppfylla kriteriet var tanken att en fullständig koppling mellan klient och server skulle upprättas varpå ett fullständigt flöde mot bakomliggande logik i Harmoneys datalager skulle genomföras. På grund av uppdragsgivarens interna IT-arkitektur innefattande brandväggar och dylikt kunde detta inte utföras inom tidsramen för studien. Utvecklingsbasen uppfyller dock kriteriet på en teoretisk nivå genom stöd för XML, XSD samt Web Service-anslutning. Tabell 7.1 Sammanställning av kriterier och prototypens uppfyllnadsgrad. Tabell 8.1 Resultat från utvärdering av utvecklingsbas Kriterier Uppfyllnadsgrad (Ja/Nej) Finns lättanvända komponenter tillgängliga vid Ja. utformning av användargränssnitt? Sker utveckling på ett plattformsoberoende vis? Ja. Finns fungerande streckkodsläsare? Ja. Finns fungerande klient/server-kommunikation? Ja

33 9 Slutsatser Kapitlet presenterar studiens slutsatser Baserat på kravställningen utformades en utvecklingsbas utifrån vilken en prototyp implementerades som proof-of-concept. Efter avslutad implementation demonstrerades prototypen för tidigare nämnd användare varpå en öppet riktad intervju inleddes för att utreda synpunkter kring användningsområde och förbättring. Slutligen utvärderades utvecklingsbasen enligt de kriterier som tidigare tagits fram för att återknyta till den övergripande forskningsfrågan och påvisa studiens genomförbarhet. Utifrån studiens resultat drogs slutsatsen att det är tekniskt möjligt att ersätta en industrihanddatorlösning med en webbaserad smartphone-applikation baserat på de kriterier som utformats från uppdragsgivarens krav och önskemål. Lösningen består av en uppsättning hybrida ramverk och plugins för utveckling av mobila webbapplikationer med stöd för streckkodsläsning. 9.1 Vad som uppnåtts Studien presenterar ett antal tekniker och ramverk som finns tillgängliga för utveckling av plattformsoberoende smartphone-applikationer med stöd för enheters hårdvara och demonstrerar därigenom teknikens potential. Förståelse för uppdragsgivarens befintliga problemsituation har utökats vilket tillsammans med lösningsförslaget bildar ett underlag för vidare beslutsfattande inom organisationen

34 10 Diskussion Kapitlet återger en diskussion efter genomförandet av studien 10.1 Konsekvenser Studiens inriktning har enbart lett till utvärdering av en utvecklingsbas och därmed påvisat studiens genomförbarhet. Studien påvisar inte att den framtagna utvecklingsbasen är optimal. För uppdragsgivaren innebär det att studien enbart kan användas som referens i en eventuell förstudie vid införande av ny teknik för utveckling till mobila enheter Giltighet Upprepningsbarhet Studiens upprepningsbarhet evalueras utifrån möjligheter för andra utvecklare att återanvända studiens tillvägagångssätt för att lösa problem av liknande karaktär. I och med studiens detaljerade beskrivning av installation och tillvägagångssätt under genomförandet anses lösningen i hög grad vara replikerbar Representativitet Studiens representativitet anger huruvida slutsatserna är generaliserbara. I och med att studiens huvudsakliga forskningsstrategi baserats på en fallstudie anses slutsatserna inte vara generaliserbara. Om kontexten man vill generalisera till däremot liknar den där studien utförts är sannolikheten större att slutsatserna även är liknande Reliabilitet Studiens reliabilitet värderar tillförlitligheten i datainsamling och analys. De olika insamlingsmetoder som nyttjats ger studien en varierande reliabilitet. I de intervjuer som förts har antalet intervjuade varit lågt vilket resulterar i en låg reliabilitet. Den dokumentstudie som utförts för att samla information om befintliga ramverk och utvecklingstekniker har i första hand riktats mot tillförlitliga källor i form av förstapartsdokumentation vilket anses ge dessa delar högre reliabilitet. I de fall tredjepartsinformation nyttjats är reliabiliteten självklart lägre. Även reliabiliteten i observationer som utförarna gjort kan ifrågasättas då delaktigheten under utvecklingen har påverkat resultatet Validitet Studiens validitet beskriver i sammanhanget hur pass bra och korrekta de valda kriterierna är för utvärderingen av artefakten. Med hänsyn till studiens inriktning i relation till de kriterier som fastställs av Economides och Nikolaou (odat.) anses studiens kriterier vara relevanta och ha god spridning inom ramen för dess avgränsningar Alternativ metod Som alternativ till studiens centrala forskningsmetod hade aktionsforskning kunnat användas. Aktionsforskning beskrivs enligt Höst et. al. (2006) som en primär metod för utredning och lösning av problem av praktisk karaktär. Metoden syftar till att förbättra något under tiden man studerar det och är indelad i en planeringsfas, handlingsfas och utvärderingsfas. Utifrån ett studerat problem tas i planeringsfasen ett lösningsförslag fram. Handlingsfasen utgör sedan studiens genomförande varpå man i en utvärderingsfas observerar resultatet av utförd handling. Aktionsforskning kan genomföras iterativt i syfte att vidare förbättra resultatet i varje iteration och hitta förbättringsområden och kan även användas i samband med Design Science. På

35 grund av aktionsforskningens fokus på konsekvenser för organisation och användare istället för fokus på själva artefakten har utförarna valt att använda sig av riktlinjer knutna till Design Science med en övergripande fallstudie som metod Vidareutveckling Med tanke på den snäva utvecklingsperioden under genomförandet och implementationen av prototypen finns i gränssnittet utrymme för förbättring ur ett användbarhetsperspektiv. Genom att utföra ytterligare en iteration med fokus på design och innehåll i prototypen, samt att få applikationen att koppla korrekt till affärssystemet Harmoney, hade dessa punkter kunnat förbättras avsevärt. I samband med detta kan man låta en större grupp användare göra en ny utvärdering av applikationen för att få en bättre uppfattning av dess funktionalitet och användningsområde. Vidare hade det varit intressant att utföra ett utvecklingsprojekt i en liknande situation baserat på en annan uppsättning utvecklingsramverk än den studien tagit upp. En sådan studie skulle kunna jämföra funktionalitet, påvisa för- och nackdelar, styrkor och svagheter och svårighet vid installation, i förhållande till den kombination av ramverk och plugins som aktuell studie har nyttjat. I samband med detta skulle det också vara intressant att alternera problemsituationen i syfte att påvisa lösningens flexibilitet och mångsidighet. Som vidare utveckling på studiens prototyp ses intresse av att kunna ansluta och använda extern hårdvara som till exempel fysisk streckkodsläsare via Bluetooth. Självklart önskas i framtiden även bättre stöd för åtkomst av hårdvara direkt genom webbteknik som HTML och W3Cs Device APIs

36 11 Referenser Kapitlet återger de källor och referenser studien nyttjat samt en figurlista över rapportens figurer Bazzi, I., Cross Platforms Issues in Software Design and Development: A Case Study of AthenaMuse 2, Boston: Massachusetts Institute of Technology. Box, D. och Sells, C., Essential.Net: The Common Language Runtime. 1 red. United States: Addison -Wesley Professional Daly, C., Horgan, J., Power, J. och Waldorn, J., Platform Independent Dynamic Java Virtual Machine Analysis: the Java Grande Forum Benchmark suite. Proceedings of the 2001 joint ACM- ISCOPE conference on Java Grande, pp Economides, A. och Nikolaou, N. (odat.) Evaluation of Handheld Devices for Mobile Learning, International Journal of Engineering Education Heitkötter, H. Hanschke,S. and Majchrzak,T. (2012) Evalutation Cross-Plattform Development Approaches for Mobile Applications, WEBIST (Selected Papers), pp Höst et. al. 2006, Att genomföra examensarbete, ISBN p1:4 Lantz, A. 1993, Intervjumetodik, Studentlitteratur, Lund. Smith A och Wempen F 2011 CompTIA Strata Study Guide, ISBN News NZ Smartphones now outsell 'dumb' phones - Story - Technology - 3 News. (Elektronisk) Tillgänglig: tabid/412/articleid/295878/default.aspx ( ). Android.com Jelly Bean Android Developers. (Elektronisk) Tillgänglig: ( ). Approaches for Mobile Applications (Elektronisk) Tillgänglig: publications/heitkoetter/evaluating-cross-platform-development-approaches-for-mobile- Applications.pdf ( ). Ballve M och Lee T The Future Of Mobile Development: HTML5 Vs. Native Apps Business Insider (Elektronisk) Tillgänglig: ( ). Develop Android Developers (Elektronisk) Tillgänglig: ( ). Firefox OS, Marketplace mozilla.org (Elektronisk) Tillgänglig: ( )

37 Getting Started with RequestFactory - Google Web Toolkit Google Developers (Elektronisk) Tillgänglig: ( ). Getting Started with RequestFactory - Google Web Toolkit Google Developers Available at: [Accessed 15 May 2013] GettingStarted - gwt-phonegap - Getting started - A GWT Wrapper for the Phonegap JS Library - Google Project Hosting Available at: [Accessed 15 May 2013] GettingStarted - mgwt - Getting Started with mgwt - Mobile GWT - Google Project Hosting Available at: [Accessed 15 May 2013] Goldkuhl, G. 2011, Kunskapande, Linköping: Linköpings och Stockholms universitet. Google Groups (Elektronisk) Tillgänglig: ( ). Google Launches Android, an Open Mobile Platform. Chitu Google Launches Android, an Open Mobile Platform. (Elektronisk) Tillgänglig: ( ). Google USB Driver Android Developers (Elektronisk) Tillgänglig: ( ). GWT Project GWT Project RequestFactory. (Elektronisk) Tillgänglig: ( ). GWT Project GWT Project. (Elektronisk) Tillgänglig: ( ). ICP-Deutschland (Elektronisk) Tillgänglig: ( ). JaysonRaymond/BarcodeScanner GitHub (Elektronisk) Tillgänglig:: ( ). John Wiley and Sons p. 140 jraymond40 / barcode-gwtphonegap-plugin Bitbucket (Elektronisk) Tillgänglig: ( ). Johannesson, P. och Perjons, E. (2012) A Design Science Primer. (Elektronisk) Tillgänglig: ( )

38 Koetsier 2013 Windows Phone jumps to third in global smartphone market share and could be second faster than you think (Elektronisk) Tillgänglig: ( ). Meeker och Wu Internet Trends Kleiner Perkins Caufield Byers. (Elektronisk) Tillgänglig: ( ). Mono, Mono -.NET Framework Architecture. (Elektronisk) Tillgänglig: ( ). Morin M, YARV Yet Another Ryby VM. (Elektronisk) Tillgänglig: ( ). Motorola Solutions Rhodes (Elektronisk) Tillgänglig: ( ). Oracle.com Learn about Java Technology. (Elektronisk) Tillgänglig: ( ). PhoneGap Home (Elektronisk) Tillgänglig: ( ). PhoneGap API Documentation (Elektronisk) Tillgänglig: ( ). Pramis, J Worldwide smartphone usage will reach 1.4 billion this year Digital Trends. (Elektronisk) Tillgänglig: / ( ). Satani The Future of Mobile HTML5 vs. Native Apps Conduit Blog. (Elektronisk) Tillgänglig: ( ). Titanium Documentation (Elektronisk) Tillgänglig: ( ). W3C W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures. (Elektronisk) Tillgänglig: ( ). Wikipedia Barcode reader - Wikipedia, the free encyclopedia. (Elektronisk) Tillgänglig: ( ). Wikipedia Enterprise digital assistant - Wikipedia, the free encyclopedia. (Elektronisk) Tillgänglig: ( ). Wikipedia Smartphone - Wikipedia, the free encyclopedia. (Elektronisk) Tillgänglig: ( )

39 Windows Phone Dev Center (Elektronisk) Tillgänglig: ( ). Worldwide Smartphone Market 2013 icharts (Elektronisk) Tillgänglig: ( ) Figurlista Figur 2.1 Harmoney affärsmoduler Figur 3.1 Java Virtual Machine Figur 3.2.NET Common Language Runtime Figur 4.1 Design Science flöde Figur 6.1 PhoneGaps plattformstillgänglighet Figur 6.2 Titaniums arkitektur Figur 6.3 Överblick av setup Figur 7.1 GUI: SearchPanel och ResultPanel Figur 7.2 GUI: MovePanel Figur 7.3 Android: SearchPanel & ResultPanel Figur 7.4 ios: SearchPanel & ResultPanel Figur 7.5 Android: MovePanel Figur 7.6 ios: MovePanel Figur 7.7 Android: BarcodeScanning Figur 12.1 GUI: Exempel med TapHandler Tabellförteckning Tabell 3.1 Värderingskriterier Heitkötter et. al Tabell 4.1 Kunskapskaraktärer Tabell 5.1 Önskemål och krav på funktionalitet hos utvecklingsbasen Tabell 6.1 Sammanställning av ramverk Tabell 8.1 Resultat från utvärdering av utvecklingsbas

40 12 Appendix Kapitlet presenterar ett appendix av betydelse för studien men som hamnat utanför rapporten 12.1 Installation och konfiguration Ramverk Mjukvara och ramverk som använts: Eclipse, GWT, Android mgwt PhoneGap gwt-phonegap BarcodeScanner RequestFactory Eclipse, GWT, Android Eclipse användes som utvecklingsmiljö i detta arbete främst p.g.a. sitt starka stöd för Googles plugins. Eclipse installerades enligt följande steg: Gå till och ladda ned Eclipse Classic. Packa upp på valfritt ställe på hårddisken. Eftersom Eclipse körs direkt ur mappen behövdes ingen särskild installation genomföras. Vid första uppstart angavs var kodprojekt skall sparas. Plugins installerades på höljande sätt: Klicka på Help > Install New Software... Fyll i Work with: och klicka på Add... Fyll i namn (t.ex. Google) och tryck på OK. Eclipse hämtade tillgängliga plugins från adressen. Följande plugins valdes: Developer Tools > Android Development Tools Google Plugin for Eclipse (required) > Google Plugin for Eclipse 4.2 SDKs > Google Web Toolkit SDK NDK Plugins > Android Native Development Tools Eclipse installerade angivna paket. Vid eventuella förfrågningar om att installera mjukvara med osignerat innehåll valdes OK. Efter installationen behövde Eclipse startas om

41 Installationen av GWT verifierades efter att Eclipse startat om: Klicka på File > New > Other... (Ctrl + N) Välj Google > Web Application Project och tryck på Next > Vid eventuell förfrågan om brandvägg, välj Tillåt. Fyll i projekt- och paketnamn (t.ex. MyGwtApp och my.gwt.app). Kryssa ur Use Google App Engine. Tryck Finish. Eclipse skapade ett exempelprojekt som kördes genom att: Högerklicka på projektet och välj Run As > Web Application. Efter att servern startats visades adressen där webbapplikationen ligger. Adressen följdes för att verifiera installationen Mgwt mgwt är en samling GWT-komponenter utformade för att användas i smartphones. Detta möjliggör utveckling av webbapplikationer som ser ut och fungerar som smartphone-appar. mgwt installerades genom att: Gå till Ladda ner den senaste versionen av mgwt.jar och spara på hårddisken. I Eclipse: Högerklicka på projektet och välj Build Path > Configure Build Path... Under Libraries, välj Add External JAR... Navigera till mgwt.jar och tryck Open För att kunna använda mgwt i GWT inkluderades modulen: Öppna MyGwtApp.gwt.xml under src/my.gwt.app Lägg till <inherits name='com.googlecode.mgwt.mgwt'/> i <module> Även sidan som applikationen visas i behövde ändras: Öppna MyGwtApp.html under war/ Ersätt innehållet i <body> med <div id="main" /> Slutligen uppdaterades själva applikationen med en mgwt-komponent. Innehållet i MyGwtApp.java ersattes med följande: import com.google.gwt.user.client.window; import com.google.gwt.user.client.ui.layoutpanel; import com.google.gwt.core.client.entrypoint; import com.google.gwt.user.client.ui.rootpanel; import com.google.gwt.user.client.ui.label; import com.googlecode.mgwt.ui.client.widget.button; import com.googlecode.mgwt.dom.client.event.tap.taphandler;

42 import com.googlecode.mgwt.dom.client.event.tap.tapevent; public class MainPanel extends LayoutPanel implements EntryPoint { public void onmoduleload() { MainPanel mainpanel = new MainPanel(); RootPanel.get().add(mainPanel); } private MainPanel() { Label label = new Label("Hello World!"); Button button = new Button("Tap me!"); button.addtaphandler(new TapHandler() public void ontap(tapevent event) { Window.alert("Tapped me"); } }); add(label); add(button); } } Applikationen startades om enligt tidigare steg. I figur 12.1 visars förväntad output vid körning av ovan kodsnutt. Figur 12.1 GUI: Exempel med TapHandler PhoneGap PhoneGap är ett ramverk som används för att packa ihop webbapplikationer så att de går att installera som appar på smartphones. PhoneGap installerades genom att: Gå till Ladda ner senaste versionen av phonegap.zip och packa upp på hårddisken. Gå till Ladda ner senaste versionen av apache-ant-bin.zip och packa upp på hårddisken. I PhoneGap medföljer ett skript som skapar ett källkodsskelett. För att detta skript skall gå att köra behövdes miljövariabler konfigureras:

43 Högerklicka på Computer och välj Properties. Välj Advanced system settings. Välj Environment variables. Två nya systemvariabler skapades, och en uppdaterades. Under System variables, välj Ny... o Namn: ANT_HOME o Värde: <Rotmappen för apache-ant uppackad på hårddisken> Under System variables, välj Ny... o Namn: JAVA_HOME o Värde: <Rotmappen för JDK-installationen på hårddisken> Under System variables, markera Path och välj Edit... Lägg till följande sökvägar, separerade med semikolon: o <Rotmappen till Android SDK-installation>\platform-tools o <Rotmappen till Android SDK-installation>\tools o %ANT_HOME%\bin o %JAVA_HOME%\bin För att skapa källkodsskelett: Öppna ett terminalfönster och navigera till <Rotmappen för PhoneGap>\lib\android\bin Skriv./create myphoneapp my.phone.app MyPhoneApp och tryck Retur. I Eclipse: File > New > Other... (Ctrl + N) Android > Android Project from Existing Code Navigera till platsen där källkodsskelettet skapades (myphoneapp) Tryck på Finish För att kunna köra Android-projektet på telefonen laddades en drivrutin ned: Öppna <Rotmappen till Android SDK-installation>\SDK Manager.exe Markera Extras > Google USB Driver package Välj Install 1 package... Drivrutinen installerades: Anslut Android-telefonen via USB Högerklicka på Computer och välj Manage Under Device Manager, högklicka på telefonen och välj Update Driver Software. Navigera till <Rotmappen till Android SDK-installation>\extras\google\usb_driver\ Välj Next. För att kunna kapsla in GWT applikationen i PhoneGap behövde den först kompileras. I Eclipse: Markera projektet MyGwtApp under Package Explorer

44 Välj GWT Compile Projekt... under den blåa Google-ikonen. Välj Compile Den kompilerade webbapplikationen hamnade under /war/ Kopiera innehållet i /war/ under MyGwtApp Ersätt innehållet MyPhoneApp/assets/www med de kopierade filerna. Öppna filen MyPhoneApp.java Ersätt super.loadurl(config.getstarturl()) med följande: super.loadurl("file:///android_asset/www/mygwtapp.html"); USB Debugging aktiverades på Android-telefonen: Settings > Applications > Development MyPhoneApp kördes på telefonen genom att: Högerklicka på projektet MyPhoneApp Välj Run As > 1 Android Application gwt-phonegap gwt-phonegap är ett ramverk som kapslar in PhoneGap i GWT-komponenter och därmed låter webbapplikationer skrivna i GWT få tillgång till hårdvara i telefonen, som t.ex. kameran. gwt-phonegap installerades genom att: Gå till Ladda ner den senaste versionen av phonegap.jar och spara på hårddisken. I Eclipse: Högerklicka på MyGwtApp och välj Build Path > Configure Build Path... Under Libraries, välj Add External JAR... Navigera till phonegap.jar och tryck Open För att kunna använda PhoneGap i GWT inkluderades modulen: Öppna MyGwtApp.gwt.xml under src/my.gwt.app Lägg till <inherits name='com.googlecode.gwtphonegap.phonegap'/> i <module> Slutligen uppdaterades själva applikationen med en PhoneGap-komponent. Innehållet i onmoduleload() kompletterades med följande i MyGwtApp.java: final PhoneGap phonegap = GWT.create(PhoneGap.class); phonegap.addhandler(new PhoneGapAvailableHandler() public void onphonegapavailable(phonegapavailableevent event) { //start your app - phonegap is ready } }); phonegap.addhandler(new PhoneGapTimeoutHandler()

45 }); public void onphonegaptimeout(phonegaptimeoutevent event) { //can not start phonegap - something is for with your setup } phonegap.initializephonegap(); BarcodeScanner Till gwt-phonegap finns ett plugin som gör att kameran kan användas till att läsa streckkoder. Plugin:et är baserat på en samling plattformsspecifika implementationer för att stödja olika typer av telefoner. Varje telefon har sitt egna native-lib. BarcodeScanner installerades genom att: Gå till Ladda ned BarcodeScanner och packa upp på hårddisken. I Eclipse: New > Other... (Ctrl+N) Android > Android Project from Existing Code Välj LibraryProject under BarcodeScanner\src\android som root. Högerklicka på projektet och välj Properties Under Android > Library, kryssa för Is Library. Projektet lades till som dependency i MyPhoneApp: Högerklicka på MyPhoneApp och välj Build Path > Configure Build Path... Välj Add... under fliken Projects Kryssa för LibraryProject och välj OK. Till BarcodeScanner medföljde även en JavaScript-fil som används som gränssnitt: Kopiera barcodescanner.js och placera i MyGwtApp/war/ Lägg till link i html För att kunna använda sig av BarcodeScanner i GWT behövdes en wrapper: Gå till Ladda ner barcode-gwtphonegap-plugin och packa upp på hårddisken. Kopiera BarcodeScanner.gwt.xml och /client/ till MyGwtApp Lägg till BarcodeScanner som modul i MyGwtApp.gwt.xml RequestFactory RequestFactory är det huvudsakliga sättet att skicka data mellan server och klient i GWTapplikationer. Själva kommunikationen abstraheras med Proxy-interface och optimeras genom att endast skicka deltan, allt under huven. Följande lades till i MyGwtApp.gwt.xml: <inherits name='com.google.web.bindery.requestfactory.requestfactory'/> Följande lades till i web.xml: <servlet> <servlet-name>requestfactoryservlet</servlet-name>

46 <servletclass>com.google.web.bindery.requestfactory.server.requestfactoryservlet</servlet-class> <init-param> <param-name>symbolmapsdirectory</param-name> <!-- You'll need to compile with -extras and move the symbolmaps directory to this location if you want stack trace deobfuscation to work --> <param-value>web-inf/classes/symbolmaps/</param-value> </init-param> </servlet> <servlet-mapping> <servlet-name>requestfactoryservlet</servlet-name> <url-pattern>/gwtrequest</url-pattern> </servlet-mapping> Följande lades till i MyGwtApp.java: final EventBus eventbus = new SimpleEventBus(); requestfactory = GWT.create(ExpensesRequestFactory.class); requestfactory.initialize(eventbus); Följande filer lades till i /WEB-INF/lib och hittas förslagsvis på Maven Central Repository: requestfactory-server.jar javax/validation/validator-api ga.jar A JSR 303 Validator of your choice, such as hibernate-validator För att RequestFactory skulle kunna validera gränssnitt utfördes följande steg: Högerklicka på MyGwtApp och välj Properties. Java Compiler > Annotation Processing Kryssa för Enable project specific settings Under Processor options, lägg till verbose: false. Java Compiler > Annotation Processing > Factory Path Lägg till requestfactory-apt.jar För att använda RequestFactory som fasad mot ett datalager skapades ett antal klasser som grund. Följande är en lista med klasserna: ArticleRequestFactory ArticleServiceLocator ArticleService Article ArticleProxy

47 12.2 RequestFactory Nedan följer sammanställning av det kodskelett som utgör prototypens RequestFactory-uppsättning ArticleRequestFactory package gwt.hello.client.requestfactory; import gwt.hello.server.articleservice; import gwt.hello.shared.articleproxy; import com.google.web.bindery.requestfactory.shared.request; import com.google.web.bindery.requestfactory.shared.requestcontext; import com.google.web.bindery.requestfactory.shared.requestfactory; import com.google.web.bindery.requestfactory.shared.service; public interface ArticleRequestFactory extends RequestFactory = ArticleService.class, locator = ArticleServiceLocator.class) interface ArticleContext extends RequestContext { Request<ArticleProxy> getarticle(string id); Request<Void> setarticle(string id, ArticleProxy value); } ArticleContext getarticlecontext(); } ArticleServiceLocator package gwt.hello.client.requestfactory; import com.google.web.bindery.requestfactory.shared.servicelocator; public class ArticleServiceLocator implements ServiceLocator { public Object getinstance(class<?> clazz) { try { return clazz.newinstance(); } catch (InstantiationException e) { throw new RuntimeException(e); } catch (IllegalAccessException e) { throw new RuntimeException(e); } }

48 ArticleService package gwt.hello.server; import gwt.hello.server.entities.article; import java.util.hashmap; import java.util.map; public class ArticleService { } Map<String, Article> articles = new HashMap<>(); public ArticleService() { String id = "123"; articles.put(id, new Article(id, "description")); } public Article getarticle(string id) { System.out.println(id); return articles.get(id); } public void setarticle(string id, Article value) { System.out.println(value); articles.put(id, value); } Article package gwt.hello.server.entities; public class Article { String id; private String value; public String getid() { return id; } public void setid(string id) { this.id = id; } public String getvalue() { return value; } } public void setvalue(string value) { this.value = value; }

49 ArticleProxy package gwt.hello.shared; import gwt.hello.server.entities.article; import com.google.web.bindery.requestfactory.shared.proxyfor; import = Article.class) public interface ArticleProxy extends ValueProxy { } public String getid(); public void setid(string id); public String getvalue(); public void setvalue(string value);

50 12.4 Klassdiagram Nedan följer klassdiagram över den prototyp som har byggts, fördelat per paket samt en sammanställd bild över prototypens olika delar och dess kopplingar. client, innehåller klassen HarmoneyLager vilket innehar applikationens EntryPoint och initierar prototypen: client.gui: client.gui.flytt:

51 client.requestfactory: shared: server: server.entities:

52 Följande bild visar hur requestfactory är uppbyggt mellan de olika domänlagren i prototypen: Följande bild visar helheten av prototypen: