複数のプラットフォームをターゲットとするアプリケーションを開発するために従うべきアプローチ

複数のプラットフォームをターゲットとするアプリケーションの場合、主に2つの開発アプローチが見られます。

• Javaのような開発プラットフォームに移動します。1つのコードソリューションを用意し、中間ランタイムに異なるプラットフォームを処理させます。プラットフォームで問題が発生した場合は、コードを少し調整してください。しかし、それはすべて同じにしてください。

• コアロジックとUIを分離するモジュラーコードを作成します。同じコアライブラリを呼び出すプラットフォームごとに個別のUIを開発します。ターゲットプラットフォームごとに個別にアプリケーションをビルドします。

それで、どちらをフォローしますか？答えは「それは場合によります」から始まります。しかし、私はこれらのアプローチとそれらのいずれかを選択するために考慮されるべき要因についてのあなたの意見を聞きたいと思います。

現在のOracle / Apache / Googleの問題はさておき、この目的のためにJVMに勝つことはまだ困難です。ほとんどのプラットフォームで非常に高品質であり、ユニバーサルであり、適切な数の言語（Java、Clojure、Scalaなど）から選択できます。これにより、単一のマシンアーキテクチャ（VM）をターゲットにすることができ、特定のエンドユーザーハードウェアをあまり気にする必要がありません。

とはいえ、適さない可能性のある特定のアプリケーションタイプがあります。低レベルのネットワーキングや、グラフィックスやビデオの重い処理が思い浮かびます。

HTML5に移行します。HTML5ブラウザを備えた任意のプラットフォームでアプリケーションを実行できます。HTML5の準備はまだ十分ではありませんが、Webアプリケーションのアプローチは準備が整っています。

Audacityサウンドエディターでは、クロスプラットフォームライブラリとしてwxWidgetsを使用します。Cライブラリにリンクする必要があり、速度と低レベルのアクセスが必要なため、JVMアプローチは機能しません。GUIコードは、すべてのプラットフォームで95％同じです。小さなバリエーションには#ifdefsを使用します。ただし、クロスプラットフォームライブラリを使用しても、あるマシンでの変更が別のマシンでの変更を行うのは簡単すぎるため、開発者が3つのプラットフォーム（Mac、Windows Linux）のそれぞれで作業することが不可欠であることがわかります。

必要なパフォーマンスが得られる場合は、JVMを使用してください。できない場合は、QTまたはwxWidgetsを使用してください。見栄えをよくするための作業が少ないため、wxWidgetsよりもQTをお勧めします。

リアルタイム開発者として、コアロジックによって使用される共通のAPIを備えた2-別のプラットフォーム固有のモジュールに似たオプションを正常に使用しました。ただし、ネットワーク、オーディオ、データストリーミングなどのUIはありません。この場合、プラットフォーム固有の低レベルのハードウェアインターフェイスです。

私はいくつかの理由でこれをこのようにしました：

1）各プラットフォームで最適なパフォーマンスを得るため

2）1つのプラットフォームでのみ提供される機能を利用する

3）（J）VMは一部のプラットフォーム（組み込みシステム、ゲームコンソールなど）には存在しませんでした。

それはあなたにとって何が重要かによります:)

約10年前にクロスプラットフォームのMac / Windowsアプリでこの選択に直面したとき、さまざまなクロスプラットフォームオプション（Java、Qt、wxWidgetsなど）をよく見てきました。 UIは私たちにとって非常に重要であり、すべての「クロスプラットフォーム」アプリは妥協されているように見えました。最終的には、弾丸をかじって、各プラットフォーム用のカスタムUI（PowerPlant for MacおよびMFC for Windowsで記述）を備えた独自のクロスプラットフォームコアを構築しました。時間が経つにつれ、これはかなりうまくなり、「クロスプラットフォーム」の部分は、UIを損なうことなく厚くなっています。

現在、新しいプロジェクトについてこの決定を検討しています。今の選択肢を見ると、おそらくQtを使用します。これは無料で、本当にうまく成熟しているようです。Javaも選択肢の1つでしたが、パフォーマンスの影響を実際に受けることはできません（3D画像処理を行っています）。

UIが本当に重要である場合、Qtのようなものを使用するか独自のものをロールするかに関係なく、各プラットフォームで適切に表示するためにかなりの時間を費やす必要があると思います。ユーザーが洗練されていないUIをより受け入れやすい内部または専門のアプリの場合、それは問題ないかもしれません。

誰もがJavaのような言語が「クロスプラットフォーム」であることについて大騒ぎしていますが、彼らが本当に話しているのは、一度コンパイルすればどこでも実行できるということです。Java（またはC＃/モノ）のような言語でも、一部の領域ではOS固有の詳細を処理するための抽象化レイヤーが必要になります。

C ++、そして実際にはほとんどの言語はクロスプラットフォームです。各プラットフォームをターゲットにするには、コンパイルする必要があります。

重要なのは、ツールや言語ではなくプロセスです。

