Førs t ehjæl p s Mobi l App l i k a t i o n. Christoffer Holm Nielsen Kongen Lyngby 2011 IMM-B.ENG

Transkript

1 1 Førs t ehjæl p s Mobi l App l i k a t i o n Christoffer Holm Nielsen Kongen Lyngby 2011 IMM-B.ENG

2 2 Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone , Fax IMM-B.Eng

3 3 F o r o r d Denne rapport er udarbejdet af Christoffer Holm Nielsen i forbindelse med det afsluttende eksamensprojekt på Diplom-IT på Damnarks Tekniske Universitet. Den er udarbejdet i perioden 14. februar 2011 til 16. maj Projektet er en idé jeg har fået i samarbejde med Laerdal Copenhagen A/S og med vejleding fra Finn Gustafsson IMM DTU. Formålet med opgaven er at vise de forskellige kompetencer indenfor softwareudvikling: analyse, design, implementering og test, som den studerende besidder. Projektet er udført i samarbejde med Laerdal Copenhagen A/S og rapporten er underlagt DTUs standardaftale for Diplom- og Kandidateksamensprojekter.

4 4 Indhold Laerdal Medical A/S Motivation og baggrund Eksisterende applikationer Formål Problemformulering Arbejdsmetoder Rapport skitse Teknologi Kravs specifikation Businessmodel Overordnede design Brugergrænseflade Applikations elementer som er xml-filer Score System Dataindsamling Fejl-håndtering: Mini-games Reminder Generelt om implementeringen Brugergrænsefladen Applikations elementer Database og dataindsamling Applikations elemeter der mangler at blive implementeret

5 5 1.1 Laerdal Medical A/S Laerdal Medical A/S er et af de førende firmaer indenfor simulering go produktion af medicin og førstehjælps redskaber. Den klare mission og vision er: Helping Save Lives og no one should unnecessarily die or be disabled during birth or from sudden illness or trauma. Laerdal star bl.a. andet bag simuleringsdukkerne SimMan 3G, ResusciAnne med flere og tager man et førstehjælpskursus i Danmark er der god sandsynlig hed for at det er nogle Laerdal dukker der bliver trænet på. Laerdal Copenhagen som er den afdeling hvor denne opgave skrives står bag en hel del af softwaren der ligger bag de simuleringsdukker som kan tisluttes computer. Desuden står Laerdal Copenhagen også HaertCode ACLS og BLS som er mikro-simulatorer der er browserbaseret og men hel del af de andre software produkter som kan ses her Motivation og baggrund Efter i flere år at have arbejdet som tester for Laerdal Copenhagen og har jeg stiftet bekendtskab med førstehjælp og forskellige uddannelses og læringsprogrammer. Programmerne henvender sig til alt fra læger til den almene mand på gaden. Som firma får vi på infomøder engang imellem indblik i hvor gode befolkningen er til at give førstehjælp ved hjertestop og andre ulykker. Her får man ofte at vide at vi i Danmark er langt bagud i forhold til et land som Norge. En af grundende til at Norge er foran Danmark på det område er at man har førstehjælp i folkeskolen og har haft det i mange år. På den måde lærer i en tidlig alder at kunne hjælpe andre i nød. I Danmark skal man nu have et førstehjælpskursus i forbindelse med sit kørekort, men det er langt fra alle som vælger at tage kørekort og da det er et forholdsvist nyt initiativ så der er mange ældre som ikke har været igennem kurset. Desuden er der også en stor gruppe som ikke er gamle nok til at tage kørekort som heller ikke har fået tilstrækkelige førstehjælpskundskaber. 1 Dem der tager et førstehjælpskursus kan spørge sig selv om det at tage et udbudt førstehjælpskurs er nok? Hvad sker der når der er gået et par år og der måske er kommet nye regler? Vi kender det alle sammen, situationer hvor vi bliver konfronteret med noget vi burde kunne svare på/udføre men som man efterhånden har glemt da det er uger, måneder ja sågar år siden du sidst havde brug for den kunnen. Hvad gør man så den dag hvor en af ens nærmeste kommer til skade eller får hjertestop og der ikke lige er nogen til at hjælpe? Man forsøger selvfølgelig at hjælpe så godt man kan, hvis man da ikke selv er gået for meget i panik over den hjælpeløshed der kan ramme en. Den største motivation for dette projekt er at hjælpe med at finde en holdbar måde til at befolkningen kan blive bedre oplyst om førstehjælp, så skulle de stå i den uheldige situation og skulle få brug for det, så sidder det på rygraden. Der findes mange måder hvorpå man kan hjælpe folks vidensniveau indenfor førstehjælp, det kan gøres ved at tage kurser, bruge nogle eksisterende programmer eller blot læse omkring emnet. Dette er dog ikke altid lige spiseligt for alle og er man ikke tvungen bliver det med at læse eller bruge tid og penge på kurser hurtigt en belastning i en travl hverdag.

6 6 Hvis man derimod laver noget der er sjovt som samtidig hjælper dit vidensniveau med at blive opretholdt er det måske lettere at få en bruger til at gide bruge 5 min en gang imellem og dermed holde vidensniveauet oppe. På baggrund af at Laerdal Medical ikke har mobilapplikationer i deres portefølje endnu og at folk i dag har meget travlt og derfor altid skal have let adgang til sin læring er valget faldet på en mobil applikation. Det er vigtigt at man som bruger kan udnytte det spild tid som f.eks. opstår når man transporteres til og fra arbejde. Man udelukker på den måde man undskyldningen med man ikke lige havde tid eller ikke lige havde applikationen ved hånden som tilfældet kunne være hvis det var en internet applikation. 1.3 Eksisterende applikationer Der findes allerede forskellige førstehjælps applikationer på det danske marked hvor to er nævneværdige: Mobil Førstehjælp som er sponseret af Dansk Røde Kors og Førstehjælp sponseret af Codan. Førstnævnte er cross-platform og laves endda til ikke smartphones, det er dog mere et opslagsværk end noget andet om end så er det et godt opslagsværk. Mobil Førstehjælp er altså en håndbog i mobilt format der kan hjælpe dig hvis du kommer ud for ulykker/skader som du ikke kan huske hvordan man skal behandle. Codans førstehjælp er et blandings produkt, det er både opslag al la mobilførstehjælp dog er der lavet en søgefunktion til opslags værket, derudover har de en mini quiz, et interaktivt lær Hjerte Lunge Redning(HLR), en hurtigknap til at ringe 112 og mulighed for at finde nærmeste hospital, plejehjem eller apotek. Codans førstehjælp findes pt. Kun til Iphone hvilket gør det kun er en begrænset mængde der får glæde af den. Ved at kigge på de andre mobil applikationer er det tydeligt at den form for applikation jeg skal lave ikke er på markedet endnu. Hvor de andre er mere opslags orienteret og er mere møntet på at man i selve ulykkes situationen søger hjælp og assistance er det meningen at min skal have givet en masse viden inden ulykken så man kun til nøds behøver at bruge tid på at slå op hvad det er man skal gøre. Det er ikke sådan at min applikation vil erstatte den ene eller anden, da de vil være et godt supplement til hinanden og man skal huske på at en mobil applikation aldrig kan erstatte et rigtigt førstehjælps kursus. 1.4 Formål Helt konkret er formålet med denne opgave at lave en prototype på en mobil applikation der kan hjælpe med at forbedre folks forståelse og viden indenfor førstehjælp på sjov måde og følge udviklingen via indsamling af data. Den indsamlet data skal bruges til at følge udviklingen og kan eventuelt bruges til at finde ud af på hvilke områder førstehjælpskurser skal forbedres. 1.5 Problemformulering Det ønskes fremstillet en prototype på en førstehjælps mobil applikation som på en smart og sjov måde kan hjælpe folk med at holde deres kvalifikationer/kendskab til førstehjælp ved lige. Det er bevist at folks lærings kurve er høj efter et kursus men at den falder over tid hvis ikke man holder det ved lige. Læringskurven i dette tilfælde er over kompetencerne og viden inden for førstehjælp, men vi ved at niveauet falder over tid hvis ikke kurven bliver påvirket med viden og træning. Prototypen skal minde brugeren om man skal huske at bruge 3-5 min på applikationen en gang om ugen eller hver 14. dag, hvilket gerne skulle bevirke at deres læringskurve bliver stabil høj i stedet faldende.

