SlideShare une entreprise Scribd logo
1Livre blanc


      Le livre blanc de J2ME


                       Bruno Delb




www.BrunoDelb.com
© 2006, Bruno Delb
En 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 :        1
         Date d’émission : 8 juillet 2006
         Auteur :         Bruno Delb




                                                                                                         Bruno Delb
                                                                                      Email : edition@brunodelb.com
                                                                                         Web : www.brunodelb.com
Table des matières
               Introduction.................................................................................................5
                         Le marché.............................................................................................................................5
                         Les freins au développement................................................................................................5
                         Les enjeux.............................................................................................................................6

               Java..............................................................................................................7
                         Les machines virtuelles........................................................................................................8
                                  KVM (Kilo Virtual Machine)................................................................................8
                                  CVM (Convergence Virtual Machine)..................................................................8
                         Les configurations................................................................................................................9
                                  CLDC (JSR 30)......................................................................................................9
                                  CDC (JSR 36)........................................................................................................9
                         Les profils.............................................................................................................................9
                                  MIDP......................................................................................................................9
                                  PDAP (JSR 75)......................................................................................................9
                                  Foundation Profile (JSR 46)................................................................................10
                                  Personal Profile (JSR 62).....................................................................................10
                                  RMI (JSR 66).......................................................................................................10
                         Les autres API de J2ME.....................................................................................................10
                                  Java Phone API....................................................................................................11
                                  Java TV API.........................................................................................................11
                                  Java Card.............................................................................................................11
                                  Connexion Jini.....................................................................................................11
                                  Java Embedded Server.........................................................................................11
                                  Spotlet..................................................................................................................12

               Introduction à J2ME.................................................................................13
                         Les configurations..............................................................................................................14
                                  La configuration CLDC.......................................................................................14
                         Les profils...........................................................................................................................15
                                  Le profil MIDP....................................................................................................16
                                  Le profil MIDP 2.0..............................................................................................17
                                  Le profil PDAP....................................................................................................17

               Le profil MIDP...........................................................................................18
                         Vue d'ensemble de l'API....................................................................................................18
                         L'interface utilisateur.........................................................................................................19
                                  L'interface utilisateur de haut niveau..................................................................19
                                  La gestion des événements..................................................................................20
                                  L'interface utilisateur de bas niveau....................................................................20
                                  La gestion des événements..................................................................................20
                         Le stockage persistent........................................................................................................21
                         Le réseau.............................................................................................................................22
                                  Le GCF.................................................................................................................22
                                  HttpConnection....................................................................................................22
                         Un exemple.........................................................................................................................22
                                  Le MIDlet HelloWorld.........................................................................................23
                                  La déclaration de la classe...................................................................................24
                                  Les variables d'instance.......................................................................................24
Livre blanc de J2ME                                         Bruno Delb                                                                                       • i
                                                            Email : edition@brunodelb.com
                                                            Web : http://www.brunodelb.com
Le constructeur....................................................................................................24
                              Les méthodes du cycle de vie...............................................................................24
                              L'interface utilisateur...........................................................................................25
                              Le composant TextBox........................................................................................25
                              L'association des commandes aux touches..........................................................25
                              La priorité............................................................................................................25
                              La gestion des événements..................................................................................25
                              Conclusion...........................................................................................................26

       Le profil MIDP 2........................................................................................26
                 Les nouvelles fonctionnalités.............................................................................................26
                          Le modèle de sécurité..........................................................................................26
                          HTTPS/SSL ........................................................................................................26
                          Réseau et push avancés........................................................................................27
                          Livraison d’application........................................................................................27
                          Interface utilisateur améliorée.............................................................................27
                          Le jeu....................................................................................................................28
                          Le son...................................................................................................................29
                 La sécurité..........................................................................................................................30
                          Les autorisations..................................................................................................30
                          Les domaines de protection.................................................................................31
                          La politique de sécurité........................................................................................31
                          Les applications signées certifiées.......................................................................31
                          Les applications signées OTA (Over The Air)...................................................32
                 Le réseau.............................................................................................................................32
                          Nouveaux gestionnaires de protocole..................................................................32
                          Appel de MIDlet..................................................................................................33

       Le profil PDAP..........................................................................................34
                 Introduction........................................................................................................................34
                          Le positionnement de PDAP...............................................................................34
                          La raison d’être de PDAP....................................................................................34
                 Les PDAlets........................................................................................................................35
                 L’interface utilisateur.........................................................................................................35
                          AWT....................................................................................................................35
                          Interaction entre AWT et LCDUI.......................................................................35
                 Personal Information Management (PIM).........................................................................35
                 La connectivité...................................................................................................................36
                          Le port série.........................................................................................................36
                          Le système de fichier...........................................................................................36
                 La sécurité..........................................................................................................................36

       La migration d’application de J2SE vers J2ME (MIDP)........................37
                 Pourquoi migrer une application de J2SE vers J2ME ?....................................................37
                 Le cycle de vie....................................................................................................................37
                          Le cycle de vie d’une application J2SE...............................................................37
                          Le cycle de vie d’une application J2ME..............................................................38
                 Migration des fonctionnalités............................................................................................38
                          L’interface utilisateur..........................................................................................38
                          Le réseau, les entrées-sorties et le stockage de données.....................................38
                 Préparation du code pour la migration..............................................................................39
                 Commutation du code........................................................................................................39
                 Test du code........................................................................................................................40

       iMode.........................................................................................................41
                 Des terminaux iMode.........................................................................................................43
                 L'API iMode.......................................................................................................................43
                         Le réseau..............................................................................................................43
                         Le stockage de données persistentes....................................................................43

ii •                                                Bruno Delb                                                 Livre blanc de J2ME
                                                    Email : edition@brunodelb.com
                                                    Web : http://www.brunodelb.com
L'interface utilisateur...........................................................................................43
                        Quelles sont les différences entre Java for i-Mode et MIDP ?..........................................44
                        Mais à quoi ressemble une i-Appli ?.................................................................................44
                                 MIDlet..................................................................................................................45
                                 iAppli...................................................................................................................45

               Le processeur Jazelle..............................................................................47
                        Les trois états......................................................................................................................47
                        Changement d’état.............................................................................................................47
                        Utilisation de registres.......................................................................................................48
                        Equilibre matériel / logiciel...............................................................................................48
                        Performances......................................................................................................................49

               Optimisation de la machine virtuelle.....................................................51
                        Optimisation matérielle.....................................................................................................51
                        Optimisation logicielle.......................................................................................................52
                                Les machines virtuelles pour les terminaux mobiles..........................................52
                                La machine virtuelle KVM..................................................................................53
                        Conclusion..........................................................................................................................54

               Optimisation de l’application..................................................................55

               Les limitations sur CLDC / KVM.............................................................56

               Conclusion................................................................................................59




Livre blanc de J2ME                                        Bruno Delb                                                                                   • iii
                                                           Email : edition@brunodelb.com
                                                           Web : http://www.brunodelb.com
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 :


                                                      200            200    200    200        2004
                                                      0              1      2      3
                         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            0,3            0,9    1,7    2,6        3
                         jeux
                         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)



Les freins au développement
                      Les freins au développement de la mobilité sont nombreux :
Livre blanc de J2ME                 Bruno Delb                                                        • 5
                                    Email : edition@brunodelb.com
                                    Web : http://www.brunodelb.com
