Clients mobiles

1. Clients mobiles J2ME Java Micro-Edition

2. Plan • Pourquoi J2ME ? • L’architecture de J2ME • Configurations • Profils • Packages optionnels • Modèles d’application • Le modèle traditionnel • Les applets • Les midlets • Les PDAlets • Les Xlets

3. Evolution • « Write once, run anywhere » • « Java everywhere » • Trouver un équilibre • portabilité  performance et faisabilité

4. L’architecture de J2ME

5. J2ME et J2SE • J2ME vs J2SE, • des machines virtuelles différentes. • certaines classes de base de l'API sont communes • de nombreuses omissions dans l'API J2ME. • L'ensemble des appareils sur lequel peut s'exécuter une application écrite avec J2ME est tellement vaste et disparate que J2ME est composé de plusieurs parties : • les configurations et les profils • J2ME propose donc une architecture modulaire. • Chaque configuration peut être utilisée avec un ensemble de packages optionnels • utiliser des technologies particulières (Bluetooth, services web, lecteur de codes barre, etc ...). • ces packages sont le plus souvent dépendant du matériel. • dérogation à la devise de Java "Write Once, Run Anywhere". • reste cependant partiellement vrai pour des applications développées pour un profil particulier.

6. Des configurations et des profils • Configuration + Profil ---> un type spécifique d’appareils • Configuration • Fournir les fonctionnalités les plus génériques et/ou les plus indispensables • Profil • S’appuie sur les configurations • supporte des APIs plus avancées • Package optionnel • Disponibles en complément des profils standards • Toujours utilisé en conjonction avec une configuration ou un profil • ne définit pas un environnement complet pour une application (contrairement à un profil) • Étendre l’environnement d’exécution pour supporter des fonctionnalités des appareils • qui ne sont pas suffisamment universelles pour être définie dans un profil • qui peuvent être partagées par différents profils • Pour combler des besoins spécifiques d’une application • e.g. communication Bluetooth

8. Les configurations • 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. • Une machine virtuelle + un ensemble d'API de base. • Deux configurations • CLDC (Connected Limited Device Configuration) • des appareils possédant • des ressources faibles • moins de 512 Kb de RAM, faible vitesse du processeur, connexion réseau limitée et intermittente • une interface utilisateur réduite (par exemple un téléphone mobile ou un PDA "bas de gamme"). • machine virtuelle KVM. • La version 1.1 : ajout du support des nombres flottants + autres. • CDC (Connected Device Configuration). • des appareils possédant des ressources plus importantes • au moins 2Mb de RAM, un processeur 32 bits, une meilleure connexion au réseau • un settop box ou certains PDA "haut de gamme". • Elle s'utilise sur une machine virtuelle JVM. • Dernière version : August 3, 2006 (JSR 218 (CDC 1.1.2)).

9. Les profils • Les profils • un ensemble d'API particulières à un type de machines ou à une fonctionnalité spécifique. • permettent l'utilisation de fonctionnalités précises • doivent être associés à une configuration. • Ils permettent donc d'assurer une certaine modularité à la plate-forme J2ME. • 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 Java Technology for the Wireless Industry (JTWI) a été développée. • Cette spécification impose aux périphériques qui la respectent de mettre en oeuvre 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.

10. Configuration for Small Devices - The Connected Limited Device Configuration (CLDC) • Configuration • CLDC 1.1 • Profils • Mobile Information Device Profile MIDP 2.0 • un profil standard • pas défini pour une machine particulière • pour un ensemble de machines embarquées possédant des ressources et une interface graphique limitée. • Exemples de packages optionnels • Wireless Messaging API (WMA) • envoyer et recevoir des messages SMS, MMS • Mobile Media API (MMAPI), API multimédia • DOJA, un profil pour iMode • Prise en charge du stockage permanent • Prise en charge des données multimédias • Activation automatique d’application • Sécurité optimisée des données

11. CLDC 1.1. API

12. Mobile Information Device Profile MIDP 2.0

