我一直在Android开发中训练自己。我对一系列应用程序有所了解，这些应用程序都与存储类似/相关爱好数据的相同基本数据存储有关。我想在我看来，对这些数据的访问应该类似于有多少应用程序使用联系人。所以我开始阅读内容提供商，但据我所知，他们实际上并没有提供我所需要的灵活性。
我想要的是创建说4或5个爱好相关的应用程序，记录相似和相关的数据，但客户可能会决定他们只需要一个特定的数据开始。稍后他们可能会决定其他一个或多个应用程序也可能有用。
应用商店存储的数据非常相似，核心数据是相同的。所以显而易见的选择是内容提供商。但是，我看不到提供商提供我需要的灵活性。首先，购买的第二个应用程序如何确定内容提供商已经可用，如果没有安装它自己（这似乎是在清单中硬连线并且没有程序控制）。其次，应用程序将如何实现没有内容提供者并安装一个（与第一点相关）。第三，安装的新应用可能有更新的提供商或更老的提供商！
所以我不认为提供商提供我需要的东西。我还注意到数据库是沙盒的，提供者似乎是应用程序共享持久数据的唯一方法，或者是我缺少的东西。它实际上让我想知道没有默认安装内容提供商如何有用的提供商！
我认为另一种方法是让客户购买和使用应用程序，然后再刊登额外的功能，但我不确定这是否可行，如果有的话，信息的位置是。
任何帮助都将不胜感激。
史蒂夫
答案 0 :(得分：4)
对版主的注意事项：起初我以为我认为这是一个议论问题，但现在我再想一想，我认为这是一个设计问题。一个很好的人留在这里。
应用商店存储的数据非常相似，核心数据是相同的。所以显而易见的选择是内容提供商。
是
首先，购买的第二个应用程序如何确定内容提供商已经可用，如果没有安装它自己（这似乎是在清单中硬连线并且没有程序控制）。其次，应用程序将如何实现没有内容提供者并安装一个（与第一点相关）。第三，安装的新应用可能有更新的提供商或更老的提供商！
许多应用程序通过在市场中提供“库应用程序”来实现此目的，该应用程序提供了您可能需要的其他应用程序的常用功能。您应该要求用户在任何这些应用程序中下载该库应用程序以启用“UI应用程序”的基础功能。我不知道，也许我会采取这种方式......毕竟，你需要考虑你的内容提供商的命名空间冲突，因此“库应用程序”。
我认为另一种方法是让客户购买和使用应用程序，然后再刊登额外的功能，但我不确定这是否可行，如果有的话，信息的位置是。
是的，这就是应用内结算的目的。但是，假设您有一个具有不同功能的应用。
事实是，这是一个很好的问题。它当然引起了我的思考。我相信您需要提供一个应用程序，该应用程序具有通过应用程序内结算添加的一系列功能，或者许多应用程序共享由市场上提供的一个中央应用程序提供的通用功能。
关于这最后一个问题，我会做一些让用户觉得更自然的事情。如果应用程序真的不相关，主题方面，我会提供不同的应用程序。如果它是类似套件的产品（例如，想想Office套件），我会实现应用内购买。关于代码可见性也存在一个小的安全问题（通过软件启用与按下载启用）。
无论如何，在我看来，应用内购买肯定更简单，更容易维护。但是如果你的应用程序那么大，那可能是浪费空间......效率不高。
我的2美分。