[MUSIC]

What we'd like to do next is to walk you through a case study of creating

a To Do List or a To Do List Manager or To Do Item Manager.

In doing this we hope that we will prepare you for a peer review assignment,

that's one of the things we're interested in.

We also want to give you a chance to synthesis

a lot of the different concepts that we've been using independently and

put them together into one moderately featured application.

We are going to do that,

we're going to put those features together and along the way we're also going to

discover that there are a few additional things that we're going to have to learn

about how the flow of an application works when you get it down end to end.

So, the concept that we want to work with is

from the big picture an application that looks like this.

It's going to have one primary view which has your to do list on it,

it will be a table view, it's going to be backed by core data.

Each element in the list is going to be representative of some task that

the user has to get done.

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.

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.

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.

All right, so let's go to Xcode and let's create our new project.

And, like I said,

it's going to be a single view application, we'll call it toDoManager.

And we will give it a organization identifier.

We use objective C, make sure we check use CoreData and hit next.

We'll have it build it for us in our standard repository.

Maximize our window and go to our story board and see where we start.

All right, we got that basic view controller and

we want to get rid of that because that's not how we're going to build it and

our story board is going to start with nothing.

So let's put what we want in there and

what we want in particular is a navigation controller.

That's going to be our standard point and this is going to come with a navigation

controller and it's going to come with a root view controller.

And then the last thing that we're going to want is we're going to want our

edit window, so we're going to have a basic view controller that's going to hold

our editing pane.

Let's see if we can make some space for it, all right.

Now our navigation controller is our initial view controller so we're going to

come over here and click this is the place where application can start.

And you can see over on the right we have all three of this things ready to go.

So that's our basic storyboard.

We have three elements that we're working with.

It was single view and now we've created kind of master detail show.

What I'd like to do now is I would like to create some sub classes so

that we can write code within these different storyboards.

So our first item here is a navigation controller.

I'm going to click on it, I'm going to come over here and see what type we have.

Right now you can see faintly that it says UI navigation controller.

So that's the class that we're going to subclass.

I come over here and we're going to create a new file.

And it's going to be a cocoa, nope it's going to be iOS source, cocoa touch class.

There we go.

And the class is going, we'll call it MyUINavigationController.

We use this pattern repeatedly.

All right, and when I do that it wants to change My UI navigation controller.

My UI navigation control, there we go, okay.

Objective c on the iPhone, great.

And create it in our project, over on the left we should see

it receives a header and receives it's implementation.

And then we want to go back to our storyboard, our main storyboard.

And we want to select our navigation controller.

And now we want to make our navigation controller be of the type we just created.

So now when we edit code for

that navigation controller we can come here and it will take effect.

So the next thing we've got is this root view controller scene.

And this is a table view.

The root view controller scene is a UI table view controller.

And that's the one that we want to subclass,

we want to subclass that whole controller.

So we look over here and we see that by default it is a UITableViewController, so

that's what we're going to subclass, UITableViewController.

So we're going to create a new file, a cocoa touch class.

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.

Come back to our storyboard.

Our view controller is of class UIViewController.

So that's what we're going to subclass for our third scene.

Create a new file, cocoa touch class

is going to be a UIViewController.

And we'll call it MyUIViewController, create it in our project,

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.

So the protocol which is the same as in.

A prototype is like a member variable.

Protocol is an interface.

So what we're going to do is we're going to use my initials DP

just a Convention within IOS.

And we're going to say that what we're going to be defining is something that

is a manager.

So something that receives the managed object context.

And well, that's kind of maybe a bad confusion of terms.

So we'll say DP,

we'll say handles, handles maybe.

Managed object context, all right?

So this is supposed to say that something that implements this can receive

a managed object context.

Good, hit next.

We'll generate that code and,

we have just a dot h file, because there's no implementation for this.

And what we need to do is,

we need to specify those functions that implement this, what is it that they do?

Well, they implement a function called receive manage object context,

which as it's parameter takes a NS managed

object context,

wow, called the incoming managed object context.

And what it does with it is it's going to keep a copy of it, so

that it can do core data work.

All right, so that's the first one that we created.

I want to create one more.

One more protocol.

We're going to call it DPHandlesToDoEntity.

This is going to be a protocol that a class can implement if it can hand,

if it can receive one of our two DoEntities,

which is going to be our basic entity in our core data class.

All right, straight forward, and basically this is going to

have the exact same signature except it's going to be receive to do entity.

And we'll say incoming to do entity.

And it is going to be a to do entity.

And this will give us an error because we haven't actually defined that thing yet.

It's not going to give us an error.

It should give us an error.

All right, we have two warnings.

Let's check those out.

What are our warnings?

Says scene is unreachable due to lack of entry points.

It does not have an identifier for run time access.

So presumably, oh, presumably that means that

this scene is not accessible, because there's no way to get to it.

We'll add that later.

And prototype table cells must have reuse identifiers.

So that means that we need to give this cell a name.

I'm going to select it up here.

This cell a name so that we can access it from within code.

So we're going to come over here to the reuse identifier.

And what we're going to do is we'll call it a We'll just call it a table cell.

We'll call it the table cell Identifier so that when we use it in code we can

remember where it was that we used this name.

Table cell identifier.

Okay, and that got rid of one of our warnings.

Now, we should be able to run this without any problem.

going to be probably the second most boring app in the world but

it should run okay.

Let's see if it does.

Bringing it up on an iPhone 6 plus, see it coming up in the background.

And there we go, we got a Root View Controller if I, I don't know if you can

see this on the recording, but I, you can see that there's a table view there and

there's no way to move around but it's working so far.

So that's our first Part 1.

We've initialized our Single View project with CoreData.

We created the basic storyboard.

We subclassed the View Controllers so that we could work with them.

And we created prototypes that will

help us to describe the architecture for passing variables between ViewControllers.

We'll pick up again in the next lecture with Part 2 of the Steps to make our

ToDoList manager.

Thanks. [MUSIC]

Case Study: To Do List Part 1

Best Practices for iOS User Interface Design

Meet the Instructors