13. Connected Device Configuration • Pour les appareils qui exigent • Une implémentation complète de la JVM • Une API qui peut, via l’addition de profils, inclure l’API complète de J2SE • Une implémentation caractéristique n’utilisera par contre qu’un sous-ensemble de ces APIS en fonction du profil supporté

14. Connected Device Configuration

15. Les profils associés à CDC • Foundation Profile, version 1.1.2 • Ce profil ne permet pas de développer des IHM. • Il faut lui associer un des deux profils suivants : • Personal Basic Profile • Personal Profile est un profil qui. • Personal Basis Profile • permet le développement d'application connectée avec le réseau • fournit un environnement d’application pour les applications utilisant AWT qui ne reposent que sur les composantes légères (lightweight). • AWT de base à l’exclusion des «  heavyweight widgets ». • Ce profil sert de base pour construire des librairies d’interfaces usagers légères tel Swing ou d’autres toolkits. • Personal Profile 1.1.2. • permet le développement complet d'une IHM et d'applet grace à AWT • fournit un environnement d’application pour les applications utilisant AWT qui ne reposent que sur les composantes lourdes (heavyweight). • Support AWT comparable au JDK 1.1 • Plateforme adaptée pour les applets web ou pour la migration des applications PersonalJava

16. Foundation Profile

17. Personal Basis Profile

18. Personal Profile

19. Un package optionnelWireless Messaging API (WMA) • Recevoir et envoyer des SMS • Pas dans un profil car peut être utile dans plusieurs profils et types d’appareils

20. Java ME Platform pour la convergence des services • J2ME • Couvre des appareils limités aux connexions intermittentes jusqu’aux appareils mobiles en-ligne. • Un design dont l’ambition est de rendre facilement portable les différents configurations et profils afin de permettre au même service d’être livré à travers différents canaux

21. Exemples d’outils de développement • Sun Java Wireless Toolkit for CLDC • Sun Java Toolkit for CDC

22. Sun Java Wireless Toolkit • May 22, 2007 • Un ensemble d’outils pour créer une application Java qui s’exécute sur des appareils compatibles avec • la spécification Java Technology for the Wireless Industry (JTWI, JSR 185) • La spécification Mobile Service Architecture (MSA, JSR 248). • Des outils pour construire l’application, des utilitaires et un émulateur. • Mobile Service Architecture (JSR 248) • Java Technology for the Wireless Industry (JTWI) (JSR 185) • Connected Limited Device Configuration (CLDC) 1.1 (JSR 139) • Mobile Information Device Profile (MIDP) 2.0 (JSR 118) • PDA Optional Packages for the J2ME Platform (JSR 75) • Java APIs for Bluetooth (JSR 82) • Mobile Media API (MMAPI) (JSR 135) • J2ME Web Services Specification (JSR 172) • Security and Trust Services API for J2ME (JSR 177) • Location API for J2ME (JSR 179) • SIP API for J2ME (JSR 180) • Mobile 3D Graphics API for J2ME (JSR 184) • Wireless Messaging API (WMA) 2.0 (JSR 205) • Content Handler API (JSR 211) • Scalable 2D Vector Graphics API for J2ME (JSR 226) • Payment API (JSR 229) • Advanced Multimedia Supplements (JSR 234) • Mobile Internationalization API (JSR 238) • Java Binding for the OpenGL(R) ES API (JSR 239)

23. Sun Java Toolkit 1.0 for CDC • Connected Device Configuration (CDC) 1.1 (JSR 218) • Foundation Profile (FP) 1.1 (JSR 219) with Security Optional Package 1.0 • Personal Basis Profile (PBP) 1.1 (JSR 217) • Advanced Graphic and User Interface Optional Package for the J2ME Platforn (AGUI) 1.0 (JSR 209) • December 12, 2006

24. Modèle d’applications en J2ME • Le modèle traditionnel • Le modèle Applet • Le modèle midlet • Le modèle PDAlet • Le modèle Xlet

