代码之家 › 专栏 › 技术社区 › John Rudy

跨平台桌面应用——一种方法?

cross-platform

John Rudy · 技术社区 · 17 年前

我有一个我认为是应用程序的杀手锏。根据定义,这将是一个桌面应用程序,它与我编写它的平台(Windows搜索服务、Mac OS X Spotlight服务器)提供的一些相当低级的服务相关联。

我的意图是Mac OS X和Windows版本。绝对的意图实际上是不共享代码——主要是因为很少(如果有的话)代码是通用的。因此,我打算使用完全不同的框架(Mac上的Cocoa/Obj-C,Windows上的C#/WPF/PInvoke),让两者都感觉“原生”于他们的平台,如果你愿意的话,可以说是一流的应用程序公民。

我的问题是:尝试“同时”构建它们是否更好,也就是说,即使在整个开发周期中,也要努力保持它们的功能对等;还是最好先“正确”一个,然后再跟进另一个?

保持平价的好处似乎是:

更容易使算法保持一致,因为我用一种语言实现,我只需移植到另一种语言
更容易确保在发布时,这两个应用程序都可以立即使用

保持平价的缺点似乎是:

更难做到;不断的语言切换可能会让我头疼(每当我在工作中用C#工作4天,然后突然不得不维护我们的一个旧VB.NET解决方案时,我就已经在工作中遇到了这个问题)

一个和另一个的优点似乎是:

无持续语言切换
一个平台可以在测试中,而另一个平台正在构建中

一个的缺点,然后是另一个,似乎是:

回到“旧”代码来移植算法
可能对“重做”我已经做过的事情失去兴趣

诚然,这是非常雄心勃勃的。..我只是一个人,在“空闲”时间做这件事(哈哈)。如果你在同一条船上,并且熟悉这两套技术,你会如何处理这个问题?

更新

针对以下问题:

是的,通用的API是可行的,但是调用约定并不容易——或者至少不容易。我确实打算定义相同的类,但使用特定于平台的代码。(这似乎相当关键,因为Windows Search Service和Spotlight的工作方式确实不同。)

我可以选择像Java这样的东西,但我选择不这样做有几个原因:(1)我没有学过Java 永远 ,我现在危险地没有资格。(2)其中一部分是通过在我熟悉的技术中“基本上”使用相同的应用程序来学习Objective-C;(3)虽然Swing可以在OS X上提供一种基本上是原生的外观,但它的Windows UI感觉并不完全正确,我真的希望这两个应用程序都感觉它们属于各自的系统。

上市时间不是一个大的考虑因素;我觉得应用程序的想法本身是相当安全的。比TTM更重要的是让应用程序感觉正确并提供功能。..

9 回复 | 直到 17 年前

da5id 17 年前

我会先为目标受众最大的平台(比如你的杀手级应用)开发,然后利用我在开发过程中学到的不可避免的经验教训来改进我为其他平台开发的方式。

Dan Rosenstark 13 年前

尽管我一直在狂热地寻找适用于这两个平台的桌面解决方案,但我认为两次构建应用程序没有任何问题。…可能是有道理的。

也就是说,我认为你不应该先建造一个,然后再建造另一个,而是试着做一些非常困难的事情,比如 对两者使用相同的UML类图。 这将迫使您将应用程序划分为以下部分: 完全相同的 以及根据定义特定于平台的部分。

我们的想法不是共享代码库,而是共享软件设计。

MusiGenesis 17 年前

您最初应该专注于为一个平台编写应用程序,并担心以后移植它。如果你不完成你的项目,它肯定会失败,试图同时为两个平台编写它肯定会增加整体开发时间。你能说出一款因为不支持多个平台而失败的商业软件吗?

Kevin Le - Khnle 17 年前

你提到的利弊都是绝对正确的。就我个人而言,我讨厌回去重新做一些事情,即使是用不同的语言,而不是不断地在精神上转换语言思维。我每天都在做这件事,我用Python做服务器开发,用JavaScript做客户端开发。

话虽如此,将低级内容与高级UI内容分开怎么样。在每个平台中构建底层内容,以便它们具有完全相同的API。底层内部实现可以完全不同,这并不重要,只要它们都公开了相同的接口。我想你会发现这样做很有趣。你还说你希望UI在每个平台上都是原生的,那么为什么不考虑像Java中的SWT这样的东西呢。如果SWT和Java不是一种选择,那么我想你必须使用WPF和Cocoa构建高级内容。但到这个时候,您的工作会更容易,因为您将调用以前在低级库中构建的相同的API。

milot 17 年前

如果我是你,我会选择跨平台框架和/或编程语言,现在你有很多跨平台的语言/框架,比如Java、QT(使用Java和C++语言)、C#与MONO、GTK+与C(gtkmm与C++、GTK#和MONO用于C#)。因此,如果你用一种语言/框架做这件事比同时用两种语言/架构做更简单,因为如果你用两种不同的语言/框架编写同一个应用程序,你将花费额外的开发时间,其中一半的时间你可以掌握新的框架和语言,因为你从一开始就知道你的目标平台是多平台的。如果现在你的主要平台是Windows,后来的Mac用户非常喜欢这个应用程序,那么重写它的原因就是针对另一个平台并使用它的开发工具。

Michael Borgwardt 17 年前

你确定你不能将低级服务抽象为一个通用接口,并且仍然有足够的应用程序(如UI)来让跨平台开发更经济吗?如果你想有一个快速的上市时间,计划每件事都做两次听起来很浪费。

OscarRyz 17 年前

使用第三种语言作为母语调用的粘合剂怎么样?

我听说python或ruby具有很好的本地库集成能力。差异可以通过内部API进行抽象。

这样,所有的逻辑都可以设置在第三种语言中,特定的部分可以设置在另一种语言中。

Java可能也是如此,但我认为集成看起来有点困难。

顺便说一句,这就是(或者曾经是?)java.io.File这样的类的工作方式。

告诉我们事情进展如何。

编辑

我认为大公司这样做的方式是使用C++,并使用fork来编写特定于平台的代码。

frankodwyer 17 年前

如果你无论如何都要学习一项新技术(Objective-C),我会再看一看Java。试图在两个不同的平台上开发同一个程序两次,同时学习太多东西,可能意味着你最终会得到一个在两个平台上都能很好地工作的程序——或者如果你被诱惑使用一个平台上可用的功能,而在另一个平台却无法使用,那么你会陷入无法支持的混乱。

如果你使用Java,你只需要处理每个平台上的一些UI和安装怪癖——你的大部分应用程序(以及重要的是,你所做的任何错误修复)都会立即移植。Java UI现在看起来相当成熟,并且有很多可重用的UI代码(例如JIDE组件很好)。如果你的应用程序想法真的是杀手锏,你可以在赚到数百万美元后雇佣员工来做“一流的公民应用程序”。

你还可以看看其他跨平台应用程序是如何成功交付的——例如,看看firefox、thunderbird、openoffice,看看你可以重用什么。我也知道一些用Java开发的跨平台应用程序,例如我使用PersonalBrain和crashplan,它们似乎都是基于Java的,而且根本没有侵入性。(有趣的是,PersonalBrain最初只提供Windows,然后他们进行了Java重写。然而,有些功能仍然是Windows专用的,但我很高兴在Mac上使用它。)

这在一定程度上取决于你想写的应用程序——例如,你想在某个时候支持iPhone吗?如果是这样,目前别无选择,只能使用目标C,如果你提前计划,你可能会看到MacOSX工作的一些重用。

无论你做什么,我肯定会建议将UI与程序的主逻辑分开,并使主逻辑尽可能直接可移植。否则,你将在每个平台上重新发明每个轮子。

Paul Lefebvre 13 年前

正如我通常在回答这样的问题时提到的,你至少也应该看看 Real Studio ,它允许您从相同的代码库创建本机桌面应用程序。它还允许您使用声明或插件连接到低级服务。