14

クロスプラットフォームアプリケーション（特にGUIを備えたプログラム）を扱う開発者からのアドバイスが必要です。

クロスプラットフォームである必要があるアプリケーションをまもなく作成する予定なので、JavaFX2.0とQtという2つの異なるフレームワークについて予備調査を行いました。

正直なところ、どちらも私のニーズに合うだけではありません。それで、なぜ私がどちらかを選ぶのかと自問しました（ネタバレ注意：答えはわかりません：P）。JavaFX 2.0はかなり新しく（2012年現在）、プラットフォーム間で完全にはサポートされていないことを私は知っていますが、最終的にはサポートされる予定です。

私が提起する質問はこれです：クロスプラットフォームアプリケーションにこれらのどれを使用しますか、そしてその決定をするときにどのような基準を見ましたか？

お時間を割いていただきありがとうございます！:)

編集： この質問を検討する際の参考のために、私が作成するアプリケーションには、XMLファイルの読み取り/書き込み、画像の表示、およびカスタム機能を備えたいくつかの小さなウィジェットの作成が含まれます。.NETを使用してC＃で同様のアプリケーションを作成しましたが、クロスプラットフォームのユーザビリティについてJavaFX2.0またはQtを検討する際のアドバイスが必要です。

再度、感謝します！:)

4

5 に答える 5

20

それは古い質問です：安定性と最先端。アプリケーションの機能に基づいて、個人的な洞察を提供しようと思います。

JavaFX 2.0はかなり新しく（2012年現在）、プラットフォーム間で完全にはサポートされていません

Linux、Windows、Macで完全にサポートされています。サーバーがLinuxボックスで実行され、クライアントがWindowsボックスで実行されるMacでJavaFX2.2アプリケーションを開発しているためと言えます。

XMLファイルの読み取り/書き込み

XMLを解析するためのsax2よりも優れた/簡単な/高速なツール/インターフェースはまだありません。もちろん、QtXMLPatternsモジュールパーサーは尊重しますが、SAX2ベースのXMLパーサーを開発しています（ちなみに、これは完全ではなく、従来のSAX1メソッドと完全には互換性がありません）。

画像の表示

どちらのテクノロジーも十分に簡単に画像を表示できますが、JavaFX 2.2には画像操作用のツール（特にコーデックのフォーマット）がいくつかありません。画像処理が重要な問題であるとすれば、Qtは戦いの前にわずかに進んでいると言えます。

カスタム機能を備えたいくつかの小さなウィジェットを作成します。

現在のところ、これはJavaFX 2では簡単な作業ではありません。StageオブジェクトにはALWAYS_ON_TOPのようなオプションがなく、3.0まではありません（2013年のどこか）。難しいことではありませんが、Qtにはすでにカスタマイズ用の優れたツールがいくつかあります。 / display/handleウィジェットはJavaFXでは再現できません。

クロスプラットフォームアプリケーションにこれらのどれを使用しますか？また、その決定を行う際にどのような基準を検討しましたか？

ええと、JavaFX 2.2はJavaでできており、Java用です。私は個人的に、JavaでのプログラミングはC++よりもはるかに優れていて簡単だと思っています。Javaでポインタを使用するのに苦労する必要はありません。メモリ管理については、ガベージコレクタにいつでも頼ることができます。また、Web全体（C ++を超えると思います）にたくさんのチュートリアルとドキュメントがあり、常に成長しているJavaGurusコミュニティがあります。

要約すると、JavaFX 2.2を選択したのは、それがかわいくて、かっこいいから、MVCをより簡単に処理できるから、そしてJavaが大好きだからですが、アプリケーションのウィジェット部分が主な目的である場合は、Qtを選択する必要があると思います。それの。

お役に立てば幸いです、乾杯

于 2012-09-27T01:14:18.653 に答える
13

私は現在、オフラインのhtml5オーサリングアプリケーションの開発に適したさまざまなクロスプラットフォームフレームワークを研究しています。クロスプラットフォーム操作（Windows、Linux、OS-X）に加えて、私のアプリには次の主要な要件もあります。

