IFT604_4a_J2ME
publicité
Clients mobiles J2ME Java Micro-Edition 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 Evolution « Write once, run anywhere » « Java everywhere » Trouver un équilibre portabilité performance et faisabilité L’architecture de J2ME 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. 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 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)). 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. Configuration for Small Devices - The Connected Limited Device Configuration (CLDC) Configuration Profils Exemples de packages optionnels CLDC 1.1 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. 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 CLDC 1.1. API Mobile Information Device Profile MIDP 2.0 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 sousensemble de ces APIS en fonction du profil supporté Connected Device Configuration 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 Foundation Profile Personal Basis Profile Personal Profile Un package optionnel Wireless Messaging API (WMA) Recevoir et envoyer des SMS Pas dans un profil car peut être utile dans plusieurs profils et types d’appareils Java ME Platform pour la convergence des services J2ME Couvre des appareils limités aux connexions intermittentes jusqu’aux appareils mobiles enligne. 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 Exemples d’outils de développement Sun Java Wireless Toolkit for CLDC Sun Java Toolkit for CDC 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) 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 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 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. Une application qui ne termine jamais Elle lance un thread qui ne se termine jamais Le modèle applet 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 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(). Le cycle de vie d’un applet Création d’une applet Création du contexte de l’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 Invocation de la méthode stop(). Relâcher les ressources acquises par la méthode start() Par exemple, lorsque l’usager appuie sur le bouton BACK pour revenir à la page précédente Destruction d’une 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 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 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. 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. Le cycle de vie d’un midlet Initialisation n’est faite qu’une seule fois Centralise le code de nettoyage 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. L’état initial d’un MIDlet est paused. 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. 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(). Par exemple, L’AMS affiche la liste des midlets disponibles et l’usager en choisit une. 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. 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. 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 sousensemble 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 Le modèle Xlet 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. 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. References http://developers.sun.com/mobility/midp/article s/models/ http://www2.syscon.com/itsg/virtualcd/java/archives/0801/keog h/index.html http://developers.sun.com/mobility/getstart/arti cles/survey/
