Up till now, in order to persist data, we've essentially only been using single tables, right? 1
You think about how we save data using UserDefaults or using our plist and decodable protocol, 2
we were still saving things into a single table that had a key-value pair. 3
Now, this is equivalent to your tables inside Excel, for example. 4
So in order to explain the next step of persistent data storage solutions, let's use an example. 5
Let's say that you own a small bakery, 6
right? 7
And in order to keep track of your orders, your ingredients, your cost, you have to make a table, 8
right? 9
People would probably do this normally inside Excel. And inside the single table, you list all the things 10
that you can make, 11
so you just make cookies, brownies, and cakes. And you have columns where you can write down what are the 12
ingredients, what's the cost for each of these products, and how many orders you're getting, say, every 13
month or every week. 14
And this can be easily done using our plist or using our UserDefaults. 15
But what happens if you know, say, your cookies get featured on the Cookie Magazine, right? 16
And you end up being the Best Chewy Chocolate Chip Cookies in the world, 17
what are you going to do? 18
Well, then your sales are going to massively explode and people are going to be queuing around the block 19
to buy your cookies, right? 20
Now, I just want to take a moment and pause and reflect on the fact that it took me about half an hour to 21
find the perfect cookie image to illustrate the slide and given the fact that I've been trying to cut 22
all sugars in my diet for the last year, 23
I just want you to know how much of a sacrifice I've just made for you, guys, 24
looking at a million chocolate chip cookie images that I can have. 25
But anyways, let's continue. 26
So your business explodes and you now have loads and loads of orders, including big supermarkets and 27
big brands, and they all want to buy your cookies and all of your bakery goods. 28
So your single table inside Excel is not going to cut it anymore because you now need to keep track 29
of a lot more things. 30
So for your products, for example, you need to be able to track the ingredients, the cost, the shelf life 31
of each of them, 32
what are the nutrition details. 33
Because all of these big shops, they all want to know, right? 34
So you have to test that and you have to update the products table. 35
But in addition, you might want to keep track of your buyers, right? 36
Say Walmart, Tesco, and Whole Food, they're all regular buyers of your stuff, and now you need to know what 37
is their address, what are their phone number, what are their bank details, 38
who do you need to contact in order to invoice them, 39
whole bunch of details about your buyers. So you need another table. 40
And then in addition to your products' and your buyers' table, you also need to keep track of your orders, 41
right? 42
So, for example, this month Walmart wanted 2 batches of cookies, Tesco's wanted 12 batches, and Whole 43
Foods wanted 10 batches of your brownies. 44
So you need to match up the items from the Products' table to the buyers' table 45
in order to know who to invoice, who to send which details about which products, a whole bunch of data. 46
And you now have three tables and the tables are related to each other, 47
they have relationships, right? 48
They're not just single tables. Because when you have an order for two batches of cookies to Walmart, 49
you need to pull out data from the Products' table for the cookies and you need to pull out data from 50
the Buyers' table for Walmart. 51
So you now need to establish relationships between the tables. 52
And this is when you will need a database. And in the coming lessons, we're going to be talking about 53
two database solutions that are way more sophisticated than the single tables that we've been working 54
with using plist and UserDefaults, and they'll allow us to establish relationships between our tables 55
or between our classes so that we can perform far more complex tasks like querying our database to find 56
a particular item or linking two tables together using relationships. 57
Now, let's just quickly review some of the methods that we've come across to persistently store on data, 58
on the local device. 59
So the ones that we've seen and that we've used are user defaults and codable. 60
So the first section here, the ones in blue are essentially tables, the plist, all their individual tables 61
that tracks a small amount of data. 62
Now, the three solutions in yellow are databases or database solutions, and they allow for more complex 63
data and apps with more complex needs 64
in terms of data storage and data retrieval. 65
So let's go from the top. 66
So the first method that we saw and we used in order to persist our data, which is probably the easiest way 67
of doing it, is UserDefaults. 68
And this allows you to quickly persists small bits of data, things like, what is the top score of the user, 69
what does the player's chosen nickname, or whether if you want music on or off. 70
These are really small bits of data and that's what you should use UserDefaults for. Once you start 71
trying to put objects into UserDefaults, then you know that you're probably doing something a little 72
bit wrong. 73
Now, that's when we moved on to the Codable protocol which allows us to save many individual plist that 74
contain our custom objects. So you can see it almost as taking an ice cream and dehydrating and storing 75
it as astronaut ice-cream which taste terrible, by the way. 76
I don't know who came up with this. But it's a good analogy for the item saved with the Codable protocol. 77
You basically flash freezing your custom objects into a plist, and then when you use it, you have to 78
retrieve the entire plist or load the entire plist into memory before you can use any of the items or 79
objects contained within the plist. 80
So, again, it's memory intensive to load up an entire table when you only want one or two items inside 81
it. 82
And this is why the Codable protocol, saving your custom plist to file, again, should only be used for 83
small pieces of data. 84
So less than 100 kilobytes, for example. 85
Then we've got something that we haven't seen yet, 86
and it's called the Keychain. 87
And this is an API that allows us to save, again, small bits of data inside a table, but allows us to save 88
that securely, and Apple takes care of a lot of the heavy lifting of keeping the data that you put into 89
the Keychain secure. 90
So this is with things like, you know, usernames, passwords, things that you probably want to keep secure 91
for the user. 92
And then we crossed the threshold and we move into the database solutions. And the first one that comes 93
to mind is SQLite. 94
So pretty much all of your iPhone apps, their backend or the database that stores the data on the 95
device is mostly using SQLite. And SQLite has been around for a long time. 96
If you're familiar with relational databases like MySQL or SQL, then you are probably familiar 97
with SQLite. 98
It's meant to be a lightweight, easy-to-use relational database that will help you to persist large amounts 99
of data and it has efficient ways built in 100
in order for you to query data from it. 101
So, for example, when you're trying to sort a SQLite database, you don't have to load up your entire 102
database on your tiny iPhone, and then try to sort everything inside, 103
no, people have come up with really efficient solutions, so that it's quick and it's not so intensive on memory. 104
And if you're familiar, ready with the Querying Language and SQL databases, then this might potentially 105
be a solution that you want to use. 106
Now, the next one in the list is Core Data and this can use SQLite 107
as the database. 108
And whenever people talk about Core Data, you'll hear them hesitate to call it a database. 109
And the reason for that is because while you can use Core Data to work with a relational database, 110
it's so much more than that. It allows you to convert these individual tables inside your database into objects 111
that you can manipulate easily using code. 112
It gives you efficient methods to query the database using a more natural language. 113
It can also do a lot of things that you can't do with SQLite 114
For example, monitor for changes in the database and a whole lot more. 115
I could probably talk about Core Data by itself for 40 hours. 116
So we're only going to be looking at the most fundamental things that you can do with Core Data which 117
is basically create, read, update, and destroy. 118
And that's the base functionality that you'll need for pretty much any database you want to use, 119
and we're going to look into all of them. 120
Now, the last one in the list is something called Realm, and this is a open-source framework that is a much 121
faster and easier database solution than Core Data and it's fast becoming one of the most popular ways 122
of persisting data locally on device. 123
So we're going to be looking into that as well. 124
So when you're looking to save data from the user inside your apps and have it persist across, you know, 125
app updates or iOS updates, then you should consider maybe one of these six methods. 126
So if you want to persist just a tiny amount of information like a small key-value pair, then consider 127
something like UserDefaults. If you want to save a small amount of custom objects, 128
then think about using Codable and encoding your data into a plist. If you want a safe secure data 129
like user passwords, then use something like Keychain. 130
And if you have a large amount of data and you need to be able to query the data to pull out specific entries 131
inside, then you want to think about one of the database solutions. 132
If you already know about a SQLite or you already have data stored in a SQLite database, then you 133
might want to use SQLite with a wrapper. 134
If you're sending up your data from scratch, then Core Data might be a good solution. 135
There's a lot of help online for Core Data. A lot of people use it. 136
Most iOS developers are familiar with it. 137
And finally, if you want to be able to do, 138
I would say, most things that you can do with Core Data but faster, quicker, and have a more efficient database 139
solution, then you might think about something like Realm. 140
So let's get started looking at, firstly, Core Data, and then looking at Realm, and you can make your own 141
decisions when it comes to creating your own apps.