SQLite数据库的定期iCloud备份

Question

现在让我解决这个问题：是的，不使用Core Data几乎肯定是错误的。 但是，当我做出这些决定时，我是iOS开发的新手，我不知道我会像这样陷入困境。 此外，该应用程序也打算在Android（最终）上运行，因此我尽可能避免使用特定于平台的API。

我有一个iOS应用程序，可以将数据存储在本地SQLite数据库文件中。 存储在文件中的数据由用户提供，因此保持安全非常重要。 我有计划“稍后再做”，后来现在在这里。 我很快意识到它不会像我希望的那样直截了当......

我现在明白，无法跨设备无缝同步数据，我愿意接受这个限制，直到我设法迁移到Core Data。 但是，与此同时，我至少要定期备份SQLite数据库，这样用户可以在单个设备上使用该应用程序感到安全。 我以为我会这样做：

• 定期（例如每周一次）将SQLite文件从本地存储复制到云存储中，从而确保备份
• 当应用程序启动时，如果本地存储丢失或损坏但文件存在于云存储中，请询问用户是否要将其复制

这种方法的最大问题是用户可以在多个设备上运行应用程序，因此存储在iCloud中的数据可以来自这些设备中的任何一个，但只有一个。 为了解决这个问题，我想我可以在云存储中使用每个设备的唯一名称。 我会使用UIDevice.identifierForVendor生成它。

所以我的启动逻辑是：

1. 确定云文件的唯一名称。

2. 本地文件是丢失还是损坏，如果是，云文件是否存在？

   2.1。 询问用户是否要从云文件中恢复。 使它真正他们很难说不，因为这样做会失去他们的所有数据。

   2.2。 如果他们说是，请将云文件复制到本地文件存储。

3. 打开本地数据库文件。

在后台运行我偶尔会将数据库文件从本地复制到云存储。

在我进行核心数据集成之前，我想知道这是否是一种合理的方法。 还有，我可能会遗漏任何隐藏的“陷阱”吗？

更新：正如@TomHarrington在评论中指出的那样，事实证明我的数据库文件已经位于/Documents ，后者备份到iTunes和任何iCloud帐户。 所以我的问题变成了这样：

我是否应该简单地确保我的数据库具有特定于设备的名称，以便在连接到同一iCloud帐户的另一台设备上运行的应用程序不会破坏它？

Answer 1

我要回答我的问题，因为我最终走上了这条道路并找到了一个巨大的拦截器。 UIDevice.identifierForVendor API中存在一个错误，导致每次安装新版本的应用程序时都会重新生成错误！ 看到这里 。 这当然排除了将其用作设备标识符。 叹

我认为我采用这种方法是SOL。 相反，我可能会在第一次执行时生成GUID并将其用作我的标识符。 问题是，我需要存储那些没有备份到iCloud的地方。

呃，我可能只是放弃这里说我的应用程序无法在多个设备上运行，直到Core Data集成完成。

更新 ：我最初在第一次运行时生成一个标识符并将其存储在钥匙串中（仅作为本地条目，因此它不会备份到iCloud）。