Java i mobiltelefonen - får vi noe nyttig nå?

Ingress: Det begynner å komme mobiltelefoner på markedet med søtte for Java. Er dette bare pynt og stæsj, eller kan vi vente oss nye og nyttige mobilapplikasjoner som et resultat av dette?

Trykket i Nettverk & Kommunikasjon nr.1/2002
(c) Anders Fongen 2002

Anders Fongen er høgskolelektor og fagsjef ved Norges Informajonsteknologiske Høgskole. Webstedet hans er på www.fongen.no

Mobiltelefoner med støtte for programmeringsspråket Java begynner nå å komme på markedet, i form av modellene Nokia 9210 og Nokia 7650. Hva innebærer dette? At vi kan overføre alle våre Java-programmer til telefonen og la dem kjøre der? Eller er det begrensninger som krever spesialtilpassede programmer og klasser?

Vi kan love at det er mange begrensninger ute og går. Men det oppstår også mange nye muligheter når Java-teknologien kan utnyttes i denne typen mobile kommunikasjonsenheter. Denne artikkelen vil fortelle om disse mulighetene og begrensningene.

Rørleggerassistenten

En rørlegger som gjør reparasjoner hjemme hos folk kan bruke en mobil elektronisk assistent og kommunikasjonsenhet til:

å registrere besøkstid, materialforbruk og kjørelengde som fakturagrunnlag
online visning av kommunale kart og tegninger
mottak av hasteordrer underveis
planlegging av beste kjørerute

Er dette mulig å få til med en Java-basert mobiltelefon?

Sykkelbudet

Vi kjenner alle til hvordan drosjenæringen benytter et omfattende mobilt informasjonssystem for formidling av bestillinger og meldinger. Dette er tungt og kostbart utstyr. Om en tilsvarende funksjonalitet kunne legges i en mobiltelefon, kunne et sykkelbud på tilsvarende måte kommunisere med en budsentral for å motta oppdrag og redirigeringer, eller sende meldinger og fakturagrunnlag til sentralen.

"Vertikale" applikasjoner

"Mobil-PDAer" (mobiltelefoner med PDA-funksjoner) er etter vår mening velegnet for "vertikale applikasjoner", dvs. anvendelser hvor maskinvaren og systemprogramvaren er innrettet mot et bestemt bruksområde. Produksjon i stort volum gjør enhetene mye billigere enn slikt utstyr har vært inntil idag, og med en fornuftig programmeringsplattform kan man lage profesjonelle mobilapplikasjoner som tidligere har krevet utbygging av en hel infrastrukstur (f.eks. drosjesystemer).

Java i største laget

Problemet med å programmere mobile applikasjoner i Java har vært at Javas kjøremiljø (Java Virtual Machine og standard klassebibliotek) har krevet for mye minneplass for de fleste PDAer. Relativt kraftige PDAer som Psion Netbook er utstyrt med Java versjon 1.1. Java versjon 1.2 (som de fleste Java-produkter nå bygger på) er enda større og utenfor rekkevidde for Netbook. Det innebærer at mange Java-produkter innenfor distribuert databehandling ikke kan brukes der.

For mindre maskiner enn Psion er også Java versjon 1.1 utenfor rekkevidde, men Sun har på et tidlig tidspunkt adressert dette problemet gjennom lettvektsversjoner med begrenset funksjonalitet. Det er disse versjonen som kommer i betraktning når vi vil kjøre Java-versjoner på mobiltelefoner. Glem aldri: Java på mobiltelefoner vil aldri benytte standard Java-funksjonalitet.

Java på smartkort

Som en kuriositet i denne sammenhengen kan vi nevne at selv den ytterst begrensede konfigurasjonen vi finner på et smartkort (512 bytes med RAM, 16 kilobytes med ROM, og en liten 8-bits prosessor) kan kjøre en mikroversjon av Java kalt JavaCard. Den har ingen tråder (enklere JVM) og et ytterst begrenset klassebibliotek (mindre plass).

Java i håndportable enheter

Ressurssituasjonen i håndportable enheter blir noe midt i mellom smartkort og PCer, men også her er spennvidden så stor at Sun har sett det som nødvendig å levere ulike produkter for enkle enheter (mobiltelefoner) og kraftige (PDAer).

Disse Java-versjonene kalles begge Java 2 Micro Edition, J2ME. Siden det utstyret de retter dettte produktet mot er kommunikasjonsprodukter, legger også Sun stor vekt på kommunikasjonsegenskapene til J2ME.

J2ME leveres i to såkalte "konfigurasjoner" kalt CDC "Connected Device Configuration", og CLDC "Connected Limited Device Configuration", ment for henholdsvis PDA-lignende og mobiltelefonbaserte enheter. CDC har en standard JVM, men med forenklede klassebiblioteker, mens CLDC har også en forenklet JVM (uten bruk av "reflection" og "finalizer").

Mobile Information Device Profile

