Comment fonctionne Codename One?
Je recherche des alternatives à développer pour plusieurs plates-formes mobiles et j'ai trouvé Codename One , qui utilise Java as lingua franca , au lieu de HTML/CSS/JS ou de langages de script.
Ce que je n'ai pas trouvé, c'est comment ça marche. Fournit-il une JVM avec l'application pour iOS et Win7 et utilise Dalvik dans Android? Traduit-il le code source en natif et avons-nous accès à ce code source? Y a-t-il une autre magie, étant donné qu'ils promettent "pas de compromis"? Quelles limitations dois-je savoir lors du codage de Java agnostique?
Frappe préventive: il s'agit d'une question sur Codename One, et non sur quelle plate-forme dois-je choisir ou si je devrais devenir natif ou si je devrais aller sur le Web .
Codename One utilise une approche basée sur SaaS donc cela pourrait (et probablement changera) à l'avenir pour accueillir des architectures améliorées. Notez que Codename One fournit également une option pour - build offline ce qui signifie que les sociétés qui ont des politiques interdisant de telles architectures cloud peuvent toujours utiliser Codename One avec une surcharge/complexité supplémentaire.
Actuellement sur Android le code standard Java est exécuté tel quel. Java 8 est traduite en utilisant retrolambda pour toutes les plateformes lorsque son utilisé. Cela lui permet d'être compatible avec toutes les versions Android ainsi que d'autres ports.
Sur iOS Codename One construit et open source ParparVM qui est une machine virtuelle très conservatrice. ParparVM dispose d'un GC simultané (non bloquant) et il est entièrement écrit en Java/C. Cela signifie en fait qu'un projet xcode est généré et compilé sur les serveurs de génération, donc c'est comme si vous codiez à la main une application native et donc "à l'épreuve du temps" pour les modifications apportées par Apple. Par exemple. avec les récentes modifications 64 bits et bitcode apportées aux versions iOS, ParparVM n'a eu besoin d'aucune modification pour se conformer à ces modifications.
Dans le passé, Codename One utilisait XMLVM pour générer du code natif de manière très similaire, mais la solution XMLVM était trop générique pour les besoins de Codename One.
les versions iOS sont compilées et signées sur Mac dans le cloud à l'aide de xcode (l'outil officiel Apple build). Cela les rend compatibles avec les modifications actuelles/futures de Apple et permet aux développeurs d'utiliser Windows/Linux tout en ciblant iOS. Vous pouvez en savoir plus sur la compatibilité de ParparVM avec iOS ici .
Dans le passé, Codename One prenait en charge Windows Phone à l'aide d'un traducteur C # qui s'appuyait sur XMLVM, mais ce n'était pas une approche idéale. Notez que le backend XMLVM qui se traduit en C # est très différent de celui qui était auparavant utilisé pour la traduction vers iOS. Codename One a choisi de arrêter cet ancien backend car il n'était pas aussi puissant que le nouveau backend UWP et ne correspond pas aux objectifs de Microsofts pour aller de l'avant et se concentrer sur WP (Universal Windows Platform) .
Pour la prise en charge de bureau et mobile Windows 10, Codename One utilise iKVM pour cible UWP (Universal Windows Platform) et a ouvert les modifications du code iKVM d'origine dans Codename One github repository .
Notez que les générations UWP sont effectuées sur des machines Windows 10 dans le cloud, permettant ainsi aux développeurs d'utiliser Mac/Linux ou des versions plus anciennes de Windows lors de la création d'applications Windows natives ...
Les cibles de génération JavaScript disponibles au niveau de l'entreprise abonnés utilisent TeaVM pour effectuer la traduction de manière statique. TeaVM prend en charge le filetage à l'aide de JavaScript en décomposant l'application de manière assez élaborée. Pour prendre en charge l'interface utilisateur complexe Codename One utilise l'API HTML5 Canvas qui offre une flexibilité absolue pour la création d'applications.
Pour les versions de bureau, Codename One utilise javafxpackager, étant donné que les machines Mac et Windows sont disponibles dans le cloud, la nature spécifique à la plate-forme de javafxpackager n'est pas un problème.
Ce qui distingue Codename One, c'est son approche de l'interface utilisateur qui utilise une "architecture légère" pour permettre à l'interface utilisateur de fonctionner de manière transparente sur toutes les plates-formes et d'être développée presque entièrement en Java. Il est augmenté par la possibilité d'intégrer des widgets "lourds" en place parmi les "poids légers". Vous pouvez en savoir plus à ce sujet dans ce article de blog . Notez qu'à l'heure actuelle le peering est en cours d'amélioration et prend désormais en charge des utilisations plus élaborées telles que la superposition.
Un composant léger est entièrement écrit en Java, ce qui permet aux développeurs de prévisualiser l'application avec précision dans le simulateur et le générateur d'interface graphique.
Codename One atteint des performances rapides en dessinant à l'aide des API de jeu natives de la plupart des plates-formes, par exemple OpenGL ES sur iOS.
Les technologies de base derrière Codename One sont toutes open source, y compris la plupart des éléments développés par Codename One lui-même, par exemple ParparVM mais aussi bibliothèque complète, ports de plate-forme, outil de conception , habillages de périphériques etc. Vous pouvez en savoir plus sur l'utilisation des sources Codename One - ici .
FYI Shai Almog, l'auteur de cette réponse, est le PDG de Codename One.
Le nom de code un 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 un canevas fourni par la plate-forme. Il essaie d'imiter l'aspect et la convivialité de la plate-forme, si vous le choisissez, mais a autant de succès que Swing avec son "aspect et la sensation de la plate-forme native", car la plate-forme native change constamment, et "native l & f" manque toujours derrière et dans la plupart cas ne semble pas tout à fait raison.
Mais, si vous choisissez l'apparence indépendante de la plate-forme (ce qui est le genre de tendance aujourd'hui), vous n'êtes pas limité par l'ensemble de composants par défaut de Codenameone: c'est comme Swing avec son apparence multiplateforme (" Métal "etc.). Ce qui est bon.
Du côté du langage: sur iOS, il est Java compilé en C qui est ensuite lié à Objective-C manuscrit, et il ne regroupe pas VM, seulement la 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, car il fait des invocations de méthode virtuelles ou, plus souvent, directes au lieu de lent Objective C envoi de messages. Ce qui est bon.
Cela peut également sembler un peu plus rapide sur Android, car, tout en utilisant Dalvik/Art, il n'utilise pas l'interface utilisateur native Android qui est volumineuse par rapport aux CN1. Cela peut accélérer la création d'interface utilisateur dynamique lors de l'exécution, ce qui est bien.
L'un des points forts de l'approche CN1 est son émulateur (implémenté sur une toile 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 plates-formes mobiles et vous permet d'utiliser IDE de choix pour le débogage. Il redémarre rapidement et le cycle d'édition-compilation-exécution est très durable par rapport à Android. Ce qui est bon.
Le deuxième point très fort (principal!) Est la nature ouverte de leur bibliothèque d'interface utilisateur, tout le code natif et le convertisseur bytecode-to-C. Si vous dépensez un peu d'effort, 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!). Selon votre situation, cela peut (ou pas!) Être très 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 façon dont ils n'ont pas été conçus pour ê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 vous devrez peut-être utiliser le natif à certains endroits, et porter d'autres bibliothèques Java pures, aussi.
De plus, l'état actuel des performances graphiques n'est pas optimal; si vous obtenez un tas de texte à l'écran, vous manquerez facilement le délai d'animation/repeinture fluide de 16 ms, cela peut être résolu par une double mise en mémoire tampon, mais il a aussi ses limites. Heureusement, il y a encore de la place pour l'optimisation dans la mise en œuvre sur les deux principales plates-formes, j'espère qu'elles vont l'améliorer.
Dans l'ensemble, Codenameone a une bonne niche en tant que cadre multiplateforme pour plusieurs classes d'applications; vous pouvez également trouver une valeur dans leurs services.