Intermittent data loss with background fetch - could NSKeyedUnarchiver return nil from the documents directory?

问题

I have a simple app that stores an array of my custom type (instances of a class called Drug) using NSCoding in the app’s documents folder.

The loading and saving code is an extension to my main view controller, which always exists once it is loaded.

Initialisation of array:

var drugs = [Drug]()

This array is then appended with the result of the loadDrugs() method below.

func saveDrugs() {
    // Save to app container
    let isSuccessfulSave = NSKeyedArchiver.archiveRootObject(drugs, toFile: Drug.ArchiveURL.path)

    // Save to shared container (for iMessage, Spotlight, widget)
    let isSuccessfulSaveToSharedContainer = NSKeyedArchiver.archiveRootObject(drugs, toFile: Drug.SharedArchiveURL.path)
}

Here is the code for loading data.

func loadDrugs() -> [Drug]? {
    var appContainerDrugs = NSKeyedUnarchiver.unarchiveObject(withFile: Drug.ArchiveURL.path) as? [Drug]
    return appContainerDrugs
}

Data is also stored in iCloud using CloudKit and the app can respond to CK notifications to fetch changes from another device. Background fetch also triggers this same method.

// App Delegate
func application(_ application: UIApplication, performFetchWithCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void) {
    // Code to get reference to my main view controller
    // This will have called loadDrugs() to populate local array drugs of type [Drug]
    mainVC.getZoneChanges()
}

Finally, there is the getZoneChanges() method, which uses a stored CKServerChangeToken to get the changes from the private user database with CKFetchRecordZoneChangesOperation. The completion block calls saveDrugs().

The problem

All of this seems to work fine. However, sometimes all local data disappears between uses of the app, especially if it has not been used for some time. Deleting and reinstalling the app does pull the backed-up data from iCloud thankfully.

It seems to happen if the app has not been used for a while (presumably terminated by the system). Something has to have changed, so I presume it is the calling of a background fetch when the app is terminated that may be the problem. Everything works fine while debugging and when the app has been in foreground recently.

Possible causes

I’m guessing the problem is that I depend on background fetch (or receiving a CK notification) loading my main view controller in the background and then loading saved local data.

I have heard that UserDefaults does not work correctly in the background and there can be file security protections against accessing the documents directory in this context. If this is the case here, I could be loading an empty array (or rather initialising the array and not appending the data to it) and then saving it, overwriting existing data, all without the user knowing.

How can I circumvent this problem? Is there a way to check if the data is being loaded correctly? I tried making a conditional load with a fatal error if there is a problem, but this causes problems on the first run of the app as there is no data anyway!

Edit

The archive URLs are obtained dynamically as shown below. I just use a static method in my main data model class (Drug) to access them:

static let DocumentsDirectory = FileManager().urls(for: .documentDirectory, in: .userDomainMask).first!
static let ArchiveURL = DocumentsDirectory.appendingPathComponent("drugs")

回答1:

The most common cause of this kind of issue is being awakened in the background when the device is locked and protected data are encrypted.

As a starting point, you can check UIApplication.isProtectedDataAvailable to verify that protected data is available. You can also lower the protection levels of data you require to .completeUntilFirstUserAuthentication (the specifics of how to do that depends on the how you create your files).

As a rule, you should minimize reducing data protection levels on sensitive information, so it's often best to write to some other location while the device is locked, and then merge that once the device is unlocked.

回答2:

The problem is that you are storing the full path of the file and not just the fileName (or relative path). The document directory URL can change, and then if you stored that URL persistently you will not be pointing to the correct location of the file. Instead just store the filename and use NSFileManager URLsForDirectory to get the documents directly every time you need it.

来源：https://stackoverflow.com/questions/57758330/intermittent-data-loss-with-background-fetch-could-nskeyedunarchiver-return-ni

标签

ios

swift

background-process

nscoding

data-loss