Xlet-ek, CDC konfiguráció, Personal Profile


Paller Gábor

1. CDC

A CLDC érdekes és népszerű platform, de eléggé behatárolt. A hibái nem nyilvánvalók, mert ezek alkalmazói programok által ritkán használt és kevéssé ismert szolgáltatásokhoz kapcsolódnak. A Reflection API hiánya lehetetlenné teszi a dinamikus hívásokat használó szolgáltatásokat pl. az RMI-t vagy a JDBC-t. A Classloader-ek hiánya miatt betöltött Jáva osztályokat nem lehet frissíteni, csak JVM-specifikus módon, a Java Security hiánya pedig nem teszi lehetővé megbízható és nem megbízható Jáva kódok használatát ugyanabban a rendszerben.

A mobil platformok erejének növekedésével lehetővé vált, hogy olyan JVM-et használhassunk, ami a programozó szempontjából megegyezik az asztali gépeken használt Jávával. Ez a Connected Device Configuration (CDC), amelyet a JSR-36 szabványban specifikáltak. A CDC-hez legalább 2 MByte szabad memória kell és olyan operációs rendszer, aminek van fájlrendszere. Cserébe a CDC praktikusan J2SE 1.3 kompatibilitást nyújt.

A CDC a következő alap Jáva csomagokat támogatja:
A CDC mellé egy profilt definiáltak, amivel a J2SE 1.3-as kompatibilitás teljessé válik, ez a Foundation profil (JSR-46). A Foundation fő szolgáltatásai a következők.

2. Personal Profile, Personal Basis Profile és az Xletek

A CDC+Foundation Profile már teljes J2SE kompatibilitást nyújt, de hiányoznak belőle a felhasználói felülettel és az alkalmazásmodellel kapcsolatos szolgáltatások. A CDC tetején két bővített profil van, a Personal Basis Profile (PBP, JSR-129) és a Personal Profile (PP, JSR-62). A PBP szolgáltatásai:
Ehhez a PP még a következőket adja:
A PBP és a PP új alkalmazásmodellt specifikál, ez az Xlet. Az Xlet (pl. az Applethez és a MIDlethez hasonlóan) egy menedzselt alkalmazásmodel, tehát az alkalmazásmenedzser mondja meg, mikor induljon és mikor álljon le az alkalmazás. A MIDlet-hez hasonlóan az Xletnek is három futási állapota van, Paused, Active és Destroyed. Az állapotátmenetek a MIDlethez hasonlóan történnek. Az Xlet és környezete egy XletContext egyeden keresztül kommunikál. Az XletContext-en keresztül kérheti az Xlet, hogy futási állapota megváltozzon (pl. Destroyed állapotba akar menni). Az XletContext ezen felül hozzáférést nyújt a környezet konfigurációjához és az Xlet legfelső szintű ablakához.

Íme egy triviális Xlet:

import javax.microedition.xlet.*;

public class TrivialXlet implements Xlet {
  private XletContext context;

public TrivialXlet(){
}

public void destroyXlet( boolean unconditional ) throws XletStateChangeException {
}

public void initXlet( XletContext context ) throws XletStateChangeException {
  this.context = context;
}

public void pauseXlet(){
}

public void startXlet() throws XletStateChangeException {
  context.notifyDestroyed(); // immediately quit
}

}

A MIDletekhez képest újdonság, hogy az Xletek kommunikálni tudnak egymással, ez az Inter-Xlet Communication (IXC). Az IXC igen hasonlít az RMI-hez (Remote Method Invocation, lásd később). Az elv az, hogy objektumokat hozunk létre és az objektumegyedeket egy névhez kötve regisztráljuk egy közösen elérhető adatbázisban (registry). Ezek után a többi alkalmazás a név alapján kiveheti az objektum u.n. távoli referenciáját a registry-ből és meghívhatja metódusait. A távoli referencia és az eredetileg regisztrált objektumegyed kapcsolata implementációfüggő. Általában a távoli referencia nem az eredetileg regisztrált objektumra mutat, hanem annak egy helyettesítő objektumra (stub). Ha a helyettesítő objektum metódusát meghívjuk, az implementáció gondoskodik róla, hogy a hívás végül a regisztrált objektum objektum megfelelő metódusában és a regisztráló Xlet kontextusában kössön ki.

Az Xlet alkalmazásmodel egyelőre nem használt széleskörűen.