Livre blanc de J2ME

Livre blanc

Le livre blanc de J2ME

Bruno Delb

www.BrunoDelb.com

© 2006, Bruno DelbEn application de l’article 41 de la loi du 11 mars 1957 et du code de la propriété intellectuelle du 1er juillet 1992, toute reproduction partielle ou totale à usage collectif de la présente publication est strictement interdite sans autorisation expresse de l’éditeur.

Version : 1Date d’émission : 8 juillet 2006Auteur : Bruno Delb

Bruno DelbEmail : [email protected]

Web : www.brunodelb.com

Table des matières

Introduction 5

Le marché...................................................................................................................... 5Les freins au développement..........................................................................................6Les enjeux..................................................................................................................... 6

Java 7

Les machines virtuelles..................................................................................................8KVM (Kilo Virtual Machine)...........................................................................8CVM (Convergence Virtual Machine)..............................................................8

Les configurations......................................................................................................... 9CLDC (JSR 30)................................................................................................9CDC (JSR 36)..................................................................................................9

Les profils..................................................................................................................... 9MIDP............................................................................................................... 9PDAP (JSR 75)................................................................................................9Foundation Profile (JSR 46)...........................................................................10Personal Profile (JSR 62)................................................................................10RMI (JSR 66).................................................................................................10

Les autres API de J2ME...............................................................................................10Java Phone API..............................................................................................11Java TV API...................................................................................................11Java Card.......................................................................................................11Connexion Jini...............................................................................................11Java Embedded Server...................................................................................11Spotlet............................................................................................................ 12

Introduction à J2ME 13

Les configurations.......................................................................................................14La configuration CLDC..................................................................................14

Les profils.................................................................................................................... 15Le profil MIDP..............................................................................................16Le profil MIDP 2.0.........................................................................................17Le profil PDAP..............................................................................................17

Le profil MIDP 18

Vue d'ensemble de l'API..............................................................................................18L'interface utilisateur...................................................................................................19

L'interface utilisateur de haut niveau..............................................................19La gestion des événements.............................................................................20L'interface utilisateur de bas niveau................................................................20La gestion des événements.............................................................................20

Le stockage persistent..................................................................................................21Le réseau..................................................................................................................... 22

Le GCF.......................................................................................................... 22HttpConnection..............................................................................................22

Un exemple................................................................................................................. 23Le MIDlet HelloWorld...................................................................................23

Livre blanc de J2ME Bruno DelbEmail : [email protected] : http://www.brunodelb.com

· i

La déclaration de la classe..............................................................................24Les variables d'instance..................................................................................24Le constructeur..............................................................................................24Les méthodes du cycle de vie.........................................................................25L'interface utilisateur.....................................................................................25Le composant TextBox..................................................................................25L'association des commandes aux touches......................................................25La priorité......................................................................................................25La gestion des événements.............................................................................26Conclusion.....................................................................................................26

Le profil MIDP 2 26

Les nouvelles fonctionnalités.......................................................................................26Le modèle de sécurité....................................................................................27HTTPS/SSL...................................................................................................27Réseau et push avancés..................................................................................27Livraison d’application..................................................................................27Interface utilisateur améliorée........................................................................27Le jeu............................................................................................................. 28Le son............................................................................................................30

La sécurité................................................................................................................... 30Les autorisations............................................................................................31Les domaines de protection............................................................................31La politique de sécurité..................................................................................31Les applications signées certifiées..................................................................32Les applications signées OTA (Over The Air)................................................32

Le réseau..................................................................................................................... 32Nouveaux gestionnaires de protocole.............................................................32Appel de MIDlet............................................................................................33

Le profil PDAP 35

Introduction................................................................................................................. 35Le positionnement de PDAP...........................................................................35La raison d’être de PDAP...............................................................................35

Les PDAlets................................................................................................................. 36L’interface utilisateur...................................................................................................36

AWT.............................................................................................................. 36Interaction entre AWT et LCDUI...................................................................36

Personal Information Management (PIM)....................................................................36La connectivité............................................................................................................37

Le port série...................................................................................................37Le système de fichier.....................................................................................37

La sécurité................................................................................................................... 37

La migration d’application de J2SE vers J2ME (MIDP) 38

Pourquoi migrer une application de J2SE vers J2ME ?.................................................38Le cycle de vie............................................................................................................ 38

Le cycle de vie d’une application J2SE..........................................................38Le cycle de vie d’une application J2ME.........................................................39

Migration des fonctionnalités.......................................................................................39L’interface utilisateur.....................................................................................39Le réseau, les entrées-sorties et le stockage de données..................................39

Préparation du code pour la migration..........................................................................40Commutation du code..................................................................................................40Test du code................................................................................................................ 41

iMode 43

ii · Bruno DelbEmail : [email protected] : http://www.brunodelb.com

Livre blanc de J2ME

Des terminaux iMode...................................................................................................45L'API iMode................................................................................................................ 45

Le réseau........................................................................................................45Le stockage de données persistentes...............................................................45L'interface utilisateur.....................................................................................45

Quelles sont les différences entre Java for i-Mode et MIDP ?.......................................46Mais à quoi ressemble une i-Appli ?............................................................................47

MIDlet...........................................................................................................47iAppli............................................................................................................. 47

Le processeur Jazelle 49

Les trois états............................................................................................................... 49Changement d’état.......................................................................................................49Utilisation de registres.................................................................................................50Equilibre matériel / logiciel.........................................................................................50Performances............................................................................................................... 51

Optimisation de la machine virtuelle 53

Optimisation matérielle................................................................................................53Optimisation logicielle.................................................................................................54

Les machines virtuelles pour les terminaux mobiles.......................................54La machine virtuelle KVM.............................................................................55

Conclusion................................................................................................................... 56

Optimisation de l’application 57

Les limitations sur CLDC / KVM 58

Conclusion 61


· iii

Introduction

Le marchéTout d’abord, brossons l’état du marché actuel et faisons quelques prévisions d’évolution.

En 2000, on dénombrait 40 millions d'utilisateurs de l'Internet mobile dans le monde. En 2002, on en attend 225 millions et en 2005, 730 millions (source : eTForecasts, 02/2001).

Début 2000, on comptait 400 millions de terminaux mobiles dans le monde. On en attend 1 milliard pour fin 2002 (source : IDC 2001).

En 2001, 16,3 millions de PDAs ont été vendus dans le monde. En 2005, on attend 43,5 millions de ventes (source : eTForecasts, 2001).

Il devrait être vendu 400 millions de téléphones mobiles en 2002 (source : Siemens).

Nokia devrait distribuer 50 millions de téléphones mobiles J2ME d'ici à fin 2002, le double l'année suivante (source : Nokia).

Cependant, il faut bien comprendre que la démocratisation du téléphone mobile a eu pour effet la diminution du revenu moyen par abonné (ARPU). En suit une course à toujours plus d’abonnés. Voici quelques statistiques pour illustrer ce point :

2000

2001

2002

2003

2004

Voix 35 35 33,7 32,4 31,4

SMS 3,4 3,9 4,7 5,8 7,2

Navigation Web 0 0,3 1,1 2,1 3,2

Téléchargement et jeux

0,3 0,9 1,7 2,6 3

mCommerce 0 0,1 0,3 0,8 1,3

Total 38,7 40,2 41,5 43,7 46,1

Ratio données / total 10 % 13 % 19 % 26 % 32 %

Figure 1 - ARPU en Europe (en euros) (source : Kagan)


· 5

Les freins au développementLes freins au développement de la mobilité sont nombreux :

Frein Description

Ergonomie des terminaux

· Trop petit taille des écrans

· Clavier uniquement numérique

· Couleur trop souvent absente

· Impossibilité de recevoir un appel vocal au cours d’une communication de données

· Impossibilité de stocker localement des données

· Difficulté de configuration des téléphones

· Manque de standard d’utilisation des téléphones

Bande passante et qualité de service insuffisants

· Temps d’établissement de la connexion trop long (le GPRS possède une connexion permanente, ce qui règlera le problème)

· Risque de saturation du réseau GSM en cas de forte utilisation des services de données

Facturation au temps de communication

· Facturation au volume de données, à l’acte d’usage ou forfaitaire possibles avec l’arrivée du GPRS

Manque de service et de contenus de qualité

· Tests insuffisants sur les terminaux

Les enjeuxLes enjeux sont donc aujourd’hui de :

· créer un marché pour les services de données via des réseaux sans fil.

· identifier les usages principaux des terminaux mobiles.

· inventer les applications génératrices de revenus.

· identifier les acteurs clefs dans la chaîne de valeur.

· identifier les standards de déploiement des services de données.

· trouver les modèles économiques associés.

6 · Bruno DelbEmail : [email protected] : http://www.brunodelb.com

Livre blanc de J2ME

Java

L’utilisation de J2ME dans le développement d’applications embarquées présente un certain nombre d’avantages. Le premier d’entre eux est la mise à disposition d’outils faciles à utiliser et performants garantissant un cycle rapide d’édition, de construction et de débogage.

J2ME permet de minimiser l’utilisation du terminal dans le cycle de développement. Pour cela, il met à disposition un émulateur de terminal sur l’ordinateur de bureau, qui comprend une machine virtuelle et émule l’API. Cet émulateur reproduit fidèlement le comportement d’un terminal, y compris ses performances et son aspect physique du terminal. Il est en effet important que l’émulateur reproduise les mêmes performances qu’un vrai terminal afin de développer des applications adaptées aux performances réelles du terminal et non pas à celles de l’ordinateur sur lequel tourne l’émulateur.

Le déploiement des applications est un besoin récurent chez les développeurs. Le mécanisme de packaging de l’application y répond à ce besoin. Une autre attente des développeurs sans fil est de pouvoir tester l’application sur différents terminaux. En réponse, J2ME permet de développer des applications adaptées aux capacités des terminaux en réutilisant des sous-ensembles d’API existantes et en proposant des éléments optionnels.

Les briques de base de J2ME sont la configuration, le profil et les packages optionnels.

· Une configuration est une machine virtuelle et un ensemble minimal de classes de base et d’API. Elle spécifie un environnement d’exécution généralisé pour les terminaux embarqués et agit comme plate-forme Java sur le terminal.

· Un profil est une spécification des API Java définie par l’industrie et utilisé par les fabricants et les développeurs à destination des différents types de terminaux spécifiques.

· Un package optionnel est, comme son nom l’indique, un package qui peut ne pas être implémenté sur un terminal particulier.

La machine virtuelle J2ME et les spécifications d’API de plate-formes spécifiques sont développées en sollicitant les besoins d’entrée par l’initiative du JCP (Java Community Process) de façon à s’assurer que les spécifications répondent aux besoins spécifiques d’une famille ou d’une catégorie de terminaux clients.

Par exemple, les terminaux sans fil Handheld disposent de beaucoup moins de mémoire de stockage et de capacités d’interface utilisateur que les terminaux avec fil et utilisent des protocoles de communication différents.Une fois une JSR (Java Specification Request) acceptée par l’initiative Community Process, la JSR, qui peut être proposée par Sun Microsystems ou


· 7

par une société tiers, crée une machine virtuelle Java (JVM) et une implémentation de référence API pour la plate-forme J2ME cible.

Les principales JSR actuelles sont les suivantes :

· JSR 30 pour CLDC (Connected Limited Device Configuration)

· JSR 36 pour CDC (Connected Device Configuration)

· JSR 37 pour MIDP (Mobile Information Device Profile)

· JSR 46 pour Foundation Profile

· JSR 62 pour Personal Profile

· JSR 66 pour RMI Profile

La solution J2ME présente de nombreux avantages par rapport aux autres solutions de développement sans fil. Elle permet notamment de développer des applications Java pour les terminaux mobiles et embarqués. Les points forts de J2ME portent sur la richesse de l’interface utilisateur et sur le fonctionnement, au choix, en mode connecté ou en mode déconnecté. Java permet facilite l’accès à J2ME à tous les développeurs Java et assure la neutralité de la plate-forme. De plus, J2ME permet le chargement dynamique des applications et repose sur un modèle de sécurité Sandbox.

En plus de J2ME, d’autres technologies Java peuvent être utilisées. Ces dernières, qui ne sont pas définies sous les spécifications J2ME puisqu’elles ont les leurs, incluent Jini Connection, Java Card et Java Embedded Server.