7 7 Applikationen skal henvende sig både til folk som har været på et førstehjælpskursus, men også folk som ikke har. Desuden ønskes der at der indsamles data, så der er mulighed for at se hvordan forskellige befolkningsgrupper klare sig, om der er områder der skal sættes specielt ind på og om brugeren har haft et førstehjælpskursus og den bruger så bedre end dem uden kursus. Der skal laves en prototype, hvor ovenstående krav er opfyldt. Applikationen udarbejdes for Laerdal Copenhagen A/S som hører under Laerdal Medical A/S 1.6 Arbejdsmetoder Normalt udvikler og vedligeholder firmaet dets produkter ud fra en række krav og forespørgsler fra kunder som dermed definerer det endelige produkt og nye produkter. Da der i dette projekt ikke er knyttet en reel kunde og det er et prototype projekt, er det den studerende og virksomheden som har udtænkt produktet. Produktet skal udarbejdes indenfor firmaets værdier om at levere kvalitetsprodukter. Udviklingen af prototypen vil foregå efter Unified Process(UP) som består af 4 faser. Inception fasen hvor de centrale dele af systemet fastlægges ud fra generelle ideer og krav som udmønter sig i forskellige use cases. Det er også i denne fase man finder ud af om man skal fortsætte med projektet eller droppe det. Derudover kan man på baggrund af denne fase give et løst bud på tidsestimeringen af projektet. Elaboration de endelige krav fastlægges i denne fase og arkitektur vælges. Design og Analyse færdiggøres og de grundlægende elementer fra de tidlige use cases bør udvikles. På den måde får man et endeligt overblik over produktet, tidsestimeringen kan gøres mere præcis og sidst man finder ud af om det er muligt at færdiggøre projektet. Construction her udvikles og implementeres det endelige system. Det er også i denne fase at mindre vigtige elementer udvikles samt der sideløbende med udviklingen, dokumenteres og testes for at eventuelle fejl fanges. Transition denne fase bruges til betatestning og aflevering til kunde. Enkelte fejl kan findes her og rettes. Sidste finpudsning af systemet finder også sted her, men ny funktionalitet vil ikke blive implementeret. Da Laerdal Copenhageni den seneste tid har afsat mere af medarbejdernes tid til pair commitment, vil dette også blive tænkt ind og afprøvet i implementeringen. Pair commit tager tid og tid er lig penge, men fordelene er til gengæld at man som udvikler har hundrede procent styr på hvad man har lavet. Det er gennemrettet, man får overført viden så mere end en udvikler ved hvad der er sket og man får et par konstruktive og friske øjne til at se på det der er lavet og man fanger eventuelle fejl eller kan få optimeret nogle funktioner.

8 8 For at data ikke skal gå tabt eller fejlimplementeringer af funktioner skal tage for meget tid at rette op på, bruges der til hele projektet både kode og dokumentation Tortoise svn til versionsstyring. Dermed bliver det lagt på DTU s server samtidigt med at det bliver lavet back up både på arbejds- og hjemme computer. Med versionsstyring kan man rulle tilbage til tidligere versioner, så hvis noget funktionalitet tabes er det muligt at rulle tilbage til der hvor det virkede og man kan så analyserer hvad der er gået galt Tidsplan Til projektet er der afsat 12 uger (eksklusiv påskeferien på en uge) med start og slut dato Analyse 4 uger Design 4 uger Implementering 3 uger Test foregår sideløbende med implementeringen og bruger testes senest 7 dage før deadline. Dokumentation laves sideløbende i alle ugerne dog med mest fokus i sidste uge af projektet. 1.7 Rapport skitse Introduktion Analyse Design Implementering Test Konklusion og videreudvikling

9 9 2 Analyse afsnittet vil redegøre for: hvilke teknologier der kan bruges, tidsestimering via use cases, udviklingsproces og om opgaven kan gennemføres. 2.1 Teknologi Her redegøres for hvilke teknologier der kan bruges til at lave mobilapplikationen. Fordele og ulemperne ved de forskellige teknologier vil blive gennemgået og på baggrund af disse vil en passende teknologi blive valgt Mobile platforme En af de første og vigtigste elementer er at vælge en platform til applikationen. Der findes flere forskellige men de to største er Android og Apples Iphones. Figur 1: Der er dog flere som også vil blive nævnt men med udgangspunkt i fig 1 vil det være de to platforme nævnt ovenfor som vil blive undersøgt grundigst.

10 Android Android har en lang række fordele i forhold til de andre platforme. En af de mest væsentlige er at den understøtter Adobe Flash player. Da rigtig mange ting hos Laerdal Copenhagen bliver lavet i flash kan man genbruge flere elementer fra andre programmer bl.a. ville man kunne bruge flashvideoer og på den måde vil man altså kunne spare en del arbejde. Det kunne også tænkes der var flash animationer man ville tage med i programmet, så man sørger for at holde mulighederne åbne ved ikke at begrænse de teknologiske muligheder. En anden oplagt fordel er at det er gratis open source og det kun kræver at man henter et udviklings miljø og installerer android sdk og så er man klar til at udvikle. Det er nemt og muligt at installerer ikke android market applikationer. Til android bruger man Java programmering, hvilket er en fordel hvis man allrede har stiftet bekendtskab med sproget og derfor ikke skal til at lærer et nyt sprog og man kan bruge det miljø man kender. En af de største ulemper er at når en android applikation skal udvikles, så skal man tænke på at der er mange forskellige mobiltelefoner som har android og man bliver nødt til at gøre sig nogle tanker om udseendet eller huske at gøre opmærksom på at applikationen er bedst på nogle bestemte typer telefoner. Det kunne bl.a. gå på hvor stor skærmen er. Android platformen udvikler sig meget hurtigt og der kommer hele tiden nye OS features så det kan blive svært at holde sin applikation optimeret. Derudover kan man ramle ind i problemer med nogle devices da mobilselskaberne har ret og kan ændrer på lige netop deres udgave af android OS Iphone Den største fordel ved udvikling til Iphone er at man udvikler til ét device ikke flere 100 forskellige, hvilket gør man kan optimerer sin applikation og ikke behøver frygte klager fordi den ikke kan køre på en bestemt mobil. Man har et konsistent UI. Af ulemper findes der en del, bl.a. at det koster penge hvis man vil have udgivet sin applikation, iphone understøtter ikke flash, sproget er hvilket jeg som udvikler ikke har kompetence indenfor og derfor først skal tilegne mig. Desuden skal man registrere sig først for at få lov til at udvikle til iphone Platform konklusion Baseret på de forskellige fordele og ulemper ved de to platforme vælges android frem for iphone. De tre hoved grunde er: - Open source - At sproget er Java - Flash understøttelse Udvikling miljø og sprog Eclipse og Java med Android sdk. Java er et objekt-orienterede programmeringssprog lavet af Sun Microsystems (i dag ejet af Oracle)som kom frem i I dag er Java på sin 6. standard udgave og har i årenes løb inspireret/haft indflydelse på

11 11 flere programmeringssprog. Java er open source under GNU(general public license) hvilket er en fordel da man så har adgang til alt uden det kræver at man skal betale noget eller have logo eller anden firma repræsentation. Eclipse er et udviklingsværktøj som oprindeligt var udtænkt til Java men som man i dag kan udvide til mange andre sprog. Eclipse hører også under kategorien free software. Der findes flere alternative udviklingsmiljøer og måder at lave applikationer til android telefoner, men skal man lave en applikation som skal kunne kostumieres helt ned i detaljerne er det svært at komme udenom Eclipse. Man kan sagtens bruge andre IDE eller simple tekstediterings programmer men da Eclipse nu understøtter android development tools som gør alle features tilgængelige fra Eclipse og mulighed for support vi android developper site er det oplagt at bruge Eclipse. Blandt de alternative løsninger for udviklings miljø og sprog findes bl.a. Titanium Developer, google app inventor og PhoneGap som alle er gode alternativer og som man helt klar skal vurderer fra projekt til projekt. Google app inventor virker som et godt alternativ hvis man gerne vil lave en hurtig quiz eller en simpel applikation og man ikke har kodekendskab. Phonegab og Titanium kan begge lave både android og iphone applikationer hvilket burde være en klar fordel da man slipper for at lave to programmer men kan nøjes med et.. Flere skriver på diverse forums at titaniums android funktionalitet ikke er helt i top endnu og man kan ende med en masse dumme bugs, eller i en dead-end hvor man ikke kommer videre fordi der simpelthen mangler noget funktionalitet. Både Titanium og PhoneGap bruger html, javascript og css som så bliver konveteret til native code. Eftersom android developper siden har en lang udførlig guide til hvordan Eclipse og android fungerer sammen og at Eclipse for mig er et kendt arbejdsmiljø er det også Eclipse som jeg har valg som udviklingsmiljø. 2.2 Kravspecifikation Da der er taler om en prototype på et nyt produkt er kravende sat ud fra andre produkter i Laerdal Copenhagens portefølje mht. kvalitet og udseende og selvfølge ud fra forventningerne til prototypen. For at vise hvordan det overordnet system skal se ud er figur 2 udviklet og ses nedenfor. Den online database/register skal bruges til at kommunikerer med applikationen som skal sende data om hvor godt brugeren klarer og andre oplysninger som brugeren opgiver, desuden skal applikationen kunne hente en global high score.