25. Le modèle d’application traditionnel • Le point d’entrée est une méthode statique nommée main() • Cycle de vie • la JVM charge la classe et invoque la méthode main(). • L’application s’exécute jusqu’à • elle mette fin elle-même à son exécution en appelant System.exit() (si le gestionnaire de sécurité autorise cet appel) • tous les threads non-daemon (incluant celui qui a démarré l’application) soient terminés. • Bien que l’OS puisse mettre fin à l’application sans préavis n’importe quand, • C’est l’application qui possède le contrôle complet sur son cycle de vie pour décider lorsqu’elle se termine ou lorsqu’elle acquiert ou relâche des ressources du système.

26. Une application qui ne termine jamais • Elle lance un thread qui ne se termine jamais

27. Le modèle applet

28. Le modèle Applet • Applet • Une application embarquée qui s’exécute sous le contrôle d’un browser web • Étroitement liée à la page web qui la contient • La page fournit l’espace d’affichage • L’interface usager n’est pas sous l’entier contrôle de l’applet • L’usager peut se promener de page en page sans demander la permission à l’applet • Il est raisonnable de • mettre en pause ou de détruire l’applet quand l’usager passe à une autre page • réactiver ou redémarrer l’applet si l’usager revient à la page originale • Est dite « gérée » car son cycle de vie est sous le contrôle du browser • Dans J2ME, les applets sont supportées seulement dans le Personal Profile

29. Le contexte et l’état d’une applet • Une applet doit être sous-classe de java.applet.Applet, • qui est elle-même sous-classe de java.awt.Panel. • Le contexte d’une applet • La méthode getAppletContext() rend une instance de l’interface java.applet.AppletContext • Permet d’obtenir des ressources – parametres d’initialisation, images, clips audio - du browser web. • La méthode getParameter(), • Permet de controler le browser web de manière limitée • Modifier la taille de l’applet (le browser peut refuser sans informer l’applet de le faire) • Jouer un clip audio • Afficher une message dans la barre de statut du browser • Ouvrir une nouvelle fenêtre du browser à un URL spécifique • Remplacer la page web courante par une nouvelle page • 4 états possibles pour un applet: • loaded: une instance de Applet est crée, mais aucune initialisation n’est faite. • stopped: l’ applet a été initialisée mais n,est pas active. • started: l’applet est active. • destroyed: l’applet est terminée et l’instance est prête pour le ramasse-miettes. • 4 méthodes de notification pour le cycle de vie : init(), start(), stop(), and destroy().

30. Le cycle de vie d’un applet • Création d’une applet • Lorsque le browser web charge et affiche la page contenant les tags • Il existe d’autres alternatives équivalentes • L’état de l’applet est loaded. • En général ne pas faire d’initialisation dans le constructeur parce que le contexte d’opération n’existe pas encore • Création du contexte de l’applet • context : paramètres, container parent, etc. • Lorsque le contexte est prêt, le browser met l’applet dans l’état stopped et invoque sa méthode init(). • La méthode init() n’est invoquée qu’une seule fois dans le cycle de vie d’une applet • Activation d’une applet • Lorsque l’état de l’applet passe de stopped à started, • En général lorsque le browser affiche la page contenant l’applet • Invocation de la méthode start() de l’applet. • Désactivation d’une applet • Lorsque l’état de l’applet passe de started à stopped. • En général, lorsque le browser arrête d’afficher la page contenant l’applet • Par exemple, lorsque l’usager appuie sur le bouton BACK pour revenir à la page précédente • Invocation de la méthode stop(). • Relâcher les ressources acquises par la méthode start() • Destruction d’une applet • Lorsqu’elle est dans l’état stopped, le browser peut détruire l’applet pour libérer les ressources qu’elle utilise, immédiatement après l’avoir arrêtée ou après un intervalle de temps plus long • Invocation de la méthode destroy() – dernière chance pour l’applet de faire quelque chose avec un contexte valide. • Note • Une applet ne peut pas inférer sur son cycle de vie directement • Pour se désactiver, elle doit remplacer la page web courante par une nouvelle.

