3

我的应用程序最近被拒绝，因为它在将备份到 iCloud 的目录中安装了一个数据库。由于数据库带有大量预先填充的数据，并且应用程序将用户生成的数据存储到同一个文件中。因此，将用户生成的内容与预先填充的数据混合起来并不是 Apple 想要我们做的。到目前为止，一切都很好。

将我的数据库分成两部分，并使用 NSURLIsExcludedFromBackupKey = YES 使用预先填充的数据标记存储文件。

但是如果用户想要修改该存储中的数据会发生什么，因为他发现了一个失败并希望修改它。或者我自己提供了一个在线更新，它修改了该商店的值。我该如何应对。

我是否必须删除存储文件，创建一个新文件（现在使用 NSURLIsExcludedFromBackupKey = NO）或从一开始就将数据库存储在 /tmp 或 /Library/caches 下并将其移动到 /Application Support（自动备份）但是由于某种原因我的数据库被系统删除的威胁是 /Library/caches 的情况是什么？

4

2 回答 2

2

如果您的应用程序属于您可以实际更改应用程序中预填充数据的类型，Apple 将不允许您备份预填充数据，这有点烦人。如果预填充的数据库很大，我可以理解他们不希望您的应用程序将用户的 iCloud 空间浪费在 AppStore 中已有的信息上。

Woody 对这种方法有一个好主意，但我不确定 Apple 是否会忽略这样一个事实，即如果您在应用启动时将预填充的数据复制到用户备份的数据库，您实际上会浪费同样多的空间。

像这样的东西怎么样：

  • A：带有预填充数据的数据库，未备份
  • B：带有用户添加数据的数据库，已备份
  • 当用户对 A 中的对象进行更改时，在 B 中创建一个“覆盖”A 中的行的新行，例如通过使用相同的 ID 或在 DB 中有一个列来告诉应用程序应该替换 A 中的哪个对象通过 B 中的新行。

每当您需要更新您的应用程序时，您将用新内容替换 DB A，仅此而已。这可能会导致与用户更改的数据发生冲突。您必须决定用户数据是否比更新的数据更重要，以及如何处理这些冲突（例如，尝试同时保留它们）。

如果您需要在更新中更改 DB B 的结构，例如，如果您需要添加一列，则必须在您的应用程序中包含一个更新例程，该例程检测用户拥有旧的 DB 版本并编写代码更新后首次启动时将用户数据迁移到新数据库。

于 2012-06-27T08:33:53.757 回答
0

当您启动时，如果用户数据库未填充，您可以从预先填充的数据表中复制数据，并可能给用户一个选项来重置默认值，这又会如何？

于 2012-06-27T08:26:21.747 回答