J2ME portabilitet. Afgangsprojekt på IT-Diplomuddannelsen ved Ingeniørhøjskolen i København

Transkript

1 J2ME portabilitet Afgangsprojekt på IT-Diplomuddannelsen ved Ingeniørhøjskolen i København Dato: Studerende: Vejleder: Birger Andersen Side 1

2 Indholdsfortegnelse 1. Indledning Problemformulering Mål og formål Metode Afgrænsninger 4 2. Java 2 Micro Edition platformen J2ME evolution Connected Limited Device Configuration (CLDC) Mobile Information Device Profile (MIDP) Andre API'er Enheder, der understøtter J2ME 8 3. Udviklingsværktøj Udviklingsmiljøer Introduktion til J2ME Wireless Toolkit J2ME Wireless Toolkit - historik J2ME Wireless Toolkit - emulatorer Palm OS Emulator J2ME hardware Anvendte mobile enheder MIDP for Palm OS Demo applikationer Højniveau brugergrænseflade (UIDemo) Label Date Field Alerts Choice Group Gauge Image Item List Text Field /Text Box Ticker Lavniveau brugergrænseflade (games - PushPuzzle) 31 Side 2

3 5.3 Kommunikation (Connection Framework) Lagring af data (RMS) Andre overvejelser ifm. portabilitet Sundhed.dk vejviser - baggrund Sundhed.dk - Vejviser Proof of concept ProofOfConcept MIDlet Overvejelser ifm. proof of concept Afgrænsning Sundhed.dk vejviser - analyse og design Karakterisering af applikationen Beskrivelse af brugssituationen Identificering af opgaver Skitsering af opgaver Design af applikationsforløb Udkast til skærmbilleder (mock-up) Sundhed.dk vejviser - programmering og test Samlet konklusion Forkortelser Litteraturliste 59 Bilag 1 Udviklings- og projektmiljøet 62 Bilag 2 J2ME Wireless Toolkit splash screens 63 Bilag 3 J2ME Wireless Toolkit emulatores 65 Bilag 4 Kildekode til sundhed.dk vejviser prototype 69 Bilag 5 Udvalgte portabilitet-problemstillinger 76 Bilag 6 Tabel- og figuroversigt 78 Side 3

4 1. Indledning Denne rapport udgør sammen med de tilhørende udviklede applikationer mit afgangsprojekt på IT-Diplomuddannelsen ved Ingeniørhøjskolen i København, Center for Videreuddannelse. 1.1 Problemformulering Baggrunden for at vælge Java 2 Micro Edition (J2ME) portabilitet som emne er dels et ønske om at udfordre min umiddelbare begejstring for Java som enhedsuafhængigt udviklingssprog og dels en interesse for at undersøge de karakteristika, som den nedskalerede Java 2 Micro Edition medfører i forhold til Java 2 Standard Edition (J2SE) eller Java 2 Enterprise Edition (J2EE). Det forudsættes, at læseren har et grundlæggende kendskab til Java generelt, samt et overordnet kendskab terminologi og struktur i relation til J2ME. 1.2 Mål og formål Projektets formål er at identificere og belyse forskellige faktorer og egenskaber, som udviklere af J2ME applikationer bør være opmærksom på og med fordel kan vælge at tage hensyn til i forhold til portabiliteten af en given applikation. Målet med projektet er at dokumentere disse faktorer og egenskaber i denne rapport, at inddrage dette kendskab i design og udviklingen af en konkret applikation, samt at uddrage en samlet konklusion af erfaringerne. 1.3 Metode Den metode, jeg har valgt til dette, er igennem relevant litteratur og ved egne afprøvninger at undersøge og kommentere relevante egenskaber samt at prøve dem i praksis ved at designe og påbegynde udvikling af en konkret J2ME applikation. Ifm. udviklingen afprøves en systemudviklingsmetode, som er målrettet denne type applikationer. Derudover diskuteres overvejelser omkring valg/fravalg af funktionalitet samt konkrete programmeringsmæssige udfordringer i relation til portabiliteten. 1.4 Afgrænsninger Det er ikke indenfor rammerne af dette projekt at give en udtømmende gennemgang af alle faktorer og egenskaber for de forskellige grene eller generationer af J2ME. Med hensyn til udviklingen af applikationen, er fokus at uddrage et tilstrækkeligt sæt af erfaringer ikke at udvikle et fuldt driftmodent produkt. Side 4

5 2. Java 2 Micro Edition platformen Java 2 Micro Edition er, som navnet antyder, en udgave af Java 2, som er målrettet et segment af apparater, som i høj grad er defineret ved deres relativt begrænsede kapacitet mht. processorkraft, hukommelse, netværkshastighed mv. 2.1 J2ME evolution Som med andre dele af Java foregår udviklingen af J2ME i forskellige projekter i den såkaldte Java Community Process (JCP), som definerer nye standard API er. De to grundlæggende API er i relation til J2ME er CLDC og MIDP, som tilsammen udgør en given enheds run-time environment (JRE). Tendensen i øjeblikket er, at ud over den generelle modning af de grundlæggende standarder, stiger mængden af nye API er kraftigt i takt med udvidelsen af de mobile enheders kapacitet og funktionalitet Connected Limited Device Configuration (CLDC) I J2ME er der defineret to grundlæggende konfigurationer: Connected Device Configuration (CDC) og Connected Limited Device Configuration (CLDC). En konfiguration i denne sammehæng er en Java Virtual Machine (JVM) med et tilhørende sæt af grundlæggende klasser, der som udgangspunkt er en reduceret udgave af J2SE tilpasset egenskaberne for apparater og enheder med relativt begrænset kapacitet. CLDC er den konfiguration, som typisk anvendes på mobiltelefoner og PDA er. Pga. disse enheders store og stigende udbredelse, er det relevant at fokusere på netop denne konfiguration ifm. en vurdering af portabiliteten af J2ME. Begrænsningerne omfatter en række forhold omkring VM ens interne håndtering af objekters livscyklus, ligesom faciliteter som reflektion og understøttelse af Java Native Interface (JNI) er sparet væk. Klasserne i CLDC er begrænset til fire packages: java.io java.lang java.util javax.microedition.io Derudover håndteres verificeringen af klasser forskelligt, idet den proces som ellers foregår i VM en er for tung og derfor erstattet af en proces, hvor klasser verificeres ifm. kompileringen (preverify). CLDC 1.0 blev frigivet i år 2000 som første udgave af denne JVM med grundlæggende klasser tilpasset ressourcebegrænsede enheder. Side 5

6 CLDC 1.1 fra marts 2003 indeholder en række forbedringer og udvidelser, hvor en af de væsentligste er understøttelse af tal og oprerationer med flydende komma (floating point). Et overblik og uddybende information om CLDC findes hos Sun: Mobile Information Device Profile (MIDP) Oven på konfigurationen findes såkaldte profiler, hvor den relevante i denne sammenhæng er Mobile Information Device Profile (MIDP). Profiler udvider sættet af klasser med faciliteter, som understøtter en bestemt gruppe enheders særlige egenskaber. Det kan typisk være krav til enhedens grænseflade så som skærm, mulighed for at give input til enheden (fx taster) eller apparatets evne til at afspille simple lyde. Andre væsentlige faktorer er fx understøttelse af og krav om evnen til at lagre data persistent, samt understøttelse af bestemte kommunikationsprotokoller. På den måde understøtter den definerede profil på den ene side enhedens egenskaber, men begrænser på den anden side sin anvendelse til enheder, som lever op til disse krav. MIDP 1.0 blev frigivet i september 2000 og indeholder basale men brugbare faciliteter bl.a. med det formål at vinde bred anerkendelse og udbredelse blandt producenter og udbydere af mobile apparater/enheder. Enheder, der lever op til MIDP 1.0, opfylder som minimum bl.a. krav om en skærm på mindst 96*54 pixels i 1 bit farvedybde (dvs. sort/hvid) samt mulighed for input fra enten et tastatur (standard telefon-taster eller QWERTY) eller fra en berøringsfølsom skærm. Derudover er der krav om 2-vejs trådløs netværksmulighed, hvilket betyder at HTTP protokollen kan benyttes. Udover udvidelser til de eksisterende packages fra CLDC udvider MIDP 1.0 sættet af packages med: javax.microedition.lcdui javax.microedition.midlet javax.microedition.rms Der er imidlertidig også usikkerhedsmomenter som fx manglende præcisering af krav til hukommelseskapacitet og håndtering af tråde, hvilket potentielt udgør risici ifm. portabiliteten af applikationer imellem disse enheder. Side 6

7 MIDP 2.0 fra 2002 indeholder en række nye egenskaber som fx udvidelse af faciliterer i brugergrænsefladen, en decideret understøttelse af spil, samt understøttelse af HTTPS protokollen. Igen er der udvidelser af eksisterende packages, og derudover udvider MIDP 2.0 sættet af packages med: javax.microedition.lcduigame javax.microedition.media javax.microedition.media.control javax.microedition.pki MIDP 2.0 anbefaler, men stiller ikke direkte krav om, større skærmopløsning og farvedybde. Til gengæld er mulighederne i brugergrænsefladen kraftigt udvidet med nye komponenter samt ændrede og forbedrede faciliteter. Understøttelse af netværk er udvidet med flere protokoller, heriblandt HTTPS. Derudover er der enkelte andre forbedringer i API erne, men udover disse er over-the-air (OTA) provisioning, dvs. evnen til at levere og installere applikationer trådløst, blevet et krav, hvor denne mulighed i MIDP 1.0 kun var anbefalet. Et overblik og uddybende information om MIDP findes hos Sun: Andre API er I takt med de mobile apparaters stigende udbud af nye faciliteter og funktioner udvikles og frigives der også i stigende grad nye API er til at understøtte disse. Som eksempler kan nævnes: Mobile Media API (MMAPI) - javax.microedition.media Wireless Messaging API (WMA) - javax.wireless.messaging PDA Optional Packages - javax.microedition.pim og javax.microedition.file Bluetooth javax.obex og javax.bluetooth Mobile 3D Graphics API - javax.microedtion.m3g En længere liste over package navne fra november 2004 kan ses på: Det er en væsentlig faktor at denne standardisering af API er er med til at gøre programmering op mod de nye faciliteter og funktioner generel og dermed sikre så optimale forhold for portabiliteten som muligt. Derudover er det den fordel ved fragmenteringen af API erne at det giver udviklerne mulighed for at skræddersy applikationer til givne enheders egenskaber uden at skulle trækkes med et overhead af API er som enhederne ikke understøtter. Side 7

