4

我正处于为未来的 mISV 创建软件的初期阶段。该程序是一个桌面应用程序，从长远来看，我希望有一个适用于 Windows 和 OS X 的本机版本（我查看了各种跨平台 API，但没有一个能满足我的需求）。不过，最初，我认为同时为两个平台开发是没有意义的。考虑到这一点，我一直在研究适用于 Windows 的 WPF 和适用于 OS X 的 Cocoa，它们看起来很相似。

有没有人有过将一个移植到另一个的经验？是否有特定的技术/范式可以使移植更容易？忽略业务考虑，您会建议先开发其中一个吗？

4

4 回答 4

6

好。一旦您为 Cocoa 编写了应用程序，就可以将其移植到 Windows。这可以使用gnustep或Cocotron来完成。

如果你用另一种方式来做，WINE是为了让移植更容易。

我宁愿先写 OSX 版本。这是因为 Windows 用户不清楚他们想要应用程序的外观。根据我的经验，他们很容易受到各种用户界面的影响。一致性对他们来说没有什么价值。由于没有共同的协议，Windows 应用程序应该是什么样子，没有什么能阻止 Windows 用户真正喜欢 OSX 设计，他们甚至经常这样做。Windows 版 iTunes 看起来像一个非常典型的 OSX 应用程序，你很少听到有人抱怨它不够 Windows-ish。

往另一个方向发展，这是不正确的。OSX 用户对 Cocoa 应用程序有明显的偏好，并且对 GIMP 或 Inkscape 之类的东西在 OSX 下的工作与其他任何地方一样好，但对于 OSX 训练有素的眼睛来说看起来很丑陋。

于 2009-01-11T08:35:38.267 回答
6

我认为通过选择特定于每个平台的窗口环境，您走在了正确的道路上。这种方法允许您在每个平台上创建不受跨平台窗口工具包固有妥协限制的用户体验。

一个好的第一步是将您的设计分解为两部分：特定于平台的元素和平台中性元素。您已经可以将任何 UI 代码放入特定于平台的列中，但也许您的应用程序需要一些可以用平台中立的 C++ 编写的数据持久性。使用这种方法您可能会发现，您可以以与平台无关的方式编写相当多的逻辑和基础架构，而只留下 UI 和胶合代码作为特定于平台的代码。

最近有一集Late Night Cocoa名为Porting Large Applications to the Mac 平台。您的应用程序可能不符合“大”的条件，但这个播客从做过几次的人那里提供了很多很棒的移植知识。

于 2009-01-11T16:21:10.263 回答
4

我目前正致力于在这个领域移植工具，并且在 Mac 和 Windows 上使用或编写跨平台框架方面拥有多年的痛苦经验。

过去最大的问题之一是 Apple 拒绝为 Cocoa 开放 nib 格式（Carbon nib 几年前是开放的 XML 文件）。这随着 XCode 3 和.xib格式而改变，正如Frasier Speirs所解释的那样。

至少在基本布局级别，现在有机会自动从一种 XML 格式移植到另一种格式。我认为 WPF (XAML) 更干净，因此我将其用作我的基本格式并迁移到 Cocoa。

谈到后面的代码，虽然您可以在 Mono 下使用 C#，但CocoaSharp项目似乎停滞不前或非常缓慢，我不推荐它。

如果您对 C++ 感到满意，请考虑在 C++ 中使用尽可能多的逻辑，并在 C# 和 Objective-C 中使用特定于平台的薄层。

另一种值得研究的方法是使用动态语言，如 Python 或 Ruby。我不确定IronPython和IronRuby目前哪个更成熟，但现在两者都得到了微软人员的支持。在 Cocoa 方面，我认为 Ruby 语法的灵活性将取得胜利，并且RubyCocoa可能正在超越PyObjC。

否则，使用 C# 和 Objective-C 工作并维护两个具有相同设计的完全独立的代码库。幸运的是，框架对于大多数事情都有类似的语义，特别是如果您使用绑定。

于 2009-01-12T05:51:57.067 回答
1

好吧，没有一条直截了当的道路。最好的方法是使用模型-视图-控制器模式或其他架构将业务逻辑等与表示分离。但是，除非您使用 Mono，否则我认为将很少有代码可供您共享。如果您正在开发 WPF，那么您肯定会使用 .NET，除了 Mono，Objective-C 是 Mac OS 下的标准编程工具X。

保持良好的设计，您可以让大部分代码只是 .NET 代码的 Objective-C 版本，反之亦然，而不是试图找到迁移路径。

于 2009-01-11T08:01:17.540 回答