Xebia Mobile Application Contest : Java FX – Android – iPhone

Fonctionnement du contest

Dans le cadre de nos XKE (formations internes), beaucoup d’entre nous ont émis le souhait d’étendre leur champ de compétence au développement d’application sur téléphone mobile. Nous avions plusieurs technologies dans nos bagages : l’installé iPhone (à première vue pas vraiment compatible avec des développeurs Java), l’étoile montante Android, et l’outsider JavaFx.
Mais pour voir au-delà des promesses marketing, il nous fallait nous mesurer à ces technologies dans le cadre de leur utilisation réelle, sur un projet de la ‘vraie vie’. Ainsi est née l’idée de ce contest : 3 technologies, 3 développeurs Java (Amin Fathallah sur iPhone, Erwan Alliaume sur Android, Pablo Lopez sur JavaFx), et un mois (sur notre temps libre) pour traiter d’un sujet choisi par nos collègues : afficher sur le téléphone mobile l’ensemble des photos Flickr à proximité de l’utilisateur géolocalisées sur une carte. Chaque technologie a donné lieu à une démo en live et une analyse du ressenti lors du XKE suivant.

Résultats et commentaires

Commençons par un survol des démos : JavaFx très poussif, sur émulateur. Pas un franc succès. Android sur un G1 flambant neuf, très convaincant, notamment par les divers ajouts hors cahier des charges. Large vainqueur à l’applaudimètre, l’iPhone, avec une UI très soignée et des effets graphiques à la hauteur de la réputation du célèbre terminal.

Dans le même ordre, voici l’analyse de chacun des développeurs.

Java FX Mobile (SDK 1.1)

Mes premières heures de développement de l’application m’ont confirmé mes a priori : cela n’allait pas être facile. Il n’existe pas à ma connaissance de composant JavaFx permettant de simplement se géolocaliser sur une carte, qui plus est si la source cartographique est gratuite (type Google). On croise quelques API J2ME offrant ce service, mais rien de bien convaincant en open source.
Direction donc le capot et c’est parti pour une séance de ‘mains dans le cambouis’ : en utilisant l’API statique de Google et quelques astuces J2ME pour récupérer les coordonnées GPS, on peut s’en sortir.
Un petit tour ensuite sur les tutoriels officiels qui expliquent clairement comment récupérer des images flickR et les binder sur des composants JavaFx.
Et là commencent les ennuis réels, à savoir la gestion de l’affichage. J’ai eu la désagréable impression de revenir aux tous premiers temps de Swing : pas de layout (j’ai volontairement (faute de temps) laissé de côté les quelques frameworks open source proposant quelques composants graphiques de haut niveau) et donc tous les éléments doivent être ‘positionnés à la main’ (entraînant toutes les éventuelles problématiques de resize…). Un simple exemple pour illustrer mon propos : pour encadrer une miniature flickR, il faut récupérer les dimensions de la miniature et dessiner programmatiquement ‘sous’ celle-ci un rectangle de quelques pixels plus grand… Pas idéal.

Ajoutez à cela des plugins pour NetBeans et Eclipse défaillants (pas d’auto-complétion, mauvaise gestion des imports, marquage d’erreurs inexistantes, et pas de composition graphique…)

Peut être est ce la faute à une fonction de refactoring inexistante, mais mon code est rapidement devenu fouilli, et j’avais parfois du mal à m’y retrouver entre déclarations, binds et implémentations des fonctions.

Malgré tout, l’objectif est en partie atteint : l’application géolocalise l’utilisateur (en passant par la couche J2ME ‘pure’), affiche la carte et les miniatures, et permet de les zoomer / dézoomer, même si tout cela reste très artisanal.

Enfin, et à mon grand désespoir, contrairement à ce qui était sous-entendu dans nombre d’interviews des dirigeants de Sun à la sortie du Sdk 1.1, les terminaux mobiles du marché ne sont pas prêts à accueillir JavaFx. Il n’existe à ce jour aucun moyen de déployer des applications sur les téléphones du marché. Pour cela, il faudra attendre les terminaux ‘JavaFx ready’ que l’on nous promet pour JavaOne.
Faute de mieux, j’ai dû réaliser ma démo sur l’émulateur (qui soit dit en passant est bien réalisé et très agréable à utiliser), avec toutes les interrogations que cela comporte (pas de limitation mémoire par exemple…)

Pour conclure, on entrevoit nettement les possibilités offertes par le langage de Sun, mais de nombreux obstacles (pitié, un environnement de développement digne de ce nom) viennent rapidement ternir le tableau et laisse JavaFx sur le bord de la route, loin derrière ses concurrents directs sur mobile.