8 Samtidig må man dog ifm. valg af løsning ved udvikling af applikationer være opmærksom på den begrænsning i portabilitet det giver at benytte de givne API er overfor enheder som ikke understøtter dem. Et af de nyeste tiltag med i relation til J2ME API er er Java Technology for the Wireless Industry (JTWI), som på den anden side forsøger at skabe et nyt højere niveau for en standard platform ved at samle egenskaber som efterhånden er relativt udbredte for mobiltelefoner og på den måde at skabe et konsistent fundament for udviklingen af nye applikationer. Således er grundlaget for JTWI en kombination af de eksisterende standarder CLDC 1.0 og MIDP 2.0 sammen med Mobile Media API og Wireless Messaging API. Udover de ovennævnte standarder kan der være funktionaliteter i de mobile enheder, som ikke på samme måde er generelt understøttet, men hvortil de enkelte producenter har frigivet egne proprietære API er. Anvendelse af disse kan naturligvis være ønskelig og tilsigtet, men begrænser i sagens natur portabiliteten i endnu højere grad. Endelig skal man være opmærksom på, at der kan være enheder med funktioner eller faciliteter som normalt ville være understøttet af nyere standard-api er, men som ikke kan udnyttes på de givne enheder, fordi de kun understøtter tidligere udgaver af API erne. Et eksempel på dette er Palm PDA er som kan have infrarød port (IrDA), men hvor MIDP for Palm OS 1 kun understøtter CLDC 1.0/MIDP 1.0 og dermed ikke giver adgang til enhedens infrarøde port. 2.2 Enheder, der understøtter J2ME Det kan være svært løbende at have overblik over udvalget af enheder, der understøtter J2ME. Et godt udgangspunkt for at danne sig et indtryk af den aktuelle udvikling er at slå op i den J2ME Device List, som findes på Sun Developer Network: Listen er omfattende, men ikke nødvendigvis udtømmende. Den indeholder imidlertid information om aktuelle og kommende enheders egenskaber, ikke mindst software, og kan på den måde give et fingerpeg om hvor bredt en given standard understøttes, samt hvor modent markedet er mht. understøttelse af nye standarder. En tilsvarende liste med lidt anderledes søge- og filtreringsmuligheder samt tilhørende kommentarer findes på Micro Developer Network (tidl. Micro Java Network): 1 MIDP for Palm OS understøttes fra Palm OS 3.5 Side 8

9 3. Udviklingsværktøj Selv om udviklingsværktøjer ikke som sådan har direkte betydning for J2ME s portabilitet, er emnet relevant at inddrage i denne sammenhæng på grund af det historiske perspektiv og dets faciliteter til understøttelse af de forskellige API er. 3.1 Udviklingsmiljøer Som til udvikling af J2SE og J2EE applikationer, findes der også til udvikling af J2ME applikationer en palette af udviklingsmiljøer og værktøjer. En del af disse værktøjer er udvidelser eller plug-ins der integreres i eksisterende kommercielle og ikke-kommercielle udviklingsværktøjer som fx, Eclipse ME, Borland og Forte. Har man et foretrukkent udviklingsmiljø, kan det være en god idé at undersøge om og i givet fald hvordan det kan bringes til at understøtte udvikling i J2ME. Til dette projekt har jeg valgt at benytte Sun s eget gratis udviklingsmiljø: J2ME Wireless Toolkit, som er tilgængeligt via deres hjemmeside: Toolkittet fungerer oven på Java 2 Standard Edition, så til udvikling er det en forudsætning, at standard Java SDK 2 er installeret, ikke mindst pga. javac compileren. Hvis man kun har brug for at eksekvere fx de medfølgende demoprogrammer, er det tilstrækkeligt at have Java Runtime Environment (JRE) installeret. Toolkittet indeholder ikke en editor, så det står en frit for at vælge selv. Til dette projekt har jeg valgt den gratis JCreator 3.50 LE fra Xinox Software: Introduktion til J2ME Wireless Toolkit J2ME Wireless Toolkit er et sæt værktøjer, som støtter udviklingen af Javaprogrammer til små trådløse enheder. Sættet består af en række værktøjer, hvoraf KToolbar er det primære ifm. selve udviklingsprocessen, idet det er i dette værktøj, man bygger, tester og pakker sine applikationer. Nedenstående figur med tilhørende oversigt viser de enkelte værktøjer og forklarer kort deres funktion: 2 Java SDK (Software Development Kit), tidligere benævnt JDK (Java Development Kit). Side 9

10 Figur 3.1: J2ME Wireless Toolkit 2.2 J2ME WTK værktøjer Default Device Selection Documentation Ktoolbar OTA Provisioning Preferences Run MIDP Application Utilities Funktion Værktøj til at vælge hvilken emuleret enhed, der skal være default. Overordnet dokument, som henviser til bl.a. den essentielle API dokumentation og Toolkit ets User s Guide. Selve udviklingsværktøjet, hvor man bygger, tester og pakker sine applikationer. Dette værktøj samler også adgangen til de øvrige værktøjer. Simulerer rigtig installation af applikationer via emuleret application management software. (Nyt værktøj fra WTK 2.0) Mulighed for at tilpasse egenskaber for de emulerede enheder. Værktøj til at eksekvere en specifik applikation (.jad fil) i emulatoren. Et sæt af små værktøjer til at konfigurere og måle forskellige faktorer omkring applikationen. Inkluderede til og med WTK en PRC Converter. Side 10

11 3.3 J2ME Wireless Toolkit - historik Efterhånden som J2ME API erne har har udviklet sig, er Sun s Wireless Toolkit fulgt med i understøttelsen af de nye faciliteter samtidig med at de til stadighed bestræber sig på at være bagudkompatible. Udviklingen foregår i spor som hver især følger en kombination af CLDC- og MIDP-versionerne. Nedenstående tabel viser en kronologisk oversigt over væsentlige frigivne versioner: J2ME tidslinie Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 CLDC 1.0 / MIDP _ _02 CLDC 1.0 / MIDP _01 CLDC 1.1 / MIDP _01 2.2b 2.2b b Tabel 3.1: J2ME Wireless Toolkit kronologisk oversigt over versioner Som det ses, foregår udviklingen fortsat i flere parallelle spor, samtidig med at der er en tendens til at der frigives versioner hyppigere i takt med den tidligere omtalte accellerering i mængden af tilgængelige API er. Senest er der fx frigivet en ny udgave af version næsten samtidig med den nyeste version 2.2. Dette harmonerer godt med anbefalingen om, at man som udvikler af MIDP 1.0 applikationer stadig tester kompatibiliteten med emulatorer i den grundliggende platform, selvom man evt. anvender en nyere version af toolkit et i sin udviklingsproces. Denne anbefaling er også, selvom den relaterer sig til emulator-niveauet, i nogen grad med til at sikre en højere grad af portabilitet. Device Toolkit version DefaultColorPhone * ** *** DefaultGrayPhone * ** MinimumPhone Motorola_i85s PalmOS_Device RIMJavaHandheld MediaControlSkin ** *** QwertyDevice ** *** * ** *** PalmOS_Device udgået i version 1.0.4_02 Ændret design og egenskaber siden version Ændret design og egenskaber siden version 2.0 Ændrede egenskaber siden version 2.1 Tabel 3.2: J2ME Wireless Toolkit - tilgængelige emulerede enheder Side 11

12 Ovenstående tabel viser, hvilke emulatorer der er tilgængelige i de forskellige versioner af J2ME Wireless Toolkit. I næste afsnit gives en oversigt over nogle af emulatorernes egenskaber, hvoraf bl.a. de begrænsede skærmegenskaber for nogle af de tidlige emulatorer tydeligt fremgår. Frigivelsen af nye eller opdaterede versioner af API er afspejles løbende af tilsvarende indstillingsmuligheder i de nye versioner af J2ME Wireless Toolkit. Nedenstående skærmbillede viser den store palette af muligheder i version 2.2. Udvalget af muligheder udvides eller begrænses afhængig af den valgte platform. Figur 3.2: J2ME Wireless Tookit KToolbar project settings API Selection Side 12

13 3.4 J2ME Wireless Toolkit - emulatorer Som nævnt ovenfor har emulatorerne i J2ME Wireless Toolkit forskellige egenskaber, som man ifm. udvikling af applikationer kan benytte sig af i bestræbelserne på at sikre den ønskede grad af portabilitet. Det gælder både mht. systeminterne forhold i den centrale API er og forhold ifm. udforming af brugergrænsefladen, ikke mindst skærmens egenskaber. For at illustrere konkrete forskelle i emulatorernes egenskaber og skabe et overblik over dem, har jeg lavet en lille MIDlet kaldes SystemProperties, som viser CLDC og MIDP versioner samt den aktuelle enheds skærmegenskaber. Informationen for de enkelte emulatorer er samlet i nedenstående tabel grupperet efter WTK version: Device System Properties CLDC MIDP Skærm Gråtoner Farver / DefaultColorPhone * DefaultGrayPhone * MinimumPhone *54 2 Motorola_i85s * PalmOS_Device *142 2/4/ K RIMJavaHandheld * DefaultColorPhone * DefaultGrayPhone * MediaControlSkin * QwertyDevice * DefaultColorPhone * DefaultGrayPhone * MediaControlSkin * QwertyDevice * DefaultColorPhone * DefaultGreyPhone * MediaControlSkin * QwertyDevice * Antal farver/gråtoner på PalmOS_Device (Palm OS Emulator) kan vælges i Java HQ applikationen under Java Preferences se figur 3.3 på næste side. Tabel 3.3: J2ME Wireless Toolkit emulator egenskaber På de to næste sider vises også et eksempel på SystemProperties MIDletten i en emulator sammen med programkoden til de 2 klasser, som udgør MIDletten. Side 13

