2 Forskjeller mellom J2SE og J2ME. Hvordan lage brukergrensesnitt i J2ME.

Transkript

1 Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Forskjeller mellom J2SE og J2ME. Hvordan lage brukergrensesnitt i J2ME. Lene Hoff/Mildrid Ljosland Lærestoffet er utviklet for faget SO350D J2ME for programmering av mobile enheter 2 Forskjeller mellom J2SE og J2ME. Hvordan lage brukergrensesnitt i J2ME. Resymé: Denne leksjonen starter med å se på de viktigste forskjellene mellom API en i J2SE og J2ME. Dette underbygges med enkle brukergrensesnitt. Det finnes flere former for brukergrensesnitt for mobile enheter. I denne leksjonen begynner vi med de enkleste formene. Gjennom kurset skal vi se på alle disse formene. Innhold 2.1 INNLEDNING SAMMENLIGNING AV API FOR J2SE OG J2ME java.lang-pakken java.io-pakken java.util-pakken LAGE BRUKERGRENSESNITT Visning på skjerm HØYNIVÅ GUI-PROGRAMMERING Klassen Display Hendelser i MIDP Felles egenskaper for Screen-klassen Klassen TextBox Klassen Alert Eksempel på bruk av klassene TextBox og Alert Innledning I denne leksjonen skal vi starte med å gjennomgå forskjeller mellom API ene i J2ME og J2SE. Det er en rekke ulikheter når det gjelder hvilke klasser og metoder som er med i de to APIene. Grunnen er de begrensninger som en mobiltelefon har i form av kapasitet og skjermstørrelse. Vi skal se på de viktigste endringene. Brukergrensesnitt (GUI) er en viktig del av J2ME. Uten det får vi ikke kommunisert med brukeren. Av naturlige grunner vil det være store forskjeller på å programmere et brukergrensesnitt for en mobiltelefon i stedet for en PC. I J2ME er det to måter å sette opp et brukergrensesnitt, og de fleste av dere har nok brukt begge på mobiltelefoner. Det ene ligner komponentene som vi kjenner igjen fra Swing i J2SE, se Fig 1a. Dette kan være radioknapper,

2 Forskjeller mellom J2SE og J2ME. Hvordan lage brukergrensesnitt i J2ME. side 2 av 16 lister, tekstfelt og lignende. For flere av disse komponentene finnes det varianter i J2ME. Det andre brukergrensesnittet er det vi ofte ser i spill, hvor hele skjermbilde er tegnet opp fra bunnen av uten bruk av ferdige komponenter, se Fig 1b. Fig 1a Fig 1b. Spillet Snake Vi begynner i denne leksjonen med å se på de mulighetene som finnes med GUI for mobile enheter, for så å gå gjennom de enkleste formene. I neste leksjon fortsetter vi med flere former. 2.2 Sammenligning av API for J2SE og J2ME MIDP er basert på vanlig Java-programmering for PC. Målet er at du som programmerer skal kjenne deg igjen når du programmerer mot mobile enheter. Det er derfor tatt utgangspunkt i de eksisterende Java-pakkene og gjort en rekke forenklinger. I tillegg er det lagt til noen egne pakker som er spesielle for mobile enheter. I leksjon 1 gikk vi gjennom forholdet mellom de ulike pakkene i J2ME. Der så vi at MIDPpakken er bygd oppå CLDC-pakken. I dette kapitlet skal vi se på en del kjente pakker fra J2SE som ligger i CLDC. Dette er java.lang, java.io og java.util. Vær oppmerksom på at i siste del av pensumboken (fra side 367) finnes hele API-en for MIDP og CLDC. Her vil du se forskjellene på CLDC 1.0 og 1.1, og på MIDP 1.0 og 2.0. Lær deg allerede fra begynnelsen av å bruke denne flittig. Det vil være til god hjelp. I kap. 4 i boken er det en rekke tabeller som oversiktlig viser forskjellene mellom J2SE, CLDC 1.0 og CLDC 1.1. Tabellene vil ikke bli satt opp i denne leksjonen, så bruk boken mens du leser dette kapitlet. Når jeg i fortsettelsen henviser til CLDC, betyr dette både CLDC 1.0 og CLDC 1.1. Hvis det bare gjelder for en av versjonene vil dette framkomme. CLDC 1.0 støtter ikke de primitive datatypene double og float. Dermed er også wrappertypene java.lang.double og java.lang.float fjernet fra pakken. Disse er fjernet siden hardware for mindre enheter ofte ikke støtter operasjoner med desimale tall. Dette er tatt inn igjen i CLDC java.lang-pakken I tabell 4-1 og 4-2 i boken kan du se hvilke klasser i J2SE som er tatt med i CLDC, og også hvilke av dem som er endret. Som du ser er det store endringer. Her skal vi kort beskrive de