Klassebiblioteket som J2ME bygger på kalles "Mobile Information Decive Profile. (MIDP) har de viktigste egenskapene fra standardversjonen (kalt J2SE - "Standard Edition") i form av klasser for nettverk, lagring og brukerdialog. Generelt er de enklere, slankere og med lavere funksjonalitet enn de tilsvarende klassene fra J2SE. Her finner vi ikke konsoll-i/o, filestreams, serversockets, awt (abstract windowing toolkit) eller flyttall. Derimot finner vi en arkitektur av klasser som skal støtte flyttbare programmer gjennom å tilby et generelt grensesnitt til mobilenhetens maskinvare. For å få dette til må man ta hensyn til:

at kommunikasjonen kan basere seg på ulike typer av svitsjing (GPRS eller HSCSD) og forskjellige hastigheter. Ulike enheter har ulik evne til å ta imot innkommende forbindelser.
hvilken størrelse det er på skjermen, om utstyret har fargeskjerm, om den er trykkfølsom, og hva slags tastatur som er i bruk.

Dette innebærer at vi går glipp av mye moro: Ikke venter vi å finne adgang til telefon-funksjoner (f.eks. å sette opp eller besvare en samtale), funksjoner for å lese og sende SMS-meldinger, eller muligheter for å lese innholdet i SIM-brikken.

Vi skal raskt ramse opp de viktigste egenskapene ved de ulike pakkene: javax.microedition.io - Denne pakken inneholder klasser nødvendig for nettverksforbindelse. Den har alminnelig støtte for TCP-forbindelser (kun klient-ende) og Datagram-trafikk. Datagram vil trolig være implementert som UDP-protokoll, men spesifikasjonen forlanger ikke dette. Med en Connector-klasse kan man sette opp "nakne" TCP-baserte socket-forbindelser eller forbindelser som overfører data med HTTP-protokoll (mot en web-tjener).

Hvordan en IP-rute realiseres mellom klienten og tjeneren er derimot ikke noe som disse klassene legger seg opp i: Vi kan se for oss at klienten (som er en mobiltelefon) har en fast .oppkoplet. GPRS-forbindelse som kan brukes, eller at telefonen reagerer på en forbindelsesordre med å kople opp en svitsjet forbindelse til en prekonfigurert aksess-ruter.

javax.microedition.rms - Denne pakken inneholder erstatning for et filsystem, nemlig en permanent lager i form av en enkel "database". Selvfølgelig er dette ingen relasjonsdatabase med SQL-spørringer, men en mulighet til å lagre og gjenfinne en bytebuffer under en primærnøkkel (et heltall). Man kan søke på poster ved å lage klasser som implementerer et RecordFilter, og gjennomløpe radsett ved å implementere en RecordComparator. Delingen av en bytebuffer-post i "felt" eller .attributter" er helt opp til applikasjonen selv.

En database lagres under et navn, og hver Java-applikasjon har sitt eget "navnerom". Noen katalogstruktur finnes ikke, men det finnes en enkel metode for å liste opp alle databasene i et navnerom.

javax.microedition.midlet - En MIDlet tilsvarer en Applet, nemlig en klasse som inneholder en flyttbar Java-applikasjon. En MIDlet kan lagres på en web-tjener og hentes inn av kjøremiljøet på telefonen på lik linje med hvordan en Applet lastes inn i en web-leser.

En MIDlet (altså en klasse som arver fra MIDlet) har metoder som blir kallet fra "utsiden" når applikasjonen startes eller stoppes, og applikasjonen kan dermed reagere på disse hendelsene ved å sette opp GUI-dialogen, åpne og lukke nettverksforbindelser og database.

javax.microedition.lcdui - Et sett av klasser som støtter grafisk brukergrensesnitt mot brukeren. Et brukergrensesnitt på en mobiltelefon blir nødvendigvis mye enklere enn hva det er på en PC, fordi skjermen er mye mindre. Derfor kan dette klassebiblioteket bare tilby vinduer som dekker hele skjermen. Det tilbyr et mindre sett av UI-"elementer" enn hva f.eks. awt gjør; buttons, labels, sliders, tekstfelt, valgfelt og nedtrekkslister, men ingen menyer, pop-up vinduer el.lign. Tanken er å beskrive strukturen av brukerdialogen og la telefonens kjøremiljø stille opp de grafiske elementene i stil med de øvrige betjeningsfunksjoner.

Her finner vi ingen "layout manager" slik vi er vant til fra awt og swing, elementene som tar i mot brukerinput skal som hovedregel stilles under hverandre. Ledetekster og bilder kan plasseres litt friere etter bestemte regler.

Knytningen fra hendelser i brukerdialogen til applikasjonsprogrammet skjer gjennom egne "Command"-objekter. Dette knytter en ledetekst og en type til en skjerm, nedtrekksliste eller en knapp. Disse opplysningene gjør det mulig å plassere input-valgene utenfor skjermbildet (på "soft-buttons" o.l.) med egnede ledetekster. Til et "Command"-objekt kan man også knytte en lytter (event listener) som blir kallet når denne kommandoen aktiveres. Dette er en velegnet teknikk for å fokusere på strukturen i brukerdialogen og å skille denne fra selve utseendet i skjermbildet. Husk igjen at dette skal kunne realiseres på et vidt spekter av utstyr.

