1:10
In the example, we're going to use a title for the task and
then we're going to have a date for the task as well.
So the title going to be on the left, date will be on the right, there'll be a second
view, which is a detail view which we handle by a navigation view controller.
And that detail view will be the opportunity for
the user to edit the details of, well, not just the details,
but edit all of the items of the ToDo, the title and the due date.
And from there, we're going to make this work so that If you want to delete
one of the to do's you go to the edit panel and you hit the trash can button.
And that will send you back to the initial to do list and it will be deleted.
If you want to edit a to do rather than hitting the plus sign on the To Do List,
you'll hit the item itself and it will to the edit page as well,
and you'll be able to edit the content that's there.
There's a lot of little details we need to get right in this, but
this is the basic idea of what we want to do, and
in the To Do List it's going to be sorted and it's going to be backed by core data.
So that's the big picture,
we've got about six steps that we need to walk through in this.
We'll probably break it up into six lectures but
we'll see how it goes here as we flow.
And we'll introduce a few new things along the way, all in preparation for
getting your peer review assignment ready.
So in terms of the way that we're going about doing this is that we're actually
going to do a lot of the heavy lifting ourselves in this application.
And by that I mean that, we could ask Xcode to do a lot of it,
there's a template that's built into Xcode called the Master-Detail View, now it's
really nice because it uses a split-view controller that gives you the option of,
when you're on a large screen, showing basically you're to-dos on one side and
then your editing panel on the same side both on the same screen when you have
a lot of screen real estate.
And it naturally builds the structures that when you rotate the device or
you're in a view that doesn't have much horizontal space,
it goes back to having the to-do list on one view, and
then going to detail pane that takes up the entire screen on another view.
That comes from the template, and so
the problem with that is that you could look at that code and
unless you built it yourself at some point, it's really hard to understand
what are all the moving pieces that are involved in that templated code.
So, unless we're able to do it on our own, it's going to be very difficult to
understand what the template is doing, and if you ever want to customize that
behavior, it's even more difficult to figure out how to go about doing that.
So, we're going to build it from the ground up using a little bit of support
from Xcode, but not the full blown template.
And while what we are doing is better for learning,
I mean clearly it's not going to be as fast as what you could do as if you just
dropped in the template at the out go but this is a learning environment and
we're not worried in getting the app done as fast as possible yet.
And so we're going to go do the heavy lifting, we're going to learn it.
And this will give us better foundation for editing the template in the future.
All right, so without further ado,
what we're going to do is address some challenges.
So one of the challenges that we encounter is when we're using core data
we know that we have this ManagedObjectContext that moves around.
This is our scratchpad where we create new items and we edit them.
And then periodically we'll save and we'll need the ManagedObjectContext in order to
save those items, those entities to our persistent storage on our device.
And moving that variable or
a reference to that variable around in our application is a little tricky because
remember, it gets created in our AppDelegate method, our AppDelegate File.
And that's where it lives, and so we have to pass it to our view controllers, and
there is not a real natural way of doing that.
And so the we we're going to do it is one of three ways,
now the three ways that you could handle this are as follows.
So the first one is you could handle all of the code that needs to be
executed In the AppDelegate file itself, in principle anyway.
You could have all of the table view populated,
you can have all of the fetched results handlers,
they can all be coming from a singles class, that's one way to do it.
Now it's messy and it's poor architecture is putting all of your functionality and
all of your concerns into one place.
And it becomes hard to edit the code, and it's just your separation of concerns is
poor, and in larger projects it would end up being a problem.
A second option would be to create a singleton class.
So this would be to create a brand new class using Xcode, creating a file.
And in that class you would treat it as a singleton,
meaning that whenever you wanted access to that class rather than
instantiating that class, you would call a static method called get singleton.
That would return the one instance of that
class that exists within the entire scope of your program.
And in that one instance of the class you would put
any variables that you wanted to be able to access from anywhere in your app.
So basically it's kind of a container for global variables.
So what you could do is you could take your ManagedObjectContext and
from your AppDelegate you could set it in this global class.
And any time you needed to get that ManagedObjectContext,
you could get the singleton, and you could retrieve the ManagedObjectContext.
Now that's very fast, and it's probably the most practical thing to do,
it's not very future proof.
There are some instances where you may have multiple ManagedObjectContext moving
around, something we're not going to cover in this specialization.
6:33
And Sam and I were discussing the way we wanted to teach this,
we were on the borderline about whether we should use a singleton class as it
was kind of the most practical and yet maybe not the best thing.
So in the end, at the end of the day,
we decided to go with a good architectural model which not the singleton class.
It's what we're going to do instead,
which is we're going to pass the ManagedObjectContext around through our
ViewControllers whenever they're needed so that the ViewController gets it's
ManagedObjectContext when it gets instantiated or when it gets rendered.
And this is sort of the ideal way to do it.
It's going to take a little bit more work, but it's the best architecture and it's
the most future-proof if you ever wanted to have multiple ManagedObjectContext.
All right, the last challenge that we're going to address is that we're going
to drop in a bunch of ViewControllers that are just from an object library.
And we're going to need to implement some of that code in order to pass
the ManagedObjectContext around.
Unless we do something we're not going to have any code,
any place that we can write code because these things are built in
some of these classes, this ViewController classes are built in to xcode.
So we're going to sub class some of those ViewControllers that are built into xcode.
Now this isn't hard and it's not particular rocket science but it's new for
us, we haven't really done that yet.
So we're going to see examples of that In this case study, and
then last thing that we going to do that's a little bit different
is we're going to do something where we dynamically save our
entities Whenever the user edits any field of the entity.
So for example, if they're on that edit pane and they change the due date,
as soon as they're done setting the due date we're going to update it even if
they're still going to be making other changes on that edit pane.
And the rationale for this that Sam really recommended is that because at any
point your app can be killed, it's nice to have to most current edits
that are available that the user had made stored in persistence storage.
And so that's what we're going to do, whenever the user makes an edit,
we're going to store it in persistence storage.
Not just when they're done with their added pane.
So that's an example of a best practice that we are going to show you.
8:43
All right, so step one and we have about six parts to this and
we'll tackle them in subsequent videos.
So step one we're going to do here.
We're going to initialize a Single View project with CoreData,
then we're going to ditch the Single View that it gives us.
We are going to create the basic storyboard, however.
And we're going to subclass the ViewControllers that we need.
That's going to create sort of a skeleton space for us to work from, and then we're
going to create prototypes for passing variables between the view controllers.
So, this is for managing the managed object contexts.
Prototypes is not something that we have written before, but
this is something that we've used before.
These prototypes are another word for interfaces.
So whenever we wanted to decide
a signature that a class needs to implement, we can say,
oh, let's create a prototype that shows the interface that a class must implement.
And that's the way that we can just communicate in our architecture and
in our design what is important for
a class to be supporting, for class to implement as we move it around and
you'll see how this works a little bit as we get going.
So lets do this, initialize a single view project with CoreData,
create a storyboard, subclass ViewControllers and make a product.
So we're going to make two prototypes.
13:34
Next, and we will call it, oops.
Let me select everything, MyUITable.
Actually, it's going to override it, so I'm going to come here.
UITableViewController, great.
And we'll call it MyUITableViewController.
Good, create it in our project and
then go back to where there's code for it, the template code, go back to it select
the view controller and then make sure it is using our code for that, all right.
And just for completeness, we're going to come to our last one,
which is our view controller.
We're going to select our view controller, and
we see here that it is a UIViewController by default.
Now, over here, on our project,
we have the view control that was created when we initially made our template, so
let's just go ahead and delete those so those don't confuse us later.
We're going to move them to the trash.
14:57
go back to our storyboard, and for some reason it put it up there.
So we're just going to move it down here and because I'm that way,
we're going to move these down so it's alphabetical, because that's how I roll.
All right, and then finally, in our main story
board we need to make sure that our view controller is using that class.
My UI View Controller, great, so we've laid out our story board,
we've sub classed each of those view controllers.
Primarily the reason I'm worried about that is so that we can write the code that
moves the view context along this sequence,
when we want to implement the core data functionality.
All right the last thing we said we want to do is implement two different
prototypes.
So prototype is the equivalent of an interface in another language and
it is set, it gives specifications for functions that a class must.
If it uses that prototype,
it must implement the appropriate functions associated with it.
So to do this, we're going to create a new file,
when you do this a little bit differently, you go to other.
Oh no, I'm sorry, you go to source.
And you do an objective c file.
And then you do next, and then you have the option of choosing a protocol.
I've been saying prototype.
Sorry. What we're creating is a protocol,
not a prototype.