3 Forskjeller mellom J2SE og J2ME. Hvordan lage brukergrensesnitt i J2ME. side 3 av 16 viktigste endringene. Henviser også til Appendiks i boken med API over java.lang-pakken for CLDC. Den starter på side Object Finalization fjernet Finalization er en mekanisme hvor objekter i Java rydder opp etter seg selv, før de legges i søppelbøtten. Dette kan gjøres ved å legge opprydningskoden i objektets finalize-metode. Denne mekanismen er ikke støttet i CLDC. Trengs det opprydning, må du som programmerer ordne dette. På grunn av begrensede ressurser for mobile enheter er det anbefalt å rydde opp etter objekter når du er ferdige med dem. Dette vil hjelpe deg til mer effektive programmer. Dette vil bli beskrevet mer senere i kurset RMI og JINI kan ikke benyttes RMI vil si samarbeid mellom objekter som ligger på fysisk adskilte steder. Mens JINI bruker RMI for å få flere ulike enheter til å samarbeide. Det er ikke mulig å implementere verken RMI eller JINI for mindre mobile enheter. Støtte for dette finner du i J2ME-pakker for større mobile enheter, jmf leksjon Trådprogrammering Ved trådprogrammering med CLDC vil mye være likt det du kjenner fra J2SE-pakken. Vi kommer noe inn på trådprogrammering senere i kurset Klassene String og StringBuffer Klassene String og StringBuffer er stort sett uendret i CLDC. Metoden valueof() for flyttall er naturlig nok tatt bort i CLDC 1.0, men kan brukes som vanlig i CLDC 1.1. Dessuten er det noen mindre endringene i klassene, men dem vil vi merke lite til Klassen Math For klassen Math er det skjedd store endringer. CLDC 1.0 støtter ikke flyttall, og de aller fleste metodene er fjernet fra klassen av den grunn. I CLDC 1.1 er noen av metodene for flyttall tatt tilbake, men langt fra alle. Se API-dokumentasjonen i boken for endringene Klassene Runtime og System For å aksessere Java Virtual Machine (JVM) og systemressurser brukes klassene Runtime og System. Disse klassene har blitt betraktelig mindre i CLDC. For klassen Runtime kan vi benytte metoden gc() for å kalle JVM sin garbage collector. Det er også mulig å se på hvor mye minne som er tilgjengelig og ledig med metodene totalmemory() og freememory(). Eksterne prosesser er ikke mulig å kjøre fra en MIDlet (dette gjøres i J2SE med metoden exec()). Fra System-klassen kjenner vi PrintStream ene err og out for å skrive ut feilmeldinger eller meldinger til konsollet. Dette er fortsatt mulig med CLDC. På en mobil enhet vil ikke dette være hensiktsmessig, da det ikke finnes noe konsoll. Men under testing på en emulator, vil disse PrintStream ene være nyttige å ha. PrintStream en in er fjernet, siden det ikke er mulig å komme med input fra brukeren gjennom en konsoll.