12 12 Bruger Laerdal Mobil applikation Laerdal Online database figur 2: System Brugergrænseflade Hoved kravet til udseendet er at det er enkelt og bruger de rigtige fonte, farver og logoer som resten af Laerdal organisationen. Der skal være et topbanner som ikke fylder specielt meget i højden hvor det fremgår at det er Laerdal og eventuelt en sponsor som står for udviklingen af applikationen. Da en del af oplevelsen er baseret på man kan holde øje med hvor god man er i form af et score system er det vigtigt at man hele tiden kan se hvordan det går og derfor skal scoren være en del af skærmen som bliver vist når man kører applikationen. Der skal også være en let måde at komme ud af programmet på så en menu knap og en exit knap er også krav til applikationen Applikation elementer Usecase: Oprettelse af ny bruger. Aktør: bruger Præ-kondition: første gang brugeren starter applikationen Succes Post-kondition: brugeren oprettes og oplysningerne sendes til online register/database. Fejl Post-kondition: Data kunne ikke sendes, applikationen gemmer og sender næste gang applikationen åbnes. Flow: 1. Brugeren indtaster navn og de adspurgte data 2. Applikationen sender de indtastede data til databasen hvor brugeren registreres. 3. Samtidig med data sendes får brugeren nu lov til at bruge applikationen. Usecase: Se high score Aktør: Bruger Præ-kondtion: bruger befinder sig i main menu Succes Post-kondition: lokal og global highscore vises Fejl Post-kondition: global high score kan ikke vises grundet mangel på forbindelse eller at værten er nede. Skal give fejlmeddelelse i det område hvor den globale score normalt vises. Flow: 1. brugeren trykker på se high score

13 13 2. applikationen sender et request til Laerdal Databasen og søger efter den lokale highscore, begge returnerer navn og score. 3. highscore side bliver vist med global og lokal score Usecase: Start spil Aktør: bruger Præ-kondtion: applikationen kører Succes Post-kondition: spillet starter Fejl Post-kondition: spillet kan ikke starte, giv fejlmeddelelse til bruger og send fejlkode til supportmail. Flow: 1. brugeren trykker start 2. Applikationen loader et spørgsmål eller spil. Usecase: Load næste element(spil/spørgsmål) Aktør: bruger Præ-kondtion: har svaret på et spørgsmål eller gennemført en test Succes Post-kondition: loader næste spørgsmål eller test og opdaterer score Fejl Post-kondition: kan ikke loade nyt spørgsmål eller spil, eller kan ikke opdaterer scoren. Fejlmeddelelse til bruger og applikation sender fejlkode til supportmail. Flow: 1. Applikation viser næste-knappen 2. brugeren trykker på næste 3. applikationen opdaterer score og loader næste test/spørgsmål Usecase: gå til menu fra spil Aktør: bruger Præ-kondtion: en bruger er i gang med at spille. Succes Post-kondition: man kommer til menu og score er gemt lokalt og sendt globalt. Fejl Post-kondition: hvis der ikke er signal til at sende, man ender i menu men score bliver gemt og sendt senere. Flow: 1. bruger trykker på menu 2. applikation viser popup vindue 3. bruger trykker ok på 4. applikation sender Usecase: exit fra spil Aktør: bruger Præ-kondtion: en bruger er i gang med at spille. Succes Post-kondition: Applikationen lukker

14 14 Fejl Post-kondition: hvis der ikke er signal til at sende, score bliver gemt og sendes næste gang applikationen køres. Applikationen lukker Flow: 1. bruger trykker på exit 2. Applikationen viser en pop-up som også indeholder et tænk spørgsmål 3. Bruger bekræfter 4. Applikationen sender data og lukker. Usecase: About info Aktør: Bruger Præ-kondtion: Applikationen er i main menu Succes Post-kondition: info om version, laerdal etc. vises Flow: 1. bruger trykker på about 2. info side vises Usecase: exit fra menu Aktør: Bruger Præ-kondtion: Applikationen er i main menu. Succes Post-kondition: Pop-up med et tænk spørgsmål vises, Applikationen lukker Flow: 1. brugeren trykker luk 2. Pop-up viser et tænk spørgsmål 3. bruger trykker igen 4. Applikationen lukker Usecase: Option Aktør: Bruger Præ-kondtion: Applikationen er i main menu Succes Post-kondition: option siden vises. Flow: 1. bruger trykker på option. 2. option side vises Usecase: reminder fra/til Aktør: bruger Præ-kondtion: Applikationen er på option siden Succes Post-kondition: reminderen bliver slået til/fra Flow: 1. bruger trykker på reminder 2. Applikationen viser pop-up 3. bruger slår til/fra

15 15 4. Reminderen bliver slået til/fra Usecase: reminder Aktør: Applikation Præ-kondtion: Applikationen har været åben, reminder er slået til, der er gået 10 dage siden applikationen sidst var åben Succes Post-kondition: Der vises en pop-up om det er på tide at bruge applikationen igen Flow: 1. pop-up der minder bruger om at bruge lidt tid på førstehjælp 2. bruger trykker åben eller cancel Dataindsamling og administrator del Det er meningen at applikationen skal sende nogle oplysninger om brugeren. Disse oplysninger sendes til en database som Laerdal eller en administrator har adgang til og ville kunne bruge til at se nogle basis oplysninger om brugerne og om hvor godt de klarer sig. Da det er en prototype vil det være få og enkle oplysninger der bliver sendt til en database. Usecase: Send bruger oplysninger Aktør: applikation Præ-kondtion: en bruger har indtastet sine oplysninger. Succes Post-kondition: Applikationen oplysninger bliver sendt og indsat i database. Fejl Post-kondition: data bliver ikke indsat, de gemmes lokalt og forsøges sendt efter 1 min Flow: 1. applikationen sender brugerdaten 2. Databasen modtager og sender en status besked tilbage til applikationen. Usecase: hent high score Aktør: applikation Præ-kondtion: en bruger starter applikationen og går til view highscore. Succes Post-kondition: Applikationen den globale score vises. Fejl Post-kondition: ingen forbindelse, besked til bruger i feltet hvor scoren skulle have været vist Flow: 1. applikation sender forespørgsel på highscore 2. databasen returnerer scoren 3. applikationen viser den. Usecase: Send score Aktør: applikation Præ-kondtion: en bruger har spillet og er på vej til main menu eller helt ud af spillet. Succes Post-kondition: scoren bliver sendt og indsat i database.

16 16 Fejl Post-kondition: data bliver ikke indsat, de gemmes lokalt og forsøges sendt efter 1 min Flow: 1. Sender scoren og hvilken bruger det er 2. Databasen indsætter scoren. Sekvensdiagrammet i figur 3 herunder viser normal brug ved første gang man bruger applikationen. Tallene i teksten henviser til tallene på diagrammet. Figur 3: sekvensdiagram 1 Brugeren starter applikationen første gang(1), og applikationen beder ham oprette en ny bruger ved at indtaste nogle data(2). Når brugeren godkender de indtastede data(3), sender applikationen dataene til databasen online(4) og leder brugeren til main menu. Databasen sender en status meddelelse tilbage som brugeren ikke ser(5). Hvis der ikke kunne oprettes forbindelse lagres brugerdataene lokalt(4b) indtil næste gang applikationen køres.

17 17 Brugeren starter et spil(6) og applikationen viser nu det første spørgsmål(7). Brugeren besvarer nu spørgsmål og gennemfører små minitests(8). For hver gang han har svaret eller gennemført en test opdateres scoren (9), dette er prøvet indikeret som et loop der bliver ved lige indtil at han vælger at trykke exit(10). Når han trykker exit bliver der vist en pop-up(11) hvor brugeren skal bekræfte han vil ud af applikationen og i samme pop-up bliver der vist et lektions/tænke spørgsmål. Dette spørgsmål er ting som man bør tænke over men tit glemmer i forhold til førstehjælp. Brugeren bekræfter(12), scoren sendes til databasen(13) som returnerer status(14) og applikationen lukker(15). Blev scoren ikke sendt gemmes den lokalt(13b) Figur4: sekvensdiagram2 I sekvensdiagram i figur4 ses hvad der sker når en bruger der er registreret logger ind anden gang og vælger at browse lidt rundt i applikationen. Tallene referer fra teksten til tallene på diagrammet.

