Lors du lancement de l'iPhone, par le fondateur de la marque à la pomme, Steve jobs a présenté l'iPhone comme un produit innovant qui réinvente le concept de téléphone portable. Aujourd'hui tout le monde est d'accord pour dire que ce mobile est un vrai bijou technologique: premier écran multi-touche sans stylet, détecteur de position, reconnaissance vocale, clavier virtuel... Mais, à mon avis, la vraie révolution n'est pas dans l'appareil lui même mais dans le bras tendu par Apple aux développeurs du monde entier pour réaliser et distribuer leurs créations grâce à l'AppStore. Comme son nom l'indique il s'agit d'une boutique d'application en ligne qui contient à ce jour plus de 100 000 applications développées par des entreprises spécialisées, qu'on a vu naître avec l'arrivée de l'iPhone, ou par des amateurs passionnés de nouvelles technologies. Ce concept a rencontré un succès sans précédant avec plus d'un milliard d'applications téléchargées. Même le nouveau spot publicitaire télévisé de l'iPhone met en avant le nombre d'applications disponibles plutôt que le téléphone lui même. Après ce fulgurant succès, tous les géants du marché se sont pressés de créer leurs propres « stores ». Windows a annoncé son MarketPlace, Nokia (Ovi Store), Google (Android Market), Palm (App Catalog), Samsung (Samsung Mobile Applications), Sony Ericsson (PlayNow)... Nous sommes entrain d'assister à une révolution dans le domaine de l'application mobile où l'applicatif prend le dessus sur le matériel. Avant l'arrivée de l'iPhone, les constructeurs de mobiles avaient toujours la même approche, à savoir concevoir des téléphones de plus en plus beau, de plus en plus sophistiqués, de plus en plus orientés vers l'appareil gadget! Mais Apple voulait un téléphone qui offre de plus en plus de fonctionnalités.
Bien avant Apple, quelques entreprises avaient déjà eu l'idée de lancer des « stores », des sites comme « handandgo » ou « getjar » proposent aux développeurs de mettre en ligne leurs applications mobiles. Pour un utilisateur lambda, la démarche pour télécharger et installer un logiciel sur son portable n'est pas évidente et peut rapidement devenir un vrai casse-tête. Avec l'iPhone, plus besoin de se compliquer la vie, tout ce fait directement avec le téléphone. Notons aussi que les constructeurs de téléphones mobiles ont toujours donné une marge de manœuvre très limitée aux développeurs et souvent ceci a été justifié par des raisons de sécurité! Les fonctionnalités qui leurs sont offertes ne permettaient que la réalisation de jeux 2D très basiques type Snake, Tetris et Pack-man... qui s'adressaient à un public limité. Sur l'AppStore, on trouve des jeux 3D qui n'ont rien à envier aux jeux sur PC, des applications utiles (horaires des prières pour les musulmans, GPS, horaires des vols en temps réel, accès aux informations, Facebook...) et des applications professionnelles (agenda synchronisé, diffusion marketing, campagne publicitaire, cours des actions en bourse, pages jaunes...).
Une fois de plus Apple a su créer une vraie révolution en réinventant le mobile. Cette réussite est due, en grande partie, à la créativité et à l'imagination des développeurs du monde entier.
Sunday, November 29, 2009
Friday, November 27, 2009
MIDlet
Le point d'entrée de tout programme MIDP est une classe qui hérite de la classe MIDlet du package javax.microedition.midlet.* Voici le plus petit programme Java ME qui fonctionne mais qui ne fait rien:
import javax.microedition.midlet.MIDlet;
/**
* Pppj2me.java
* Plus petit programme Java ME qui fonctionne
*/
public class Pppj2me extend MIDlet {
public void startApp(){}
public pauseApp(){}
public void destroyApp(boolean _b){}
}
La classe MIDlet étant abstraite, notre classe Pppj2me doit donc implémenter toutes les méthodes abstraites de MIDlet à savoir startApp(), pauseApp() et destroyApp(boolean b) dont voici les rôles:
L'appel de ces méthodes se fait par l'AMS (Application Management Software) qui est un programme faisant partie de l'OS du mobile et non pas de la plateforme Java ME. L'AMS s'occupe aussi de:
import javax.microedition.midlet.MIDlet;
/**
* Pppj2me.java
* Plus petit programme Java ME qui fonctionne
*/
public class Pppj2me extend MIDlet {
public void startApp(){}
public pauseApp(){}
public void destroyApp(boolean _b){}
}
La classe MIDlet étant abstraite, notre classe Pppj2me doit donc implémenter toutes les méthodes abstraites de MIDlet à savoir startApp(), pauseApp() et destroyApp(boolean b) dont voici les rôles:
- startApp() est le point d'entrée (équivalent de la méthode main() dans un programme Java standard ou la méthode init() dans les applets)
- pauseApp() est appelée quand la MIDlet entre en mode pause
- destroyApp(boolean b) est appelée pour quitter l'application et libérer toutes les ressources qu'elle utilise
L'appel de ces méthodes se fait par l'AMS (Application Management Software) qui est un programme faisant partie de l'OS du mobile et non pas de la plateforme Java ME. L'AMS s'occupe aussi de:
- l'installation, cycle de vie (active, pause...) suppression, lancement (opère comme la commande « java » en Java standard) des MIDlets
- l'intéractions entre l'OS et l'application (APIs, connexions I/O...).
- définition du domaine d'installation de la MIDlet
- l'écoute des connexions et alarmes pour le lancement automatique
- ...
La Fragmentation Java ME
Si on récapitule brièvement ce que l'on vient de dire dans ce premier article, on notera qu'il ya :
JTWI
La première action pour résoudre ce problème était la JSR 185 appelée Java Technology for Wireless Industry (JTWI) qui impose le support de MIDP 2.0, CLDC (1.1 ou 1.0), WMA et laisse optionnel celui de MMAPI.
MSA
Après la spécification JTWI, de plus en plus d'APIs ont vu le jour alors une nouvelle spécification appelée Mobile Service Architecture (MSA JSR 248) a été définie. Pour les mobiles a capacités relativement limitées, une sous couche de MSA a été mise en place.
MSA définie deux types de JSR: obligatoire ou obligatoire à condition. Les APIs qui nécessitent un matériel spécifique sont de type obligatoire à condition comme par exemple Location API (JSR 179) qui nécessite que le mobile soit équipe de GPS ou encore comme pour l'API Bluetooth.
Tout au long de ce live nous détaillerons toutes les APIs une par une et nous présenerons des exemples d'utilisation.
« Write once, run anywhere » ou « ?»
Java est un langage portable. Nous avons tous appris ça quand on a commencé à programmer sauf que ce qu'on oublie souvent de dire est que la portabilité n'est assurée que si on utilise la même machine virtuelle. Donc je dirais Java est portable si on l'exécute sur une JVM unique. Malheureusement, dans le monde de la téléphonie mobile, ce n'est pas le cas, on vient de voir que les téléphones embarquent des KVM avec un nombre d'APIs qui varient de 3 à 16!!
En plus vu que certaines APIs dépendent du matériel présent sur le mobile, on imagine bien que ceci peut être un facteur important quant à l'implémentation de l'API sur un téléphone donné. L'image ci dessous montre le nombre important de facteurs qui pourraient jouer sur la portabilité d'une application.
Malgré le JTWI et le MSA, aujourd'hui tous les développeurs ont recours à des outils et/ou des méthodes de développement pour s'assurer du bon fonctionnement de leurs applications sur un nombre important de téléphone. Dans le prochain chapitre nous présenterons l'outil le plus utilisé: le pré-processeur.
- de plus en plus de mobile avec des caractéristiques différentes (taille d'écran, nombre et disposition des touches, écran tactile...)
- différents fournisseurs de KVM
- 2 versions de CLDC
- 3 (~4) versions de MIDP
- des APIs optionnelles et/ou proprétaires
- ...
JTWI
La première action pour résoudre ce problème était la JSR 185 appelée Java Technology for Wireless Industry (JTWI) qui impose le support de MIDP 2.0, CLDC (1.1 ou 1.0), WMA et laisse optionnel celui de MMAPI.
MSA
Après la spécification JTWI, de plus en plus d'APIs ont vu le jour alors une nouvelle spécification appelée Mobile Service Architecture (MSA JSR 248) a été définie. Pour les mobiles a capacités relativement limitées, une sous couche de MSA a été mise en place.
MSA définie deux types de JSR: obligatoire ou obligatoire à condition. Les APIs qui nécessitent un matériel spécifique sont de type obligatoire à condition comme par exemple Location API (JSR 179) qui nécessite que le mobile soit équipe de GPS ou encore comme pour l'API Bluetooth.
Tout au long de ce live nous détaillerons toutes les APIs une par une et nous présenerons des exemples d'utilisation.
« Write once, run anywhere » ou « ?»
Java est un langage portable. Nous avons tous appris ça quand on a commencé à programmer sauf que ce qu'on oublie souvent de dire est que la portabilité n'est assurée que si on utilise la même machine virtuelle. Donc je dirais Java est portable si on l'exécute sur une JVM unique. Malheureusement, dans le monde de la téléphonie mobile, ce n'est pas le cas, on vient de voir que les téléphones embarquent des KVM avec un nombre d'APIs qui varient de 3 à 16!!
En plus vu que certaines APIs dépendent du matériel présent sur le mobile, on imagine bien que ceci peut être un facteur important quant à l'implémentation de l'API sur un téléphone donné. L'image ci dessous montre le nombre important de facteurs qui pourraient jouer sur la portabilité d'une application.
Malgré le JTWI et le MSA, aujourd'hui tous les développeurs ont recours à des outils et/ou des méthodes de développement pour s'assurer du bon fonctionnement de leurs applications sur un nombre important de téléphone. Dans le prochain chapitre nous présenterons l'outil le plus utilisé: le pré-processeur.
Architecture de Java ME
Comme on l'a déjà dit Java Micro Edition est la plateforme Java de Sun adaptée pour les téléphones portables, les PDA mais aussi les systèmes embarquées, boitiers de télévision...
Sur la Figure 1, nous distinguons les deux grandes parties de la plateforme (CDC et CLDC) ainsi que les sous parties de chacunes.
Dans ce livre nous nous intéressons uniquement à la partie concernant les mobiles et les PDAs à savoir celle représentée sur la 4ème colonne de la Figure 1 et qui est composée de KVM, CLDC, MIDP et Optional Packages. Nous détaillerons dans les paragraphes qui suivent la signification et le rôle de chacun d'eux.
KVM
La KiloByte Virtual Machine (KVM) est la machine virtuelle Java fournie, généralement, par Sun ou par d’autres entreprises comme JBed, Esmertec, IBM… Il s'agitt d'une version allégée de la JVM (Java Virtual Machine) standard. D'après les spécifications fournies par Sun, la KVM a été programmée à partir de zéro en ANSI C. Depuis 2007 une version open source de la KVM existe (Phone ME Project). Le succès de Java ME auprès des constructeurs de téléphones portables est dû en grande partie à cette machine virtuelle et plus précisement à la sécurité qu'elle offre vis à vis des applications tièrces qu'un utilisateur pourrait installer sur son téléphone sans endommager ce dernier contrairement à ce qu'on pourrait faire avec des technologies natives comme Symbian OS.
CLDC
La configuration Connected Limited Device Configuration (CLDC) est un sous ensemble de classes du langage Java qui sont nécessaires pour le développeur (java.lang.*, java.util.*), les E/S, la sécurité… CLDC ne gère ni le cycle de vie de la MIDlet ni les interfaces utilisateurs ni les événements utilisateurs ou externes (interruptions…). A l'heure actuelle, il existe 2 configuration avec une compatibilité ascendantes: CLDC 1.0 et CLDC 1.1. Cette dernière version apporte la gestion des flottants.
MIDP
Le profile Mobile Information Device Profile (MIDP) de l’ensemble des APIs qui définissent l’interaction de l’utilisateur avec le téléphone lui-même en passant par la KVM (écran, son, vibreur, mémoire…). La première version MIDP 1.0 a vu le jour en Septembre 2000. A l'heure actuelle, il existe 3 profils avec une compatibilité ascendantes: MIDP 1.0 embarqué sur les vieux téléphones et MIDP 2.0 plus récents (apporte plus d'API: jeux, sécurité...) et MIDP 2.1. On parle aussi de la sortie de MIDP 3.0 en Novembre 2009.
Comme le montre la Figure 2. Certains mobiles contiennent des APIs optionnelles en plus de MIDP. Il s'agit d'implémentation de certaines Java Specification Request (JSR) gérées de façon très formelle par le Java Community Process (JCP) et qui proposent des fonctionnalités avancées comme par exemple:
Wireless Messaging API (WMA 1.1 JSR 120) pour l'envoi de SMS
Multimedia Media API (MMAPI JSR 135) pour le support multimédia
Personal Information Management (PIM JSR 75) pour l'accès aux contacts
...
A noter aussi que certains constructeurs de téléphones portables et certains opérateurs peuvent rajouter des bibliothèques propriétaires au dessus de MIDP.
Sur la Figure 1, nous distinguons les deux grandes parties de la plateforme (CDC et CLDC) ainsi que les sous parties de chacunes.
Dans ce livre nous nous intéressons uniquement à la partie concernant les mobiles et les PDAs à savoir celle représentée sur la 4ème colonne de la Figure 1 et qui est composée de KVM, CLDC, MIDP et Optional Packages. Nous détaillerons dans les paragraphes qui suivent la signification et le rôle de chacun d'eux.
KVM
La KiloByte Virtual Machine (KVM) est la machine virtuelle Java fournie, généralement, par Sun ou par d’autres entreprises comme JBed, Esmertec, IBM… Il s'agitt d'une version allégée de la JVM (Java Virtual Machine) standard. D'après les spécifications fournies par Sun, la KVM a été programmée à partir de zéro en ANSI C. Depuis 2007 une version open source de la KVM existe (Phone ME Project). Le succès de Java ME auprès des constructeurs de téléphones portables est dû en grande partie à cette machine virtuelle et plus précisement à la sécurité qu'elle offre vis à vis des applications tièrces qu'un utilisateur pourrait installer sur son téléphone sans endommager ce dernier contrairement à ce qu'on pourrait faire avec des technologies natives comme Symbian OS.
CLDC
La configuration Connected Limited Device Configuration (CLDC) est un sous ensemble de classes du langage Java qui sont nécessaires pour le développeur (java.lang.*, java.util.*), les E/S, la sécurité… CLDC ne gère ni le cycle de vie de la MIDlet ni les interfaces utilisateurs ni les événements utilisateurs ou externes (interruptions…). A l'heure actuelle, il existe 2 configuration avec une compatibilité ascendantes: CLDC 1.0 et CLDC 1.1. Cette dernière version apporte la gestion des flottants.
MIDP
Le profile Mobile Information Device Profile (MIDP) de l’ensemble des APIs qui définissent l’interaction de l’utilisateur avec le téléphone lui-même en passant par la KVM (écran, son, vibreur, mémoire…). La première version MIDP 1.0 a vu le jour en Septembre 2000. A l'heure actuelle, il existe 3 profils avec une compatibilité ascendantes: MIDP 1.0 embarqué sur les vieux téléphones et MIDP 2.0 plus récents (apporte plus d'API: jeux, sécurité...) et MIDP 2.1. On parle aussi de la sortie de MIDP 3.0 en Novembre 2009.
Comme le montre la Figure 2. Certains mobiles contiennent des APIs optionnelles en plus de MIDP. Il s'agit d'implémentation de certaines Java Specification Request (JSR) gérées de façon très formelle par le Java Community Process (JCP) et qui proposent des fonctionnalités avancées comme par exemple:
Wireless Messaging API (WMA 1.1 JSR 120) pour l'envoi de SMS
Multimedia Media API (MMAPI JSR 135) pour le support multimédia
Personal Information Management (PIM JSR 75) pour l'accès aux contacts
...
A noter aussi que certains constructeurs de téléphones portables et certains opérateurs peuvent rajouter des bibliothèques propriétaires au dessus de MIDP.
Java ME et les autres
Java ME mais aussi Blackberry, Symbian OS, Android, iPhone, DoJA, Brew... Ces noms vous disent peut etre quelque chose. Il s'agit de quelques plateformes utilisées sur des milliers de téléphones disponibles sur le marché. Quand un développeur souhaite développer une application, un choix important doit se faire sur la technologie à utiliser. Ce choix doit se faire en fonction des besoins auxquels l'application doit répondre mais aussi au parc de téléphone que le développeur souhaiterai couvrir qui revient généralement à choisir le public de l'application à developper.
Dans ce livre nous nous sommes intéressés à la plateforme Java ME pour les raisons suivantes:
technologie présente sur la plus grande majorité des téléphones disponibles sur le marché
plateforme de plus en plus mûre
outils de développement évolués
la prise en main de cette technologie est relativement rapide
profiter (en partie) de la puissance du langage Java
...
Au moment de la rédaction de ce livre, une dizaine de téléphone équipé du système d'exploitation de Google (Android) ont fait leur apparition sur le marché et une grande communauté de développeurs s'est créée autour donc à suivre de très près... ça sera peut être mon prochain livre :).
Dans ce livre nous nous sommes intéressés à la plateforme Java ME pour les raisons suivantes:
technologie présente sur la plus grande majorité des téléphones disponibles sur le marché
plateforme de plus en plus mûre
outils de développement évolués
la prise en main de cette technologie est relativement rapide
profiter (en partie) de la puissance du langage Java
...
Au moment de la rédaction de ce livre, une dizaine de téléphone équipé du système d'exploitation de Google (Android) ont fait leur apparition sur le marché et une grande communauté de développeurs s'est créée autour donc à suivre de très près... ça sera peut être mon prochain livre :).
Téléphonie mobile
Nous avons assisté ces dernières années a une évolution significative du rôle que joue le téléphone portable dans nos vies. Il est passé d'un outil de communication classique à un outil personnel avec lequel on s'orgnaise (agenda, calendrier...), on s'amuse (jeux...) et aussi on travaille (email...). Il n ya pas que l'utilisation du mobile qui a évolué mais les technologies qui y sont embarquées aussi. En effet, aujourd'hui presque tous les téléphones sont équipés d'appareil photo numérique, de Bluetooth et même d'écran tactile et de GPS.
Les tendances aussi changent souvent, au début on a tout misé sur la miniaturisation des mobiles jusqu'à avoir des téléphones d'une taille impressionnante mais aujourd'hui ce qui nous intéresse c'est plûtot la qualité des services qu'il offre (Taille d'écran, logiciels, mémoire, vitesse...). Cette évolution visible par tout le monde en cache une autre qui intéresse des utilisateurs particuliers à savoir les développeurs d'application embarquée sur mobile. En effet, on a vu apparaître et disparaître plusieurs technologies, plusieurs fabriquants de mobile, plusieurs outils de développement aussi. Mais à mon avis le changement le plus intéressant que nous avons vécu, en tant que développeurs, est l'évolution du type d'application qu'on peut embarquer sur un mobile. Nous avons commencé par des jeux basiques comme Snack pour arriver aujourd'hui à des jeux type Age of Empire ou autre. Mais on est aussi passer du jeu à l'application utile (synchronisation des contacts, gestion de compte bancaire) ou amusante (chat par Bluetooth, lecteur multimédia)...
Tout ceci pour dire que les développeurs d'application mobile ont de beaux jours devant eux à condition de se mettre à jour aux niveau des technologies mais aussi aux niveaux des outils qu'ils utilisent.
Les tendances aussi changent souvent, au début on a tout misé sur la miniaturisation des mobiles jusqu'à avoir des téléphones d'une taille impressionnante mais aujourd'hui ce qui nous intéresse c'est plûtot la qualité des services qu'il offre (Taille d'écran, logiciels, mémoire, vitesse...). Cette évolution visible par tout le monde en cache une autre qui intéresse des utilisateurs particuliers à savoir les développeurs d'application embarquée sur mobile. En effet, on a vu apparaître et disparaître plusieurs technologies, plusieurs fabriquants de mobile, plusieurs outils de développement aussi. Mais à mon avis le changement le plus intéressant que nous avons vécu, en tant que développeurs, est l'évolution du type d'application qu'on peut embarquer sur un mobile. Nous avons commencé par des jeux basiques comme Snack pour arriver aujourd'hui à des jeux type Age of Empire ou autre. Mais on est aussi passer du jeu à l'application utile (synchronisation des contacts, gestion de compte bancaire) ou amusante (chat par Bluetooth, lecteur multimédia)...
Tout ceci pour dire que les développeurs d'application mobile ont de beaux jours devant eux à condition de se mettre à jour aux niveau des technologies mais aussi aux niveaux des outils qu'ils utilisent.
First post
Hello everybody, this is my first post in this blog. Today I decide to launch my blog to write about wireless programming using J2ME platform, Android, BlackBerry, Symbian... I will give tips, examples. Bookmark this blog it will be great :). Don't hesitate to ask me questions I will answer as soon as possible.
Subscribe to:
Posts (Atom)