Les machines virtuellesAu centre de la technologie Java se trouve la machine virtuelle Java JVM. Une machine virtuelle permet aux applications Java écrites dans le langage de programmation Java d’être portables sur différents environnements matériels et systèmes d’exploitation. La machine virtuelle se trouve entre l’application et la plate-forme utilisée, convertissant les bytecodes de l’application en code machine approprié au matériel et au système d’exploitation utilisé.

En plus d’exécuter les bytecodes d’une application, la machine virtuelle gère les tâches relatives à la gestion de la mémoire du système, fournissant la sécurité et la gestion de multiples threads d’exécution de programme.

J2ME propose aujourd’hui deux machines virtuelles, KVM et CVM. La première est associée à la configuration CLDC, et la seconde à CDC.

KVM (Kilo Virtual Machine)

Implémentation runtime extrêmement légère de la machine virtuelle Java pouvant être utilisée dans les terminaux avec peu de mémoire, comme les téléphones cellulaires, les pagers bidirectionnels et les PDA. Le K signifie Kilobyte, indiquant que cette machine virtuelle fonctionne avec un total de mémoire de quelque 100 Ko.

CVM (Convergence Virtual Machine)

Machine virtuelle Java 2 conçue pour les terminaux ayant besoin de l’ensemble des fonctionnalités de la JVM mais avec des capacités plus réduites. CVM est conçu pour répondre aux besoins du marché émergent des terminaux embarqués de prochaine génération. Les terminaux utilisant CVM sont généralement des terminaux compacts et connectés, orientés consommateur.


Livre blanc de J2ME

Les configurationsJ2ME comprend aujourd’hui deux configurations, CLDC (Connected Limited Device Configuration), pour les terminaux légers à connexion limitée, et CDC (Connected Device Configuration), pour les terminaux légers connectés.

CLDC (JSR 30)

Disponible comme implémentation de référence de CLDC, cette configuration consiste en la machine virtuelle K (KVM) et un ensemble de bibliothèques de classes noyau appropriées à l’utilisation dans un profil de l’industrie, comme le profil sans fil spécifié par l’implémentation de référence MIDP ou la spécification de PDA, qui sont toutes les deux décrites ci-dessous. Les terminaux concernés sont dotés d’interfaces utilisateur simplifiées, d’au moins 128 Ko de mémoire et de connexions réseau intermittentes à faible bande passante.

CDC (JSR 36)

Fondée sur la spécification de machine virtuelle classique, qui définit un environnement runtime complet comprenant, cette configuration est destinée aux terminaux plus gros, avec au moins quelques mégaoctets de mémoire disponible, et qui peuvent se connecter à Internet ou à d’autres terminaux, comme les visiophones fonctionnant sur Internet, les communicateurs et les systèmes de navigation.

Les profilsJ2ME comprend à l’heure actuelle deux familles de profils : ceux qui dépendent de la configuration CLDC, avec les profils MIDP, pour les terminaux du type SmartPhone, et PDAP (Personal Digital Assistant Profile), pour les PDA, et ceux qui dépendent de la configuration CDC, avec le Foundation Profile, le RMI (Remote Method Invocation) Profile et le Personal Profile.

MIDP

Ce profil nécessite l’implémentation de référence CLDC et fournit des classes pour l’écriture d’applications téléchargeables qui tournent sur des terminaux mobiles comme les téléphones cellulaires et les pagers bidirectionnels. Il permet le téléchargement de nouveaux services d’intérêt pour le client comme les jeux, les applications de commerce et les services de personnalisation. Le profil MIDP fournit une plate-forme standard pour les petits terminaux d’information mobiles, aux ressources limitées et connectés sans fil, aux caractéristiques suivantes :

· 512 Ko de mémoire totale (ROM + RAM) disponible pour le runtime Java et ses bibliothèques ;

· puissance et batterie limitées ;

· connectivité à certains types de réseaux sans fil à la bande passante limitée ;

· interfaces utilisateur à différents niveaux de sophistication.


· 9

PDAP (JSR 75)

Ce profil se trouve au niveau supérieur de la spécification CLDC. Il fournit des API d’interface utilisateur et de stockage de données pour les petits terminaux Handheld aux ressources limitées, comme les PDA, aux caractéristiques suivantes :

· 512 Ko de mémoire au total (ROM + RAM) disponible pour le runtime Java et les bibliothèques ;

· puissance et batterie limitées ;

· interfaces utilisateur de différents degrés de sophistication, disposant d’un affichage d’une résolution supérieure à 20 000 pixels, d’un terminal de pointage et d’une entrée pour caractères.

Foundation Profile (JSR 46)

Ce profil est destiné aux terminaux qui ont besoin de support pour une plate-forme Java avec un réseau riche mais ne nécessitent pas d’interface utilisateur. Il fournit en outre un profil de base pour d’autres profils, qui auraient besoin de construire leurs propres fonctionnalités en ajoutant, par exemple, une GUI (Graphical User Interface). Les terminaux disposent des caractéristiques suivantes :

· 1 024 Ko de ROM (sans compter les besoins mémoire des applications) ;

· 512 Ko de RAM (sans compter les besoins mémoire des applications) ;

· connectivité à certains types de réseaux ;

· aucune GUI.

Personal Profile (JSR 62)

Ce profil repackage l’environnement d’application PersonalJava pour fournir la spécification J2ME aux terminaux qui ont besoin d’un haut niveau de connectivité Internet et d’une fidélité Web. Ce profil est conçu pour être compatible avec la spécification de l’environnement d’application PersonalJava. Les caractéristiques des terminaux sont le suivantes :

· 2,5 Mo de ROM ;

· 1 Mo de RAM ;

· connectivité robuste à certains types de réseaux ;

· GUI avec un haut degré de fidélité Web et la possibilité de faire tourner des applets.

RMI (JSR 66)

Ce profil supporte le RMI interapplication sur des connexions TCP/IP pour des applications écrites en Foundation Profile. La spécification de profil RMI est interopérable avec l’API J2SE RMI.


Livre blanc de J2ME

Les autres API de J2MEParmi les autres API de J2ME déjà disponibles, certaines concernent le contrôle du téléphone, la télévision numérique ou encore la mise à disposition d’un serveur embarqué.

Java Phone API

L’API Java Phone est une extension verticale de la plate-forme PersonalJava consistant en deux profils de référence ciblant les visiophones Internet et les SmartPhones sans fil. L’API fournit un accès aux fonctionnalités spécifiques des terminaux de téléphonie client. Elle permet notamment de contrôler le téléphone, d’envoyer des messages à base de datagramme, d’obtenir des informations du carnet d’adresses et du calendrier, d’accéder au profil utilisateur et d’installer une application.

Java TV API

L’API Java TV est une extension verticale à la plate-forme PersonalJava pour créer des applications interactives pour la télévision numérique. L’API permet l’affichage en temps réel d’informations appropriées et contextuelles en parallèle avec la programmation standard : transactions de commerce électronique, publicité interactive, applications de banque à domicile, communications interactives en temps réel avec des personnalités ou des personnages animés, etc.

Java Card

Une carte intelligente est une carte de crédit dotée d’un circuit intégré (CI). Le CI contient un microprocesseur et de la mémoire de façon que la carte intelligente puisse traiter et stocker des informations. La plate-forme Java Card donne au développeur de carte intelligente la possibilité de standardiser une plate-forme de carte commune. Cela signifie, par exemple, qu’un opérateur de téléphonie sans fil GSM (Global System for Mobile communications) peut facilement développer de nouveaux services susceptibles d’être téléchargés de manière sélective sur la carte intelligente résidant dans le téléphone.

Connexion Jini

La technologie de connexion Jini permet aux services de fonctionner dynamiquement et simplement avec d’autres services. Dans une communauté Jini, les services disposent du code de découverte et de recherche dont ils ont besoin pour fournir immédiatement les services aux autres membres de la communauté. Il n’est pas nécessaire d’éditer des fichiers de configuration, d’arrêter et redémarrer des serveurs, de configurer des passerelles, etc., quand un nouveau service est mis à disposition sur le réseau, les communautés Jini supportant une infrastructure redondante.

Java Embedded Server

Le logiciel JES (Java Embedded Server) est installé sur un terminal de terminaison à large bande, comme un modem DSL-câble, pour le transformer en passerelle résidentielle. Une passerelle résidentielle est un boîtier situé chez soi qui se connecte à Internet à l’extérieur. Les appareils de connexion à Internet donne aux résidents l’accès aux services tels que la téléphonie à la demande, le contrôle de l’énergie, la sécurité de la maison, le diagnostique de l’appareil, etc.


· 11

Si la technologie de connexion Jini supporte des communautés de services spontanément crées, JES est un framework permettant de générer les services délivrés à lui. Le framework JES peut utiliser la technologie Jini pour localiser et recevoir les services d’une communauté Jini. Les services peuvent être explicitement écrits pour JES et comprendre des services Web ou HTTP, de la sécurité et des passerelles, comme l’interopérabilité Home Audio-Vidéo.

Spotlet

Spotlet, aujourd’hui abandonné, est un projet de technologie dont l’objectif était de démontrer la viabilité de J2ME. On utilise aujourd’hui à la place les profils dépendant de la configuration CLDC. Au cas où vous rencontriez une spotlet, nous présentons ici les grandes spécificités des spotlets par rapport aux MIDlets.

L’API Spotlet comprend un constructeur et neuf méthodes publiques.

Le constructeur est :

Spotlet()

La méthode suivante est utilisée pour la réception de paquets de données par infrarouge depuis un autre terminal Palm :

void beamReceive(byte[] data)

La méthode suivante est appelée si l’utilisateur presse sur l’une des touches Page Up ou Page Down, sur l’icône de la calculatrice ou du menu ou encore s’il saisit un caractère (par Graffiti) :

void keyDown(int keyCode)

La méthode suivante est appelée si l’utilisateur place le stylo sur l’affichage :

void penDown(int x, int y)

La méthode suivante est appelée si l’utilisateur déplace le stylet sur l’affichage :

void penMove(int x, int y)

La méthode suivante est appelée si l’utilisateur retire le stylet de l’affichage :

void penUp(int x, int y)

D’autres méthodes sont disponibles.

La méthode suivante enregistre les gestionnaires d’événements de l’objet et donne le focus à la spotlet pour la gestion de l’événement :

void register(int eventOptions)

La méthode suivante supprime l’enregistrement des gestionnaires d’événements de l’objet :

void unregister()

La méthode suivante est utilisée pour faire du beam, c’est-à-dire échanger des paquets de données via l’infrarouge vers un autre terminal Palm :

static boolean beamSend(byte[] data)

La méthode suivante est utilisée pour obtenir le flashID du terminal Palm :

static String getFlashID()


Livre blanc de J2ME

Introduction à J2ME

Java est un langage de développement inventé par Sun Microsystems dans les années 90. A l’origine prévu pour des développements embarqués, il connut un vif succès avec l’arrivée du Web dans les années 94. Aujourd’hui, Java est un standard de développement dans les entreprises.

L’adaptation aux terminaux mobiles a posé un certain nombre de problèmes, dont en voici les principaux :

· la machine virtuelle est logicielle et donc peu rapide

· les contraintes d’ergonomie des terminaux sont diverses et variées ; au point qu’au Japon, les développeurs ont une version par modèle de terminal

Les avantages du Java mobile sont importants :

· sa capacité de téléchargement de logiciel puis d’exécution en local

· le contrôle sur l’interface utilisateur du terminal

· sa capacité à sécuriser les transactions

· l’existence d’une communauté importante de développeurs Java

Une des caractéristiques de Java est le JCP (Java Community Process). Il s’agit d’un processus semi-ouvert de classification des demandes d’évolution de Java. Ces évolutions sont traitées par des groupes de travail appelés JSR (Java Specification Request) et composés d’entreprises et d’individus.


· 13

Figure 5 - L’architecture de la technologie Java

J2ME (Java 2 Micro Edition) vise deux familles de terminaux à travers deux configurations CLDC (Connected Limited Device Configuration) et CDC (Connected Device Configuration) :

CLDC CDC

Taille mémoire

128 à 512 Ko (RAM + ROM)

1 Mo (ROM) + 512 Ko (RAM)

Processeur 16 ou 32 bits 32 bits

Réseau Faible bande passante ou faible qualité de service du réseau

Connexion réseau

Exemples Téléphone, pager, PDA Set-top box, WebTV, Screen phone, GPS