Frein                        Description
                Ergonomie des                •    Trop petit taille des écrans
                terminaux
                                             •    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            •    Temps d’établissement de la connexion trop
                qualité de service
                                                  long (le GPRS possède une connexion
                insuffisants
                                                  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         •    Facturation au volume de données, à l’acte
                de communication
                                                  d’usage ou forfaitaire possibles avec
                                                  l’arrivée du GPRS
                Manque de service et         •    Tests insuffisants sur les terminaux
                de contenus de
                qualité



Les enjeux
             Les 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 Delb                                 Livre blanc de J2ME
                           Email : edition@brunodelb.com
                           Web : http://www.brunodelb.com
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
                      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.

Livre blanc de J2ME                  Bruno Delb                                                            • 7
                                     Email : edition@brunodelb.com
                                     Web : http://www.brunodelb.com
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 virtuelles
                Au 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.




8 •                           Bruno Delb                              Livre blanc de J2ME
                              Email : edition@brunodelb.com
                              Web : http://www.brunodelb.com
Les configurations
                      J2ME 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 profils
                      J2ME 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.


                      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

Livre blanc de J2ME                 Bruno Delb                                                           • 9
                                    Email : edition@brunodelb.com
                                    Web : http://www.brunodelb.com
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.


Les autres API de J2ME
               Parmi 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é.



10 •                         Bruno Delb                               Livre blanc de J2ME
                             Email : edition@brunodelb.com
                             Web : http://www.brunodelb.com
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.
                      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.



Livre blanc de J2ME                  Bruno Delb                                                      • 11
                                     Email : edition@brunodelb.com
                                     Web : http://www.brunodelb.com
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()




12 •                  Bruno Delb                               Livre blanc de J2ME
                      Email : edition@brunodelb.com
                      Web : http://www.brunodelb.com
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.


                              J2EE                     J2SE                          J2ME

                                EJB

                               Servlet
                                                                                           Personal     RMI
                                JSP                                                         Profile    Profile


                                JDBC                                       MIDP     PDAP    Foundation Profile


                                JMS                                           CLDC               CDC

                                JCA                     SDK                   KVM                CVM

                            APIs du noyau           APIs du noyau         APIs du noyau    APIs du noyau



                                                              Langage Java




Livre blanc de J2ME                      Bruno Delb                                                              • 13
                                         Email : edition@brunodelb.com
                                         Web : http://www.brunodelb.com
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                 128 à 512 Ko (RAM +         1 Mo (ROM) + 512 Ko
                   mémoire                ROM)                        (RAM)
                   Processeur             16 ou 32 bits               32 bits
                   Réseau                 Faible bande passante ou    Connexion réseau
                                          faible qualité de service
                                          du 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 configurations
                J2ME 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.


14 •                            Bruno Delb                             Livre blanc de J2ME
                                Email : edition@brunodelb.com
                                Web : http://www.brunodelb.com
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 profils
                      J2ME 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)


Livre blanc de J2ME                 Bruno Delb                                                      • 15
                                    Email : edition@brunodelb.com
                                    Web : http://www.brunodelb.com
•    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.
                    •    Les MIDlets peuvent fournit des conseils sémantiques (comme
                         retour).
16 •                 Bruno Delb                              Livre blanc de J2ME
                     Email : edition@brunodelb.com
                     Web : http://www.brunodelb.com
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.




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




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


                      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é.
                      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
Livre blanc de J2ME                 Bruno Delb                                                      • 19
                                    Email : edition@brunodelb.com
                                    Web : http://www.brunodelb.com
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.


       La gestion des événements
       La classe Canvas est une sous-classe de la classe Displayable. Elle permet
       d'enregistrer un listener de commandes. Il est cependant préalablement
       nécessaire de créer plusieurs interfaces listener, chacune étant associée à un
       type d'événement.




20 •                 Bruno Delb                              Livre blanc de J2ME
                     Email : edition@brunodelb.com
                     Web : http://www.brunodelb.com
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 persistent
                      RMS (Record Management System) est une API de stockage persistent sur le
                      terminal. C'est en quelque sorte une base de données indépendante du terminal.
                      Chaque enregistrement est représenté sous forme de tableau d'octets. La mise
                      est jour est dite atomique : l'enregistrement entier est réécrit à chaque fois.
                      Les enregistrements sont stockés dans ce que l'on appelle un Record store. Si
                      l'on veut faire un parallèle avec les SGBD relationnels, RMS correspond au
                      SGBD lui-même et le Record store à la table. D'ailleurs, le parallèle de la notion
                      de clé primaire des bases de données relationnelles est le recordID. Il s'agit de
                      l'identifiant de l'enregistrement. C'est un nombre entier. La valeur de l'ID du
                      premier enregistrement est 1 et chaque nouvel enregistrement a une valeur ID
                      augmentée de un.
                      Plusieurs méthodes permettent de gérer les Records store.
                      openRecordStore et closeRecordStore permettent respectivement d'ouvrir et de
                      fermer un Record store.
                      La liste de tous les Record store peut être obtenue par listRecordStore.
                      deleteRecordStore en supprime un.
                      Le nombre d'enregistrements dans un Record store est retourné par
                      getNumRecords.
                      Les opérations de base sur les enregistrements sont assurées par ces méthodes :
                      addRecord (ajout), deleteRecord (suppression), getRecord (lecture), setRecord
                      (modification), getRecordSize (taille de l'enregistrement).
                      L'API RMS dispose cependant de quelques particularités supplémentaires,
                      concernant la sélection des enregistrements. La première est l'utilisation de la
                      méthode RecordEnumeration pour lister tous les enregistrements du Record
                      store. La seconde est la possibilité de définir un filtre avec la méthode
                      RecordFilter. Enfin, l'interface RecordComparator doit être implémentée pour
                      que des enregistrements puissent être comparés et donc triés.
Livre blanc de J2ME                 Bruno Delb                                                     • 21
                                    Email : edition@brunodelb.com
                                    Web : http://www.brunodelb.com
Le réseau
             Avec plus de 100 classes, l'API de J2EE dédiée au réseau, aux entrées / sorties
             et au stockage est beaucoup trop lourde que celle utilisée pour les terminaux
             CLDC.
             Elle est remplacée dans la CLDC par le GCF (Generic Connection Framework).
             Le GCF assure une plus grande cohérence entre les différents types d'entrées /
             sorties tout en améliorant la portabilité des applications.


             Le GCF
             Le GCF fournit un moyen uniforme et pratique d'effectuer des entrées / sorties
             quelque soit le type de protocole. La syntaxe générale est la suivante :
             Connector.open("<protocole>://<adresse>:<parametres>");

             Plusieurs protocoles sont utilisables. 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é.
             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 exemple
             Comme 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
22 •                          Bruno Delb                               Livre blanc de J2ME
                              Email : edition@brunodelb.com
                              Web : http://www.brunodelb.com
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:
                      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: }

Livre blanc de J2ME                      Bruno Delb                                                     • 23
                                         Email : edition@brunodelb.com
                                         Web : http://www.brunodelb.com
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.


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


24 •                  Bruno Delb                              Livre blanc de J2ME
                      Email : edition@brunodelb.com
                      Web : http://www.brunodelb.com
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.


                      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.


                      La gestion des événements
                      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).

