|
"Le marché du développement mobile a besoin de se structurer"
Spécialiste J2ME, Bruno Delb décrit le mode de développement Java mobile habituel, et en pointe le problème majeur, à savoir la nécessité de réaliser des tests réels plutôt que sur émulateur. Sa solution : le développement unifié.
(20/09/2006)
|
| |
|
 |
|
| Bruno Delb est PDG de la société Unified Mobiles |
| |
|
|
|
Un marché du jeu sur mobile en explosion, un nombre de modèles de téléphones mobiles en constante augmentation, une montée en complexité des fonctionnalités Java des mobiles
des coûts de développement qui doivent intégrer des coûts de portage et de personnalisation également en explosion. Le marché a besoin de se structurer.
Plus de 1200 modèles de mobiles Java sont sur le marché à travers le monde. Ces mobiles ont des caractéristiques très différentes les uns des autres : taille de l'écran, disposition des touches, mémoire disponible,
Les mobiles ont également des éléments optionnels, en particulier au niveau de Java, par exemple Bluetooth, la 3D, la prise de photo, l'enregistrement audio, le SMS (envoi et réception), le MMS (envoi et réception), etc. Pour pouvoir utiliser ces éléments depuis un programme Java, le mobile doit être équipé de l'API Java correspondante, ce qui n'est pas systématique. Les mobiles ne sont pas exempts de bugs tant au niveau de la machine virtuelle que du système d'exploitation. Enfin, les standards ont parfois des zones de flou et peuvent être tout simplement mal interprétés.
| |
| "Toute opération ralentissant le processus diminue les bénéfices de la solution"
|
| |
La conséquence est que pour pouvoir distribuer une application sur 200 modèles de mobiles différents, il est nécessaire de gérer en parallèle quasiment autant de versions dès lors que l'application tire parti des options de chaque mobile. Bien sûr, moins l'application utilise les spécificités de chaque mobile, moins il sera nécessaire de gérer de versions différentes. Ainsi, pour un jeu n'utilisant que le graphisme, le son et le stockage de données en local (pour les meilleurs scores), par exemple de 100 à 120 versions différentes peuvent être nécessaires.
D'autres paramètres viennent encore complexifier la situation, comme le support multilangues, qui nécessite souvent de générer une version pour chaque langue, ou encore le réseau de l'opérateur mobile, dont dépend les accès réseau depuis une application Java, utilisé par exemple comme pour les jeux multijoueurs en réseau.
Toute opération manuelle effectuée par le développeur est donc répétée autant de fois qu'il y a de modèles de mobiles sur lesquels l'application doit tourner.
Bien qu'à ce jour le portage soit encore effectué souvent manuellement en interne ou en offshore, il est vital d'automatiser ce procès, ce qui suppose de fluidifier chaque étape : codage, compilation, test sur émulateur, déploiement,
Au-delà de l'opération de portage proprement dite, qui consiste à adapter une application à différentes plates-formes, la problématique de configurabilité des fonctionnalités Java des mobiles est non moins complexe. Il s'agit de personnaliser l'application aux capacités maximales Java de chaque mobile, permettant ainsi d'utiliser le Bluetooth lorsqu'il est disponible, ou le SMS, le MMS, la prise de photo, etc.
L'opération de portage
L'état de l'art du portage consiste à ce que le développeur écrive une application de référence. Cette application doit d'abord être développée sur un mobile à ressources limitées, voire trois ou quatre gabarits très différents déterminés par les paramètres (heap memory disponible, taille maximale du fichier JAR,
). Il est en effet beaucoup plus simple d'ajouter des fonctionnalités à une application que d'en retirer.
Cette application est ensuite adaptée à chaque modèle de mobile. Ceci se fait à deux niveaux. Tout d'abord, le code source est adapté en activant des portions de code source et en en désactivant d'autres. D'autre part, les ressources comme les images et les sons sont adaptés en fonction des capacités de chaque modèle de mobile. Enfin, des données complémentaires (textes, niveaux de jeux,
) sont intégrées dans l'application.
Les contraintes du modèle de mobile doivent bien sûr être prises en compte pour adapter le comportement de l'application : taille maximale de l'application, mémoire disponible pour l'exécution (heap memory), taille maximale du RMS (ou scratchpad pour DoJa), etc
L'application doit être assez robuste pour fonctionner sans désagrément pour l'utilisateur final dans un environnement complexe, notamment en cas d'appel vocal entrant ou d'arrivée de SMS (l'application doit alors s'interrompre et reprendre à la fin de l'interruption), en cas de connectivité défectueuse (interruption du réseau mobile,
).
Par ailleurs, la solution doit être capable de supporter un maximum de plates-formes (J2ME, DoJa) ainsi que les fonctionnalités optionnelles des mobiles (comme l'utilisation de l'appareil photo du mobile, l'accès au système de fichier du mobile, l'envoi et la réception de MMS,
).
L'architecture également est très importante : la priorité est la rapidité et la fiabilité du processus global. Ce processus suit plusieurs étapes :
-
codage d'une application de référence sur un modèle de référence,
-
portage sur l'ensemble des modèles de mobile à supporter
personnalisation de l'application en fonction de la configuration de chaque modèle de mobile,
-
test sur émulateur,
-
test sur téléphone mobile réel.
| |
| "Le test sur émulateur n'est pas suffisant, la validation sur téléphone réel est nécessaire"
|
| |
Toute opération ralentissant le processus diminue les bénéfices de la solution.
Etape 1 - Codage
Le développeur doit conserver un contrôle total sur son code source. Il doit pouvoir faire des modifications ciblées et rapides de son code, y compris pour une famille de modèles de mobile ou pour un modèle précis.
Le développeur devant respecter certaines règles lors du développement de l'application, tous les efforts visant à limiter ses efforts d'adaptation doivent être menés en respectant ses habitudes.
Etape 2 - Portage
Le portage nécessite au minimum d'adapter le code source, les ressources, le tout en prenant en charge les éléments du mobile et en prenant en compte ses capacités.
La solution de portage doit prendre en charge les différents éléments du mobile : clavier (prise en charge des constantes associées aux touches, gestion des softkeys, support de la répétition des touches, réaffectation des touches du clavier,
), écran (support du plein écran, régulation des frames, gestion des sprites,
), son (support de la musique, support des sons naturels type Wave, optimisation des sons,
), mémoire (appel automatique du ramasse-miettes, réduction de la mémoire consommée,
).
Etape 2.1 - Adaptation du code source
Il existe quatre grandes méthodes pour porter du code source.
La première consiste à modifier le byte-code. Ce type d'approche ne peut que constituer une solution complémentaire, car elle a ses limites et des contraintes fortes.
La seconde repose sur l'adaptation dynamiquement au modèle de mobile sur lequel tourne l'application. Ceci suppose d'embarquer dans chaque application le comportement de tous les mobiles, ce qui est bien sûr illusoire.
La troisième alternative consiste à utiliser des classes différentes en fonction du modèle de mobile, ce qui est une approche saine en soi, mais qui est trop limitée, car les différences entre les mobiles ne se limitent pas à simplement une énumération de caractéristiques.
La dernière option, la seule qui soit réellement viable, est celle de l'utilisation d'un préprocesseur.
Etape 2.2 - Adaptation des ressources
La solution doit adapter les images aux formats supportés par le mobile. Si celui-ci supporte différents formats, le meilleur doit être sélectionné automatiquement en fonction du contenu de chaque image.
La solution doit également supporter les images plein-écran, qui posent de gros problèmes d'ordre technique, puisque les images doivent conserver leur ratio, or les écrans des mobiles ont des ratios d'écran différents.
Le format des sons doit être choisi de manière judicieuse, en fonction de la nature du son (musique, son naturel) et du volume occupé.
Etape 2.3 - Optimisation
La solution doit optimiser les ressources ainsi que le code de l'application afin de tenir compte des limitations spécifiques à chaque modèle de mobile.
Le système doit privilégier la génération automatique des images dynamiquement, en cours d'exécution, chaque fois que cela est possible. Par exemple, l'image correspondant au personnage se déplaçant à gauche doit être réalisée par symétrie de l'image correspondant au personnage se déplaçant à droite chaque fois que possible en cours d'exécution, ce afin de limiter la taille de l'application. Cependant, si cela n'est pas possible, la solution de portage devra effectuer cette transformation en amont et stocker les deux images dans l'application déployée.
Les images étant de gros volume, plusieurs techniques permettent de limiter leur taille, mais quasiment toujours au détriment des performances : regroupement des petites images, optimisation des fichiers d'image,
La consommation de la mémoire doit être limitée au maximum. La solution doit donc aider à décharger les objets dès qu'ils ne sont plus utilisés, ce qui est particulièrement important pour les images, les sons, les tableaux de données et les autres objets volumineux.
De même, le mécanisme de rafraîchissement de l'écran est un goulot d'étranglement. C'est notamment lui qui permet de produire une application plus ou moins fluide. Il existe plusieurs paramètres d'ajustage permettant des gains de performance en fonction du modèle de mobile.
Le son est souvent un problème, notamment pour la latence qui peut apparaître au moment de jouer le son. Il est donc nécessaire d'optimiser ce fonctionnement.
Etape 3 - Test
Une fois l'application portée et optimisée à chaque modèle de mobile, elle doit être testée puis validée sur les mobiles. Si les performances ne sont pas suffisantes, il sera nécessaire de l'optimiser à nouveau.
Emulation
Un bon émulateur est un émulateur qui reproduit parfaitement fidèlement les dysfonctionnements des téléphones mobiles réels. Malheureusement, ces émulateurs n'atteignent que plus ou moins leurs objectifs. Il est donc absolument nécessaire de faire un test sur des mobiles réels, ce qui pose un problème de disponibilité des mobiles.
Certains fabricants proposent leurs propres émulateurs. De son côté, Sun Microsystems propose un émulateur générique.
Cependant, chacun a une taille d'écran fixe, qui ne correspond en général pas à la taille réelle de l'écran du mobile, ce qui est une véritable difficulté pour le test.
Le test sur émulateur n'est donc pas suffisant, la validation sur téléphone réel est nécessaire. Des centres de test de mobiles, locaux ou à distance, commencent à voir le jour.
Test sur mobile réel
L'application peut alors être testée sur mobile réel. Pour cela, vous devez avoir à disposition les mobiles à tester. La solution peut alors vous aider à déployer l'application sur votre mobile, via WAP (OTA - Over The Air), Bluetooth, infrarouge ou par câble. En particulier, les aspects nommage des fichiers sont très importants. La solution doit être capable d'être suffisamment souple pour intégrer des spécificités de chaque distributeur ou pour certains mobiles.
Personnalisation aux fonctionnalités de chaque mobile
L'application doit tenir compte des capacités maximales du mobile. Par exemple, si le mobile supporte une taille réduite d'application, le nombre d'images incluses dans l'application doit être réduit. Par exemple, l'image associée au ciel sera remplacée dans ce mobile par un fond d'écran bleu uni dessiné par une simple instruction Java.
La solution doit aussi permettre d'ajouter des fonctionnalités optionnelles. Par exemple, si le mobile supporte la prise de photos, alors il peut être proposé au joueur d'en prendre une pour personnaliser son jeu. Sinon, le joueur doit choisir une image dans une galerie prédéfinie.
Les accès à Internet depuis une application mobile Java sont également source de problème. De nombreux paramètres sont à intégrer : réseau mobile sur lequel tourne l'application, configuration réseau du mobile, stabilité de la communication réseau,
|
Bruno Delb |
Bruno Delb, consultant auprès de l'ETSI concernant les problèmes d'interopérabilité des applications J2ME, est fondateur de la société Net Innovations et auteur du premier livre francophone sur J2ME, « J2ME Applications Java pour terminaux mobiles », chez Eyrolles.
En 2006, il crée Unified Mobiles.
La société a créé un framework, UMAK, introduisant le développement unifié d'applications mobiles, qui permet à partir d'un même code source de développer de manière identique pour des plates-formes hétérogènes. |
|
|
