跨平台开发 - 使用跨平台UI工具包或多个平台上的本机？

Question

我正在寻找一些可以向我的老板和其他开发人员推销的论点。

我们目前正在完成初步的UI模型，并准备好进入下一个开发阶段。与此同时，我一直在挖掘Carbon，Win32和wxWidgets API的深度，尝试使一些控件在Mac和Windows平台上具有更原生的外观。

我越是深入研究Win32和Carbon API，以便在我们项目的UI中实现我们想要的东西，他们感觉越陈旧，我越开始认为我们应该按照最后一段here。

我们正在为当前项目使用wxWidgets。 wxWidgets正在wxCocoa端口上出现，但在我们开始对我们的新应用程序进行重大开发之前，看起来它还没有准备好进入黄金时段。在Windows方面，它包装Win32 API而不是WinForms或WPF（可能是由于本机代码和托管代码）。

我们已经在考虑使用MVC模式设计系统，因此除了必须编写两个本机UI之外，它应该是非常可行的，并且，恕我直言，使用现代API（如Cocoa）更容易获得所需的UI效果和WPF。

我一直试图巧妙地推动这些观点，但重大发展的开始即将到来。有没有人对我们下一个应用程序中如何使用本机UI工具包与坚持使用wxWidgets有任何建议？

提前致谢。

Answer 1

使用标准C ++创建核心代码，并使用Objective-C ++和Cocoa在Mac和C ++ / CLI以及使用WPF的C＃上创建用户体验，以在Windows上创建用户体验。请遵循Mac版本中适用于Mac的平台准则，适用于Windows版本中的Windows，并且甚至不必考虑尝试共享用户界面代码。

管理这个的一个好方法是，而不仅仅是模型 - 视图 - 控制器，遵循模型 - 模型控制器 - 视图控制器 - 视图架构。您的模型控制器独立于平台并管理应用程序的更高级功能。 （例如，它的整个文档概念，文件格式，作业队列等。）您的视图控制器依赖于平台并在模型控制器和用户体验之间进行调解。

当然，您可能也想在模型级别使用一些与平台相关的代码;例如，在Mac上使用NSOperation，在Windows上使用线程池来实现作业队列。为这类事情创建自己的轻量级抽象。

Answer 2

实际上我认为使用Qt变得非常有趣，因为它现在是LGPL

Answer 3

每次添加一个抽象层时，您都会对细节进行交易控制，以便进行更快速的开发。您可以使用一些跨平台框架预先完成大量工作。另一方面，当你想要做一些框架不支持的东西时 - 让我们面对它：它不会实现那些原生API可以做的所有可能的事情 - 你要么必须实现它（对于所有平台） ）使用本机API，或做一些其他奇怪的hackery来获得“足够好”的解决方案。当然，当事情变得非常糟糕时，拥有你不拥有的额外代码层会使调试变得更加困难。对于拥有尽可能多的整个堆栈，确实有一些说法。

Answer 4

编写两个字体结尾是很多工作，维护两个前端是一项繁重的工作，如果您需要在多个平台上运行程序，请使用多平台工具包。< / p>

如果您编写特定于平台的前端，每个前端都使用该特定平台的最新工具，您将获得更好的用户体验 - 但开发和维护这些前端的成本将处于同一数量级从头开始为每个平台开发整个应用程序（是的，即使是使用MVC）。

Answer 5

就个人而言，我宁愿坚持多平台，也不要吝啬那个眼睛，但是如果我想推广使用这些原生API，我会弄清楚（最终用户可见）之间的差异如何在不同的GUI中完成任务。如果你可以说服他们，为了感觉原生，程序的用户界面在Windows和OSX上必须看起来和感觉非常不同（因为不同的设计指南/哲学/无论如何），他们应该明白，即使使用wx，你仍然需要实现它两次，以适应这些不同的要求，所以你也可以使用真实的东西，即本机API。

Answer 6

另请参阅Google Chrome邮件列表中的this thread，讨论在不同平台上为Chrome选择相同的用户界面。

Answer 7

Win32肯定是老了，但是你可能想要研究像Microsoft基础类这样的东西，用于使用C ++进行本机开发。我假设MAC存在类似的事情。

就个人而言，如果我处于你的情况，我也会选择QT或WX。

Answer 8

  

有没有人对如何在我们的下一个应用程序中使用本机UI工具包与坚持使用wxWidgets提出任何建议？

没有人喜欢 corridor-wiseass 。

我认为行动胜于雄辩......制作一个你认为可以完成的小型原型并展示它。也许你必须在业余时间这样做。

Cocoa真的很棒所以我认为只需很少的代码你就可以表现出一个想法......好吧，这需要你足够了解Cocoa。