L’idée fun et simple
Pour cela, voici mon expérience personnelle en la matière : l’idée est née de créer une application très simple afin d’avoir un suivi de la consommation d’essence de mon véhicule. En effet, j’utilisais la calculatrice de mon téléphone portable pour faire le ratio entre le nombre de litres consommé sur le nombre de km effectués. Voila comment NokiaEssence est né…

Coté matériel, je disposais de 2 téléphones portables de marque Nokia : un 3100 et un 6136. Les mobiles chez Nokia se décomposent en 3 grandes séries : s40, s60 et s80. Mes 2 portables font partie de la série s40. Le site http://forum.nokia.com (Voir figure 1) m’a rapidement renseigné sur les possibilités de ces 2 téléphones. Aux vues des spécifications, mon choix c’est rapidement porté vers le modèle 6136.

Tableau 1

Les logiciels

J’ai donc commencé par installer tous les logiciels nécessaires (cf. Tableau 2). J’ai été ensuite très agréablement surpris de m’apercevoir qu’un matériel de formation, très bien fait, était à disposition de tous gratuitement : des tutoriaux indispensables disponibles sur le site d' EclipseME expliquent pas à pas comment construire ses premières applications mobiles.

L'environnement de développement
L'IDE utilisé, Eclipse, propose un éditeur agréable avec le confort habituel des IDE : coloration syntaxique, complétion de code, assistants etc… Le " refactoring " (possibilité par exemple de renommer intelligemment une méthode, un attribut ou paramètre partout dans le code) est un plus agréable.

Le plug-in " Carbide.j " avec le " SDK S40 3rd Edition Feature Pack " permet de créer et régénérer un package application. Le sdk met à disposition un émulateur très proche du téléphone réel. Et chose très utile, il est possible d'utiliser le débuggeur d'Eclipse pour tracer le code de l'application qui s'exécute sur l'émulateur.

Au commencement fût la MIDlet…
Le début de tout développement mobile Java est de créer une MIDlet : une MIDlet est un programme java pour l'informatique embarquée, plus spécifiquement pour les machines virtuelles Java ME (Mobile édition - J2ME en abrégé). Une MIDlet doit se conformer au standard MIDP (Mobile Information Device Profile). MIDP est un ensemble d'APIs J2ME qui définit la façon dont les applications se connectent à l'interface des téléphones cellulaires.

La classe principale de l'application doit être une classe dérivée de la classe " javax.microedition.midlet.MIDlet ". Cette classe permet d'implémenter 3 méthodes : startApp, pauseApp et destroyApp qui seront appelées respectivement au démarrage, à la mise en pause, ou à l'arrêt de l'application. Les APIs disponibles pour le développement J2ME sont à rechercher dans le package javax.microedition. Ensuite la MIDlet doit être packagée dans un fichier " .jar ", ce que Carbide.j permet de faire aisément.

L'affichage
L'interface utilisateur étant réduite, même si plusieurs MIDlet sont en cours d'exécution à la fois, une seule affiche son écran. La hiérarchie de classe mise en place pour l'interface utilisateur est basée sur la classe Displayable (Voir figure 2). 2 classes abstraites dérivent de cette précédente : Screen et Canvas. Les classes concrètes dérivées de Screen fournissent une API de haut niveau afin de permettre l'affichage de fenêtres.

Figure 2

Voici le code pour afficher une boite de dialogue :

public class HelloWorldMIDlet extends MIDlet
{
public void ShowMessage(String aTitre, String aAlertText, AlertType aAlertType)
{
// Création de la boite de dialogue " Alert "
Alert myAlert = new Alert(aTitre, aAlertText, null, aAlertType);
// Affichage de la boite de dialogue
Display.getDisplay(this).setCurrent(myAlert);
}

protected void startApp( )
{
ShowMessage("Hello world","Hello world",AlertType.INFO);
}
protected void pauseApp( )
{
}

protected void destroyApp( boolean p1 )
{
}
}

Voici les objets proposé dans la palette de composant :