Livre blanc de J2ME                  Bruno Delb                                                       • 25
                                     Email : edition@brunodelb.com
                                     Web : http://www.brunodelb.com
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és
                Les nouvelles fonctionnalités de MIDP 2.0 sont :
                             •    Nouveau modèle de sécurité avec les MIDlets certifiées
                             •    HTTPS
                             •    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
26 •                          Bruno Delb                             Livre blanc de J2ME
                              Email : edition@brunodelb.com
                              Web : http://www.brunodelb.com
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.


                      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.




Livre blanc de J2ME                 Bruno Delb                                                       • 27
                                    Email : edition@brunodelb.com
                                    Web : http://www.brunodelb.com
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME
Livre blanc de J2ME

Contenu connexe

Tendances

Rapport atef
Rapport atefRapport atef
Rapport atef
Atef Kouiri
 
Conception et développement de la gestion de visa sous Dynamics Ax R2
Conception et développement de la gestion de visa sous Dynamics Ax R2Conception et développement de la gestion de visa sous Dynamics Ax R2
Conception et développement de la gestion de visa sous Dynamics Ax R2
Rawdha MABROUKI
 
Amadou Bory Diallo (document sur la téléphonie sur IP)
Amadou Bory Diallo (document sur la téléphonie sur IP)Amadou Bory Diallo (document sur la téléphonie sur IP)
Amadou Bory Diallo (document sur la téléphonie sur IP)
Bory DIALLO
 
The Ring programming language version 1.9 book - Part 1 of 210
The Ring programming language version 1.9 book - Part 1 of 210The Ring programming language version 1.9 book - Part 1 of 210
The Ring programming language version 1.9 book - Part 1 of 210
Mahmoud Samir Fayed
 
Support formation vidéo : Excel 2016 - Maîtrisez les bases
Support formation vidéo : Excel 2016 - Maîtrisez les basesSupport formation vidéo : Excel 2016 - Maîtrisez les bases
Support formation vidéo : Excel 2016 - Maîtrisez les bases
SmartnSkilled
 
Apprenez à monter votre ordinateur
Apprenez à monter votre ordinateurApprenez à monter votre ordinateur
Apprenez à monter votre ordinateur
Fouad Root
 
The Ring programming language version 1.10 book - Part 1 of 212
The Ring programming language version 1.10 book - Part 1 of 212The Ring programming language version 1.10 book - Part 1 of 212
The Ring programming language version 1.10 book - Part 1 of 212
Mahmoud Samir Fayed
 
The Ring programming language version 1.6 book - Part 1 of 189
The Ring programming language version 1.6 book - Part 1 of 189The Ring programming language version 1.6 book - Part 1 of 189
The Ring programming language version 1.6 book - Part 1 of 189
Mahmoud Samir Fayed
 
Fr fr regulatory-653267-052
Fr fr regulatory-653267-052Fr fr regulatory-653267-052
Fr fr regulatory-653267-052Rafikos1982
 
Support formation vidéo : Word 2016 - Maîriser les bases
Support formation vidéo : Word 2016 - Maîriser les basesSupport formation vidéo : Word 2016 - Maîriser les bases
Support formation vidéo : Word 2016 - Maîriser les bases
SmartnSkilled
 
Mise en place d'une solution du supérvision réseau
Mise en place d'une solution du supérvision réseauMise en place d'une solution du supérvision réseau
Mise en place d'une solution du supérvision réseau
Rabeb Boumaiza
 
Support formation vidéo: PowerPoint 2016 - Maîtriser les bases
Support formation vidéo: PowerPoint 2016 - Maîtriser les basesSupport formation vidéo: PowerPoint 2016 - Maîtriser les bases
Support formation vidéo: PowerPoint 2016 - Maîtriser les bases
SmartnSkilled
 
mise en place d'un système de classes virtuelles utilisant le webRTC + openfi...
mise en place d'un système de classes virtuelles utilisant le webRTC + openfi...mise en place d'un système de classes virtuelles utilisant le webRTC + openfi...
mise en place d'un système de classes virtuelles utilisant le webRTC + openfi...
Bassirou Dime
 
The Ring programming language version 1.2 book - Part 1 of 84
The Ring programming language version 1.2 book - Part 1 of 84The Ring programming language version 1.2 book - Part 1 of 84
The Ring programming language version 1.2 book - Part 1 of 84
Mahmoud Samir Fayed
 
Barometre des Pratiques de Veille 2008
Barometre des Pratiques de Veille 2008Barometre des Pratiques de Veille 2008
Barometre des Pratiques de Veille 2008
Digimind
 
Digimind: Benchmark Solutions de Veille 2011
Digimind: Benchmark Solutions de Veille 2011Digimind: Benchmark Solutions de Veille 2011
Digimind: Benchmark Solutions de Veille 2011
Digimind
 
Administration joomla2 5
Administration joomla2 5Administration joomla2 5
Administration joomla2 5
Com'3elles - www.com3elles.com
 
Rapprot de satge supervision de résau par EyesOfNetwok
Rapprot de satge supervision de résau par EyesOfNetwokRapprot de satge supervision de résau par EyesOfNetwok
Rapprot de satge supervision de résau par EyesOfNetwok
Abdessamad IDRISSI
 

Tendances (19)

Rapport atef
Rapport atefRapport atef
Rapport atef
 
Conception et développement de la gestion de visa sous Dynamics Ax R2
Conception et développement de la gestion de visa sous Dynamics Ax R2Conception et développement de la gestion de visa sous Dynamics Ax R2
Conception et développement de la gestion de visa sous Dynamics Ax R2
 
Amadou Bory Diallo (document sur la téléphonie sur IP)
Amadou Bory Diallo (document sur la téléphonie sur IP)Amadou Bory Diallo (document sur la téléphonie sur IP)
Amadou Bory Diallo (document sur la téléphonie sur IP)
 
The Ring programming language version 1.9 book - Part 1 of 210
The Ring programming language version 1.9 book - Part 1 of 210The Ring programming language version 1.9 book - Part 1 of 210
The Ring programming language version 1.9 book - Part 1 of 210
 
Support formation vidéo : Excel 2016 - Maîtrisez les bases
Support formation vidéo : Excel 2016 - Maîtrisez les basesSupport formation vidéo : Excel 2016 - Maîtrisez les bases
Support formation vidéo : Excel 2016 - Maîtrisez les bases
 
Apprenez à monter votre ordinateur
Apprenez à monter votre ordinateurApprenez à monter votre ordinateur
Apprenez à monter votre ordinateur
 
The Ring programming language version 1.10 book - Part 1 of 212
The Ring programming language version 1.10 book - Part 1 of 212The Ring programming language version 1.10 book - Part 1 of 212
The Ring programming language version 1.10 book - Part 1 of 212
 
The Ring programming language version 1.6 book - Part 1 of 189
The Ring programming language version 1.6 book - Part 1 of 189The Ring programming language version 1.6 book - Part 1 of 189
The Ring programming language version 1.6 book - Part 1 of 189
 
Fr fr regulatory-653267-052
Fr fr regulatory-653267-052Fr fr regulatory-653267-052
Fr fr regulatory-653267-052
 
Support formation vidéo : Word 2016 - Maîriser les bases
Support formation vidéo : Word 2016 - Maîriser les basesSupport formation vidéo : Word 2016 - Maîriser les bases
Support formation vidéo : Word 2016 - Maîriser les bases
 
