Eclipse 中的 Android 和 Blackberry 项目
我对 android 相当陌生，并且只真正使用 eclipse 进行一些基本的 Blackberry 工作，所以我很好奇是否可以挑选一些专家的想法来了解您用于双平台支持项目的工作区/项目设置的任何建议/指针蚀？
我发现大约 80% 的代码在 Blackberry 和 Android 之间是通用的，因此我需要解决这 20% 的问题。
我目前的想法是通过在源树选项中设置多个项目来在一个工作区中共享源代码。
在使用特定于平台的功能的情况下，我将分别将源名称标记为 *Android_???* 和 *Blackberry_???* ，并拥有两个项目都指向的通用类。
即，实际上，一个工作区同时包含 Android 和 Blackberry 设置，并且工作区中有一个用于 Blackberry 的项目和一个用于 Android 的项目，但每个项目与从构建中排除的适当其他平台的源文件共享相同的文件系统。
如果有一种简单的方法可以在 java 中执行相当于 #ifdef 的操作，这将简化此端口，但我想我们必须这样做。（我听说过使用 ac 预处理器来执行此操作，但听起来很混乱所以除非强烈推荐，否则我宁愿不采用这个）
我听说过创建一个共享库，但感觉它们在android和黑莓之间不兼容，所以也欢迎任何关于这种方法的建议。
I'm fairly new to android and have only really been using eclipse for some basic Blackberry work so I was curious if I could pick a few expert's minds for any suggestions/pointers on the workspace/project setup you use for dual platform support projects in eclipse?
I've found about 80% of my code is common between Blackberry and Android so it's this 20% I'm needing to address.
My current thinking is to have one workspace with shared source in multiple projects via setting them in the source tree options.
Where platform specific features are used I'll tag the source name as *Android_???* and *Blackberry_???* respectively and have a generic class that both projects point to.
I.e. effectively one workspace holds both Android and Blackberry setups and in the workspace have one project for Blackberry and one for Android but each project shares the same filesystem with the appropritate other platform's source files excluded from the build.
If only there was an easy way of doing the #ifdef equivalent in java this would simplify this port but I guess we have to do it without.(I heard about using a c preprocessor to do this but sounds messy so unless it's highly recommended I'd rather not adopt this)
I'd heard about creating a shared library but have a feeling these are not compatible between android and blackberry so any advice on this approach is also welcome.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
可能已经太晚了，但我仍然会告诉你我的想法。
我有类似的需求。我有通用代码以及 Blackberry 和 Android 特定部分。我为每个部分创建了三个独立的 Eclipse 项目。 “特定”项目是实际运行的项目，它们都对通用项目具有项目依赖性（我发现它比源包含更清晰）。
请注意，Common 项目必须是 Blackberry 项目（使用插件创建），因为 Blackberry 项目不能依赖于非 Blackberry 项目。
它对我来说效果很好！
It's probably too late, but I'll still give you my thoughts on that.
I have a similar need. I have common code and Blackberry and Android specific parts. I have three separate Eclipse project for each part. The "specific" projects are the one actually run, and they both have a project dependancy (which I find cleaner than source inclusion) on the Common one.
Note that the Common project must be a Blackberry project (created using the plugin), since a Blackberry project cannot depend on a non-blackberry project.
It's working well for me!
对于面临此问题的其他人，我发现有效的解决方案是在磁盘上创建 3 个目录
Common
黑莓
Android
绝大多数进入 Common，但是具有平台特定调用的类分别进入 Blackberry/Android 对应项，并在公共目录中扩展公共基类。
例如，需要平台特定版本的名为 MyClass 的类将在公共目录中具有 MyClassCommon，并且在 Blackberry 目录中它具有 MyClass 扩展 MyClassCommon 定义，对于 Android 也是如此。
在 Eclipse 中，Common、Blackberry、Android src 路径是通过公共变量（trunk）单独添加的，该变量扩展为 3 个 src 根导入的 Common、Blackberry、Android 路径。
这似乎是确保包名称跨平台一致的唯一机制，因此不会产生其他依赖类需要新包名称的连锁效应。
我确信有一种更优雅/正确的方法可以做到这一点，但目前看来效果很好。
For anyone else facing this issue I've found the solution that worked was by creating 3 directories on disk
Common
Blackberry
Android
The vast majority goes into Common however the classes that have platform specific calls go into the Blackberry/Android counterparts respectively and extend a common base class in the common directory.
E.g. a class called MyClass that needed platform specific versions would have a MyClassCommon in the common directory and in the Blackberry directory it has MyClass extends MyClassCommon definition and the same for Android.
In Eclipse the Common,Blackberry,Android src paths are individually added via a common variable (trunk) which is extened to the Common,Blackberry,Android paths for the 3 src root imports.
This seemed to be the only mechanism to ensure that the package name was consistent across platforms so not having a knock on effect that other dependent classes needed new package names.
I'm sure there is a more elegant/correct way of doing this but this appears to work well for now.