La télécommunication a permis d’effacer les distances entre des personnes qui souhaitent se communiquer. En effet, Alexander Graham Bell, né en 1847 a inventé le téléphone en 1876 : c’est la première communication moderne reliant deux postes fixes par une paire de fil mise en place par Thomas Doolittle. Cependant la technologie ne cesse d’évoluer et le téléphone fixe domine le monde sauf dans les pays en voie de développement comme Madagascar. Chez nous, les principaux abonnés étaient les entreprises, mais depuis les années 90, des abonnés particuliers hébergent le téléphone chez eux pour les raisons familiales. Malgré l’insatisfaction des clients sur l’incapacité de portabilité, les opérateurs mobiles apparaissent progressivement sur le marché public au début de la vingt unième siècle. Le dernier modèle vient de perdre sa popularité et les utilisateurs font recours à l’usage des téléphones mobiles qui deviennent un outil nécessaire à la vie quotidienne des Malagasy. Ce produit attire presque la majorité des citadins pour certaines raisons particulières tel que sa portabilité, la facilité d’envoyer les donnés (parole, message). A son apparition, les téléphones portables ont été limités à des affichages simplistes, quelques lignes de texte avec un fond gris et quatre couleurs. L’évolution technologique fait qu’aujourd’hui, des téléphones plus puissants, avec plus de mémoire, un meilleur affichage et une résolution élevée apparaissent avec un prix abordable.
J2ME : PRESENTATION GENERALE
J2ME est la plateforme Java utilisée pour le développement des applications sur des appareils mobiles tel que des PDA (Personal Digital Assistant), des téléphones cellulaires, des terminaux de points de vente, des systèmes de navigations pour voiture, etc. C’est une sorte de retour aux sources, puisque Java avait été initialement développé pour piloter des appareils électroniques. A vraie dire, J2ME signifie Java pour les petits appareils.
Historiquement, Sun a proposé plusieurs plateformes pour le développement d’applications sur des machines possédant des ressources réduites, typiquement les machines ne pouvant exécuter une JVM (Java Virtual Machine) répondant aux spécifications complètes de la plateforme J2SE telles que:
– JavaCard : pour le développement sur des cartes à puces.
– EmbeddedJava : pour le développement des systèmes embarqués.
– PersonnalJava : pour le développement sur des machines possédant au moins 2Mo de mémoire.
En 1999, Sun propose de mieux structurer ces différentes spécifications sous l’appellation J2ME. Seule la spécification JavaCard n’est pas incluse dans J2ME et reste une spécification à part. Par rapport à J2SE, J2ME utilise des machines virtuelles différentes. Certaines classes de base de l’API sont communes, mais cependant, de nombreuses fonctions sont omises dans l’API de la dernière. L’ensemble des appareils sur lequel peut s’exécuter une application écrite avec J2ME est tellement vaste et disparate que J2ME est composée de plusieurs parties : les configurations et les profils qui sont spécifiés par le JCP (Java Community Process). J2ME se base alors sur une architecture modulaire. Chaque configuration peut être utilisée avec un ensemble de packages optionnels qui permet d’utiliser des technologies particulières. Ces packages sont le plus souvent dépendant du matériel.
L’inconvénient de ce principe de packaging est qu’il déroge à la devise de Java « Write Once, Run Anywhere ». Ceci reste cependant partiellement vrai pour des applications développées pour un profil particulier. Il ne faut cependant pas oublier que les types de machines cibles de J2ME sont tellement différents du téléphone mobile au set top box , qu’il est sûrement impossible de trouver un dénominateur commun. Ceci est associé à l’explosion du marché des machines mobiles expliquant les nombreuses évolutions en cours de la plateforme. Jusqu’ici c’est la J2ME qui est la plateforme objet de fréquente mise à jour.
Les configurations de J2ME
Les configurations définissent les caractéristiques de bases d’un environnement d’exécution pour un certain type de machine, possédant un ensemble de caractéristiques et de ressources similaires. Elles se composent d’une machine virtuelle et d’un ensemble d’API de base.
Deux configurations sont actuellement définies :
– CLDC (Connected Limited Device Configuration).
– CDC (Connected Device Configuration).
CLDC
La CLDC 1.0 est spécifiée dans la JSR 030 (Java Specification Request 030) : elle concerne des appareils possédant des ressources faibles (moins de 512 Kb de RAM, faible vitesse du processeur, connexion réseau limitée et intermittente) et une interface utilisateur réduite (par exemple un téléphone mobile ou un PDA « bas de gamme »). Elle s’utilise sur une machine virtuelle KVM (Kilobyte Virtual Machine). La version 1.1 est le résultat des spécifications de la JSR 139 : une des améliorations les plus importantes est le support des nombres flottants.
CDC
La CDC est spécifiée dans la JSR 036 : elle concerne des appareils possédant des ressources plus importantes (au moins 2Mb de RAM, un processeur 32 bits, une meilleure connexion au réseau), par exemple un set top box ou certains PDA « haut de gamme ». Elle s’utilise sur une machine virtuelle CVM (Compact Virtual Machine).
Remarque
La CLDC et la CDC sont deux configurations différentes et indépendantes et ne peuvent pas être utilisées en même temps. La figure suivante montre cette propriété. La CLCD n’est ni un sousensemble de la plateforme J2SE (développement standard) ni un sous-ensemble de la configuration CDC.
Le PersonalJava est alors remplacé par le Personal Profile. Le choix du ou des profils utilisés pour les développements est important car il conditionne l’exécution de l’application sur un type de machine supporté par le profil. Cette multitude de profils peut engendrer un certain nombre de problème lors de l’exécution d’une application sur différents périphériques car il n’y a pas la certitude d’avoir à disposition les profils nécessaires. Pour résoudre ce problème, une spécification particulière issue des travaux de la JSR 185 et nommée JTWI (Java Technology for the Wireless Industry) a été développée. Cette spécification impose aux périphériques qui la respectent de mettre en œuvres au minimum : CLDC 1.0, MIDP 2.0, Wireless Messaging API 1.1 et Mobile Media API 1.1. Son but est donc d’assumer une meilleure compatibilité entre les applications et les différents téléphones mobiles sur lesquelles elles s’exécutent.
DEVELOPPEMENT D’UNE APPLICATION EN J2ME
C’est le premier profil qui a été développé dont l’objectif principal est le développement d’application sur des machines aux ressources et à l’interface limitées tel qu’un téléphone cellulaire. Ce profil peut aussi être utilisé pour développer des applications sur des PDA de type Palm.
L’API du MIDP 1.0 se compose des API du CDLC et de trois packages :
– javax.microedition.midlet : cycle de vie de l’application
– javax.microedition.lcdui : interface homme machine
– javax.microedition.rms : persistance des données .
Les Midlets
Les applications créées avec MIDP sont des Midlets : ce sont des classes qui héritent de la classe abstraite javax.microedition.midlet.Midlet. Cette classe permet le dialogue entre le système et l’application. Elle possède trois méthodes qui permettent de gérer le cycle de vie de l’application en fonction des états possibles: startApp(), pauseApp(), destroyApp().
|
Table des matières
INTRODUCTION
CHAPITRE 1 J2ME : PRESENTATION GENERALE
1.1. Introduction
1.2. Les configurations de J2ME
1.2.1. CLDC
1.2.2. CDC
1.2.3. Remarque
1.3. Les profils
1.4. J2ME en bref
CHAPITRE 2 MIDP : DEVELOPPEMENT D’UNE APPLICATION EN J2ME
2.1. Les Midlets
2.2. Les interfaces utilisateurs
2.2.1. La classe Display
2.2.2. La classe TextBox
2.2.3. La classe List
2.2.4. La classe Form
2.2.5. La classe Item
2.2.6. La classe Alert
2.3. La gestion des événements
2.4. Le Stockage et la gestion des données
2.5. Packager une midlet
2.5.1. Le fichier manifest
2.6. Evolution de MIDP et ses nouvelles options
2.6.1. Introduction
2.6.2. Service de messagerie (SMS)
2.6.2.1. Généralité
2.6.2.2. Utilisation dans J2ME
2.6.2.3. Numéro de port
2.6.2.4. Réception de message
2.6.3. Multimédia
2.6.3.1. Mobile Media API
2.6.3.2. Gestion et traitement du contenu
2.6.3.3. La classe Manager
2.6.3.4. La classe Player
2.6.3.5. Snapshot
2.7. Outils de développement de MIDP
CHAPITRE 3 REALISATION
3.1. Objectif de la conception
3.2. Langage de programmation
3.2.1. Présentation du langage Java
3.2.2. Justification du choix du langage
3.3. Outil de simulation du terminal mobile
3.3.1. Installation
3.3.2. Développement d’une Midlet avec le logiciel
3.3.2.1. Les projets
3.3.2.2. L’emplacement des fichiers
3.3.2.3. Cycle simple de développement d’une MIDlet
3.3.2.4. Cycle de développement complet d’une MIDlet
3.4. Déploiement d’une MIDlet sur un terminal mobile
3.5. Les menus offerts à l’utilisateur
3.5.1. Aide
3.5.2. Bonus
3.5.3. Clip
3.5.4. Configuration
3.5.5. Jeux
3.5.6. Journal
3.5.7. Message
3.5.8. Musique
3.5.9. Répertoire
3.5.10. Sonnerie
3.6. Organigrammes des menus
3.7. Manipulation de l’application (Résumé)
3.7.1. Aide
3.7.2 Bonus
3.7.2.1. Calculatrice
3.7.2.2. Calendrier
3.7.3. Clip
3.7.4. Configuration
3.7.5. Jeux
3.7.6. Journal
3.7.7. Message
3.7.8. Musique
3.7.9. Répertoire
3.7.10. Sonnerie
CONCLUSION
Télécharger le rapport complet