1. すべてのターゲットプラットフォームの単体テストをビルドして実行する統合ビルドプロセスがあることを確認してください。
2. コードをチェックインする前に、すべての開発者がすべてのターゲットプラットフォームでテストすることを確認してください-これは明らかに、開発者が適切な数のマシン/ VMにアクセスできることを確認することを意味します。
3. よく抽象化します。ネイティブAPIを呼び出すすべてのものを抽象化します。これらの呼び出しをラップするライブラリを記述します。
4. 単純なフォームUIを超えて、最低限の共通点を満たしていない場合は、GUIコードがクロスプラットフォームではないことを受け入れてください。GUI /プレゼンテーションレイヤーを抽象化し、プラットフォームごとに個別にコーディングします。はい、クロスプラットフォームGUIツールキットがあります。これは単純なアプリに適していますが、より高度なことを行う場合は、ネイティブプラットフォーム機能にコーディングする必要があります。

これらの手順は、使用する言語/ツールセット/フレームワークに関係なく同じです。

ウェブを活用！

真剣に、もしあなたがあなたのお金のために最も強打したいなら、ウェブアプリケーションを書いてください。

どうして？

• 通常、Webクライアントはそれほど多くのPCパワーを必要としません。
• Webクライアントはどこにでもあります。PC / MAC / Linuxだけでなく、電話、モバイルデバイスなどでも使用できます。
• ユーザーにダウンロードする余計なものはありません！（通常、豪華なものが必要で、FlashまたはSilverlightを使用しない限り）
• すべての一般的なコンポーネントはサーバー側にあり、Java、.NET、PHP、または既存の多数のコンポーネントの寄せ集めである可能性があります。クライアントは気にしないでください！

あなたが言及した2つのアプローチでさえ非常に似ています。Webブラウザーは、複数の基本アーキテクチャーのHTMLをレンダリングします。同様に、JVMは、基盤となるハードウェアに適した方法でJavaコードを解釈します。ただし、Webのクライアントのベースは広範です。

私はMonoでかなりの幸運を経験しました。 Linuxマシンの場合と同じように、Windowsマシンでも同じコードを記述できます。ほとんどの場合、両方で機能します。また、C＃とWinformsですでに知っているスキルを使用できます。

最初に概念実証を行います。

それがかなり複雑なアプリケーションである場合、概念実証を掘り下げることで、必要な言語機能と、フレームワークまたはサードパーティのライブラリを活用するために必要になる領域についてのアイデアが得られます。

必要な言語機能とライブラリは、最終的にどの言語を選択するか（したがって、クロスプラットフォームサポートへの取り組み方）を決定します。

15年前にJavaがまだ初期段階にあり、これらの種類のアプリの作成に使用する準備ができていなかった15年前に、デスクトップアプリからシステムを構築しました。C ++にコアが必要であることを知っていて、Mac、Windows、UNIX（pre-Linux日々）。

優れたクロスプラットフォームUI環境を探したときに、XVTを含むものがいくつかありました。XVTのトレーニングを経験しましたが、実際のアプリの作成を開始したときに、プラットフォーム（Mac以降）でクリーンでネイティブなルックアンドフィールを作成することができないことに気付きました。そこで私はその考えをあきらめて、ポータブルコアの上にネイティブMac（PowerPlant）UIを構築しました。

数年後、Windows（MFCのUI）に移行しました。2回目にUIを構築する方が速く、MacとWindowsのUIを短時間並行して維持し、その後Windowsに移行しました。コアはその後、さまざまな種類のUNIXおよびLinuxに移行し、サーバーベースの計算を実行できるようになりました。コアは適切に移植され、64ビット対応にしたときにいくつかの調整が行われました。

Macを使用するようになりましたが、Macに戻れることを願っていますが、アプリのサイズと複雑さのため、これは難しい選択です。このアプリの多くがデスクトップアプリであることに意味はあります。これはCAD環境のようなものです。しかし、プラットフォーム固有のC / C ++言語でUIを再度構築する（そしてMFCベースのUIを維持し続ける）のではなく、スタック全体をJavaで書き直して、複数のプラットフォームで実行できるようにする傾向があります。

Java以外のコアを実行する理由がまだある可能性があります。たとえば、C ++の場合と同じです。しかし、それが本当に必要かどうかを確認するために、初期のパフォーマンステストを実行したいと思います。そして、UIを注意深く調べて、それをWebアプリとして構築し、Webサービスを介してコアに接続できるかどうかを確認して、さまざまなクライアント（デスクトップアプリ、モバイルアプリ、Webアプリなど）を用意できるようにしました。 CまたはC ++で作品が必要な場合、それをJavaのレイヤーの下に書くことができますか？またはウェブサービスとして？

別の考慮事項-アプリはどのくらいの期間存在しますか？それはどれほど複雑になりますか？これについて何か考えがある場合は、使用しているUIライブラリの寿命の可能性と、長期にわたって人々にライブラリの保守を手伝ってもらう能力を検討してください。これは今考えるのは難しいかもしれませんが、考える価値があります。

-アレックス

Webアプリにできる場合は、Webアプリにしてください。ExtJSのようなツールキットを使用すると、見栄えの良いGUIのようなブラウザーに対応したユーザーインターフェイスを比較的簡単に作成できます。

それ以外の場合、JavaまたはQT + C ++またはC + Wxは、すべてに対して1つのソースを持つための可能なオプションです。

2番目のアプローチは、アプリがすべてのターゲットプラットフォームでネイティブに見えるようにしたい場合に適しています。ネイティブMacアプリの外観は、ネイティブWindowsアプリとは異なります。別のスキンとキーバインドを使用するだけでは十分ではありません。