MIDP 2.0

Paller Gábor

1. A MIDP 2.0 szabvány

A MIDP 1.0 nagyon sikeres lett, jelenleg a középkategóriás telefonok kb. 40%, a felső kategóriások 90%-át látják el Jáva támogatással (az átlag az alsó kategóriában átlagosan 2%).A növekvő népszerűség a szabvány bővített változatának elkészítésére késztette a gyártókat, ez a MIDP 2.0 (JSR-118).Ez felfelé kompatibilis a MIDP 1.0-val. A legjelentősebb változások a következők:
 A MIDP 2.0-t a CLDC 1.1 (JSR-139) konfiguráció tetején tervezték futtatni. Maga a szabvány azonban nem tételez fel a konfigurációról semmit se, ami miatt ne lehetne a CLDC 1.0 tetején is futtatni. A CLDC 1.1 tulajdonságai a következők az 1.0-hoz képest.

Főként a lebegőpontos támogatás miatt a ROM-igény megnőtt, 160 kBájtról 192 kBájtra.

2. Bővített biztonsági rendszer a MIDP 2.0-ban

A MIDP 1.0 nagyon egyszerű biztonsági rendszerrel rendelkezik: a homokozóban futó MIDletek bármit megtehetnek, de csak a homokozó keretein belül. Nem férhetnek hozzá semmilyen szolgáltatáshoz, mellyel kár okoznának a telefonban ill. annak használójának. Ez egy egyszerű és biztonságos model, de nagyon korlátozott. A MIDP 2.0-ban egy új, engedélyeken (permission) alapuló rendszert vezettek be, ami a J2SE biztonsági rendszerének egyszerűsített változatának tekinthető és teljesen kompatibilis a MIDP 1.0-val.

A MIDP 2.0 midlet sorozatokat aláírják. Ez azt jelenti, hogy a digitális aláírást és a hozzátartozó igazolást (certificate) egyaránt elhelyezik az alkalmazásleíróban (JAD fájl). Érdekesség, hogy a JAR fájloknak van egy aláírási szabványa, azonban a MIDP 2.0 nem ezt használja, a MIDP 2.0 JAR fájlja nincs aláírva. Amikor a JAR letöltődik, a JAR-ra újraszámolják a digitális aláírásban levő hash-t. Ha ez illeszkedik, akkor  a megfelelő igazolást az alkalmazásleíróban ellenőrzik, hogy a telefonban tárolt mesterigazolásra (root certificate) illeszkedik-e. Ha igen, akkor a JAR-t elfogadják az igazolás tulajdonosától származónak.

Az aláírás alapján meghatározzák a midlet sorozathoz tartozó engedélyeket. Ezeket az engedélyeket a telefonba épített policy tárolja. Ez a policy a szokásos implementáció szerint fix, a gyártáskor rögzítődik és nem lehet manipulálni. Lényegileg a policy azt mondja meg, hogy egy bizonyos aláíráshoz milyen engedélyek tartoznak. A midlet sorozatnak emelett meg kell igényelnie az általa használni kívánt engedélyeket  a manifest fájlban. Példa:

MIDlet-Permissions: javax.microedition.io.PushRegistry, javax.microedition.io.Connector.serversocket

Amikor a JAR letöltődik, az igényelt engedély ellenőrződik a policy engedélyeivel szemben és ha az igénylő midlet sorozat nem kaphatja meg az engedélyt, akkor az nem is installálódik. A másik lehetőség, hogy a midlet sorozat képes az engedély nélkül is működni csökkentett funkcionalitással. Ilyenkor a midlet sorozat opcionálisan igényelheti meg az engedélyt.

MIDlet-Permissions-Opt: javax.microedition.io.PushRegistry, javax.microedition.io.Connector.datagramreceiver

