我有一个带有今日小部件扩展程序的应用。我需要应用程序，小部件以及其他设备上的应用程序和小部件的其他实例共享数据，因此我正在使用iCloud Core Data集成。起初，我有一个app和widget（在一个设备中）在共享容器目录中共享相同的Core Data存储（sqlite）。现在我启用了iCloud同步，这在设备之间工作，但现在我在应用程序和同一设备上的小部件之间显示不一致的数据（？！？）。问题可能在于我的小部件GUI更新周期或通知中心订阅，我仍在进行故障排除，但我这样做：
当您使用Core Data + iCloud时，在同一设备上的应用程序和窗口小部件（或我认为的两个应用程序）之间共享Core Data数据的“正确”解决方案是什么？他们应该共用一个实体店，还是他们每个人都有自己的商店？如果两种方法都有效，是否存在问题？
答案 0 :(得分：3)
您应该考虑的第一个问题是，您是否真的需要与您的扩展共享整个Core Data商店。如果只是通过一个plist共享一些数据，它可以使事情变得更简单。
假设这不是一个选项，并且您确实需要整个商店，那么您有两个选择：
可以在两个单独的进程之间共享一个存储，但有一些陷阱。如果一个进程保存，则第二个进程中的任何NSManagedObjectContext都不会注册更改，这意味着数据将不会在UI中更新，并且还可能导致稍后的失败保存。
要解决此问题，您必须找到一种方法将已更改对象的对象ID从一个进程传递到另一个进程，以便接收进程可以刷新对象并重新获取最新数据。
第二种选择涉及两个独立的商店，以及一种转移方式。如果您使用iCloud + Core Data，iCloud是一种传输机制，鉴于您的进程都在同一设备上，这有点过分。
我相信Apple甚至警告不要在iOS上使用这个解决方案，因为如果一个iOS应用程序转到后台，它可能会在文件协调器锁定文件时停止，这可能导致死锁另一个过程。
iCloud + Core Data不是唯一的同步解决方案。在这种情况下，更好的解决方案可能是我开发的Ensembles框架。我说的原因是它可以选择通过本地文件进行同步，而不是需要云服务。您可以为扩展和主应用程序设置单独的存储，并让Ensembles使用共享容器来传输更改集。没有云参与，也没有文件协调问题。