將WPF移植到Cocoa（和/或反之亦然）

Question

我正處於爲將要開發的mISV創建軟件的開始階段。該程序是一個桌面應用程序，從長遠來看，我希望爲Windows和OS X提供本地版本（我已經查看了各種跨平臺API，並且它們都不符合我的需求）。但最初，我認爲一次開發兩個平臺並不合適。考慮到這一點，我一直在尋找Windows的WPF和OS X的Cocoa，而且他們看起來很相似。

有沒有人有經驗移植到另一個？是否有特定的技術/範例可以使移植更容易？忽略商業考慮，你會建議先開發其中一個嗎？

Answer 1

我目前在這個空間中移植工具working，並且在Mac和Windows上使用或編寫跨平臺框架方面有許多年經驗。

過去最大的問題之一是蘋果拒絕爲Cocoa開放nib格式（Carbon nibs是多年前開放的XML文件）。這改變了XCode 3和.xib格式，以及由Frasier Speirs解釋。

在基本的佈局級別，至少現在有機會從一種XML格式自動移植到另一種XML格式。我認爲WPF（XAML）更清潔，因此我將它用作我的基本格式並遷移到Cocoa。

說到後面的代碼，雖然您可以在單聲道下使用C＃，但CocoaSharp項目似乎不穩定或非常緩慢，我不會推薦它。

如果您對C++感到滿意，請考慮在C++和Objective-C中使用C++中精簡的特定於平臺的層來儘可能多地使用邏輯。

另一種值得研究的方法是使用Python或Ruby等動態語言。我不確定目前IronPython和IronRuby之間哪個更成熟，但兩者現在都被Microsoft人支持。在Cocoa方面，我認爲Ruby語法的靈活性將取得成功，RubyCocoa可能超過PyObjC。否則，在C＃和Objective-C中工作，並使用相同的設計維護兩個完全獨立的代碼庫。幸運的是，框架在大多數情況下具有可比較的語義，特別是如果您使用綁定。

Answer 2

那麼，沒有一條直接的路徑。最好的方法是使用模型 - 視圖 - 控制器模式或其他體系結構來將業務邏輯等從演示文稿中分離出來。但是，除非你使用的是Mono，否則將會有很少的代碼供你分享，我認爲。如果你正在開發WPF，那麼你一定在做.NET，除了Mono，Objective-C是Mac OS下的標準編程工具X.

保持良好的設計，您可以將大部分代碼簡單地作爲.NET代碼的Objective-C版本，反之亦然，而不是試圖找到遷移路徑。

Answer 3

好吧。一旦你寫了一個可可的應用程序，可以將它移植到Windows。這可以使用gnustep或Cocotron來完成。

如果以其他方式執行此操作，WINE旨在簡化移植操作。

我寧願先寫OSX版本。這是因爲Windows用戶不清楚他們想要應用程序的外觀。根據我的經驗，他們很容易通過各種用戶界面。一致性對他們沒有多大價值。由於沒有共同的協議，Windows應用程序應該是什麼樣子，沒有什麼能阻止Windows用戶真正喜歡OSX設計，而且他們甚至經常這樣做。 iTunes for windows看起來像一個非常典型的OSX應用程序，並且您聽到很少有抱怨說它不夠Windows-ish。

走另一個方向，這是不正確的。 OSX用戶對Cocoa應用程序有明確的偏好，並且很少容忍像GIMP或Inkscape這樣的在OSX和其他任何地方工作的東西，但對於OSX訓練有素的眼睛看起來很醜陋。

Answer 4

我認爲你選擇了特定於每個平臺的窗口環境是正確的道路。通過此方法，您可以在每個平臺上創建不受跨平臺窗口工具包固有妥協的限制的用戶體驗。

一個好的第一步是將您的設計分爲兩部分：平臺特定和平臺中性元素。您已經可以將任何UI代碼放入特定於平臺的列中，但是您的應用程序可能需要一些可用平臺無關的C++編寫的數據持久性。這種方法可能會發現，您可以用平臺無關的方式編寫相當多的邏輯和基礎結構，只留下UI和粘合代碼作爲平臺特定的代碼。

有一個最近的Late Night Cocoa情節題爲Porting Large Applications to the Mac platform。你的應用程序可能不符合「大」的要求，但這個播客給予了相當多的移植知識。