3

我正在决定如何构建我的应用内购买。我的目标是在没有我自己的服务器基础架构的情况下做到这一点。

我的应用程序生成 PDF 格式的报告，该报告通过电子邮件导出。我想将报告的数量限制为 3，之后必须再购买 3 个。报告的所有数据以及报告本身都是在设备上本地创建的。

这应该是一种Non-Consumable类型吗？也许不是，因为它在文档中说这应该是一次性购买。但我希望用户能够再次购买另外 3 份甚至 10 份报告。但是，它还说这种类型应该在安装了我想要的应用程序的所有设备上自动可用。

或者它应该是一种Consumable类型？同样，这似乎不合适。文档声明它“必须在用户每次需要该项目时购买”。. 从概念上讲，这似乎很接近，但是如果在 iPhone 上消耗了 2 个报告，并且每个设备上仍然应该有一个报告，我该如何跟踪？

我想我们可以排除Auto-Renewable Subscription。

也许它应该是一个Non-Renewable Subscription. 但是，我不希望我的报告信用有一个到期日期，理想情况下它们应该传播到所有设备，这种类型也不提供。

我愿意在全设备传播上妥协。应准确跟踪积分，并且应该可以无限量购买。

这将如何在应用程序中实现？NSUserDefaults在启用导出按钮之前只检查一个数字？每次导出报告时是否可以通过 StoreKit 以某种方式进行检查？（它是通过电子邮件导出的，因此无论如何在线都是先决条件）。

是否可以避免我自己的服务器基础架构？如果没有，我需要跟踪什么？

有什么想法、指导和建议吗？

4

2 回答 2

2

正如 Black Frog 的回答中提到的，仅仅为了避免服务器基础设施，依靠 Apple 的一方可能是一个更难的解决方法。您必须撤销较旧的购买并计算用户花费了什么以及剩下什么。即使这样，我想你也需要一台服务器。

我将尝试将整个消耗品应用内循环分解；

  • 实现应用内 (iOS) 的客户端
  • 对于服务器端，您将需要；（最小的努力）
    • 两张表，一张保存用户及其剩余使用时间（积分）和一张保存购买报告
    • 两个脚本，（在 php 上简单几行）一个用于减少信用，一个用于保存来自 Apple 的收据信息，以及验证它。

基本上你不需要一个完整的基础设施来实现你应用内的服务器端，所以不要让它吓到你。就我所见，保留你出售给用户的每一个信息比依赖苹果方面更安全。

这里要注意的另一件重要事情是，应用内购买可能是伪造的，防止这种情况发生的唯一方法是验证购买的收据，请在此处查看。还要注意，使用 php 脚本要容易得多。如果您尝试发送检索到的收据并将其发送到用户设备进行验证，您将为此实现一个完整的类。

如果您有任何想法，请告诉我，以便我尝试详细说明。

于 2012-11-02T19:28:01.793 回答
0

因为您不想创建自己的服务器基础架构，所以用户在使用您的应用时不会获得最佳体验。暂时忘记不同类型的应用内购买。假设您在加密文件中跟踪用户可以在设备上生成的报告数量。假设文件位于NSApplicationSupportDirectory.

摘自 Apple Docs on Determining Where to Store Your App-Specific Files：

  • 您的应用程序为用户创建和管理的资源和数据文件。您可以使用此目录来存储应用程序状态信息、计算或下载的数据，甚至是您代表用户管理的用户创建的数据。
  • 自动保存文件。
  • 在 iOS 中，此目录的内容由 iTunes 备份。

因此，每次用户进行应用内购买时，您都会按金额增加计数。每当用户生成文档时，我都会减少它。有了 iCloud，这些信息就在用户拥有的所有设备上。

这就是可能发生不良用户体验的地方。假设我有一台设备，我购买了 5 个报告。我只使用了 2 个。假设我的设备存储空间不足，我想暂时删除您的应用程序。当我再次安装它时，我丢失了我拥有的 3 份信用报告。这就是为什么您需要一个服务器来跟踪/跟踪购买历史以及生成报告的时间。

于 2012-11-02T14:54:30.877 回答