是否有一个“适当的”？如何将内容提供商的实现与其用户分开？
我有一个自定义 ContentProvider 类，它最初是在与使用它的应用程序相同的项目文件中开发的。但是，由于此应用程序只是 ContentProvider 的众多用户之一，因此我想将其拆分到不同的项目中。该代码正在 Android PDK 上开发，但未来的客户端可能会在 SDK 上开发（在自定义 SDK 或 SDK 插件等上）。
我面临的问题是关于 ContentProvider 类中的常量，例如 CONTENT_URI、列名以及一些用于解释从查询返回的值的常量。当然，这些不能从其他项目访问。在我看来，此时我有 3 个选择：
1）忽略问题，直接在用户应用程序代码中输入值。然而，这使得访问 ContentProvider 变得更加难看。我必须更改一些列，用字符串而不是整数对某些列进行编码，以保持代码的可维护性。
2) 将常量放入单独的类中，并在使用 ContentProvider 的应用程序中包含完整副本。不过，我不喜欢重复代码。在每个目标应用程序中保留此代码的副本会使某些事情的维护变得更加烦人。
3) 滥用我正在 PDK 上进行开发的事实，并公开平台库，如 vendor/sample/frameworks/PlatformLibrary 中所述。但是，平台库没有清单文件，如果我的理解正确的话，这意味着我不能包含 ContentProvider。这意味着我需要一个用于 ContactProvider 的“正常”项目，以及一个单独的项目来公开具有常量值的类。这感觉太不对劲了。
答案位于具有多个子表的ContentProvider的类结构 似乎暗示选项（1），这可能看起来是目前最好的选项。
然而，也许我错过了另一个，整洁的&整洁，如何做到这一点？请记住，我正在 PDK 上进行开发，我当然希望我的 ContentProvider 能够以与现有 Google 提供商相同的方式使用。
I have a custom ContentProvider class, which I originally developed in the same project file with the application using it. However since this application is intended to be only one of many users of the ContentProvider, I want to split it in a different project. The code is being developed on the Android PDK, but future clients might be developed on the SDK (on a custom SDK, or SDK plugin, etc).
The problem I'm facing, is about the constants in the ContentProvider class, e.g. CONTENT_URI, column names and as well some constants which are used to interpret the values returned from queries. These of course cannot be accessed from another project. It seems to me I have 3 options at this point:
1) Ignore the problem, and type in the values directly in the user application code. This however makes accessing the ContentProvider uglier. I would have to change some columns, to encode some columns with strings instead of integers, to keep the code maintainable.
2) Put the constants in a separate class, and include a full copy in applications using the ContentProvider. I'm not a fan of duplicating code though. Keeping a duplicate of this code in each target app, will make some things slightly more annoying to maintain.
3) Abuse the fact that I'm developing on the PDK, and expose a platform library, as described in vendor/sample/frameworks/PlatformLibrary. However, platform libraries don't have a manifest file, which if my understanding is correct means that I can't include a ContentProvider. This means I would need one "normal" project for the ContactProvider, and a separate one just to expose the class with the constant values. This feels so much wrong.
The answer at Class structure for a ContentProvider having multiple sub tables seems to imply option (1), which probably looks like the best option right now.
However, maybe I have missed another, neat & tidy, way to do this? Keeping in mind that I am developing on the PDK, I would certainly like my ContentProvider to be usable in the same manner as stock Google providers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可能已经拥有至少一个类/接口，它使用列名、内容 URI 等静态常量来定义
ContentProvider的“契约”。如果您将其放入其自己的 Android SDK 库项目中（仅适用于构建/类路径上的 Android 类），然后您可以从实际 SDK/PDK 应用程序的
ContentProvider使用此库，并将其分发为myapp-api.jar< /code> JAR 供其他人使用。这样您就可以两全其美：没有过时的代码（因为您的
ContentProvider依赖于它），其他人可以使用漂亮的 URI 和列名常量。有关合约类的示例，请参阅 ContactsContract。
You probably already have at least one class/interface that defines the "contract" of your
ContentProviderusing static constants for column names, a content URI, etc.If you put this into its own Android SDK library project (just for the Android classes to be on the build/classpath), you can then use this library from your actual SDK/PDK application's
ContentProviderand also distribute it asmyapp-api.jarJAR for others to use.This way you get the best of both worlds: No outdated code (because your
ContentProviderdepends on it) and other people can use nice constants for URIs and column names.For an example of a contract class, see ContactsContract.