The replacement of NSKeyedUnarchiver.unarchiveTopLevelObjectWithData(data)

Question

russ822 OP

Created Feb ’24

Replies 2

Boosts 0

Participants 3

I currently found out that the

NSKeyedUnarchiver.unarchiveTopLevelObjectWithData(data) as? NSMutableArray)

is depreciated and is recommended by the compiler to use

NSKeyedUnarchiver.unarchivedObject(ofClass: NSMutableArray.self, from: data)

instead. However, the NSKeyedUnarchiver.unarchivedObject always return nil.

Our original NSMutableArrary, named array, stores our objects, such as,

public class TestInfo { public var name1 = "" public var name2 = ""

....

}

those objects were set by using:

NSKeyedArchiver.archivedData(withRootObject: array, requiringSecureCoding: false) set(data, forKey: key)

We had tried several different methods such as:

NSKeyedUnarchiver.unarchivedObject(ofClass: NSMutableData.self, from: data)

but all failed with return value nil.

Is there better replacement of "unarchiveTopLevelObjectWithData" there to use?

Thanks

Boost

Answer 1

DTS Engineer OP

Apple

Feb ’24

It’s quite hard to read your post, so I’m going to point you at my response on this thread. Make sure to follow the link to this post.

If you can’t figure it out based on that, reply back here. In that case, check out tip 5 in Quinn’s Top Ten DevForums Tips, which has a bunch of suggestions on how to make your posts more readable.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

droleary OP

1d

I've been sitting on some deprecated unarchiving code for a while now and finally had the chance to debug it, so I'll do a slight ***** of this thread to add a little context to what the OP and other developers might be running into.

If you're archiving a deep structure containing collections, it appears that it is not enough to give a "full" set of classes to the root unarchiver, you must also give the classes that are needed as you init the hierarchy of objects (e.g., via decodeObjectOfClasses:forKey:).

For example, I have an array of servers (a custom class of mine), each of which has a main URL attribute as well as an attribute that's a subarray of multiple endpoint URLs. The (secure) unarchiver kept complaining about NSURL not being allowed, despite being in the initial set, until I changed the decode for that subarray, too.

Hope that's useful info. The documentation could be improved when it comes to all of this and, really, the API itself could be enhanced to do a better job at maintaining encapsulation instead of expecting the developers to know the guts of how every class gets encoded.

0