这篇博客文章将引导您阅读一系列关于开发人员尝试这种方法的艰辛的文章.
根据我自己的理解和经验,我认为这是可行的,但不要接受你会"免费"得到任何东西的想法.根据您的数据模型,您可能最好将整个持久性存储同步为文档,而不是使用记录的核心数据/ iCloud方法.
如果您已经熟悉Core Data,那么您可能会有更好的运气.请务必考虑如何处理几个重要案例.
一个是如果用户退出他们的iCloud帐户该怎么办.发生这种情况时,将删除本地无处不在的持久存储.如果用户仍然可以访问其数据,则需要在本地存储中管理副本,然后在重新登录时管理重新同步.
另一个原因是默认情况下传播的变化显然很慢,因此您可能需要考虑一种替代机制,例如键值存储,以快速传播足够的信息以避免糟糕的用户体验.
冲突管理可能是最具挑战性的(取决于您的模型).虽然框架提供了一种通知您冲突的机制,但您可以自行提供解决冲突的机制,并且有报告称冲突通知可能不可靠(请参阅链接文章),这似乎与延迟密切相关在更新.
简而言之,如果你进入这种理解,实际的支持是非常简单的,并且你需要非常防御性地编码,你可能有机会.那里没有任何好的食谱,所以如果你确实有效,请回来告诉我们什么有效!
这取决于你想做什么。Core Data-iCloud 集成有两种类型,如下所述:http://developer.apple.com/library/ios/#releasenotes/DataManagement/RN-iCloudCoreData/_index.html
一般来说,与 iCloud 集成的基于核心数据的应用程序有两种类型:
库式应用程序,其中应用程序通常具有单个持久存储,并且存储中的数据在整个应用程序中使用。这种应用程序风格的例子是音乐和照片。
基于文档的应用程序,其中不同的文档可以在应用程序的生命周期内的不同时间打开。这种应用程序风格的示例是 Keynote 和 Numbers。
如果您使用的是库类型,本文是系列文章中的第一篇,该系列文章讨论了将出现的许多问题:http://mentalfaculty.tumblr.com/post/23163747823/under-the-sheets -with-icloud-and-core-data-the-basics。
您还可以查看今年 wwdc 的第 218 场会议(基于文档的会议)或第 227 场会议(基于图书馆的会议)。
| 归档时间: |
|
| 查看次数: |
7061 次 |
| 最近记录: |