So, now that we've confirmed that our refactoring works as we expected, the next step is to reintegrate 1
our app with UserDefaults so that we can try and persist 2
our item objects using UserDefaults. 3
So, now let's delete this line of code where we were using to debug previously, and let's reactivate our 4
defaults to try and retrieve our items out of our itemArray. 5
So before we do that, we have to make a few fixes, of course, because we're no longer retrieving an array 6
of strings, but we're retrieving an array of items. 7
Now, there's nothing to change here when we're adding items because, of course, self.default.set 8
can take any object, right? 9
Or at least theoretically. 10
So let's see what happens when we try to run our app. Now, I'm ready hinting at what's going to come. 11
But theoretically, at this point, we are creating a newItem using our class Item, we're setting its title 12
property. 13
The done property is set to false by default here. And then we're appending the item to itemArray, and 14
then we're setting into our UserDefaults using the key "TodoListArray." And then when our app loads up, 15
we use our UserDefaults to pull out an array. And if you remember, user defaults.array can be an 16
array of any type, at least theoretically. 17
And we're using the same key as we saved it and we're trying to pull it out as an array of items. 18
So if that succeeds, then we set our itemArray to equal items. 19
Let's go ahead and give our app a run and see what happens. So that's all working fine because we're 20
initializing new items inside viewDidLoad and we're appending them to this itemArray. 21
Now, the part that's interesting, because when we first press the add button and add a new item. 22
So let's press the add button and let's add a new item. 23
Now, once I hit add item, something dramatic happens 24
and, of course, you can see we've got signals SIGABRT which doesn't say anything at all. 25
But by now you should have seen it often enough 26
if you're coding along because this means that our app has crashed. And if we scroll to the top of our 27
debug console, as always, we'll find something that's trying to tell us why our app crashed. 28
And the reason that it's telling us is attempting to set a non-property-list object using UserDefaults. 29
So what does that mean? 30
Well, did you remember how I said that UserDefaults is a property list? 31
It has a whole bunch of key-value pairs. 32
So, for example, you could have a key which is "TodoListArray" and the value is an array of strings. 33
But in our case, we're trying to save an array of custom Item objects. 34
Remember, our itemArray is an array of our own Item objects. 35
and we're trying to save that into UserDefaults which it's rejecting, and it probably should reject, 36
because by the time that you're trying to save an array of your custom objects, then you're probably 37
misusing UserDefaults, 38
so this is the extent where we can get to with the UserDefaults. And we have to start considering a 39
slightly better solution than using UserDefaults to persist data which if you remember is only really 40
intended for small pieces of data, and it's massively inefficient because it has to load up the entire 41
plist before you can use or read any of the properties inside it. 42
So we have to abandon ship and stop using UserDefaults. 43
So I believe that it's always better to show rather than tell. And I can, of course, warn you don't use 44
UserDefaults. 45
It's not going to be very efficient and it's not going to work in lots of cases. 46
But I think it's better to show you when we actually try to implement it and reach its limits. 47
So remember, don't use UserDefaults for anything other than, basically, that right UserDefaults, 48
so volume on, volume off, volume high, volume low. these kind of small tidbits. For bigger pieces of data 49
and for saving data into databases, we've got better tools for them. 50
So in the next lesson, we're going to be learning about one of those tools which is NSCoder. 51
So I'll see you there.