Search code examples
iosswiftcore-datacloudkit

Why we need to use NSPersistentHistoryTransaction if NSFetchedResultController able to update UI correctly?

I still fail to understand, what is the problem NSPersistentHistoryTransaction is trying to solve, in the CoreDataCloudKitDemo WWDC 2019 "Using Core Data with CloudKit"

https://github.com/software123inc/CoreDataCloudKitDemo/blob/master/CoreDataCloudKitDemo/DataProvider/CoreDataStack.swift#L161

I want to see, what problem will occur, if processPersistentHistory is not executed.

By making the processPersistentHistory empty, I try to do the following testing.

  1. Run 2 simulators simultaneously in the same machine.
  2. Add an item to simulator A.
  3. Since, there is no way for simulator B to receive push notification, I press the home button for simulator B.
  4. In simulator B, I tap on the app icon to launch the app again.
  5. In simulator B, I can observe controllerDidChangeContent is being called. My guess is that, because the backed SQLite is seamlessly updated by CloudKit background task, NSFetchedResultController will be notified the SQLite DB change, and subsequently update the UI. Check the "Download CloudKit Changes into Core Data" of https://developer.apple.com/documentation/coredata/mirroring_a_core_data_store_with_cloudkit/syncing_a_core_data_store_with_cloudkit
  6. In simulator B, due to controllerDidChangeContent is being triggered correctly, I can observe the UI change perform by NSFetchResultController without issue.

Hence, I am not clear, on what problem processPersistentHistory is trying to solve in the demo code. May I know what kind of test case I can perform, to understand the problem solved by processPersistentHistory?

Based on "Integrate Store Changes Relevant to the Current View"

https://developer.apple.com/documentation/coredata/mirroring_a_core_data_store_with_cloudkit/syncing_a_core_data_store_with_cloudkit

Your app receives remote change notifications when the local store updates from CloudKit. However, it’s unnecessary to update your UI in response to every notification, because some changes may not be relevant to the current view.

Analyze the persistent history to determine whether the changes are relevant to the current view before consuming them in the user interface. Inspect the details of each transaction, such as the entity name, its updated properties, and the type of change, to decide whether to act.

For more information about persistent history tracking, see Consuming Relevant Store Changes.

This part is getting confusing. Our NSFetchedResultController is receiving relevant entity change event due to SQLite, and subsequently able to update the UI correct. If that is so, why do we still need persistent history?

Solution

  • You are right that NSFetchedResultsController are able to receive updates, and trigger updates to the UI.

    So the question becomes, in which UI of your app that you display data from CoreData, and do not use NSFetchedResultsController?

    For mine, it is a form editing an item, which I just pass one of item from the NSFetchedResultsController into it as a form member variable. This Form is not able to receive such updates.

    Looking at the CoreDataCloudKitDemo, there's also this DetailView, that is letting user edit a single post, and whenever this post is deleted from another device, having persistent history tracking (and query generation) allow it to "trap" this change and show a pop up before closing the edit form.