Une mise au point sur l'histoire
i-Mode a été introduit par l'opérateur Japonais NTT DoCoMo. On dénombre 30 millions d'abonnés NTT DoCoMo.
i-Mode repose sur un langage à balise décliné de HTML, le C-HTML (Compact HTML). C'est un sous-ensemble de HTML auquel des balises propriétaires ont été ajoutées, comme des balises de smileys. Donc une page C-HTML peut être visualisée avec un navigateur HTML.
Les points faibles de i-Mode / CHTML sont les suivants :

- Manque de sécurité
- Interface utilisateur pauvre
- Nécessite une connexion tout au long de l'utilisation de CHTML

Or les applications demandent aujourd'hui :

- Plus de sécurité, en particulier pour le mCommerce (mobile Commerce)
- Plus d'interactivité, en particulier pour les jeux vidéos
- Plus de sophistication, pour des applications du type client-serveur

J2ME répond à ces besoins. En effet, les principales caractéristiques de J2ME sont :

- Indépendance vis-à-vis de la plate-forme
- Modèle de sécurité intégré de base
- Déploiement d'application dynamique
- Interface utilisateur évoluée
- Fonctionnalités réseau évoluées

Pour intégrer J2ME sur les téléphones mobiles, NTT DoCoMo a implémenté une machine virtuelle Java (KVM) et la configuration CLDC. Malheureusement, il manquait toujours une brique pour que le tout puisse fonctionner : le profil. NTT DoCoMo a ainsi décidé de créer Java for i-Mode, aussi appelé DoJa. On peut donc considérer Java for i-Mode comme un profil. Le fait est que J2ME a poursuivi son évolution et le profil MIDP est apparu plus tard. Aujourd'hui, nous nous retrouvons donc avec deux "profils", DoJa et MIDP. Les deux devraient fusionner dans l'avenir : ils possèdent les mêmes bases, respectent la même philosophie et ont des bibliothèques de développement proches.

Le contenu au centre de i-mode
Les fournisseurs de contenu officiels sont directement connectés au serveur i-mode. Ces contenus sont listés dans le menu i-mode et peuvent être facilement atteints en quatre ou cinq clics. Ces sites peuvent faire payer leur contenu : NTT DoCoMo prend en charge la facturation et reverse une partie des revenus ainsi générés. Les types de contenu proposés sont des informations sur les restaurants, sur les villes, les cours de la bourse, la réservation de billet d'avion, les sites bancaires, les pages jaunes, la messagerie, …
Les fournisseurs de contenu non officiels sont tous les autres fournisseurs. Ces contenus ne sont pas listés dans le menu i-mode : pour y accéder, il faut connaître leur adresse et passer par un relais de communication entre le réseau NTT DoCoMo et Internet. Un système de bookmark permet toutefois de garder en mémoire jusqu'à 20 adresses de site de contenu sans avoir à retaper à chaque fois leur adresse.
Pour eux, NTT DoCoMo ne propose pas de système de reversement.
Pour ce qui est du langage à balises, il existe plusieurs méthodes pour développer des sites compatibles iMode. iMode utilise IHTML, qui reprend et complète CHTML. La première méthode est d'utiliser un transcodeur comme WebSphere Transcoding Publisher. La conversion d'un site HTML en site i-Mode est dans ce cas faite simplement. La deuxième méthode consiste à effectuer cette conversion manuellement. Enfin, la troisième consiste à créer une page CHTML à la base.
Par contre, pour ce qui est du langage Java, vous devrez développer vos applications avec Java for i-Mode, aussi appelé DoJa.
Java for i-Mode permet de proposer des applications impossibles à concevoir avec CHTML. On peut répartir ces applications en trois catégories :

- Les applications autonomes, qui peuvent fonctionner entièrement sans réseau (exemple : jeux de tir, jeux de puzzle, …).
- Les applications de type client-serveur, qui peuvent tourner sur le téléphone et sauvegarder les données sur le serveur en se connectant à Internet (exemple : jeux de rôle, jeux en réseau multi-joueurs)
- Les applications de type agent, qui prennent l'initiative de se connecter à Internet pour mettre à jour ses informations (exemple : météo, bourse).

L'API iMode

Le réseau
Une application Java for i-mode peut effectuer des requêtes HTTP et HTTPS (URL de type "http" et "https"). Cela permet d'échanger des données avec un serveur Web.
Java for i-Mode repose sur la notion de GCF (Generic Connection Framework), incluse dans la configuration CLDC de J2ME.

Le stockage de données persistentes
Le scratchPad (URL de type "scratchpad") permet de stocker des données sur le terminal. C'est l'équivalent du RMS de MIDP.
Par ailleurs, l'application peut lire les fichiers de données contenus dans le fichier JAR : l'accès se fait comme tout accès réseau mais en utilisant une URL de type "resource:".

