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

Question

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

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

应用程序存储的数据非常相似，核心数据是相同的。所以明显的选择是内容提供商。但是我看不到提供商提供我需要的灵活性。首先，购买的第二款应用程序如何知道内容提供商已经可用，如果没有安装它（这似乎在清单中硬连线，并且没有程序控制）。其次，应用程序如何识别没有内容提供者并安装一个（与第一点相关）。第三，安装的新应用程序可能拥有更新的提供程序或较旧的提供程序！

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

我想一个替代的方法应该是客户购买和应用程序，然后后来广告额外的功能，但我不知道这是可能的，如果是这样的信息。

任何帮助，将不胜感激。

史蒂夫

Answer 1

注到版主：起初我以为我会认为这是一个争论的问题，但现在，我再想一想，我认为这是一个设计问题。一个好的人应该留在这里。

应用程序存储的数据非常相似，核心数据是相同的。所以明显的选择是内容提供商。

是的。

首先，第二次购买的应用程序如何知道内容提供程序已经可用，如果没有安装它（这似乎是硬连接在清单中并且没有程序控制）。其次，应用程序如何识别没有内容提供者并安装一个（与第一点相关）。第三，安装的新应用程序可能拥有更新的提供程序或较旧的提供程序！

许多应用程序通过在市场中提供“库应用程序”来实现此目的，该应用程序提供了其他应用程序可能需要的常用功能。您应该在任何这些应用程序中要求用户下载该应用程序库以启用“UI应用程序”的基础功能。我不知道，也许我会走这条路......毕竟，你需要考虑你的内容提供者的命名空间冲突，因此是“图书馆应用程序”。

我想一个替代方法是让客户购买和应用程序，然后后来广告额外的功能，但我不知道这是可能的，如果是这样的信息。

是的，这就是应用内​​结算的用途。不过，这假定你会有一个具有不同功能的应用程序。

事实是，这是一个很好的问题。这当然引起了我的思考。我相信您可以自己决定提供一款应用程序，其中包含通过应用内结算功能添加的一系列功能，或许多应用程序可以共享市场上同一个中央应用程序提供的通用功能。

关于这最后一个问题，我会做什么感觉更自然的用户。如果这些应用程序真的不相关，那么我会提供不同的应用程序。如果它是一个类似于套件的产品（例如，考虑Office套件），我会实施应用内购买。在代码可见性方面也存在一个小的安全问题（通过软件或每次下载实现）。

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

我的2美分。