Mise en place d'une solution du supérvision réseau
Mise en place d'une solution du supérvision réseauMise en place d'une solution du supérvision réseau
Mise en place d'une solution du supérvision réseau
 
Support formation vidéo: PowerPoint 2016 - Maîtriser les bases
Support formation vidéo: PowerPoint 2016 - Maîtriser les basesSupport formation vidéo: PowerPoint 2016 - Maîtriser les bases
Support formation vidéo: PowerPoint 2016 - Maîtriser les bases
 
mise en place d'un système de classes virtuelles utilisant le webRTC + openfi...
mise en place d'un système de classes virtuelles utilisant le webRTC + openfi...mise en place d'un système de classes virtuelles utilisant le webRTC + openfi...
mise en place d'un système de classes virtuelles utilisant le webRTC + openfi...
 
The Ring programming language version 1.2 book - Part 1 of 84
The Ring programming language version 1.2 book - Part 1 of 84The Ring programming language version 1.2 book - Part 1 of 84
The Ring programming language version 1.2 book - Part 1 of 84
 
Rapport pfev7
Rapport pfev7Rapport pfev7
Rapport pfev7
 
Barometre des Pratiques de Veille 2008
Barometre des Pratiques de Veille 2008Barometre des Pratiques de Veille 2008
Barometre des Pratiques de Veille 2008
 
Digimind: Benchmark Solutions de Veille 2011
Digimind: Benchmark Solutions de Veille 2011Digimind: Benchmark Solutions de Veille 2011
Digimind: Benchmark Solutions de Veille 2011
 
Administration joomla2 5
Administration joomla2 5Administration joomla2 5
Administration joomla2 5
 
Rapprot de satge supervision de résau par EyesOfNetwok
Rapprot de satge supervision de résau par EyesOfNetwokRapprot de satge supervision de résau par EyesOfNetwok
Rapprot de satge supervision de résau par EyesOfNetwok
 

En vedette

EUROBACK : un outil collaboratif, pour échanger, compléter et valoriser nos ...
EUROBACK : un outil collaboratif, pour échanger, 	compléter et valoriser nos ...EUROBACK : un outil collaboratif, pour échanger, 	compléter et valoriser nos ...
EUROBACK : un outil collaboratif, pour échanger, compléter et valoriser nos ...François Renaville
 
Jardines en bloques de viviendas
Jardines en bloques de viviendasJardines en bloques de viviendas
Jardines en bloques de viviendas
Rocio
 
Quelles actions depuis les 3èmes assises 2012
Quelles actions depuis les 3èmes assises 2012 Quelles actions depuis les 3èmes assises 2012
Quelles actions depuis les 3èmes assises 2012
Office Nationale du Tourisme Madagascar
 
Análisis del programa PREPARA y de las últimas modificaciones. Del Real Decre...
Análisis del programa PREPARA y de las últimas modificaciones. Del Real Decre...Análisis del programa PREPARA y de las últimas modificaciones. Del Real Decre...
Análisis del programa PREPARA y de las últimas modificaciones. Del Real Decre...
Universidad Autónoma de Barcelona
 
01 denis tregoat - présentation spectro ir
01  denis tregoat - présentation spectro ir01  denis tregoat - présentation spectro ir
01 denis tregoat - présentation spectro irYann Dieulangard
 
Assises internationales du tourisme durable et éthique
Assises internationales du tourisme durable et éthiqueAssises internationales du tourisme durable et éthique
Assises internationales du tourisme durable et éthique
Office Nationale du Tourisme Madagascar
 
Les 58 ch-teaux_des_bords_de_loire
Les 58 ch-teaux_des_bords_de_loireLes 58 ch-teaux_des_bords_de_loire
Les 58 ch-teaux_des_bords_de_loire
Gerard Houdinet
 
Analyse linguistique du discours de presse française-la modalisation dans le ...
Analyse linguistique du discours de presse française-la modalisation dans le ...Analyse linguistique du discours de presse française-la modalisation dans le ...
Analyse linguistique du discours de presse française-la modalisation dans le ...
Alexander Decker
 
Análisis y comentario del contenido laboral, de empleo y de protección social...
Análisis y comentario del contenido laboral, de empleo y de protección social...Análisis y comentario del contenido laboral, de empleo y de protección social...
Análisis y comentario del contenido laboral, de empleo y de protección social...
Universidad Autónoma de Barcelona
 
Planete Pme 15 juin 2010 Conference Et Gorgy Timing Prix Chine 2010
Planete Pme 15 juin 2010 Conference Et Gorgy Timing Prix Chine 2010Planete Pme 15 juin 2010 Conference Et Gorgy Timing Prix Chine 2010
Planete Pme 15 juin 2010 Conference Et Gorgy Timing Prix Chine 2010
Renaud Favier
 
Phising
PhisingPhising
Phising
absisa
 
LAS HUELLAS DEL PASADO
LAS HUELLAS DEL PASADOLAS HUELLAS DEL PASADO
LAS HUELLAS DEL PASADO
luisel
 
Futur pub dossierpresse
Futur pub dossierpresseFutur pub dossierpresse
Futur pub dossierpresseDenis Verloes
 
Astec French Language Brochure
Astec French Language BrochureAstec French Language Brochure
Astec French Language Brochure
Tony Loup
 
Etude mondiale sur les web-acheteurs 2012
Etude mondiale sur les web-acheteurs 2012Etude mondiale sur les web-acheteurs 2012
Etude mondiale sur les web-acheteurs 2012
PwC France
 
Pratique sante n°16 juillet septe. 2012
Pratique sante n°16 juillet septe. 2012Pratique sante n°16 juillet septe. 2012
Pratique sante n°16 juillet septe. 2012Mustapha Ben Mansour
 
Ponencia ana meiners seminario ambiental binacional mayo 2010
Ponencia ana meiners seminario ambiental binacional mayo 2010Ponencia ana meiners seminario ambiental binacional mayo 2010
Ponencia ana meiners seminario ambiental binacional mayo 2010
Ciudades Sustentables
 

En vedette (20)

EUROBACK : un outil collaboratif, pour échanger, compléter et valoriser nos ...
EUROBACK : un outil collaboratif, pour échanger, 	compléter et valoriser nos ...EUROBACK : un outil collaboratif, pour échanger, 	compléter et valoriser nos ...
EUROBACK : un outil collaboratif, pour échanger, compléter et valoriser nos ...
 
Jardines en bloques de viviendas
Jardines en bloques de viviendasJardines en bloques de viviendas
Jardines en bloques de viviendas
 
Quelles actions depuis les 3èmes assises 2012
Quelles actions depuis les 3èmes assises 2012 Quelles actions depuis les 3èmes assises 2012
Quelles actions depuis les 3èmes assises 2012
 
Análisis del programa PREPARA y de las últimas modificaciones. Del Real Decre...
Análisis del programa PREPARA y de las últimas modificaciones. Del Real Decre...Análisis del programa PREPARA y de las últimas modificaciones. Del Real Decre...
Análisis del programa PREPARA y de las últimas modificaciones. Del Real Decre...
 
01 denis tregoat - présentation spectro ir
01  denis tregoat - présentation spectro ir01  denis tregoat - présentation spectro ir
01 denis tregoat - présentation spectro ir
 
Assises internationales du tourisme durable et éthique
Assises internationales du tourisme durable et éthiqueAssises internationales du tourisme durable et éthique
Assises internationales du tourisme durable et éthique
 
