将WPF移植到Cocoa(和/或反之亦然)

时间:2009-01-11 07:57:30

标签: wpf cocoa porting

我正处于为mISV创建软件的开始阶段。该程序是一个桌面应用程序,从长远来看,我想拥有Windows和OS X的本机版本(我查看了各种跨平台的API,但没有一个满足我的需求)。但最初,我认为一次开发两个平台并不合理。考虑到这一点,我一直在寻找Windows的WPF和OS X的Cocoa,它们看起来很相似。

有没有人有过将一个移植到另一个的经验?是否有特定的技术/范例可以使移植更容易?忽略业务考虑因素,您会建议先在其中一个上进行开发吗?

4 个答案:

答案 0 :(得分:6)

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

良好的第一步是将您的设计分为两部分:平台特定和平台中性元素。您已经可以将任何UI代码放入特定于平台的列中,但是您的应用程序可能需要一些可以使用平台中立的C ++编写的数据持久性。您可以通过这种方法找到的是,您可以使用与平台无关的方式编写相当多的逻辑和基础架构,只将UI和粘合代码保留为特定于平台。

最新一集Late Night Cocoa标题为 Porting Large Applications to the Mac platform 。你的应用程序可能不具备“大”的资格,但这个播客提供了相当多的移植知识,来自已经完成了几次的人。

答案 1 :(得分:5)

好。一旦为Cocoa编写了应用程序,就可以将其移植到Windows。这可以使用gnustepCocotron完成。

如果以另一种方式执行此操作,WINE旨在使移植更容易。

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

走向另一个方向,这不是真的。 OSX用户对Cocoa应用程序有明显的偏好,并且对GIMP或Inkscape等在OSX下运行的东西以及其他任何地方都很容忍,但对于受OSX训练的人来说看起来很难看。

答案 2 :(得分:3)

我目前working在这个领域移植工具,并且在Mac和Windows上使用或编写跨平台框架方面经验多年,经验丰富。

过去最大的问题之一就是Apple拒绝为Cocoa打开笔尖格式(几年前Carbon nibs是开放的XML文件)。使用XCode 3和.xib格式进行了更改,Frasier Speirs解释了这一点。

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

说到背后的代码,虽然你可以在Mono下使用C#,CocoaSharp项目似乎停滞不前或非常慢,我不推荐它。

如果您对C ++感到满意,可以考虑在C ++中使用C#和Objective-C中的瘦平台特定层来尽可能多地使用逻辑。

值得研究的另一种方法是使用Python或Ruby等动态语言。我不确定目前在IronPythonIronRuby之间哪个更成熟,但现在两者都得到微软人员的支持。在Cocoa方面,我认为Ruby语法的灵活性将取得胜利,而RubyCocoa可能会超越PyObjC

否则,使用C#和Objective-C并维护两个完全独立的代码库,其设计相同。幸运的是,框架在大多数情况下具有可比较的语义,特别是如果您使用绑定。

答案 3 :(得分:1)

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

保持良好的设计,您可以将大部分代码简单地作为.NET代码的Objective-C版本,反之亦然,而不是尝试查找迁移路径。