There are many different ways to leverage Core Data to get the best performance, and/or keep the code base simple and easy to maintain. This video provides an overview of some of the most used patterns for these architectures.
- [Voiceover] Okay, before we get any any further we really want to get into talking about Core Data Stacks. Seems like at all the companies I've been with that there's that one person who really, really knows the data layer really well, and then everyone else kind of knows what's going on but there's continual bugs coming from core data. And I think that comes from not understanding the different models that there are and where your app is in relation to those.
There's not a one-stack-fits-all solution. Each of these stacks have different strengths and weaknesses and it's really up to you to figure out which best fits your company's needs. So, as we look at this, there's the different objects that we've talked about before. There's queues, Main Queue or UI thread, that type of concept, as well as a Background Queue. There's a Persistent Store Coordinator, there's a Persistent Store, we merged changes and there's a relationship between parent contexts and child contexts.
You should be familiar with these as we go into this discussion. I've broken these slides down into two different pieces. A simple view of the stack on the left side and a variation of the stack on the right side. Stack number one is really simple, and that's perhaps its greatest strength. We have the Persistent Store Coordinator that does all of our messages to the database. We have our Main Context who writes directly to that store. And then any other background tasks are child contexts.
This is great because any saves to those Background Contexts bubble up to the Main Context, and then that context eventually writes to the Persistent Store Coordinator. What this means is you don't have to worry about merging. The model is very simple. On the right side we can see something similar to this, where we have these child contexts that write to the Main Context, and then that context ultimately writes through the coordinator to the store.
Again, all stacks have strengths and weaknesses. This one has a very simple process and that's its strength. But it's not very performant, especially when you have large writes from the database. That's why stack number two has been suggested, except that the writing context is not on the main thread. What we have here is still the coordinator, and the we have a buffer layer in between, a persisting layer. In this case on the left side it's called master context, on the right side it's called a persisting context.
Basically, that's on the background thread. Below it is a main context on the main thread. And then any child threads that are needed are created. What this effectively does is any saves from these lower contexts bubble up through the main context, which bubbles up again back onto a private thread, where any writes and reads to the database can happen without affecting the main queue. This is good for performance but it's not necessarily the best.
If you have a lot of data to write to the database, this can still be blocked at the coordinator layer. There are a couple of solutions for solving that particular problem. And that comes in with stack number three. On both sides of the slide there are similar pieces, but there's one difference here. On the left side we have one Persistent Store Coordinator, and on the right side we have two Store Coordinators. We'll talk about why, but first let's focus on just the basics of stack number three, in that the Main Context and the Background Context don't have children and they're both connected directly to the Store Coordinator.
This means that any delays from writes or reads will not happen at the context layer, but will happen at the Persistent Store Coordinator layer instead. It's important to note that with iOS 9 and below, the Persistent Store Coordinator has only one write or one read at a time. That's why the right side of this model is often favored. This means that you can import a large amount of data and have it write to the database on one type of coordinator, while your app behaves normally or performantly on the other type of coordinator.
They're really the same type of coordinators, but it's important to note that they're in parallel, which means you can have two writes or two reads at the same time, and the lock happens down at the data store level. But again, the drawback to this model is that it becomes very complex because you have to merge contexts as each of those write to the database. One of the great things about these stacks is that you can combine them so that they will fit your app for whatever your app's needs are.
What we have here is a combination between stack three and stack two. On the left side you can see that we have a Batch Worker Coordinator and a Batch Worker context, which will write any of the heavy writes to the database through that path. But most of the app can use the right side of this model, which is again model two. So, you have the best of all worlds, but the drawback to this again is even more complexity. None of these are correct and none of these are wrong.
The important thing to know is how these stacks can help your app perform, and also to understand where your app lies in all of this. There is not an exact stack layout, but these should be good guidelines to help you understand what type of stack your app has.
This course is meant for the enterprise developer who wants to get up to speed with the latest methods with Core Data. Instructor Jon Bott starts with a review of the basics, explaining the different architectural data models currently in use, the issues that can arise from these different models, and how the latest changes in Core Data 2016 simplify these models. He wraps up with hands-on migration to the new APIs and further tips on leveraging them in iOS 10 and macOS 10.12 apps.
- Fetching data
- Working with objects, queues, and threads
- Understanding the architectural models
- Managing local and server-side data
- Understanding iOS 10 and macOS 10.12 updates to Core Data
- Migrating to the new core data