1. Introduksjon til J2ME

Transkript

1 Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Introduksjon til J2ME Tomas Holt Lærestoffet er utviklet for faget SO350D J2ME for programmering av mobile enheter 1. Introduksjon til J2ME Resymé: I denne leksjonen skal vi se på hvordan J2ME er bygd opp. Vi skal også installere verktøy som vi skal bruke i kurset for å utvikle applikasjoner i J2ME, og se på hvordan disse brukes. Innhold 1. INTRODUKSJON TIL J2ME OM DENNE LEKSJONEN INTRODUKSJON HVORFOR J2ME? KONFIGURASJONER, PROFILER OG VALGFRIE API ER PROGRAMVARE DIN FØRSTE J2ME-APPLIKASJON/MIDLET PAKKING AV APPLIKASJONEN PUBLISERING AV APPLIKASJONEN TILSLUTT Om denne leksjonen Denne leksjonen omhandler kapittel 1-3 i læreboka, og er å oppfatte som en introduksjon til J2ME. Det kan nok være en fordel å lese leksjonen før du leser læreboka. Leksjonen henviser også stedvis til læreboka. 1.2.Introduksjon Mobile dataenheter blir stadig en viktigere del av folks hverdag. Mobiltelefoner er noe alle har, og det blir også vanligere med andre typer små datamaskiner. PDA (Personal Data Assistent) er ikke i dag uvanlig blant forretningsfolk. Biler blir utstyrt med navigasjonsutstyr, multimedia osv. Inntoget av slike enheter med begrenset datakraft setter også begrensninger på programmene som kan kjøres på enhetene. Tunge beregninger som tar flere sekunder på en PC vil typisk ta mange ganger så lang tid på en mobiltelefon. På samme måte har mobiltelefoner begrensede skjermstørrelser, noe som begrenser hva som kan vises på skjermen.

