Codename one a adopté une approche très équilibrée de la portabilité. Je voudrais ajouter un commentaire pragmatique.
Du côté de l'interface utilisateur, CN1 peint toute son interface utilisateur sur une toile fournie par la plate-forme. Elle essaie d'imiter l'aspect et la convivialité natifs de la plate-forme, si vous le choisissez, mais elle n'a pas plus de succès que Swing avec son "aspect et la convivialité natifs de la plate-forme", parce que la plate-forme native change constamment, et que l'aspect et la convivialité "natifs" sont toujours en retrait et, dans la plupart des cas, ne sont pas tout à fait corrects.
Mais, si vous choisissez un look and feel indépendant de la plate-forme (ce qui est en quelque sorte la tendance actuelle), vous n'êtes en aucun cas limité par le jeu de composants par défaut de Codenameone : c'est exactement comme Swing avec son look and feel multiplateforme ("Metal", etc.). Ce qui est une bonne chose.
Du côté du langage : sur iOS, c'est java compilé en C qui est ensuite lié à l'Objective-C écrit à la main, et il n'y a pas de VM groupée, seulement une couche de portabilité. Le plus important ici est le fait que java est compilé en C et non en Objective-C, ce qui le rend plus rapide que le code Objective-C idiomatique, parce qu'il fait des invocations de méthodes virtuelles ou, plus souvent, directes, au lieu de la lenteur de la répartition des messages de l'Objective-C. Ce qui est une bonne chose.
Il peut également sembler un peu plus rapide sur Android, car, tout en utilisant Dalvik/Art, il n'utilise pas l'interface utilisateur native d'Android qui est encombrante par rapport à celle du CN1. La création d'une interface utilisateur dynamique peut donc être plus rapide en cours d'exécution, ce qui est une bonne chose.
L'un des points forts de l'approche CN1 est son émulateur (mis en œuvre sur un canvas JavaFX de bureau) que vous utilisez pour développer des logiciels. L'émulateur utilise le même code d'interface utilisateur et les mêmes API de portabilité que sur les plateformes mobiles et vous permet d'utiliser l'IDE de votre choix pour le débogage. Il redémarre rapidement, et le cycle édition-compilation-exécution est très durable par rapport à Android. Ce qui est bien.
Le deuxième point fort (le principal !) est la nature ouverte de leur bibliothèque d'interface utilisateur, tout le code natif et le traducteur bytecode vers C. Si vous faites quelques efforts, vous pouvez éviter de construire des ports Android/iOS sur leurs fermes et vous détacher de leur révision particulière du produit (mais pas de quelques services à valeur ajoutée qu'ils offrent, qui ne sont pas open source !) En fonction de votre situation, cela peut (ou ne peut pas !) être assez bon pour vous !
Le point faible de Codenameone est sa maturité moins qu'idéale, ce qui signifie que vous pouvez facilement vous tirer une balle dans le pied en utilisant des composants d'interface utilisateur de base, si vous les utilisez de la manière dont ils n'étaient pas destinés à être utilisés. Cela signifie également que sa couche de portabilité Java n'est pas assez grande (et comporte des trous) pour couvrir les besoins de tout le monde, et que vous devrez peut-être utiliser le langage natif à certains endroits, et porter d'autres bibliothèques purement Java également.
De plus, l'état actuel des performances graphiques n'est pas optimal ; si vous avez un tas de texte à l'écran, vous manquerez facilement la limite de temps de 16msec pour l'animation/peinture fluide, cela peut être contourné par le double-buffering, mais cela a aussi ses limites. Heureusement, il y a encore de la place pour l'optimisation dans l'implémentation sur les deux plateformes principales, espérons qu'ils vont l'améliorer.
Dans l'ensemble, Codenameone a un bon créneau en tant que cadre multiplateforme pour plusieurs classes d'applications ; vous pouvez trouver une valeur dans leurs services, aussi.