Le composant Command a pour particularité de proposer à l'utilisateur d'interagir avec l'application. Pour que la commande soit utilisable, le formulaire doit implémenter l'interface CommandListener. On retrouve typiquement la programmation événementielle…

// Implémentation de l'interface CommandListener :
public void commandAction(Command aCommand, Displayable aDisplayable)
{
if ( aCommand == commandOk ) ActionOk();
if ( aCommand == commandSauver ) ActionSauver();
// etc.
}
// Au préalable il faudra enregistrer ces commandes à l'initialisation de la form grace à ces instructions :
this.addCommand(commandOk);
this.addCommand(commandSauver);
// Cette instruction défini l'interface comment listener d'événement
this.setCommandListener(this);

Figure 3 bis

Le graphisme
Des APIs de plus bas niveau sont aussi disponibles : la classe Canvas est à la base de tout nouveau graphisme à implémenter. Elle permet de représenter des données sous formes de diagrammes ou de créer des animations, voire même des jeux.

La méthode centrale de la classe Canvas à implémenter est la méthode paint(Graphics g). L’objet graphique passé en argument à cette méthode permet les opérations graphiques, comme le tracé de lignes, de cercles, l’affichage de texte, le remplissage par une couleur, etc. La classe Image complète ces APIs de bas niveau pour l’affichage. L’image devra être dans un format reconnu par le mobile. Le standard MIDP reconnaît en standard le format PNG.

La classe FileConnection permet l'accès au système de fichier d'une manière générale : elle permet de lister, supprimer, obtenir des informations sur les fichiers, etc. L'accès au fichier s'effectue à l'aide des flux : InputStream en lecture et OutputStream en écriture. Voici un exemple de code pour créer le fichier :

public void WriteToFileString(String aStringToWrite)
{
// Crée le fichier
mainFileConnection .create();
// Récupére le flux en écriture
OutputStream os = mainFileConnection .openOutputStream();
// Ecrit dans le fichier
os.write(aStringToWrite.getBytes());
// Vide le cache
os.flush();
// Ferme le fichier
os.close();
}

L'option JSR 75 ne se limite pas à l'accès au système de fichiers. Elle fournit une 2ème API nommée PIM (Personal Information Management). Cette API permet l'accès aux données personnelles (Contacts/Liste des numéros de téléphone, Agenda/Calendrier, Liste des choses à faire) depuis la mémoire interne du téléphone ou la carte SIM. Voici un petit exemple de code pour lister les contacts :

PIM pim = PIM.getInstance();
int i = 0;
try
{
ContactList cl= (ContactList)pim.openPIMList(PIM.CONTACT_LIST, PIM.READ_ONLY );
Enumeration e=cl.items();
while(e.hasMoreElements() )
{
// Récupère un contact
Contact contact = (Contact)e.nextElement();
// Pour récupérer un N° de téléphone par exemple :
// String tel= contact.getString( Contact.TEL, 0 );
i++;
}
System.out.println(i+" téléphones trouvés.");
}
catch(PIMException pime)
{
System.out.println("Aucun contact trouvé");
}
catch(SecurityException se )
{
System.out.println("L'application n'a pas la permission d'accéder à la liste");
}

Multimédia API
Si votre téléphone portable supporte la spécification JSR 135 Mobile Media API, vous pourrez gouter à la joie de piloter l'appareil photo ou caméra de votre mobile. 4 classes principales sont là pour utiliser l'API : Voir figure 4

• Manager
• Player
• Control
• Datasource

Figure 4

La classe Manager contient uniquement des méthodes statiques. La méthode Manager.createPlayer créé un player avec un DataSource associé pour lui fournir les données. La source de données peut être construite à partir d'un flux (InputStream) ou d'un " URI-style locator ". En voici quelques exemples :

Tableau 4

Voici un exemple de code pour afficher la capture en temps réel de ce qui est visualisé par l'objectif de l'appareil photo. Le rendu est affiché directement sur la Form.

