2009-06-19 133 views

回答

4

这是不可能的,据我了解你的问题 - iPhone和Java的二进制格式不兼容 - 甚至对于黑莓设备上的本地库。

这不像是为OS X构建的,您可以非常容易地使用Java,而iPhone不支持Java。

最好的想法可能是在Objective-C中构建您的库,然后将其移植到Java,这比通过其他方式更容易。如果您为Objective-C编程并确保您的代码没有内存泄漏 - 那么这些更改并不复杂。

如果你把你的类的结构相同,那么你应该找维修简单得多 - 修复在Java中的错误,你应该发现很容易检查在ObjC方法等

同样的错误希望这会有所帮助 - 抱歉,这不是所有的好消息。

+0

这确实帮助。我编辑了我的文章一点。我更多地寻找一种最佳实践,而不是共享二进制文件的能力。内存泄漏指导正是我正在寻找的信息。 – 2009-06-19 14:24:10

+0

我同意teabot - 任何你可以做的设计类似的将是一个巨大的胜利。 – Grouchal 2009-06-19 15:02:29

4

正如Grouchal提到的那样 - 您无法在两个平台之间共享应用程序的任何物理组件。但是,如果您仔细将其分解为高度分离的图层,则应该可以共享应用程序的逻辑设计。这仍然是一个巨大的胜利,因为逻辑应用程序设计可能占您开发工作的很大一部分。

您可以尝试将自己的界面中使用的特定于平台的API(iPhone SDK等)部分包装起来。这样做可以有效地隐藏特定于平台的库,并在处理平台差异时使您的设计和代码更易于管理。

使用此功能,您可以编写核心应用程序代码,使其在任一平台上看起来都非常相似 - 即使它们是用不同语言编写的。我发现Java和Objective-C在概念上非常相似(至少在我使用它的级别),并且期望能够实现至少与以下级别的对等性:

  • 几乎相同的一组Java和Objective-C类具有相同的名称和职责
  • 的Java/Objective-C类具有类似的命名方法
  • 的Java/Objective-C的方法具有相同的责任和逻辑实现

仅凭这一点使应用程序更易于理解a跨平台。当然,代码在边缘看起来总是非常不同 - 也就是说当你开始处理视图,线程,网络等时。然而,这些问题将由你的API包装器处理,它们一旦开发出来就应该有相当静态的接口。

如果您稍后开发者需要将更多应用程序交付给这两个平台,您可能也会受益,因为您可能会发现可以重用或扩展您的API包装器。

3

如果你正在编写一个客户端 - 服务器类型的应用程序,你应该尽可能地在你的服务器上尽可能地保持逻辑。尽量减少设备上的额外业务逻辑。您可以将设备视为视图层越多,您就必须完成更少的移植操作。除此之外,在所有项目中遵循相同的命名约定和包结构有很大帮助,特别是对于您的框架代码。

用于BlackBerry和iPhone的UI API和可用性范例非常不同,以至于在大多数情况下,在应用程序之间直接移植这种逻辑是不可能的。在我看来,最大的错误是试图将为一个移动平台设计的用户体验移植到另一个平台上。人们与黑莓手机和iPhone手机的互动方式非常不同,因此准备为您想部署的每个移动平台重新调整您的用户体验。

希望这是有帮助的。

+0

你是对的大错,并确保用户交互在每个平台上一致。 有关在服务器上放置尽可能多的代码的评论并不总是有效 - 它依赖于具有良好连接的用户。我认为如果你的解决方案是让服务器尽一切努力去写一个web应用程序。如果您打算使用本地应用程序,那么如果用户需要服务器执行核心操作并且用户没有信号,则用户体验不佳。 – Grouchal 2009-06-19 16:07:31

0

可以编写适用于BB10 Native应用程序和iOS应用程序的C++代码。 XCode需要将C++文件看作ObjectiveCPP代码。

我目前在业余时间从事这样的工作。我还没有完成足以显示或知道它是否真的可能,但我还没有跑到任何路障。

您需要遵守纪律才能编写出具有平台特定功能的,具有抽象的良好跨平台代码。

我的一般模式是,我有“班Foo”做跨平台的东西,而“班FooPlatform”做特定平台的东西。 “Foo”类可以调用类“FooPlatform”,它抽象出任何特定平台。

原始的跨平台代码本身不能编译。 独立的BB10和XCode项目在其各自的IDE中创建。 每个项目都实现了一个很小的(几十行)“class FooPlatform”,并引用了原始的跨平台代码。

当我得到的东西的工作,我可以证明我将张贴在这里再次...