31. MIDP et Midlet • combiner CLDC avec Mobile Information Device Profile (MIDP) pour fournir un environnement Java pour les applications s’exécutant sur des téléphones cellulaires et des appareils avec des capacités similaires. • MIDlet • Application pour CLDC + MIDP • par un logiciel application-management software (AMS) • installé dans l’appareil • La gestion externe de l’application est raisonnable car dans le contexte des appareils visés, l’application doit pouvoir être interrompue par des événements externes. • Exemple, il faut pouvoir interrompre l’application pour permettre à l’usager de recevoir un appel téléphonique • Placée dans un répertoire quelconque • Idéalement l’usager devrait pouvoir faire une recherche pour ce type d’application et télécharger celle qui l’intéresse dans son appareil.

32. Le cycle de vie d’un midlet

33. Initialisation n’est faite qu’une seule fois Centralise le code de nettoyage

34. Le cycle de vie d’un midlet • La classe principale d’un MIDlet doit être sous-classe de javax.microedition.midlet.MIDlet. • Cette sous-classe définit 3 méthodes de notification liées au cycle de vie : • startApp(), • pauseApp(), • destroyApp(). • Il existe 3 états possibles reliés à son cycle de vie pour un MIDlet : • paused: l’instance du MIDlet a été construite et est inactive. • active: l’instance du MIDlet est active. • destroyed: l’instance du MIDlet est terminée et est prête pour être réclamée par le ramasse-miettes. • Il n’y a aucun équivalent de l’état loaded des applets. • Le midlet doit être gérer lui-même son initialisation la première fois que sa méthode startApp() est invoquée. • Les MIDlets sont créés par l’AMS, en général suite à une requête de l’usager. • Par exemple, L’AMS affiche la liste des midlets disponibles et l’usager en choisit une. • L’état initial d’un MIDlet est paused. • A l’instar d’un applet, le MIDlet ne devrait pas faire d’initialisation dans son constructeur parce que son contexte d’exécution n’est pas encore mis en place. • Après la construction du midlet, l’ AMS l’active et invoque sa méthode activates startApp(). • Après avoir fait les initialisations nécessaires, la méthode startApp() crée et affiche l’interface usager. • Après que la méthode startApp() ait rendu le contrôle, l’état deu MIDlet passe de paused à active. • Si le MIDlet ne peut pas s’initialiser pour quelque raison que ce soit, il doit lancer une exception javax.microedition.midlet.MIDletStateChangeException – dans ce cas, son état passe immédiatement à destroyed. • La désactiviation du MIDlet survient pour toute transition de l’état active à l’état paused. • Le MIDlet n’est pas détruit, mais il devrait relâché le plus possible de ressources du système. • Si la désactivation est déclenchée par l’AMS, la méthode pauseApp() du midlet est invoquée • Si le MIDlet se désactive lui-même, par l’intermédiaire de son contexte d’opération, la méthode pauseApp() du midlet n’est PAS invoquée. • La destruction du MIDlet survient lorsque le MIDlet passe dans l’état destroyed. • Si la destruction est déclenchée par l’AMS, la méthode destroyApp() du MIDlet est invoquée. • Une valeur booléene est transmise à cette méthode pour indiquer si la destruction est inconditionnelle (doit être détruit) ou optionnelle. Le MIDlet peut refusé une destruction optionnelle en lançant une exception MIDletStateChangeException. • Si le MIDlet se détruit lui-même, la méthode destroyApp() du MIDlet n’est PAS invoquée.

35. Le contexte d’un MIDlet • Méthodes permettant à un MIDlet d’intergair avec son contexte • getAppProperty() • rend les valeurs des propriétés d’initialisation du MIDlet; • Les propriétés d’initialisation sont des paires nom-valeur • Elles sont recherchées dans • le descripteur d’application (1er choix), un fichier texte qui contient de l’information sur un ensemble de midlet « packagées » ensemble dans un même fichier .jar (MIDlet suite) • le fichier manifest (alternative) placé dans le .jar (MIDlet suite) qui contient le MIDlet • Dans MIDP 2.0, si la suite est « trusted », la méthode getAppProperty() ne cherche que dans le manifest. • resumeRequest() • le MIDlet dans l’état paused invoque cette méthode pour demander à l’AMS d’être réactivé; c’est l’AMS qui décide si le MIDlet sera réactivé ou non • notifyPaused() • le MIDlet invoque cette méthode pour être désactivé; • notifyDestroyed() : • le MIDlet invoque cette méthode pour être détruit.