Ha a midlet sorozat opcionális engedélyt igényel, akkor is installálódik, ha az engedélyt nem kaphatja meg. Ha a midlet sorozat meghív egy metódust, amit a meg nem kapott engedély véd, SecurityException lesz az eredmény. A midlet leellenőrizheti a MIDlet alaposztály checkPermission metódusával, hogy megkapta-e valamelyik engedélyt.

A policy kétféleképpen rendelkezhet valamely engedélyről. Egy engedély lehet Allowed ill User. Az Allowed engedélyt a midlet sorozat minden további nélkül megkapja, az User minősítővel megjelölt engedélyek megadása előtt azonban meg kell kérdezni a felhasználót. Háromféle opció lehetséges: az engedély megadása lehet blanket, session vagy oneshot. A blanket azt jelenti, hogy a felhasználót csak egyszer, a legelső végrehajtáskor kell megkérdezni, hogy megadja-e ezt az engedélyt az alkalmazásnak. Session esetében a MIDlet minden egyes futtatásakor fel kell tenni a kérdést, de csak egy futtatás során egyszer. A oneshot azt jelenti, hogy a védett funkció minden egyes meghívása előtt fel kell tenni a kérdést.

3. Push registry

A MIDletek nem tudnak állandóan futni. A legtöbb implementáció eleve nem teszi lehetővé több MIDlet egyidejű futtatását. Ebben a környezetben "szerver" alkalmazások írása csak úgy megoldható, hogy az AMS-nél lehet regisztrálni, milyen eseményre figyeljen az AMS és az esemény bekövetkezésekor mit hívjon meg. Ezt a mechanizmust push registry-nek hívják. Az esemény bekövetkezésekor a startApp metódus hívódik meg, ahol a MIDlet megszerezheti az eseménnyel kapcsolatos adatokat az AMS-től.


Manifest:

MIDlet-Name: SunNetwork - Chat Demo
MIDlet-Version: 1.0
MIDlet-Vendor: Sun Microsystems, Inc.
MIDlet-Description: Network demonstration programs for MIDP
MicroEdition-Profile: MIDP-2.0
MicroEdition-Configuration: CLDC-1.0
MIDlet-1: InstantMessage, /icons/Chat.png, example.chat.SampleChat
MIDlet-Push-1: datagram://:79, example.chat.SampleChat, *
MIDlet-Permissions: javax.microedition.io.PushRegistry, javax.microedition.io.Connector.datagramreceiver

A MIDlet-Push-n sor egy push midletet dwfiniál. A push midletnek normális MIDlet-n sorban is definiálni kell lennie, ezen felül ha még MIDlet-Push-n sorban is definiálva van, akkor az AMS megnyit számára egy kapcsolatot, amit az első mező ad meg, megengedi a kapcsolódást mindenhonnan, amit a harmadik mező megenged (jelenleg *, mindenhonnan kapcsolódhatnak). A MIDletnek rendelkeznie kell javax.microedition.io,PushRegistry engedéllyel, hogy regisztrálhasson a push registry-be.

A manifest-hez tartozó startApp metódus a következő:

public void startApp() {
  String connections[];
  connections = PushRegistry.listConnections(true);
  for (int i=0; i < connections.length; i++) {
// connections[i] egy megnyitható kapcsolat URL-jét jelzi
  }
...
}

4. Játék UI és Media API

Nagyon röviden a játék UI szolgáltatásai a következők a normál Canvas UI-hoz képest

Ezen felül a MIDP 2.0 támogat médialejátszást is. A Media API-n keresztül médiafájlokat lehet letölteni vagy folyamatosan lejátszani (streaming)

5. JTWI

A Java Technology for Wireless Industry (JTWI) egy szabványgyűjtemény, ami azt írja le, mit kell támogatnia egy Jáva-képes telefonnak. Ez azt célozza megelőzni, hogy a telefonok sok, egymással nem kompatibilis API-készletet támogassanak. A JTWI-t a JSR-185 írja le és a következő főbb megkötéseket tartalmazza.