java.util - Nesten den vanlige util-pakken fra J2SE, den inneholder Vector, Hashtable, Date m.m., men mangler StringTokenizer (som vi selv bruker mye). Det som savnes her lar seg enkelt kompilere fra kildekoden til J2SE.

java.lang - Standardpakken med alle de vanlige datatypene unntatt float. Flyttall er bygget inn i JVM og lar seg ikke enkelt skaffe ved å kompilere annen kildekode. Trenger du desimaltall må du emulere fast desimaltegn ved hjelp av heltallsberegninger (og håpe at du ikke trenger kvadratrot eller logaritmer). Av samme grunn er Math-klassen redusert til noen ubetydelige metoder. En viktig ting ved J2ME er at den fortsatt har beholdt klassen Threads, noe som gjør det mulig å skrive flertråds applikasjoner som f.eks. regelmessig undersøker om en web-side er blitt endret og varsler deg om dette. Vi er usikker på om trådene i en Java-applikasjon også kjøres når telefonen er i vanlig bruk (under samtaler eller bruk av de innebygde applikasjonene). Dersom dette er tilfelle, kan vi altså lage Java-programmer som kjøres "i bakgrunnen" hele tiden og som gjør fornuftig arbeid for oss mens vi bruker telefonen til andre ting.

Nødvendig med GPRS

Som vi allerede har skrevet, så har MIDP-klassene ingen server-sockets, dvs. at det ikke er mulig å ta imot nettverksforbindelser (som en tjener). Dersom vi har applikasjoner som trenger å bli varslet om hendelser som skjer på en tjener et annet sted i nettverket, da må det foregå ved at telefonen har en permanent oppkoplet TCP-forbindelse (satt opp av klienten) til tjeneren, og at data sendes fra tjeneren over denne forbindelsen når noe skal varsles. Dette er uaktuelt dersom man bruker linjesvitsjet forbindelse (HSCSD) fordi den er tidstaksert. En volumtaksert forbindelse som GPRS er derimot velegnet for en slik anvendelse, og vi konkluderer derfor med at GPRS blir en nødvendig teknologi der vi trenger noen form for "asynkron" dataoverføring fra tjeneren til klienten.

Forholdet til Java mellomvare

En av Javas sterke sider er hvordan Java-programmer kan kommunisere via nettverk med mellomvare-teknologier som RMI (Remote Method Invocation) og JINI. Mangelen på såkalt reflection (at man kan inspisere et objekt og finne ut hvilke metoder det har) utelukker bruk av RMI for J2ME-applikasjoner. Likeså JINI, fordi JINI krever både reflection og en spesiell "ClassLoader".

Dersom man har bygget opp en Java-basert infrastruktur med Enterprise Java Beans, bruk av RMI, meldingskøer og navnetjenester, da kommer J2ME-applikasjoner på utsiden av dette fellesskapet. Løsningen i disse tilfellene blir å lage "proxy"-tjenere: Et full-skala tjenerprogram (basert på J2SE) som opptrer på vegne av mobilklientene inne i en RMI-basert infrastruktur og som oversetter mellom enkel nettverksprotokoll (HTTP) mot mobilklientene og RMI-protokoll mot det øvrige nettverket. Det kan også vise seg at SOAP (Simple Object Access Protocol) kan være en interessant metode for å inkludere J2ME-baserte mobilklienter i en avansert infrastruktur.

Portabiliteten

Når vi programmerer i Java, er det bl.a. for å oppnå portabel binærkode (bytekode). Kan vi nå overføre vanlige Java-programmer og kjøre dem på en J2ME-basert enhet?

Nei, det kan du ikke! J2ME tilbyr et helt annet kjøremiljø for programmene, både i form av en annen JVM og et annet klassebibliotek. Programmer skrevet for standard Java-miljø (med brukergrensesnitt basert på awt eller swing) vil kreve massiv redesign på brukerdialogen. All bruk av permanent lagring i filer eller databaser må også skrives helt om.

Klasser som bare benytter interne datastrukturer kan muligens overføres i form av kildekode dersom koden ikke benytter klasser som ikke finnes i J2ME (f.eks. StringTokenizer). Vi antar at f.eks. en XML-parser er innenfor rekkevidde å få overført til et J2ME-kjøremiljø.

En av fordelene med bruk av Java i mobilenheter er trolig i form av "kunnskapsportabilitet". Du trenger ikke lære deg å tenke i et nytt programmeringsspråk, og kan ta med deg den effektiviteten du har opparbeidet deg som Java-programmerer på andre plattformer.

Sitatbokser:

- GPRS blir nødvendig teknologi for J2ME-baserte mobilapplikasjoner

- Programmer skrevet for standard Java-miljø krever massivt redesign for å brukes i J2ME