The example given in the last chapter saying that “Cancelling and Removing an Core Data Object can be difficult”.
But for most people, I guess the natural logic would be:
Instead of creating a core data object right after user opens the detailViewController, use some temp holder for content and changes the user made and create the core data object right after the user click “Save”, and transfer what in the temp holders into the object. If they click “Cancel”, then you don’t even need to create that core data object in the first place.
Maybe not for a simple application but for more complex applications where the user might want to make some changes and not commit them to the psc yet, but hold on to them as they use other parts of the application.
@den330. Thanks very much for your question, and my apologies for the delayed response.
The advantage of using a child context is to allow the app to run a task on the background thread while the user continues to work on the app uninterrupted. One project I worked on where I had to use a child context was that I ran a purge method which deleted any older data on the app which had already been synced with the cloud while the user was working on the app. Because this functionality happened in the background, the user was still able to enter and store data they were inputting without realizing that Core Data was running in the background deleting older data that was taking up unnecessary space on the device. Typically, a child context would be used for complex tasks, especially those that involved multiple tasks which needed to be done concurrently.
@den330 You end up basically having double the variables for everything. Your core data model already defines everything you need, and then you create another whole set of those variables local to the view controller. It’s much easier (personal opinion of course!) to just directly set the value on your managed object and then either toss it at the end or save it.
This is actually incorrect. You are not duplicating the data model, nor any of the entities it contains. A child context allows you to perform additional tasks on another thread simultaneously with the parent managed object context.
@syedfa I’m answering his question as to why you do it the way you suggested. If you do NOT use a child context, then you have to create duplicate variables. Instead of just editing myObject.name there has to be a ‘name’ variable in the view controller, and then when it’s done write ‘myObject.name = name’
If you use the child context, then you don’t have to create that extra set of variables in the view controller.