L'interface utilisateur
De manière similaire à MIDP, une application Java for i-mode propose deux manières de créer l'interface utilisateur. L'API de bas niveau de l'interface utilisateur permet de créer l'interface utilisateur en dessinant directement dans le contexte graphique tandis que l'API de haut niveau permet de créer une interface utilisateur à partir de composants comme des boutons ou des listes déroulantes.
Tant qu'à l'API de haut niveau de gestion des événements de l'interface utilisateur, elle propose un modèle événementiel similaire au modèle de délégation du JDK 1.1.

Quelles sont les différences entre Java for i-Mode et MIDP ?
Bien que NTT DoCoMo ait implémenté J2ME sur ses téléphones mobiles et bien que cette implémentation repose sur la configuration CLDC, elle n'est absolument pas compatible avec MIDP. Autrement dit, un MIDlet, qui correspond à une application développée pour MIDP, ne peut pas être exécutée sur un téléphone DoCoMo.
Afin de vous faire une idée plus précise de cette implémentation, brossons un aperçu des principales différences entre i-Mode et MIDP.
La première différence porte sur l'API elle-même. MIDP repose sur les classes suivantes :

- javax.microedition.midlet
- javax.microedition.lcdui
- javax.microedition.rms
- javax.microedition.io

Tandis que i-Mode repose sur celles-ci :

- com.nttdocomo.io
- com.nttdocomo.util
- com.nttdocomo.ui
- com.nttdocomo.net
- javax.microedition.io

La seconde différence est qu'une application DoCoMo, que l'on appelle une iAppli, étend com.nttdocomo.ui.IApplication tandis qu'une application MIDP, que l'on appelle un MIDlet, étend javax.microedition.midlet. De plus, une iAppli implémente une méthode obligatoire, start(), et deux méthodes optionnelles, resume() et terminate(). De son côté, un MIDlet implémente trois méthodes obligatoires, startApp(), pauseApp() et destroyApp().
La troisième différence concerne le mécanisme d'OTA (Over The Air). Tandis que MIDP repose sur des fichiers .jad, une iAppli repose sur des fichiers .jam contenant des champs. Voici un exemple de fichier jam :

AppNamec=HelloWorld
AppVer=1.0
PackageURL=HelloWorld.jar
AppSize=1000
KvmVer=1.0
SPsize=0
AppClass=HelloWorld
AppParam=arg
LastModified=Wed, 01 June 2002 12:00:00

La quatrième et dernière grande différence concerne les limitations de la taille des fichiers .jar. Elle est de 10 Ko pour les iAppli tandis qu'elle est de près de 50 Ko pour les MIDlets.

Mais à quoi ressemble une i-Appli ?
Pour illustrer ce que nous venons de voir, voici une même application développée avec MIDP (on parle de MIDlet) et avec DoJa (on parle de iAppli).

MIDlet
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;

public class HelloMidlet extends MIDlet implements CommandListener {
  private Display midletDisplay;
  private Command doneCommand;

  public HelloMidlet() {
    midletDisplay = Display.getDisplay(this);
    doneCommand = new Command("OK", Command.SCREEN, 1);
  }

  public void startApp() {
    TextBox textBox = new TextBox("Midlet", "Hello World", 256, 0);
    textBox.addCommand(doneCommand);
    textBox.setCommandListener( (CommandListener) this);
    midletDisplay.setCurrent(textBox);
  }

  public void pauseApp() {
  }

  public void destroyApp(boolean unconditional) {
  }

  public void commandAction(Command command, Displayable screen) {
    if (command == doneCommand) {
      destroyApp(false);
      notifyDestroyed();
    }
  }
}

iAppli
import com.nttdocomo.ui.*;
import com.nttdocomo.util.*;

public class iAppliSample extends IApplication {
  Panel panel;
  TextBox textBox;

  public iAppliSample() {
    panel new Panel();
    textBox = new TextBox ("Hello world", 10, 5, TextBox.DISPLAY_ANY);
  }

  public void start() {
    panel.add (textBox);
    Display.setCurrent (panel);
  }
}

Environnement de développement
Constituez votre environnement de développement complet :

- J2SE (notamment pour le compilateur) : http://java.sun.com/j2se/1.3/
- Configuration CLDC : http://java.sun.com/products/cldc
- Profil MIDP : http://java.sun.com/products/midp
- Toolkit J2ME Wireless : http://java.sun.com/products/j2mewtoolkit
- Emulateur Java for i-Mode : http://uni-labo.com/products/iEmulator/eindex.html
- Un autre émulateur Java for i-Mode : http://www.zentek.com/i-JADE/en/index.html