40
Clients mobiles J2ME Java Micro-Edition

Clients mobiles

  • Upload
    dino

  • View
    32

  • Download
    0

Embed Size (px)

DESCRIPTION

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 » - PowerPoint PPT Presentation

Citation preview

Page 1: Clients mobiles

Clients mobiles

J2ME

Java Micro-Edition

Page 2: Clients mobiles

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

Page 3: Clients mobiles

Evolution

« Write once, run anywhere »

« Java everywhere »

Trouver un équilibre portabilité performance et faisabilité

Page 4: Clients mobiles

L’architecture de J2ME

Page 5: Clients mobiles

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.

Page 6: Clients mobiles

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

Page 7: Clients mobiles
Page 8: Clients mobiles

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

Page 9: Clients mobiles

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.

Page 10: Clients mobiles

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

Page 11: Clients mobiles

CLDC 1.1. API

Page 12: Clients mobiles

Mobile Information Device Profile MIDP 2.0

Page 13: Clients mobiles

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é

Page 14: Clients mobiles

Connected Device Configuration

Page 15: Clients mobiles

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

Page 16: Clients mobiles

Foundation Profile

Page 17: Clients mobiles

Personal Basis Profile

Page 18: Clients mobiles

Personal Profile

Page 19: Clients mobiles

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

Page 20: Clients mobiles

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

Page 21: Clients mobiles

Exemples d’outils de développement

Sun Java Wireless Toolkit for CLDC

Sun Java Toolkit for CDC

Page 22: Clients mobiles

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)

Page 24: Clients mobiles

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

Page 25: Clients mobiles

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.

Page 26: Clients mobiles

Une application qui ne termine jamais

Elle lance un thread qui ne se termine jamais

Page 27: Clients mobiles

Le modèle applet

Page 28: Clients mobiles

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

Page 29: Clients mobiles

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

Page 30: Clients mobiles

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.

Page 31: Clients mobiles

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.

Page 32: Clients mobiles

Le cycle de vie d’un midlet

Page 33: Clients mobiles

Initialisation n’est faite qu’une seule fois

Centralise le code de nettoyage

Page 34: Clients mobiles

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.

Page 35: Clients mobiles

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.

Page 36: Clients mobiles

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

Page 37: Clients mobiles

Le modèle Xlet

Page 38: Clients mobiles

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.

Page 39: Clients mobiles

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.

Page 40: Clients mobiles

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/