From the course: Complete Guide to SwiftUI

A dual key model

From the course: Complete Guide to SwiftUI

Start my 1-month free trial Buy for my team

A dual key model

“

- [Instructor] We've gone through most of the models we'll need, with one exception, and that's recipe steps, which has a few variations that you'll need to consider. Recipe step is a child bottle of recipe. So it is two keys to find a record. And if you go down here into the struct, you'll see this first one here is recipe ID. And that identifies the recipe as I have up here in my comment. And the second one is the row ID, which is right here. And that's the second half. And that gives a row for each one of the steps for the given recipe ID. So you'll need both to find each individual row, and we'll iterate over both of them when we put them out into the view. As they could be in the ingredient or an action, I have this one here called is action, 'cause I'm using it for both, for both ingredients and actions. And then the rest of this is the item code, which I am referencing. The ingredients, the quantity, and the action itself, which will also be a comment when I need it for an ingredient. Underneath that, I have something that I haven't done before and I have an ID that's a computed property. And this is a way of using recipe ID and row ID in a single ID. And what I did was I just multiplied by a thousand and then added the row ID. So I have a unique number for every single row in here. So I can access this in either way. And this comes in handy, particularly for searches and stuff where I can go straight to an ID instead of having to worry about recipe ID and row ID. And then again, we have another blank. And then under that, we've got our code. And you can see it works pretty much the same way with the exception that you now have to be a little more careful about where you are. So for example, we've got add row recipe step here, and you'll see here, next row ID has changed. Instead of just looking for a row ID, I've got to first look for everything that has a recipe ID, and then find the steps that have the maximum step on row ID. So I've got to do it a little differently 'cause I want to be watching the ID on the row ID to increase as I go through it. The recipe ID stays constant. Okay? And then I have another ad row where I can put all the information in as well, just like I did before. This one has a few extra pieces to it, as you can read here in the code. And that is to just do a little more error checking than I did before. I found that useful when I was doing these into the preloaded data that it needed this, so I made sure I didn't make a mistake. And then below that, I have remove row, which it says row ID. And here's one thing I didn't do in this code is, I didn't actually remove any rows. So I never tested this, which I'll find that it would be wrong. This shouldn't be row ID. This should be id. And so you may want to change that. And you can see in the code here for the first index, I actually used ID. So it's a good idea. You might want to make that change yourself. And this is something that happens with real programming is you're going to find lots and lots of little errors. And as much as I can clean this up, I'm going to find things as we go along. Then we've got a very important one here, is remove recipe steps. This is a good citizen thing because when I remove a recipe, I'm going to only be removing the header. I'll be removing things from the recipe's full class. I'm not going to be removing from the recipe steps. That leaves a whole bunch of orphan data that's just going to take up room for no reason. And we want to get rid of that. And that's what this removed recipe steps is for. Next we have an updated row, same as before. I have a couple of pieces here that I was doing when I was debugging, and we now have an insert method. This is different because we now have to worry about inserts for rows, unlike the others, which can just depend on the end. I have to put things in a correct order. And again, our order is not based on index. It's based on the row IDs and the recipe IDs. So I have to go through this very carefully, and that's why I got so much stuff here. And the big thing is that I have to stick things in the right place. And to do that, I have to move everything down on the IDs, and that's what this is for. So I find a certain ID, which is called the base row, and you can see that up here, and that base row becomes my point that I'm going to be using to set the location of my row. And then the row after that is going to be the new insertion. And so I find everything that's below base row and changes row ID to one more than it was before. So I have a space to put the insertion, and then I put the insertion in, here. Okay? Then we have a bunch of find methods, which I can either do by ID, or we have to find an index if I need it, or a step which is kept with the recipe ID and the row ID. All steps, and these come in handy when we're going to be doing our list, is we've got all steps, ingredient steps, and action steps. So I can do all the steps I want in one thing for a certain recipe, just the ingredient steps for the recipe and the action steps for the recipe. And then I also can check to see if I've got an existence of a row. I can check for duplicate records, which may come in handy. And so I've got a duplicate IDs and figured out which ones are duplicate IDs. And finally, I've got my recipe steps, and I've got a lot of them because you're going to see a lot of recipes. And you can see here, just for example here, you can see we're going to have one recipe and it's going to have several rows of data for the individual recipe steps. So all of that is there for that. This is what you'll need in the models. You should be able to use this code to make your SwiftUI application. This is definitely a lot of the difficult coding. So as I suggested, start here. However, if you want to start from scratch, you're certainly welcome to do so.

Contents