Université Joseph Fourier

PolyTech & IMA

Année Universitaire 2004-2005

RICM3 SR & M2GI SRR

Communications Mobiles

 

Concepteur :                    Didier DONSEZ <didier.donsez@imag.fr>

But :                     Manipuler J2ME/CLDC/MIDP

Pratique de J2ME

Date de dernière mise à jour : 4/02/2005

 

Le but de ce TD est de tester l’environnement J2ME/CLDC/MIDP 1.0 et 2.0.

Installation du J2ME Wireless Toolkit

Normalement, vous téléchargez de du site http://java.sun.com/j2me et l’installer.

Cependant vous n’avez qu’à décompresser le fichier suivant dans C:\tmp :

http://www-adele.imag.fr/~donsez/cm/wtk104.zip

http://www-adele.imag.fr/~donsez/cm/wtk22.zip

Configurez JAVA_HOME et ANT_HOME

Configurez WTK_HOME (set WTK_HOME=C:\TEMP\WTK22 pour la version 2.2 du toolkit)

Configurez WTK_HOME (set WTK_HOME=C:\TEMP\WTK104 pour la version 1.0.4 du toolkit)

Ajoutez %WTK_HOME%\bin à votre PATH

 

Les commandes suivantes vous permettent de :

 

La documentation est accessible depuis %WTK_HOME%\index.html

Le guide d’utilisation est accessible depuis %WTK_HOME%\docs\UserGuide.pdf

Remarque 1

Les constructeurs de télé phones cellulaires tels que Nokia, SonyEricsson, Siemens, … proposent le téléchargement de Toolkit J2ME sur leurs sites « developer ». Ils contiennent également des émulations de téléphone réels et de nombreux exemples illustrant plusieurs JSR et des API propriétaires. Ces toolkits permettent de développer des Midlets (pas toujours portables si les API propriétaires sont utilisées) et de les charger sur des vrais téléphones afin de les exécuter « in-vivo » et de les débogger « in-vivo ».

Remarque 2

Si vous possédez un téléphone Java (ou plus exactement J2ME/CLDC/MIDP), vous avez intéressé de tester les MIDlets que vous développerez sur votre téléphone (c’est toujours bon pour le CV). Il faudra de préférence récupérer le Toolkit (s’il existe).

Des listes (incomplète) de téléphone Java se trouvent sur

Attention, Si votre téléphone est MIDP1.1, il faudra que la suite de MIDLet que vous développerez soit également MIDP1.0 ou MIDP1.1 (MicroEdition-Profile: MIDP-1.0).

Remarque 3

DoJa est un profile basé sur le J2ME/CDLC/MIDP pour les téléphones mobiles Docomo iMode comme ceux de l’opérateur Bouygues Telecom.

Vous pouvez télécharger et installer le kit de développement et d’émulation DoJa.

Remarque 4

D’autres exemples de midlets (1.0 et 2.0) sont disponibles sur

http://www-adele.imag.fr/~donsez/cours/exemplesj2me/

Chargez les dans votre répertoire %WTK_HOME%\apps

Documentation

Prise en main i

Lancez ktoolbar

Ouvrez un des projets (games par exemple)

Les projets (présents dans %WTK_HOME%\apps) sont brièvement décrit dans %WTK_HOME%\docs\AppDemos.html

Construisez le [Build]

Exécutez le [Run] et testez l’interface homme-machine (L’émulateur que vous avez choisi est lancé avec les MIDlets du projet)

Visualisez les 2 scripts build.sh et run.sh dans du répertoire %WTK_HOME%\apps\*\bin\

Certains applications ont des scripts ANT !

Profilage et supervision (monitoring)

Configurez dans [menu Edit>Preferences, onglet Monitor] :

·       La supervision de l’utilisation de la mémoire

·       La supervision des échanges réseau

·       Le profilage des méthodes appelées

Recommencez l’exécution de la MIDlet précédente.

Question : que configurent les autres onglets de [menu Edit>Preferences]

NB : la supervision de l’utilisation de la mémoire ralentit énormément la simulation ! désactivez la pour la suite

Prise en main ii

Lancez l’émulateur avec un des .jad situé dans %WTK_HOME%\apps\*\bin\

(voir les options de lancement dans le chapitre 4 du UserGuide).

Développement

Lancez ktoolbar

Créez [New Project] un nouveau projet hello avec la classe examples.hello.HelloMIDlet