Les 58 ch-teaux_des_bords_de_loire
Les 58 ch-teaux_des_bords_de_loireLes 58 ch-teaux_des_bords_de_loire
Les 58 ch-teaux_des_bords_de_loire
 
Analyse linguistique du discours de presse française-la modalisation dans le ...
Analyse linguistique du discours de presse française-la modalisation dans le ...Analyse linguistique du discours de presse française-la modalisation dans le ...
Analyse linguistique du discours de presse française-la modalisation dans le ...
 
Análisis y comentario del contenido laboral, de empleo y de protección social...
Análisis y comentario del contenido laboral, de empleo y de protección social...Análisis y comentario del contenido laboral, de empleo y de protección social...
Análisis y comentario del contenido laboral, de empleo y de protección social...
 
Blanche neigev2 1
Blanche neigev2 1Blanche neigev2 1
Blanche neigev2 1
 
Planete Pme 15 juin 2010 Conference Et Gorgy Timing Prix Chine 2010
Planete Pme 15 juin 2010 Conference Et Gorgy Timing Prix Chine 2010Planete Pme 15 juin 2010 Conference Et Gorgy Timing Prix Chine 2010
Planete Pme 15 juin 2010 Conference Et Gorgy Timing Prix Chine 2010
 
Phising
PhisingPhising
Phising
 
LAS HUELLAS DEL PASADO
LAS HUELLAS DEL PASADOLAS HUELLAS DEL PASADO
LAS HUELLAS DEL PASADO
 
B2 c sss lanaudiäre 2008
B2 c sss lanaudiäre 2008B2 c sss lanaudiäre 2008
B2 c sss lanaudiäre 2008
 
Futur pub dossierpresse
Futur pub dossierpresseFutur pub dossierpresse
Futur pub dossierpresse
 
Astec French Language Brochure
Astec French Language BrochureAstec French Language Brochure
Astec French Language Brochure
 
Etude mondiale sur les web-acheteurs 2012
Etude mondiale sur les web-acheteurs 2012Etude mondiale sur les web-acheteurs 2012
Etude mondiale sur les web-acheteurs 2012
 
B2 b gala acq
B2 b gala acqB2 b gala acq
B2 b gala acq
 
Pratique sante n°16 juillet septe. 2012
Pratique sante n°16 juillet septe. 2012Pratique sante n°16 juillet septe. 2012
Pratique sante n°16 juillet septe. 2012
 
Ponencia ana meiners seminario ambiental binacional mayo 2010
Ponencia ana meiners seminario ambiental binacional mayo 2010Ponencia ana meiners seminario ambiental binacional mayo 2010
Ponencia ana meiners seminario ambiental binacional mayo 2010
 

Similaire à Livre blanc de J2ME

Configuration vm sur hyper sharepoint 2013
Configuration vm sur hyper sharepoint 2013Configuration vm sur hyper sharepoint 2013
Configuration vm sur hyper sharepoint 2013
UGAIA
 
Le livre blanc des systemes embarques
Le livre blanc des systemes embarquesLe livre blanc des systemes embarques
Le livre blanc des systemes embarques
Hichem Bensenouci
 
Administration joomla2 5
Administration joomla2 5Administration joomla2 5
Administration joomla2 5
Céline Robert
 
Adobe Photoshop CS5
Adobe Photoshop CS5Adobe Photoshop CS5
Adobe Photoshop CS5
Claudio Montoni
 
Bi methodes agiles
Bi methodes agilesBi methodes agiles
Bi methodes agiles
youssef222
 
Mémoire seo-fb
Mémoire seo-fbMémoire seo-fb
Mémoire seo-fb
Fanny_Bardel
 
Guide administrateur rubedo 2.2
Guide administrateur rubedo 2.2Guide administrateur rubedo 2.2
Guide administrateur rubedo 2.2
Rubedo, a WebTales solution
 
Technocles2010 1
Technocles2010 1Technocles2010 1
Technocles2010 1
Cyril Durand
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
mouafekmazia
 
Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0
Codendi
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
Belwafi Bilel
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
Belwafi Bilel
 
Course outline p6
Course outline p6Course outline p6
Course outline p6Kazim Naqvi
 

Similaire à Livre blanc de J2ME (20)

Configuration vm sur hyper sharepoint 2013
Configuration vm sur hyper sharepoint 2013Configuration vm sur hyper sharepoint 2013
Configuration vm sur hyper sharepoint 2013
 
Le livre blanc des systemes embarques
Le livre blanc des systemes embarquesLe livre blanc des systemes embarques
Le livre blanc des systemes embarques
 
Administration joomla2 5
Administration joomla2 5Administration joomla2 5
Administration joomla2 5
 
Guide administrateur22
Guide administrateur22Guide administrateur22
Guide administrateur22
 
Adobe Photoshop CS5
Adobe Photoshop CS5Adobe Photoshop CS5
Adobe Photoshop CS5
 
Pmbok methodes agiles
Pmbok methodes agilesPmbok methodes agiles
Pmbok methodes agiles
 
Bi methodes agiles
Bi methodes agilesBi methodes agiles
Bi methodes agiles
 
Mémoire seo-fb
Mémoire seo-fbMémoire seo-fb
Mémoire seo-fb
 
Guide administrateur rubedo 2.2
Guide administrateur rubedo 2.2Guide administrateur rubedo 2.2
Guide administrateur rubedo 2.2
 
Le PC
Le PCLe PC
Le PC
 
Technocles2010 1
Technocles2010 1Technocles2010 1
Technocles2010 1
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
 
Me wbp
Me wbpMe wbp
Me wbp
 
Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0
 
Cours animation et multimédia:
Cours animation et multimédia:Cours animation et multimédia:
Cours animation et multimédia:
 
Complet
CompletComplet
Complet
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
19
1919
19
 
Course outline p6
Course outline p6Course outline p6
Course outline p6
 

Plus de Bruno Delb

Introduction to Swift (tutorial)
Introduction to Swift (tutorial)Introduction to Swift (tutorial)
Introduction to Swift (tutorial)
Bruno Delb
 
Android Lab Test : Storage of data with SharedPreferences (english)
Android Lab Test : Storage of data with SharedPreferences (english)Android Lab Test : Storage of data with SharedPreferences (english)
Android Lab Test : Storage of data with SharedPreferences (english)
Bruno Delb
 
Android Lab Test : Using the sensor gyroscope (english)
Android Lab Test : Using the sensor gyroscope (english)Android Lab Test : Using the sensor gyroscope (english)
Android Lab Test : Using the sensor gyroscope (english)
Bruno Delb
 
Android Lab Test : Using the network with HTTP (english)
Android Lab Test : Using the network with HTTP (english)Android Lab Test : Using the network with HTTP (english)
Android Lab Test : Using the network with HTTP (english)
Bruno Delb
 
Android Lab Test : Managing sounds with SoundPool (english)
Android Lab Test : Managing sounds with SoundPool (english)Android Lab Test : Managing sounds with SoundPool (english)
Android Lab Test : Managing sounds with SoundPool (english)
Bruno Delb
 
Android Lab Test : Using the text-to-speech (english)
Android Lab Test : Using the text-to-speech (english)Android Lab Test : Using the text-to-speech (english)
Android Lab Test : Using the text-to-speech (english)
Bruno Delb
 