14 Figur 3.3: Palm OS farvevalg Figur 3.4: SystemProperties MIDlet» // ITD AFP F2005 // SystemProperties.java // import javax.microedition.midlet.*; import javax.microedition.lcdui.*; public class SystemProperties extends MIDlet { Canvasgrafik grafik = new Canvasgrafik(); public void startapp() { grafik.setdisplay(display.getdisplay(this)); Display.getDisplay(this).setCurrent(grafik); public void pauseapp() { public void destroyapp(boolean unconditional) { SystemProperties.java Side 14

15 // ITD AFP F2005 // Canvasgrafik.java // import javax.microedition.lcdui.*; public class Canvasgrafik extends Canvas { private Display display; public void paint(graphics g) { // slet baggrunden g.setcolor( 0x00ffffff ); // hvid g.fillrect(0, 0, getwidth(), getheight()); Font fontplain = Font.getFont(Font.FACE_SYSTEM, Font.STYLE_PLAIN, Font.SIZE_MEDIUM); Font fontbold = Font.getFont(Font.FACE_SYSTEM, Font.STYLE_BOLD, Font.SIZE_MEDIUM); g.setcolor( 0x ); // sort g.setfont(fontbold); g.drawstring("system Properties", 0,0,Graphics.TOP Graphics.LEFT); g.setfont(fontplain); g.drawstring(system.getproperty("microedition.configuration"), 0,10,Graphics.TOP Graphics.LEFT); g.drawstring(system.getproperty("microedition.profiles"), 0,20,Graphics.TOP Graphics.LEFT); g.drawstring(getwidth() + "*" + getheight(), 0,30,Graphics.TOP Graphics.LEFT); g.drawstring(display.numcolors() + " " + (display.iscolor()? "colors" : "greys"), 0,40,Graphics.TOP Graphics.LEFT); public void setdisplay(display d) { this.display = d; Canvasgrafik.java Side 15

16 3.4.1 Palm OS Emulator Som det fremgår af tabel 3.2 udgik understøttelsen af Palm OS emulatoren med frigivelsen af J2ME Wireless Toolkit 1.0.4_02. Da netop denne emulator matcher den fysiske Palm m500 enhed, der anvendes ifm. dette projekt, har jeg imidlertid valgt fortsat at anvende emulatoren i projektets analyser. Dette afsnit beskriver kort nogle få faktorer ifm. anvendelsen af Palm OS Emulator. Efter installation af J2ME Wireless Toolkit eller 1.0.4_01, er enheden PalmOS_Device blandt valgmulighederne, når man enten skal angive default device eller vælge en aktuel enhed ifm. eksekvering af et projekt i KToolbar. Selve emulatoren til enheden følger dog ikke med toolkit installationen og skal således anskaffes og installeres separat. Emulatoren består af tre dele, som her er angivet med de versionsnumre, som er anvendt ifm. dette projekt: Palm OS Emulator 3.5 Palm OS Emulator Skins 1.9 Palm OS Platform Release ROMs Udover selve emulator-programmet drejer det sig altså om såkaldte skins, som repræsenterer brugergrænsefladens visuelle del inkl. placering af bruger-input samt ROM images, som er Palm enhedens binære kerne/operativsystem. Alle tre dele er en forudsætning for at emulering af enheden virker. De findes i forskellige versioner fra forskellige udbyder af PalmOS kompatible enheder. Det er iøvrigt også muligt at kopiere ROM en direkte fra en fysisk enhed. Emulatoren med de tilhørende elementer, som er anvendt ifm. dette projekt, er tilgængelig via PalmSource s website (gratis, men kræver registrering): Når man har installeret Palm OS Emulator efter de medfølgende anvisninger, kan den benyttes via J2ME Wireless Toolkit. Første gang, man eksekverer en applikation på emulatoren skal man dog lige angive placeringen af emulatoren for på den måde at sammenkæde toolkit et og emulatoren, her forkortet POSE (se figur 3.5). Side 16

17 Figur 3.5: J2ME Wireless Toolkit - Palm OS Emulator (POSE) Location I selve Palm OS emulatoren findes der en række indstillingsmuligheder, som giver mulighed for at bestemme de aktuelle egenskaber for emulatoren, som fx hvilken enhed (skin), der skal emuleres. Udover det default skin, som er vist i figur 3.3, findes der i den aktuelle installation skins, som repræsenterer en Palm V og en IBM WorkPad c3 (se figur 3.6 og 3.7). Figur 3.6: Palm V emulator Figur 3.7: IBM WorkPad c3 emulator Side 17

18 Figur 3.8: About Palm OS Emulator Selve Palm-enheden betjenes som andre (telefon-)emulatorer vha. musen. En væsentlig forskel i denne sammenhæng, og således også i relation til næste kapitels analyser af portabilitet, er at den berøringsfølsomme skærm i Palm OS Emulator også betjenes direkte med musen. Ved eksekvering af en applikation via J2ME Wireless Toolkit, foretages en installation af MIDletten i Palm OS emulatoren, hvorefter applikationen startes. MIDletten er herefter iøvrigt tilgængelig i PalmOS grænsefladen sammen med Java HQ, som er JVM en (se figurerne 3.9 og 3.10). Figur 3.9: Java applications i PalmOS Figur 3.10: About Java HQ En række egenskaber for skærm, netværk og hukommelse kan sættes for selve applikationen eller globalt for hele JVM en. Det foregår enten via et menupunkt i Side 18

19 MIDletten eller fra Preferences knappen i Java HQ. Et eksempel på skærmdialogen til at sætte disse indstillinger ses ved figur 3.3. Til test ifm. udvikling af J2ME applikationer på nyere PalmOS-baserede platforme findes nu også, til supplement af eller afløsning for Palm OS Emulator, en såkaldt Palm OS Simulator. Hvor Palm OS Emulator er en hardware emulering, jfr. anvendelsen af ROM images, er Palm OS Simulator derimod en udgave af PalmOS, som er kompileret til Intel platformen og eksekveres ovenpå et hardware- og et enhedsabstraktionslag. Dels fordi Palm OS Simulator ikke på samme måde som Palm OS Emulator er integreret i Sun s J2ME Wireless Toolkit, og dels af tidsmæssige årsager, har jeg fravalgt at arbejde med simulatoren i dette projekt. Man kan læse mere om detaljerne ved Palm OS Simulator og downloade den via: De nyere versioner af Palm OS understøtter bl.a. CLDC 1.1 og MIDP 2.0. Palm- Source s information om Java til Palm OS tager udgangspunkt i denne side: For generel information om udvikling til Palm OS henvises til denne side: For specifik information om IBM WebSphere Everyplace Micro Environment (WEME, også kaldet J9 VM) henvises til enten palmone eller IBM: Side 19

20 4. J2ME hardware Ifm. udvikling af applikationer testes disse som udgangspunkt på de relevante emulatorer, som indgår i WTK installationerne. At en applikation virker efter hensigten i en emulator er imidlertid ingen garanti for, at den virker tilfredsstillende i en tilsvarende fysisk enhed fx mobiltelefon eller PDA. En række forskellige forhold gør sig gældende i den sammenhæng og kan være årsag til væsentligt anderledes brugeroplevelser eller endog deciderede fejl: fysisk-logiske begrænsninger af ressourcer som fx hukommelse i enheden. anderledes logisk håndtering internt (af fx tråde) og eksternt (fx netværk). deciderede fejl eller andre uregelmæssigheder i operativsystem eller JVM. udseende og ikke mindst betjening ifm. brugerens håndtering af applikationen på enheden. Derfor er det vigtigt, at man også tester applikationer på fysiske enheder, inden de frigives. Hvor omfattende en sådan test bør være kan afhænge af, hvilke elementer der indgår i applikationen samt en subjektiv vurdering af, hvor kritisk en problemfri bred portabilitet er for applikationens succes. For seriøse producenter og udbydere af mobile applikationer er der naturligvis meget stor fokus på test af kompatibilitet, idet det er et væsentligt økonomisk grundlag for deres virksomhed. Derfor er det essentielt for dem at teste deres applikationer ekstensivt på alle relevante eksisterende og kommende enheder på markedet for at kortlægge og løse evt. kompatibilitetsproblemer. Dette er i sagens natur en ressourcekrævende opgave, som ikke let lader sig automatisere og derfor kræver en høj grad af menneskelig indsats. Uden at gå ind i større markedspolitiske betragtninger, betyder det at nogle producenter ser en fordel i at flytte denne del af udviklingsprocessen til lavindkomstlande i fx Østeuropa eller Asien. 4.1 Anvendte mobile enheder Som nævnt i afsnit 2.2 kan man fx hos Sun orientere sig om egenskaberne for et udvalg af fysiske mobile enheder. Til dette projekt har jeg haft tre enheder til rådighed ifm. analyse af portabiliteten for forskellige forhold samt udviklingen af den applikation, hvor jeg vil forsøge at drage egne erfaringer omkring disse. De tre enheder er en Palm m500 PDA samt to telefoner hhv. en Nokia 3510i og en Sony Ericsson K500i (se figur 4.1). Device System Properties CLDC MIDP Skærm Gråtoner Farver Palm m *65 2/4/16 Nokia 3510i * Sony Ericsson K500i * Tabel 4.1: Anvendte mobile enheder og deres egenskaber Side 20