plus
  1. Des possibilités intéressantes
  2. De nombreuses ressources (officielles ou non)
  3. Un émulateur fonctionnel
moins
  1. Langage loin d’être production ready
  2. Pas d’API / de composants graphiques de haut niveau
  3. Un environnement de développement réduit au strict minimum
javafx javafx

Android

Il n’aura fallu que 3h (si si) pour répondre au cahier des charges : afficher des photos FlickR géolocalisées sur une carte. Entre la MapView, directement disponible dans le SDK Android et le wrapper Java de l’api FlickR téléchargeable sur internet, très peu de code fut nécessaire pour développer les bases de cette application. Et c’est là toute la force d’Android !

D’autre part, contrairement à mes camarades, je n’ai pas eu à me préoccuper de toutes les connexions réseau. La carte se met à jour automatiquement et la communication vers le site de FlickR s’effectue par simple choix de protocole (REST ou SOAP).

Une fois ce POC terminé, seul un gros travail d’enrobage restait à effectuer :

  • L’affichage des photos sur la map a nécessité la création d’un Overlay spécifique, la récupération des coordonnées GPS est passée par l’intermédiaire du LocationManager
  • La création du menu est aussi simple que d’ajouter des éléments dans une liste
  • L’édition des préférences s’effectue par simple description XML des écrans associés. Android se charge de sauvegarder celles-ci et de les rendre disponibles au reste de l’application
  • Externalisation de la recherche et récupération des informations des photos FlickR dans un service exécuté en background de l’application. Ainsi, l’UI ne reste pas bloquée lors de la récupération des photos. La communication entre le service et le front s’effectue par l’intermédiaire de messages : les Intent
  • Ajout de messages Toast, popup et notifications système en faisant vibrer le téléphone en rythme, juste histoire de jouer un peu avec le SDK
  • Affichage d’une preview vidéo de l’appareil photo du G1 sur un canvas, il s’agit d’un point de départ à une fonctionnalité d’upload de photos FlickR

La communauté Android est assez active, il est aisé de trouver une solution à la plupart des questions et problèmes que vous pouvez rencontrer. De plus, la documentation officielle est plutôt bien fournie, même si elle souffre de quelques lacunes : certaines notions fondamentales comme les ‘Intent’ y sont par exemple mal expliquées.

Tout cela fait que les développeurs Java ne devraient avoir aucun mal à se lancer dans l’aventure. D’ailleurs suite à la première présentation Android effectuée lors du XKE de mars, quelques-uns d’entre nous se sont essayés à écrire leurs propres applications : programme TV, Tetris…

plus
  1. Environnement et programmation full Java
  2. SDK puissant et relativement simple à utiliser
  3. Utilisation possible d’api java existantes
  4. Licence développeur donnant l’accès au market peu onéreuse (25 €)
moins
  1. Technologie naissante
  2. Widgets et vues moins beaux que sur l’iPhone
  3. Premiers mobiles qualifiés par certains de ‘moches’
android-map android-menu android-notif android-prefs

iPhone

Il m’a fallu attendre 2 semaines pour répondre au cahier des charges. L’api MapKit n’est pas accessible par les développeurs dans les versions 2.x.x du SDK d’iPhone. Heureusement, la nouvelle version 3.0 en beta est sortie avant la présentation des résultats. J’ai passé pas mal de temps pour comprendre l’utilisation des composants MkMapView et MkAnnotationView. Le résultat est impressionnant. Une carte très fluide annotée avec plus de 300 photos téléchargées en mode asynchrone.

D’autre part, à l’instar des concurrents, j’ai développé plus de fonctionnalités pour 50 heures de travail :

  • Localisation des coordonnées GPS (longitude, latitude) de l’utilisateur.
  • Téléchargement des photos en mode asynchrone.
  • Cache des photos téléchargées.
  • Affichage des photos en liste.
  • Affichage des détails d’une photo (nom, auteur, commentaires).
  • Affichage des photos en taille réelle.
  • Affichage de toutes les photos au format tableau.
  • Affichage de la position de l’utilisateur sur la carte.
  • Annotation de la carte avec plus de 300 photos.

La récupération des photos et de leurs informations de FlickR s’effectue par le protocole REST en mode asynchrone.

Une fois le développement terminé, j’ai passé beaucoup de temps pour déployer l’application sur l’iPhone. Plusieurs étapes sont nécessaires pour créer un profil développeur et pour générer les certificats nécessaires pour le déploiement de l’application sur l’iPhone.

Les développeurs Java auront du mal à se lancer dans l’aventure. La prise en main de l’iPhone SDK nécessite beaucoup de temps. Il faut apprendre un nouveau langage (Objective-C) et de nouveaux outils pour se lancer dans le développement (Xcode, Interface builder, Instruments, Shark).

