Codename Oneはどのように機能しますか？
複数のモバイルプラットフォーム向けに開発する代替案を探していますが、 Codename One を使用し、Javaをlingua franca、HTML/CSS/JSまたはスクリプト言語の代わりに。
私が見つけることができなかったのは、それがどのように機能するかです。 iOSおよびWin7用のアプリケーションにJVMをバンドルし、AndroidでDalvikを使用しますか？ソースコードをネイティブに変換しますか？このソースコードにアクセスできますか？ 「妥協しない」ことを約束していることを考えると、他の魔法はありますか？不可知論者のJavaをコーディングするとき、どのような制限に注意する必要がありますか？
先制攻撃：これはCodename Oneについての質問です。notどのクロスプラットフォームを選択すべきか、ネイティブにすべきか、Webに行くべきかについて。
Codename One は、SaaSベースのアプローチを使用するため、これは将来、アーキテクチャの改善に合わせて変更される可能性があります（おそらく変更される可能性があります）。 build offline これは、そのようなクラウドアーキテクチャを禁止するポリシーを持っている企業が、追加のオーバーヘッド/複雑さを伴うCodename Oneを引き続き使用できることを意味します。
現在Android標準のJavaコードはそのまま実行されます。Java 8これにより、すべてのAndroidバージョンおよび他のポートと互換性があります。
IOS Codename Oneでビルドおよびオープンソース ParparVM これは非常に保守的なVMです。 ParparVM 同時（非ブロッキング）GCを備えており、完全にJava/Cで記述されています。これは、Xcodeプロジェクトがビルドサーバー上で生成およびコンパイルされることを意味します。そのため、ネイティブアプリをハンドコーディングし、Appleによる変更を「将来的に保証」するようになります。例えば。 iOSビルドに対する最近の64ビットとビットコードの変更により、ParparVMはこれらの変更に準拠するために変更する必要がありませんでした。
以前はCodename Oneが [〜＃〜] xmlvm [〜＃〜] を使用して非常によく似た方法でネイティブコードを生成していましたが、XMLVMソリューションはCodename Oneのニーズに対して汎用的すぎました。
iOSビルドは、xcodeを使用してクラウド内のMacでコンパイルおよび署名されます（公式Appleビルドツール）。これにより、Apple開発者がiOSをターゲットにしながらWindows/Linuxを使用できるようにします。ParparVMとiOSの互換性について詳しくはこちらをご覧ください here 。
過去に、Codename OneはXMLVMに依存するC＃トランスレーターを使用してWindows Phoneをサポートしていましたが、理想的なアプローチではありませんでした。 C＃に変換するXMLVMバックエンドは、以前iOSに変換するために使用されていたものとは非常に異なることに注意してください。 Codename Oneは、 古いバックエンドを廃止 を選択しました。これは、新しいUWPバックエンドほど強力ではなく、Microsoftの目標に向かって前進し、焦点を当てていないためです WP（Universal Windows Platform） 。
Windows 10デスクトップおよびモバイルサポートの場合、Codename OneはiKVMを使用して target UWP（Universal Windows Platform） にし、 Codename One github repository の元のiKVMコードへの変更をオープンソースにしました。
UWPビルドはクラウド内のWindows 10マシンで実行されるため、開発者はネイティブWindowsアプリをビルドするときにMac/Linuxまたは古いバージョンのWindowsを使用できます。
エンタープライズレベルのサブスクライバーで利用可能なJavaScriptビルドターゲットは、 TeaVM を使用して静的に翻訳を行います。 TeaVMは、かなり複雑な方法でアプリを分解することにより、JavaScriptを使用したスレッド化をサポートします。複雑なUIをサポートするために、Codename OneはHTML5 Canvas APIを使用して、アプリケーションを構築するための絶対的な柔軟性を実現しています。
デスクトップビルドの場合、Codename Oneはjavafxpackagerを使用します。MacとWindowsの両方のマシンがクラウドで利用可能であるため、javafxpackagerのプラットフォーム固有の性質は問題ではありません。
Codename Oneが際立っているのは、「軽量アーキテクチャ」を使用してUIをすべてのプラットフォームでシームレスに動作させ、ほぼ完全にJavaで開発できるようにするUIへのアプローチです。これは、「軽量」ウィジェットの中に「重量」ウィジェットを埋め込む機能によって強化されます。これについて詳しくは、この ブログ投稿 をご覧ください。現時点では ピアリングはいくつかの改善を行っています であり、レイヤリングなどのより複雑な使用法をサポートしていることに注意してください。
軽量コンポーネントはすべてJavaで記述されているため、開発者はシミュレータとGUIビルダーでアプリケーションを正確にプレビューできます。
Codename Oneは、ほとんどのプラットフォームのネイティブゲームAPIを使用して描画することにより、高速なパフォーマンスを実現します。 iOS上のOpenGL ES。
Codename Oneの背後にあるコアテクノロジーはすべて、Codename One自体が開発したほとんどのものを含むオープンソースです。 ParparVM だけでなく、 フルライブラリ、プラットフォームポート、デザイナーツール 、 デバイススキン など。CodenameOneソースの使用方法の詳細については、こちらをご覧ください- ここ 。
この回答の著者であるFYI Shai Almogは、Codename OneのCEOです。
コードネーム1は、移植性に対して非常にバランスの取れたアプローチを取りました。実用的なコメントを追加したいと思います。
ユーザーインターフェイス側から、CN1はプラットフォームが提供するキャンバスにすべてのUIをペイントします。プラットフォームネイティブのルックアンドフィールを模倣しようとしますが、Swingと同様に「ネイティブプラットフォームのルックアンドフィール」で成功しました。ネイティブプラットフォームは常に変化し、「ネイティブl＆f」は常に背後にあり、ケースはまったく正しくないと感じています。
ただし、プラットフォームに依存しないルックアンドフィール（今日のトレンドのようなもの）を選択した場合、Codenameoneのデフォルトコンポーネントセットに制限されることはありません。クロスプラットフォームのルックアンドフィール（ "金属」など）。どっちがいい。
言語側から：iOSではJavaがCにコンパイルされ、それが手書きのObjective-Cに結び付けられ、VMをバンドルせず、移植性レイヤーのみをバンドルします。ここで最も重要なのは、JavaがObjective-CではなくCにコンパイルされていることです。これにより、通常のObjective-Cコードよりも高速になります。 Objective Cメッセージのディスパッチ。どっちがいい。
また、Dalvik/Artを使用している間は、CN1に比べてかさばるAndroidネイティブUIを使用しないため、Androidでは少し高速に見えるかもしれません。これにより、実行時の動的なUIの作成が速くなります。これは良いことです。
CN1アプローチの最も強力な点の1つは、ソフトウェアの開発に使用するエミュレータ（デスクトップJavaFXキャンバス上に実装）です。エミュレーターは、モバイルプラットフォームと同じUIコードと移植性APIを使用し、IDEを選択してデバッグすることができます。すぐに再起動し、編集-コンパイル-実行サイクルはAndroidと比較して非常に持続可能です。どっちがいい。
2つ目の非常に強い点（主な点！）は、UIライブラリのオープンな性質、すべてのネイティブコードおよびバイトコードからCへのトランスレーターです。多少の努力を払えば、ファームでAndroid/iOSポートを構築することを避け、製品の特定のリビジョンから解放することができます（ただし、提供する付加価値サービスの多くはオープンソースではありません！）。あなたの状況に応じて、これはあなたにとって非常に良いかもしれません（そうでないかもしれません！）！
Codenameoneの弱点は、それほど理想的ではない成熟度です。つまり、使用が意図されていなかった方法で使用すると、基本的なUIコンポーネントを使用して簡単に自分の足で撃つことができます。また、そのJavaポータビリティレイヤーは、すべてのユーザーのニーズをカバーするのに十分な大きさではなく（穴が開いている）、いくつかの場所でネイティブを使用し、他の純粋なJavaライブラリも。
また、グラフィックスのパフォーマンスの現在の状態は最適ではありません。画面上に大量のテキストが表示された場合、16ミリ秒の流体アニメーション/再描画の時間制限を簡単に見逃してしまいます。これはダブルバッファリングで回避できますが、制限もあります。幸いなことに、両方の主要プラットフォームでの実装には最適化の余地がまだありますが、うまくいけば改善されるでしょう。
全体として、Codenameoneは、いくつかのクラスのアプリケーションのクロスプラットフォームフレームワークとして優れたニッチを持っています。彼らのサービスにも価値があるかもしれません。