Android 将 ContentProvider 作为与应用程序捆绑在一起的库进行分发

Question

我正在开发一组新颖的应用程序，这些应用程序具有相同的基本行为（从数据库中选择随机单词并将它们组合起来）。因为它们的工作原理基本相同，所以我尝试将代码的基础视为某种模板，但结果好坏参半。

当我正在进行更新时，我想让该项目对 MVC 更加友好，并开始考虑使用 ContentProvider 而不是直接的 SQLiteOpenHelper。我倾向于这种方式，因为谷歌的文档对于使用它们是令人难以置信的坚定。我的问题是命名冲突领域。

TL;DR 跳过此处回答问题。

如果两个第 3 方 Android 应用程序（由同一开发人员制作）都想使用相同的 ContentProvider，但不依赖于正在安装的另一个应用程序，它们是否都可以包含ContentProvider 的副本（具有相同的权限和所有内容）并允许同时安装（使用可用的 ContentProvider 的最高版本）？

我不确定这是否可以通过内容提供商的设置方式实现，这似乎是单一的。我无法想象谷歌没有将此视为潜在的问题或所需的功能。是的，可能会出现一些复杂性，但我们已经克服了 dll 地狱和其他类似名称的问题……正确地做到这一点并不是那么困难。

Answer 1

我倾向于这种方式，因为 Google 的文档对于使用它们非常坚决。

并非所有谷歌员工都同意这一立场，更不用说像我这样的其他笨蛋了。我只使用 ContentProvider 在进程之间共享数据。

如果两个第 3 方 Android 应用程序（由同一开发人员制作）都想要使用相同的 ContentProvider，但不依赖于正在安装的另一个应用程序，它们是否都可以包含 ContentProvider 的副本（具有相同的权限和所有内容）并允许同时安装（使用可用的 ContentProvider 的最高版本）？

AFAIK，注册的第一个 ContentProvider 将获胜，而不是最高版本。事实上，我不确定如果第二个应用程序尝试重新定义现有的 ContentProvider 是否会安装。

此外，如果用户卸载当前的 ContentProvider，另一个应用程序就会被搞砸，因为它的数据现在变得“噗”。