4 Forskjeller mellom J2SE og J2ME. Hvordan lage brukergrensesnitt i J2ME. side 4 av java.io-pakken Den neste pakken vi skal se på er java.io, som behandler ulike datastrømmer. Mange av klassene vi kjenner fra denne pakken er fjernet. Det er hovedsakelig tre grunner for dette. For det første har vi ikke noe filsystem på mobiltelefoner. Av den grunn er alle klasser som har med lagring til fil å gjøre, fjernet. Det finnes en egen pakke for lagring av data for mobile enheter. Det kommer vi tilbake til i leksjon 7. Videre er det ingen støtte for objektserialisering i CLDC. Den siste grunnen henger sammen med de minneressursene som er tilgjengelig for mobile enheter. Det finnes en rekke klasser for ulik behandling av datastrømmer som kan være gode å ha, men som tar opp ressurser. En del av disse er fjernet fra pakken. Komplett liste over alle klassene i de ulike API ene finnes i tabell 4-3, side java.util-pakken Til slutt skal vi se på java.util-pakken hvor mange av klassene er fjernet i CLDC. Mange av disse klassene henger sammen med Collections-klassene som rett og slett blir for store for de mindre mobile enhetene vi jobber med. Komplett liste finner du i tabell 4-4 side Collection-klassene De eneste Collections-klassene som er med er Vector, Hashtable og Stack. Disse vil stort sett dekke opp de behovene som trengs i MIDP-programmering. Interfacet Enumeration er også med i CLDC og du vil se bruk av denne når vi kommer til permanent lagring av data Klasser for dato og tid Når det gjelder ulike klasser for tid er det lagt til klassene Timer og TimerTask i MIDP og ikke i CLDC. Disse klassene er stort sett identiske med de tilsvarende i J2SE. Datoer kan vi representere på ulike måter i MIDP-programmer: - Klassen Date kan du bruke på stort sett samme måte som før ved å oppgi et antall millisekunder siden for å representere en dato. - For å representere et tidspunkt ved hjelp av dager, måneder og år kan du bruke klassen Calender (denne er markert som å ikke eksistere i CLDC i tabell 4-4, noe som er en feil). Den mye brukte klassen GregorianCalender i J2SE er ikke tatt med i CLDC. - Datoer i MIDP-programmer vises i et eget javax.microedition.lcdui.datefield på riktig format. Formatering av datoer ligger i denne klassen. Mer om klassen kommer i neste leksjon. - Tidssoner representeres fortsatt med klassen TimeZone. Dette var de endringene i forhold til J2SE vi ville ta med her. Nå går vi over til GUIprogrammering.

5 Forskjeller mellom J2SE og J2ME. Hvordan lage brukergrensesnitt i J2ME. side 5 av Lage brukergrensesnitt Som tidligere nevnt er det en rekke begrensninger på ressursene til en mobil enhet som minnekapasitet, skjermstørrelse og antall farger. Dette påvirker også hvordan vi setter opp brukergrensesnittet for en mobil enhet. I J2SE er det to pakker som kan brukes for å programmere brukergrensesnitt; java.awt og javax.swing. Begge disse pakkene er optimalisert for en PC hvor mulighetene er langt større. Av den grunn er det laget en helt ny pakke for GUI-programmering for mobile enheter: javax.microedition.lcdui. Brukergrensesnitt for mobile enheter kan vi dele inn i to grupper: - Høynivå API. Her legges brukergrensesnittet på et abstrakt nivå. Vi forteller ikke nøyaktig hvordan alle GUI-komponenter skal se ut, men kanskje heller plasser en Nestekommando et sted på skjermen. Hvor kommandoen plasseres, er opp til den mobile enheten. Her har vi liten kontroll med hvordan grensesnittet vil bli seende ut og kan være ulikt for ulike mobile enheter. Det er denne typen brukergrensesnitt vi skal begynne å se på i denne og neste leksjon. - Lavnivå API. Her er det lite abstraksjon, derimot veldig konkret hvordan et brukergrensesnitt skal se ut. Eksempel er mange spill hvor vi som programmerer må vite nøyaktig hvor de ulike grafiske elementene skal plasseres. På grunn av store variasjoner i skjermstørrelse og farger for ulike mobile enheter må programmet tilpasse brukergrensesnittet, noe som gjøres ved å spørre enheten underveis i kjøringen. Dette krever en god del mer programmering enn ved høynivåprogrammering, og vi kommer nærmere inn på dette senere i kurset Visning på skjerm Alle brukergrensnitt-klassene ligger i to pakker; javax.microedition.lcdui og javax.microedition.lcdui.game. For å kunne vise noe på enhetens skjerm trengs tilgang til enhetens display som representeres av klassen javax.microedition.lcdui.display. Denne klassen holder oversikt over hva som vises på skjermen til enhver tid. Superklassen for hva som kan vises på en skjerm er den abstrakte klassen Displayable. Under vises et klassediagram for Displayable og de subklasser som hører til den. Command Displayable Screen Canvas Graphics GameCanvas Alert Form TextBox List Høynivå Lavnivå