21 Disse enheder repræsenterer både ældre og nyere konfigurationer, hvilket kan ses af deres egenskaber, som er beskrevet i tabel 4.1 ovenfor på samme måde som emulatorerne tilbage i tabel 3.3. Palm m500 Nokia 3510i Sony Ericsson K500i Figur 4.1: Anvendte mobile enheder Nærmere information om enhederne kan findes hos de respektive producenter: MIDP for Palm OS Understøttelse af J2ME er ikke indbygget i Palm OS. Sun har dog lavet et Java Runtime Environment kaldet MIDP for Palm OS 1.0, som er en J2ME implementering baseret på CLDC 1.0 og MIDP 1.0, optimeret til Palm OS 3.5 og implicit efterfølgeren 4.0. Pakken, som udover selve MIDP også indeholder en PRC converter og eksempler på MIDlets kan downloades via Sun Developer Network: Dokumentationen, som downloades separat samme sted, beskriver bl.a. udførligt detaljerne i Palm- dialekten af MIDP, dvs. hvordan forskellige grundlæggende elementer i brugergrænsefladen for at passe ind i Palm OS sædvanlige grænseflade repræsenteres anderledes end fx på de emulatorer som følger med J2ME Wireless Toolkit. Eksempelvis kan nævnes abstrakte kommandoers placering bag Palm-enhedens normale menu-knap (nederst til venstre), eller de særlige forhold Side 21

22 der gør sig gældende, når betjeningen foregår direkte via den berøringsfølsomme skærm. Både selve MIDP og MIDlets iøvrigt installeres på Palm-enheder som andre Palm OS applikationer ved at overføre dem i Palm Resource (PRC) format via det normale synkroniseringsværktøj. MIDP, et medfølgende udvikler-værktøj og nogle MIDlets findes allerede i som.prc filer og kan installeres/synkroniseres uden videre. For at overføre en egenudviklet MIDlet, skal den først konverteres til en.prc fil. Denne proces foregår vha. et PRC Converter Tool (se figur 4.2), som er en del af MIDP for Palm OS. Med dette værktøj lokaliserer man simpelthen sin MIDlets.jad fil og implicit den tilhørende.jar fil, hvorefter de ved et tryk på en knap konverteres til en.prc fil, som kan synkroniseres til Palm enheden. Figur 4.2 PRC Converter Tool PRC Converter Tool er iøvrigt som det ses, naturligvis et java program. Side 22

23 5. Demo applikationer For at vurdere portabiliteten af de grundlæggende elementer i J2ME / MIDP har jeg valgt at tage udgangspunkt i nogle af de demo-applikationer, som følger med J2ME Wireless Toolkit. Tabel 4.1 nedenfor viser en oversigt over, hvilke applikationer, de enkelte versioner af toolkit et kommer med: Application Toolkit version photoalbum UIDemo demos games mmademo audiodemo NetworkDemo SMSDemo FPDemo JSR172Demo WMADemo BluetoothDemo ObexDemo PDAPDemo Demo3D C:\J2mewtk C:\WTK104 C:\WTK20 C:\WTK21 C:\WTK22 Tabel 5.1: J2ME Wireless Toolkit demo applikationer Som det fremgår af tabellen, følger udviklingen af demo-applikationer det stigende antal forbedringer og udvidelser af API erne, som netop er baggrund for hver ny version af toolkit et. Ifm. test af portabilitet finder jeg det dog relevant at analysere forskellene med udgangspunkt i de applikationer, som er gennemgående i alle generationer af toolkit et og demed API erne. Til formålet har jeg valgt: UIDemo demonstrerer en række high-level ui komponenter games PushPuzzle som repræsentant for low-level interfacet demos demonstrerer lagring af data og netværkskommunikation Da det i sagens natur primært er i forbindelse med brugergrænsefladen, at man som bruger af mobile applikationer vil observere evt. forskelle i funktionaliteten, vurderer jeg, at disse gennemgående applikationer vil dække de mest væsentlige elementer, som kræver belysning i denne sammenhæng. Side 23

24 I dette kapitel vil jeg således kort gennemgå eksempler på de enkelte designelementer. Gennemgangen belyser relevante forhold ifm. portabilitet ved at illustrere og sammenligne elementernes repræsentation på forskellige generationer af emulerede enheder. De nedenstående skærmbilleder er fra Palm OS Emulator samt Default Color Phone i hhv. MIDP 1.0 og 2.0. Skærmbillederne præsenteres i netop den rækkefølge fra venstre mod højre eller oppefra og ned. MIDP 2.0 eksemplerne afspejler i nogen grad de skærmelementer, som den version blev udvidet med. Hvor det er relevant suppleres gennemgangen med beskrivelser af elementernes repræsentation og evt. særlige forhold ifm. dette på et lille udvalg af fysiske håndholdte enheder. De enheder, jeg har til rådighed, er kort beskrevet i næste afsnit. 5.1 Højniveau brugergrænseflade (UIDemo) I højniveau brugergrænsefladen (High Level UI) er det i høj grad enhedernes eget ansvar at repræsentere og placere elementerne så godt som muligt efter programmørens anvisninger. Programmøren har således mulighed for at angive ønskede egenskaber for skærm-elementerne, men kan ikke bestemme den faktiske placering. I portabilitets-sammenhæng er udvikleren dermed som udgangspunkt i nogen grad friholdt fra ansvar for en kompatibel funktionalitet på forskellige enheder, men samtidig prisgivet, hvis enheden ikke placerer elementerne fornuftigt Label Figur 5.1: Label eksempler Som det ses, repræsenteres labels forskelligt afhængigt af type, hvis det er muligt i enhedens skriftstype. Derudover er der forskel på, om kolon anvendes. På Palm OS indrykkes dele af teksten uhensigtsmæssigt. Side 24

25 5.1.2 Date Field Felter til angivelse af dato og tid betjener sig typisk af enhedernes interne funktion til det samme. Figur 5.2: Date Field Palm OS Ifm. det kombinerede dato-/tidsfelt er der den forskel, at ved angivelse af datoen alene sættes tidspunktet i Palm OS til 12:00, mens det i MIDP-emulatorerne sættes afhængigt af den aktuelle system-tid. Igen uheldig ledetekst på Palm OS. Figur 5.3: Date Field MIDP 1.0 Figur 5.4: Date Field MIDP 2.0 Side 25

26 5.1.3 Alerts Generelt er der 5 typer alerts: info, warning, error, alarm og confirmation. Alle typerne kan enten vises tidsbegrænset eller modalt, dvs. at brugeren skal kvittere for meddelelsen. Som det ses af nedenstående figurer, vises alerts i Palm OS oven på det eksisterende skærmbillede, mens de i MIDP optager hele skærmen. Figur 5.5: Timed Alert I Palm OS indikeres timede alerts med en nedtælling. MIDP 1.0 har ingen tidsindikator, men i MIDP 2.0 kan man slå en tidsindikator til. En modal alert svarer i øvrigt blot til en time et alert, men med tids-egenskaben uendelig (forever). Figur 5.6: Modal Alert I Palm OS indikeres alert-typen med forskellige ikoner, og alarmen har en anderledes lyd. I MIDP er alert-typerne identificeret ved hver sin lyd. På fysiske enheder er alerts iøvrigt typisk være suppleret med vibration, hvis denne mulighed er tilgængelig og slået til på enheden. Side 26

27 5.1.4 Choice Group Figur 5.7: Choice Group Mht. choice group er de vigtigste ting at bemærke sig i relation til portabilitet, at ikke alle platforme er i stand til at vise evt. tilhørende grafik/ikoner, samt at den nye pop-up mulighed i MIDP 2.0 sprænger rammerne i forhold til tidligere versioner, hvor alt i højniveaugrænsefladen var enten i fuldskærm eller layoutelementer i en fuldskærm Gauge De enkelte plaformes repræsentation af målestokken gauge kan variere en del, hvilket kan have synlig indflydelse på brugergrænsefladen, men ellers ingen praktisk betydning ifm. portabilitet. Figur 5.8: Gauge Karakteristika er, at den interaktive gauge i Palm OS ikke har en bjælke, men en tal-værdi og skyggede pile til at indikere minimum (0) og maksimum (30). MIDP 2.0 har nye indikatorer til aktivitet af ubestemmelig varighed. Side 27

28 5.1.6 Image Item Figur 5.9: Image Item / Custom Item Ifm. billeder er det ikke garanteret, at den af programmøren anviste placering (alignment) kan opfyldes se fx MIDP 1.0 eksemplet ovenfor. I Palm OS eksemplet er billedet faktisk centreret, men i data-delen, som er højre side af skærmen. I MIDP 2.0 udgaven af UIDemo er Image Item erstattet af Custom Item List Der er tre slags lister: exclusive, implicit og multiple. Da de præsenteres stort set konsistent på en given platform, har jeg for nemheds skyld valgt en type liste for hver platform i eksemplet nedenfor. Figur 5.10: List Som ved choice group understøtter ikke alle platforme billeder ifm. lister. På berøringsfølsomme enheder som Palm en, er det iøvrigt ikke altid nødvendigt eller relevant med en bjælke til at markere den aktuelle position i en liste. Side 28

