Pages 1 | 2 | 3 | 4

Nous présentons dans cet article J2ME (Java 2 Micro Edition), le Java de la mobilité. C'est le Java tournant sur les terminaux légers. Un terminal J2ME dispose d'une machine virtuelle KVM au-dessus de laquelle se trouve la configuration CLDC. Elle définit les capacités minimales et les bibliothèques disponibles sur tous les terminaux. En d'autres termes, c'est le tronc commun.
CLDC est le plus petit commun dénominateur de la technologie Java applicable à une grande variété de terminaux mobiles. Il garantit la portabilité et l'interopérabilité du code entre les différents types de terminaux mobiles CLDC. La configuration CLDC ne définit que les bases communes à l'ensemble des terminaux.
Au-dessus de CLDC, on trouve le profil MIDP. C'est lui qui prend en charge les fonctionnalités de plus haut niveau. Cette archirecture permet ainsi à l'interface utilisateur d'une application J2ME tournant sur un téléphone intelligent d'être différente de celle tournant sur un Palm Pilot.

Vue d'ensemble de l'API

Le package java.lang est un sous-ensemble des classes standards du package java.lang de J2SE. Un absent de marque, toutefois : la classe Float. En effet, MIDP ne supporte pas les calculs en virgule flottante ! Vous devrez donc faire sans ou les émuler.
Le package java.io contient les méthodes nécessaires pour récupérer des informations des systèmes distants.
Le package java.util contient un petit sous-ensemble du package correspondant de J2SE, dont voici les classes retenues : Calendar, Date, TimeZone, Enumeration, Vector, Stack, Hashtable et Random.
Le principal objet du package javax.microedition.io est la classe Connector. Nous reviendrons plus longuement sur celle-ci dans la partie traitant de la connexion réseau.
Le package javax.microedition.ui permet de définir l'interface utilisateur.
Le package javax.microedition.rms implémente le système de stockage persistent, que nous aller traiter plus loin dans l'article.
Le package javax.microedition.midlet contient la classe MIDlet. C'est elle qui exécute le cycle de vie du MIDlet. Elle fournit en outre la méthode getAppProperty(key) qui permet de récupérer les informations des propriétés de l'application placées dans le fichier jad associé au MIDlet.

L'interface utilisateur

MIDP est conçu pour tourner sur de nombreux types de terminaux : téléphones, Palm Pilot, … Or la plupart de ces terminaux sans fil sont utilisés dans la main, disposent d'un petit écran et tous ne possèdent pas de système de pointage comme un stylo. Tout en respectant ces contraintes, les applications MIDP doivent intégrer toujours les mêmes fonctionnalités quelque soit le terminal. La solution a été de décomposer l'interface utilisateur en deux couches : l'API de haut niveau et celle de bas niveau. La première favorise la portabilité, la second l'exploitation de toutes les fonctionnalités du terminal. Le concepteur doit donc faire un compromis entre portabilité et bénéfice des particularités du terminal.
L'API de bas niveau donne accès direct à l'écran du terminal et aux événements associés aux touches et système de pointage. Aucun composant d'interface utilisateur n'est disponible : vous devez explicitement dessiner chaque composant, y compris les commandes.
L'API de haut niveau fournit quant à elle des composants d'interface utilisateur simples. Mais aucun accès direct à l'écran ou aux événements de saisie n'est permis. C'est l'implémentation MIDP qui décide de la manière de représenter les composants et du mécanisme de gestion des saisies de l'utilisateur.
Il est possible d'utiliser l'API de haut niveau et l'API de bas niveau dans un même MIDlet mais pas simultanément. Par exemple, les jeux qui utilisent l'API de bas niveau pour contrôler l'écran peuvent aussi utiliser l'API de haut niveau pour afficher les meilleurs scores. L'API de bas niveau peut aussi être utilisée pour tracer des graphes.

Pages 1 | 2 | 3 | 4