Migration to archiveObject about lockbox HOT 5 CLOSED

Specifically the code that is crashing went from:

if let myArray = Lockbox.arrayForKey("MyArray") as? [String] {

to:

if let myArray = Lockbox.unarchiveObjectForKey("MyArray") as? [String] {

The value was originally stored in the app in the previous version using:

Lockbox.setArray(myArray, forKey: "MyArray", accessibility: kSecAttrAccessibleAfterFirstUnlock)

from lockbox.

There is no automatic migration from the old setXxx methods to the new archive/unarchive methods. In fact, that would be nearly impossible as there is no way to know what you stored for any given key. I will update the README with some guidance.

To migrate, you would need to fetch your data using the now deprecated type-specific methods, and then store them again using the new archiveObjectForKey: method.

I can imagine that you might do this at launch, one time, for all your Lockbox data stored using the old methods. Then make a note by storing another key, either via Lockbox or in User Defaults or somewhere else, that you've done this migration in your app. So on subsequent launches, you wouldn't have to do the migration again. In fact, that would be redundant and probably mess up your data.

Sorry for the inconvenience.

from lockbox.

Is the benefit in moving to this just reduced complexity for new code? It seems like for existing apps it may be better to just continue with the older version, rather than adding migration code to our codebase for all time. But maybe I'm not fully understanding the benefits.

from lockbox.

The original implementation (all the type-specific setXxx methods) is limited, it turns out, if you want to store a complex object. For example, an array of strings can be stored and retrieved easily enough. But an array of arrays not so much; the retrieved array's contents were not arrays.

The new model stores opaque data from a keyed archive, relying on each core object to serialize and de-serialize itself on its way into and out of a keyed archive, respectively. So this allows you to store any complex object provided the object (and any contained objects) conform to NSSecureCoding. It is more robust, and removes the burden of worrying about data types from Lockbox.

from lockbox.

OK, great, thank you!

from lockbox.