29 5.1.8 Text Field / Text Box Til indtastning af data findes både felter som et element på en skærm (field) og felter, som fylder hele skærmen (box). Da de to typer har stort set ens egenskaber, beskrives de her under ét. Felterne findes i særlige versioner målrettet bestemte typer data. Således er der udover et generelt indtastningsfelt, hvor alt er tilladt, målrettede versioner til tal-værdier, telefonnummer, adresse, password og fra MIDP 2.0 også til decimal-tal. Figur 5.11: Text Field Fælles for felterne er, at de benytter platformens egne muligheder for indtastning af data (se figur 5.12), herunder for Palm OS platformen mulighed for input via enten Grafitti 3 eller virtuelt keyboard samt redigeringsmuligheder som fx klippe og klistre via berøringsgrænsefladen eller menuer. På mobiltelefonen er et eksempel den særlige side med specialtegn. Ved afprøvningen af funktionerne ifm. denne gennemgang skiftede MIDP 1.0 enheden iøvrigt automatisk til fuldskærmstilstand ved indtastning i et felt. Øvrige observationer fra gennemgangen af relevans for portabiliteten: felter havde ikke validering af input (gyldigt format). I Number felter kan kun indtastes cifre dog også bogstaver via Palm OS keyboard. I Phone felter kan bogstaver indtastes formateres i MIDP emulatorerne til amerikansk format (### ### ####). Password indtastes i Palm OS synligt i en dialogboks, hvorefter feltværdien skifter til -Assigned-. På telefonerne indtastes et synligt tegn af gangen, hvorefter det skjules med * (se figur 5.13). URL felter havde ikke validering af input (gyldigt format). 3 Grafitti er Palm OS platformens koncept for håndskriftgenkendelse. Side 29

30 På de fysiske mobiltelefoner er funktionaliteten af Phone-feltet understøttet af en ekstra integration til enhedens egen brugergrænseflade, nemlig muligheden for opslag i telefonnumre fra enhedens telefonbogsfunktion. På samme måde kunne man forestille sig opslag af allerede lagrede adresser eller URL er. Palm OS understøtter ikke denne integration til platformens egen systemfunktionalitet/ applikationer. Figur 5.12: Platformens egen normale input funktionalitet Figur 5:13: Indtastning af password Side 30

31 5.1.9 Ticker Også ticker en, som er den vandret scrollende tekst øverst på skærmen er iflg. specifikationerne understøttet på enhederne. Fra MIDP 2.0 kan ticker en udover på strukturerede skærme i højniveaubrugergrænsefladen som i MIDP 1.0 nu også tilknyttes ustrukturerede skærme som lavniveaubrugergrænsefladens Canvas. Det samme gælder iøvrigt muligheden for at tilknytte en titel til skærmen. Figur 5.14: Ticker En særlig egenskab i Palm OS er, at ticker en, som ellers kun optager pladsen til højre for titlen, kan bringes til at fylde hele bredden ved at klikke på den. 5.2 Lavniveau brugergrænseflade (games - PushPuzzle) I lavniveau brugergrænsefladen (Low Level UI) er det i udpræget grad udviklerens ansvar at sørge for at præsentere skærmens information på fornuftig vis. I og med at al information i denne skærmtype tegnes eksplicit på skærmen, må programmøren sørge for at placere og skalere informationen, så indholdet til enhver tid passer til skærmens størrelse. Som eksempel på en MIDlet, som benytter sig af lavniveau brugergrænsefladen har jeg valgt PushPuzzle fra games suiten. Det første sæt af eksempler er fra Palm OS indstillet til 16 gråtoner. Lavniveau brugergrænsefladen i Palm OS åbner (i Java-indstillingerne) mulighed for at supplere betjeningen via knapper ved at indsætte en virtuel keypad i højre eller venstre side af skærmen. På den måde forsøges kompensere for de manglende fysiske taster på Palm enheden, men på applikationer (spil) hvor fingerfærdighed er påkrævet, er den virtuelle keypad i praksis ikke brugbar. Som det ses, indgår abstrakte kommandoer i menu-strukturen sammen med Palm s egne menupunkter. Derudover findes de højt prioriterede som knapper, som dog kan vælges fra også via Java-indstillingerne. Side 31

32 Figur 5.15: PushPuzzle på Palm OS Bemærk iøvrigt applikationens evne til at tilpasse sig den aktuelle skærmstørrelse. Som det ses af nedenstående eksempel er applikationen egentlig i farver, som dog er afstemt, så de også skelnes med blot få gråtoner. Pga. forskellen i spil-elementernes forskel i form, fungerer spillet endog med blot 2 gråtoner, altså i sort/hvid. Hver især elementer, som er med til at øge applikationens portabilitet. Som det ses af nedenstående eksempler er der forskel i præsentationen af de abstrakte kommandoer i menuerne. I MIDP 1.0 er de tilgængelige via en fuldskærmsmenu, mens de i Palm OS som nævnt indgår i den normale grænseflade som menupunkter og evt. knapper. I MIDP 2.0 eksemplet ses de i den nye popup-menu form. Figur 5.16: PushPuzzle på MIDP Bemærk iøvrigt, hvordan applikationen i MIDP 2.0 eksemplet ikke er skaleret ned, men i stedet for virker ved at man scroller hen over spillepladen (2D windows/ viewport). Dette kan være en praktisk mulighed som alternativ til at skalere ned efter skærmens størrelse. Fx bliver visse baner på en Nokia 3510i så små, at spilelementer kun fylder 1 pixel. Side 32

33 5.3 Kommunikation (Connection Framework) Brugergrænsefladen som beskrevet tidligere er naturligvis en yderst væsentlig faktor ifm. en J2ME applikations portabilitet, idet enhedernes skærmog inputegenskaber udgør brugerens primære oplevelse af en MIDlet. Understøttelse af netværkskommunikation indgår også i specifikaltionen, men er i sagens natur en mere usynlig del af applikationen. Også her kan der dog være væsentlige elementer at lægge mærke til ifm. funktionaliteten. Ikke at de nødvendigvis er en del af J2ME specifikationerne, men selv som en del af en given enheds standard-funktionalitet, har de betydning for brugerens oplevelse af applikationen. Figur 5.17: MIDP connection Til at eksemplificere faktorer ifm. kommunikation har jeg valgt Stock MIDletten fra demos suiten. Bemærk iøvrigt ifm. valg af MIDlet i suitens menu, at visning af tilhørende ikoner på samme måde som med højniveau brugergrænseflade-elementerne fra tidligere heller ikke nødvendigvis understøttes på dette eksterne 4 niveau (se figur 5.18). Eksempler på elementer ifm. kommunikation, som kræver handling fra brugeren er fx MIDP 2.0 enhedens verificering af, om det er OK at bruge airtime (figur 5.19), og at man i Palm OS aktivt skal slå netværksmuligheden til (figur 3.3) demos (Stock) Figur 5.18: MIDlet suite MIDlets menu 4 Med ekstern menes her, at MIDlet-ikoner konfigureres ifm. MIDlet suitens projektegenskaber og dermed eksternt i forhold til at ikoner til brugergrænseflade-elementer er en del af den enkelte MIDlets programlogik. Side 33

34 Verificering af, om der rent faktisk er hul igennem til enhedens netværksforbindelse sker ved almindelig afprøvning af, om der kan læses aktuelle data. Da det i J2ME er relativt simpelt at etablere en HTTP forbindelse, er en sådan nok et oplagt valg. Konkret viser testen i denne gennemgang aktuelle aktiekurser fra for Sun Microsystems (SUNW) og Pixar Animation Studios (PIXR) på hver af de tre gennemgående emulatorer i dette projekt (se figur 5.19). Figur 5.19: Stock MIDlet Stock Tracker Bemærk iøvrigt, at det af hensyn til brugerens opmærksomhed på, at han er online (koster penge) er anbefalet for enheden at have en indikator ifm. netværksaktivitet. Ifm. denne test ses, at Palm OS har en sådan pulserende indikator nederst til højre. De to telefon-emulatorer har ikke umiddelbart indikatorer, men det er dog principielt accepteret, at anvende den bekræftelse af brug af airtime, som er omtalt ovenfor. 5.4 Lagring af data (RMS) Det andet usynlige element fra MIDP 1.0 er understøttelsen af persistent lagring af data, altså af J2ME s Record Management System (RMS). I relation til vurdering af portabilitet er relevansen af dette emne alt andet lige relativt begrænset, idet det blot forudsættes at lagermediet virker. Der er dog alligevel et par betragtninger at overveje. Dels er der den faktiske performance på de fysiske enheder. Denne type lagermedie er relativt langsom, så hvis man er nødt til at have tunge læse/skrive processer, kan det være relevant at udføre dem i sin egen tråd, ligesom det kan være relevant at holde brugeren orienteret om aktiviteten via brugergrænsefladen. Derudover kan der være tale om ting som JVM-implementeringens robusthed overfor evt. fejlsituationer ved læsning eller skrivning, fx ved problemer med adgangen til ressourcerne eller pga. fejl i program-logikken (fx. ikke-parede open-close statements). Side 34

35 I denne gennemgang er der eksempler på succesfuld RMS-aktivitet både ifm. håndteringen af aktuelt level i PushPuzzle og ifm. lagringen af aktie-information i Stock-applikationen. Der er heller ikke observeret uregelmæssigheder med eksemplerne på de fysiske enheder. 5.5 Andre overvejelser ifm. portabilitet Igennem mine undersøgelser ifm. dette projekt er jeg stødt på en række konkrete problemstillinger, man skal overveje at tage hensyn til. Her et par eksempler: Understøtter kun.png billedfiler som standard Evt. intolerance ifm. open() - close() parring i RMS Forskellig tolkning af layout Blank eller ej ifm. ledetekster på Palm Erfaringen viser, at man med baggrund i sit kendskab til platformens faldgruber dels må undersøge de konkrete forhold omkring en given applikations egenskaber og dels sørge for at teste applikationen på alle relevante platforme. Side 35

36 6. Sundhed.dk vejviser - baggrund For selv at drage erfaringer med aktuelle problemstillinger omkring portabilitet ifm. udvikling af mobile applikationer / MIDlets i relation til observationerne tidligere i denne rapport, har jeg valgt at afprøve en konkret udviklingsprocess af en mobil applikation. 6.1 Sundhed.dk Vejviser Den applikation, jeg har valgt at arbejde med, er en mobil udgave af vejviseren på Den fælles offentlige sundhedsportal, sundhed.dk. Valget af netop denne løsning udspringer i et behov for at vurdere to eller flere modeller for mobil tilgang til sundhed.dk som internetportal. Den ene tilgang kunne være at konfigurere en ren mobil-portal udgave af sundhed.dk med en rent internet-/browserbaseret tilgang til portalens grænseflade og funktionaliteter med udgangspunkt i fx konfigurering af en decideret mobil-venlig grænseflade på sundhed.dk s webserver (IBM WebSpere Portal Server). Denne mulighed er ikke indenfor rammerne af denne rapport. Figur 6.1: Eksempler på browserbaserede mobile løsninger ( og Den anden tilgang er at udvikle en eller flere mobile applikationer målrettet konkret funktionalitet på sundhed.dk. For at vurdere denne mulighed, har jeg valgt Sundhed.dk s Vejviser som repræsentativ funktionalitet, idet jeg mener den dels har relevans som mobil applikation, og dels har en informationsmængde og struktur som egner sig til mobile enheder. Derudover er vejviseren langt den mest brugte tjeneste på sundhed.dk i øjeblikket. Også derfor kan den tjene som en god model for den ene halvdel af en Side 36

37 vurdering af om browser- eller MIDlet-løsningen er en god idé ifm. evt. fremtidige overvejelser om mobile sundhed.dk-tjenester. Samtidig er det min vurdering, at en implementering af Vejviser-funktionaliteten vil dække relevante dele af J2ME-/MIDP-arkitekturen: - forskellige high-level interface-elementer - netværkskommunikation - begrænset, men ikke-triviel navigation Som udgangspunkt er der ikke behov for arkitektur-elementer som fx low-level interface-elementer eller persistent storage, men de vil i det omfang det viser sig muligt forsøges inddraget i løsningen også. 6.2 Proof of concept For at vurdere om det i det hele taget ville være muligt at konstruere en mobil udgave af sundhed.dk s vejviser, som baserer sig på den eksisterende udgave i form af internetportalen, har jeg med udgangspunkt i HttpExample.java lavet et hurtigt proof of concept på om det kunne lade sig gøre at få et brugbart svar ved at konstruere en relevant URL ProofOfConcept MIDlet URL en er konstrueret ud fra et kendskab til strukturen fra praktiske forsøg med søgning i vejviseren på internettet. Derudover har jeg til denne test valgt en søgning, som jeg på forhånd ved kun giver 1 resultat. Først vises kildekoden til test-midletten, derefter det udsnit af emulator-skærmbilledet som viser søgeresultatet og til sidst outputtet fra toolkit-konsollen med testens mellemresultater. // ITD AFP F2005 // ProofOfConcept.java // import javax.microedition.midlet.*; import javax.microedition.lcdui.*; import javax.microedition.io.*; import java.io.*; public class ProofOfConcept extends MIDlet implements CommandListener { private Command exitcommand; private Display display; private Form displayform; Side 37

38 public ProofOfConcept() { displayform = new Form("Proof of Concept"); try{ String result = getviahttpconnection(" SOEG_ATTRIBUTE_NAVN=klamer&SOEG_ATTRIBUTE_ORG_TYPE_PRAESENT=0& SOEG_ATTRIBUTE_ORG_TYPE=0&SOEG_ATTRIBUTE_AMT=0&SOEG_KORT_KONT AKTINFORMATION=1"); displayform.append(" " + result); catch (Exception exc){ exc.printstacktrace(); exitcommand = new Command("Exit", Command.SCREEN, 1); displayform.addcommand(exitcommand); displayform.setcommandlistener(this); public void startapp(){ display = Display.getDisplay(this); display.setcurrent(displayform); public void pauseapp(){ public void destroyapp(boolean unconditional) { public void commandaction(command c, Displayable s){ if (c == exitcommand) { destroyapp(false); notifydestroyed(); private String getviahttpconnection(string url) throws IOException { HttpConnection connect = null; InputStream inputs= null; StringBuffer buffer = new StringBuffer(199); try { connect = (HttpConnection)Connector.open(url); inputs = connect.openinputstream(); int ch; while ((ch = inputs.read())!= -1) { buffer.append((char)ch); finally { if (inputs!= null) inputs.close(); if (connect!= null) connect.close(); Side 38

39 String val = parse(buffer.tostring()); System.out.println("val.length()=" + val.length()); System.out.println(val); return val; private String parse(string str) { int tracker1 = str.indexof("ico_vk_hus"); System.out.println("keyword: " + tracker1); int marker1 = str.indexof("<div>", tracker1); System.out.println("marker1: " + marker1); int marker2 = str.indexof("<br>", marker1+1); System.out.println("marker2: " + marker2); int marker3 = str.indexof("<br>", marker2+1); System.out.println("marker3: " + marker3); int marker4 = str.indexof("<br>", marker3+1); System.out.println("marker4: " + marker4); int tracker2 = str.indexof("ico_vk_telefon"); System.out.println("keyword: " + tracker2); int marker5 = str.indexof("<div>", tracker2); System.out.println("marker5: " + marker5); int marker6 = str.indexof("<br>", marker5+1); System.out.println("marker6: " + marker6); String str1 = str.substring(marker1+5, marker2).trim() + "\n"; String str2 = str.substring(marker2+4, marker3).trim() + "\n"; String str3 = str.substring(marker3+4, marker4).trim() + "\n"; String str4 = str.substring(marker5+5, marker6).trim() + "\n"; return(str1 + str2 + str3 + str4); ProofOfConcept.java Figur 6.2: Proof of Concept MIDlet Side 39

40 Running with storage root DefaultColorPhone keyword: marker1: marker2: marker3: marker4: keyword: marker5: marker6: val.length()=82 Finn Klamer Prà stbrovej 238, Ã?ster Jà lby 7950 Erslev Telefon: Execution completed bytecodes executed 41 thread switches 741 classes in the system (including system classes) 4440 dynamic objects allocated ( bytes) 3 garbage collections (92624 bytes collected) ProofOfConcept - Console output Overvejelser ifm. proof of concept Resultatet af ovenstående proof of concept er, at det beviseligt kan lade sig gøre at fremsøge relevant information ved at konstruere en passende søge-url. Der har dog allerede ifm. testen vist sig nogle problematikker som kræver nærmere bearbejdning: Eksemplet virker ikke i MIDP 1.0, idet svaret fra søgningen ser ud til at være for langt for MIDletten at håndtere. Det er ifm. testen ikke afklaret, om problemet skyldes begrænsninger i http input stream en eller i stringbufferen. Det er et tegnsæt problem ifm. fx de danske bogstaver æ, ø og å. Der er behov for forbedringer ifm. håndteringen af HTML-elementer. Svar-tiden opleves som ventet relativt lang pga. det overhead der er ved at læse data fra en hel HTML-side meget i denne sammenhæng overflødig information. Side 40

41 6.3 Afgrænsning Dette projekt omfatter alene design og udvikling af dele af en konkret J2ME applikation / MIDlet, og vurderinger udledt deraf. Projektet afgrænser sig således fra at belyse andre mobile løsningsmuligheder af den valgte eller andre funktionaliteter. Derudover er det kendt, at den til rådighed værende data-kilde direkte fra sundhed.dk s standard internetportal-grænseflade via http ikke er en ideel og på sigt praktisk anvendelig model. Men da der i øjeblikket ikke er andre offentligt tilgængelige kilder til de relevante data, må denne model af konceptet acceptere og i vurderingen tage højde for de begrænsninger i performance, det vil give. Hvis man hos sundhed.dk vælger at arbejde videre med mobile tjenester, kan dette projekt måske i stedet tjene som katalysator for, at der stilles mere relevante data-kanaler til rådighed. 7. Sundhed.dk vejviser analyse og design Da jeg vurderer, at et full-scale udviklingsprojekt efter Unified Process langt vil overstige behovet i relation til den aktuelle applikation, har jeg valgt at tage udgangspunkt i en væsentligt mindre designmodel, som er målrettet udviklingen af J2ME-applikationer/MIDlets. Den valgte model er fra MIDP 2.0 Style Guide [BLOCH] 5 og omfatter seks trin: 1. Karakterisering af applikationen 2. Beskrivelsen af en brugssituation (Usage Case / Use Case (UP)) 3. Identificering af opgaver 4. Skitsering af opgaver 5. Design af applikationsforløb 6. Udkast til skærmbilleder Dette suppleret med konkret viden om den eksisterende implementering af vejviseren på sundhed.dk danner herefter udgangspunkt for selve udviklingsprocessen. 7.1 Karakterisering af applikationen Beskrivelse af applikationen i én sætning: Denne applikation gør det muligt for brugeren at søge kontaktinformation om sundhedsfaglige organisationer på tværs af det danske sundhedsvæsen via trådløse mobile enheder Beskrivelse af en brugssituation 5 se litteraturlisten Side 41

42 Eksempel på en usage case: Familien Hansen er på ferie i sommerhus på Fanø for første gang. Søndag aften får familiens ældste barn, Emil på 8 år, uforklarlige mavesmerter. Emils forældre føler sig utrygge ved situationen og har brug for at konsultere til lægevagten. Da de ikke kender forholdene i området, søger de vha. Sundhed.dk s mobile vejviser efter telefonnummeret på lægevagten i Ribe Amt. Vejviseren finder fire telefonnumre til lægevagter i Ribe Amt. Det ene telefonnummer er til lægevagten på Fanø, så det noterer de sig og ringer med det samme for at søge hjælp Identificering af opgaver Baseret på beskrivelsen af brugssituationen defineres umiddlebart to primære opgaver: Søgning efter kontaktinformation (fx telefonnummer) Præsentation af kontaktinformation 7.4 Skitsering af opgaver Da idéen med denne opgave er at prøve at implementere en mobil udgave af en allerede eksistende applikation, anvendes denne applikations nuværende skærmbilleder som udgangspunkt i stedet for at skitsere noget manuelt fra bunden. Hvor det er relevant vurderes den nuværende applikations egenskaber så med baggrund i erfaringerne fra tidligere i dette projekt - i relation til faktorer der er relevante for transformeringen til en mobil platform og evt. relevante betragtninger i relation til portabilitet. Den eksisterende implementering af vejviseren på Den fælles offentlige sundhedsportal, sundhed.dk er tilgængelig via Vejviser i den vandrette menu øverst på forsiden af portalen (se figur 7.1). Derudover findes der flere steder på portalen, bl.a. på forsiden, en lille udgave af vejviseren med overskriften Find adresse. Det er ikke den udgave af brugergrænseflade, der tages udgangpunkt i, men pga. portlettens relativt lille størrelse kan dens udformning jo godt tjene til inspiration for den mobile løsning. Selve den primære vejviser-brugergrænseflade indgår som en portlet i et større skærmbillede med øvrig navigationsmuligheder på portalen (se figur 7.1). For lige at præcisere, er det Find adresse fanebladet i selve portletten, der tjener som skitse i denne analyse, og ikke de øvrige elementer. Side 42

43 Figur 7.1 Sundhed.dk forside og Vejviser Side 43

44 Som udgangspunkt forsøges det primære søge-billede transformeret til MIDP med så høj grad af genkendelighed som muligt, dog med to væsentlige ændringer: For at skabe en genkendelig kontekst, indsættes sundhed.dk logoet øverst til venstre på skærmbilledet. Logoet vurderes umiddelbart at have en kontrast, som ikke kræver en særlig sort/hvid udgave til enheder med gråtoner. Kommunefeltet udelades af to årsager. Med tanke på de begrænsede ressourcer på den mobile platform, skyldes det for det første at listen med alle landets kommuner fylder relativt meget, hvilket dels ville beslaglægge en relativt stor del af MIDlettens fodaftryk 6, og dels vil være relativt uhensigtsmæssig at overføre direkte til de fleste mobile enheders lille skærm. For det andet anvendes kommune-feltet i praksis stort set ikke, da brugerne umiddelbart relaterer sig mere til bynavn eller postnummer og således anvender disse felter til geografisk afgrænsning ifm. søgning. På søge-skærmbilledet mappes Søg knappen iøvrigt til en abstrakt kommando. Ifm. søgning er der en række mulige udfald, som hver især resulterer i forskellige efterfølgende skærmbilleder, som skitseres nedenfor. Figur 7.2: Vejviser - resultat af en tom søgning 6 Fodaftryk = footprint: et udtryk for den mængde RAM, som MIDletten optager i den mobile enheds hukommelse. Side 44

45 Figur 7.2 viser responsen ved en tom søgning, dvs. at brugeren umidelbart har valgt Søg uden at have defineret afgrænsende søgekriterier. I den mobile brugergrænseflade tænkes dette repræsenteret ved en modal Alert med en tilpasset udgave af figurens meddelelsestekst. Figur 7.3 viser responsen ved en søgning, som ikke har givet noget søgeresultat. Også her er den mobile pendant at vise en tilpasset version af meddelelsesteksten som en modal Alert. En mere passende kort tekst kunne fx være: Din søgning gav ingen relsultater. Prøv at tilpasse dine søgekriterier.. Figur 7.3: Vejviser - søgning med ingen resultater Et søgning kan uanset brugerens anstrengelser indeholde resultater fra flere forskellige underområder (til et sundhedsområde). Fx kan en søgning på lægevagten i et givent amt give resultater for både Lægevagten eller Tandlægevagten eller en søgning på sygehus kan give resultater i de forskellige organisatoriske enheder på et sygehus. En sådan situation repræsenteres ved et skærmbillede som i figur 7.4. Der findes ialt ca. 50 underområder, men det er ikke relevant at kende dette værdisæt i applikationen, da de i hvert tilfælde vil Side 45

46 kunne aflæses i søgeresultatet inkl. den tilhørende URL. På den måde vil det i MIDP være naturligt at repræsentere et sådant resultat som en implicit liste. Figur 7.4: Vejviser Vælg underområde Enten direkte som et respons på søgningen eller efter valg af underområde præsenteres selve søgeresultatet så. Hvis der kun er 1 resultat af søgningen (se figur 7.5), kan man i MIDletten umiddelbart præsentere søgeresultatet. I første version af applikationen vises alene navn, adresse og telefonnummer som resultat. Figur 7.5: Vejviser ét søgeresultat Side 46

47 Figur 7.6: Vejviser flere søgeresultater (modificeret fra 10 til 4) Hvis der er flere søgeresultater, vises disse som en liste med op til 10 resultater på hver side. Figur 7.6 illustrerer dette (modificeret fra 10 til 4 resultater pga. pladsen på siden). Side 47

48 Da en sådan liste vurderes at være for uoverskuelig på mobile enheder, vises i MIDletten først en implicit liste alene med navnene, som ved valg resulterer i adresse og telefonnummer (gemt ifm. søgeresultatet) som beskrevet under situationen med ét søgeresultat. Hvis der er flere søgeresultater end der kan være på en side, etableres en abstrakt kommando: Næste side. På sundhed.dk kan links i søgeresultatet give adgang til uddybende information om den givne sundhedsfaglige, afhænig af typen. Fx har praktiserende læger (se figur 7.7) og tandlæger en praksisdeklaration, som dog er udformet forskelligt. Informationer fra praksisdeklarationer indgår ikke i første version af Sundhed.dk s mobile vejviser. Figur 7.7: Vejviser - praksisdeklaration Side 48

49 7.5 Design af applikationsforløb Med udgangspunkt i ovenstående skitser illustreres applikationens forløb imellem skærmbillederne Alert: Tom søgning (7.2) Alert: Ingen resultater (7.3) Søge-input (7.1) Vælg underområde (7.4) 1 søgeresultat (7.5) Flere søgeresultater (7.6) Figur 7.8: Vejviser - applikationsforløb Udgangspunktet er skærmbilledet med søgekriterier. I tilfælde af en tom søgning eller ingen søgeresultater vises en alert, og der returneres til udgangspunktet. Resultat af søgningen kan resultere i tre forskellige situationer/skærmbilleder. Den simpleste er ved ét søgeresultat, hvor man umiddelbart kan præsentere resultatets informationer (navn, adresse og telefonnummer). I tilfælde af flere end et resultat (i samme underområde) præsenteres listen over resultater (hvert resultat angivet med navn). Fra listen kan man vælge et resultat og gå direkte til dennes informationer. I tilfælde af at der er flere sider, kan der bladres videre til næste side i samme format. Hvis resultatet/-erne falder i flere underområder, vises listen med de mulige valg. Efter valget vises enten en liste over resultater eller selve resultatet, hvis der kun er et for det givne underområde. Side 49

50 I den nuværende form, hvor der navigeres via de eksisterende internet-sider, detekteres den aktuelle situation efter søgningen ved at søge efter karakteristika på de forskellige side-typer. 7.6 Udkast til skærmbilleder (mock-up) Denne del af udviklingsmodellen vurderes at være overflødig i dette projekt, da skærmbillederne fra skitseringen af opgaver er af høj/brugbar kvalitet og med tilhørende kommentarer udgør et tilstrækkeligt grundlag for programmering. Side 50

51 8. Sundhed.dk vejviser programmering og test Ifm. udviklingen er der brug for at kende værdisættene på de forudefinerede lister i søgebilledet. Figur 8.1 viser værdisættene fra vejviseren, hvoraf sundhedsområde (til venstre) og amt (i midten) skal anvendes, mens kommune (til højre) som tidligere nævnt ikke anvendes. Figur 8.1: Sundhed.dk vejviser - værdisæt Den URL, som anvendes til søgning konstrueres dels ud fra kendskab til strukturen fra praktiske forsøg med søgning i vejviseren på internettet, og dels ud fra syntax en i en søge-plug-in til vejviseren som er udviklet til Mozilla-baserede browsere som fx Firefox (se figur 8.2). Denne metode er som tidligere nævnt nok ikke praktisk anvendelig pga. det relativt store overhead, men anvendes ifm. dette projekt, fordi det pt. er den eneste adgang til de nødvendige data. # Sundhed.dk - Vejviser plugin # Created by Søren Thing Pedersen <stp@ag.aaa.dk> # Updated by Kenn A. Thisted <kat@sundhed.dk> <search version = "7.1" name="sundhed.dk - Vejviser" description="sundhed.dk - Vejviser" method="get" action=" searchform=" querycharset="utf-8" > Side 51

52 <input name="soeg_attribute_navn" user> <input name="soeg_attribute_org_type_praesent" value="0"> <input name="soeg_attribute_org_type" value="0"> <input name="soeg_attribute_by" value=""> <input name="soeg_attribute_kommune" value=""> <input name="soeg_attribute_postnr" value=""> <input name="soeg_attribute_amt" value="0"> <input name="soeg_kort_kontaktinformation" value="1"> <browser update= " updateicon= " updatecheckdays="3" > </search> Figur 8.2: Vejviser Mozilla søge-plug-in Figur 8.3: Organisationshierarki med SKS-koder for amter Side 52

53 De indtastede værdier fra søgebilledet kan anvendes direkte i URL en som strengværdier, og for sundhedsområde anvendes det indeks som det valgte område har i listen. For amter er det imidlertid nødvendigt at oversætte indeksværdien fra listen til en SKS-kode 7 jfr. figur 8.3. I udviklingsprocessen tages udgangspunkt i de skitserede skærmbilleder, og selve processen foregår i høj grad som prototyping. Konkret har jeg taget udgangspunkt i det første skærmbillede søgebilledet og arbejdet med muligheder og begrænsninger i dette. Dette billede er valgt både fordi det er det første, men også fordi det er det skærmbillede, hvor der er flest forskellige elementer at vurdere i relation til funktionalitet og portabilitet. Resultatet af den første udgave med en fuld liste af typen EXCLUSIVE med de faste værdier for sundhedsområde viste, at det ikke umiddelbart er en brugbar løsning. Palm OS håndterer det fint med en drop-down liste, mens både MIDP 1.0 og MIDP2.0 emulatorerne kun havde en uelegant liste af radio-buttons, hvilket for det første ikke umiddlebart er genkendeligt i forhold til portal-udgaven af vejviseren, og for det andet optager alt for meget plads til at fungere fornuftigt i praksis sammen med de øvrige felter (se figur 8.3). Figur 8.3: Prototyping af søge-skærmbilledet 7 SKS er Sundhedsstyrelsens Klassifikationssystem. Se evt. Side 53

54 Derfor valgte jeg i stedet at arbejde videre med den nye POPUP option for choice groups. Denne mulighed fungerer væsentligt bedre både i forhold til genkendeligheden og betjeningen. Den findes dog først fra MIDP 2.0, hvilket i sagens natur ikke er optimalt for bagud-kompatibiliteten og dermed portabiliteten. I koden er det en forholdsvis lille ændring, men altså et valg med konsekvenser: choicetype = new ChoiceGroup("Sundhedsområde:", Choice.EXCLUSIVE); // 1.0 choicetype = new ChoiceGroup("Sundhedsområde:", Choice.POPUP); // 2.0 På den måde opnår man en væsentlig mere brugervenlige grænseflade, hvor man altså bryder med MIDP 1.0 s alt er fuldskærm princip ved at introducere de dynamiske pop-op vinduer, for felterne sundhedsområde og amt (se figur 8.4): Figur 8.4: Søge-skærmbilledet i MIDP 2.0 Tilstanden for applikationen på tidspunktet for aflevering af projektet er, at: Søgebilledet virker tilfredsstillende på MIDP 2.0 enheder Logikken, der binder input fra søgebilledet sammen til en brugbar URL er på plads Således er selve søgningen faktisk på plads man kan fremsøge data efter samme kriterier 8 som på selve sundhed.dk. 8 med undtagelse af Kommune, som bevidst er fravalgt. Side 54

55 I den nuværende tilstand er der dog umiddelbart også ting, som ikke er løst: Præsentation af søgeresultat i emulatoren (findes pt. kun i konsol-vinduet) Håndtering af mere end et søgeresultat samt den videre navigering efter fremsøgning af søgeresultater Håndtering af lokalt tegnset Running with storage root DefaultColorPhone Type: Alle områder Name: klamer Zip : City: Region: Hele Danmark ATTRIBUTE_KOMMUNE=0&SOEG_KORT_KONTAKTINFORMATION=1&SOEG_ATTR IBUTE_ORG_TYPE=0&SOEG_ATTRIBUTE_NAVN=klamer&SOEG_ATTRIBUTE_POST NR=&SOEG_ATTRIBUTE_AMT=0&SOEG_ATTRIBUTE_ORG_TYPE_PRAESENT=0 val.length()=82 Finn Klamer Prà stbrovej 238, Ã?ster Jà lby 7950 Erslev Telefon: Figur 8.5: Console output ifm. seneste prototype Kildekoden til dette stadie af prototype-iterationerne samt de øvrige forberedende programmer findes på: Med udgangspunkt i denne adresse forventer jeg, at der arbejdes videre på denne prototype samt evt. andre MIDlets i relation til sundhed.dk. Da der indtil videre kun er tale om laboratorieforsøg og der som sådan ikke er konkrete planer fra sundhed.dk s side om at profilere mobile løsninger i relation til internetportalen, kan det ikke garanteres at materialet er tilgængeligt igennem længere tid. Side 55

56 9. Samlet konklusion Med baggrund i problemformuleringen og målet for dette projekt, finder jeg formålet opfyldt. Igennem mit arbejde med projektet har jeg ved at undersøge og afprøve forskellige problemstillinger opnået en tilstrækkelig forståelse for de parametre ifm. udvikling af J2ME-applikationer, som er afgørende for graden af portabilitet. Med udgangspunkt i det, har jeg fået et godt indtryk af udviklingen på J2ME platformen og er blevet i stand til at opstille kriterier, som kan danne grundlag for afvejninger og vurderinger i forhold til konkrete til- og fravalg ved design og udvikling af mobile Java-applikationer. Min konklusion i forhold til J2ME s portabilitet må være, at platformen ikke umiddlebart er så problemfrit tværgående, som jeg havde forventet eller håbet. Til gengæld er standarder, sprog og udviklingsværktøjer relativt let tilgængelige, samtidig med at der til stadighed fokuseres på nyudvikling. På den baggrund finder jeg bestemt fortsat J2ME relevant i konkurrence med de øvrige platforme på det mobile marked. De nærmeste fremtidsudsigter på J2ME platformen byder på en fortsat udvikling af standarder og værktøjer, som understøtter de mobile enheders stigende kapacitet og funktionalitet. Konkret er den første beta-udgave af J2ME Wireless Toolkit 2.3 netop blevet frigivet til download. Denne udgave bygger i sagens natur videre på version 2.2 med tilføjelse af understøttelse for flere nye API er. Med baggrund i den aktuelle udvikling af standarder og det kraftigt voksende marked for mobile håndholdte enheder, vil jeg lidt imod mine forventninger ved starten af dette projekt mene, at der skal vægtige grunde til at prioritere bagudkompatibilitet ved udvikling af nye applikationer. Udover de løbende forbedringer af platformen, som man i givet fald ville afskære sig fra, er omsætnignen i markedet så hurtig, at nye standarder er relativt kort tid om at nå en kritisk masse. Til gengæld kan det være af stor betydning at sikre portabilitet på tværs af enheder med en given valgt platform. Der kan naturligvis være politiske eller praktiske grunde til at vælge at prioritere bagudkompatibilitet i konkrete projekter. Dels kan det være et holdningsmæssigt eller principielt spørgsmål, og der kan være foretaget store investeringer i konkret infrastruktur som endnu ikke er afskrevet. Markedet for mobile Java-applikationer domineres utvetydigt af (low level UI) spil til mobiltelefoner. I den sammenhæng er deciderede forretningsapplikationer stort set endnu ikke bredt tilgængelige, men udvikles mere til konkrete formål indenfor afgrænsede områder. Et nyt område, som dog måske åbner muligheder i den retning er, at TDC netop er begyndt at forhandle Blackberry, som er nogle anderledes enheder (fx typisk Side 56

57 med fuldt tastatur), end vi ellers ser på det danske marked. Blackberry var faktisk med som emulering i de første Wireless Toolkits, og tager stadig udgangspunkt i den gamle CLDC 1.0/MIDP 1.0 platform, men med tillæg af en række egne platformsspecifikke API er. Side 57

58 10. Forkortelser AMS CDC CLDC J2EE J2ME J2SE.jad.jar JDK JVM MIDP OTA PDA.prc SDK VM WTK Application Management Software Connected Device Configuration Connected Limited Device Configuration Java 2 Enterprise Edition Java 2 Micro Edition Java 2 Standard Edition Java Application Descriptor (filtype) Java Archive (filtype) Java Development Kit Java Virtual Machine Mobile Information Device Profile Over-The-Air Personal Digital Assistent Palm Ressource (filtype) Software Development Kit [Java] Virtual Machine [J2ME] Wireless Toolkit Side 58

59 11. Litteraturliste Bøger [BLOCH] [DUGGER] [MAAS] Bloch, Cynthia, Annette Wagner MIDP 2.0 Style Guide for the Java TM 2 Platform, Micro Edition Sun Microsystems, Inc./Addison-Wesley, ISBN: Dugger, Mark, John Grimes Zen of Palm Designing Products for Palm OS PalmSource, Inc., 13. juni Maas, Brian Using Palm OS Emulator PalmSource, Inc., 25. februar 2003, Document no HW [MAHMOUD] Mahmoud, Qusay H. Learning Wireless Java TM O Reilly & Associates, Inc, ISBN: [MIDPDEV] Developer s Notes MIDP for Palm OS, Version 1.0 FCS Java 2 Platform, Micro Edition Sun Microsystems, Inc., oktober [MIDPUSER] User s Guide MIDP for Palm OS, Version 1.0 FCS Java 2 Platform, Micro Edition Sun Microsystems, Inc., oktober [MUCHOW] Muchow, John W. Core J2ME TM Technology & MIDP Sun Microsystems, Inc. / Prentice Hall, ISBN: [OSTREAM] Ostream, Jean Palm OS User Interface Guidelines PalmSource, Inc., 24. februar 2003, Document no HW Side 59

60 [RIGGS] [TOPLEY] Riggs, Roger, Antero Taivalsaari, and Mark VandenBrink Programming Wireless Devices with the Java TM 2 Platform, Micro Edition Sun Microsystems, Inc./Addison-Wesley, ISBN: Topley, Kim J2ME TM in a Nutshell O Reilly & Associates, Inc, ISBN: X [WTKUSER] Java 2 Platform, Micro Edition Wireless Toolkit User s Guide, versions Sun Microsystems, Inc., oktober 2001 oktober Internet ressourcer Sun Developer Network J2ME Documentation (udvalgte dokumenter) Sun Developer Network Connected Limited Device Configuration (CLDC) Sun Developer Network Mobile Information Device Profile (MIDP) Sun Developer Network FAQ J2ME Package Listing Sun Developer Network - J2ME Wireless Toolkit (udvalgte dokumenter) MIDP Style Guide 1.0a, August Sun Developer Network J2ME Devices Micro Developer Network Java Devices Benhui.net MIDP 2.0 Mobile Resources Side 60

61 Xinox Software - JCreator PalmSource Developers (udvalgte dokumenter) PalmSource Java Technologies PalmSource Palm OS Emulator Sun Developer Network MIDP for Palm OS Sundhed.dk Sundhed.dk Mozilla søge-plug-ins Side 61

62 Bilag 1 Udviklings- og projektmiljø Følgende hardware-enheder og software-versioner er anvendt ifm. dette projekt: Hardware Compaq Deskpro EN (Intel Pentium III 864 MHz, 512 MB RAM, 15 GB disk) Software Microsoft Windows Me (Millennium Edition) Microsoft Word 97 Mozilla Firefox Sun Java 2 Standard Edition Software Development Kit (SDK) v 1.4.2_05 Sun Java 2 Micro Edition Wireless Toolkit versioner 1.0.3, 1.0.4, 2.0, 2.1 og 2.2 Palm OS Emulator 3.5 Palm OS Emulator Skins 1.9 Palm OS Platform Release ROMs Palm Desktop for Windows Mobile enheder Palm m500 PDA Palm OS 4.0 MIDP for Palm OS 1.0 (Java HQ 1.0) Nokia 3510i telefon Sony Ericsson K500i telefon Side 62

63 Bilag 2 J2ME Wireless Toolkit splash screens Version (2001), (2002) og 2.0 (2003) Version 2.1 ( ) og version 2.2 (2004) Side 63

64 MIDP for Palm OS PRC Converter Tool Side 64

65 Bilag 3 J2ME Wireless Toolkit emulators Emulator Devices version og (80% størrelse) Side 65