In the last video, we created a FetchRequest.

All that's left to do now is to perform the FetchRequest and display the results.

The FetchRequest is performed, or executed, by the managed object context.

So in our TodoListController subclass, let's get a reference to that context and

assign it to the stored property, to a stored property rather.

So the top we'll say let managedObjectContext

equal CoreDataStack.managedObjectContext.

Now once we have the context, executing a fetch result is quite simple.

We'll use a throwing method to do this.

So inside viewDidLoad.

Actually before we do that, we need to import CoreData and

then back inside viewDidLoad, we can say, let request equal

Item.fetchRequest, because this is created as a static stored property.

So if we go back here,

you'll see that this is a class function rather than a stored property.

So, there's an annoying bug though here.

It's not really a bug, it's an issue that pops up where we have to specify the type

of the fetch request to get the compiler to understand which method we're calling.

So here we'll say NSFetchRequest, which is generic over item.

The reason we're doing this is since there's a similar method in the base

class, remember I said that there is already a fetch request method in the base

class, which is why we put this @nonobjc here.

And because there's that similar method,

the compiler is going to complain that just calling fetch request is ambiguous,

because it could be either one of those methods.

Since one of those methods returns a non-generic request,

if we specify the type of the constant as a generic one,

the compiler then knows which method we're trying to call.

Now, you could avoid this dance by getting rid of the generated method.

For example, back here we could just give this a different name, but

we'll stick to this just so that you know what this bug does.

Well it's not really a bug, but okay.

So let's use this request to execute a fetch.

The fetch method on the context is a throwing one again.

So we need to stick this code in a do catch.

So do let items equal try managedObjectContext.fetch.

And this takes a request, we'll pass in the request.

Now, if an error occurs that is propagated to a catch statement, so

in here we'll just say print error fetching item objects, and using

string interpolation, we'll just print the error's localized description string.

Okay.

The fetch method returns an array of item instances so

let's display these in the table view.

We'll start by adding a stored property to keep track of these items.

I will assign an empty array as the initial value, so we'll say var items is

or equals an empty array of item objects.

Let's also add a didSet observer, so that after initialization,

when a new value is assigned to this, we just automatically reload the table view.

So didSet, tableView.reloadData().

Now standard stuff, we've done all of this before.

Now, down here in viewDidLoad instead of assigning the results of the fetch request

to a local constant,

we'll assign the results of the fetch to the stored property.

So all we have to do is get rid of that let.

Okay, now that we have items in a stored property, let's provide implementations

for the table view's data source method to actually get these out on the screen.

So I'm gonna get rid of any unnecessary code here.

So number of sections in the table view return 1, and get rid of this comment.

Numbers of rows in sections, we'll say items.count and

then so for index path is commented out.

Let's get rid of all of this first, a bunch of stuff we don't need for now and

we're going to get rid of the comment markers.

And in here we'll grab a basic cell, so dequeueReusableCell with identifier.

We'll say ItemCell as the identifier.

And we'll need to go back to the story board and adjust that, so that we know

what cell we're looking for and then we also need to get an item object, so

we'll say let item = items[indexPath.row].

If you're unfamiliar with what I'm doing here,

you need to check our table views course.

So what I'm doing here is using the row property on the indexPath

to figure out which row we're on, and

using that as an index value to get an object out of the item's array.

Once we have that, we'll say cell.textLabel.text = item.text.

Okay, and return the cell.

Now, we specified an identifier here that is, as of now, undefined.

So let's duck back into main.storyboard and

we have a table view in here with a prototype cell.

So let's select that.

And in the attributes inspector, we'll set this as a basic cell and

then give it an identifier of ItemCell.

Okay, so this is the text table that we're assigning the items text property to.

Let's run the app.

And hey, look at that.

A single item should be displayed in the list.

This is the item I added earlier.

There is an issue, however.

So let's add another item to our list.

So I'll say, buy groceries, and save.

So we didn't crash, once we were done we hit save.

We know that the save worked because there's no errors, but

there aren't any updates to the list.

There's a problem in our current approach in that we have to always be listening for

when a user saves or dismisses that modal and then perform the fetch again and

then reload again.

That requires either the view controller knowing about what the other one is doing,

about what the modal view controller is doing.

And then we get into that coupling territory that we don't want.

Luckily, we don't have to do any of that.

In the next video, let's take a look at a fetched results controller and

understand how this object is perfect for the job at hand.