Android 内容提供商多应用程序灵活性

我一直在训练自己学习Android开发。我想到了一系列应用程序，它们都与存储相似/相关爱好数据的相同基本数据存储相关。我想在我看来，访问这些数据应该类似于有多少应用程序使用联系人。所以我开始阅读内容提供商的文章，但从我所看到的，他们实际上并没有提供我所需要的灵活性

我想要的是创建4或5个与爱好相关的应用程序，记录类似和相关的数据，但是客户可能会决定他们只需要一个特定的应用程序。之后，他们可能会认为一个或多个其他应用程序也可能有用

应用商店的数据非常相似，核心数据是相同的。因此，显而易见的选择是内容提供商。但是，我看不到提供商提供我所需要的灵活性。首先，购买的第二个应用程序如何确定内容提供商已经可用，如果可用，则不安装自己的应用程序（这似乎是清单中的硬连接，并且没有编程控制）。其次，应用程序如何意识到没有内容提供商并安装一个（与第一点相关）。第三，新安装的应用程序可能会有更新的提供商或更老的提供商

所以我不认为供应商提供了我所需要的。我还注意到数据库是沙盒的，提供者似乎是应用程序共享持久数据的唯一方法，或者我缺少什么。这实际上让我想知道，对于没有默认安装的内容提供商来说，这些提供商是多么有用

我想另一种方法是让客户购买和应用程序，然后在以后发布额外功能的广告，但我不确定这是否可行，以及信息在哪里

任何帮助都将不胜感激

主持人史提夫注意到：起初我认为我会认为这是一个争论性的问题，但现在我想，我认为这是一个设计问题。一个会留在这里的好孩子

应用商店的数据非常相似，核心数据是相同的。因此，显而易见的选择是内容提供商

对

首先，购买的第二个应用程序如何确定内容提供商已经可用，如果可用，则不安装自己的应用程序（这似乎是清单中的硬连接，并且没有编程控制）。其次，应用程序如何意识到没有内容提供商并安装一个（与第一点相关）。第三，新安装的应用程序可能会有更新的提供商或更老的提供商

许多应用程序通过在市场上提供“库应用程序”来实现这一点，该应用程序提供了您可能需要的其他应用程序的通用功能。您应该要求这些应用程序中的用户下载该库应用程序，以启用“UI应用程序”的底层功能。我不知道，也许我会走那条路。。。毕竟，您需要考虑内容提供者的命名空间冲突，因此需要“库应用程序”。

我想另一种方法是让客户购买和应用程序，然后在以后发布额外功能的广告，但我不确定这是否可行，以及信息在哪里

是的，这就是应用内计费的目的。然而，这假设你有一个具有不同功能的应用程序

事实是，这是个好问题。这的确引起了我的思考。我相信这取决于你提供一个应用程序，该应用程序具有应用内计费添加的一套功能，或者许多应用程序共享一个中央应用程序提供的通用功能，这些中央应用程序在市场上也可用

关于最后一个问题，我会做用户觉得更自然的事情。如果这些应用程序真的不相关，就主题而言，我会提供不同的应用程序。如果它是一个类似套件的产品（比如说Office套件），我会实施应用内购买。还有一个关于代码可见性的小安全问题（通过软件启用而不是每次下载）

无论如何，在我看来，应用内购买绝对更简单，更容易维护。但是如果你的应用程序那么大，那可能是浪费空间。。。效率不高

---

我的2美分。

谢谢你的回复，大卫。其他人也向我提到了应用程序内购买，所以这是你们两个现在，所以这是我将要阅读的东西。我可以制作一个基础应用程序，它的功能可以在模块化的基础上添加。然后，我可以用一个模块销售应用程序，或者用不同的第一个模块销售多个版本。我仍然认为我发现了内容提供商的一个问题，尽管目前他们的创建和管理似乎不够灵活，我认为谷歌在这方面缺少了一个技巧。