Configurez [Settings] la MIDlet et notamment son icône /examples/hello/icon/hello.png

Générez [Build] les classes

Exécutez dans le simulateur [Run]

Exécutez avec un autre mobile (device)

Procédez de même avec animation, addressbook, http, xml (attention, l’exemple xml nécessite les packages de kXML (http://www.kxml.org)

Utilisez un ofuscateur pour reduire la taille des MIDlets

Aidez vous de la documentation %WTK_HOME%\index.html

Débogage

Lancez ktoolbar

Ouvrez le projet addressbook

Positionnez l’option de deboggage [Project>Debug]

Reconstruisez le projet

Lancez l’application [Run]

Lancez le déboggeur jdb sur le port de deboggage

jdb -connect com.sun.jdi.SocketAttach:hostname=localhost,port=5000 \

 –sourcepath %WTK_HOME%\apps\addressbook\src

Aidez vous de la documentation de jdb

Vous pouvez également lancer le déboggeur depuis votre IDE.

Développement suite

Regroupez les 4 exemples précédents sous un seul projet total qui contiendra les 4 MIDlets.

Ecrivez un script (build.sh, build.bat ou build.xml) qui construit total.jar

Configurez le fichier total.jad avec ktoolbar

Testez [Run]

Déploiement par un serveur Web

Installez total.jar et total.jad dans une webapp midlets d’un serveur J2EE (TomCat ou JOnAS par exemple)

Changez la propriété MIDlet-Jar-URL de total.jad avec l’URL absolu de JAR http://monserverweb:8080/midlets/total.jar

Assurez vous que webapps/midlets/WEB-INF/web.xml contiennent les correspondances suivantes pour les types MIME (sinon ajoutez les).

jad     text/vnd.sun.j2me.app-descriptor

jar     application/java-archive

 

Lancez l’émulateur sans passer par ktoolbar avec la commande suivante :

    emulator –Xdescriptor:http://monserverweb:8080/midlets/total.jad

Installez les MIDlets sur l’émulateur en passant l’URL absolue de total.jad

    emulator –Xjam:install=http://monserverweb:8080/midlets/total.jad

Vous pouvez changer le device avec la commande suivante DefaultDevice

Vous pouvez également le tester sur un vrai téléphone si le serveur d’hébergement et accessible par le Web.

Développement J2ME - J2EE Hall of Fame pour Worm

L’objectif de cet exercice est de réaliser un « Hall of Fame » (tableau des meilleurs scores) global pour le jeu Worm qui est disponible dans la démo games du WTK.

Pour cela, vous devez premièrement

·       développer une JSP halloffame.jsp dans votre webapp midlets qui enregistre (dans un ListArray non persistent) un nouveau score (c.a.d le n-uplet <gameid,score,pseudo,ipaddress>), calcule son rang (rank) parmi les scores des autres joueurs et retourne le Hall of Fame aux formats WML, xHTML, HTML, CSV, SOAP XML en fonction du paramêtre mimetype ou en fonction du champs Accept :.

·       modifier la midlet example.wormgame.WormMain pour pour que le joueur saisisse son pseudo (qui est rendu persistant avec le RMS) puis envoie (par HTTP) le score à la JSP halloffame.jsp. récupère la tête du tableau (au format CSV ou SOAP XML (voir le chapitre 12 « Using Web Services » du UserGuide ou le JSR172)) et l’affiche au joueur en jouant également une mélodie.

·       modifier le games.jad pour l’entrée GAMES_HALLOFFAME_URL (ex : http://centralgame.groland-telecom.com/midlets/halloffame.jsp) permette de paramétrer l’url de halloffame.jsp. Remarque : on pourrait y ajouter le pseudo de l’utilisateur GAMES_PSEUDO quand il s’inscrit sur le site, le numéro de licence GAMES_LICENCE pour restreindre l’usage illicite ou profiter pleinement des niveaux de jeux , …

·       écrire un document WML ou xHTML contenant une ancre référençant le games.jad pour inciter l’usager (ie client) à installer la suite de midlets sur son téléphone. Ce document est généralement accessible depuis le portail (première page) de l’opérateur de l’usager.

 

Remarque : le format CSV (Comma-Separated Value) qui est un format d’import/export entre tableurs, formate un enregistrement sur une ligne de texte et sépare les champs par le caractère ; . La classe java.util.StringTokenizer peut vous aider à récupérer les champs individuellement.

Un exemple de CSV retourné par halloffame.jsp

Type MIME : text/csv, application/csv, application/x-csv voir http://www.geocities.com/dtmcbride/tech/filetype.html

gameid;rank;ipaddress;pseudo;score;timestamp

worm;1;-;Didier (Grenoble);1203;34662829983837

worm;2;-;Humberto (Mexico);1010;3466282995635

worm;3;-;Rick (Chicago);760;34610020300333

worm;236;192.178.230.100;Toto (Petäouchsnock);210;34772829983837

 

Questions:

·       pourquoi le champ gameid est il utile ?

·       pourquoi l’adresse ip n’est elle pas fournie pour les enregistrements qui concerne les autres joueurs ?

 

Profitez de l’occasion pour faire en sorte que halloffame.jsp puisse retourner le tableau en xHTML ou en WML !

 

Enfin, créez une JSP games.jad.jsp qui retourne le JAD avec l’entrée GAMES_HALLOFFAME_URL configurée dynamiquement avec l’adresse du serveur. Remarque : cette JSP retourne le type MIME text/vnd.sun.j2me.app-descriptor.

Développement J2ME - J2EE dans eCOM

L’objectif de cet exercice est d’ajouter à votre site de commerce électronique eCOM que vous avez développé d’Octobre à Décembre, la possibilité d’accepter des clients J2ME/CDLC/MIDP !

Quel peut être l’intérêt d’utiliser J2ME plutôt que WAP/WML pour ce type d’application ?

Basez vous sur le code de examples.http.DownloadMIDlet pour écrire une MIDlet ecom.midlet.EcomMIDlet (et la servlet correspondante) qui consulte les catalogues des magasins du projet Ecom.

Complétez EcomMIDlet pour qu’elle puisse constituer un caddie embarqué (géré au niveau du terminal).

Modifiez EcomMIDlet pour qu’elle envoie le contenu du caddie à la servlet ProcessCartServlet sous la forme d’un document XML (HTTP POST))

Modifiez EcomMIDlet pour qu’elle envoie le contenu du caddie à la servlet ProcessCartServlet sous la forme d’un document SOAP/HTTP

Ecrivez la servlet ProcessCartServlet qui reçoit toutes les entrées du caddie et procède au paiement du caddie.

Jeu de la Vie (Automate cellulaire de Conway)

Ecrire une MIDlet ConwayMIDlet réalisant une animation basée sur le jeu de la vie.

Rappel des règles de Conway:

·       Une cellule se crée s’il y a 3 cellules voisines (parmi 8)

·       Une cellule reste vivante s’il y a 2 ou 3 voisines

·       Sinon elle meurt

Remarque : plusieurs contenants (collection) peuvent être utilisés : HashMap, Array, Tree, LinkedList, … pour représenter la population avec des performances et des consommations mémoire variables ! Quel contenant choisir ?

Vous étudierez les performances au moyen du profiler du J2MESDK

Indications : lire Jonathan Allin, Wireless Java for Symbian Devices, http://www.symbian.org/books

et http://servlet.java.sun.com/javaone/resources/content/sf2002/conf/sessions/pdfs/1022.pdf page 46

Remarque : le WTK2.2 inclut maintenant un jeu de la vie en 3D pour la démonstration de Java3D.

Annexe A : Emulation PalmOS

(sous Windows seulement et avec WTK 1.0.4)

Installation de POSE

Vous téléchargez l’émulateur Palm OS (POSE)  http://www.palmos.com/dev/tech/tools/emulator/ sur le site développeur http://www.palmsource.com/developers/

Sous Windows, exécutez l’émulateur POSE/PalmOS-Emulator.exe

Appuyez sur New pour démarrer une nouvelle session d’émulation.

Récupérez l’image de la ROM de votre Palm ou téléchargez sur le site développeur.

Configurez le POSE avec la ROM récupérée.

Désactivez toutes les options de deboggage dans le « menu bouton droit> Settings > Debug Options »

MIDlet sur émulateur POSE

Lancez ktoolbar.bat

Ouvrez un projet (demos)

Sélectionnez le device PalmOS_device puis lancez [Run]

Indiquez l’exécutable /PALM/POSE/PalmOS-Emulator.exe

Testez la MIDlet

Annexe B : Mini-Projet « MiniPIM »

Remarque : ce projet n’est plus d’actualité depuis l’introduction de l’API PIM (JSR75) décrit dans le chapitre 10 « Using the PIM and FileConnection APIs » du UserGuide. L’exemple « PDAPDemo » illustre l’utilisation de cette API.

 

PIM est l’acronyme de Personal Information Manager. C’est un ensemble d’applications de base des terminaux nomades. Cet ensemble inclut généralement : un carnet d’adresse, un agenda, un bloc note, un gestionnaire de mots de passe, …)

Dans ce mini-projet, vous développerez l’application de carnet d’adresse.

Vous pourrez partir de l’exemple AddressBook étudié précédemment

Etape 1 : Les entrées du carnet

Cette étape consiste à visualiser/ajouter les entrées du carnet.

Chaque entrée a plusieurs champs qui peuvent être multivalués (exemple : plusieurs numéros de téléphone). Des champs de bases (firstname, lastname, phone, gsm, address, city, zipcode, country) sont prédéfinis cependant l’utilisateur peut en ajouter. Tous les champs sont de type texte .

Etape 2 : Recherche et Filtres (dépendance 1)

Cette étape consiste à rechercher les entrées du carnet sur plusieurs critères.

La recherche utilise des filtres simples (débute par la sous-chaîne, contient la sous-chaîne, tous les champs, un de ces champs).

Les filtres sont mémorisables. (exemple : filtre sur le category=friend)

Etape 3 : Appel à des applications tiers (dépendance 1)

Certains champs (quand ils sont sélectionnés, peuvent être associés à des commandes particulières (autre que Full Display, Edit). Par exemple : le champ phone ajoute la commande Call qui en principe appèle l’application de téléphonie. Le champ gsm ajoute la commande Call et la commande SMS qui en principe appèle l’application de rédaction et d’envoie de SMS. Le champ url ajoute la commande Browse qui en principe appèle le navigateur.

Vous n’effectuerez l’appel réel aux applications-tierces.

Etape 4 : La sécurisation des entrées (dépendance 1)

Cette étape consiste à protéger les entrées du carnet par un mot de passe. Vous utiliserez pour cela des moyens cryptographiques (voir exemple crypto)

Vous pourrez étendre la classe RecordStore par une classe SecureRecordStore qui s’initialise avec un encrypteur et un décrypteur générique. Utilisez l’instanciation retardée de l’encrypteur/decrypteur.

Etape 5 : Le déchargement (ou export) (dépendance 1)

Cette étape consiste à exporter le contenu des entrées du carnet vers une servlet. Vous definirez une DTD XML pour le format du document à exporter. Vous utilisez la méthode POST pour envoyer ce document à la servlet AddressBookServlet. Ecrivez la servlet AddressBookServlet. Remarque : la servlet gère plusieurs carnets d’adresses. Le carnet est sélectionné après authentification simple.

Etape 6 : Le chargement (ou import) (dépendance 1)

Cette étape consiste à importer des entrées dans le carnet, chargées depuis une servlet. Vous définirez une DTD XML pour le format du document à importer (il peut être identique à celui de l’import). Comme il peut y avoir des conflits avec les entrées déjà présentes dans le carnet, définissez les champs qui forment la clé des entrées et proposez plusieurs politiques d’importation (Remise à zéro, Remplacement, Fusion, Abandon de l’entrée). Vous utilisez la méthode GET pour recevoir ce document à la servlet AddressBookServlet. Completez la servlet AddressBookServlet.

Etape 7 : La synchronisation (dépendance 5 et 6)

Cette étape consiste à synchroniser les entrées dans le carnet et celui géré par la servlet AddressBookServlet. Vous pourrez vous inspirer de SyncML (http://www.syncml.org) et lire « Sync or Sink--Synchronizing Data Between Clients Based on the JavaTM 2 Platform, Micro Edition (J2METM) and Servers Based on the Java 2 Platform, Enterprise Edition (J2EETM) " http://servlet.java.sun.com/javaone/resources/content/sf2002/conf/sessions/pdfs/1812.pdf. et utiliser kSync (http://ksync.enhydra.org). Complétez la servlet AddressBookServlet. Utilisez un drapeau de synchronisation sur les entrées indiquant que ces dernières ont été modifiées depuis la dernière synchronisation. Définissez les politiques de règlements de conflits qui seront appliqués bilatéralement.