Android Lab Test : Reading the foot file list (english)
Android Lab Test : Reading the foot file list (english)Android Lab Test : Reading the foot file list (english)
Android Lab Test : Reading the foot file list (english)
Bruno Delb
 
Android Lab Test : Creating a menu dynamically (english)
Android Lab Test : Creating a menu dynamically (english)Android Lab Test : Creating a menu dynamically (english)
Android Lab Test : Creating a menu dynamically (english)
Bruno Delb
 
Android Lab Test : Creating a dialog Yes/No (english)
Android Lab Test : Creating a dialog Yes/No (english)Android Lab Test : Creating a dialog Yes/No (english)
Android Lab Test : Creating a dialog Yes/No (english)
Bruno Delb
 
Android Lab Test : The styles of views (english)
Android Lab Test : The styles of views (english)Android Lab Test : The styles of views (english)
Android Lab Test : The styles of views (english)
Bruno Delb
 
Android Lab Test : Creating a menu context (english)
Android Lab Test : Creating a menu context (english)Android Lab Test : Creating a menu context (english)
Android Lab Test : Creating a menu context (english)
Bruno Delb
 
Android Lab Test : Using the camera preview (english)
Android Lab Test : Using the camera preview (english)Android Lab Test : Using the camera preview (english)
Android Lab Test : Using the camera preview (english)
Bruno Delb
 
Android Lab Test : The views, the Gallery (english)
Android Lab Test : The views, the Gallery (english)Android Lab Test : The views, the Gallery (english)
Android Lab Test : The views, the Gallery (english)
Bruno Delb
 
Android Lab Test : Using the WIFI (english)
Android Lab Test : Using the WIFI (english)Android Lab Test : Using the WIFI (english)
Android Lab Test : Using the WIFI (english)
Bruno Delb
 
Android Lab Test : Managing the telephone calls (english)
Android Lab Test : Managing the telephone calls (english)Android Lab Test : Managing the telephone calls (english)
Android Lab Test : Managing the telephone calls (english)
Bruno Delb
 
Android Lab Test : Reading the SMS-inbox (english)
Android Lab Test : Reading the SMS-inbox (english)Android Lab Test : Reading the SMS-inbox (english)
Android Lab Test : Reading the SMS-inbox (english)
Bruno Delb
 
Android Lab Test : Installation of application in Java (english)
Android Lab Test : Installation of application in Java (english)Android Lab Test : Installation of application in Java (english)
Android Lab Test : Installation of application in Java (english)
Bruno Delb
 
Android Lab Test : Ecrire un texte sur le canevas (français)
Android Lab Test : Ecrire un texte sur le canevas (français)Android Lab Test : Ecrire un texte sur le canevas (français)
Android Lab Test : Ecrire un texte sur le canevas (français)
Bruno Delb
 
Android Lab Test : La connectivité réseau avec HTTP (français)
Android Lab Test : La connectivité réseau avec HTTP (français)Android Lab Test : La connectivité réseau avec HTTP (français)
Android Lab Test : La connectivité réseau avec HTTP (français)
Bruno Delb
 
Android Lab Test : Le capteur gyroscope (français)
Android Lab Test : Le capteur gyroscope (français)Android Lab Test : Le capteur gyroscope (français)
Android Lab Test : Le capteur gyroscope (français)
Bruno Delb
 

Plus de Bruno Delb (20)

Introduction to Swift (tutorial)
Introduction to Swift (tutorial)Introduction to Swift (tutorial)
Introduction to Swift (tutorial)
 
Android Lab Test : Storage of data with SharedPreferences (english)
Android Lab Test : Storage of data with SharedPreferences (english)Android Lab Test : Storage of data with SharedPreferences (english)
Android Lab Test : Storage of data with SharedPreferences (english)
 
Android Lab Test : Using the sensor gyroscope (english)
Android Lab Test : Using the sensor gyroscope (english)Android Lab Test : Using the sensor gyroscope (english)
Android Lab Test : Using the sensor gyroscope (english)
 
Android Lab Test : Using the network with HTTP (english)
Android Lab Test : Using the network with HTTP (english)Android Lab Test : Using the network with HTTP (english)
Android Lab Test : Using the network with HTTP (english)
 
Android Lab Test : Managing sounds with SoundPool (english)
Android Lab Test : Managing sounds with SoundPool (english)Android Lab Test : Managing sounds with SoundPool (english)
Android Lab Test : Managing sounds with SoundPool (english)
 
Android Lab Test : Using the text-to-speech (english)
Android Lab Test : Using the text-to-speech (english)Android Lab Test : Using the text-to-speech (english)
Android Lab Test : Using the text-to-speech (english)
 
Android Lab Test : Reading the foot file list (english)
Android Lab Test : Reading the foot file list (english)Android Lab Test : Reading the foot file list (english)
Android Lab Test : Reading the foot file list (english)
 
Android Lab Test : Creating a menu dynamically (english)
Android Lab Test : Creating a menu dynamically (english)Android Lab Test : Creating a menu dynamically (english)
Android Lab Test : Creating a menu dynamically (english)
 
Android Lab Test : Creating a dialog Yes/No (english)
Android Lab Test : Creating a dialog Yes/No (english)Android Lab Test : Creating a dialog Yes/No (english)
Android Lab Test : Creating a dialog Yes/No (english)
 
Android Lab Test : The styles of views (english)
Android Lab Test : The styles of views (english)Android Lab Test : The styles of views (english)
Android Lab Test : The styles of views (english)
 
Android Lab Test : Creating a menu context (english)
Android Lab Test : Creating a menu context (english)Android Lab Test : Creating a menu context (english)
Android Lab Test : Creating a menu context (english)
 
Android Lab Test : Using the camera preview (english)
Android Lab Test : Using the camera preview (english)Android Lab Test : Using the camera preview (english)
Android Lab Test : Using the camera preview (english)
 
Android Lab Test : The views, the Gallery (english)
Android Lab Test : The views, the Gallery (english)Android Lab Test : The views, the Gallery (english)
Android Lab Test : The views, the Gallery (english)
 
Android Lab Test : Using the WIFI (english)
Android Lab Test : Using the WIFI (english)Android Lab Test : Using the WIFI (english)
Android Lab Test : Using the WIFI (english)
 
Android Lab Test : Managing the telephone calls (english)
Android Lab Test : Managing the telephone calls (english)Android Lab Test : Managing the telephone calls (english)
Android Lab Test : Managing the telephone calls (english)
 
Android Lab Test : Reading the SMS-inbox (english)
Android Lab Test : Reading the SMS-inbox (english)Android Lab Test : Reading the SMS-inbox (english)
Android Lab Test : Reading the SMS-inbox (english)
 
Android Lab Test : Installation of application in Java (english)
Android Lab Test : Installation of application in Java (english)Android Lab Test : Installation of application in Java (english)
Android Lab Test : Installation of application in Java (english)
 
Android Lab Test : Ecrire un texte sur le canevas (français)
Android Lab Test : Ecrire un texte sur le canevas (français)Android Lab Test : Ecrire un texte sur le canevas (français)
Android Lab Test : Ecrire un texte sur le canevas (français)
 
Android Lab Test : La connectivité réseau avec HTTP (français)
Android Lab Test : La connectivité réseau avec HTTP (français)Android Lab Test : La connectivité réseau avec HTTP (français)
Android Lab Test : La connectivité réseau avec HTTP (français)
 