Form f = new Form("JPP Form"); // Crée la form principale
Display.getDisplay(this).setCurrent(f); // Affiche la form
Player p = Manager.createPlayer("capture://video");
p.realize(); // Initialise le player
VideoControl vc = (VideoControl)p.getControl("VideoControl");
if (vc != null)
{
Item it = (Item) vc.initDisplayMode (VideoControl.USE_GUI_PRIMITIVE, null);
f.append(it); // Rajoute l'item à la form.
p.start(); // Affiche la vidéo dans l'item.
}

La ligne de code suivante permet de prendre une photo :
videoControl.getSnapshot("encoding=bmp");

Cette architecture très ouverte permet aussi d'afficher des vidéos au format 3gp, de jouer des sons très facilement, etc. La méthode getControl de la classe Player renvoie une interface abstraite que plusieurs classes concrètes implémentent. Suivant les cas, le transtypage vous permettra de manipuler tel ou tel type de contrôle. Voici quelques exemples de classes concrètes :

• ToneControl
• VolumeControl
• VideoControl
• StopTimeControl
• RecordControl

Figure 5

Mais le plus impressionnant reste les jeux 3D. L'option JSR 184 (M3G Mobile 3D Graphics API) propose tout le nécessaire en la matière. 3 classes sont la clé de voute de cette option :

Tableau 5

Nokia a pour l'instant une longueur d'avance en matière de jeux vidéo pour mobile. Le " smartphone " N-Gage (mi téléphone, mi console de jeu) en est un bel exemple. Mais Nokia ne se limite pas à la production de terminaux : la société a lancé un sdk nommé SNAP (Scalable Network Application Package). Il s'agit d'une solution " clé en main " pour fournir une infrastructure de services pour la communauté de jeux en ligne multi-joueurs.

SNAP permet d'établir une communication réseau entre le terminal et le serveur de jeu afin de rejoindre une communauté de jeu. Les fonctionnalités proposées sont l'authentification, la liste de contacts, l'échange de message en cours de jeu, la création d'événements et enfin le classement des joueurs. Ce sdk particulier est conçu pour fonctionner avec les standards MIDP 2.0 et CLDC 1.0

Communications / Web services
Par définition, un téléphone est un objet communicant :, bien plus que vous ne pouvez l'imaginer : la variété des moyens de communication et des protocoles est impressionnante. Jugez-en par vous-même :

Tableau 6

Le package javax.microedition.io.Connector est le point d'entrée de l'utilisation de ces moyens de communication.

Reste un autre moyen de communication très populaire : les Web services. L'option JSR 172 permet de s'appuyer sur un serveur ou fournisseur de Web services déjà existant. Le but de ce package est de fournir un parsing XML, et une API standard pour accéder et consommer des Web services. Un des avantages de créer un Web service est de permettre à différents clients (application client riche, application web via un navigateur, ou application mobile) d'accéder au même service. Carbide.j facilite le travail en proposant un générateur de code afin d'accéder aux Web services. La logique " métier " est donc centralisée et réutilisable pour différents types de clients.

Une autre option, qui couplée avec les web services semble vraiment prometteuse est l'option JSR 179 (Géolocalisation). Aujourd'hui, cette option n'est pas encore très répandue. Elle fournit des informations comme le positionnement géographique (latitude, longitude et altitude), la vitesse du terminal mobile en déplacement, etc. Ces informations peuvent provenir de différentes sources : GPS, réseau cellulaire, ou pour des localisations de proximité Bluethoot positionning system par exemple. Cette option fournit aussi un ensemble de classes afin de se connecter à une base de données de " landmark ". Un landmark est une localisation physique connue qui est associée avec un nom représentant cette localisation.

Les mobiles sont aussi équipés de navigateur web. La norme actuelle pour le développement de pages web pour ces navigateurs est XHTML MP (Mobile Profile). XHTML est très proche du HTML que l'on connaît. Il suffit d'être un peu plus rigoureux sur quelques points comme dans la fermeture des balises… Cependant, il faudra adapter les pages à une taille d'écran à laquelle le web ne nous a pas habitués. Cela réduit forcément le nombre d'informations affichées simultanément…