組み込みデータベース組み込み（または、二次的には主流のブラウザ）HTML5レンダリングエンジン高機能の編集可能なDNDツリー、スプリッターパネル、およびリッチテキストエディターウィジェット中型画像処理USBスティックの移植性

私はこれらのフレームワークを真剣に検討しました。

jQuery（JavaScript）、HTML5、CSS3 Google Web Toolkit [GWT]（JavaからJavaScript）JavaFX 2.0（Java）QT（C ++（Javaバインディングが利用可能））Xulrunner（XML、JavaScript）GTK +（C）Adobe Air Pajamas

私はこれらすべてのテクノロジーの本に少額のお金を費やし、プロトタイプのコーディングを開始して、各フレームワークがどれだけ速く、どれだけ遠くまで行けるかを確認しました。

当初、JavaFX 2.0は、私を最も速く、大きな差で連れて行ってくれました。これについての簡単な説明は、JavaFXを使用すると、すべてのツール、IDE、ライブラリ、ドキュメント、コード例、ターンアラウンド、デバッグ、コミュニティサポート、メーカー（Oracle）サポート、および学習曲線が、インピーダンスの不一致を最小限に抑えたということです。

おそらくJavaFXの最大の利点は、クライアント側の組み込みデータベース（Derby）の実装の容易さでした。他のすべてのフレームワークでは、このタスクは驚くべきことに、かなり困難で「扱いにくい」ものでした。

残念ながら、WebViewウィジェットがローカルのfile：// URLからJavaScriptを実行しないことを発見したとき、深刻なJavaFXの障害に遭遇しました。QtWebKit、GTKWebKit、Safari、およびOpera（すべてWebKitベース）も同じfile：// JavaScriptブロッキング動作を示します（ただし、Chromeはそうではありません）。したがって、これはデフォルトのWebKitセキュリティ対策であると推測されます。

当時、私はfile：// JavaScriptの問題をJavaFXのショートッパーと考えていたので、jQuery、GWT、およびXulrunnerのプロトタイプの開発に移りました。しかし、その結果、私のプロトタイピングの生産性は大幅に低下しました。これらの他のフレームワークとのフランケンシュタインとインピーダンスの不一致は、JavaFXよりも著しく悪化しました。

何週間も雑草の中をさまよった後、私は回避策を見つけることに非常に意欲的なJavaFXプロトタイプに戻りました。最終的には、Java SE 6のWebサーバーをプロトタイプに埋め込み、JavaFX WebEngineに次の形式のURLをロードしてローカルファイルに接続することで問題を解決しました： "http：// localhost：58357 /xxxxx.html"JavaFXプロトタイプのブロックを解除するこのように家に帰るようなものでした。それは、大きな、大きな生産性の向上は言うまでもなく、新鮮な空気の本当の息吹でした。