6 Forskjeller mellom J2SE og J2ME. Hvordan lage brukergrensesnitt i J2ME. side 6 av 16 Klassen Screen og dens subklasser hører til den abstrakte delen å programmere brukergrensesnitt. Alert og TextBox er de enkleste klassene å bruke, og dem skal vi se på i denne leksjonen. List og Form er noe mer avanserte og blir gjennomgått i neste leksjon. Klassen Canvas og GameCanvas hører til lavnivå-programmering og blir gjennomgått i henholdsvis leksjon 5 og Høynivå GUI-programmering Før vi begynner med klassene Alert og Textbox skal vi se på en del felles klasser som gjelder for programmering av brukergrensesnitt. Som en hjelp til beskrivelsene ser vi på et enkelt eksempel for å vise oppbygningen av et program. Det kommer til å bli henvist til dette eksemplet senere i leksjonen. Eksemplet viser en TextBox som spør etter brukerens navn, sammen med to kommandoer; avslutt og neste, se figur etter koden. import javax.microedition.midlet.*; import javax.microedition.lcdui.*; public class Navn extends MIDlet implements CommandListener{ private Display display; private Command avslutt; private Command neste; private TextBox navn; public Navn(){ avslutt = new Command("Avslutt", Command.EXIT, 0); neste = new Command("Neste", Command.SCREEN, 1); navn = new TextBox("Navn", "", 50, TextField.ANY); navn.addcommand(avslutt); navn.addcommand(neste); navn.setcommandlistener(this); public void startapp(){ display = Display.getDisplay(this); display.setcurrent(navn); public void commandaction(command c, Displayable d){ if(c == avslutt) notifydestroyed(); if(c == neste){ // Utfør kode for neste-kommandoen public void pauseapp() { public void destroyapp(boolean unconditional) {

7 Forskjeller mellom J2SE og J2ME. Hvordan lage brukergrensesnitt i J2ME. side 7 av 16 I Emulatoren vil dette se ut som: Som vi lærte i leksjon 1 må alle MIDP-programmer arve fra klassen MIDlet og implementere metodene startapp(), pauseapp() og destroyapp(). Som oftest har vi også med en konstruktør Klassen Display For å få tilgang til enhetens skjerm for visning kan vi bruke metoden: public static Display getdisplay(midlet m) Dette gjøres som regel i MIDlet ens startapp()-metode, noe vi så i eksempelkoden over: public void startapp(){ display = Display.getDisplay(this); display.setcurrent(navn); Det er viktig at vi ikke kaller getdisplay() i selve konstruktøren, som kalles før startapp(). I verste fall kan det hende programmet ikke blir initialisert på riktig måte. Når vi nå har fått tilgang til enhetens display kan vi begynne å lage noe som kan vises på skjermen, som for eksempel en TextBox, som i kodeeksemplet over. Denne kan vi vise på skjermen ved å kalle en av følgende metoder: public void setcurrent(displayable next)

8 Forskjeller mellom J2SE og J2ME. Hvordan lage brukergrensesnitt i J2ME. side 8 av 16 public void setcurrent(alert alert, Displayable next) Disse metodene bruker vi hver gang vi vil skifte innhold på skjermen. Den andre metoden her blir brukt hvis det skal vises en midlertidig melding for brukeren før neste Displayableobjekt vises. Det er mulig å finne ut hva som vises på skjermen akkurat nå ved å kalle metoden: public Displayable getcurrent() Hvis flere MIDlet er kjøres samtidig kan denne metoden returnere et Displayable-objekt som ikke er synlig for brukeren. Klassen Displayable har derfor en metode som sjekker om dette objektet er synlig for brukeren nå: public boolean isshown() Klassen Display har også en rekke metoder for å finne ut hva som er mulig på skjermen og hvordan den ser ut. To av de viktigste er: public boolean iscolor() public int numcolors() Metoden iscolor() forteller om en skjerm har støtte for farger eller gråskala. True vil si farger, mens false vil si gråskala. Metoden numcolors() returnerer hvor mange farger/gråskalaer skjermen støtter. En god del av de andre metodene for å finne hva skjermen støtter kommer vi tilbake til senere i kurset Hendelser i MIDP Klassen Displayable kan benytte en fleksibel klasse Command, for å ta imot hendelser fra en bruker. Det kan ses på som en knapp som brukeren kan trykke på for at det skal skje noe. I kodeeksemplet over har vi 2 Command-objekter for hendelsene Avslutt og Neste. Legg merke til hvordan kommandoene presenteres i emulatoren på figuren på forrige side. Fordelen med klassen Command er at vi som programmerer slipper å bry oss for hvordan kommandoen blir presentert for brukeren. Det viktige er at kommandoen er tilgjengelig for brukeren. For å legge til eller slette hendelser kan disse Displayable-metodene brukes: public void addcommand(command cmd) public void removecommand(command cmd) Opprette kommandoer Klassen Command har to konstruktører: public Command(String label, int commandtype, int priority) public Command(String shortlabel, String longlabel, int commandtype, int priority) Det er vanligst å bruke den første konstruktøren. Den tar inn en tekst som skal stå på kommandoen, hvilken type kommando det er og en prioritering. Hvis ønskelig, kan det gis en kort og en lang tekst slik at den mobile enheten selv kan velge hvilken som skal brukes (den andre konstruktøren). Command-klassen har en rekke konstanter som kan brukes som verdier for commandtype-parameteren: - OK bekrefte et valg - CANCEL kansellere en endring

9 Forskjeller mellom J2SE og J2ME. Hvordan lage brukergrensesnitt i J2ME. side 9 av 16 - BACK flytter brukeren tilbake til forrige skjerm - STOP stoppe en kjørende prosess - HELP vise programmets instruksjoner - SCREEN annet (hva som helst) Disse konstantene antyder hvilken type kommando det er snakk om, men legger ingen hendelser på dem. Eksempel på opprettelse av en kommando så vi i eksempelkoden over: Command avslutt = new Command( Avslutt, Command.EXIT, 0); Command neste = new Command( Neste, Command.SCREEN, 1); Det første eksemplet her er Avslutt-kommandoen. Som du ser, brukes konstanten EXIT i Command-klassen. Den andre kommandoen som lages er Neste-kommandoen. Dette er en kommando som er spesiell for vårt program og vi bruker derfor konstanten SCREEN. Den siste parameteren over er priority som angir hvor viktig denne kommandoen er. Verdien 0 er viktigst. En mobiltelefon har som regel to såkalte soft-knapper, se figuren under. Dersom vi har mer enn to kommandoer, samles ofte kommandoene i en gruppe og vises under en soft-knapp. I figuren under er det laget et Menu-valg for de tre siste kommandoene. Her er priority-parameteren viktig. I figuren under er kommandoene Ny, Slett og Endre alle gitt verdien 1 for priority. Da kommer de i den rekkefølgen vi har lagt dem inn. Hadde vi gitt for eksempel Ny prioritet 2, ville den kommet nederst. Soft-knapper Det er mulig å hente ut verdiene som er gitt for label, longlabel og commandtype ved hjelp av metodene: public int getcommandtype() public String getlabel() public String getlonglabel()

10 Forskjeller mellom J2SE og J2ME. Hvordan lage brukergrensesnitt i J2ME. side 10 av Fange opp kommandohendelser For at det skal skje noe når brukeren trykker på en kommando, må vi lytte til denne type hendelse i programmet vårt. Dette vil være på samme måte som i J2SE når vi behandler hendelser. Når brukeren trykker på en kommando sendes det ut en hendelse. Programmet må derfor ha en lytter som fanger opp denne bestemt hendelsen. Vi lar derfor programmet vårt implementere en CommandListener på denne måten: public class extends MIDlet implements CommandListener { Når vi implementerer denne lytteren må vi også definere følgende metode innenfor klassen vår: public void commandaction(command c, Displayable d){ Inni metoden programmerer vi hva som skal skje når brukeren trykker på en kommando. Vi kan bruke den første innparameteren, som er av type Command, for å sjekke hvilken kommando som er trykt på. Vi kan tenke oss at vi har deklarert følgende objekt: Command avslutt = new Command( Avslutt, Command.EXIT, 0); I commandaction-metoden kan vi sjekke om det er denne knappen som er trykt på: public void commandaction(command c, Displayable d){ if(c == avslutt) notifydestroyed(); Her sammenligner vi innparameteren c med navnet (referansen) på Command-objektet vi opprettet over. Vær oppmerksom på at det ikke bør være for mye kode i denne metoden som tar opp mye ressurser. Grunnen er at det brukes en egen tråd for denne type hendelser og denne tråden bør ikke bli oppholdt for lenge. Skal det utføres tyngre beregninger bør det opprettes en egen tråd for dette. Vi skal ikke se på dette nå. I læreboken side 58 er det vist et eksempel med en annen måte å sette opp kommandolytteren og metoden commandaction på. Forskjellen er at vi har latt MIDleten selv være en CommandListener (det er derfor vi skriver this i setningen navn.setcommandlistener(this); ), mens i eksemplet i læreboka lages et nytt objekt av en navnløs klasse som implementerer CommandListener-grensesnittet. Du velger selv hvilken form du vil bruke Felles egenskaper for Screen-klassen Vi så at klassen Screen var superklassen for høynivåklassene. Før vi går i gang med subklassene TextBox og Alert skal vi se på to egenskaper som er felles for alle subklasser til Screen (i MIDP 2 er metodene flyttet fra klassen Screen til klassen Displayable). Dette er en tittel og en rulletekst (ticker). Tittelen vises øverst i skjermbilde, mens rulleteksten vises på toppen av skjermen. Det finnes fire metoder i tilknytning til disse egenskapene: public void settitle(string newtitle) public String gettitle() public void setticker(ticker newticker) public Ticker getticker()

11 Forskjeller mellom J2SE og J2ME. Hvordan lage brukergrensesnitt i J2ME. side 11 av 16 Vi skal nå legge inn en tittel og en ticker i en tekstboks (kommer tilbake til tekstboks i neste delkapittel): TextBox boks = new TextBox("Test","Dette er en test!", 50, TextField.ANY); Ticker rulletekst = new Ticker("Dette er en rullende tekst"); boks.setticker(rulletekst); boks.settitle("ny tittel"); I emulatoren vil nå se ut som: Som vi skal se på i neste delkapittel, vil en av innparameterne til TextBox være en tittel. Av den grunn er det ikke nødvendig å sette en tittel, ved hjelp av settitle(), når vi oppretter tekstboksen. Men metoden vil være bra å ha vi senere vil endre på tittelen Klassen TextBox TextBox-klassen er den enkleste subklassen til Screen, som vi så et eksempel på i forrige delkapittel. En TextBox er et vindu hvor vi kan skrive flere linjer med tekst. Det er også mulig å legge på filter på tekstboksen, slik at brukeren blir tvunget til å skrive input på rett format. Konstruktøren til TextBox ser ut som: public TextBox(String title, String text, int maxsize, int constraints) De to første parametrene er henholdsvis en tittel og teksten som vises i selve tekstboksen. Ved hjelp av maxsize kan vi sette det maksimale antall tegn som kan skrives i tekstboksen. Den siste parameteren, constraints, begrenser hva brukeren kan skrive i tekstboksen. Vi vil nå se litt på hvilke verdier constraints-parameteren kan ha. For det første er det en rekke restriksjonskonstanter vi kan bruke. Disse setter begrensninger på hva brukeren kan skrive inn. Sammen med disse kan vi også benytte flagg som definerer hvordan selve tekstboksen skal oppføre seg/vise teksten. De fleste flaggene er nye i MIDP 2. Merk at alle konstantene ligger i klassen TextField (ikke TextBox). Her er restriksjonskonstantene: - ANY tillatt alle former for input - NUMERIC kan bare skrive inn heltall - DECIMAL kan skrive inn både heltall og desimaltall - PHONENUMBER input må være et telefonnr - ADDR input må være en e-postadresse

12 Forskjeller mellom J2SE og J2ME. Hvordan lage brukergrensesnitt i J2ME. side 12 av 16 - URL input må være en internettadresse NUMERIC, DECIMAL og PHONENUMBER krever alle at du skriver inn tall. Andre tegn (bortsett fra. for DECIMAL) blir ingnorert. Men det skjer ingen sjekk på at det er et lovlig telefonnummer som skrives inn om du bruker PHONENUMBER. Det samme gjelder for ADDR og URL. Her kan hva som helst skrives inn og bli godtatt. Konstantene er altså bare en indikasjon på hva slags data som forventes, hvis du virkelig vil sjekke gyldighe, må du programmere det selv. Flaggene: - PASSWORD tegnene som skrives inn vises ikke. Som regel vises det stjerner i stedet - UNEDITABLE teksten kan ikke redigeres - SENSITIVE teksten som skrives inn skal ikke lagres for senere bruk - NON_PREDICTIVE indikerer at teksten som skrives inn ikke vil kunne forutsis - INITIAL_CAPS_WORD hvert ord i input vil få stor forbokstav - INITIAL_CAPS_SENTENCE det første ordet i hver setning vil få stor forbokstav Når det gjelder de to siste flaggene vil dette fungere hvis du trykker på knappene i emulatoren, og ikke på tastaturet. En restriksjon og et flagg kan kombineres ved å bruke tegnet mellom 1 : TextBox boks = new TextBox("Kontonr", "", 11, TextField.NUMERIC TextField.PASSWORD); Her har vi en tekstboks hvor et kontonr skal fylles ut. Dette skal være et heltall på 11 tegn, og tallene som skrives inn skal ikke vises. Husk på at det kan være vanskelig for en bruker hvis flagget PASSWORD brukes, fordi det er en mobiltelefon det tastes på og ikke et tastatur. Alle innparametrene til konstruktøren kan endres eller hentes etter deklarasjonen ved hjelp av set- og get-metoder. Det vil si; setstring(string text), getstring(), setmaxsize(int mazsize), getmaxsize(), setconstraints(int constraints) og getconstraints() sammen med settitle(string title) og gettitle() fra Displayable-klassen. Videre finnes det metoder for å sette inn og slette deler av teksten: public void insert(string src, int position) public void insert(char[] data, int offset, int length, int position) public void delete(int offset, int length) For den første metoden angir du teksten som skal settes inn, og deretter fra hvilken posisjon du vil sette inn teksten. Metode to setter istedenfor inn en char-tabell av tegn fra angitt sted i tabellen (offset-parameteren) og et visst antall tegn (length-parameter) til en bestemt posisjon i tekstboksen. Den siste metoden sletter fra offset og et bestemt antall tegn. Hvis du vil legge til en ny tekst i slutten av det som allerede står, kan du bruke følgende metode for å finne posisjon etter siste tegn: public int getcaretposition() 1 er tegent for bitvis eller, og beregnes slik: Se på motsvarende posisjon i begge tallene. Hvis det er 0 i begge, blir resultatet 0 på denne posisjonen. Hvis det er 1 i minst ett av tallene, blir resultatet 1. Hvis begge tallene er toerpotenser, vil de ha 1 på en posisjon, 0 på alle andre. mellom to slike tall gir et resultat som er 1 på de to ener-posisjonene, 0 ellers. Eksempel: 2 4 = = 0110 = 6. Dette utnyttes ved at konstantene er slike toerpotenser, og da vil mellom dem gi et tall som viser nøyaktig hvilke tall det er sammensatt av.

13 Forskjeller mellom J2SE og J2ME. Hvordan lage brukergrensesnitt i J2ME. side 13 av 16 Prøv deg frem med disse metodene. I kap sto det et eksempel med en tekstboks. Se på dette eksemplet for hvordan klassen er bygd opp, og TextBox benyttes. I siste delkapittel vil det komme et litt større eksempel Klassen Alert En alert er en melding til brukeren som kan inneholde en tekst og et bilde. De kan sammenlignes med dialogbokser på en vanlig datamaskin. Det finnes to former for meldinger: - Tidsinnstilte meldinger som vises en viss tid og så lukkes av seg selv. En typisk melding kan være In progress. - En modal melding som vises helt til brukeren bekrefter den. Et eksempel her kan være en melding Vil du virkelig slette denne filen med en Ja- og Nei-knapp Vi har to konstruktører for klassen Alert: public Alert() public Alert(String title, String alerttext, Image alertimage, AlertType alerttype) I den siste konstruktøren her har vi en tittel og selve teksten som skal stå i meldingen. Videre har vi et Image-objekt for bilde som kan vises sammen med teksten og til slutt har vi hvilken type melding det er snakk om. Alle parametrene kan ha verdien null. For å endre dem eller hente verdien ut senere kan metodene gettitle, settitle, getstring, setstring, getimage, setimage, gettype og settype brukes. Det finnes fem typer meldinger som er representert med konstanter; ALARM, CONFIRMATION, ERROR, INFO og WARNING. Disse konstantene indikerer bare hvilken type melding som skal vises, og den knyttes opp mot ulike lyder når de vises. For emulatoren er det noen forhåndsdefinerte lyder for hver type. Det er mulig å legge til egne lyder, men det tar vi ikke nå. Vi kan lage en feilmelding for lagring av fil: Alert alert = new Alert( Lagring, Det skjedde en feil under lagring av filen!, null, Alert.ERROR); For å angi hvilken form for melding dette skal være, tidsinnstilt eller modal, bruker vi metoden: public void settimeout(int time)

14 Forskjeller mellom J2SE og J2ME. Hvordan lage brukergrensesnitt i J2ME. side 14 av 16 Time-parameteren er i millisekund. Hvis vi vil at meldingen over skal vises i 3 sekund skriver vi: alert.settimeout(3000); Alternativet er å gjøre meldingen modal. Da brukes konstanten FOREVER i metoden over: alert.settimeout(alert.forever); Ved modal meldinger vil selve MIDP-implementasjonen legge til en DONE-kommando. Når brukeren trykker på kommandoen vil neste Displayable vises, hvis det er angitt en neste ved metoden setcurrent(alert alert, Displayable next). Det er mulig å legge til egne kommandoer til en melding. Da vil den forhåndsdefinerte kommandoen fjernes. I neste delkapittel vises et eksempel hvor vi legger til knapper i en modal melding Eksempel på bruk av klassene TextBox og Alert Nå skal vi se på et eksempel som kobler sammen kommandoer, tekstbokser og meldinger. I figuren under ser du selve programmet på emulatoren. Vi vil altså at brukeren skal skrive inn et land, for deretter å bekrefte om det er rett land i en melding. I neste tekstboks skal en by i dette landet fylles inn. Ved OK i tekstboksen kommer en melding om lagrede data i 5 sekunder. Deretter starter programmet på ny igjen. Skjerm 1 Skjerm 2 Skjerm 3 Skjerm 4 Koden for dette programmet ser du her: import javax.microedition.lcdui.*; import javax.microedition.midlet.*; public class Land extends MIDlet implements CommandListener{ private Display display; private TextBox land; private TextBox by; private Command neste; private Command avslutt; private Command OK; private Alert bekreft; private Alert lagret; private Command ja; private Command nei; public Land(){ land = new TextBox("Land:","", 50, TextField.ANY);

15 Forskjeller mellom J2SE og J2ME. Hvordan lage brukergrensesnitt i J2ME. side 15 av 16 by = new TextBox("","", 50, TextField.ANY); neste = new Command("Neste", Command.SCREEN, 0); avslutt = new Command("Avslutt", Command.EXIT, 0); OK = new Command("OK", Command.OK, 0); land.addcommand(avslutt); land.addcommand(neste); by.addcommand(ok); land.setcommandlistener(this); by.setcommandlistener(this); bekreft = new Alert("Bekreft land", null, null, AlertType.WARNING); lagret = new Alert("Opplysninger lagret", null, null, AlertType.INFO); bekreft.settimeout(alert.forever); lagret.settimeout(5000); ja = new Command("Ja", Command.OK, 0); nei = new Command("Nei", Command.BACK, 0); bekreft.addcommand(ja); bekreft.addcommand(nei); bekreft.setcommandlistener(this); public void startapp(){ display = Display.getDisplay(this); display.setcurrent(land); public void commandaction(command c, Displayable d){ if(c == neste){ bekreft.setstring("er du sikker på at landet " + land.getstring() + " er riktig?"); by.settitle("by i " + land.getstring()); display.setcurrent(bekreft); else if(c == OK){ lagret.setstring("følgende opplysninger er lagret:\n Land: " + land.getstring() + "\n By: " + by.getstring()); land.setstring(""); by.setstring(""); display.setcurrent(lagret, land); else if(c == avslutt) notifydestroyed(); else if(c == ja) display.setcurrent(by); else if(c == nei) display.setcurrent(land); public void pauseapp(){ public void destroyapp(boolean unconditional){ Metoden startapp() setter første Displayable som skal vises. I konstruktøren opprettes to tekstbokser og to meldingsbokser. Det legges til kommandoer for begge tekstboksene og for en melding. Meldingen bekreft opprettes som en modal melding. Legg merke til at selve meldingen settes foreløpig til null. Meldingsteksten vil genereres fra resultatet i første

16 Forskjeller mellom J2SE og J2ME. Hvordan lage brukergrensesnitt i J2ME. side 16 av 16 tekstboks. Den siste meldingen, lagret, vil være en tidsinnstilt melding som skal vises i 5 sekunder. I commandaction() skjer skiftene mellom de ulike Displayable-objektene. Når brukeren trykker på kommandoen Neste vil teksten som brukeren skrev inn, hentes ut og legges i meldingen bekreft. Vi vil også ha med navn på landet i tittelen på by. Deretter vises bekreft ved hjelp av metoden setcurrent. Denne metoden får inn to parametre. Først meldingen som skal vises og deretter tekstboksen som vil være neste Displayable etter meldingen. For kommandoen OK skal den tidsinnstilte meldingen lagret vises, for deretter å vise den første tekstboksen igjen. Når meldingen lagret er vist, vil programmet starte på nytt. Vi må derfor nå sette teksten for land og by til tomme strenger igjen. For kommandoene Ja og Nei endres bare visning av skjerm.