Cependant beaucoup d'opérateurs font payer au prix fort l'accès à Internet via leur réseau. Mais à ne pas en douter, la demande croissante d'accès à Internet via ces terminaux sera forte. A quand verrons-nous la guerre commerciale chez les opérateurs mobiles pour nous proposer un accès Internet mobile illimité à un prix tout à fait compétitif ? L'exemple des " box " que nous connaissons aujourd'hui chez les opérateurs téléphoniques classiques pourrait donner quelques idées aux opérateurs mobiles…

Figure 5 bis

Le déploiement
Le transfert de l'application peut s'effectuer sur le téléphone de différentes manières. Les moyens les plus courants sont le câble usb, l'infrarouge ou le bluetooth. Par câble usb, un logiciel comme Nokia Pc Suite (qui propose parmi ses nombreuses fonctionnalités d'installer une application par simple copie du fichier .jar) sera nécessaire. L'envoie du fichier par infrarouge installe automatiquement l'application sans avoir besoin d'un logiciel tiers.

Un autre moyen très répandu pour installer et diffuser des MIDlet est d'utiliser la technique nommée OTA (Over The Air) : le distributeur de votre application installe la MIDlet sur un serveur web et fournit un lien hypertexte. L'utilisateur active ce lien sur le téléphone portable qui va déclencher le téléchargement de la MIDlet. Le lien pointera comme l'indique l'exemple vers le fichier .jad créé lors de la génération du package par Carbide.j.
<A href="/sybaris/MaMIDlet.jad">Cliquez ici</A> pour installer l'application

L'un des gros avantages du langage java est sa portabilité. La portabilité signifie que le programme fonctionnera sur une grande quantité de plateformes différentes, sans nécessiter d'être recompilé. Même si on développe avec les outils fournit par Nokia, le fruit du développement peut tout à fait être utilisé sur d'autres marques de téléphones, sans recompilation. Il suffit que le téléphone supporte les spécifications qui ont été à la base du développement (MIDP, CLDC et JSR…) et le fichier .jar sera exécuté…

Sécurité
L'accès aux fichiers via l'API JSR 75 n'est pas autorisé par défaut. En effet, on ne plaisante pas avec la sécurité sur téléphone portable : une MIDlet non signée se verra par défaut refuser l'accès au système de fichier (cf. Tableau 7). L'utilisateur pourra paramétrer cela, mais il devra quand même donner son autorisation (" Ask every time ") à chaque ouverture de fichiers. Pour que votre application puisse se passer de l'autorisation de l'utilisateur, elle devra être signée.

Tableau 7

Figure 6

De plus il faudra donner les permissions suivantes à la MIDlet :
javax.microedition.io.Connector.file.read
javax.microedition.io.Connector.file.write
Cela se paramètre lors de la génération du package avec Carbide.j

Figure 7

Conclusion
Dans un environnement où l'ordinateur n'est pas toujours présent, il est envisageable de se tourner vers ce genre d'application à moindre coût. L'interface d'entrée privilégie essentiellement la saisie numérique. C'est ainsi que l'adaptation à ce type de plateforme nécessite de repenser la manière d'appréhender les applications : il peut parfois être plus pratique de substituer la saisie par la prise d'une photo qui servira d'identifiant, quitte à compléter les informations ultérieurement sur ordinateur.

En conclusion, les outils (IDE, sdk, plug-ins, outils de design, etc.…), les normes, le matériel de formation, les documentations sont là. Nokia propose de manière claire et efficace tout le nécessaire pour vous lancer sur le sujet. Ce type de développement est beaucoup plus simple qu'il n'y parait. Les projets sont de petite taille, donc rapide à réaliser. Les possibilités sont vastes. Pourquoi ne pas vous lancer dans la création d'une petite application pour mobile ? C'est fun, ludique et rapide.

A vous de trouver la bonne idée…