Développer des applications mobiles multiplateformes avec Java… avec le framework Codename One

14
26
juil.
2015
Java

Codename One est un framework permettant de développer en natif pour iOS, Android, BlackBerry et Windows Phone à partir d'un unique code Java.

Il est open-source (licence GPL avec exception Classpath) et se présente sous la forme d'un plug-in disponible pour les trois environnements de développement majeurs en Java (NetBeans, Eclipse, IntelliJ IDEA (NdM: les deux premiers sont sous licence libre, le dernier existe en version "Community" libre et en version propriétaire). Il a pour particularité d’utiliser le cloud pour la compilation, ce qui évite aux développeurs d'avoir à installer divers SDK ou de posséder un système d’exploitation spécifique indispensable à la programmation des applications pour certaines plateformes mobiles.

Il a été créé par deux anciens ingénieurs d'Oracle, Chen Fishbein et Shai Almog, ceux-là mêmes qui mirent au point la bibliothèque d'interface graphique LWUIT, qui eut son âge d'or à l'heure où le J2ME régnait encore dans le monde de la téléphonie avant d'être détrôné par l'iPhone.

Codename One produit du code natif optimisé, assurant à ses applications de meilleures performances. (NdM: l'accès au code source natif produit n'est pas fourni dans l'offre gratuite de Codename One).

Le plug-in est composé d'une API contenant toutes les classes nécessaires à la conception d'une application mobile, d'un designer, d'un simulateur pour tester les applications sur son ordinateur et du serveur de compilation dans le cloud.

L’une des grandes particularités de Codename One est son architecture dite « lightweight » qui apporte une meilleure solution aux problèmes de fragmentation des plateformes mobiles. Un composant lightweight dans ce cas-ci est un composant écrit entièrement en Java qui dessine sa propre interface tout en gérant ses propres événements et états. Cette manière de faire apporte un énorme avantage en termes de portabilité puisque le même code est exécuté sur toutes les plateformes en plus d’autres avantages. Les composants graphiques de Codename One sont personnalisables.

L’API de Codename One couvre de nombreuses fonctionnalités. On peut y trouver ce qu’il faut pour faire, par exemple, les tâches suivantes :

  • l'interface graphique ;
  • la manipulation de la vidéo et de l’audio (enregistrement comme affichage) ;
  • le stockage ;
  • l'accès à la caméra ;
  • la manipulation d'une base de données SQLite ;
  • la manipulation des services web ;
  • le réseau ;
  • l'accès au cloud ;
  • la lecture des codes barres et QR codes ;
  • l’internationalisation et la localisation ;
  • les notifications ;
  • la manipulation des contacts ;
  • l'accès aux pages web ;
  • la monétisation ;
  • l’accès aux réseaux sociaux ;
  • la géolocalisation ;
  • les tests unitaires ;
  • la création de thèmes personnalisés ;
  • etc.

Codename One est orienté exclusivement vers la conception d’applications métiers et n’a pas du tout été pensé pour créer des jeux. Quelques efforts sont en train d’être faits dans ce sens, mais rien de concret n’est encore disponible de ce côté.

Pour s'y former, vous disposez de la documentation officielle, complétée par de nombreux articles et tutoriels vidéo, ainsi qu'un forum très actif (en anglais). En outre, un livre vient de paraître en français aux éditions D-BookeR.

  • # Embarquer la jvm sur une app ?

    Posté par (page perso) . Évalué à -2.

    Autant pour android la jvm (enfin dalvik, l'implémentation custom android) est déjà fournie, autant pour iOS, BlackBerry et Windows Phone on se retrouve à devoir la packager avec sur son app ?
    Je suis très étonné de la viabilité de ce choix:

    • poids de l'app avec une jvm (j'imagine qu'on peut stripper toutes les bibliothèques non utilisées mais ça doit comme même représenter quelque chose in fine)
    • consommation de ram en hausse, non seulement à cause de java (coucou mon téléphone Android qui n'arrive pas à lancer plus de 2 apps à la fois avec 1Go…) mais surtout car chaque app utilisant ce framework aura sa propre instance de jvm lancée (donc pas de partage de mémoire possible)
    • performances, java est performant à partir du moment où la ram disponible (comprendre le gros bloc de ram qu'il se réseve au démarrage de la jvm) est très supérieur (j'avais lu quelque part 7 fois plus pour être optimal) à celle nécessaire pour faire tourner l'application. Vu que chaque instance de jvm est indépendante l'action de réserver un bloc de mémoire se fait par app, d'où soit une accentuation de la surconsommation (je réserve 500mo pour mon app alors qu'au final elle ne va consommer que 400) ou bien un écroulement des perfs (je réserve 300mo pour mon app, le garbage collector doit travailler plus souvent pour limiter la conso mémoire)

    Maintenant je ne suis pas un expert Java, donc ce serait cool si quelqu'un de plus calé pouvait m'expliquer comment ces points on pu être résolus

    • [^] # Re: Embarquer la jvm sur une app ?

      Posté par (page perso) . Évalué à 8.

      De ce que j'en ai compris, il n'y a pas de JVM. Le code Java est compilé en code natif et non en bytecode. Il est donc juste nécessaire d'avoir un runtime.

      Et de toute façon, sauf si Apple a changé son fusil d'épaule, l'utilisation des VM n'est pas autorisée sur l'AppleStore.

      • [^] # Re: Embarquer la jvm sur une app ?

        Posté par . Évalué à 2.

        @G.bleu : Rassurez-vous, il n’y a pas de JVM à embarquer. Il y a de la génération de code avant la compilation dans le cloud. Les fichiers .class et ressources du projet sont envoyés vers le serveur pour la compilation. Avant cette compilation, il y a de la génération de code (toujours sur le serveur) à partir du bytecode. Pour les utilisateurs pro, il est possible de récupérer ce code source s’ils le veulent. Ce processus de génération de code avant la compilation se fait pour l’iOS (en C), Android (en Java pour Dalvik) et Windows Phone (en C#). Pour BlackBerry, tout le travail se fait au niveau des bytecodes envoyés sur le serveur. Il s’agit de réelles applications natives donc aucune pénalité. Vous n’avez pas à vous faire du souci pour ça. Vous pouvez effectuer un test et vous serez agréablement surpris. Le plug-in ne fait que 85 Mo et s’intègre facilement avec les 3 environnements de développements majeurs en Java.

  • # Portabilité

    Posté par (page perso) . Évalué à 7. Dernière modification le 26/07/15 à 09:10.

    Est-ce que quelqu'un a déjà testé et peut me faire un retour quant à la portabilité des applications ?

    Pour préciser ma pensée, c'est la portabilité de l'API qui m'intéresse, hors interface graphique. En effet, j'ai eu l'occasion d'utiliser Phonegap pour un projet iOS et Android, et il n'y a rien de plus fatigant que de devoir écrire une couche d'abstraction supplémentaire car l'API fourni de bases n'est pas 100% portable (des différences de comportements subtiles mais suffisamment chi**** pour créer des bugs sur une plateforme et pas sur une autre), rendant la correction de bugs délicates (ok, j'ai réparé sur iOS, mais est-ce que cela fonctionne toujours sur Android ? Et vice-versa.) Et encore, je n'ai testé PhoneGap que sur 2 plateformes. Je suppose qu'en en rajoutant, cela aurait été pire.

    Un exemple de mémoire, j'ai rencontré des problèmes d'incompatibilité lors de la suppression d'un fichier, qui ne générait pas d'erreur si le fichier n'existait pas sur une des deux plateformes alors que oui sur l'autre… Et je sais que j'ai rencontré un autre soucis avec les fichiers. Il faudrait éventuellement que je relise mes notes pour la retrouver :)

    J'ai aussi eu des soucis avec les bases de données SQLite. Du coup, j'ai fais plus simple et tout géré moi-même pour être sur d'avoir un code qui fasse la même chose quelque soit la plateforme.

    J'ai eu le droit à d'autres soucis de ce genre avec un plugin externe (lecteur de QRCode). Mais là, c'est un plugin donc je n'accuse pas phonegap :p

    • [^] # Re: Portabilité

      Posté par . Évalué à 1.

      Oui Francesco, je confirme que l’API est très portable. C’est justement le but principal de Codename One. Il y a quand même certaines fonctionnalités qui ne sont pas disponibles sur les 4 plateformes citées au même moment. En exemple, il y a les notifications push qui n’ont as été implémentées pour Windows phone, mais pour iOS, Android et BlackBerry. Certaines fonctionnalités aussi ne sont pas sur les 4, mais elles sont minimes. En Codename One, tu ne feras presque jamais d’ajustement de code. Les cas sont très rares. Je recommande sincèrement de tester l’API ;-)

  • # multiplateforme?

    Posté par (page perso) . Évalué à 1.

    C'est fou comme quoi maintenant que j'utilise firefoxos, je me rends compte que les gens se foutent completement des OS mobile hors android/ios…

    • [^] # Re: multiplateforme?

      Posté par . Évalué à 4. Dernière modification le 26/07/15 à 10:57.

      Si j'ai bien compris, les applications tierces sur FirefoxOS c'est essentiellement du HTML5, peut-être un peu de Javascript. L'objectif de FirefoxOS est d'être compatible avec les autres plateformes « by design » au travers du navigateur Gecko qui va bien.

      Du coup je ne pense pas que FfOS puisse même être supporté par ce projet (Java compilé != HTML5). Après je peux me tromper.

      • [^] # Re: multiplateforme?

        Posté par . Évalué à 2.

        Les apps firefox os sont en HTML/CSS/javascript (html5 implique quasi automatiquement le js, et de toute façon on parle de langage de programmation ici, le html5 est un langage de markup). Le js fait les appels aux apis comme sur tous les autres os mobiles. Il n'y a aucune raison technique de ne pas pouvoir générer une app FxOs s'ils arrivent à générer des apps IOs par ex.

    • [^] # Re: multiplateforme?

      Posté par (page perso) . Évalué à -1.

      je me rends compte que les gens se foutent completement des OS mobile hors android/ios…

      Dans une dépèche qui dit "pour iOS, Android, BlackBerry et Windows Phone", ce commentaire semble… rigolo.

      maintenant que j'utilise firefoxos, je me rends compte que les gens se foutent completement des OS mobile

      euh… tu utilises un navigateur web uniquement, pas un OS, ou du moins les développeurs n'ont pas accès à une API pour l'OS, donc bon, plaint-toi aux développeurs de ton "OS" qui ne propose pas d'API sorti d'HTML5 (qui ne fait pas tout, loin de la). C'est un choix que de supporter que le web sur un téléphone, après il ne faut pas se plaindre si les développeurs ne suivent pas (tout le monde n'a pas envie de se taper le file API d'HTML pour juste faire un new FileReader("/toto"); ReadLine() ainsi que toutes les limites imposées par FFOS qui sont au niveau de l'iPhone mais sans les utilisateurs)

      • [^] # Re: multiplateforme?

        Posté par (page perso) . Évalué à 2.

        Ma remarque portait sur le titre de la depeche… "Multiplateforme". Certes multiplateforme ne veut pas dire "toutes les plateformes", mais je trouve que sur mobile cela veut trop souvent dire "android+ios".

      • [^] # Re: multiplateforme?

        Posté par . Évalué à 6.

        MMhhh. Tu pourrais me citer une API présente sur Android et IOS qui n'est pas présente sur Firefox OS ? Juste histoire de prouver que tu dis pas n'imp :-)

        C'est un choix que de supporter que le web sur un téléphone

        Tu as déjà coder pour FxOs ? Tu as entendu parlé des Web API ? En gros tu préfères X apis propriétaires distinctes plutôt que 1 multiplateforme (le web) tout aussi puissante ?

        ainsi que toutes les limites imposées par FFOS

        Lesquelles ?

        Bref

        euh… tu utilises un navigateur web uniquement, pas un OS

        Aussi pertinent que de dire aux utilisateurs d'Android qu'ils ont une JVM, pas un OS.

        • [^] # Re: multiplateforme?

          Posté par . Évalué à 1.

          Il me semble qu'une des offres payante permet de sortir une appli web, ça peut possiblement passer sous firefox os.

          Je l'ai testé tout à l'heure et c'est plutôt cool, j'ai fait le petit exemple du hello world et j'ai regardé les autres exemples, c'est limpide. Rien à voir avec la prog Java/Android… Reste un point qui me fait un peu peur, on doit passer par leur serveur pour la compilation, certes c'est pratique, c'est leur business model et tout mais s'ils mettent la clef sous la porte on est un peu embêté. Heuresement il semble possible de compiler en local moyennant quelques bricoles, je vais voir ça de plus près.

          Le livre a l'air pas mal foutu aussi, je l'ai commandé, on verra bien je serai peut être le prochain auteur d'appli à succes :)

          J'ai pas encore pu testé sur un vrai device (j'ai un firefox os) mais juste dans le simulateur, je vois ça demain au taf sur un android vu que j'ai pas de licence dev apple.

  • # en attendant Godot…

    Posté par (page perso) . Évalué à 7.

    En me renseignant sur un jeu apparu sur fdroid, je suis tombé sur le projet godot qui est un framework orienté jeu pour ios, android, linux… (C'est complètement libre).

    Par contre ça nécessite d'apprendre un nouveau langage (gdscript, mais pas trop compliqué à prendre en main), et je ne sais pas trop ce qu'ils couvrent en terme de fonctionnalités.

    Ils ont fait une présentation aux RMLL cette année dons je suppose que certains ici doivent connaître ?

    • [^] # Re: en attendant Godot…

      Posté par . Évalué à 2.

      Oui, c'est très simple d'utilisation, ça évolue vite, et l'export Android fonctionne bien pour la 2d.

      Il y a pas mal de doc et il ne faut pas avoir peur du gdscript.

      Ça vaut pas Unity, mais c'est libre et c'est encore récent..

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.