iOS 10 NSKeyedUnarchiver Error

[davidmdavis]

Hi,

I am having a strange issue with my app when running on iOS 10. I'm using version 1.10.4 of this library.

Here's the scenario:

[CDAClient initialSynchronizationWithSuccess...] {
    [space writeToFile:@"path"];
}

[CDASyncedSpace readFromFile:@"path" client:client];

The sync and write are working fine, and I can see the space saved on the file system. When I try to read the space from the file, the space is nil. I stepped through the code and the following exception is being caught on line 204 in the CDAReadItemFromFileURL method in CDAUtilities.m.

NSException * name: @"NSUnknownKeyException" - reason: @"[<CDASpace 0x7bb6bbe0> setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key _px_reuseIdentifier."

The thing that makes this more interesting is that if I kill the app and restart, I am able to successfully read the file from the file system as normal (without re-syncing).

This is only happening on iOS 10. Any ideas?

[phoumano]

David I am having this same issue. Did Contentful ever commit a fix? If not did your temporary fix in CDAUtilities work pretty well?

[davidmdavis]

They did not commit a fix as far as I know. I haven't had time to test the latest versions that have been released, however. We have been using the temporary fix I committed since October 2016 with no issues.

[loudmouth]

Hi @davidmdavis and @phoumano . Apologies for the delay in getting to this issue. I will start looking into a fix today. Just to let you know, the next release will be with AF-Networking 3 support and drop iOS 7 support—this has already been merged into master, so when I push a fix for this issue it will be without iOS 7 support and NSURLConnection api

[loudmouth]

I must admit that I have no idea where the _px_reuseIdentifier key is coming from.

@davidmdavis would you be willing to submit a PR with your fix?

[loudmouth]

Indeed it looks like _px_reuseIdentifier is a new addition to the Objective-C runtime in iOS 10.

The SDK has some logic to determine all the property names of a class before encoding it, and choose which of those properties to ignore. The previous maintainer of the project left no comments as to why this is done, but for fear of breaking the SDK. My best guess was that it was an effort to make a universal code path for encodeWithCoder and decodeWithCoder. However, it is clear that changes to the Objective-C runtime can easily break this, and that simply implementing the two NSCoding methods would be a better course of action.

[loudmouth]

@davidmdavis @phoumano would you be able to give branch bugfix/Issue-64-NSKeyedArchiver-exception a try? See #69

[phoumano]

So if I am reading this correctly pulling this branch will require AFNetworking 3.0+?

[loudmouth]

@phoumano yes that is correct—it is a sub-dependency so it will be resolved automatically by cocoapods rather than requiring you to manually pull.

If you are not ready to migrate to AFNetworking 3, I suggest using the patch @davidmdavis made. It will certainly fix the issue for now, but it will not prevent a similar issue from arising when Apple makes future changes to the Objective-C runtime, for instance, when iOS 11 comes out.

[loudmouth]

v2.0.0 has been released.