18 18 Brugeren starter applikationen(1), som starter i main menu(2). Han vælger highscore(3), og applikationen sender en forespørgsel til databasen(4), som hvis der er forbindelse får returneret den globale highscore(5). hvis ikke der er forbindelse(4b) vises en meddelelse i det felt, hvor den globale score skulle være. Ligemeget hvad vises highscore siden(6), bruger går tilbage og i stedet ind i option(7) som applikationen viser(8). Her vælger brugeren om reminder skal være til eller fra(9) hvilket så gemmes så applikationen husker det(10). (11) bruger vælger about fra main menu og får vist info om applikationen(12). Start spil sekvensen(13-16) er vist igen for i stedet for at lukke applikationen vælger brugeren at gå tilbage til main menu(17), når en bruger gør det gemmes scoren lokalt(18) hvis nu brugeren vil spille videre. Efter at være gået til main menu beslutter brugeren sig for at lukke applikationen(19), tænk spørgsmålet og bekræft vises som pop-up(20). Brugeren bekræfter(21) og scoren sendes til databasen(22) der sender et svar(23) hvorefter applikationen lukkes(24). Hvis ikke der er forbindelse gemmes scoren lokalt dvs. bliver ikke slettet(22b). 2.3 Businessmodel Der findes mange måder at sælge applikationer til mobiler på. Hvis denne skal sælges ud fra firmaets værdier om helping save lives skal den for forbrugeren helst være gratis eller følge med ved køb at et andet produkt, som f.eks. ved tilmelding til et førstehjælps kursus. Da udvikling koster tid og penge kunne man f.eks. bruge reklamer for at holde applikationen gratis men det er forstyrrende og vil nok ødelægge fokus. I stedet skal der søges samarbejdspartnere som i det pågældende land står for udbredelsen af førstehjælp. I Danmark kunne det være Røde Kors, Trygfonden eller Codan. Eftersom både Røde Kors og Codan allerede har deres egne applikationer er det yderst tvivlsomt at de vil satse på denne applikation, da de allerede har brugt penge på at få udviklet noget lignende. Man skal ikke udelukke der sørges for at applikationerne er forskellige nok og man kan skabe et grundlag for at de også har brug for denne applikation i deres portefølje. Det er også en mulighed at gå efter nogle af de andre firmaer som udbyder førstehjælp herhjemme. Den ønskede model er altså at man finder en Sponsor/samarbejdspartner som man i fællesskab udvikler applikationen færdig med. Partneren betaler Laerdal for udviklingen af projektet og for at vedligeholde produktet. Partneren får en til gengæld en kvalitets førstehjælps applikation som kan bruges til at holde øje med kvaliteten af førstehjælpskurserne og hvilke fokus områder der eventuelt skal være. Desuden får partneren og Laerdal deres navne ud til en masse brugere og Laerdal viser at de er et af de førende firmaer indenfor førstehjælp innovative produkter som kan hjælpe med at rede liv. Omkring denne model så er der løst blevet snakket med Brett Derecourt som er produkt manager for træning hos St John fra New Zealand( I forbindelse med optagelse af instruktionsvideoer til førstehjælp. Han var ret interesseret da man netop hos hans organisation har et budget til alternative former for at lære folk førstehjælp. Ved denne model kan der altså aftales en pris for en kostumeret udgave til hans

19 19 organisation, med deres guidelines, og deres logoer hvor de betaler løn og eventuelt et aftalt beløb til Laerdal. Om de så distribuerer applikationen gratis eller tager penge for den er op til dem. 3 Designfasen tager udgangspunkt i analysen og de endelige teknologier der skal bruges i projektet fastlægges. Desuden vælges der standarder for de forskellige komponenter. Implementeringen laves ud fra design fasen og det er derfor vigtigt at designet er velovervejet og godt skruet sammen fra start da det gør processen omkring implementering væsentligt lettere. Det kan selvfølgelig ske at man ændrer noget i forhold til designet, men det skulle gerne være meget få ting som der redegøres for i implementeringsafsnittet 3.1 Overordnede design Essensen i dette projekt er dog at lave en så generisk opbygning som muligt så applikationen hurtigt og nemt kan kostumeres til hvilket sprog/land/kunde det skulle være. Det vil sige at så meget der kan spredes ud i filer som xml skal spredes ud, så man kan nøjes med at skifte enkelte filer ud men beholde hovedfunktionaliteten. Figur 5 Design diagram

20 20 I figur 5 ses en overordnet og meget simpelt design diagram der viser hvordan applikationen hænger sammen. Diagrammet er lavet ud fra analysen, for ikke at klistre endnu flere pile på er de steder hvor der hentes fra en XML-ressource fået denne label (XML). Den blå blok er selve applikationen og i den er vist et flow. En blå enkelt pil betyder man kun kan gå én vej. En dobbeltpil betyder at man kan gå begge veje. Den sorte boks er online databasen og den gule er den lokale. De sorte og gule pile viser hvilke veje der sendes data/forespørgsler og hvornår. Den røde boks er fejlhåndtering, hvor der først gøres opmærksom på at der er en fejl i programmet, derefter sendes fejlkoden til en support mail og brugeren kan vælge at gå til main menu eller lukke programmet. 3.2 Brugergrænseflade Formålet med brugergrænsefladen er at det er gennemskueligt og at navigerer rundt i applikationen og tilgå alle de forskellige funktioner. Det skal simpelt at se på for brugeren, dvs. ingen forstyrrende farver eller animationer. Det skal være let at se hvem det er der står bag applikationen, og kan gøres med et enkelt stilfuldt topbanner med Laerdal og partners logo. Opbygningen af de forskellige skærmbilleder følger herunder på baggrund af det overordnede diagram i figur. Skærmbilleder er vigtige da man kan spore dead-ends eller finder ud af om der mangler nogle billeder til flowet. Skærmbillederne der bliver vist i dette afsnit er mock-ups og er ikke de færdigdesignede Skærm mockups Denne skærm skal bruges når applikationen lige er blevet startet og loader. Det er vigtigt den er enkel og at det fremgår: Partner, Laerdal og navnet på applikationen. Figur 6: startskærm figur 7: standard skærm Standard skærm billedet er udgangspunktet for alle menuer og andre elementer i applikationen. Denne indeholder baggrund og topbanner ses i figur. De resterende mock-ups præsenteres herunder, med sigende titel.

21 21 Fig. 8 Main menu Fig. 9 Opret bruger Fig. 10 Spørgsmål Fig.11 Svar på spørgsmål Fig.11 Før mini game Fig. 12 Mini game Fig. 13 resultat Fig.14 Gå til Main menu Fig. 15 Forlad app Fig. 16 About Fig. 17 High score Fig.18 High score med fejl For at se de ovenstående mockups i et flowdiagram se i appendix. Der kan komme små ændringer til det endelige design. Som det ses er designet meget enkelt med maksimalt 4 navigationsknapper, på nær i hoved menuen.

22 Applikations elementer som er xml-filer De forskellige applikations elementer bygges op således at de at de let kan opdateres eller erstattes. For at gøre dette bruges der xml-filer som en del af løsningen. Alle quiz spørgsmål, lektions spørgsmål, sprogfil og config bliver lavet som xml-er som applikationen kan læse fra. Ideen kommer af at der i flere laerdal produkter findes quizes med spørgsmål og at det at man på android developper site bliver anbefalet at lave xml filer hvis man skal skifte mellem sprog Spørgsmål/quiz I denne prototype er der to kategorier af spørgsmål, hvor en fuldt udviklet applikation ville have en del flere. I princippet kunne kategorier være lige meget for prototypen da der ikke er lagt op til at der skelnes mellem kategorierne. Ved at gøre kategorier klar lægges der op til at man kan lave en mere avanceret monitorering af hvordan brugerne klare sig og man vil kunne give feedback til brugerne om hvilke kategorier de ikke er så gode i. For at tage det endnu et plan op kunne man lave en algoritme som sørger for flere spørgsmål i kategorier hvor brugeren ikke er så stærk. Det er også meningen at man i den endelige applikation ikke får samme spørgsmål to gange tæt på hinanden som man allerede har svaret korrekt på, da det er vigtigt at komme rund i alle kategorier og blive spurgt ekstra til det man er dårlig til. figur 19: svar valgt figur 20: rigtigt/forkert De to mock-ups i figur 19 og 20 viser hvordan det kan se ud når man er i gang med quizzen. Spørgsmålet øverst og svar mulighederne er fra quiz.xml. Der vælges et svar blandt mulighederne og på næste screen ses så om det var rigtigt eller forkert, dette er også givet i quiz.xml samt en eventuel forklaring på svaret. Et eksempel på quiz.xml 01 <Quiz> 02 <Question> 03 <Category>BLS</Category> 04 <QNum>1</QNum>

23 23 05 <QText>What is most important during CPR</QText> 06 <Option> Do nothing until paramedics arrive </Option> 07 <Option correct = 1 > Press hard and fast </Option> 08 <Option> Keep a slow rate</option> 09 <Option> push lite 1-2 cm down</option> 10 <AddText> pressing hard and fast helps the blood circulating</addtext> 11 </Question> 12 </Quiz> I linie 1 startes quiz. Linie 2 Starter et spørgsmål som slutter i linie 12. Inden for question gives der kategori i 3. line, spørgsmål nummer i 4. og selve spørgsmålsteksten som vil blive vist øverst i fig. Er fra linie 5. Linie 6-9 definerer hver linie en svarmulighed som vil blive vist i applikationen. En af dem har Correct=1 og er altså det korrekte valg. Linie 10 er ekstra forklarende tekst som vises når der er svaret. I line 11 sluttes spørgsmålet, men hvis der ønskes flere spørgsmål gentages linie 2 til 11 indtil der ikke defineres flere. Linie 3 og 4 er dem som lægger op til den udvidet funktionalitet. Xml-filen vil blive på engelsk dog vil al tekst der hente være på dansk så ovenstående eksempel er altså bare et eksempel Lektions spørgsmål Lektion spørgsmålet eller tænk spørgsmålet som det også er kaldt er et spørgsmål der skal vises lige før applikationen lukkes. Dette er spørgsmål som skal få brugeren til at gøre sig nogle tanker om førstehjælp som de normalt ikke plejer. Disse spørgsmål hentes fra lection.xml og filen er ret enkelt da den indeholder spørgsmål uden svar. Dog tilføjes et spørgsmål nummer da det på sigt er ønskeligt at undgår de samme spørgsmål. Eksempel på lection.xml 01 <Lection> 02 <Question> 03 <QNum>1</QNum> 04 <QText>Ved du hvor den nærmeste hjertestarter er når du er på arbejde?</qtext> 05 </Question> 06 </Lection> Sprog Language.xml kommer til at være en del anderledes end de to foregående. Det er meningen applikationen skal hente al tekst som ind xmlen Dvs. at man på en let og enkel måde bare skifter xml filen ud med det sprog man vil bruge. Det kræver selvfølgelig at alt er defineret rigtigt. Et eksempel på et uddrag af language.xml 01 <Language> 02 <Menu> Main Menu</Menu> 03 <about>about</about> 04 <newuser>ny Bruger</newuser> 05 <back>tilbage</back> 06 <Answer>Svar</Answer> 07 <Confirm>Bekræft</Confirm>

24 24 08 <CreateUser> 09 <UserName>Navn</UserName> 10 <UserAge>Alder</UserAge> 11 <Sex> 12 <Option>Male</Option> 13 <Option>Female</Option> 14 </Sex> 15 <UserExp> 16 <Option>kursus1</Option> 17 <Option>kursus2</Option> 18 <Option>kursus3</Option> 19 <Option>ingen erfaring</option> 20 </UserExp> 21 <Other>Andet</Other> 22 </Language> Der er en del tekst der skal tastes ind men det vil gøre processen med at skifte sprog lettere. Man kan meget vel komme ud for situationer hvor man skal kunne skifte mellem sprog i selve applikationen bl.a. mellem spansk og engelsk eftersom der f.eks. i USA er mange der kun taler spansk eller er bedst på spansk. Et skift mellem sprog i selve applikationen vil være en funktion som ved valg af spansk leder efter language_es.xml. Dog har applikations prototypen ikke denne funktionalitet men det er godt at være på forkant da det kan fremkomme som kunde krav Configuration Konfigurations filen indeholder oplysninger om de visuelle elementer her tænkes på bl.a. på logoer, bannere, fonte. Config.xml kunne se således ud: 01 <PartnerLogo> StJohns.jpg</PartnerLogo> 02 <LaerdalLogo>Laerdal_Logo.jpg</LaerdalLogo> 03 <Font>Helvetica Neue Extended.otf</Font> 04 <SizeHeaderFont>16</SizeHeaderFont> 05 <SizeNormalFont>12</SizeNormalFont> 06 <FontColorNormal>#000000</FontColorNormal > 06 <FontColorMOver>#00008B</FontColorMOver> Der findes mange andre ting der kunne defineres i denne fil, men det er igen for at sikre ensartethed og for lethedens skyld hvis der skal skiftes banner. Hvis man skulle sælge applikationen til en ny kunde kunne man bede om deres logo og så hurtigt ændre linie 1til deres deres logo fil about.xml About skal indeholde alt fra versions nummer, info om hvornår applikationen er fra og alt om rettigheder. Der kan eventuelt stå lidt om firmaet/partneren og findes link til mere information.

25 Score System Point systemet er skruet sådan sammen at man får 1 eller 0 for hvert spørgsmål eller mini test man gennemfører. High scoren vægter antal spørgsmål man har svaret rigtigt på højest, og derefter kigges der på hvor mange procent rigtigt der er. Altså vil en der har svaret 1 ud 10 spørgsmål rigtigt ligge under en der har svaret rigtigt på 2/2. den der har svaret 2/2 ligger så højere end den der har svaret på 2/3. er der en bruger som så har svaret 5/10 ligger denne nummer et da scoren først kigger på antal rigtige svar uanset hvor mange spørgsmål brugeren har brugt til at få det antal. På denne måde honorerer man både brugere der bruger applikationen meget og dem der brugeren den knap så meget men svarer rigtigt. 3.5 Dataindsamling Data indsamling foregår på to måder, både lokalt og globalt. Den lokale database skal indeholde stort set det samme som online databasen da man på den må de sikre at data ikke går tabt omkring briugernes udvikling. Da android understøtter SQLite database er det denne type som bliver brugt. Den online database bliver ikke implementeret i prototypen. Den eneste forskel på den og den lokale er at der tilføjes et PhoneID. Der skal være en Users tabel som skal indeholde følgende felter: _id en integer der automatisk får en ny værdi for hver nu indsat bruger username et felt som gemmer en string med navnet på brugeren der er oprettet. userge- indeholder fødselsdagsdato som en integer. userex en string som indeholder info om brugerens køn experience et string felt hvori der hvilket kursus brugeren har taget hvis han overhovedet har taget noget kursus. other et string felt hvor brugeren har haft mulighed til at noterer andre bemærkninger, dette kunne bl.a. være at han havde taget flere af de overnævnte kurser. answered- integer med antal spørgsmål brugeren har svaret på. correct- integer med det antal korrekte svar brugren har haft. percentage- integer med den udregnede svar procent phoneid hvis det er muligt at finde et unik ID skal der være en tabel med det ID. Grunden er at man på den måde kan se hvor mange forskellige telefoner applikationen bliver brugt på samt man kan sikre at man kan håndterer flere brugere med samme navn. PhoneID feltet gemmes som string. Når den globale high score skal indlæses beder applikationen kun om de 5 første fra tabellen sorteret efter correct og ved lighed percentage. Det er en forholdsvis meget simpel database da den kun er til prototypen. Man kunne forestille sig at sådan noget som kategorier kunne få en tabel hver og at man på den måde kunne se hvem der var bedst indenfor hvilke områder. Det er alt sammen mulige udvidelser da applikationen også vil sende flere data hvis prototypen videreudvikles.

26 Bruger Når en bruger oprettes gemmes han i users.db. Når man starter et spil kan man enten vælge hvilken bruger man vil spille som. Eller oprette en ny. users.db opdateres med nye brugere og historik. En af grundende til der ikke kun er valgt en tekst fil til de forskellige bruger er at forbindelsen til online databasen som samler data kan være nede. Derfor ville der gå data tabt hvis ikke det også blev gemt lokalt og sendt næste gang brugeren har brugt applikationen. Hvis applikationen udvides til at holde styr på de forskellige kategorier af spørgsmål skal databasen udvides til at håndterer dette. 3.6 Fejl-håndtering: Opstår der er fejl i applikationen som ikke kan håndteres skal der komme en popup hvor der står at der er fejl i applikationen og evt fejlkode. Brugeren får valget mellem at lukke applikationen eller prøve at gå til main menu. Bag facaden sendes en mail til SupportApp@laerdal.dk med fejlkode, telefon id, eventuelt hvilken version af android telefonen bruger. På den måde kan man i prototype stadiet holde styr på hver gang noget går galt. Figur. 21: fejl diagram Den sorte stiplede linie indikerer en automatisk begivenhed, i dette tilfælde sender den fejlkode til support mailen. Den blå pil indikerer et bruger valg om enten at lukke applikationen eller gå til main menu. 3.7 Mini-games Det er meningen at der skal designes en masse mini games hvis applikationen videreudvikles. Det er dog meningen at en eventuel partner skal være med til at definerer disse da der kan være forskellige krav specielt til guidelines i det land applikationen laves til. Der for vil der i prototypen ikke findes nogen af disse mini spil

27 27. Da Laerdal har en del små spil i de forskellige andre programmer er det værd at overvejer at genbruger nogle af disse. De eksisterende spil er lavet i flash som så ville være ressourcer man henter ind i selve hovedapplikationen. Der er dog mini games som ikke er lavet kunne give mening at få lavet et eksempel kunne være Tab the tempo Tab the tempo Tab the tempo er et enkelt spil som går ud på at trykke det tempo man mener, er mellem beats pr. min. Efter man har trykket start tæller applikationen ned og man starter nå uret rammer nul. Herefter trykker man i det tempo man mener, er det rigtige. Man trykker i 30 sekunder og for at ligge mellem 100 og 120 skal man altså trykke gange på de 30 sekunder. Der skal laves måling som forhindrer brugeren i at trykker 50 gange hurtigt efter hinanden og så bestå. Der skal måles om brugeren faktisk ligger mellem 1,6 til 2 tryk i sekundet. Efter 30 sekunder stopper spillet og et resultat vises til brugeren, og eventuelt med forslag til sange som man kan nynne for at holde takten i det rigtige tempo. 3.8 Reminder Reminderen der skal huske brugeren på at bruge applikationen laves som skal laves som statusbar notifikation. Dette vil sige at brugeren får en note i toppen på sin telefon ligesom man får en note om der er modtaget en besked. Trykker man på noten starter applikation. Reminderen vil ikke være at finde i portotypen da den kan virke irriterende og ville skulle sættes til noget meget kort for at vise det virker. Det bør være en kunde beslutning om den skal implementeres.

28 28 4 I dette kapitel redegøres der for de mest interessante funktioner i projektet. Kildekoden findes i det vedhæftet eclipse projekt eller kan findes på den vedlagte cd. Der vil indgå kildekode flere steder i kapitlet for at gøre det mere læsevenligt, så læseren ikke skal fedte rundt i koden for at finde det relevante stykke kode. Laerdal Førstehjælps applikationen er udviklet i eclipse med android sdk og skrevet i Java. Kapitlet følger den samme struktur som design kapitlet for at gøre det mere overskueligt at se hvor de enkelte dele fra designet er implementeret. Det er vigtigt at understrege at det er en prototype og ikke et produktionsklart produkt. For at det skal kunne tages i brug kræves der en partner, videreudvikling og opsætning. Prototypen er kun for at vise hvad man kan lave for at fange eventuelle interesserede partnere. 4.1 Generelt om implementeringen Applikationen er bygget op omkring Aktiviteter(activity). Det svare lidt til at lave en applikation som bygger på html eller andet websprog hvor man navigerer rund på de forskellige sider. Så den første aktivitet er når programmet bliver startet fra telefonen er en startskærm for applikationen. Android starter aktiviteten som bliver bragt forrest i en stack af aktiviteter. Efter load skærmen har været på x-antal sekunder eller er færdig med at hente det der skal hentes, startes en ny aktivitet i denne applikation er det hovedmenuen der starter. Ny aktivitet bliver kaldt på to måder i applikationen Intent intent = new Intent(); intent.setclass(this, PlayGame.class); intent.putextra("username", UserName); intent.putextra("qanswered", ans); intent.putextra("qcorrect", cor); intent.putextra("qpercentage", per); startactivity(intent); eller Intent intent = new Intent(this, Quit.class); startactivity(intent); Den sidste måde er den hurtigste og er handy hvis der ikke skal ske andet end at skifte aktivitet. Den første og lidt langsommere måde er mest for overblikkets skyld, de to første linjer er det samme som første line i den korte metode. Intent.putExtra er en måde at overfører værdier og tekst fra en aktivitet til en anden. For at en aktivitet kan hente de sendte data kalder man følgende. Bundle bundle = getintent().getextras(); Alle de værdier man lagde ind via putextra kan nu hentes ud fra bundle. For at alle aktiviteterne kan køre skal man have deklareret dem i AndroidManifest.xml eller kan

29 29 applikationen ikke finde ud af at starte dem. For hver aktivitet kan der sættes forskellige parametre bl.a. om aktiviteten kan ses både som landskab go portræt eller kun en af delene. Denne applikation er udviklet til kun at vises i portræt. Hver aktivitet peger på en xml fil i ressourcer som indeholder et layout. 4.2 Brugergrænsefladen Brugergrænsefladen er opbygget gennem XML filer som hver indeholder holder en baggrund og et lineært layout i toppen med to logoer, som pt. begge er Laerdal logoer. Derudover er der for hver enkelt layout forskellige elementer som knapper og tekst alt efter hvad der er nødvendigt. Stilen er søgt holdt meget enkelt og gjort klar til et partner logo kan indsættes i toppen. Det eneste Layout der skiller sig ud er det load billede som vises i starten. Da det er meget simpelt at læse XML-filen bag har jeg valgt den som én af to eksempler på opbygning af layout XML. <?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android=" android:layout_width="match_parent" android:layout_height="match_parent"> <ImageView android:id="@+id/imageview1" android:src="@drawable/loading" android:layout_height="match_parent" android:layout_width="match_parent"> </ImageView> </LinearLayout> Figur 22: layout xml Først defineres version og encoding af XML-filen, det bliver automatisk gjort i eclipse. xmlns:android definerer at denne xml bruges af android og ikke andre funktioner. Herefter defineres det lineære layout hvor bredden og højden sættes til at være det samme som parrent hvilket i dette tilfælde betyder at skærmen på den enhed der kører applikationen fyldes ud. I det linære layout defineres et ImageView som får et for dette layout unikt id (imageview1). Dette id kan bruges i program hvis man ønsker ændre billedet f.eks. android:src="@drawable/loading" peger på det billede der er lagt ind i projektets ressource folder og som er valgt som start skærm.

30 30 Skærmen der vises ved start ser ud som på: Figur 23: startskærmen figur 24: hovedmenu Main.xml er XML-filen bag figur som er vores hovedmenu og kan ses i figur. Selv med forholdsvis få knapper og simpelt layout bliver det hurtigt en stor mundfuld at finde rundt i filen. <RelativeLayout xmlns:android=" android:orientation="vertical" android:layout_width="fill_parent" android:layout_height="fill_parent" android:background="@drawable/wallpaper"> <TableLayout android:id="@+id/tablelayout1" android:layout_height="wrap_content" android:layout_centerhorizontal="true" android:layout_centerinparent="true" android:layout_width="fill_parent" android:layout_below="@+id/bannerholder"> <Button android:layout_width="wrap_content" android:layout_height="wrap_content" android:id="@+id/startgame" android:ellipsize="none" android:layout_weight="1" android:text="@string/but_start"></button> <Button android:layout_width="wrap_content" android:layout_height="wrap_content" android:id="@+id/highscore" android:layout_weight="1" android:text="@string/but_highscore"></button> <Button android:layout_width="wrap_content" android:layout_height="wrap_content" android:id="@+id/about" android:layout_weight="1" android:text="@string/but_about"></button> <Button android:layout_width="wrap_content" android:layout_height="wrap_content" android:id="@+id/newuser" android:layout_weight="1" android:text="@string/but_newuser"></button> <Button android:layout_width="wrap_content" android:layout_height="wrap_content" android:id="@+id/quit" android:layout_weight="1" android:text="@string/but_quit"></button> </TableLayout> <LinearLayout android:layout_height="wrap_content" android:layout_width="fill_parent" android:id="@+id/bannerholder" android:layout_alignparentleft="true"> <ImageView android:layout_height="fill_parent" android:layout_margin="1dp" android:id="@+id/laerdallogo" android:src="@drawable/laerdal_top_logo" android:layout_weight="1" android:layout_width="match_parent"></imageview> <ImageView android:layout_height="fill_parent" android:layout_margin="1dp" android:id="@+id/partnerlogo" android:src="@drawable/partner_top_logo" android:layout_weight="1" android:layout_width="fill_parent"></imageview> </LinearLayout> </RelativeLayout>

31 31 Figur 25: main.xml Hoved layoutet er et relativt layout, som er sat til at fylde sin parent som er hele skærmen. Med: peges der på wallpaper i drawable ressourcen. Ønsker man at skifte baggrund i hele applikationen kan man nøjes at erstatte wallpaper.png da denne går igen på alle andre layouts. I toppen ses de to Laerdal logoer som bliver holdt i et lineært layout. Dette lineære layout går også igen ligesom som wallpaper på alle layouts, så skifter man det ene eller begge logoer sker det på alle layouts. Knapperne i menuen indgår i et tabellayout og en knap defineres på følgende måde: <Button android:layout_width="wrap_content" android:layout_height="wrap_content" android:id="@+id/newuser" android:layout_weight="1" android:text="@string/but_newuser"></button> Højde og bredde er sat til wrap_content, hvilket betyder de burger de har brug for. Android idet er som beskrevet et ID som man kan bruge i program koden. Layout weight angiver hvor meget plads efter alle andre elementer har taget den plads der er defineret, dette element skal have. Denne værdi spiller ikke rigtigt nogen rolle i dette layout. Havde der i stedet været tre knapper ved siden af hinanden som hver var 30 pixels bred men der er 100 pixel til rådighed ville knappen hvis kun den ene knap havde vægt 1 får de 10 ekstra pixels. Ved to knapper med vægten 1 ville de få 5 pixels hver osv. android:text="@string/but_newuser"> Teksten på knappen bliver sat ved en reference til strings.xml hvilket svare til language.xml fra design. But_newUser er navnet på den streng den skal finde i filen og skrive teksten fra. Resten af de forskellige layouts er bygget op på sammen måde. Eclipse har indbygget et grafisk layout preview se figur 26 hvortil man også kan lave drag and drop med de forskellige elementer så man ikke for hver layout skal skrive en stor XML-fil. figur 26 Dog kan man ikke være helt sikker på at elementerne vises helt rigtigt, figur 26 er preview af figur 24 som er et screenshot fra applikationen.

32 Applikations flow For at vise hvordan resten af de implementerede layouts ser ud og for at give et overblik over hvad der er blevet implementeret vises flowdiagram med screenshots fra det kørende program. I figur I forhold til det oprindelige design er der lidt færre dels fordi det gør applikationen lettere for brugeren og dels fordi der er nogle elementer som er udeladt. Hvilke elementer der er udeladt vil blive beskrevet senere i kapitlet. figur 27: flowdiagram 4.3 Applikations elementer I de kommende afsnit vil implementeringen af de forskelligege applikations elementer gennemgås XML-elementer. I dette afsnit vil quiz.xml og strings.xml blive gennemgået, de andre xml-filer er about.xml og lection.xml. De to sidst nævnte er ens med de to første i måden de opbygges på quiz.xml Måden quiz.xml er blevet sat op er en del forskellig fra den først foreslået måde i design. Da android ikke bare lige kan læse fra hvilken som helst xml.fil uden en selvlavet parser klasse. Er der til prototypen valgt at følge android måde at lave xml filer hvilket gør tingene lidt besværligere. opbygningen ser nu som i figur00. Quizzen laves ud fra et string-array med items. Det første item er spørgsmålet, de næste 4 items er de 4 svar muligheder. Item 5 er det det rigtige svar og skal være lig et af de 4 svar items og det 6 item er beregnet til en mere forklarende tekst om det rigtige svar. På den måde fortsætter items med at komme i ovenævnte rækkefølge. for at se hvordan de bliver brugt se Playgame.java afsnittet. Hovedgrunden til at quiz spørgsmålene skulle eksistere i xml format var letheden i at erstatte og opgradere

33 33 med nye spørgsmål. Dog skal der enten laves en xml-parser klasse som kan læse fra rigtige xml filer eller også skal der laves en spørgsmål database. Figur 28: quiz.xml Til denne prototype er en xmlfil til at indeholde spørgsmålene fin nok, men hvis applikationen skal videreudvikles bør der nok oprettes en spørgsmålsdatabase, hvilket også vil skabe flere muligheder mht. monitorering af hvordan bestemte brugere klare sig inden for bestemte kategorier af førstehjælp. lection.xml er bygget på samme princip dog er hvert item et nyt spørgsmål som brugeren kan tænke over strings.xml Strings.xml indeholder næsten alt tekst der bliver vist i løbet af applikationen. Den er også en smule anderledes end oprindeligt designet men det er stadig vejen frem. Alle strings har et engelsk navn men selve indholdet af strengen er dansk. På den måde kan man lave strings.xml til en masse forskellige sprog så længe navne på strengene er de samme som i den originale strings.xml. Det er muligt at finde hver streng grundet det navn man giver strengen f.eks. er app_name er det unikke ID i den følgende streng og kan bl.a. tilgås fra layout designeren eller direkte fra koden. <string name="app_name">førstehjælps applikation</string> String nameoffapp = getresources().getstring(r.string.app_name);

34 34 Figur 29: strings.xml Abouttext.xml indeholder pt. kun en streng da der på nuværende tidspunkt ingen partner er på projektet samt der ikke er aftalt nogen former for licensaftaler eller andet som typisk ville indgå her Java klasser De fleste af java filerne repræsenterer sin egen aktivitet, den eneste som ikke gør, er hjælper klassen DBHelder.java som hører under Database og dataindsamlingsafsnittet FirstAidHelp.java FirstAidHelp er den første aktivitet der bliver kaldt når applikationen startes. Denne klasse er sat til at køre et while loop i 3 sekunder for derefter at forsætte til hovedmenuen en ny aktivitet. Der er to grunde til at have en startskærm, den ene er for at vise hvem der har lavet applikationen og den anden er hvis der skal hentes meget data online. I denne prototype er det kun for at vise hvem der har lavet applikationen, men hvis applikationen videreudvikles kunne det tænkes det blev nødvendigt at starte et asynkront task til at hente data i bagrunden Mainmenu.java Main menu aktiviteten laver ikke så meget andet end at holde styr på de 5 knapper der pt. er i menuen. den har en initcontrol funktion som holder øje med de forskellige knapper og hvad der skal ske når der er trykket på en knap.

35 35 Figur 30: initcontrol() fra Mainmenu.java initcontrol finder de fem knapper via deres unikke id. Derefter sættes en onclicklistener for hver knap som hvis den registrerer at knappen bliver trykket ned så kører en ny funktion som for alle mainmanu.javas knapper starter en ny aktivitet. Hvis knappen about er trykket ned startes funktionen GoAbout() som starter en aktiviteten about og dermed navigerer til en ny side i applikationen. figure 31: goabout Newuser.java Newuser aktiviteten bruges som klassen også hentyder til at lave nye brugere med. En bruger skal opgive navn, alder, køn erfaring og har mulighed for at for at angive nærmere hvilken slags erfaring. Der findes ikke tjek for om der er indtastet noget så det er muligt at få programmet til at gå ned ved bare at klikke videre. Layoutet for newuser ses i figur 32, der er sat et tjek på alder så kun tal kan indtastes. Figur 32: ny bruger skærm

36 36 Køn og erfaring er implementeret som to radiogrupper hvor man skal vælge en, og en er valgt fra starte som default. Ligesom for de almindelige knapper sætter der en listerner op denne gang er det en onchange som kører en switch hver gang der bliver ændret på knapperne som sørger for at sætte strengene for de to radiogrupper. Funktionen on change med switch statementen: figur 33: Onckeckchanged GoNext funktionen som bliver kaldt ved tryk på næsteknappen bruger intent.putextra funktionen som beskrevet i afsnit 4.1. den sender username og de tre score parametre videre til næste aktivitet. En af de vigtigere ting i GoNext er at insertuser() bliver kaldt. insertuser funktionen tager de bruger valgte værdier og sætter ind i users.db den lokale SQLite databse. Som det fremgår bruger insert-metoden DBHelper.java figur 34: insertuser()

37 37 Tilbage kalder knappen GoBack som kun indeholder en linje finish(); denne linje afslutter den nuværende aktivitet, og på den måde kommer man tilbage til den forrige aktivitet, da android stabler(stacker) aktivisterne og i princippet ikke lukker dem medmindre man beder om det eller aktiviteten bliver for gammel så android selv lukker den ned for at gøre plads til nye aktiviteter Loaduser.java Loaduser kaldes når brugeren trykker start spil. Her har brugeren mulighed for at vælge den bruger profil som skal bruges i spillet. Hvis ikke der i forvejen er bruger i databasen stopper applikationen. De forskellige brugere bliver hentet fra databasen via DBHelper. Brugerne lægges i en spinner som på en måde fungerer som dropdown liste når der trykkes på listen vises listen i et view som ses i.. figur 35: hent bruger figur 36: spinnerlist koden bag som viser hvordan man bruger en Cursor som indeholder data fra databaseforespørgslen. Et string array oprettes hvor hver streng indeholder et brugernavn og et int array indeholder den række hvori strengen skal sættes ind. useradapter sættes med hvilket layout der skal bruges, med cursoren og de to arrays der blev lavet. userspinner sættes så med adaptereren og der sættes en listener op som tjekker valget af bruger. Koden bag kan ses i figur 37 Når en bruger er valgt og der trykkes næste kalder GoNext også til databasen og får score parametrene. GoNext sender også oplysningerne om brugen videre til PlayGame.java

38 38 figur: 37 spinner code PlayGame.java PlayGame er quiz aktiviteten i applikationen. Der er dog ikke så meget spil over det endnu da der kun bliver indhentet tre spørgsmål fra quiz.xml og der er pt. noget galt med den måde den registrer svarerne for spørgsmål 2 og tre. Først hentes værdierne fra den sidste aktivitet som bindes til de forskellige textviews. Derefter hentes spørgsmålene ind i et string array questions. Figur 38: PlayGame.java set up screens

39 39 Som det ses i den sidste linje i figur 38 som er med køres game så længe integeren i som er en public integer der starter på nul. Integeren bruges både til at køre spillet men som det også ses i figur bruges den også til aflæse de forskellige strenge fra question som bruges til at sætte quizzen op. figur 39: game funktion Når en bruger har valgt sit svar og trykker næste sendes værdien af i videre som integeren j i GoNext metoden. I go next tjekkes der for om svaret er korrekt. Derefter vises det korrekte svar og updatescore med i som argument. figur 40: næste spørgsmål Update score opdaterer alle textviews der indeholder noget med score og clearer alle svar-knapperne og tæller i op med 7 og kalder game med den nye værdi.

40 40 figur 41: update score funktionen Som det ser, er updateuser ud kommenteret da den ikke er gjort færdig. Ydermere fejler applikationen efter tre spørgsmål, men det vigtige er at vise konceptet med quizzen Quit.java skal i fremtiden loade et lektions spørgsmål som brugeren får stillet lige før bekræft quit bliver trykket. GoQuit har en metode hvor som kalder hjem skærmen og lukker aktiviteten. Figur 42: quit der resterende aktiviteter/java klasser About.java og Highscore.java laver ikke noget interessant da de ikke er fuldt implementeret endnu, highscore skal holde en top 5 over de bedste bruger lokalt og en top 5 over de globale brugere.

41 Database og dataindsamling Der er implementeret en SQLite database til at holde de forskellige brugere og deres score. Den lokale database skal i første omgang fungerer før en den online database oprettes. Så for prototypen er den lokale database eneste sted der er dataindsamling. DBHelper.java er en hjælper klasse som har diverse funktioner til at hente data. Den er langt fra færdig da der bl.a. mangler metoder som get highscore og update user. At have en databasehjælper klasse er altid en god idé da man samler alle de querys der kunne være og implementerer dem i den og derefter kan metoderne kaldes fra de andre klasser. Figur 43: fetchallusers Metoden i figur 43 viser bare en af mange metoder og funktioner men de fleste fungerer på samme måde. fetchalluser() returnerer et string array alle brugere og bliver brugt i loaduser.java. Videreudvikles prototypen kan det overvejes om quizzen skal være database drevet i stedet, da man ville kunne monitorerer udviklingen af brugerne bedre, og man ville kunne lave en algoritme som sørgede for at man kom alle spørgsmål igennem før en bruger fik gentagelser. Algoritmen kunne også sørge for at stille spørgsmål indenfor de kategorier hvor brugeren klarer sig dårligst. 4.5 Applikations elemeter der mangler at blive implementeret. Under de følgende punkter vil de ikke implementerede elementer fra design og analysen blive gennemgået. Der vil blive redegjort hvorfor de er blevet fravalgt og i nogle tilfælde et forslag til hvordan elementet kan implementeres Reminder Reminderen er ikke blevet implementeret eftersom at den ikke tilføjer applikationen mere værdi andet end den selvfølgelig gør opmærksom på at det snart er tid til at bruge noget tid på førstehjælp. Hvis en reminder skal implementeres på et senere tidspunkt bruges ideen fra designafsnittet om en reminder der kan indstilles efter hvor ofte brugeren vil have reminders, og at reminderen er en notifikation Mini games Det ville helt sikkert tilføre applikationen en enorm værdi hvis der bliver lavet en masse af disse små spil, men da det vil tage for lang tid for en person at implementerer og lave grafisk til prototypen. Får man en aftale i hus om et møde med en partner skal der findes mindst et minigame. Da Laerdal har flere af disse minigames fordelt på andre applikationer kunne man overvejre at hente et eller to af dem ind i applikationen.

42 Fejlhåndtering Eftersom det er en prototype og en mail ville blive fyldt op med en masse fejl hvis der blev sendt en hver gang den fejler i udviklingsfasen. Det er helt klart en god ting når man når et beta-test niveau da nogen test vil være ude af hænderne på udviklerne. Desuden skal der laves en masse tjeks rundt omkring i koden så man undgår at programmet stopper.

43 43 5 Test er tit et område der bliver forsømt, da tiden tit er knap til at få produkter færdige og er det bestemt også i dette tilfælde. Da det kun er en prototype har det fog ikke større konsekvenser end at man fortæller en eventuel partner hvad status er for applikationen. Det er først hvis eller når prototypen skal videreudvikles at tests begynder at blive rigtig vigtigt. Strategien for test af prototypen er systematisk black-box testning. Det er klart man som udvikler har nogle helt klare forventninger til hvad der sker i hver funktion hvis de bliver brugt som de er tænkt. Når man bl.a. har med en database at gøre er det væsentligt at de forventede værdier stemmer overens med de værdier der bliver gemt. Hvad sker der hvis der er oprettet to brugere med samme navn på telefonen og man prøver at spille videre som en af dem? Ved at lave noget systematisk blak-box test må der også tænkes i scenarier som helt sikkert går galt. Er man klar over hvor ting bør går galt ved man også hvor der skal sættes ind. Det vigtigste er at få tjekket alle de områder der kan tjekkes systematisk. For denne prototype kunne man sætte forskellige tests op i følgende kategorier: Lav bruger, Load bruger, tjek knapper, tjek quiz, lektions spørgsmål og crash test. For at demonstrere princippet og teste lidt på applikationen er følgende skema sat op for lav bruger fordelen er man kan tilgå databasen og tjekke værdierne hvor nogle af de andre kategorier kan være svære at måle på: Scenarie Forventet resultat 1. gå til ny bruger 2. indtast test1 i navn i alder 4. klik kvinde 5. klik nej 6. indtast other i andet 7. klik næste Username: test1 Userage: 99 Usersex: kvinde Experience: nej other: other Korrekt 1. gå til ny bruger 2. indtast test2 i navn i alder 4. klik mand 5. klik ja med kørekort 6. indtast 999 i andet 7. klik næste 1. gå til ny bruger 2. indtast intet i navn i alder 4. klik mand 5. klik ja andet 6. indtast other i andet 7. klik næste Username: test2 Userage: 1000 Usersex: mand Experience: ja med kørekort other: 999 Username: Userage: 98 Usersex: mand Experience: ja andet other: business Fejl se under test2 i figur Fejl se under blank i figur

44 44 figur 44: users.db Som det ses af resultatet er der noget galt omkring valg af køn der er desværre ikke tid til at udbedre denne fejl inden første prototype afleveres, men det viser at disse systematiske black-box tests kan være ret brugbare. Da der ikke er mere test-tid grundet skred i tidsplanen er der ikke foretaget yderligere systematiske tests. Der er og dog testet løbende for at tjekke funktionaliteten af applikationen og som nævnt i implementeringsafsnittet er der flere steder der mangler nogle tjeks så applikationen ikke fejler. Status for applikationen er at den virker i meget begrænset omfang og der er en del fejl.