Android 访问同一数据库的两个内容提供商

大家好

我想知道如果一个人想让两个完全不同的Android应用程序访问和操作同一个数据库，是否有一个普遍首选的实现范例值得尊重？是否建议或甚至在技术上可能这样做？这样的架构会是什么样子

到目前为止，我正在考虑让这两个应用程序实现它们自己的

ContentProvider

s（尽管这两个

ContentProvider

s将访问同一个数据库，但保证永远不会同时访问）。我还考虑构建一个公共内容提供者，并让两个应用程序在访问数据库时都使用该提供者。我更喜欢第一个例子，但没有完全抛弃后面的例子

理由：
我有两个应用程序需要访问一个公共数据库。数据库本身存储数据，但也描述数据行之间的关系，通常描述一组“表单”，其中表单内容；UI元素，如文本框、按钮和不同类型的列表，是可自定义的。这两个应用程序都使用数据库中的“描述数据”在运行时生成相应应用程序UI的一部分

因此，这两个应用程序有两个方面：一个“管理”方面（管理数据结构和数据行之间的关系）和一个“通用用户”方面（读取/修改实际数据值）。在不同的应用程序中分离这两个方面是一个深思熟虑的选择

注意！数据值与数据结构分离，即值存储在一个单独的表中，结构在另一个表中描述。这意味着这两个应用程序本质上会修改同一数据库中的两个不同表，而且它们永远不会修改“另一个表”

任何想法都非常感谢。应用程序还处于规划阶段，因此，现在是进行根本性更改的时候了。

Dbm

是的，在安卓系统上这样做是被接受、鼓励和可能的。你有第三个选择（这无疑会给我带来一些激烈的评论），那就是把内容提供者（1）放在一个APK中，这是它自己的。但是，考虑到您只有两种类型，您可以将其托管的apk翻转四分之一。我会选择管理应用程序，但这是我主观的一部分

如果您在创建两个应用程序时遇到了麻烦，那么您对每个应用程序的行为以及每个应用程序可以操作的数据类型具有“先验”知识。因此，我将总结一个CP接口，并根据您描述的行为限制每个应用程序调用的内容

---

弗兰克

谢谢你的快速回答。我觉得把

ContentProvider

放在自己的APK中有点勇敢，但我不能马上放弃它（这个想法很有趣，它让我的注意力像被迷住了一样）：-）把它放在自己的APK中有什么好处吗？如果CP APK没有出现在目标上，我会看到一些问题。然后，我可能必须在客户端（管理和用户APK）中实现某种“优雅降级”的概念。@dbm我把它扔进了炖锅，因为它似乎是第三个选项。除非你想在构建->发布细分方面有极大的灵活性，否则我不知道（没有想到）第三代APK会给你带来什么。CP接口无论位于何处都可以公开。如果DB/CP是一个需要定期更新的通用信息集合，出于部署原因，我会选择将其作为自己的APK。@dbm没问题。。。想知道你的决定是以哪种方式做出的吗？我想我会对这两种解决方案都做一些试验。但到目前为止，我发现“仅两个APK”解决方案更具吸引力。通过这种方式，我看到了依赖性的减少（这两个应用程序都不依赖于预安装的ContentProvider APK），并且在管理和用户应用程序之间有了更清晰的划分，这毕竟是本例中的圣杯：-）