I have what I believe is a killer idea for an application. By definition, this would be a desktop application, and it ties into some fairly low-level services provided by the platforms for which I'd write it (Windows Search Service, Mac OS X Spotlight server).
我认为这是一个应用程序的杀手锏。根据定义,这将是一个桌面应用程序,它与我编写它的平台(Windows Search Service,Mac OS X Spotlight服务器)提供的一些相当低级别的服务相关联。
My intent is both a Mac OS X and Windows version. The absolute intent is actually to not share code -- mostly because very little (if any) of it would be able to be common. Because of this, I intend to use completely different frameworks (Cocoa/Obj-C on Mac, C#/WPF/PInvoke on Windows) and get both feeling "native" to their platforms, first-class application citizens if you will.
我的意图是Mac OS X和Windows版本。绝对意图实际上是不共享代码 - 主要是因为它很少(如果有的话)可以是共同的。因此,我打算使用完全不同的框架(Mac上的Cocoa / Obj-C,Windows上的C#/ WPF / PInvoke),并且如果愿意的话,让他们对他们的平台,一流的应用程序公民感到“原生”。
My question is this: Is it better to try and build them both "simultaneously," that is, try to keep them at feature parity even through the development cycle; or is it better to get one "right" and then follow up with the other?
我的问题是:尝试“同时”构建它们是否更好,也就是说,即使在开发周期中也尽量保持它们的特征奇偶性;或者更好地让一个“正确”然后跟进另一个?
The pros to keeping parity seem to be:
保持平价的优点似乎是:
- Easier to keep the algorithms in alignment, as I implement in one language, I merely port to the other
- Easier to ensure that at release, both apps are immediately available
更容易保持算法一致,因为我用一种语言实现,我只是移植到另一种语言
更容易确保在发布时,两个应用程序都可立即使用
The cons to keeping parity seem to be:
保持平价的缺点似乎是:
- Harder to do; constant language switching might make my head explode (I already go through this at work whenever I work C# for 4 days then suddenly have to maintain one of our old VB.NET solutions)
更难做;不断的语言切换可能会让我的头脑爆炸(我在工作C#4天后已经完成了这个工作,然后我突然不得不维护一个旧的VB.NET解决方案)
The pros of one, then the other, seem to be:
一个,然后另一个的优点似乎是:
- No constant language switching
- One platform can be in test while the other is being built
没有恒定的语言切换
一个平台可以在测试中,而另一个平台正在构建中
The cons of one, then the other, seem to be:
一个,然后另一个的缺点似乎是:
- Going back to what will then be "old" code to port the algorithms
- Potentially losing interest in "redoing" what I've already done
回到那将是“旧”代码来移植算法
可能会失去对“重做”我已经做过的事情的兴趣
Admittedly, this is very ambitious ... And I'm only one guy, doing it in "spare" time (hah). If you were in the same boat, and are familiar with both suites of technology, how would you approach this?
不可否认,这是非常雄心勃勃的......我只是一个人,在“闲暇”时间做这件事(哈哈)。如果你在同一条船上,熟悉两种技术套件,你会如何处理?
Updated
In response to some questions from below:
回答以下一些问题:
Yes, a common API is doable, however calling conventions wouldn't be -- or at least, not easily. I do intend to have the same classes defined, but with platform-specific code. (This seems fairly critical, as Windows Search Service and Spotlight work really differently.)
是的,一个常见的API是可行的,但是调用约定不会 - 或者至少不容易。我打算定义相同的类,但使用特定于平台的代码。 (这似乎非常关键,因为Windows Search Service和Spotlight的工作方式完全不同。)
I could go with something like Java, but I'm choosing not to for a couple reasons: (1) I haven't done Java in forever, and am now dangerously unqualified. :) (2) Part of it is an exercise in learning Objective-C by doing "essentially" the same app in technologies I am familiar with; and (3) While Swing can provide a mostly-native look on OS X, its Windows UI doesn't ever feel quite right, and I truly want both apps to feel like they belong on their respective systems.
我可以使用类似Java的东西,但我选择不这样做有几个原因:(1)我没有永远完成Java,而且现在危险地不合格。 :)(2)部分内容是通过在我熟悉的技术中“基本上”使用相同的应用来学习Objective-C; (3)虽然Swing可以在OS X上提供大多数本机外观,但它的Windows UI并不是非常正确,我真的希望这两个应用程序都感觉它们属于各自的系统。
Time to market isn't a big consideration; I feel the app idea itself will be fairly safe. More important than TTM is getting the app to feel right and provide the functionality ...
上市时间不是一个重要的考虑因素;我觉得应用程序的想法本身会相当安全。比TTM更重要的是让应用程序感觉正确并提供功能......
9 个解决方案
#1
4
You should focus on writing your application for one platform initially, and worry about porting it later. Your project is guaranteed to fail if you don't complete it, and trying to write it for two platforms at once is certain to increase the overall development time. And can you name one piece of commercial software that failed because they didn't support multiple platforms?
您应该专注于最初为一个平台编写应用程序,并担心以后移植它。如果你没有完成它,你的项目肯定会失败,并且尝试一次为两个平台编写它肯定会增加整个开发时间。您是否可以将一个失败的商业软件命名为因为它们不支持多个平台?
#2
5
I'd develop for whichever platform has the largest target-audience (as in for your killer app) first, then use the inevitable lessons I'd learn along the way to improve the way I'd develop for the other(s).
我会先为最大的目标受众(就像你的杀手级应用程序)开发平台,然后使用我不可避免的经验教训来改进我为其他人开发的方式。
#3
5
Although I've been fanatically looking for a desktop solution for both platforms, I don't think there's any problem with building the app twice... probably makes sense.
虽然我一直在*地寻找两种平台的桌面解决方案,但我认为构建应用程序两次没有任何问题...可能有意义。
That said, I don't think that you should build one and then the other, but try to do something madly difficult like use the same UML class diagrams for both. This will force you to do the hard work of dividing the app into the parts that are identical and the parts which are, by definition, platform specific.
也就是说,我不认为你应该构建一个然后另一个,但是尝试做一些疯狂的事情就像使用相同的UML类图一样。这将迫使您将应用程序划分为相同的部分以及根据定义特定于平台的部分进行艰苦的工作。
The idea is not to share a code base, but to share a software design.
这个想法不是共享代码库,而是共享软件设计。
#4
2
Both the pros and cons that you mentioned are absolutely valid. Personally, I hate going back and re-do something even in a different language than having to constantly mentally switch the language mindset. I am already doing this everyday where I am doing both the server development in Python and the client side in JavaScript.
您提到的优点和缺点都绝对有效。就个人而言,我讨厌回去,甚至用不同的语言重新做一些事情,而不是不断地在心理上转换语言思维。我每天都在做这个,我在Python中进行服务器开发,在JavaScript中进行客户端。
Having said, how about separating the low-level stuff from the high-level UI stuff. Build the low level stuff in each platform so they would have the very exact same APIs. The underlying internal implementation can be totally different, it does not matter, as long as they both expose the same interface. I think you'll find it interesting to do so. You also said you want the UI to feel native on each platform, then why not consider something like SWT in Java. If SWT and Java are not an option, then I guess you'll have to build the high-level stuff using WPF and Cocoa. But by this time, your job will be easier since you would be calling the same API that you previously built in your low-level libraries.
话虽如此,如何将低级别的东西与高级UI内容分开。在每个平台中构建低级别的东西,以便它们具有完全相同的API。底层的内部实现可以完全不同,只要它们都暴露相同的接口并不重要。我想你会觉得这样做很有意思。您还说过,您希望UI在每个平台上都有原生感,那么为什么不考虑使用Java中的SWT。如果SWT和Java不是一个选项,那么我猜你将不得不使用WPF和Cocoa构建高级东西。但是到了这个时候,您的工作将变得更加容易,因为您将调用之前在低级库中构建的API。
#5
1
If I were you I would go with a cross-platform framework and/or programming language, nowadays you have plenty of languages/frameworks that are working cross platform such as Java, QT (with both Java and C++ languages for using the toolkit), C# with MONO, GTK+ with C (gtkmm with C++, gtk# and Mono for C#). So it is more simple if you do it in one language/framework than in two simultaneously because if you write the same app in two different languages/frameworks it will cost you extra development time for half of that time you can get your hands on new framework and the language because you know from the very beginning that your target platform is multi-platform. If now your primary platform would be e.g Windows and later the Mac users like the application very much so then is the reason for re-writing it targeting another platform and using its development tools.
如果我是你,我会选择跨平台的框架和/或编程语言,现在你有很多跨平台的语言/框架,如Java,QT(使用工具包同时使用Java和C ++语言),带有MONO的C#,带有C的GTK +(带有C ++的gtkmm,带有C#的gtk#和Mono)。因此,如果你在一种语言/框架中比在两种语言/框架中同时使用它更简单,因为如果你用两种不同的语言/框架编写相同的应用程序,那么在一半的时间内你可以花费额外的开发时间来获得新的框架和语言,因为您从一开始就知道您的目标平台是多平台的。如果现在您的主要平台将是Windows,后来Mac用户非常喜欢该应用程序,那么就是将其重新编写为另一个平台并使用其开发工具的原因。
#6
1
Are you sure you can't abstract the low-level services into a common interface and still have enough app left (such as the UI) to make it more economical to develop in something cross-platform? If you want a shrt time-to-market it sounds wasteful to plan doing everything twice.
您确定无法将低级服务抽象为一个通用界面,并且仍然有足够的应用程序(例如UI),以便在跨平台的东西中开发更经济吗?如果你想要缩短产品上市时间,那么计划做两次所有事情听起来都是浪费。
#7
1
What about using a third language as glue for the native calls?
使用第三种语言作为原生呼叫的粘合剂怎么样?
I've heard that python or ruby have good capabilities for native lib integration. The difference could be abstracted through an internal API.
我听说python或ruby具有很好的本机lib集成功能。可以通过内部API抽象差异。
This way all the logic could be set in the third lang and the specific part in the other.
这样,所有逻辑都可以在第三个lang中设置,而特定部分在另一个中设置。
The same may go for Java, but I think the integration looks a little bit harder.
Java可能也是如此,但我认为集成看起来有点困难。
BTW this is the way ( or was? ) classes like java.io.File works.
顺便说一句,这是像java.io.File这样的方式(或者是?)。
Tell us how it went.
告诉我们它是怎么回事。
edit
I think the way big companies go with this is using C++ and using forks for platform specific code.
我认为大公司采用这种方式的方式是使用C ++并使用forks来处理特定于平台的代码。
#8
0
If you are going to have to learn a new technology anyway (Objective-C), I would give Java another look. Trying to develop the same program twice for two different platforms and learn too many things at once may mean that you wind up with a program that works well with neither - or an unsupportable mess if you get seduced into using features available on one platform but not on the other.
如果你不得不学习一门新技术(Objective-C),我会再看看Java。尝试为两个不同的平台开发两次相同的程序并一次学习太多东西可能意味着你最终得到一个既不能正常工作的程序 - 如果你被诱惑使用一个平台上可用的功能而不是一个不受支持的混乱在另一。
If you go with Java you'll only need to deal with some UI and installation quirks on each platform - the bulk of your app (and, importantly, any bug fixes you do) are going to port right away. Java UIs seem fairly mature right now, and there is a lot of reusable UI code (e.g. JIDE components are nice). If your app idea is truly killer, you can hire staff to do the 'first class citizen apps' after you make your millions.
如果你使用Java,你只需要在每个平台上处理一些UI和安装怪癖 - 你的应用程序的大部分(以及重要的是,你做的任何错误修复)都会立即移植。 Java UI现在看起来相当成熟,并且有许多可重用的UI代码(例如JIDE组件很好)。如果您的应用创意确实是杀手锏,您可以雇佣员工在您赚取数百万美元之后进行“头等公民应用”。
You could also look at how other cross platform apps have been delivered successfully - for example look at firefox, thunderbird, openoffice, and see what you can reuse. I know of a number of cross platform apps done in Java, too - for example I use PersonalBrain and crashplan, and they both seem to be java based, and it's not intrusive at all. (Interestingly, PersonalBrain was first delivered Windows only and they then did a Java rewrite. Some features are still windows only however, but I'm happy using it on a Mac.)
您还可以查看其他跨平台应用程序是如何成功交付的 - 例如,查看firefox,thunderbird,openoffice,以及了解可以重用的内容。我也知道用Java完成的许多跨平台应用程序 - 例如我使用PersonalBrain和crashplan,它们似乎都是基于java的,并且它根本不是侵入性的。 (有趣的是,PersonalBrain首先只提供了Windows,然后他们进行了Java重写。但是有些功能仍然是Windows,但我很高兴在Mac上使用它。)
It does depend on some extent on the application you want to write - for example will you want to support iPhone at some point? If so there is little choice currently but to use objective C, and you will probably see some reuse out of your MacOSX efforts if you plan ahead.
它在某种程度上取决于您要编写的应用程序 - 例如,您是否希望在某些时候支持iPhone?如果是这样,目前几乎没有选择,只能使用目标C,如果您提前计划,您可能会看到MacOSX工作中的一些重用。
Whatever you do, I would definitely suggest splitting the UI from the main logic of your program - and make that main logic as directly portable as possible. Otherwise you will be reinventing every wheel on every platform.
无论你做什么,我肯定会建议从你的程序的主要逻辑中分离UI - 并使主要逻辑尽可能直接移植。否则你将重新发明每个平台上的每一个*。
#9
0
As I usually mention with questions like this, you should also at least take a look at Real Studio, which allows you to create native desktop applications from the same code base. It also allows you to hook into low-level services using Declares or Plugins.
正如我经常提到的这样的问题,您至少应该看看Real Studio,它允许您从相同的代码库创建本机桌面应用程序。它还允许您使用Declares或Plugins挂钩到低级服务。
#1
4
You should focus on writing your application for one platform initially, and worry about porting it later. Your project is guaranteed to fail if you don't complete it, and trying to write it for two platforms at once is certain to increase the overall development time. And can you name one piece of commercial software that failed because they didn't support multiple platforms?
您应该专注于最初为一个平台编写应用程序,并担心以后移植它。如果你没有完成它,你的项目肯定会失败,并且尝试一次为两个平台编写它肯定会增加整个开发时间。您是否可以将一个失败的商业软件命名为因为它们不支持多个平台?
#2
5
I'd develop for whichever platform has the largest target-audience (as in for your killer app) first, then use the inevitable lessons I'd learn along the way to improve the way I'd develop for the other(s).
我会先为最大的目标受众(就像你的杀手级应用程序)开发平台,然后使用我不可避免的经验教训来改进我为其他人开发的方式。
#3
5
Although I've been fanatically looking for a desktop solution for both platforms, I don't think there's any problem with building the app twice... probably makes sense.
虽然我一直在*地寻找两种平台的桌面解决方案,但我认为构建应用程序两次没有任何问题...可能有意义。
That said, I don't think that you should build one and then the other, but try to do something madly difficult like use the same UML class diagrams for both. This will force you to do the hard work of dividing the app into the parts that are identical and the parts which are, by definition, platform specific.
也就是说,我不认为你应该构建一个然后另一个,但是尝试做一些疯狂的事情就像使用相同的UML类图一样。这将迫使您将应用程序划分为相同的部分以及根据定义特定于平台的部分进行艰苦的工作。
The idea is not to share a code base, but to share a software design.
这个想法不是共享代码库,而是共享软件设计。
#4
2
Both the pros and cons that you mentioned are absolutely valid. Personally, I hate going back and re-do something even in a different language than having to constantly mentally switch the language mindset. I am already doing this everyday where I am doing both the server development in Python and the client side in JavaScript.
您提到的优点和缺点都绝对有效。就个人而言,我讨厌回去,甚至用不同的语言重新做一些事情,而不是不断地在心理上转换语言思维。我每天都在做这个,我在Python中进行服务器开发,在JavaScript中进行客户端。
Having said, how about separating the low-level stuff from the high-level UI stuff. Build the low level stuff in each platform so they would have the very exact same APIs. The underlying internal implementation can be totally different, it does not matter, as long as they both expose the same interface. I think you'll find it interesting to do so. You also said you want the UI to feel native on each platform, then why not consider something like SWT in Java. If SWT and Java are not an option, then I guess you'll have to build the high-level stuff using WPF and Cocoa. But by this time, your job will be easier since you would be calling the same API that you previously built in your low-level libraries.
话虽如此,如何将低级别的东西与高级UI内容分开。在每个平台中构建低级别的东西,以便它们具有完全相同的API。底层的内部实现可以完全不同,只要它们都暴露相同的接口并不重要。我想你会觉得这样做很有意思。您还说过,您希望UI在每个平台上都有原生感,那么为什么不考虑使用Java中的SWT。如果SWT和Java不是一个选项,那么我猜你将不得不使用WPF和Cocoa构建高级东西。但是到了这个时候,您的工作将变得更加容易,因为您将调用之前在低级库中构建的API。
#5
1
If I were you I would go with a cross-platform framework and/or programming language, nowadays you have plenty of languages/frameworks that are working cross platform such as Java, QT (with both Java and C++ languages for using the toolkit), C# with MONO, GTK+ with C (gtkmm with C++, gtk# and Mono for C#). So it is more simple if you do it in one language/framework than in two simultaneously because if you write the same app in two different languages/frameworks it will cost you extra development time for half of that time you can get your hands on new framework and the language because you know from the very beginning that your target platform is multi-platform. If now your primary platform would be e.g Windows and later the Mac users like the application very much so then is the reason for re-writing it targeting another platform and using its development tools.
如果我是你,我会选择跨平台的框架和/或编程语言,现在你有很多跨平台的语言/框架,如Java,QT(使用工具包同时使用Java和C ++语言),带有MONO的C#,带有C的GTK +(带有C ++的gtkmm,带有C#的gtk#和Mono)。因此,如果你在一种语言/框架中比在两种语言/框架中同时使用它更简单,因为如果你用两种不同的语言/框架编写相同的应用程序,那么在一半的时间内你可以花费额外的开发时间来获得新的框架和语言,因为您从一开始就知道您的目标平台是多平台的。如果现在您的主要平台将是Windows,后来Mac用户非常喜欢该应用程序,那么就是将其重新编写为另一个平台并使用其开发工具的原因。
#6
1
Are you sure you can't abstract the low-level services into a common interface and still have enough app left (such as the UI) to make it more economical to develop in something cross-platform? If you want a shrt time-to-market it sounds wasteful to plan doing everything twice.
您确定无法将低级服务抽象为一个通用界面,并且仍然有足够的应用程序(例如UI),以便在跨平台的东西中开发更经济吗?如果你想要缩短产品上市时间,那么计划做两次所有事情听起来都是浪费。
#7
1
What about using a third language as glue for the native calls?
使用第三种语言作为原生呼叫的粘合剂怎么样?
I've heard that python or ruby have good capabilities for native lib integration. The difference could be abstracted through an internal API.
我听说python或ruby具有很好的本机lib集成功能。可以通过内部API抽象差异。
This way all the logic could be set in the third lang and the specific part in the other.
这样,所有逻辑都可以在第三个lang中设置,而特定部分在另一个中设置。
The same may go for Java, but I think the integration looks a little bit harder.
Java可能也是如此,但我认为集成看起来有点困难。
BTW this is the way ( or was? ) classes like java.io.File works.
顺便说一句,这是像java.io.File这样的方式(或者是?)。
Tell us how it went.
告诉我们它是怎么回事。
edit
I think the way big companies go with this is using C++ and using forks for platform specific code.
我认为大公司采用这种方式的方式是使用C ++并使用forks来处理特定于平台的代码。
#8
0
If you are going to have to learn a new technology anyway (Objective-C), I would give Java another look. Trying to develop the same program twice for two different platforms and learn too many things at once may mean that you wind up with a program that works well with neither - or an unsupportable mess if you get seduced into using features available on one platform but not on the other.
如果你不得不学习一门新技术(Objective-C),我会再看看Java。尝试为两个不同的平台开发两次相同的程序并一次学习太多东西可能意味着你最终得到一个既不能正常工作的程序 - 如果你被诱惑使用一个平台上可用的功能而不是一个不受支持的混乱在另一。
If you go with Java you'll only need to deal with some UI and installation quirks on each platform - the bulk of your app (and, importantly, any bug fixes you do) are going to port right away. Java UIs seem fairly mature right now, and there is a lot of reusable UI code (e.g. JIDE components are nice). If your app idea is truly killer, you can hire staff to do the 'first class citizen apps' after you make your millions.
如果你使用Java,你只需要在每个平台上处理一些UI和安装怪癖 - 你的应用程序的大部分(以及重要的是,你做的任何错误修复)都会立即移植。 Java UI现在看起来相当成熟,并且有许多可重用的UI代码(例如JIDE组件很好)。如果您的应用创意确实是杀手锏,您可以雇佣员工在您赚取数百万美元之后进行“头等公民应用”。
You could also look at how other cross platform apps have been delivered successfully - for example look at firefox, thunderbird, openoffice, and see what you can reuse. I know of a number of cross platform apps done in Java, too - for example I use PersonalBrain and crashplan, and they both seem to be java based, and it's not intrusive at all. (Interestingly, PersonalBrain was first delivered Windows only and they then did a Java rewrite. Some features are still windows only however, but I'm happy using it on a Mac.)
您还可以查看其他跨平台应用程序是如何成功交付的 - 例如,查看firefox,thunderbird,openoffice,以及了解可以重用的内容。我也知道用Java完成的许多跨平台应用程序 - 例如我使用PersonalBrain和crashplan,它们似乎都是基于java的,并且它根本不是侵入性的。 (有趣的是,PersonalBrain首先只提供了Windows,然后他们进行了Java重写。但是有些功能仍然是Windows,但我很高兴在Mac上使用它。)
It does depend on some extent on the application you want to write - for example will you want to support iPhone at some point? If so there is little choice currently but to use objective C, and you will probably see some reuse out of your MacOSX efforts if you plan ahead.
它在某种程度上取决于您要编写的应用程序 - 例如,您是否希望在某些时候支持iPhone?如果是这样,目前几乎没有选择,只能使用目标C,如果您提前计划,您可能会看到MacOSX工作中的一些重用。
Whatever you do, I would definitely suggest splitting the UI from the main logic of your program - and make that main logic as directly portable as possible. Otherwise you will be reinventing every wheel on every platform.
无论你做什么,我肯定会建议从你的程序的主要逻辑中分离UI - 并使主要逻辑尽可能直接移植。否则你将重新发明每个平台上的每一个*。
#9
0
As I usually mention with questions like this, you should also at least take a look at Real Studio, which allows you to create native desktop applications from the same code base. It also allows you to hook into low-level services using Declares or Plugins.
正如我经常提到的这样的问题,您至少应该看看Real Studio,它允许您从相同的代码库创建本机桌面应用程序。它还允许您使用Declares或Plugins挂钩到低级服务。