2. Qu`est-ce que J2ME

Mohamed Quafafou
ESIL – Département Internet
Février 2007
Table de Matière
1.
2.
3.
Pourquoi J2ME ............................................................................................................... 2
Qu’est-ce que J2ME ....................................................................................................... 2
Les Outils de développement et de tests ........................................................................ 4
a. J2ME Wireless Toolkit 2.1....................................... Error! Bookmark not defined.
b. NetBeans IDE ........................................................... Error! Bookmark not defined.
4. La problématique multi-plateformes et multi-périphériques de Java............................ 4
5. CDC (Connected Device Configuration) ....................................................................... 5
6. CLDC (Connected Limited Device Configuration) ....................................................... 6
7. MIDP (Mobile Information Device Profile) .................................................................. 6
8. Les Midlets ..................................................................................................................... 7
9. L’interface Utilisateur .................................................................................................... 7
a. Présentation ................................................................................................................ 7
b. L'interface utilisateur de haut niveau ......................................................................... 8
c. L'interface utilisateur de bas niveau ........................................................................... 9
10.
Le stockage persistent .............................................................................................. 10
11.
Le réseau .................................................................................................................. 12
12.
Mon premier Midlet : « Hello IAAI » ...................................................................... 13
13.
Conclusion ................................................................................................................ 15
1
1. Pourquoi J2ME
Avec l’avènement des nouvelles technologies, la radio, la télévision, les satellites, les
téléphones cellulaires, la société actuelle est devenue une société de communication. La
communication, et particulièrement la diffusion d’informations, sont maintenant une étape
clef de tout les processus économiques. Parmi les médias permettant une diffusion efficace et
très large, l’informatique portable s’est placée en peu de temps au devant de la scène des
produits du progrès ayant un impact fort sur les habitudes de ses usagés, modifiant leur façon
d’agir, de conceptualiser le monde qui les entours. Chacun d’entre nous sollicite son portable
(téléphones, ordinateurs de poche, PDA) de plus en plus souvent pour des services divers et
variés. Dans ce contexte, les applications écrites pour les utilisateurs sont de plus en plus
complètes et complexes. Cependant, chaque nouveau système nécessite une réécriture de
l’application pour lui. De même, le langage de programmation de ces appareils n’est pas
suffisamment structuré ou formalisé pour permettre à leurs utilisateurs de faire eux même du
développement.
Mais, comment faire partager une structure unique aux différents constructeurs de systèmes
portables alors qu’ils se livrent à une guerre commerciale sans merci ? Quel système serait
suffisamment puissant, portable et efficace pour fédérer l’ensemble des développeurs. La
solution existe maintenant, il s’agit de J2ME.
2. Qu’est-ce que J2ME
J2ME signifie Java 2 Micro Edition. Il s’agit donc d’une version allégée de la machine
virtuelle JAVA, adaptée aux systèmes portables. On connaît principalement Java en tant
qu'environnement de programmation pour serveurs, centré autour des technologies qui ont
permis de réaliser Java 2 Enterprise Edition (J2EE), telles les Enterprise JavaBeans (EJBs),
les servlets, et les JavaServer pages (JSPs). Néanmoins, ce langage avait initialement été
conçu en tant qu'environnement pour applications "côté-client". En fait, Java avait été conçu
pour les appareils ménagers. Et maintenant, avec Java 2 Micro Edition Java retourne à ses
sources.
Le "Java" auquel on fait habituellement référence est connu plus formellement sous le nom de
Java 2 Platform. La Java 2 Platform est subdivisée en trois éditions : Java 2 Standard Edition
(J2SE), Java 2 Enterprise Edition (J2EE), et Java 2 Micro Edition (J2ME). Chaque édition de
cette plateforme fournit un environnement complet pour exécuter les applications basées sur
Java, incluant une machine virtuelle Java (Java virtual machine = JVM) et les classes
exécutables. Chacune de ces trois éditions cible des catégories différentes d'applications
exécutées par des types différents de machines. Les applications destinées aux "ordinateurs de
bureau" sont développées à l'aide de J2SE, qui fournit les classes d'interface utilisateur
nécessaires. Les applications destinées aux serveurs sont développées à l'aide de J2EE, qui
met l'accent sur la programmation basée sur les composants et le déploiement. Quant à J2ME,
il cible les ordinateurs de poche et les machines "embarquées".
2
En effet, les terminaux portable (téléphones cellulaires, Palm, etc…) imposent un certain
nombre de contraintes :
o La majorité des terminaux sans fil sont utilisés dans une main
o Petits écrans
o Tous les terminaux n’ont pas de terminal de pointage
o méthodes d'entrées alternatives
o Mémoire limité
o Processeur lent et architectures différentes
Ce qui différencie chacune des éditions, c'est donc principalement l'ensemble des
bibliothèques de classes définies au sein de chacune d'elles.
Organisation des plateformes JAVA
J2ME est un sous-ensemble de J2SE, et J2SE à un sous-ensemble de J2EE. On peut exécuter
le même code Java sur chacune des éditions, dès l'instant où les classes auxquelles le code fait
appel sont disponibles. Le noeud du problème, c'est que bien entendu les machines qui
fonctionnent avec J2ME, en particulier les plus petites, disposent de moins de classes que
J2SE et J2EE peuvent en fournir. Les diverses spécifications qu'incluent J2ME sont toutes
définies au travers du Java Community Process (JCP), comme cela est fait pour J2SE et J2EE.
3
3. Outils de développement et de tests
Le J2ME Wireless Toolkit de SUN comprend un ensemble d’outils permettant aux
développeurs d’applications de bénéficier d’un environnement
d’émulation, d’une
documentation ainsi que des exemples de la technologie JAVA J2ME. En effet, il n’est pas
nécessaire de posséder un appareil supportant le J2ME pour développer et expérimenter ses
applications personnels : un téléphone portable virtuel est alors émulé. Des exemples
d’applications (Midlet) livrées sont directement expérimentables.
4. La problématique multi-plateformes et multi-périphériques de
Java
Java 2 Micro Edition est une architecture technique dont le but est de fournir un socle
de développement aux applications embarquées. L’intérêt étant de proposer toute la
puissance d’un langage tel que Java associé aux services proposés par une version
bridée du Framework J2SE : J2ME. Les terminaux n’ayant pas les mêmes capacités en
terme de ressources que les ordinateurs de bureau classiques (mémoire, disque et
puissance de calcul), la solution passe par la fourniture d’un environnement allégé afin de
s’adapter aux différentes contraintes d’exécution. Cependant, comment faire en sorte
d’intégrer la diversité de l’offre à un socle technique dont la cible n’est pas définie à priori
? La solution proposée par J2ME consiste à regrouper par catégories certaines familles de
produits tout en proposant la possibilité d’implémenter des routines spécifiques à un
terminal donné. L'architecture J2ME se découpe donc en plusieurs couches :
Les profiles : Ils permettent à une certaine catégorie de terminaux d’utiliser des
caractéristiques communes telles que la gestion de l’affichage, des évènements
d’entrées/sorties (pointage, clavier, …) ou des mécanismes de persistance (Base de
données légère intégrée). Ces profiles sont soumis à spécifications suivant le principe du
JCP (Java Community Process)
Les configurations : Elles définissent une plate-forme minimale en terme de services
concernant un ou plusieurs profiles donnés.
Les machines virtuelles : En fonction de la cible, la machine virtuelle pourra être
allégée afin de consommer plus ou moins de ressources (KVM, CVM, …)
4
Le système d’exploitation : L’environnement doit s’adapter au système d’exploitation
existant
(Windows
CE,
Palm
Os,
SavaJe,
…)
Cette architecture en couche a pour but de factoriser pour des familles de produits
données un ensemble d’API permettant à une application de s’exécuter sur plusieurs
terminaux sans modification de code. Dans cette optique, la plate-forme propose deux
configurations :
CDC (Connected Device Configuration) : Spécifie un environnement pour des
terminaux connectés de forte capacité tels que les « set top boxes », les téléphones à
écran, la télévision numérique, …
CLDC (Connected Limited Device Configuration) : Cible les périphériques à
ressources limitées ou faibles tels que les téléphones mobiles, les assistants personnels,
ou les périphériques légers sans fil (wireless)
Voyons de plus près les contraintes en terme de ressources imposées par ces deux
configurations.
5. CDC (Connected Device Configuration)
Les caractéristiques de l’environnement matériel proposé par la configuration CDC sont :
Minimum de 512Ko de ROM et 256Ko de RAM, processeur 32 bits
Une connexion réseau obligatoire (sans fil ou pas)
Support des spécifications complètes de la machine virtuelle Java (CVM)
Cette configuration s’inscrit donc dans le cadre d’une architecture Java presque complète.
5
6. CLDC (Connected Limited Device Configuration)
Cette configuration s’adresse aux terminaux légers tels que les téléphones mobiles ou les
assistants personnels. Ces périphériques étant limités en terme de ressources,
l’environnement classique ne permet pas de respecter les contraintes d’occupation
mémoire liée à ces appareils. J2ME définie donc un ensemble d’API spécifiques à CLDC et
destinées à utiliser les particularités de chaque terminal d’une même famille (profile).
La liste suivante résume l’ensemble de ces caractéristiques :
Minimum de 160Ko à 512Ko de RAM, processeur 16 ou 32 bits, vitesse 16Mhz ou plus
Alimentation limitée, prise en charge d’une batterie
Connexion réseau non permanente, sans fil.
Interface graphique limitée ou inexistante
Cette configuration est définie par un sous-ensemble de classes Java s’exécutant dans la
KVM (KiloByte Virtual Machine). Elle s’inscrit donc dans une logique d’économie de
ressources avec une KVM de 40 à 80 Ko s’exécutant 30 à 80% moins vite qu’une JVM
normale. Il n’y aucun compilateur Just-In-Time ni même de prise en charge des nombres
flottants. Quant au Multi-threading et au Ramasse miettes, ils demeurent supportés.
Toutefois, CLDC n’intègre pas la gestion des interfaces graphiques, la persistance ou
les particularités de chaque terminal. Ces aspects ne sont pas de sa responsabilité. Le
tableau suivant résume les packages et classes présentes dans cette couche :
Liste des packages de CLDC
Java.io
Fournit la gestion des flux d’entrées/sorties
Java.lang
Classes de base du langage (types, etc.)
Java.util
Contient les collections et classes utilitaires
Javax.microedition.io
Classes permettant de se connecter via TCP/IP
7. MIDP (Mobile Information Device Profile)
MIDP est à la base de l’implémentation des classes liées à un profile donné. On y trouve
les méthodes permettant de gérer l’affichage, la saisie utilisateur et la gestion de la
persistance (base de données). Il existe aujourd’hui deux implémentations majeures de
profiles MIDP. L’une, plus spécifique, destinée aux Assistants de type Palm Pilot
(PalmOs) et l’autre, totalement générique, proposée par Sun comme implémentation de
référence (RI). Ces profiles sont en libre téléchargement sur le site de Sun et intègrent
plusieurs émulateurs permettant de tester les applications de manière logicielle. Les API
liées à MIDP font aussi partie de ce package :
Liste des packages de CLDC
javax.microedition.lcdui
Fournit la
gestion
(contrôles, etc.)
de
l’interface
utilisateur
javax.microedition.midlet
Socle technique destiné à gérer le cycle de vie des
midlets
6
javax.microedition.rms
Base de données persistante légère
L’API lcdui est chargée de gérer l’ensemble des contrôles graphiques proposés par ce
profile.
Quant à la gestion des événements, elle suit le modèle des listeners du J2SE avec un
CommandListener appelé en cas d’activation d’un contrôle. Pour finir, io et rms, eux,
fournissent les routines nécessaires aux entrées/sorties réseau et à la prise en charge
d’une zone physique de stockage.
8. Les Midlets
Les Midlets sont l'élément principal d'une application Java embarquée. Pour bien saisir
leur mode de fonctionnement, il suffit de prendre comme analogie les Applets ou les
Servlets.
Le cycle de vie d’une Applet est géré par un conteneur, en l’occurrence le Navigateur
Web, dont le rôle est d’interagir avec celle-ci sous la forme de méthodes de notifications
prédéfinies (init(),paint(),destroyed(),…).
Une servlet possède les mêmes caractéristiques qu’une Applet excepté le fait que le
conteneur est un moteur de servlet (Tomcat, WebSphere, WebLogic, …).
Quant aux Midlets, ils représentent le pendant des Applets et des Servlets pour J2ME
avec comme conteneur votre téléphone mobile ou votre assistant personnel. Ainsi, en cas
de mise à jour d’une application embarquée, un simple téléchargement de code Midlet
est nécessaire à partir d’un quelconque serveur.
De cette manière, un programme développé pour un profile donné est en mesure de
s’exécuter sur tous les périphériques correspondant à cette famille. C’est aussi une
manière de découpler le socle technique des applicatifs puisque le seul lien existant entre
les logiciels embarqués et le terminal est l’API J2ME.
9. L’interface Utilisateur
a. Présentation
MIDP est conçu pour fonctionner sur de nombreux types de terminaux : téléphones, Palm
Pilot, etc. 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é et la seconde 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 : on
doit explicitement dessiner chaque composant, y compris les commandes.
7
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.
b. L'interface utilisateur de haut niveau
Cette API est de loin plus riche en classes que l'API de bas niveau. Le premier composant est
la liste déroulante présentant un menu d'options. Les classes correspondantes sont List et
ChoiceGroup. Elles implémentent toutes deux l'interface Choice.
La classe TextBox permet à l'utilisateur de saisir du texte. Des contraintes de saisie peuvent
être spécifiées.
La classe Alert met en place une alerte. C'est une boîte de dialogue affichant un message
textuel, éventuellement accompagné d'une image ou d'un son. Elle permet ainsi d'afficher un
avertissement, une erreur, une alarme, … Pendant cet affichage, l'interface utilisateur est
désactivée. Si une valeur de timeout a été spécifiée, l'alerte disparaît ensuite automatiquement,
sinon l'application attend une action de l'utilisateur.
La classe Form est un formulaire. Il contient un ensemble d'éléments (items) comme des
textes, des listes ou des images. Un Item correspond à un composant de formulaire. Il est
accompagné d'un libellé. Un ImageItem affiche une image, un StringItem un texte que
l'utilisateur ne peut pas modifier.
La classe Gauge définit une jauge. Cette dernier permet d'afficher un graphique sous forme
de barre dont la longueur correspond à une valeur comprise en zéro et un maximum.
DateField définit une zone de date modifiable.
TextField est un champ de texte permettant la saisie de texte. Il est similaire en plusieurs
points à TextBox. La différence est que TextBox est une sous-classe de Screen et peut donc
être placé directement sur le Display tandis que TextField est une sous-classe de Item et doit
donc être placé dans un Form pour être affiché.
Un Ticker est un composant de l'interface utilisateur affichant une ligne de texte défilante à
une certaine vitesse.
La dernière classe est la classe Command. Elle permet de définir une commande, l'équivalent
du bouton de commande de Windows. Cette classe intègre des informations sémantiques sur
une action. Elle possède trois propriétés : le libellé, le type de commande (exemple : retour,
8
annulation, validation, sortie, aide, …) et le niveau de priorité (qui définit son emplacement et
son niveau dans l'arborescence des menus).
La gestion des événements
Un événement de haut niveau est constitué de la source de l'événement et du listener
d'événement. Cet événement provient de la source pour arriver au listener qui traite alors cet
événement. Pour implémenter un listener, il suffit que la classe l'enregistre auprès du
composant duquel on veut écouter les événements.
Il existe deux types d'événement : l'événement Screen avec son listener correspondant
CommandListener d'une part, l'événement ItemStateChanged avec le listener
ItemStateListener d'autre part.
L'une des différences est que la source d'un événement Command peut être tout objet
affichable (Displayable) tandis que la source d'un événement ItemStateChanged ne peut être
qu'un objet Form.
CommandListener
Le traitement associé à une action effectuée sur une commande est effectué dans une interface
CommandListener. Cette interface définit une méthode, commandAction, qui est appelée si
une commande est déclenchée.
Le listener correspondant est mis en place en implémentant l'interface CommandListener. On
doit alors enregistrer cette dernière avec la méthode setCommandListener
(CommandListener myListener).
ItemStateListener
Toute modification interactive de l'état d'un élément de formulaire déclenche un événement
itemStateChanged (exemple : modification d'un texte, sélection d'un élément d'une liste, …).
Le listener correspondant est mis en place en implémentant l'interface ItemStateListener. Il
faut alors enregistrer l'objet ItemStateListener auprès d'un formulaire Form avec la méthode
setItemStateListener (ItemStateListener myListener).
c. L'interface utilisateur de bas niveau
Cette API comprend les classes Canvas, Graphics et Font. La classe Canvas permet d'écrire
des applications pouvant accéder aux événements de saisie de bas niveau, offrant ainsi un
grand contrôle sur l'affichage. Les jeux sont la meilleure illustration du type d'application qui
utilisera ce mécanisme.
Elle comprend également la classe Graphics. Elle permet de produire des graphiques en 2D.
Elle est similaire à la classe java.awt.Graphics de J2SE.
9
La classe Font représente les polices de caractères ainsi que les métriques associées.
La gestion des événements
La classe Canvas est une sous-classe de la classe Displayable. Elle permet d'enregistrer un
listener de commandes.
Il est cependant préalablement nécessaire de créer plusieurs interfaces listener, chacune étant
associée à un type d'événement.
Les touches
Chaque touche à laquelle un événement est associé est identifiée par un code de touche
(exemple : KEY_NUM0 pour la touche 0).
Il existe trois types de méthodes de gestion des événements relatifs à ces touches :
keyPressed(), keyReleased() et keyRepeated(). Attention, ce dernier événement n'est pas
supporté par tous les terminaux. Pour savoir s'il est supporté, if faut appeler la méthode
hasRepeatEvents().
Les actions de jeu
Des actions de jeu sont prédéfinies. Ces actions correspondent par exemple aux flèches de
déplacement (exemple : DOWN correspond à la touche pour descendre).
Les commandes
Comme avec les sous-classes de la classe Displayable, on peut ajouter des commandes à un
objet Canvas et enregistrer un CommandListener auprès de l'objet Canvas.
La gestion du pointeur
Sur certains terminaux, un pointeur peut être utilisé pour appuyer sur l'écran. Trois
d'événements sont mis à votre disposition : pointerDragged(),pointerPressed() et
pointerReleased(). Pour vérifier qu'un tel mécanisme est disponible sur le terminal sur lequel
tourne le MIDlet, utilisez cette méthode : hasPointerEvents().
10.
Le stockage persistent
10
RMS (Record Management System) est une API de stockage persistent sur le terminal. C'est
en quelque sorte une base de données indépendante du terminal. Chaque enregistrement est
représenté sous forme de tableau d'octets. La mise est jour est dite atomique : l'enregistrement
entier est réécrit à chaque fois.
Les enregistrements sont stockés dans ce que l'on appelle un Record store. Si l'on veut faire
un parallèle avec les SGBD relationnels, RMS correspond au SGBD lui-même et le Record
store à la table. D'ailleurs, le parallèle de la notion de clé primaire des bases de données
relationnelles est le recordID. Il s'agit de l'identifiant de l'enregistrement. C'est un nombre
entier. La valeur de l'ID du premier enregistrement est 1 et chaque nouvel enregistrement a
une valeur ID augmentée de un.
Plusieurs méthodes permettent de gérer les Records store :
openRecordStore et closeRecordStore permettent respectivement d'ouvrir et de fermer un
Record store.
La liste de tous les Record
deleteRecordStore en supprime un.
store
peut
être
obtenue
par
listRecordStore.
Le nombre d'enregistrements dans un Record store est retourné par getNumRecords.
Les opérations de base sur les enregistrements sont assurées par ces méthodes : addRecord
(ajout), deleteRecord (suppression), getRecord (lecture), setRecord (modification),
getRecordSize (taille de l'enregistrement).
L'API RMS dispose cependant de quelques particularités supplémentaires, concernant la
sélection des enregistrements. La première est l'utilisation de la méthode
RecordEnumeration pour lister tous les enregistrements du Record store. La seconde est la
possibilité de définir un filtre avec la méthode RecordFilter. Enfin, l'interface
RecordComparator doit être implémentée pour que des enregistrements puissent être
comparés et donc triés.
11
11.
Le réseau
Présentation
Avec plus de 100 classes, l'API de J2EE dédiée au réseau, aux entrées / sorties et au stockage
est beaucoup trop lourde que celle utilisée pour les terminaux CLDC.
Elle est remplacée dans la CLDC par le GCF (Generic Connection Framework).
Le GCF assure une plus grande cohérence entre les différents types d'entrées / sorties tout en
améliorant la portabilité des applications.
Le GCF
Le GCF fournit un moyen uniforme et pratique d'effectuer des entrées / sorties quelque soit le
type de protocole. La syntaxe générale est la suivante :
Connector.open("<protocole>://<adresse>:<parametres>");
Plusieurs protocoles sont utilisables. On peut par exemple lire un fichier en passant par le
système de gestion de fichier du terminal :
Connector.open ("file://monfichier.txt");
Le plus fréquent sera probablement d'utiliser le célèbre protocole HTTP. Ainsi, on peut
télécharger la page d'accueil du site Yahoo :
Connector.open ("http://www.yahoo.fr");
Pour créer une application du type peer 2 peer, on pourra utiliser les sockets :
Connector.open ("socket://www.monsite.com:8001");
On peut également contrôler l'éventuel port série du terminal :
Connector.open("comm://9600:18N");
HttpConnection
Il faut cependant savoir que la seule obligation de l'implémentation MIDP est d'implémenter
le protocole HTTP. Les autres protocoles ne sont donc pas obligatoirement disponibles sur le
terminal.
MIDP complète le GCF avec HttpConnection, qui comprend les méthodes classiques.
12
getRequestProperty et setRequestProperty permettent d'obtenir ou de spécifier des
propriétés d'une requête.
getRequestMethod et setRequestMethod retournent et modifient le type de la méthode de la
requête : Get, Post ou Head.
getResponseCode et getResponseMessage retournent respectivement le code d'état renvoyé
par le serveur et le libellé associé.
getHeaderField permet d'obtenir la valeur d'un champ figurant dans les entêtes HTTP.
getURL retourne l'URL.
12.
Mon premier Midlet : « Hello IAAI »
La procédure de création, d’installation et d’exécution d’une application MIDP est
différente de celle utilisée pour une application Java standard. On va donc examiner la
structure d’une application MIDP à travers un exemple, HelloMIDlet, dont voici le listing :
/**
* <p>Title: HelloMIDlet</p>
* <p>Description: Premi`ere MIDlet semblable un "Hello World"</p>
* <p>Copyright: Copyright (c) 2003</p>
* <p>Company: </p>
* @author Mesud HASANOVIC et Lucas PRETRE
* @version 1.0
*/
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
public class HelloMIDlet extends MIDlet implements CommandListener {
private Display affichage;
private TextField champTexteHello;
private Command boutonQuitter;
private Form formPrincipal;
public HelloMIDlet() {
// Retourne l’objet Display unique cette MIDlet
affichage = Display.getDisplay(this);
// Crée le form principal
formPrincipal = new Form("HelloMIDlet");
// Crée le bouton de commande pour quitter
boutonQuitter = new Command("Quitter", Command.SCREEN, 1);
// Crée un champ texte d’une ligne et de 15 caractères de long
// avec un étiquette (label) "Texte"
champTexteHello = new TextField("Texte", "Hello World!", 15, TextField.ANY);
// Ajoute les composants un form et met en place
// l’écouteur d’évènements
formPrincipal.addCommand(boutonQuitter);
formPrincipal.append(champTexteHello);
formPrincipal.setCommandListener(this);
}
public void startApp() {
// S´electionne affichage comme objet visible
affichage.setCurrent(formPrincipal);
}
public void pauseApp(){/*L’application va être mise en pause*/}
public void destroyApp(boolean unconditional) {/*L’application se termine*/}
public void commandAction(Command c, Displayable s) {
// Si on "clique" sur le bouton quitter
if (c == boutonQuitter) {
// La m´ethode destroyApp() doit ˆetre appel´ee manuellement
destroyApp(false);
// Demande au gestionnaire d’application de terminer l’application
notifyDestroyed();
}}}
13
Cet exemple est le traditionnel Hello World ! adapté pour les MIDlets. Comme on peut le
constater, deux paquetages sont importés : javax.microedition.midlet et javax.microedition.
lcdui. Le premier paquetage comporte la classe de base MIDlet de l’application MIDP et le
second fournit un ensemble d’éléments “interface utilisateur” de type Swing.
HelloMIDlet hérite de la classe de base MIDlet. Cette dernière propose trois méthodes
abstraites dont le gestionnaire d’applications de l’appareil se sert pour communiquer avec les
applications qu’il exécute. La méthode startApp() est appelée immédiatement après le
constructeur et à chaque fois qu’une application est activée (et non pas seulement lors de son
lancement initial !). Une application peut passer de l’état actif l’état inactif plusieurs fois au
cours d’une même exécution ; par conséquent il n’est pas judicieux d’y placer des instructions
d’initialisation (ne devant être exécutée qu’une seule fois). Ce genre d’instructions est bien
évidemment à placer dans le constructeur.
La méthode destroyApp() est appelée par le gestionnaire pour indiquer qu’une application
est sur le point de se fermer. Contrairement startApp(), cette méthode ne sera appelée qu’une
seule fois au cours de l’exécution d’une application ; on peut donc y inclure du code de
nettoyage. Vu que la spécification de la CLDC n’inclut pas la méthode finalize() pour les
objets, il faudra effectuer le nettoyage ici. Cependant, un appareil mobile est généralement
moins stable que la plate-forme standard et sera donc régulièrement éteint ou réinitialisé par
l’utilisateur. En conséquence, on ne peut pas compter sur le fait que la méthode destroyApp()
soit exécutée.
La troisième et dernière méthode abstraite, pauseApp() est à première vue étrange. Son
objectif est de signaler que l’application va se mettre en pause. Cet événement se produit
lorsque l’utilisateur passe une autre application ou se sert d’une fonction de l’appareil qui
empêche la poursuite de l’exécution de l’application. Comme la plupart des appareils n’ont
pas la puissance nécessaire pour être réellement multitâche, une application sera dans ce cas
14
de figure. Il faut donc veiller à libérer un maximum de ressources au sein de cette méthode. A
la reprise de l’application, le gestionnaire appellera la méthode startApp().
13.
Conclusion
J2ME (Java 2 Micro Edition) met à la porté des systèmes portables la puissance et la
modularité de la programmation JAVA et ce de façon adaptée aux caractéristiques des
terminaux embarqués :
- petits écrans
- architecture variable
- dispositifs d’entrée multiples
- processeur lent
- mémoire réduite
Il permet :
- de fédérer les constructeurs autour d’une plateforme unique
- la facilité d’utilisation et d’échange de programmes (code portable), propre au
langage JAVA
- de développer des applications complexes et modulaires
- aux utilisateurs de développer leurs propres applications
Cette technologie émergente prendra une importance de plus en plus grande sur le marché des
systèmes portatifs (en particulier celui des téléphones portables). Il va sans dire que cette
technologie sera un plus important pour tout système compatible et par là, un argument
commercial indiscutable.
15