La richesse des frameworks dépasse de loin celles des concurrents. La maturité des frameworks Cocoa utilisés comme couche basse de l’iPhone OS donne aussi un grand avantage à l’iPhone SDK.

plus
  1. Un téléphone sexy
  2. Multi-Touch
  3. Technologie mature
  4. Outils de développement complets et simples d’utilisation
  5. SDK puissant, complet et relativement simple à utiliser
  6. Beaucoup de composants graphiques de haut niveau
moins
  1. L’iPhone SDK nécessite un MAC OS X 10.5.4+
  2. Langage de programmation complexe
  3. Licence développeur payante (99$)
iphone1 iphone2 iphone3 iphone4
iphone5 iphone6 iphone7 iphone8

Conclusions

Bien qu’il soit difficile de tirer de grands enseignements généraux sur des technologies ayant un vécu et un parcours si différent on retiendra :

  • l’iPhone est définitivement le grand gagnant de l’expérience utilisateur. Mais la prise en main du langage peut constituer un très grand frein à l’adoption de cette technologie par les développeurs Java.
  • le Google Phone constitue la bonne surprise de ce contest. Le développement en full Java parle aux techniciens que nous sommes, et l’expérience utilisateur, même si elle n’est pas à la hauteur de celle que peut proposer l’iPhone, est très convaincante.
  • l’hypothétique JavaFxPhone reste sur le bord de la route. Même si les possibilités entrevues sont prometteuses, le manque de maturité de l’ensemble le condamne à rester dans l’ombre de ses concurrents, dans l’attente d’une version plus aboutie et plus riche.

Billets sur le même thème :

