CocoaへのWPFの移植（および/またはその逆）

Question

私は、mISVのソフトウェアを作成する初期段階にいます。このプログラムはデスクトップアプリケーションであり、長期的にはWindowsとOS Xの両方のネイティブバージョンが必要です（さまざまなクロスプラットフォームAPIを見てきましたが、どれも私のニーズを満たしていません）。最初は、一度に2つのプラットフォーム用に開発するのは理にかなっていないと思います。それを念頭に置いて、私はWindows用のWPFとOS X用のCocoaを見てきましたが、それらは似ているようです。

誰かが一方を他方に移植した経験がありますか？移植を容易にする特定のテクニック/パラダイムに従う必要がありますか？ビジネス上の考慮事項を無視して、最初にそれらのいずれかで開発することをお勧めしますか？

Answer 1

現在、このスペースでの移植ツールに取り組んでおり、長年にわたって痛みを伴う経験がありますMacおよびWindowsでクロスプラットフォームフレームワークを使用または作成します。

過去の最大の問題の1つは、AppleがCocoaのペン先形式を開くことを拒否したことです（カーボンペン先は数年前にXMLファイルを開いていました）。 XCode 3および .xib 形式で変更されました、 Frasier Speirs でも説明されています。

基本的なレイアウトレベルでは、少なくとも、あるXML形式から別のXML形式への移植を自動化する機会があります。私はWPF（XAML）をよりクリーンなものと見なしているので、それを基本形式として使用し、Cocoaに移行しています。

背後のコードについては、MonoでC＃を使用できますが、 CocoaSharp プロジェクトが停止しているか、非常に遅いようです。お勧めしません。

C ++に慣れている場合は、C＃およびObjective-Cの薄いプラットフォーム固有のレイヤーを使用して、C ++でできるだけ多くのロジックを使用することを検討してください。

調査する価値のあるもう1つのアプローチは、PythonやRubyなどの動的言語を使用することです。現在、 IronPython と IronRuby が両方ともMicrosoftの人々によってサポートされるようになりました。 Cocoa側では、Ruby構文の柔軟性が勝利し、 RubyCocoa がおそらく PyObjC 。

それ以外の場合、C＃とObjective-Cで作業し、まったく同じ設計の2つの完全に独立したコードベースを維持します。幸いなことに、フレームワークは、特にバインディングを使用する場合、ほとんどのものに対して同等のセマンティクスを備えています。

Answer 2

各プラットフォームに固有のウィンドウ環境を選択することで、あなたは正しい道を進んでいると思います。このアプローチにより、クロスプラットフォームウィンドウツールキットに固有の妥協によって制限されない各プラットフォームでユーザーエクスペリエンスを作成できます。

最初の良いステップは、設計をプラットフォーム固有の要素とプラットフォームに依存しない要素の2つの部分に分けることです。すでにプラットフォーム固有の列にUIコードを配置できますが、アプリにはプラットフォームに依存しないC ++で記述できるデータ永続性が必要になる場合があります。このアプローチで見つけることができるのは、プラットフォームに依存しない方法で記述できるかなり多くのロジックとインフラストラクチャがあり、UIとグルーコードだけをプラットフォーム固有のままにしておくことです。

Late Night Cocoa というタイトルの最近のエピソードがありました 大規模アプリケーションをMacプラットフォームに移植する 。アプリは「大」としての資格がない場合があります。しかし、このポッドキャストは、それを数回行った人からの移植に関するかなりの知識を与えてくれます。

Answer 3

まあ。 Cocoa用のアプリを作成したら、Windowsに移植できます。これは、 gnustep または Cocotron 。

別の方法で行う場合、 WINE は移植を容易にすることを目的としています。

最初にOSXバージョンを書きます。これは、Windowsユーザーがアプリケーションの外観を明確に把握していないためです。私の経験では、彼らはあらゆる種類のユーザーインターフェースを介して非常に苦しむことができます。一貫性はそれらにとってほとんど価値がありません。 Windowsアプリがどのように見えるべきかという共通の合意がないため、Windowsユーザーが実際にOSXデザインを好むことを妨げるものはなく、彼らも頻繁にそうします。 Windows用のiTunesは非常に典型的なOSXアプリのように見えますが、Windows風では不十分だという苦情はほとんどありません。

他の方向に進むと、これは真実ではありません。 OSXユーザーは、Cocoaアプリに対する明確な好みを持ち、たとえば、OSXで動作するGIMPやInkscapeなど、他の場所と同様に許容度はほとんどありませんが、OSXの訓練を受けた目には明らかにいように見えます。

Answer 4

まあ、簡単な道はありません。最適な方法は、Model-View-Controllerパターンなどのアーキテクチャを使用して、ビジネスロジックなどをプレゼンテーションから分離することです。ただし、Monoを使用している場合を除き、共有するコードは非常に少ないと思います。 X。

適切な設計を維持すると、移行パスを見つけるのではなく、ほとんどのコードを単に.NETコードのObjective-Cバージョンにすることができます。