Comment fonctionne Codename One?

Question

Je recherche des alternatives à développer pour plusieurs plates-formes mobiles, et j'ai trouvé Codename One, qui utilise Java comme lingua franca, au lieu de HTML/CSS/JS ou des langages de script.

Ce que je n'ai pas trouvé, c'est comment ça marche. Inclut-il une JVM avec l'application pour iOS et Win7, et utilise Dalvik dans Android? Est-ce qu'il traduit le code source en natif, et avons-nous accès à ce code source? Y a-t-il d'autres magies, considérant qu'ils promettent "pas de compromis"? Quelles limitations dois-je prendre en compte lors du codage de Java agnostique?

Empêchement préemptif: il s'agit d'une question sur Codename One, pas sur lequel multi-plateforme dois-je choisir ou si je devais aller natif ou si je devais aller web.

Answer 1

Codename One utilise une approche basée sur SaaS, ce qui pourrait (et changera probablement) à l'avenir pour s'adapter aux architectures améliorées. Notez que Codename One fournit également une option à build offline, ce qui signifie que les entreprises qui ont des stratégies interdisant de telles architectures de cloud peuvent toujours utiliser Codename One avec un surcoût/complexité supplémentaire.

Actuellement sur Android, le code Java standard est exécuté tel quel. La syntaxe Java 8 est traduite en utilisant retrolambda pour toutes les plateformes quand elle est utilisée. Cela lui permet d'être compatible avec toutes les versions d'Android ainsi qu'avec d'autres ports.

Sur iOS Codename Un construit & open source ParparVM qui est une VM très conservatrice. ParparVM dispose d'un GC concurrent (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 build de manière à ce qu'il soit efficace comme si vous apportiez manuellement une application native et donc "preuve à l'épreuve" des changements effectués par Apple. Par exemple. Avec les récentes modifications de 64 bits et de bitcode apportées aux versions iOS, ParparVM n'a eu besoin d'aucune modification pour se conformer à ces changements. 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 des ordinateurs Mac dans le cloud à l'aide de xcode (l'outil de construction Apple officiel). Cela les rend compatibles avec les changements actuels/futurs d'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 here. Par le passé, Codename One prenait en charge Windows Phone en utilisant un traducteur C# qui reposait sur XMLVM mais ce n'était pas une approche idéale. Notez que le backend XMLVM qui traduit en C# est très différent de celui qui était auparavant utilisé pour traduire en iOS. Codename One a choisi discontinue that old backend car il n'était pas aussi puissant que le nouveau backend UWP et ne correspond pas aux objectifs de Microsoft en allant vers UWP (Universal Windows Platform). Pour Windows 10 Desktop et Mobile support Codename One utilise iKVM à target UWP (Universal Windows Platform) et a ouvert les modifications apportées au code iKVM d'origine dans Codename One github repository.

Notez que UWP construit sont fait sur un ordinateur Windows 10 machines dans le nuage permettant ainsi aux développeurs d'utiliser Mac/Linux ou les anciennes versions de Windows lors de la construction des fenêtres natives des applications ...

JavaScript construire des cibles qui sont disponibles sur les abonnés de niveau entreprise utilisent TeaVM pour effectuer la traduction de manière statique. TeaVM fournit un support pour le threading en utilisant JavaScript en décomposant l'application d'une manière plutôt élaborée.Pour prendre en charge l'interface utilisateur complexe Codename One utilise l'API HTML5 Canvas qui permet 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 de la plateforme javafxpackager ne pose aucun 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 renforcé par la possibilité d'intégrer des widgets «poids lourds» parmi les «poids légers». Vous pouvez en apprendre plus à ce sujet dans ce blog post. Notez qu'à ce moment peering is undergoing some improvements et prend désormais en charge des usages plus élaborés tels 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 &. Codename Un permet d'obtenir des performances rapides en dessinant à l'aide des API de jeu natives de la plupart des plates-formes, par ex. OpenGL ES sur iOS.

Les technologies de base derrière Codename One sont toutes open source, y compris la plupart des choses développées par Codename One elle-même. ParparVM mais aussi full library, platform ports, designer tool, device skins etc. Vous pouvez en apprendre plus sur l'utilisation de Codename One sources here.

FYI Shai Almog, l'auteur de cette réponse, est le PDG de Codename One.

Answer 2

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 l'ensemble de son interface utilisateur sur un canevas fourni par la plate-forme. Il essaie d'imiter l'aspect natif de la plate-forme, si vous le choisissez, mais a autant de succès que Swing avec son "apparence de plate-forme native", car la plate-forme native change constamment, et "native n '& dans la plupart des cas, ne se sent pas tout à fait raison. Mais, si vous choisissez l'apparence indépendante de la plate-forme (ce qui est la tendance actuelle), vous n'êtes pas limité par le jeu de composants par défaut de Codenameone: c'est comme Swing avec son apparence multiplate-forme et sentir ("Metal" etc.). Ce qui est bon. Du côté de la langue: sur iOS, Java est compilé en C qui est ensuite lié à l'Objective-C écrit à la main, et il ne comprend pas la 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 rend le code Objective-C plus rapide que idiomatique, car il effectue des invocations de méthodes virtuelles ou, plus souvent, directes au lieu de lenteurs. Ce qui est bon.

Il 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 encombrante par rapport à CN1. Cela peut accélérer la création d'une 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 de bureau JavaFX) que vous utilisez pour développer un logiciel. Emulator 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 l'IDE de votre 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.

Deuxième point très fort (principal!) est la nature ouverte de leur bibliothèque d'interface utilisateur, tout le code natif et le traducteur bytecode-à-C. Si vous faites des efforts, vous pouvez éviter de construire des ports Android/iOS sur leur ferme et vous détacher de leur révision de produit particulière (mais pas de quelques services à valeur ajoutée qu'ils offrent, qui ne sont pas open source!). Selon votre situation, cela peut (ou ne peut pas!) Être assez bon pour vous!

Point faible de Codenameone est sa maturité moins-que-idéal, ce qui signifie que vous pouvez facilement vous tirer dans le pied en utilisant les composants de base UI, si vous les utilisez comme ils ne sont pas utilisés. Cela signifie aussi 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 natif dans certains endroits, et porter d'autres bibliothèques java pures, aussi.

De plus, l'état actuel des performances graphiques est sous-optimal; Si vous avez plein de texte à l'écran, vous perdrez facilement l'animation fluide de 16 ms/la limite de temps de repeint, cela peut être contourné par un double tampon, mais il a aussi ses limites. Heureusement, il y a encore de la place pour l'optimisation de la mise en œuvre sur les deux plates-formes principales, j'espère qu'ils vont l'améliorer.

Dans l'ensemble, Codenameone a une bonne niche en tant que framework multiplateforme pour plusieurs classes d'applications; vous pouvez également trouver une valeur dans leurs services.