Android Lab Test : Le capteur gyroscope (français)
Android Lab Test : Le capteur gyroscope (français)Android Lab Test : Le capteur gyroscope (français)
Android Lab Test : Le capteur gyroscope (français)
 

Livre blanc de J2ME

  • 1. 1Livre blanc Le livre blanc de J2ME Bruno Delb www.BrunoDelb.com
  • 2. © 2006, Bruno Delb En 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 : 1 Date d’émission : 8 juillet 2006 Auteur : Bruno Delb Bruno Delb Email : edition@brunodelb.com Web : www.brunodelb.com
  • 3. Table des matières Introduction.................................................................................................5 Le marché.............................................................................................................................5 Les freins au développement................................................................................................5 Les enjeux.............................................................................................................................6 Java..............................................................................................................7 Les machines virtuelles........................................................................................................8 KVM (Kilo Virtual Machine)................................................................................8 CVM (Convergence Virtual Machine)..................................................................8 Les configurations................................................................................................................9 CLDC (JSR 30)......................................................................................................9 CDC (JSR 36)........................................................................................................9 Les profils.............................................................................................................................9 MIDP......................................................................................................................9 PDAP (JSR 75)......................................................................................................9 Foundation Profile (JSR 46)................................................................................10 Personal Profile (JSR 62).....................................................................................10 RMI (JSR 66).......................................................................................................10 Les autres API de J2ME.....................................................................................................10 Java Phone API....................................................................................................11 Java TV API.........................................................................................................11 Java Card.............................................................................................................11 Connexion Jini.....................................................................................................11 Java Embedded Server.........................................................................................11 Spotlet..................................................................................................................12 Introduction à J2ME.................................................................................13 Les configurations..............................................................................................................14 La configuration CLDC.......................................................................................14 Les profils...........................................................................................................................15 Le profil MIDP....................................................................................................16 Le profil MIDP 2.0..............................................................................................17 Le profil PDAP....................................................................................................17 Le profil MIDP...........................................................................................18 Vue d'ensemble de l'API....................................................................................................18 L'interface utilisateur.........................................................................................................19 L'interface utilisateur de haut niveau..................................................................19 La gestion des événements..................................................................................20 L'interface utilisateur de bas niveau....................................................................20 La gestion des événements..................................................................................20 Le stockage persistent........................................................................................................21 Le réseau.............................................................................................................................22 Le GCF.................................................................................................................22 HttpConnection....................................................................................................22 Un exemple.........................................................................................................................22 Le MIDlet HelloWorld.........................................................................................23 La déclaration de la classe...................................................................................24 Les variables d'instance.......................................................................................24 Livre blanc de J2ME Bruno Delb • i Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 4. Le constructeur....................................................................................................24 Les méthodes du cycle de vie...............................................................................24 L'interface utilisateur...........................................................................................25 Le composant TextBox........................................................................................25 L'association des commandes aux touches..........................................................25 La priorité............................................................................................................25 La gestion des événements..................................................................................25 Conclusion...........................................................................................................26 Le profil MIDP 2........................................................................................26 Les nouvelles fonctionnalités.............................................................................................26 Le modèle de sécurité..........................................................................................26 HTTPS/SSL ........................................................................................................26 Réseau et push avancés........................................................................................27 Livraison d’application........................................................................................27 Interface utilisateur améliorée.............................................................................27 Le jeu....................................................................................................................28 Le son...................................................................................................................29 La sécurité..........................................................................................................................30 Les autorisations..................................................................................................30 Les domaines de protection.................................................................................31 La politique de sécurité........................................................................................31 Les applications signées certifiées.......................................................................31 Les applications signées OTA (Over The Air)...................................................32 Le réseau.............................................................................................................................32 Nouveaux gestionnaires de protocole..................................................................32 Appel de MIDlet..................................................................................................33 Le profil PDAP..........................................................................................34 Introduction........................................................................................................................34 Le positionnement de PDAP...............................................................................34 La raison d’être de PDAP....................................................................................34 Les PDAlets........................................................................................................................35 L’interface utilisateur.........................................................................................................35 AWT....................................................................................................................35 Interaction entre AWT et LCDUI.......................................................................35 Personal Information Management (PIM).........................................................................35 La connectivité...................................................................................................................36 Le port série.........................................................................................................36 Le système de fichier...........................................................................................36 La sécurité..........................................................................................................................36 La migration d’application de J2SE vers J2ME (MIDP)........................37 Pourquoi migrer une application de J2SE vers J2ME ?....................................................37 Le cycle de vie....................................................................................................................37 Le cycle de vie d’une application J2SE...............................................................37 Le cycle de vie d’une application J2ME..............................................................38 Migration des fonctionnalités............................................................................................38 L’interface utilisateur..........................................................................................38 Le réseau, les entrées-sorties et le stockage de données.....................................38 Préparation du code pour la migration..............................................................................39 Commutation du code........................................................................................................39 Test du code........................................................................................................................40 iMode.........................................................................................................41 Des terminaux iMode.........................................................................................................43 L'API iMode.......................................................................................................................43 Le réseau..............................................................................................................43 Le stockage de données persistentes....................................................................43 ii • Bruno Delb Livre blanc de J2ME Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 5. L'interface utilisateur...........................................................................................43 Quelles sont les différences entre Java for i-Mode et MIDP ?..........................................44 Mais à quoi ressemble une i-Appli ?.................................................................................44 MIDlet..................................................................................................................45 iAppli...................................................................................................................45 Le processeur Jazelle..............................................................................47 Les trois états......................................................................................................................47 Changement d’état.............................................................................................................47 Utilisation de registres.......................................................................................................48 Equilibre matériel / logiciel...............................................................................................48 Performances......................................................................................................................49 Optimisation de la machine virtuelle.....................................................51 Optimisation matérielle.....................................................................................................51 Optimisation logicielle.......................................................................................................52 Les machines virtuelles pour les terminaux mobiles..........................................52 La machine virtuelle KVM..................................................................................53 Conclusion..........................................................................................................................54 Optimisation de l’application..................................................................55 Les limitations sur CLDC / KVM.............................................................56 Conclusion................................................................................................59 Livre blanc de J2ME Bruno Delb • iii Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 6. 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 : 200 200 200 200 2004 0 1 2 3 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 0,3 0,9 1,7 2,6 3 jeux 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) Les freins au développement Les freins au développement de la mobilité sont nombreux : Livre blanc de J2ME Bruno Delb • 5 Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 7. Frein Description Ergonomie des • Trop petit taille des écrans terminaux • 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 • Temps d’établissement de la connexion trop qualité de service long (le GPRS possède une connexion insuffisants 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 • Facturation au volume de données, à l’acte de communication d’usage ou forfaitaire possibles avec l’arrivée du GPRS Manque de service et • Tests insuffisants sur les terminaux de contenus de qualité Les enjeux Les 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 Delb Livre blanc de J2ME Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 8. 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 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. Livre blanc de J2ME Bruno Delb • 7 Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 9. 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 virtuelles Au 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. 8 • Bruno Delb Livre blanc de J2ME Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 10. Les configurations J2ME 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 profils J2ME 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. 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 Livre blanc de J2ME Bruno Delb • 9 Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 11. 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. Les autres API de J2ME Parmi 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é. 10 • Bruno Delb Livre blanc de J2ME Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 12. 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. 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. Livre blanc de J2ME Bruno Delb • 11 Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 13. 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() 12 • Bruno Delb Livre blanc de J2ME Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 14. 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. J2EE J2SE J2ME EJB Servlet Personal RMI JSP Profile Profile JDBC MIDP PDAP Foundation Profile JMS CLDC CDC JCA SDK KVM CVM APIs du noyau APIs du noyau APIs du noyau APIs du noyau Langage Java Livre blanc de J2ME Bruno Delb • 13 Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 15. 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 128 à 512 Ko (RAM + 1 Mo (ROM) + 512 Ko mémoire ROM) (RAM) Processeur 16 ou 32 bits 32 bits Réseau Faible bande passante ou Connexion réseau faible qualité de service du 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 configurations J2ME 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. 14 • Bruno Delb Livre blanc de J2ME Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 16. 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 profils J2ME 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) Livre blanc de J2ME Bruno Delb • 15 Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 17. 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. • Les MIDlets peuvent fournit des conseils sémantiques (comme retour). 16 • Bruno Delb Livre blanc de J2ME Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 18. 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. Livre blanc de J2ME Bruno Delb • 17 Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 19. 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'API Le package java.lang est un sous-ensemble des classes standards du package java.lang de J2SE. Un absent de marque, toutefois : la classe Float. En effet, MIDP ne supporte pas les calculs en virgule flottante ! Vous devrez donc faire sans ou les émuler. Le package java.io contient les méthodes nécessaires pour récupérer des informations des systèmes distants. Le package java.util contient un petit sous-ensemble du package correspondant de J2SE, dont voici les classes retenues : Calendar, Date, TimeZone, Enumeration, Vector, Stack, Hashtable et Random. Le principal objet du package javax.microedition.io est la classe Connector. Nous reviendrons plus longuement sur celle-ci dans la partie traitant de la connexion réseau. Le package javax.microedition.ui permet de définir l'interface utilisateur. Le package javax.microedition.rms implémente le système de stockage persistent, que nous aller traiter plus loin dans l'article. Le package javax.microedition.midlet contient la classe MIDlet. C'est elle qui exécute le cycle de vie du MIDlet. Elle fournit en outre la méthode getAppProperty(key) qui permet de récupérer les informations des propriétés de l'application placées dans le fichier jad associé au MIDlet. 18 • Bruno Delb Livre blanc de J2ME Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 20. L'interface utilisateur MIDP est conçu pour tourner sur de nombreux types de terminaux : téléphones, Palm Pilot, … Or la plupart de ces terminaux sans fil sont utilisés dans la main, disposent d'un petit écran et tous ne possèdent pas de système de pointage comme un stylo. Tout en respectant ces contraintes, les applications MIDP doivent intégrer toujours les mêmes fonctionnalités quelque soit le terminal. La solution a été de décomposer l'interface utilisateur en deux couches : l'API de haut niveau et celle de bas niveau. La première favorise la portabilité, la second l'exploitation de toutes les fonctionnalités du terminal. Le concepteur doit donc faire un compromis entre portabilité et bénéfice des particularités du terminal. L'API de bas niveau donne accès direct à l'écran du terminal et aux événements associés aux touches et système de pointage. Aucun composant d'interface utilisateur n'est disponible : vous devez explicitement dessiner chaque composant, y compris les commandes. L'API de haut niveau fournit quant à elle des composants d'interface utilisateur simples. Mais aucun accès direct à l'écran ou aux événements de saisie n'est permis. C'est l'implémentation MIDP qui décide de la manière de représenter les composants et du mécanisme de gestion des saisies de l'utilisateur. Il est possible d'utiliser l'API de haut niveau et l'API de bas niveau dans un même MIDlet mais pas simultanément. Par exemple, les jeux qui utilisent l'API de bas niveau pour contrôler l'écran peuvent aussi utiliser l'API de haut niveau pour afficher les meilleurs scores. L'API de bas niveau peut aussi être utilisée pour tracer des graphes. 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é. 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 Livre blanc de J2ME Bruno Delb • 19 Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 21. 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. La gestion des événements La classe Canvas est une sous-classe de la classe Displayable. Elle permet d'enregistrer un listener de commandes. Il est cependant préalablement nécessaire de créer plusieurs interfaces listener, chacune étant associée à un type d'événement. 20 • Bruno Delb Livre blanc de J2ME Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 22. 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 persistent RMS (Record Management System) est une API de stockage persistent sur le terminal. C'est en quelque sorte une base de données indépendante du terminal. Chaque enregistrement est représenté sous forme de tableau d'octets. La mise est jour est dite atomique : l'enregistrement entier est réécrit à chaque fois. Les enregistrements sont stockés dans ce que l'on appelle un Record store. Si l'on veut faire un parallèle avec les SGBD relationnels, RMS correspond au SGBD lui-même et le Record store à la table. D'ailleurs, le parallèle de la notion de clé primaire des bases de données relationnelles est le recordID. Il s'agit de l'identifiant de l'enregistrement. C'est un nombre entier. La valeur de l'ID du premier enregistrement est 1 et chaque nouvel enregistrement a une valeur ID augmentée de un. Plusieurs méthodes permettent de gérer les Records store. openRecordStore et closeRecordStore permettent respectivement d'ouvrir et de fermer un Record store. La liste de tous les Record store peut être obtenue par listRecordStore. deleteRecordStore en supprime un. Le nombre d'enregistrements dans un Record store est retourné par getNumRecords. Les opérations de base sur les enregistrements sont assurées par ces méthodes : addRecord (ajout), deleteRecord (suppression), getRecord (lecture), setRecord (modification), getRecordSize (taille de l'enregistrement). L'API RMS dispose cependant de quelques particularités supplémentaires, concernant la sélection des enregistrements. La première est l'utilisation de la méthode RecordEnumeration pour lister tous les enregistrements du Record store. La seconde est la possibilité de définir un filtre avec la méthode RecordFilter. Enfin, l'interface RecordComparator doit être implémentée pour que des enregistrements puissent être comparés et donc triés. Livre blanc de J2ME Bruno Delb • 21 Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 23. Le réseau Avec plus de 100 classes, l'API de J2EE dédiée au réseau, aux entrées / sorties et au stockage est beaucoup trop lourde que celle utilisée pour les terminaux CLDC. Elle est remplacée dans la CLDC par le GCF (Generic Connection Framework). Le GCF assure une plus grande cohérence entre les différents types d'entrées / sorties tout en améliorant la portabilité des applications. Le GCF Le GCF fournit un moyen uniforme et pratique d'effectuer des entrées / sorties quelque soit le type de protocole. La syntaxe générale est la suivante : Connector.open("<protocole>://<adresse>:<parametres>"); Plusieurs protocoles sont utilisables. 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é. 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 exemple Comme 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 22 • Bruno Delb Livre blanc de J2ME Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 24. 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: 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: } Livre blanc de J2ME Bruno Delb • 23 Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 25. 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. 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). 24 • Bruno Delb Livre blanc de J2ME Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 26. 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. 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. La gestion des événements 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). Livre blanc de J2ME Bruno Delb • 25 Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 27. 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és Les nouvelles fonctionnalités de MIDP 2.0 sont : • Nouveau modèle de sécurité avec les MIDlets certifiées • HTTPS • 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 26 • Bruno Delb Livre blanc de J2ME Email : edition@brunodelb.com Web : http://www.brunodelb.com
  • 28. 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. 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. Livre blanc de J2ME Bruno Delb • 27 Email : edition@brunodelb.com Web : http://www.brunodelb.com