Une configuration est une machine virtuelle et un ensemble minimal de classes de base et d’API. Elle spécifie un environnement d’exécution généralisé pour les terminaux embarqués et agit comme plate-forme Java sur le terminal.

Un profil est une spécification des API Java définie par l’industrie et utilisé par les fabricants et les développeurs à destination des différents types de terminaux spécifiques.

Les configurationsJ2ME comprend aujourd’hui deux configurations, CLDC, pour les terminaux légers à connexion limitée, et CDC, pour les terminaux légers connectés. Il propose également deux machines virtuelles :

· KVM (Kilo Virtual Machine), associée à la configuration CLDC, est une implémentation runtime extrêmement légère de la machine virtuelle Java pouvant être utilisée dans les terminaux avec peu de mémoire, comme les téléphones cellulaires, les pagers bidirectionnels et les PDA. Le K signifie Kilobyte, indiquant que cette machine virtuelle fonctionne avec un total de mémoire de quelque 100 Ko.

· CVM (Convergence Virtual Machine), associée à la configuration CDC, est une machine virtuelle Java 2 conçue pour les terminaux ayant besoin de l’ensemble des fonctionnalités de la JVM mais avec des capacités plus réduites. CVM est conçu pour répondre aux besoins du marché émergent des terminaux embarqués de prochaine génération. Les terminaux utilisant CVM sont généralement des terminaux compacts et connectés.

La configuration CLDC

CLDC ne supporte pas toutes les classes de J2SE. Par exemple, l’internationalisation est supportée de manière limitée et la localisation est implémentée par le fabricant.

Les bibliothèques réseau, d’entrées-sorties et de stockage de la technologie Java sont trop volumineuses pour les terminaux CLDC : plus de 100 classes et taille statique totale des fichiers de classes de plus de 200 Ko.


Livre blanc de J2ME

Les classes d’origine n’ayant jamais été conçues pour les petits terminaux, CLDC spécifie une alternative au Generic Connection Framework et permet :

· plus de cohérence dans le support de différents types d’entrées-sorties

· de disposer d’un moyen pratique de supporter différents protocoles

· une portabilité améliorée des applications

· la compatibilité avec les bibliothèques de classe Java standard

· une plus faible consommation mémoire

Les profilsJ2ME comprend à l’heure actuelle deux familles de profils : ceux qui dépendent de la configuration CLDC, avec les profils MIDP, pour les téléphones mobiles, et PDAP (Personal Digital Assistant Profile), pour les PDA, et ceux qui dépendent de la configuration CDC, avec le Foundation Profile, le RMI (Remote Method Invocation) Profile et le Personal Profile.

Le profil MIDP nécessite l’implémentation de référence CLDC et fournit des classes pour l’écriture d’applications téléchargeables qui tournent sur des terminaux mobiles comme les téléphones cellulaires et les pagers bidirectionnels. Il permet le téléchargement des jeux, des applications de commerce, … Il fournit une plate-forme standard pour les petits terminaux d’information mobiles, aux ressources limitées et connectés sans fil, aux caractéristiques suivantes :

· 512 Ko de mémoire totale (ROM + RAM) disponible pour le runtime Java et ses bibliothèques

· puissance et batterie limitées

· connectivité à certains types de réseaux sans fil à la bande passante limitée

· interfaces utilisateur à différents niveaux de sophistication

Le profil PDAP se trouve au niveau supérieur de la spécification CLDC. Il fournit des API d’interface utilisateur et de stockage de données pour les petits terminaux Handheld (c’est-à-dire se tenant dans la main) aux ressources limitées, comme les PDA, aux caractéristiques suivantes :

· 512 Ko de mémoire au total (ROM + RAM) disponible pour le runtime Java et les bibliothèques

· puissance et batterie limitées

· interfaces utilisateur de différents degrés de sophistication, disposant d’un affichage d’une résolution supérieure à 20 000 pixels, d’un terminal de pointage et d’une entrée pour caractères

Le Foundation Profile est destiné aux terminaux qui ont besoin de support pour une plate-forme Java avec un réseau riche mais ne nécessitent pas d’interface utilisateur. Il fournit en outre un profil de base pour d’autres profils, qui auraient besoin de construire leurs propres fonctionnalités en ajoutant, par exemple, une interface utilisateur. Les terminaux disposent des caractéristiques suivantes :

· 1 024 Ko de ROM (sans compter les besoins mémoire des applications)


· 15

· 512 Ko de RAM (sans compter les besoins mémoire des applications)

· connectivité à certains types de réseaux

· aucune interface utilisateur

Le Personal Profile repackage l’environnement d’application PersonalJava pour fournir une spécification J2ME aux terminaux qui ont besoin d’un haut niveau de connectivité Internet et d’une fidélité Web. Ce profil est conçu pour être compatible avec la spécification de l’environnement d’application PersonalJava. Les caractéristiques des terminaux sont les suivantes :

· 2,5 Mo de ROM

· 1 Mo de RAM

· connectivité robuste à certains types de réseaux

· interface utilisateur avec un haut degré de fidélité Web et la possibilité de faire tourner des applets

Le RMI Profile supporte le RMI interapplication sur des connexions TCP/IP pour des applications écrites en Foundation Profile. La spécification de profil RMI est interopérable avec l’API J2SE RMI.

Le profil MIDP

MIDP doit être utilisable sur tous les terminaux tenant dans la main, qui sont souvent caractérisés par de petits écrans et par l’absence de système de pointage.

Il est donc nécessaire de constamment penser aux utilisateurs finaux :

· Les terminaux d’information mobile sont des produits clients, par des ordinateurs de bureau.

· L’interface utilisateur doit être unifiée parmi les MIDP : les applications MIDP doivent intégrer toujours les mêmes fonctionnalités.

Les interfaces utilisateur MIDP peuvent être crées en utilisant une des deux couches d’API proposés.

· l’API de haut niveau pour la portabilité: les applications utilisant ces APIs doivent être exécutables et utilisables sur tous les terminaux MIDP et aucun accès direct aux fonctionnalités de terminal natif n’est autorisé

· l’API de bas niveau fournit un accès aux primitives de dessin natif, des événements sur les touches du terminal, des terminaux de saisie natifs, … Elle permet aux développeurs de choisir le compromis entre portabilité et fonctionnalités plus spécifiques.

Les interfaces utilisateurs des MIDlets sont constituées à partir de simples écrans. Les écrans doivent contenir une quantité minimale d’informations : en général une seule chose. Ils doivent ne demander qu’une seule interaction de l’utilisateur. Aucune opération complexe n'est possible.

L’API de haut niveau de saisie est gérée en utilisant des commandes abstraites au lieu d’accès directs aux boutons softs :

· Chaque implémentation MIDP fait une correspondance entre les boutons softs et les éléments du menu pour un terminal particulier.


Livre blanc de J2ME

· Les MIDlets peuvent fournit des conseils sémantiques (comme retour).

L’API de bas niveau donne au développeur le moyen d’accéder aux événements de pression des touches.

RMS est une base de données orientée enregistrement léger. Indépendante du terminal, cette API permet de stocker de manière persistante des données dans ce que l’on appelle un Record Store. Chaque enregistrement du Record Store dispose d’un ID unique. Ces enregistrements sont des tableaux d’octets. Les Record Store sont partagés dans un MIDlet Suite. Les enregistrements simples sont mis à jour de manière atomique.

De plus, le RMS supporte l’énumération, le tri et le filtre.

La plate-forme de terminal est responsable de l’intégrité des données lors des boots et des changements de batterie et du stockage en mémoire flash ou d’autre terminal.

Les terminaux MIDP doivent implémenter le protocole HTTP. MIDP étend le réseau du Generic Connection Framework de CLDC.

Le profil MIDP 2.0

MIDP 2.0 introduit de nouvelles fonctionnalités dans les domaines suivants :

· Sécurité : nouveau modèle de sécurité avec les MIDlets certifiées et HTTPS

· Réseau et push étendu

· Livraison d’application

· Interface utilisateur améliorée

· Nouvelles fonctionnalités pour les jeux et le son

Le profil PDAP

PDAP (Personal Digital Assistants Profile) est un nouveau profil CLDC qui cible les PDA (Personal Digital Assistants). Il fonctionne dans un environnement de puissance limitée et fournit un accès aux fonctionnalités de PDA communes. Il supporte aussi des méthodes d’entrée supplémentaires (comme le stylet) ainsi que la connectivité aux autres terminaux.

PDAP comprend des APIs spécifiques à PDAP :

· Interface utilisateur AWT

· APIs PIM (Personal Information Management)

· Connexions port série et système de fichier

PDAP contient une API complète et compatible MIDP.


· 17

Le profil MIDP

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'APILe 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.


Livre blanc de J2ME

L'interface utilisateurMIDP 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.

L'interface utilisateur de haut niveau

Cette API est de loin plus riche en classes que l'API de bas niveau. Le premier composant dont nous parlons 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 en anglais) 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é.


· 19

Un Ticker est un composant de l'interface utilisateur affichant une ligne de texte défilante à une certaine vitesse.

La dernière classe étudiée 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, 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 vous voulez é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 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. Vous devez 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. Vous devez alors enregistrer l'objet ItemStateListener auprès d'un formulaire Form avec la méthode setItemStateListener (ItemStateListener myListener).

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.

La classe Font représente les polices de caractères ainsi que les métriques associées.


Livre blanc de J2ME


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é, vous devez 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, vous pouvez 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().