36. Le modèle PDAlet • PDAP est une extension de CLDC 1.1 et MIDP 1.0. • Capacité de développer des interfaces usagers sophistiquées avec un sous-ensemble de AWT • le PDAP AWT est un sous-ensemble de celui du Personal Profile. • capacité d’accéder aux informations personnelles natives du PDA • carnet d’adresses, calendrier, liste to-do • Gestion de l'arborescence des fichiers : File Connection (FC) • Serialisation des composants UI • Clonage des objets • Modèle de sécurité J2SE • Buffered images • APIs pour le transfert des données • Alpha composite image manipulation • un PDAlet est un MIDlet qui utilise l’API PDAlet API et suit les mêmes principes que pour un MIDlet

37. Le modèle Xlet

38. Le cycle de vie d’un Xlet • La classe principale d’un Xlet doit implémenter l’interface javax.microedition.xlet. • Cette interface déclare 4 méthodes de notification pour le cycle de vie: • initXlet(), startXlet(), pauseXlet(), and destroyXlet(). • Il existe 4 états possibles : • loaded: The Xlet instance has been constructed, but no initialization has yet occurred. • paused: The Xlet has been initialized but is inactive. • active: The Xlet is active. • destroyed: The Xlet has been terminated and is ready for garbage collection. • Lorsque l’AMS crée un Xlet, il le place dans l’état loaded. • Après la construction, l’ AMS invoque la méthode initXlet() de la nouvelle instance, avec en paramètre XletContext le contexte d’opération du Xlet • Après l’initialisation, le Xlet est placé dans l’état paused. • A ce moment, le Xlet se comporte plus comme un MIDlet que comme une applet. • Ensuite, l’ AMS active le Xlet et invoque sa méthode startXlet(). Le Xlet active son interface usager, obtient les resources du système dont il a besoin et passe dans l’état active. • La désactivation survient lorsque l’état du Xlet passe de active à paused. Lorsque l’AMS désactive le Xlet, il invoque sa méthode pauseXlet(). Le Xlet doit libérer le plus de ressources possible. Si le Xlet se désactive lui-même, la méthode pauseXlet() n’est PAS invoquée. • Un Xlet peut passer dans l’état destroyed n’importe quand. • Si c’est l’ AMS qui détruit le Xlet, il invoque la méthode destroyXlet(). Le Xlet peut demander à avorter sa destruction en déclenchant une exception. • Si c’est le Xlet qui demande sa destruction, la méthode destroyXlet() n’est PAS invoquée.

39. Xlet et son contexte • Xlet fait partie • du Personal Basis Profile (PBP) et de son sur-ensemble, the Personal Profile (PP). • Initialement dans Java TV API, • L’interaction entre un Xlet et son contexte se fait à travers un objet qui implémente l’interface javax.microedition.xlet.XletContext. • getContainer() rend l’objet à la racine de l’interface usager; • getXletProperty() rend les valeurs des propriétés d’initialisation; • notifyDestroyed() change l’état du Xlet pour destroyed; • notifyPaused() change l’état du Xlet pour paused; • resumeRequest() demande à l’AMS AMS de le réactiver. • Un Xlet utilise les méthodes resumeRequest(), notifyDestroyed() et notifyPaused() de la même manière qu’un MIDlet.

40. References • http://developers.sun.com/mobility/midp/articles/models/ • http://www2.sys-con.com/itsg/virtualcd/java/archives/0801/keogh/index.html • http://developers.sun.com/mobility/getstart/articles/survey/