2 Feil: Fant ikke kilden til referansen side 2 av 11 Enheter med begrensede ressurser (minne, prosessorkraft, skjermstørrelse og lagringskapasitet) setter andre krav til programutvikling enn det vi er vant med fra utvikling for PC. Som leser av denne leksjonen er du allerede kjent med J2SE (Java Standard Edition). Denne Java-versjonen brukes for utvikling av vanlige Java-programmer. Denne versjonen er beregnet på PC er og egner seg ikke for mindre handholdte datamaskiner. Til dette formålet har man kommet opp med J2ME (Java Micro Edition). Dette er en Java for små datamaskiner med begrensede ressurser. Utvikling av programmer med J2ME er likt det man er vant med fra J2SE. Java-filer lages på vanlig måte og kompileres. Vi er imidlertid avhengig av å installere J2ME slik at vi kan bruke riktige biblioteker i utviklingen. Deler av J2ME er et sub-sett av J2SE. Dette fører til at klasser du er vant med fra J2SE også finnes i J2ME. Integer-klassen vil du f.eks. finne i begge versjonene. Imidlertid kan du oppleve at klassene har et redusert utvalg av metoder osv. Andre klasser vil være helt borte. I tillegg har J2ME nye klasser som ikke er en del av J2SE. Dette gjelder f.eks. klasser som har med GUI (Graphical User Interface) å gjøre. For å lage brukergrensesnitt i J2ME må man derfor sette seg inn i helt nye klasser. Frykt imidlertid ikke, å lage brukergrensesnitt i J2ME er (ofte) mye enklere enn i J2SE. J2ME finnes (akkurat som J2SE) i flere versjoner. J2ME er imidlertid ikke en enkelt samling med biblioteker, kompilator, jvm (Java virtuell maskin) osv. Bibliotekene som er tilgjengelig kan faktisk variere avhengig av hvilken enhet de er beregnet på. Dette kan gjøre bruken av J2ME mer kompleks enn brukes av J2SE. I dette kurset skal vi imidlertid i all hovedsak fokusere på en del av J2ME, nemlig MIDP (Mobile Information Device Profile) 2.0 (som er siste versjon). Dette er den delen av J2ME som er beregnet på dataenheter som mobiltelefoner og PDA er. MIDP finnes også i eldre versjoner, og kurset vil også ta for seg hvilke forskjeller det er mellom versjonene. Det finnes i dag få mobiltelefoner som støtter MIDP 2.0. De aller fleste mobiltelefonene (som støtter Java) er i dag beregnet på MIDP 1.0. PDAP (Personal Digital Assistant Profile) er også en del av J2ME som er beregnet på PDA er. PDAP gir større muligheter enn MIDP, men krever at enheten støtter profilen. Pr. i dag er det få/ingen enheter som gjør dette. Hvorvidt PDAP blir mer vanlig i framtiden gjenstår å se. MIDP er forløpig det naturlige valg. 1.3.Hvorfor J2ME? Java har etter hvert blitt et meget populært og utbredt programmeringsspråk. Er Java også det riktige valget for utvikling på mobile enheter? Mye taler til Java sin fordel. Støtte for MIDP har etter hvert blitt vanlig i mobile enheter. MIDP har blant annet støtte av produsenter som Ericsson, Hitachi, Nokia, Sony, Symbian (sjekk forøvrig HTUhttp://wireless.java.sun.com/device/ UTH for MIDP enheter). Å kunne utvikle en applikasjon som fungerer på enheter fra ulike produsenter er selvsagt attraktivt. Alternativet hadde jo vært å utvikle en applikasjon for hver enhet. Da måtte man ha satt seg inn i forskjellene mellom hver enkelt enhet og kanskje t.o.m. brukt ulike programmeringsspråk.

3 Feil: Fant ikke kilden til referansen side 3 av 11 Java har også den fordelen at det er innbygget sikkerhetsmekanismer (J2ME har svakere mekanismer enn J2SE). Sikkerhetsmekanismene sørger, kort fortalt, for at et program ikke kan ødelegge for andre programmer eller operativsystemet (forutsetter at det ikke finnes bugs i Java-implementasjonen). Dette er viktig, da man kan være rimelig sikker på at et program som lastes ned på en mobil enhet, ikke kan skade programvaren på telefonen. Det verste som skal kunne skje, er at programmet henger seg, eller kanskje gjør oppkoblinger mot nettverket (dette kan hindres i MIDP 2.0). Plattformuavhengighet og sikkerhet er altså to viktige stikkord som er gode argumenter for å bruke Java. Java har imidlertid også svakheter. Fordi Java skal fungere på ulike typer enheter kan man ikke legge til spesialfunksjoner som kun fungerer på enkelte enheter. Hva gjør du da om du får i oppdrag å lage en applikasjon som bruker funksjonalitet som ikke er direkte støttet i MIDP? I J2ME har man tatt høyde for denne problemstillingen. Hver enkelt produsent kan lage sine egne Java-biblioteker. I slike tilfeller kan man derfor sjekke hos leverandøren av enheten om det finnes biblioteker som støtter ønsket funksjonalitet. Figuren på side 8 i boka viser dette. 1.4.Konfigurasjoner, profiler og valgfrie API er Vi har allerede vært inn på begrepet profil. MIDP og PDAP er begge profiler. En profil er altså et spesialisert bibliotek for en spesiell type enhet. En PDA har typisk en mye større skjerm enn en mobiltelefon. Det kan derfor være ønskelig med en annen API for å lage grafiske grensesnitt for slike enheter. Svaret på denne problemstillingen er altså å lage MIDP for mobiltelefoner (kan også brukes på PDA er som har støtte for dette) og PDAP for PDA er. Under en profil ligger en konfigurasjon, se figur side 2 i boka. En konfigurasjon er basisen som profilen bygger på. Her finner vi altså biblioteker som kan være felles for flere profiler. Av figuren kan vi se at CLDC (Connected, Limited Device Configuration) er basisen som både MIDP og PDAP bygger på. Biblioteker som ville vært naturlig for begge disse profilene finner du altså i konfigurasjonen. I tillegg inneholder konfigurasjonen en virtuell maskin. Java-programmer kjøres alltid på en virtuell maskin som sørger for å omforme Java-koden til maskinkode. Den virtuelle maskinen i J2SE har etterhvert blitt temmelig stor, og ville ikke være mulig å bruke på enheter med så begrensede ressurser som mobiltelefoner. Man har derfor vært nødt til å lage en ny virtuell maskin for slike enheter. Når vi bruker MIDP (og også PDAP) så vil altså den virtuelle maskinen i CLDC brukes. Denne er kalt kvm (i motsetning til jvm i J2SE). I tillegg til bibliotekene du finner i profilene og konfigurasjonene finnes det også valgfrie API er (eng: optional APIs). Dette er altså biblioteker som ikke er en standard del av verken konfigurasjoner eller profiler, men som det likevel kan være ønskelig å bruke. Om man f.eks. skulle ønske RMI-programmering, så må man laste ned en valgfri API som heter JSR66 (RMI Optional Package). Man må imidlertid være klar over at slike valgfrie pakker ikke

4 Feil: Fant ikke kilden til referansen side 4 av 11 nødvendigvis fungerer på alle enheter/konfigurasjoner. Ved å lete litt på HTUhttp://jcp.org/en/jsr/detail?id=66 UTH finner jeg at JSR66; RMI Optional Package kun kan brukes på konfigurasjonen CDC. Dette gjør at programmer utviklet med MIDP og PDAP ikke kan benytte seg av denne pakken (fordi de bruker konfigurasjonen CLDC) For mulige valgfrie API er, se side 3 i boka eller HTUhttp://jcp.org/jsr/allUTH. Dette kurset vil dreie seg om CLDC og MIDP. Det er likevel nyttig å være klar over at det finnes muligheter utover API ene som befinner seg der. 1.5.Programvare Når vi nå skal utvikle MIDP-applikasjoner bruker vi PC til selve utviklingen. Vi trenger imidlertid noe mer programvare enn det vi er vant med fra utvikling av J2SE-applikasjoner. Boka beskriver i detalj hvilke steg som er nødvendig for å sette sammen en MIDPapplikasjon. Disse stegene kan selvsagt gjøres manuelt, men vi velger heller å bruke verktøyet KToolBar som gjør det meste for oss. I tillegg til KToolBar trenger vi også API ene som vi skal bruke (CLDC og MIDP). Alt dette finnes i en enkelt pakke og kalles J2ME Wireless Toolkit. Siste versjon er i skrivende stund 2.2 (denne ser ut til å fungere bra sammen med J2SE 1.5, samt eldre versjoner av J2SE). J2ME Wireless Toolkit 2.2 kan du laste ned fra Du vil måtte registrere deg for å få lastet ned produktet (hvis du ikke allerede har bruker fra før). Resten av nedlastingen bør være selvforklarende. Husk å laste ned versjonen for den plattformen du bruker (Windows eller Linux). Før du fortsetter med installasjonen må du sørge for at J2SE er installert på maskinen din (dette har du tidligere gjort i Grunnkurs Java eller tilsvarende kurs). Dobbelklikk på filen du lastet ned og følg prosedyren beskrevet på skjermen. (Du må oppgi hvor J2SE finnes på maskinen din og hvor J2ME skal installeres. Er du usikker så godta valgene som blir foreslått for deg). Når du er ferdig med installasjonen skal du nå kunne finne J2ME Wireless Toolkit under startmenyen (forutsetter bruk av Windows). Et av undervalgene her vil være KToolbar, velg denne. Du får da opp følgende skjermbilde:

5 Feil: Fant ikke kilden til referansen side 5 av 11 Figur 1: Skjermbildet for KToolbar (J2ME Wirless Toolkit) For å gjøre deg litt kjent med verktøyet kan du nå velge Open Project.. Du får da opp flere ferdiglagde prosjekter. Velg games og load project. Du vil da få opp teksten Project "games" loaded i vinduet. Velg Run. Du får da opp følgende skjermbilde (eller noe liknende):

6 Feil: Fant ikke kilden til referansen side 6 av 11 Figur 2: Emulator I skjermbildet over kan du velge mellom ulike spill. Dette gjør du enten med å bruke musa til å trykke på Select-knappen eller via piltastene på tastaturet. Når du har markert ønsket spill (WormGame er markert i figuren over) så trykker du knappen Launch (du kan enten bruke musa eller enter-knappen på tastaturet). Når du nå er ferdig med å spille så kan du velge Exit for å avslutte (evt. kan du velge Menu og Start for å starte spillet på nytt). Mobiltelefonen du ser på skjermen er kalt en emulator. Slike emulatorer er nyttige verktøy når vi skal teste MIDP-applikasjonene våre. Ettersom det finnes mange ulike typer MIDPenheter er det naturlig at det finnes ulike emulatorer. Dette gjør at vi kan teste applikasjonen både på enheter med små og store skjermer, ulike typer tastaturer osv. I Figur 1 finner du nedtrekkslisten Device. Her kan du velge andre emulatorer. Ved å trykke Run etter å ha valgt en annen emulator vil du få opp applikasjonen i en annen innpakning. Ved å velge QwertyDevice blir resultatet slik:

7 Feil: Fant ikke kilden til referansen side 7 av 11 Figur 3: Emulatoren QwertyDevice Det finnes også andre verktøy for utvikling av J2ME-applikasjoner. Boka beskriver noen på s.14. De enkelte produsentene av mobile enheter kan også ha sine egne verktøy og emulatorer for sine enheter. 1.6.Din første J2ME-applikasjon/MIDlet En J2ME-applikasjon blir ofte betegnet som en MIDlet. En slik applikasjon består av minst en Java-klasse. Skjelletet til klassen vil være slik: public class Eksempel extends MIDlet{ //metoder... } Koden extends MIDlet beskriver at dette er en MIDlet-klasse. Alle J2ME-applikasjoner vil derfor ha en slik klasse. Når J2ME-applikasjonen startes er det bestemte metoder i denne klassen som vil kjøres. La oss lage en enkel MIDlet.

8 Feil: Fant ikke kilden til referansen side 8 av 11 Det første du må gjøre er å velge New project i startbildet til KToolbar (se Figur 1: ). Du får da opp skjermildet under. Her må du fylle inn Project Name og MIDlet Class Name. Førstnevnte er navnet du vil gi på prosjektet (slik at du kjenner det igjen). Sistnevnte er navnet på MIDlet-klassen. Sørg for å skrive inn som vist i figuren. Figur 4: Nytt prosjekt Ved å trykke Create Project får du opp følgende skjermbilde (eller liknende): Figur 5: Konfigurasjon av applikasjonen

9 Feil: Fant ikke kilden til referansen side 9 av 11 Her kan du velge gjøre ulike innstillinger for applikasjonen. Du kan f.eks. velge om du skal bruke konfigurasjonen CLDC 1.0 eller 1.1 (ved å endre Target Platform kan du velge MIDP 1.0). Du kan bare godta de valgene som er gjort for deg. Trykk OK og skjermildet blir noe slikt: Figur 6: Opprettet prosjekt Teksten i skjermbildet viser at prosjektet er opprettet og noen aktuelle kataloger for prosjektet. På linje nr. 2 kan du se hvilken katalog du skal plassere kildekoden for et prosjekt. Alle prosjekter vil få sin egen katalog under apps-katalogen. Navnet på katalogen er navnet du oppga i Project Name når du opprettet prosjektet. Kopier HelloWorldEx.java inn i src-katalogen for prosjektet ditt. For å kompilere prosjektet ditt, velger du Build. Det skal nå se blant annet følgende tekst i vinduet: Building "HelloWorldEksempel" Build complete Det vil si at applikasjonen nå er kompilert. Kompilerte filer finner du i classes-katalogen for prosjektet. Kjør applikasjonen med å velge Run, slik som du har gjort tidligere. Hvis du får feil med kompilering så vil du få feilmeldingene opp i KToolbar. Det er da bare å rette opp i Java-filene (husk å lagre) og trykke Build på nytt. Du finner flere detaljer om hva som skjer under kompilering og kjøring på side i boka. Tråder (threads) blir omtalt på side 23. Vi kommer tilbake til tråder senere så du kan se bort fra dette temaet foreløpig. På side 24 og 25 er det beskrevet litt om GUI, dette er et tema vi kommer tilbake til i neste leksjon, så ikke bruk tid på dette nå. 1.7.Pakking av applikasjonen Side i boka omhandler hvordan vi pakker en J2ME-applikasjon og får den overført til en mobil enhet. Dette er sider du bør lese, men du kan hoppe over kapitlet Using an

10 Feil: Fant ikke kilden til referansen side 10 av 11 obfuscator og Using Ant. Her kommer en liten oppsummering, samt noe informasjon utover det som står i boka. Før en applikasjon skal overføres til en mobil enhet, sørger vi for å pakke applikasjonen i en jar-fil (Java archive). Dette er en arkiv-fil som inneholder alle filene som trengs av applikasjonen. Dette kan være en/flere.class filer, bildefiler osv. For å få laget denne jar-filen velger du Project > Package > Create Package. Gjør dette for HelloWorldEksempelapplikasjonen. Teksten nederst i KToolbar viser at HelloWorldEksempel.jar blir lagret i applikasjonenes bin-katalog. Hvis du går inn i denne katalogen kan du nå se denne jar-filen og en fil som ender med.jad. Begge disse filene er nødvendig for å kunne bruke applikasjonen på en mobil enhet. Jar-filen inneholder som sagt nødvendig kode og eventuelle bilder osv. Jad-filen er kun en beskrivelse av applikasjonen. Ved å åpne HelloWorldEksempel.jad i en teksteditor kan vi se innholdet. Hos meg er det slik: MIDlet-1: HelloWorldEksempel, HelloWorldEksempel.png, HelloWorldEx MIDlet-Jar-Size: 1205 MIDlet-Jar-URL: HelloWorldEksempel.jar MIDlet-Name: HelloWorldEksempel MIDlet-Vendor: Unknown MIDlet-Version: 1.0 MicroEdition-Configuration: CLDC-1.0 MicroEdition-Profile: MIDP-2.0 Filen inneholder, blant annet, informasjon om hvilken profil og konfigurasjon som brukes av applikasjonen. Grunnen til at denne filen eksisterer er at en mobil enhet skal kunne sjekke applikasjonen før den lastes ned. Hvis applikasjonen trenger profilen MIDP2.0 og enheten støtter kun 1.0 er det jo ikke noen vits å laste ned applikasjonen. Merk imidlertid at det er opp til enheten selv å sjekke de ulike feltene. Du kan endre mange av disse feltene ved å gå inn på menyen Project > Settings i KToolbar. 1.8.Publisering av applikasjonen Vi har nå en applikasjon som består av en jar-fil og en jad-fil. De mobile enhetene har ulike måter å overføre applikasjonene til enheten. De fleste enhetene støtter en eller annen form for direkte overføring fra PC til enheten. Dette kan være gjennom kabel eller en form for trådløs overføring. Hvordan direkte overføring gjøres vil variere fra enhet til enhet (så her må du sjekke dokumentasjonen for enheten). Mobiltelefoner støtter typisk også å laste ned MIDP-applikasjoner via Internett (via GSM eller GPRS). For å få til dette må vi ha en web-tjener hvor vi kan legge ut applikasjonen og en web-side. Jeg har laget følgende html-fil:

11 Feil: Fant ikke kilden til referansen side 11 av 11 <html> <head><title></title></head> <body> <p> HelloWorldEksempel </p> <a href="helloworldeksempel.jad"> Last ned HelloWorldEksempel </a> </body> </html> Web-siden finner du på HTUhttp:// Ved å gå inn på denne adressen med mobiltelefonen din, og trykke på lenken Last ned HelloWorldEksempel, vil du få lastet ned HelloWorldEksempel (mobilen må selvsagt ha støtte for Java). Prøv gjerne med din mobil. 1.9.Tilslutt Kapittel 3 i læreboka inneholder en del som vi skal komme tilbake til senere. Du bør merke deg det som står i The MIDlet Life Cycle. Du kan se at metodene beskrevet i kapitlet også finnes i HelloWorldEksempel-applikasjonen. Utskriftssetningene gjør også at du kan se når disse metodene blir kalt. Resten av kapitlet forteller litt mer om pakking av en MIDlet og sikkerhetsmekanismer som kan brukes. Dette er ting som bør leses, og tas fram om dere skulle publisere applikasjoner senere. Et begrep som brukes du vil komme over etterhvert i kurset er socket. Om du ikke kjenner til dette begrepet, så kan det kort forklares med en nettverksoppkobling. Når du lager et program, som kobler seg opp mot et program på en annen maskin, så skjer dette via en socket. Programmet sender og henter informasjon fra socket en, som i sin tur sørger for overføing av dataene til motparten på den andre siden av nettverket.