12 commentaires

  • très beau billet, bravo!
    c’est une bonne façon de se mettre en situation pour tester une technologie. C’est assez proche de la réalité. Néanmoins.. aviez vous tous le même niveau de connaissance sur la technologie utilisée au départ?

  • Non en effet, nous n’avions pas tous le même niveau de départ. D’ailleurs, pour ma part, j’avais déjà eu l’occasion de faire de petits développements sous Android avant le contest. Du coup, j’ai peut-être eu le moins de mal à répondre rapidement au cahier des charges, et pourtant, au final, je ne suis pas sortit grand vainqueur de ce contest.

    Erwan (Xebia)

  • Quelle version de JavaFX? La 1.2 apporte une première série de widgets.

    « Langage loin d’être production ready » : est-ce qu’il faut comprendre que c’est bien le langage (JavaFX Script) qui n’est pas mûr?

    L’utilisation de FX mobile sur un téléphone ne nécessite pas d’attendre de nouveaux terminaux, mais une pile optimisée (GC, threads, mémoire, etc…) pour des téléphones existants comme le HTC Diamond vendu à JavaOne au début du mois. Il arrive aux « dirigeants de Sun » de dire des bêtises, mais pas là ;)

    Enfin, peut-on dire que « Environnement et programmation full Java » et « Utilisation possible d’api java existantes » s’appliquent aussi à JavaFX?

  • Bonjour,

    suis-je le seul à trouver rebutant qu’il faille MAC OS et que la license soit si élevée sur l’iPhone? Car s’il est courant de travailler sur des systèmes Windows ou unix, tout le monde n’a pas envie d’installer un OS juste pour faire du dev sur iPhone…
    Au vu de ce test, je reste plus convaincu par le futur d’Android (google a eu raison de moi, je le crains) que par l’iphone ou javafx.
    En tout cas, merci pour ce test et pour tous les autres billets :)

  • Bonjour Alexis
    Ce contest a été réalisé en avril, en utilisant donc un Sdk 1.1 (article mis à jour)
    Quand j’écris « Langage loin d’être production ready » , je parle non seulement du script, mais aussi de tout l’environnement qui l’accompagne.
    En avril, lorsque j’ai posé la question sur le déploiement, la réponse qui m’a été fournie a été « il n’est pas possible [pour le grand public] de déployer sur un terminal avant l’arrivée des terminaux JavaFx ready ».
    Si par ‘pile optimisée’, vous sous-entendez un flashage complet du téléphone, je maintiens que les ’2 milliards de terminaux Java ready sur le marché’ ne sont pas (encore ?) JavaFx ready.

    En ce qui concerne la comparaison avec le « full Java d’Android », il serait plus juste de dire « JavaFx n’est pas full J2SE ». Pour illustrer mon propos, en plus de la différence entre les langages FxScript et Java, certaines classes très utilisées de J2SE sont indisponibles dans le profil mobile standard (sans avoir à manipuler les toujours mystérieuses JSR J2ME), à l’instar de java.io.Serializable, qui est par exemple nécessaire pour utiliser l’API FlickrJ. Je n’ai pas encore eu le loisir de tester beaucoup d’API externes avec le profil mobile.

    Cependant, ce que j’ai pu voir sur la version 1.2 me fait espérer que JavaFx a un avenir : le plugin eclipse est maintenant réintégré à la home page JavaFx, et les premiers widgets montrent que Sun et la communauté se mobilisent autour de cet axe d’amélioration.

    Pablo (Xebia)

  • Pablo, merci pour cette réponse. Pour être plus précis, sur le language, quel sont les faiblesses? La question n’est pas rhétorique ;)
    Pour les téléphones le problème c’est pas lié au flashage, mais à la disponibilité d’un runtime optimisé (en cours de dev et d’intégration). Le provisioning OTA de FX est pour bientôt.

  • Alexis,
    Merci pour la confirmation de l’arrivée d’un provisioning Over The Air. Cette fonctionnalité pourrait être un facteur différenciant dans l’adoption de JavaFx sur les mobiles.

    Concernant le langage, je me suis peut être mal exprimé. Une fois passée la phase d’apprentissage, je pense que le FxScript est une bonne idée en soit, même si la grammaire est parfois déroutante pour un Javaiste (celà reste un nouveau langage à appréhender). Alléger le code source de l’UI en y dédiant un langage scripté me parait un principe sain (surtout quand on compare du script Fx à du Swing).

    La réelle souffrance provient de la difficulté à manipuler ce langage sans IDE adapté (pas d’auto complétion, d’exploration hiérarchique, de refactoring, d’assistance graphique).
    Il est donc difficile de se faire une réelle idée sur la richesse de ce langage, même si certains de ses principes nous ont d’ores et déjà séduits (comme le binding par exemple (voir notre premier retour d’expérience sur JavaFx))

    Pablo (Xebia)

  • Salut,
    Cet article est intéresant, mais il manque plusieurs systèmes. Pourquoi ne pas avoir testé avec un SDK Windows Mobile ou Symbian ?
    Ils sont quand même plus représentatifs en terme de nombre de téléphone installé que l’Iphone ou Android….

  • Ce sont ces frameworks qui nous semblaient les plus intéressants à comparer. D’ailleurs le choix des technologies du contest s’est fait sur la base du volontariat : il s’agit donc d’une sélection naturelle. :)

    Par ailleurs, pour avoir fait partit d’un laboratoire de développement mobile il y a quelques années, je suis toujours a minima l’actualité autour des autres technologies. Ce n’est pas parce que l’on s’est focalisé sur ces frameworks ’nouvelle génération’ que d’autres technologies n’offrent pas de solution au problème demandé. Par exemple, les Micro et Compact Framework DotNet proposent entre autres des intégrations similaires à Google Map et à FlickR.

    Si vous désirez compléter cet article par vos propres retours d’expériences, n’hésitez pas à laisser vos commentaires.

    Erwan (Xebia)

  • Le choix d’une technologie pour développer ses applications repose également sur le temps d’apprentissage (iPhone est, comme le dit l’article, très ardue) et le marché, le ROI possible.
    iPhone aujourd’hui c’est un seul matériel (enfin 1 constructeur), Android c’est 3 matériels aujourd’hui mais…20 d’ici la fin de l’année, et des devices différents.
    C’est un autre débat mais quelles seront les parts de marché en terme de business l’année prochaine? Quel OS sera le plus répandu?
    Si on répond Android aux précédentes questions, on peut penser que Android est le grand gagnant de ce test d’un point de vue business et ROI.

  • Bonjour,

    merci pour cette etude tres interessante et motivante !
    Realiser une etude de ce genre en mode ‘contest’ est une
    grande reussite et un gage de pragmatisme.

    Je retiens principalement que Android est dans la bonne
    direction : la liste des composants s’enrichira pour arriver
    au niveau de ceux de l’Iphone.

    Et le choix en matiere de materiel va favoriser l’emergence
    rapide de terminaux Android performants et bon marché.

    En fait, j’ai l’impression de revoir la bataille Microsoft/Apple
    pour la conquete du poste de travail. A vu de nez, l’histoire se
    repete. A l’en croire, on peut predire le succès d’Android sur le
    moyen terme.

    Time will tell.

  • Pour info, et pour ceux qui veulent développer pour iPhone en Java, le produit iSpectrum permet de développer pour iPhone en Java sous Eclipse. Voir http://www.flexycore.com pour plus d’info si cela vous intéresse.

Laisser un commentaire