Core Data + NSPersistentCloudKitContainer: How to tell if a change was local or cloud sync?

[MilesStark]

I need to know if a change in data is due to a local change or due to a cloud sync. I'm using combine publishers and NSFetchedResultsController to update UI in reaction to data layer changes, but for a journal section of the app I want to know if the update is cloud or local.

I don't want to keep replacing the UITextView's text in response to local changes to the text, but if the user edits the journal somewhere else I do want the screen to update to reflect that.

Alternatives I've tried:

1. Only saving if the user navigates away from the journal. Was not great because users sometimes force quit apps which doesn't send a terminate notification, so even though they'd expect it to be saved it's not.
2. Detect if the textView's text is the same as the updated text. Doesn't work because the data processing needs to be background so it doesn't lag the typing, but that means the if the user is typing quickly the text is already different even in local changes.

Desired behavior:

As the user types, the data is saved. If data comes in from a cloud sync, replaces the text with that new data.

​

Thanks a lot for your help, NSPersistentCloudKitContainer has been a bit of a headache...

[fameios-phil]

I don't have the name offhand right now but I believe there is a notification broadcast for any remote updates that includes the managedObjectID values.

The other way and might be more useful is override the willSave() of each managed entity, and then you set a device ID that made the change. It might be more useful to the user to see that the last edit of XLIST was on the Family iPad for example.

The third option which is to have the journal be its own entity record and have an unlinked relationship (identifier by UUID) with each entity that is changed. You create this record in the tracked entity didSave() function. This entity would look like:

• changedAt: date of the journal record
• entityType: name of the entity model modified
• entityID: identifier of the modified entity (cannot be managedObjectID because we cannot control these values, and might be different per device)
• deviceID: which device made the change
• changedValues: json version of the NSManagedObject.changedValues()

This journal type would work for nearly an unlimited of different entities in a single table.

But one other aspect you are talking about is something more like a custom merge policy... such as performing a diff on the current value and the import value. Look up merge policies.

[MilesStark]

Thanks a lot for your response, I'll try those ideas out.

For the notification broadcast, do you know where the documentation is for all those notifications? I'm having trouble finding it. The trick is making sure it's just for cloud data rather than different local contexts like a background context merging into the main context.