これらの経験に基づいて、JavaFXとQtの議論に役立つ可能性のあるいくつかの洞察を以下に示します。

  • JavaFXとQtの質問に同意します。これらの2つのフレームワークは、それぞれ私の＃1と＃2のお気に入りで、最も生産的な選択肢になりました。
  • そうは言っても、jQuery / HTML5/CSS3フレームワークをミックスに追加します。このフレームワークは非常に強力であり、xプラットフォーム
    アプリケーション開発の可能性が非常に高いため、避けられないと言っても過言ではありません。ウィジェットコントロールの幅広い検索では、編集可能なDNDツリー、スプリッターパネル、およびリッチテキストwysiwygエディターウィジェットの主要な候補は、オープンソースのjQueryプラグインであることが判明しました。ローカルのfile：//の問題を回避すると、jQuery / HTML5/CSS3はJavaFXWebViewウィジェットとうまく互換性があります。jQuery / HTML5 / CSS3が不十分な領域の1つは、クライアント側のデータベースストレージです。これは、JavaFXとjQuery / HTML5/CSS3フレームワークの組み合わせが非常に強力であることが証明されている場所です。
  • QtモジュールはC++で記述されていますが、JavaおよびJavaScript言語ラッパーを備えているため、開発者はQtを使用するためにC++を知ったり使用したりする必要はありません。
  • これは、JavaFX対Qtである必要はないという点を浮き彫りにします-または質問です。実際、より建設的でやりがいのある質問は、「JavaFX ANDQt？」である可能性があります。
  • これは別の重要なポイントをもたらします。私の最高のクロスプラットフォームアプリケーション開発フレームワークは、実際にはJavaFX 2、ストレートアップJava SE、Swing（レガシーカスタムウィジェット用）、WebKit、およびjQuery /HTML5/の融合であることがすぐにわかります。 CSS3。将来的には、GWT、関連するサードパーティのGWTライブラリ、およびQtモジュールが混在する可能性があります。ここでのポイントは、単一の遺伝的に純粋なフレームワークを使用する計画がすぐに窓から外れたことです。
  • 現在、このハイブリッドフレームワーク全体をバインドする1つの共通スレッドは、昔ながらのJavaSEです。また、JavaFX2はJavaSEに基づいて構築されているため、私の投票では、JavaFX 2から始めて、必要に応じてSwing、WebKit、jQuery / HTML5 / CSS3、GWT、およびQtを追加します。
  • 最後に、この記事は、JavaFXワゴンに飛び乗るように私を説得するのに役立ちました。 http://fxexperience.com/2012/04/interview-with-peter-zhelezniakov/

--H

于 2012-09-28T07:21:55.923 に答える
8

タイムスタンプから、プロトタイピング研究プロジェクトにQTではなくJavaFX2を選択したと報告したのは4か月前でした。約2か月前にJavaFX2からQTに切り替え始めましたが、それ以来振り返っていません。論争の主なポイントは、プロトタイピングから生産への移行でした。プロダクションコードを書くために、QTはJavaFX2よりもはるかに進んでいることが証明されました。

いつものように、悪魔は細部に宿っていて、大きな違いを生んだのはたくさんの小さなものでした。JavaFX2では、制御できないスプリッターペインのサイズ変更動作、制限されたツリー制御、制限されたWebKit APIアクセスなどの小さな問題に常に直面して回避していました（たとえば、ブラウザーのズームボタンを実装するか、Webページ全体をローカルのhtmlファイルに保存してみてください-実行可能）しかし、本来よりも100倍不格好です）。一緒に追加すると、これらの「マイナーな」回避策は進行を遅らせて停止させました。

QTを使用すると、このような障害ははるかに少なくなり、その結果、プロトタイプから製品への移行は自然でシームレスになり、桁違いに高速になります。

欠点は、QTで「HelloWorld」に到達するのにはるかに時間がかかったことです。しかし、そこに到達すると、生産性はすぐにJavaFX2を上回り、はるかに上回りました。この理由の1つは、QTドキュメント、サンプルプログラム、および開発者コミュニティがはるかに広範囲にわたることです。QTは1992年から、JavaFX2は2011年から存在しており、この年齢差により、2つのGUIフレームワークの成熟度レベルに大きな違いが生じます。

JavaとC++の問題については、まったく問題になりませんでした。どちらも素晴らしい言語です。個人的には、さまざまな効率、生産性、パフォーマンスの理由から、C ++が優れたGUI言語であると感じていますが、これも個人的な結論です。

于 2013-02-03T23:31:31.667 に答える
2

Qtの最も優れた、最も楽しい部分は、特にスレッドを処理する際のシグナルスロットであると思います。これにより、非常に簡単になります。

于 2019-02-28T09:54:54.700 に答える
1

.NET / C＃から来ているので、クロスプラットフォームアプリケーションを作成する方法としてRealStudioも検討する必要があります。それは確かにあなたが作成しようとしているものに対するあなたの要件を満たし、JavaFXやQtよりもはるかに簡単になります。

于 2012-09-26T11:47:35.293 に答える