Le stockage persistentRMS (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 store peut être obtenue par listRecordStore.

deleteRecordStore en supprime un.

Le nombre d'enregistrements dans un Record store est retourné par getNumRecords.


· 21

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.

Le réseauAvec 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. Nous allons voir les principaux. Vous pouvez 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, vous pouvez télécharger la page d'accueil du site Yahoo :

Connector.open ("http://www.yahoo.fr");

Si vous voulez créer une application du type peer 2 peer, vous pourez utiliser les sockets :

Connector.open ("socket://www.monsite.com:8001");

Vous pouvez é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.

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é.


Livre blanc de J2ME

getHeaderField permet d'obtenir la valeur d'un champ figurant dans les entêtes HTTP.

getURL retourne l'URL.

Plusieurs méthodes permettent de décomposer cette URL : getHost retourne le nom d'hôte, getPort le numéro de port, getFile le fichier, getQuery la requête (c'est la partie de l'URL se trouvant après le " ? ") et getRef la portion de référence (c'est la partie de l'URL se trouvant après le " # ").

Un exempleComme les applets, les MIDlets sont contrôlées par le logiciel qui les lance. Dans le cas d'une applet, le logiciel utilisé est un navigateur ou l'outil appletviewer. Dans le cas d'un MIDlet, on utilise l'implémentation du terminal qui supporte CLDC et MIDP.

Le Toolkit J2ME Wireless fournit un environnement de test pour MIDP. Il intègre notamment un émulateur de téléphone J2ME.

La première chose à savoir est que tous les MIDlets étendent la classe MIDlet, qui est l'interface entre le gestionnaire d'application et le code de l'application MIDlet.

Cette classe MIDlet fournit des interfaces pour l'appel, la suspension, la reprise et la sortie d'une application MIDlet.

Dans cet article, nous allons créer un MIDlet dont le nom est HelloWorld.

Le MIDlet HelloWorld

La structure du code d'un MIDlet est similaire à celle d'une applet : il n'y a pas de méthode main() et les MIDlets étendent toujours la classe MIDlet. Les composants de l'interface utilisateur se trouvent dans le package lcdui.

Voici le listing de notre MIDlet HelloWorld :

001: import javax.microedition.midlet.*;

002: import javax.microedition.lcdui.*;

003:

004: public class HelloWorld extends MIDlet implements CommandListener {

005: private Command cmdExit;

006: private Display myDisplay;

007: private TextBox myTextBox = null;

008:

009: public HelloWorld () {

010: myDisplay = Display.getDisplay (this);

011: cmdExit = new Command ("Sortie", Command.EXIT, 2);

012: myTextBox = new TextBox ("HelloWorld", "Bonjour le monde", 256, 0);

013: myTextBox.addCommand (cmdExit);

014: myTextBox.setCommandListener (this);

015: }

016:

017: public void startApp() {

018: myDisplay.setCurrent (myTextBox);

019: }

020:


· 23

021: public void pauseApp() {

022: }

023:

024: public void destroyApp (boolean unconditional) {

025: }

026:

027: public void commandAction (Command myCommand, Displayable myDisplayable) {

028: if (myCommand == cmdExit) {

029: destroyApp (false);

030: notifyDestroyed ();

031: }

032: }

033: }

La déclaration de la classe

La classe HelloWorld étend la classe MIDlet et implémente l'interface CommandListener (ligne 4).

En étendant la classe MIDlet, le MIDlet peut suivre son cycle de vie complet.

En implémentant l'interface CommandListener, il peut intégrer un listener d'action pour les événements de commande.

Les variables d'instance

Nous utilisons trois variables d'instance pour conserver l'état de la commande (Command), de l'affichage (Display) et de la zone de saisie (TextBox). Elles sont initialisées dans le constructeur (lignes 5 à 7).

Le constructeur

Le constructeur effectue une succession d'actions. La première est de récupérer l'objet Display associé à cette instante de la classe HelloWorld (ligne 10). L'objet Display correspond au gestionnaire de l'affichage du terminal. Il comprend des méthodes de récupération des propriétés du terminal et d'affichage d'objets sur le terminal.

Puis il crée une commande du type EXIT avec une priorité de niveau 2 (ligne 11).

Ensuite, il crée et initialise le seul composant de l'interface utilisateur du MIDlet, à savoir une zone de saisie (TextBox) ayant pour texte Bonjour le monde (ligne 12). La longueur maximale de saisie est de 256 caractères et aucune contrainte de saisie n'est spécifiée (d'où la valeur 0). Ce composant permet la saisie au clavier. Les éventuelles contraintes de saisie restreignent les caractères qui peuvent être entrés.

La commande de sortie est associée à la zone de saisie (ligne 13).

Le listener d'action du MIDlet est mis en place sur le composant TextBox (ligne 14). Ainsi, la méthode HelloWorld.commandAction sera appelée dès lors qu'une commande sur le TextBox génèrera un événement.

Après l'appel du constructeur, la méthode startApp() est appelée. Dans notre exemple, le composant TextBox est passé à l'objet Display pour le rendre visible sur l'affichage du terminal (ligne 18). Tout MIDlet a un et un seul objet Display.


Livre blanc de J2ME

Les méthodes du cycle de vie

Le gestionnaire d'application appelle les méthodes associées aux différentes étapes de son cycle de vie. Il appelle en tout premier la méthode startApp() pour lancer le MIDlet. Dans notre cas, elle rend le Display courant (lignes 17 à 19).

La second étape du cycle de vie est la suspension du MIDlet. Cela est fait en appelant la méthode pauseApp().Cette méthode doit libérer les ressources partagées comme les threads ou les connexions. Dans notre exemple, nous ne faisons rien (lignes 21 et 22).

La troisième et dernière étape consiste à terminer et détruire le MIDlet. Pour cela, le gestionnaire d'application appelle la méthode destroyApp(). Cette méthode libère toutes les ressources et sauvegarde toutes les données persistentes. Nous n'utilisons ni des ressources ni des données persistentes, la méthode est donc vide (lignes 24 et 25).

L'interface utilisateur

L'interface utilisateur est basée sur un composant TextBox, similaire aux composants TextArea et TextField de l'AWT (Abstract Window Toolkit). Il faut savoir que l'interface utilisateur d'un MIDlet est adaptée aux caractéristiques des terminaux mobiles légers.

Le composant TextBox

Notre interface utilisateur, en dehors d'une commande, ne comprend qu'un seul composant, un TextBox. Ce dernier possède trois propriétés : un libellé, un contenu initial (c'est la valeur par défaut) et un type. Pour utiliser cet objet, il vous suffit lors de la création du composant de spécifier le libellé et le contenu initial. Ensuite, vous ajoutez les commandes à la zone de saisie et demandez au MIDlet d'écouter les événements d'action en appelant les méthodes TextBox.setCommand et TextBox.setCommandListener.

Dans notre exemple, le texte HelloWorld apparaît dans la zone du titre et le texte Bonjour le monde apparaît dans la zone du contenu initial. La commande Sortie apparaît dans la zone de commande et est associée à la touche juste en dessous et à sa droite.

L'association des commandes aux touches

L'association des commandes aux touches est dépendante du terminal et est gérée par le terminal selon le type spécifié lors de la création de la commande. La classe MIDP Command vous permet de spécifier les types de commande : BACK, CANCEL, EXIT, HELP, ITEM, OK, SCREEN et STOP.

Dans notre exemple, la pression du bouton dont le texte figure au-dessus appelle la méthode commandAction() et lui passe une référence à la commande cmdExit. La pression de la touche rouge appelle la méthode destroyApp(true). Le MIDlet se termine alors et l'environnement retourne au gestionnaire d'application.


· 25

La priorité

Si plusieurs commandes d'une même application ont un même type de commande, alors la valeur de priorité fixée détermine la manière dont va se faire l'association des commandes aux touches. Plus la valeur de priorité est grande, plus importante est la commande.

Concrètement, le terminal choisit l'emplacement d'une commande selon le type de commande de même type par ordre de priorité. Cela peut signifier que la commande de plus haute priorité est placée de manière à ce que l'utilisateur puisse la déclencher directement et que les commandes avec une priorité inférieure sont placées dans un menu.


Les événements sont gérés par la méthode commandAction. Elle reçoit en paramètre un objet événement qui permet d'identifier la provenance de l'événement survenu (ligne 27).

Ensuite, elle détermine le composant dans lequel est survenu cet événement (ligne 28).

Si c'est bien la commande Sortie qui a été activée, alors on détruit l'application (ligne 29) puis on notifie au gestionnaire d'application que le MIDlet est détruit (ligne 30).

Conclusion

Cet exemple simple montre la facilité de développement d'un MIDlet. Bien entendu, il s'agit d'un exemple trivial, mais le développement d'un MIDlet reste bien plus simple que le développement d'une application J2EE, tout simplement parce que l'API MIDP est bien plus légère. Par contre, vous devrez changer nombre de vos habitudes de développement, tant au niveau du stockage des données que de l'interface utilisateur.

Le profil MIDP 2

MIDP 2.0 (JSR 118) est une spécification complète qui assure une compatibilité descendante avec MIDP 1.0.

Les nouvelles fonctionnalitésLes nouvelles fonctionnalités de MIDP 2.0 sont :

· Nouveau modèle de sécurité avec les MIDlets certifiées

· HTTPS 26 · Bruno Delb

Email : [email protected] : http://www.brunodelb.com

Livre blanc de J2ME

· Réseau et push étendu

· Livraison d’application

· Interface utilisateur améliorée

· Jeu

· Son

Le modèle de sécurité

MIDP 1.0 utilisait un modèle de sécurité “sandbox”, similaire aux Applets, où les MIDlets ne sont exposées qu’aux APIs “sûres”.

MIDP 2.0 spécifie comment les MIDlet Suites peuvent être cryptographiquement signées pour que leur authenticité et leur origine puissent être validés.

Un nouveau framework de sécurité introduit la notion de MIDlets “certifiées” ou “privilégiées”, selon leur signature. Il permet d’accéder aux APIs en dehors du sandbox.

HTTPS/SSL

MIDP 1.0 supportait HTTP. MIDP 2.0 ajoute HTTPS. HTTPS permet d’établir une transaction sécurisée de bout en bout. Elle peut être établie avec SSL, TLS ou WTLS. Le MIDlet peut interroger la méthode utilisées pour établir la connexion lors de l’exécution. En plus, MIDP 2.0 permet d’utiliser SSL/TLS avec des stockets, pas simplement HTTPS, ce qui garantit plus de flexibilité.

Réseau et push avancés

MIDP 1.0 intégrait HTTP. MIDP 2.0 intègre d’autres protocoles : HTTPS, le port série, les sockets, les sockets de serveur et les datagrammes.

En plus, MIDP 2.0 includ également une nouvelle capacité de push réseau. Un MIDlet peut être déclenché lorsqu’une connexion entrante arrive.

Livraison d’application

Après que la spécification de MIDP 1.0 ait été publiée, un document de pratique recommandée OTA (Over The Air) décrivant les points suivants a été publié :

· Comment les utilisateurs déclenchent un téléchargement de MIDlet par l’air à partir du navigateur résident sur le terminal

· Les détails du protocole et de la gestion de cookie concernant le téléchargement de MIDlets

· Les notifications à envoyer au serveur (meilleur effort, mais non fiable) quand le MIDlet est installé avec succès

· Comment gérer les mises à jour de MIDlet

Des améliorations ont été faites avec MIDP 2.0.

MIDP 2.0 intègre le document de pratique recommandée OTA (Over The Air) associé à MIDP 1.0. De plus, la livraison des notifications au serveur sont améliorées. Les notifications peuvent aussi être envoyées pour les installation d’application réussies comme pour les suppressions. De plus, le support du cookie a été retiré, puisque certains réseaux ou passerelles ne peuvent pas les passer au client. La réécriture de l’URL est une alternative suggérée.


· 27

Interface utilisateur améliorée

L’interface utilisateur de MIDP 2.0 assure une compatibilité descendante avec MIDP 1.0.

CustomItem

CustomItem permet la création de classes Item personnalisées et leur ajouté à des formulaires Forms. Le développeur garde le contrôle sur l’aspect.

Formatage des contrôles

Les possibilités de formatage sont très améliorées tout en conservant la portabilité. Les Items sont groupés en lignes.

Ils ont une hauteur et une largeur préférés : ils peuvent être étendus ou restreint pour tenir sur l’écran.

Des Items d’espacement peuvent être ajoutés pour contrôle l’espacement.

Graphiques

Graphics permet un support d’image transparent. C’est un drawImage amélioré qui permet de travailler sur une zone spécifique et qui permet d’effectuer des transformations.

Divers

De nouveaux modes sont ajoutés à la jauge (Gauge).

Le contrôle List supporte Command.

Les ImageItems peuvent être mis à jour.

Le jeu

L’API de jeu fournit des fonctionnalités pour le développement de jeux en 2D. Elle permet ainsi une implémentation native et de simplifier le développement de jeu.

Elle permet une conception flexible des jeux. Elle est compatible avec les classes Graphics de LCDUI.

Voici la hiérarchie des classes :


Livre blanc de J2ME

Layer

Layer est une super-classe abstraite de tous les éléments visuels : taille, emplacement, visibilité. Elle peut être ajoutée à un LayerManager.

TiledLayer

TiledLayer est un élément visuel composé d’un grid qui peut être remplit avec un ensemble de cells. Les cellules Cells sont fournies sous forme d’une simple image Image.

Des cellules animées peuvent être définies. Chaque élément de la grille (grid) peut contenir une cellule spécifique ou peut être laissée vide.

TiledLayer permet de créer de grands éléments visuels.

Les cellules sont fourni dans une image Image :

Chaque élément de la grille peut contenir une cellule spécifique.

Sprite

Sprite est un élément visuel qui peut afficher un parmi plusieurs frames. Les Frames sont fournis sous forme de simples images Image.

Des transformations sont possibles :

· TRANS_NONE

· TRANS_MIRROR

· TRANS_MIRROR_ROT_180

· TRANS_ROT_90


· TRANS_ROT_270

· TRANS_ROT_180


De plus, la détection de collision peut être assurée avec un TiledLayer ou avec un autre Sprite. Les frames sont fournis sous forme d’une simple image Image :

LayerManager

LayerManager gère une liste ordonnée d’objets Layer. Des Layers peuvent être ajoutés ou retirés n’importe quand.

L’ordonnancement de liste implique un Z-order.

LayerManager automatise le process de rendu :

· Fenêtre de visualiastion définissable

· Support du défilement

La fenêtre de visualisation est définissable.

GameCanvas

GameCanvas améliore le Canvas avec des fonctionnalités adaptées aux jeux. Tout d’abord, il intègre un support de la saisie de touche :

· Interroge directement les états de touche de jeu

· Prise en charge de pressions de touche simultanées

Ensuite, il proposé un tampon hors-écran :

· Peut être dessiné directement


· 29

· « Flushing » synchrone

Le son

Sound fournit des fonctionnalités audio évoluées :

· Génération de tonalité (obligatoire)

· Sons échantillonés comme les .wav (optionnel)

· MIDI (optionnel)

Structure comme un sous-ensemble du JSR-135 (Multimédia)

· Compatibilité ascendante complète

Les interfaces

L’interface Control est utilisé pour contrôler des fonctions de traitement de média.

L’interface Player permet au MIDlet de contrôler le rendu des données du média basé sur le temps.

L’interface PlayerListener est utilisée pour déclencher les événements asynchrones générés par des Players.

L’interface Manager est le point d’accès pour obtenir des ressources dépendantes du système comme les Players pour le traitement multimédia.

Les fonctionnalités

Les interfaces permettent au MIDlet de contrôler l’audio, selon son format.

Pour générer une tonalité : Manager.playTone(note, duration, volume);

Il est également possible d’émettre des sons et des sons MIDI :

· Manager.createPlayer(locator);

· locator est une chaîne de caractères de syntaxe URL qui décrit le contenu du média

· Player.start(), Player.stop(), …

Les prérequis

Tous les terminaux compatibles MIDP 2.0 doivent supporter la génération de tonalité.

Si un terminal supporte l’audio échantilloné, il doit supporter au moins le format wav mono PCM 8 bits, à 8 KHz.

D’autres formats échantillonnés ou MIDI peuvent être supportés en option.

La sécuritéPrenons un exemple d’application de eCommerce gérant des données confidentielles ou financières d’un client. Cette application permet de :

· S’enregistrer pour stocker les données financières.

· S’enregistrer pour être averti d’événements significatifs.

· Récupérer des informations ou est averti.

MIDP 2.0 introduit la notion d’applications. La première est celle d’application non certifiée :


Livre blanc de J2ME

· Support de sandbox comme dans MIDP 1.0

· Utilisé pour toute application ne pouvant pas être certifiée

· La fonctionnalité minimale nécessaire est spécifiée

La seconde est celle d’application certifiée :

· Les autorisations sont définies pour des APIs restreintes

· Un domaine de protection pour chaque niveau de certification

· Le terminal fait un choix pour certifier en fonction de la politique

Les autorisations

Les autorisations sont des booléens :

· Accordée (Granted)

· refusée (denied) à un utilisateur

Les conventions de nommage suivent le nommage des packages.

Extensible aux APIs développées indépendamment dans les autres JSRs ou comme Licensee Open Classes.

Chaque API définit les autorisations qui s’appliquent.

Les APIs restreintes définissent les autorisations :

Autorisation Protocolejavax.microedition.io.Connector.http httpjavax.microedition.io.Connector.https httpsjavax.microedition.io.Connector.datagram Datagrammejavax.microedition.io.Connector.datagramreceiver Serveur de datagrammejavax.microedition.io.Connector.socket Socketjavax.microedition.io.Connector.serversocket Sockets serveurjavax.microedition.io.Connector.ssl Ssljavax.microedition.io.Connector.comm Communicationsjavax.microedition.io.PushRegistry.datagram Datagrammejavax.microedition.io.PushRegistry.socket socket

Les domaines de protection

Un domaine de protection, Un MIDlet Suite

Permissions autorisées :

· Accordée si la certification est vérifiée

Permissions de l’utilisateur :

· Accordé avec approbation explicite de l’utilisateur

· L’utilisateur peut être autorisé

Blanket – Valide jusqu’à ce que l’utilisateur retire l’autorisation

Session – valide pour un seul appel

Oneshot – valide pour une seule utilisation d’une API

La politique de sécurité

Politique sur le terminal :


· 31

· Domaines de protection pour chaque source de certification

· Vérifications de sécurité hors ligne et sans bande passante

· Configuré en avance

La politique de sécurité et spécifique au terminal et au marché :

· Variations dans l’objet du terminal

· Variations dans les prérequis de sécurité dans les marchés

Les applications signées certifiées

Un mécanisme pour la certification basé sur PKI

Le descripteur d’application comprend :

· La signature du JAR du MIDlet Suite

· Les attriburs du Manifest sont sécurisés dans le JAR

· Un certificat est nécessaire pour vérifier la signature

· Les permissions sont demandées par l’application

Signature JAR :

· PKCS #1 Version 2.0 en utilisant une clé privée

· La clé publique correspondante est dans le certificat

· La clé publique racine (certificat) est sur le terminal

Les applications signées OTA (Over The Air)

Installation :

· Vérifier l’intégrité de JAR en utilisant la signature

· Vérifier les certificats à un domaine de protection

· Vérifier que les permissions nécessaires sont valides

Appel :

· Certaines permissions peuvent être accordées par domaine de protection via un certificat racine

· Certaines permissions peuvent être accordées par l’utilisateur lors des demandes de permissions

Le réseauNouveaux gestionnaires de réseau et d’entrées-sorties de terminal

Sécuriser le réseau

Support de push d’application

Nouveaux gestionnaires de protocole

Un nouveau gestionnaire de protocoles succède au GCF (Generic Connection Framework) du CLDC. Il permet une implémentation optionnelle avec une consommation minimale de la mémoire.

Les nouvelles fonctions d’entrées-sorties sont protégées comme les opérations privilégiées


Livre blanc de J2ME

L’API réseau

SocketConnection – Socket TCP/IP

ServerSocketConnection – Serveur de socket TCP/IP

UDPDatagramConnection – Datagramme UDP

Fonctionnalités de l’API :

· Les options de socket contrôlent les atilles et les délais du tampon (exemple : délai lors de la fermeture)

· Fournit un accès aux informations d’adresse IP et de port locaux et distants

· Ajout de l’affectation d’adresse de port dynamique

Les APIs sont spécifiées (tous les terminaux ne doivent pas les implémenter)

L’API réseau sécuriséeProtocole DescriptionHTTPSConnection Sécurise HTTP sur SSL 3.1 ou TLS 1.0 ou WTLS SecureConnection Sécurise la connexion socket en utilisant SSL ou TLS SecurityInfo Accès au certificat de serveur

Vérification de l’algorithme de cryptageCertificate Accès à l’identité et aux paramètres du serveurCertificateException

L’API de communication série

comm:<port>[<paramètres>] Paramètre Valeur par défautbaudrate Dépendant de la plate-formebitsperchar 8 Stopbits 1 Parity none (aucun)Blocking on (actif)Autocts on (actif)Autorts on (actif)

Propriété du système pour liste les ports disponibles :

· Conventions de nommage pour distinguer les ports infra-rouge des ports série (exemple : IR0, COM1, ...)

Appel de MIDlet

L’application enregistrement les connexions entrantes attendues :

· Fichier descripteur d’application ou

· PushRegistryto register orunregister

L’enregistrement comprend :

· La connexion entrante : datagram://:12345

· Le nom du MIDlet : example.Demo

· Le filtre de la source : 129.148.70.142

Le support de protocoles spécifiques de la part du logiciel de gestion d’application est spécifique à l’implémentation.

La fonction d’alarme permet un démarrage à une heure précise.


· 33

Le MIDlet appelle une nouvelle connexion

Lors de la notification, le MIDlet est lancé pour gérer l’opération d’entrée-sortie entrante :

· La méthode ThelistConnections() est disponible pour que le MIDlet vérifie les connexion déjà enregistrées dans le MIDlet suite ou

· Les connexions qui ont une connexion entrante en attente

Le MIDlet gère toutes les entrées-sorties comme normales :

· Par exemple, open(), read(), close(), ...

· Après que le MIDlet soit terminé, le AMS reprend l’écoute

L’application peut être rejetée à l’installation

· Si une qualification appropriée ne comprend pas les permissions de push

· Si la connexion est déjà allouée à une autre application installée


Livre blanc de J2ME

Le profil PDAP

IntroductionPDAP (Personal Digital Assistant Profil) est un nouveau profil CLDC qui cible les PDA (Personal Digital Assistants) :

· Fonctionne dans un environnement de puissance limitée

· Fournit un accès aux fonctionnalités de PDA communes

· Supporte des méthodes d’entrée supplémentaires (comme le stylet)

· Supporte la connectivité aux autres terminaux

PDAP comprend des APIs spécifiques à PDAP :

· Interface utilisateur AWT

· APIs PIM (Personal Information Management)

· Connexions port série et système de fichier

· PDAlet

PDAP contient une API complet et compatible MIDP.

Le positionnement de PDAP

Quels sont les rapports entre PDAP et MIDP/CLDC ? Les PDAs partagent des attributs avec les terminaux MIDP. Les PDAs nécessitent des fonctionnalités plus riches qui correspondent aux capacités de leur terminal.

Quels sont les rapports entre PDAP et Personal Profile / CDC ? La plupart des PDAs ne sont pas appropriés. MIDP et CLDC apportent des avantages significatifs aux PDAs.

PDAP répond aux besoins de fonctionnalités entre Personal Profile et MIDP. Il établit une continuité entre les profils de la plate-forme J2ME.

La raison d’être de PDAP

Ce dont ont besoin les développeurs :

· Accéder aux données du terminal

· Accéder au port série

· Tirer parti de l’interface utilisateur du terminal


· 35

PDAP vise également une occupation mémoire de 900 Ko ainsi qu’un aspect proche des applications natives du terminal.

Les PDAletsLe cycle de vie des applications PDAP, que l’on appelle PDAlets, est contrôlé par la classe PDAlet. La classe PDAlet fait suite à la classe MIDlet.

De nouveaux attributs de fichier JAD et un nouveau Manifest sont introduits :

· PDAlet-<n> pour spécifier les PDAlets

· “PDAP_1.0” pour la balise MicroEdition-Profile

PDAP peut spécifier des MIDlets et des PDAlets dans le même Suite.

L’interface utilisateur

AWT

Les avantages de AWT sont :

· Préserve l’aspect natif

· Fournit une API extensible

· Transfert les compétences du développeur

· S’adapte rapidement aux outils de développement existants

AWT supporte des widgets communs de l’interface utilisateur des PDAs :

· Support de containers extensibles

· Gestion complet de la présentation des composants

· Capacité graphique dans les composants

· Evénement de multicasting

· Les implémentations peuvent supporter un seul Frame plein écran à chaque fois.

Interaction entre AWT et LCDUI

Interaction opérationnelle, pas dans les APIs.

L’interaction a lieu au niveau des Frames AWT et du Displayable LCDUI.

Le mélange de composants entre les deux modèles n’est pas autorisé.

Personal Information Management (PIM)Les APIs fournissent un accès aux bases de données natives :

· Adresses

· Liste « To Do »

· Agenda

L’API est optimisée pour les environnement informatiques avec fortes contraintes. Elle est implémentée dans le nouveau package javax.microedition.pim.


Livre blanc de J2ME

Exemple : Ajout d’un contact :

ContactListcontacts = null;

contacts = ContactList.open(ContactList.READ_WRITE);

Contact contact = new Contact();

contact.setString(Contact.NAME_FAMILY, "Stevenson");

contact.setString(Contact.NAME_GIVEN, "John");

contact.setString(Contact.TEL, Contact.TYPE_HOME, "613-123-4567");

contacts.add(contact);

La connectivité

Le port série

La classe javax.microedition.io.CommConnection ouvre une connexion logique par le port série pour les échanges d’octets. Il dispose d’un mécanisme de découverte de port.

Le système de fichier

La classe javax.microedition.io.FileConnection ouvre une connexion sur un simple fichier ou sur un répertoire. Il supporte l’accès aux cartes mémoire comme les répertoires hors du répertoire racine.

Exemple : Création d’un fichier

FileConnection fconn;

fconn= (FileConnection) Connector.open("file:///CFCard/newfile.txt");

if (!fconn.exists())

fconn.create(); // create the file if not there

fconn.close();

La sécuritéPDAP dispose d’un modèle de sécurité basique pour les fonctionnalités privilégiées :

· Lecture / écriture aux bases de données PIM

· Accès aux ports séries

· Lecture / écriture aux systèmes de fichier

Un mécanisme d’autorisation de l’utilisateur est nécessaire mais l’implémentation et l’application peuvent changer.

Le modèle de sécurité dans MIDP 2.0 est plus avancé.


· 37

La migration d’application de J2SE vers J2ME (MIDP)

Pourquoi migrer une application de J2SE vers J2ME ?Le profil MIDP de J2ME n’est pas un sous-ensemble complet de J2SE. Il utilise des APIs différentes et une logique différente.

Le portage d’application est nécessaire pour la première fois pour faire passer une application de la plate-forme J2SE vers J2ME CLDC (MIDP).

Les principales différences entre J2SE et J2ME sont les suivantes :

· Cycle de vie de l’application

· Interface utilisateur

· Réseau

· Entrées-sorties et stockage de données

Le cycle de vie

Le cycle de vie d’une application J2SE

Le cycle de vie d’une application J2SE commence par la méthode Main() :

· Le point d’entrée d’une application Java

· Contrôle le flux du programme

· Alloue les ressources

· Fait tourner d’autres méthodes

Toute application J2SE doit contenir une méthode main :

public static void main(String[] args)

Voici un exemple d’application Hello World :

class HelloWorldApp { public static void

main(String[] args) { System.out.println("Hello World!");

}

}


Livre blanc de J2ME

Le cycle de vie d’une application J2ME

La méthode StartApp() acquiert les ressources de l’application et commence l’activité.

La méthode PauseApp() suspend l’activité et attend une réponse.

La méthode DestroyApp() libère les ressources de l’application et termine l’activité.

Voici une application de type Hello World :

import javax.microedition.midlet.*; import javax.microedition.lcdui.*;

public class HelloWorld extends MIDlet { private Display display;

public HelloWorld() {

display = Display.

getDisplay(this);

}

public void startApp(){ TextBox t = new TextBox("

Hello World”, "Hello World!", 256, 0); display.setCurrent(t);

}

public void pauseApp(){} public void destroyApp(boolean

unconditional){}

}

Migration des fonctionnalités

L’interface utilisateur

L’interface utilisateur de MIDP est différente de celle de J2SE.

L’interface utilisateur J2SE repose sur AWT et JFC / l’API Swing.

L’interface utilisateur de MIDP repose sur javax.microedition.lcdui :

· High Level:Alert, Form, Item, List, TextBox, Ticker

· Low Level:Canvas, Font, Graphics, Image

Le réseau, les entrées-sorties et le stockage de données

Les bibliothèques de réseau, d’entrées-sorties et de stockage de données sont trop lourdes pour les terminaux MIDP. En effet, on compte plus de 100 classes séparées et la taille totale dépasse 200 Ko.

De plus, J2SE suppose que TCP/IP et le système de gestion de fichier sont disponibles, ce qui n’est pas le cas pour les terminaux MIDP.

J2ME utilise un sous-ensemble du package java.io pour les entrées-sorties à travers les flux de données. J2ME fournit un package spécifique java.microedition.io pour le réseau. Il ne supporte que HTTP. Enfin, J2ME fournit un package spécifique, javax.microedition.rms, pour le stockage de données. Celui-ci repose sur des tableaux d’octets stockés dans des enregistrements.


· 39

Préparation du code pour la migrationSéparez vos classes. Vous remarquerez que le code concernant l’interface utilisateur, le réseau, les entrées-sorties et le stockage de données n’est pas migré facilement.

Voici quelques bonnes pratiques :

· Ne pas retourner d’un bloc try.

· Lors de concaténation de texte, utiliser StringBuffer au lieu de String (si possible).

· Instantiez aussi peu d’objets que possible. En tout cas, essayez de faire en sorte qu’ils soient petit.

· Utilisez les types de base tant que possible.

· Utilisez les tableaux plutôt que les vecteurs.

Vous aurez également besoin de savoir ce qui manque :

· La virgule flottante

· La finalisation des objets

· Le support de JNI ou la réflexion

· Les groupes de Thread

· Les chargeurs de classe définis par l’application

· Le système de fichier

Commutation du codeEmpruntez le concept #ifdef du monde du pré-processeur C.

· Créez des blocs de code qui effectue des tâches spécifiques pour MIDP et pour J2SE.

· Isolez les blocs de code avec les ordres #ifdef et #endif qui sont déclenchés par un identifiant unique.

· Tout le code se trouvant entre #ifdef et #endif seront ignorés.

Vous devrez « précompiler » le code Java pour séparer les fonctionnalités imbriquées.

Exemple :

void storeData(StringBuffer sb) {

#ifdef MIDP_CODE

rms_Storage(sb);

#else

db_Storage(sb);

#endif

}

Pour cette précompilation, utilisez un préprocesseur C. Lancez le préprocesseur C sur le code Java en utilisant les bonnes options :

cpp –DMIDP_CODE HelloWorld.java

Des préprocesseurs Java peuvent être trouvés sur le site de JAD Central (section Utilities) : http://www.jadcentral.com/codecentral.


Livre blanc de J2ME

Test du codeLes différences importantes entre chaque terminal nécessite que vous testiez le code sur chacun d’eux.

Espace du tas 128 Ko 640 Ko 256 Ko 128 KoEspace du programme 16 Mo 2 Mo 640 Ko 2 MoTaille de l’écran 101 x 80 320 x 240 110 x 100 160 x 160

Siemens SL45i

Accompli 008

Motorola i85s

Palm Vx

Lors du test, vous devrez donc veillez à ces différents critères :

· Espace du tas disponible

· Espace de programme disponible

· Formatage de l’écran

· Bugs de l’implémentation MIDP

· Performance : de l’application et du réseau


· 41

iMode

Le Japon connaît trois systèmes concurrents et propriétaires pour 46 millions d’abonnés, qui représentent par ailleurs 80 % des utilisateurs de l’Internet mobile dans le monde. L’opérateur NTT DoCoMo possède 65 % du marché Japonais. Sur un chiffre d’affaire de 4 milliards d’euros pour les transmissions de données, cet opérateur a reversé 340 millions d’euros aux fournisseurs de contenus.

Le succès d’iMode est du à plusieurs facteurs :

· système de reversement d’une partie des revenus aux fournisseurs de contenu, ce qui a eu pour effet une offre très variée

· lancement initial avec des contenus simples et des téléphones ergonomiques en couleur

· montée en complexité progressive des services et augmentation de la diversité

· langage à balises utilisé (CHTML) dérivé de HTML, ce qui a facilité la production de contenu

· avance technologique des fabricants de téléphones japonais

· utilisation d’un réseau orienté paquets, PDC-P, ce qui permet une facturation au volume et met à disposition une connexion permanente

Cependant, le Japon a un certain nombre de spécificités :

· le goût du gadget électronique

· un niveau de vie élevé

· la bonne adaptation de l’écriture japonaise aux terminaux mobiles

· le temps de transport important

· une population fortement urbaine

Les points faibles de i-Mode / CHTML sont les suivants :

· Manque de sécurité

· Interface utilisateur pauvre

· Nécessite une connexion tout au long de l’utilisation de CHTML

Or les applications demandent aujourd’hui :

· plus de sécurité, en particulier pour le mCommerce (mobile Commerce)


· 43

· plus d’interactivité, en particulier pour les jeux vidéos

· plus de sophistication, pour des applications du type client-serveur

Il se trouve que J2ME répond à ces besoins :

· Indépendance vis-à-vis de la plate-forme

· Modèle de sécurité intégré de base

· Déploiement d’application dynamique

· Interface utilisateur évoluée

· Fonctionnalités réseau évoluées

NTT DoCoMo a donc décidé d’intégrer J2ME sur les téléphones mobiles. Pour cela, il a implémenté une machine virtuelle Java (KVM) et la configuration CLDC. Malheureusement, il manquait toujours une brique pour que le tout puisse fonctionner : le profil. NTT DoCoMo a ainsi décidé de créer Java for i-Mode, aussi appelé DoJa. On peut donc considérer DoJa comme un profil. Le fait est que J2ME a poursuivi son évolution et le profil MIDP est apparu plus tard. Aujourd’hui, nous nous retrouvons donc avec deux « profils », DoJa et MIDP. Les deux devraient fusionner dans l’avenir : ils possèdent les mêmes bases, respectent la même philosophie et ont des bibliothèques de développement proches.

Le modèle économique de NTT DoCoMo est le suivant :

· Facturation de l’accès au réseau : 2,8 € / mois

· Facturation au volume (0,025 € par Ko)

· Facturation mensuelle pour certains services (de 0,95 € à 2,8 €), dont 91 % sont reversés au fournisseur du service. Ce modèle génère un revenu mensuel complémentaire à la voix d’environ 16 € par abonné pour un revenu voix de 66 €.

Il est intéressant de noter les services iMode les plus utilisés :

Service Proportion

Messagerie 30 %

Services ludiques (jeux, logos, sonneries, …) 50 %

Informations (météo, actualités, traffic routier, …) 15 %

Banque 3 %

Réservations 2 %

Comme nous l’avons indiqué plus haut, il existe d’autres technologies concurrentes à iMode au Japon. Les deux principaux concurrents de NTT DoCoMo sont AU par KDDI avec son offre EZWeb (AU est le fabricant de téléphone, KDDI l’opérateur) et J-Phone avec J-Sky.

Aujourd’hui, iMode détient les deux tiers du marché Japonais.

iMode utilise le langage à balise cHTML, qui est un dérivé de HTML, et ce bien que NTT DoCoMo ait participé aux travaux sur le WAP. Les raisons de ce choix sont la lenteur des process de prise de décision de ce type de groupe de travail d’une part, le fait que cHTML s’appuie sur les développeurs HTML déjà formés d’autre part.

Le service EZWeb de KDDI utilise le langage à balises HDML, proche de WML à quelques différences de syntaxe près. Il possède quelques particularités


Livre blanc de J2ME

également : support de la couleur et possibilité de pusher des informations du serveur vers le terminal mobile.

Le service J-Sky de J-Phone repose sur le langage à balises MML (Mobile Markup Language), proche du cHTML de NTT DoCoMo.

Des terminaux iMode

Terminal Fabricant DefaultFont SIZE_SMALL SIZE_MIDEUM SIZE_LARGE BOLD ITALIC Taille de l’écran

F503i Fujitsu Ltd. 12x12 12x12 12x12 12x12 X X 120x130

P503iMatsushita Communication Industrial Co., Ltd.

12x12 10x10 12x12 12x12 X X120x130

N503i NEC Corp. 12x12 12x12 12x12 12x12 X X 120x130SO503 Sony Corp. 14x12 12x10 14x12 14x12 X X 120x120D503i Mitsubishi Electric Corp. 16x16 12x12 16x16 16x16 X X 132x126

L'API iMode

Le réseau

Une application Java for i-mode peut effectuer des requêtes HTTP et HTTPS (URL de type "http" et "https"). Cela permet d'échanger des données avec un serveur Web.

Java for i-Mode repose sur la notion de GCF (Generic Connection Framework), incluse dans la configuration CLDC de J2ME.

Le stockage de données persistentes

Le scratchPad (URL de type "scratchpad") permet de stocker des données sur le terminal. C'est l'équivalent du RMS de MIDP.

Par ailleurs, l'application peut lire les fichiers de données contenus dans le fichier JAR : l'accès se fait comme tout accès réseau mais en utilisant une URL de type "resource:".

L'interface utilisateur

De manière similaire à MIDP, une application Java for i-mode propose deux manières de créer l'interface utilisateur. L'API de bas niveau de l'interface utilisateur permet de créer l'interface utilisateur en dessinant directement dans le contexte graphique tandis que l'API de haut niveau permet de créer une interface utilisateur à partir de composants comme des boutons ou des listes déroulantes.

Tant qu'à l'API de haut niveau de gestion des événements de l'interface utilisateur, elle propose un modèle événementiel similaire au modèle de délégation du JDK 1.1.


· 45

Quelles sont les différences entre Java for i-Mode et MIDP ?

Bien que NTT DoCoMo ait implémenté J2ME sur ses téléphones mobiles et bien que cette implémentation repose sur la configuration CLDC, elle n'est absolument pas compatible avec MIDP. Autrement dit, un MIDlet, qui correspond à une application développée pour MIDP, ne peut pas être exécutée sur un téléphone DoCoMo.

Afin de vous faire une idée plus précise de cette implémentation, brossons un aperçu des principales différences entre i-Mode et MIDP.

La première différence porte sur l'API elle-même. MIDP repose sur les classes suivantes :

· javax.microedition.midlet

· javax.microedition.lcdui

· javax.microedition.rms

· javax.microedition.io

Tandis que i-Mode repose sur celles-ci :

· com.nttdocomo.io

· com.nttdocomo.util

· com.nttdocomo.ui

· com.nttdocomo.net

· javax.microedition.io

La seconde différence est qu'une application DoCoMo, que l'on appelle une iAppli, étend com.nttdocomo.ui.IApplication tandis qu'une application MIDP, que l'on appelle un MIDlet, étend javax.microedition.midlet. De plus, une iAppli implémente une méthode obligatoire, start(), et deux méthodes optionnelles, resume() et terminate(). De son côté, un MIDlet implémente trois méthodes obligatoires, startApp(), pauseApp() et destroyApp().

La troisième différence concerne le mécanisme d'OTA (Over The Air). Tandis que MIDP repose sur des fichiers .jad, une iAppli repose sur des fichiers .jam contenant des champs. Voici un exemple de fichier jam :

AppNamec=HelloWorld

AppVer=1.0

PackageURL=HelloWorld.jar

AppSize=1000

KvmVer=1.0

SPsize=0

AppClass=HelloWorld

AppParam=arg

LastModified=Wed, 01 June 2002 12:00:00

La quatrième et dernière grande différence concerne les limitations de la taille des fichiers .jar. Elle est de 10 Ko pour les iAppli tandis qu'elle est de près de 50 Ko pour les MIDlets.


Livre blanc de J2ME

Mais à quoi ressemble une i-Appli ?Pour illustrer ce que nous venons de voir, voici une même application développée avec MIDP (on parle de MIDlet) et avec DoJa (on parle de iAppli).

MIDletimport javax.microedition.midlet.*;

import javax.microedition.lcdui.*;

public class HelloMidlet extends MIDlet implements CommandListener {

private Display midletDisplay;

private Command doneCommand;

public HelloMidlet() {

midletDisplay = Display.getDisplay(this);

doneCommand = new Command("OK", Command.SCREEN, 1);

}

public void startApp() {

TextBox textBox = new TextBox("Midlet", "Hello World", 256, 0);

textBox.addCommand(doneCommand);

textBox.setCommandListener( (CommandListener) this);

midletDisplay.setCurrent(textBox);

}

public void pauseApp() {

}

public void destroyApp(boolean unconditional) {

}

public void commandAction(Command command, Displayable screen) {

if (command == doneCommand) {

destroyApp(false);

notifyDestroyed();

}

}

}

iAppliimport com.nttdocomo.ui.*;

import com.nttdocomo.util.*;

public class iAppliSample extends IApplication {

Panel panel;

TextBox textBox;


· 47

public iAppliSample() {

panel new Panel();

textBox = new TextBox ("Hello world", 10, 5, TextBox.DISPLAY_ANY);

}

public void start() {

panel.add (textBox);

Display.setCurrent (panel);

}

}


Livre blanc de J2ME

Le processeur Jazelle

De nombreux fabricants (Jile Systems, ARM, Aurora VLSI, inSilicon, Nazomi Communications, Parthus, Zucotto Wireless) ont choisi la licence Java de Sun pour implémenter leurs processeurs mobiles. Ces processeurs implémentent la machine virtuelle J2ME, qui traduit les instructions Java en commandes que le circuit peut directement comprendre. L'extension Jazelle de ARM exécute les bytecodes J2ME les plus souvent utilisés directement au niveau matériel. L'interprétation de Java au niveau hard permet de réduire les accès mémoire et la commutation, ce qui a effet de faire tourner plus vite les applications.

Les trois étatsLes processeurs ARM (Advance RISC Machine) supportent trois états :

Etat DescriptionLe jeu d’instruction ARM Les instructions sont sur 32 bits.Le jeu d’instruction Thumb Les instructions sont sur 16 bits, ce qui permet de

compresser à 35-40 % pour une petite réduction de performance.

Le nouveau jeu d’instruction Java Byte Code

Il fonctionne comme une machine virtuelle Java : les instructions (byte code) Java sont directement exécuté au niveau matériel comme du code natif.

Pour quel état opter ? Le premier état pour favoriser les performances, le second pour la consommation de mémoire et le troisième pour l’exécution de code Java.

Changement d’étatDe plus, il est possible de passer d’un état à l’autre à tout instant : une simple instruction ARM « BXJ Rm » (BXJ pour « Branch to Java ») permet de basculer en état Java pour exécuter du Java Byte Code.

BXJ Rm Bits 31 à 28 Bits 27 à 4 Bits 3 à 0Condition Rm

Si Condition (bits 28 à 31) est vérifié, alors faire ceci :

· J = 1

· PC = Rm

· Activer l’état Java

· Commencer l’exécution du Byte Code à l’adresse PC

J est un nouveau bit de CPSR qui enregistre l’état du processeur :31..27 24 7 6 5 4..0


· 49

Drapeaux J I F T Mode

Voici comment cela fonctionne :

· Si J = 0, alors le processeur est en état ARM ou Thumb (en fonction du bit T).

· Si J = 1 et T = 0, alors le processeur est en état Java.

Lors du déclenchement d’une interruption, CPSR est automatiquement sauvegardé puis restauré, ce qui garantit la compatibilité avec le modèle d’interruption ARM actuel et donc avec les systèmes d’exploitation existants.

Utilisation de registresLe processeur réutilise des registres ARM pour des tâches particulières :

Registre DescriptionR0-R3 Utilisé pour le cache des 4 éléments du haut de la pile d’expression JavaR4 Variable locale 0 (pointeur « this »)R5 Pointeur vers la table des gestionnaires SWR6 Pointeur vers la pile JavaR7 Pointeur vers les variables JavaR8 Pointeur vers le pool de constantes JavaR9-R11 Réservé pour la JVMR12, R14 Utilisateur scratch / adresse de retour JavaR13 Pointeur vers la pile machineR15 PC Java

Les avantages sont :

· réduction de la taille de la logique supplémentaire pour implémenter la machine virtuelle

· conservation des états des extensions Jazelle dans les registres ARM, ce qui garantit la compatibilité avec les gestionnaires d’interruption et les systèmes d‘exploitation actuels

Equilibre matériel / logicielLes Java Byte Codes sont répartis en trois classes :

Classe Description Types d’instructionsDirectement exécuté

140 instructions au total sont directement exécutées au niveau matériel

· Chargement de constante· Chargement / stockage

de variables· Chargement / stockage

de tableau· Opérations de données

sur des entiers· Branchements· Chargement rapide de

pool de constante· Opérations rapides

statiques / champsEmulé 94 instructions sont émulées par de petites

séquences d’instructions ARM, ce qui permet de réduire le coût (puisque moins complexe) et la consommation de batterie de l’extension Java.

Par ailleurs, ces instructions sont re-

· Virgule flottante· Division entière· Commutation· Appel· Retour


Livre blanc de J2ME

démarrable, autrement dit elles sont interrompables ce qui permet d’éviter de dégrader les performances d’interruption.Enfin, la boucle d’interprétation VMZ de la machine virtuelle permet de gérer les Byte Codes non pris en charge par le matériel.

· Nouveau· Champ / statique non

résolu· ldc non résolu

Non défini Ce sont les Byte Codes ni exécutés directement ni émulés.Quand le système rencontre un Byte Code non défini, le processeur quitte l’état Java et déclenche une exception, codée avec le jeu d’instructions ARM. Cependant, ce système permettrait d’implémenter de nouvelles extensions Java Byte Code à l’avenir.

PerformancesUne attention toute particulière a été portée sur le temps de réponse au déclenchement d’une interruption et à la compatibilité avec les applications existantes : tous les Java Byte Codes sont redémarrables. Ainsi, les performances en terme de temps réel ne sont pas dégradées.

Une remarque concernant le temps d’exécution des Byte Codes. Ces derniers sont lus en deux cycles au lieu d’un cycle pour les états ARM et Thumb, soit un temps double :

· Un cycle pour décoder le Byte Code

· Un cycle pour gérer une opération de lecture de registrePerformance d’exécution CM / MHz

Coût en mémoire Coût de l’implémentation au niveau matériel

Emulation logicielle (JDK de Sun, ARM9)

0,67 16 Ko

Emulation logicielle (JDK de ARM, ARM9)

1,7 16 Ko

JIT 6,2 (hors surcharge de compilation)

100 Ko

Co-processeur (exemple : Jedi Tech JSTAR)

2,9 25 K gates

Processeur dédié 3 20 à 30 K gates

ARM avec extension 5,5 8 Ko 12 K gates

Notes :

· CM / MHz est une unité de benchmark signifiant « CaffeineMarks par MHz ». Sa valeur n’est intéressante que pour être comparée, pas en absolu. Cette valeur a été inventée par Pendragon Software. Les CaffeineMarks testent donc des fonctionnalités de la plate-forme Java mais exclue les opérations en virgule flottante, le garbage collector et les threads multiples. Autrement dit, cette unité de mesure est bien adaptée aux environnements embarqués, mais pas aux applications traditionnelles.

· Un « gate » est un circuit de base qui produit une sortie seulement quand certaines conditions en entrée sont satisfaites. Son nombre donne une indication sur la complexité du circuit et donc sur son coût d’implémentation.


· 51

Ce tableau montre plusieurs points.

· Tout d’abord que les performances ARM avec extension (5,5) sont :

· d’environ 8 fois supérieure à celle d’une émulation logicielle (0,67). Les émulations logicielles sont donc particulièrement mal adaptées aux systèmes disposant de peu de puissance et de peu de mémoire.

· d’environ 90 % supérieures à celle d’un co-processeur (2,9) ou d’un processeur dédié (3).

Ensuite que le JIT est très consommateur en mémoire : la mémoire consommée est d’environ 100 Ko en taille, le code compilé occupe entre 6 et 8 fois plus de mémoire et le processeur est particulièrement utilisé lors de la compilation.

Enfin que le coût de l’implémentation de l’extension au niveau matériel (12 K gates) est particulièrement faible par rapport au cas du processeur (20 à 30 K gates).


Livre blanc de J2ME

Optimisation de la machine virtuelle

Un argument souvent opposé à Java est sa performance. La réponse à cette critique peut prendre deux formes : l'optimisation du matériel en proposant un processeur Java natif et l'optimisation du logiciel en proposant une machine virtuelle adaptée.

Optimisation matérielleEn 1996, Sun annonce sa future ligne de processeurs Java. Le premier sera le picoJava. A l'origine, il prévoyait un trio picoJava, microJava et UltraJava. Ce processeur Java devait pouvoir faire tourner des fichiers Java en natif.

Un programme Java consiste en fichiers .class. Un fichier .class correspond à une succession de codes d'instruction représentant des opérations simples, appelés bytecodes par Sun. Ces bytecodes ressemblent aux instructions du langage machine traditionnel. En fait, c'est exactement la même chose avec un processeur Java puisque dans ce cas ces bytecodes sont directement compris par le processeur.

Après avoir voulu fabriquer et vendre la licence de ses processeurs Java, Sun s'est ensuite focalisé sur la vente de ses licences.

Cependant, Sun ne rencontra pas le succès attendu.

La première raison est probablement que personne n'a voulu faire miser son entreprise sur un produit basé sur un processeur Java de première génération.

La seconde raison est que ces processeurs Java ne pouvaient fournir un meilleur ratio prix / performance que les offres concurrentes non Java déjà existantes.

La troisième et non la moindre est une mauvaise adaptation entre le processeur et les besoins du marché. En effet, ces processeurs Java étaient coûteux et consommaient beaucoup. Ainsi, le MicroJava 701 consommait 3 watts pour fonctionner tandis que le StrongArm consommait 1/3 de watt.

Ceci explique que ces processeurs Java n'ont pas rencontré le succès attendu. Le choix s'est plutôt porté sur des processeurs plus génériques, ne nécessitant pas par définition de personnalisation coûteuse.


· 53

Optimisation logicielle

Les machines virtuelles pour les terminaux mobiles

Optimisation du temps de compilation et du temps de chargement

Les compilateurs traditionnels se focalisent sur l'optimisation de la vitesse d'exécution et sur la taille du code. Les compilateurs Java pour les terminaux mobiles se focalisent pour leur part sur l'optimisation de la consommation de mémoire. Or l'optimisation de la vitesse conduit souvent à consommer un peu plus de mémoire, d'où la difficulté d'optimisation d'une machine virtuelle pour un terminal mobile.

Analyse du programmeIl s'agit ici d'apprend à analyser le programme. Pour cela, il existe plusieurs types d'algorithmes.

Le premier consiste à éliminer le code utilisant les constantes, ce qui n'a que peu d'effet sur la consommation de mémoire, ainsi que le code qui n'est jamais exécuté, ce qui n'a aucun effet si le bytecode est placé en ROM.

Le second algorithme consiste à simplifier le code généré. Notamment, les portions de code identiques sont déplacées pour être exécutées plusieurs fois.

Le troisième algorithme consiste dérouler les boucles, c'est-à-dire à éviter les tests suivis de séquences de saut. Cet algorithme n'affecte pas la consommation de mémoire si le bytecode est placé en ROM.

Enfin le quatrième consiste à éliminer les appels récursifs. Cependant, cette structure est rarement utilisée par les développeurs d'applications classiques.

Spécialisation du programmeIl s'agit ici d'exploiter les informations dont dispose le compilateur sur le système cible. Par exemple si l'on sait que le chagement de classe dynamique n'existe pas sur le système cible, alors on peut savoir quelle méthode spécifique appeler quand un appel à une méthode virtuelle est fait et quel champ spécifique utiliser quand le champ d'une classe est référencé. Ainsi, l'analyse du programme permet de retirer des champs et des classes non référencés et qui ne ne seront jamais utilisés dans le programme. De plus, il peut également déplacer les variables locales au niveau global pour le cas des méthodes non-réentrantes, ce qui aura pour effet de réduire la taille des instances de classe.

Exécution du code

Le principe de l'exécution du code Java consiste à générer du code intermédiaire, appelé bytecode, qui sera ensuite exécuté par la machine virtuelle.

La solution la plus simple est d'utiliser un interpréteur de bytecode. Le principal avantage est sa simplicité et le peu de consommation de mémoire. Le principal inconvénient est la lenteur d'exécution.

Une solution plus complexe est d'utiliser un compilateur JIT (Just In Time). Il compile le code et l'exécute chaque fois qu'il rencontre un nouveau code. Autrement dit, plus un code sera rencontré, plus le JIT sera adapté. La principale différence avec un compilateur traditionnel est que le compilateur JIT ne compile que le code des isntructions actuellement exécutées. Cela


Livre blanc de J2ME

signifie par contre que ce code compilé doit être stocké quelque part. L'avantage de cette solution est donc une exécution plus rapide mais son inconvénient est l'augmentation de la mémoire consommée.

La troisième solution repose sur une approche hybride. On utilise un interpréteur pour exécuter une partie du code et un compilateur pour le reste du code. Ceci signifie qu'une partie du code sera exécutée plus lentement mais sans utiliser du supplément de mémoire du au code compilé. Le reste du code sera créé par le compilateur et sera ainsi exécuté plus rapidement.

Garbage collection

Le Garbage collection est l'identification et la récupération de mémoire plus utilisée par le programme. Cette opération peut être faite selon différentes stratégies.

La stratégie du mark sweep (marquage de champ) comprend deux phases. La première consiste à marquer tous les objets. La seconde consiste à découper en "champs" le tas (heap) et à établir une liste des emplacements de zones de mémoire inutilisés. Pour allouer un nouvel objet, on recherche dans cette liste des portions de mémoire libre. L'inconvénient est que la mémoire sera fragmentée et que la recherche dans cette liste d'espaces libres prend du temps.

La stratégie du comptage de référence consiste à ajouter à chaque objet un compteur qui contient le nombre de références à cet objet. Lors d'une nouvelle référence à un objet, le compteur de référence est incrémenté. Inversement, quand une référence à un objet est retirée, ce compteur est décrémenté. Et quand ce compteur atteint la valeur 0, cela signifie que la mémoire utilisée par cet objet peut être libérée. Il existe une situation particulière : ce sont les références cycliques dans lequelles il n'existe plus aucune référence depuis un objet "vivant". Dans ce cas, la place occupée par ces objets pourra aussi être libérée. L'inconvénient est que si l'on a beaucoup de petits objets, alors l'espace mémoire utilisé pour stocker ce compteur occupe beaucoup de place. Si par contre on utilise beaucoup de gros objets, la place occupée par ce compteur sera minime. L'avantage de cette solution est que son exécution est rapide. Cependant, le cas des références cyliques est un peu plus consommateur en temps machine.

La stratégie de copie consiste à copier les objets pour défragmenter la mémoire. Plus précisément, la mémoire est découpée en deux zones. Lors de l'allocation d'un nouvel objet, celui-ci est placé dans la première zone de mémoire. Quand il n'y a plus assez de place disponible, tous les objets de cette première zone sont recopiés dans la seconde et les références à ces objets sont modifiées pour bien pointer vers la seconde zone puis on libère totalement la première zone. Cette opération permet ainsi de compacter la mémoire. On applique alors la même méthode non plus à la première zone mais à la deuxième. L'inconvénient de cette méthode est que l'on n'utilise plus que la moitié de la mémoire.

La machine virtuelle KVM

Romisation et prévérification

Avec KVM est fourni un SDK. Ce SDK comprend le prévérificateur, qui effectue une vérification du bytecode au moment de la compilation, et le romisateur, qui effectue un lieu du bytecode dans la KVM éliminant ainsi le besoin de chargement du bytecode lors de l'exécution.

Avec J2SE, la machine virtuelle effectue des vérifications sur le bytecode lors du chargement d'une classe en mémoire (analyse de l'utilisateur de la pile, test d'intégrité des types, ...). Avec J2ME, une partie de ce travail est sur le poste de développement, allégeant ainsi la tâche du terminal cible.


· 55

La romisation (romizing) consiste à traduire un fichier class en fichier source C pouvant être lié (link) avec la KVM (le bytecode n'est pas traduit en code natif, seulement en source C). L'avantage est de pouvoir ainsi conserver en ROM la KVM et les classes ainsi romisées, ce qui permet d'éviter à avoir à charger le fichier de classe lors de l'exécution, de réduire la quantité de mémoire consommée et le temps de démarrage.

Le système d'exécution

La KVM utilise un interpréteur pour l'exécution du bytecode Java. Afin d'accélérer l'exécution, certains bytecodes sont remplacés par des bytecodes KVM personnalisés lors de leur première exécution. Ces bytecodes KVM personnalisés contiennent tout simplement des informations qui ne seront alors plus recherchées lors des exécutions suivantes.

Garbage collection

L'algorithme de garbage collection utilisé par la KVM est du type "mark sweep". Lors de l'allocation d'un nouvel objet, celui-ci reçoit comme marque un entête contenant notamment la taille de l'objet et une marque.

ConclusionLes terminaux mobiles sont limités par la mémoire, la puissance de traitement et par les possibilités de l'interface utilisateur. Cependant, c'est la contrainte sur la mémoire qui a le plus gros impact : elle peut limiter le choix du garbage collector, empécher l'utilisation du JIT et d'autres optimisations.

Bien que ces dix dernières années, l'optimisation ait principalement porté la vitesse d'exécution, l'optimisation pour les terminaux mobiles repose essentiellement sur la mémoire.

De plus, afin que le compilateur soit efficace, il est nécessaire que le langage compilé mette l'accent sur les structures de données et sur des styles de programmation rigoureux, tels que l'on les rencontre avec Java.


Livre blanc de J2ME

Optimisation de l’application

Quand vous développez une application mobile J2ME, votre première préoccupation doit être de l’optimiser. Pour cela, vous pouvez agir sur les algorithmes utilisés ainsi que chercher à réduire la taille du code.

Voici quelques conseils vous permettant d’optimiser votre code J2ME :

· Réduisez la longueur des noms des classes. Agissez pour cela à la fois au niveau du nom du fichier, du nom de la classe et du nom du constructeur. Dans le même esprit, vous pouvez raccourcir les noms des méthodes. Assez curieusement, la réduction du nom des arguments et des variables locales n’a pas d’effet sur la taille du code. Il est donc conseillé de conserver des noms significatifs. Par contre, le fait de réduire les noms des champs diminue la taille du code.

· Chaque classe apportant une surcharge, utilisez la programmation orientée objet avec parcimonie.

· Évitez autant que possible la création dynamique d’objets, comme avec les vecteurs, et préférez les tableaux.

· Lorsque vous réalisez des animations, réduisez le nombre de sprites affichées.

· Évitez d’utiliser l’écran entier sur les terminaux de type Palm.

· L’utilisation d’un fichier .jar non compressé accélère le démarrage du MIDlet.

· Pour internationaliser votre application, il est conseillé de créer une application par langue ou par pays.

· Préférez l’utilisation des types scalaires, comme int, plutôt que des objets, comme person.

· Affectez la valeur null aux références qui ne sont plus utilisées.

· Lorsque vous le pouvez, utilisez un pool pour réutiliser les objets instanciés.

· Évitez les exceptions, car ce sont des objets et elles consomment des octets.

· Préférez StringBuffer à la concaténation des chaînes.

· Utilisez autant que possible des variables locales.


· 57

Les limitations sur CLDC / KVM

Les principales différences d'implémentation de la KVM et du langage Java

sont :

· Pas de finalisation. CLDC ne propose pas de méthode de finalisation des instances de classe Object.finalize(). La raison en est que CLDC ne supporte pas le nettoyage de la mémoire (garbage collection). Il n'est donc pas possible de nettoyer les données de l'objet avant le garbage collection.

· Peu de classes d'erreurs. Le langage Java prévoit deux catégories d'exceptions, java.lang.Error et java.lang.Exception, toutes deux dérivant de java.lang.Throwable. Les classes issues de la classe Error ne sont pas récupérables, alors que celles issues de la classe Exception le sont. Or CLDC n'a prévu que deux classes d'erreurs, java.lang.OutOfMemoryError et java.lang.VirtualMachineError. Il y a deux raisons à cela : le traitement des erreurs est fortement spécifique du terminal, et ce processus est très consommateur de ressources.

· Pas de JNI. JNI n'est pas implémenté, d'abord pour des raisons de sécurité, ensuite parce que l'implémentation de JNI est trop coûteuse en mémoire.

· Pas de chargeur de classe défini par l'utilisateur. Pour des raisons de sécurité le chargeur de classe intégré ne peut être surchargé par l'utilisateur.

· Ni reflection, ni RMI, ni sérialisation d'objet. La reflection n'est pas supportée, ce qui signifie que l'application ne peut pas inspecter le contenu des classes, des objets ou des méthodes. Par conséquent, toutes les fonctionnalités qui découlent de la reflection ne sont pas supportées, tels le RMI ou la sérialisation d'objet.

· Pas de groupes de threads ou de threads démons. Le multithreading est implémenté, mais les groupes de threads ou les threads démons ne le sont pas. Pour rappel, les groupes de threads permettent de regrouper un ensemble de threads et d'effectuer des méthodes, comme l'arrêt ou la suspension, sur chacun de ces threads. Les threads démons sont des threads qui tournent en tâche de fond et proposent des services aux autres threads. Pour contourner cette limitation, vous devez utiliser des objets de collection pour stocker les objets threads au niveau de l'application.


Livre blanc de J2ME

· Pas de références faibles. Les références faibles ne sont pas autorisées.

· Une référence faible est un type de référence vers un objet qui vous permet de déterminer si un objet est finalisé. Elle permet de conserver une référence vers l'objet sans l'empêcher d'être pris en compte par le garbage collector. L'application la plus évidente en est le cache. C'est aussi une solution de rechange au nettoyage classique effectué lors de la finalisation Java.


· 59

Conclusion

Le marché actuel est d’abord caractérisé par une diversification croissante de l’offre et des réseaux d’accès. De plus, nous assistons à une montée en puissance assez rapide des possibilités des terminaux et des réseaux.

Les aspects culturels ne sont pas à sous-estimer. Il est nécessaire de tenir compte des habitudes culturelles et des contraintes spécifiques à chaque pays (géographie, langue, situation économique, …).

Le marché des logiciels pour terminaux et pour serveurs est pour l’instant très fragmenté et en cours de consolidation. Et les standards existants sont encore à leurs débuts.

Au niveau économique, les modèles économiques et les coûts d’accès vont sensiblement évoluer. Il est prudent de s’assurer que le retour sur investissement soit possible sans devoir attendre l’explosion dans le grand public. Cependant, les projets d’entreprise sont viables dès aujourd’hui mais nécessitent un long prototypage et des projets pilotes pour intégrer les remarques des utilisateurs.

Les projets sont conditionnés à plusieurs facteurs. Le premier est l’existence de terminaux plus ergonomiques. Le second est le déploiement du GPRS, donc de la connexion permanente, et la stabilisation des offres de facturation au volume de données. Le troisième est le développement des systèmes de messagerie type EMS, MMS ou email. Enfin, le quatrième est la mise en place de modèles économiques de partage de revenus de la part des opérateurs.


· 61


· 63

Technology

Livre blanc de J2ME