We're gonna start here by deleting the Master and DetailViewController files.

There's a lot going on in each of these files, and you'll probably get a better

understanding by starting with a lot less boilerplate in writing that code yourself.

So we move all of these to the trash.

Let's add a new file to the project.

And this time, we're going to select Cocoa Touch subclass or Class.

We want a subclass of UITableViewController.

And we're going to call this file, rather than the default TableViewController,

we'll call this ContactListController.

This controller is going to serve as the view controller for our master view.

So we'll hit next, and we'll add this to the project.

Now, one of the reasons we do this, instead of creating an empty swift file,

is because we get some boilerplate code by default.

Let's get rid of all of the commented code in here, so delete everything.

And might as well get rid of this.

There we go.

We need another controller for the detail view.

And here, we're going to add another TableViewController.

You'll see why later on.

We're going to call this one ContactDetailController.

And again, we'll delete all the commented code in here as well,

just to clear things up and make things less confusing.

We still need to make a couple more changes.

So head over to the main.storyboard file.

And in the Master scene shown here, we need to change this underline class to

contact list controller since we don't have that master detail or

master view controller file anymore.

So click on this,

click on the identity inspector and make sure you select ContactListController.

Let's also change this title to Contacts.

For the detail theme down here, right now, there's just a plain old view controller.

So click delete to get rid of it, and

then we're going to drag out from the Object Library, a Table View Controller.

Now, you might have to zoom out to make all this fit neatly, there we go.

Select the table view controller,

change the underline classic ContactDetailController.

Now, we also need to set this TableViewController as the root

view controller of this navigation controller.

And to do that, pretty simple,

right-click on the navcontroller, and you'll see a triggered segue.

It says, root view controller, and

just drag over from the outlet to the table view.

If you try and run the app now though, it will fail.

And this is because now that we've switched out the master and detailed view

controller, the Split View Controller doesn't know how to handle a new set.

These are brand new classes.

So you'll see here that we have an error, and

this error is located in the AppDelegate class.

When we first built our first iOS app, we talked about the AppDelegate for a bit.

The AppDelegate is the main point of interaction between the app and

the system, and other apps on your device.

The AppDelegate is the root object of our app.

Like the UIApplication object itself,

the AppDelegate here is the single routine object, and is always present at runtime.

This AppDelegate performs several roles and, oftentimes,

it can get bloated because of this.

In response to key changes in the state of your app, for example, if your app is

temporarily interrupted, or if there are changes in the execution state of your

app, such as when your app transitions from the foreground to the background.

It also responds to notifications originating from outside the app,

such as remote notifications, also known as push notifications,

low memory warnings, download complete notifications, and many more.

But the crucial bit for us is that the AppDelegate also contains the very first

bits of code run when an app is open.

Well, we didn't really have to switch out the Table View Controllers.

We could have used the Master in detail defaults.

This way, we actually have to figure out what's going on in the AppDelegate

in this new template.

What's different?

And all of these should hopefully broaden your understanding of the role of

this object place, and how your app is set up when it first launches.

So when the app is run and

it's done launching, the system calls application didFinishLaunchingWithOptions.

And we can override this method to add any customizations, post-launch.

Typically, this is where we set the viewController as the rootViewController

on an apps window.

Since this project uses a splitViewController, the code in here

sets up the splitViewController as the windows root controller, and

then customizes the navigationController embedded in the master view.

So all of this is the navigationController and

subsequent views that were set up in the storyboard file by default.

We have two navigation controllers embedded in a splitViewController.

One for the master view and one for detail.

And each of those navcontrollers contains our Table View Controllers.

So complicated but out of the box, the good thing is that this

app should also work on an iPad or on an iPhone 7+ in landscape.

Now, the last bit of code in here, the important bit,

is the line of code right before the returning statement.

That one right there, which sets up the AppDelegate as the delegate for

this splitViewController in this app.

Why does this matter?

Well, because using a splitViewController means understanding

how it handles presenting views.

What you're about to learn isn't necessary for understanding table views at all.

But this aspect, a split view controllers can drive you mad,

because you might think that your code is setting up the table view incorrectly.

When in reality,

the problem is with your understanding of how a splitViewController works.

Let's take a look at how a sample table view appears on regular displays,

then compact displays using a Split View Controller.

So, on the left, is how you would see the table view on an iPhone in portrait mode.

And on the right is an iPhone 7+ in Landscape.

On the Portrait View, the Split View Controller handles the primary and

secondary views, or the master detail interface, as we've come to expect.

If you tap on a row in the master, the Detail View Controller

is pushed onto the navigation stack on top of the master or the primary view.

In a landscape mode on the same phone,

the split view controller handles things differently.

The primary view controller or master is on the left side, and

the detail screen is also on the screen already, on the right.

If you tap something in the master list,

the detail view shows it right on the right side.

And all of this again happens out of the box which is super useful

because without having to write any additional logic,

we have a set up that works better on larger screens.

What happens though when you rotate that 7+ from landscape to portrait mode?

This is the interesting bit, and where it starts to get mildly complicated.

When you rotate from the expansive display in landscape

to the compact one in portrait,

the system first needs to pick a view controller to act as the primary view.

If you look at the storyboard scene we have set up, the only indication

that one view controller is acting as the primary is that detail segue.

The detail segue is enough information though, and the Split View Controller

figures out which one it should use as the primary controller.

Okay, so why does a choice of the primary controller even matter?

Well in a compact display mode, in portrait view,

the secondary view controller is pushed onto the primary controller.

And this behavior allows for the typical navigation hierarchy with the back button,

and the behavior of going back from detail to master.

So if, for example, the split view controller decided to pick the detail

view as the primary view, then the list would be pushed on top of the detail view.

And if we hit back, we would go to the detail view, not the other way around.

If we wanted to modify this behavior, we can implement the Primary View Controller

for collapsing method of UISplitViewControllerDelegate protocol

to explicitly state which controller acts as the primary.

But again, the split view controller knows how to do this out of the box.

It has enough information here.

But there's another aspect of this behavior that we need to handle.

So let's bring that portrait and landscape view side by side again.

Once the primary view controller has been chosen, the next step is the secondary

controller, the detail, that needs to be merged into the primary controller.

So again, by default, the Split View Controller does the right thing, and

merges the detail view on top of the master.

When it does this, so when you rotate from landscape to portrait,

the system displays the detail view on top, already pushed on top of the stack.

This is convenient because if you have something selected, when you rotate it,

you're still in the detail view.

So you're looking at the information that you want to see.

Except, what about when we haven't selected anything for the detail view?

If, for example, we're holding our plus iPhones in landscape

where we see the side by side display, and then we rotate it to

portrait without having selected an item from the master view.

Then, the split view controller is going to correctly

select the master view controller as the primary controller.

And it's going to merge the secondary view, or the detail with the primary

by pushing it onto the navigation stack and collapsing the whole thing.

As you can see in this case though, since we didn't select anything in the master

prior to rotating, the detail view's empty.

And the user now has to navigate back to the main view, select something, and

then get the detail view again.

In such an event, we can provide an implementation for

a second delegate method.

And if you scroll to the bottom of the app delegate,

you'll see this method right here.

And this is split view controller collapse secondary on to primary view controller.

In this method, the split view controller asks the delegate to

adjust the primary view controller.

And to incorporate the secondary view controller into the collapsed interface.

After this method returns,

the splitViewController removes the secondaryViewController from its

viewControllers array, leaving the primaryViewController as its only child.

Okay, so all that sounds complicated.

What does it mean?

Well, by using this method,

we can either choose to show the primaryViewController as the main view.

Or depending on the situation, we can choose to add the secondaryViewController

back to the stack to mimic the default behaving.

And we do this simply by returning true or false, because as you can see,

this method returns a Boolean value.

Returning false tells the splitViewController to use its default

behavior to try and

incorporate the secondaryViewController into the collapse interface.

Returning true, on the other hand,

tells the splitViewController not to apply any default behavior.

What it all comes down to is we return true in cases where we do not want

the secondaryViewController's content incorporated into the resulting interface.

What we'll do here is figure out if we have a contact to display first.

If we do, then we'll display the secondary controller on top of the primary,

otherwise, we're going to just display the primary, that list.

Now, luckily for us,

much of this code is already implemented because we used a template.

We just need to change a few details.

So first step here, this line of code,

we check to see that there is a secondary controller to work with.

Remember that when a view controller is embedded in a navigation stack,

the navigation controller is the main controller, for all respects and purposes.

So here, if we don't have a secondary view controller,

which we're checking to see that it's a nav controller.

Then we're just going to return false, which results in just the primary

controller being shown since we're resorting to default behavior, right?

At that point, only the primary controller exists, okay?

Well, what if we have a secondary controller, that navigation controller?

After that, we check to see that the navigation controller contains the correct

view controller that we want to act as the secondary controller.

Now, by default here, the template came with the detail view control subclass

which is what it's checking for.

We need to change this here since we removed that default.

We want to check if an instance of contactDetailController is available.

If it isn't, again, we're going to return false because that means that

we only want to show that primary controller the list of contacts.

This happens for the same reason, in that, without a secondary controller,

the default is to just show the primary.

For the last step, this is the important part,

we need to check if the contact detail controller actually has an instance

of a contact to show and isn't just an empty view controller.

So the code in here is checking some property called detailItem, and

making sure it's not nil.

Our secondary controller, ContactDetailController,

doesn't have a property named detailItem.

Instead, what we would need to check is if we have a contact

associated with the controller.

So let's go to that TableViewController subclass, and add a property.

We'll call this contact, and this is an optional contact.

You should know why this is an optional property, but

no big deal if you don't remember.

You'll always be initializing this TableViewController using init coders,

since we're using storyboards to build our layout.

Since we won't be able to assign an initial value to the contact store

property during initialization, we have to create an optional property and

assign nil to start off.

Okay, so now that we have this contact in this bit of code,

we'll check to see that the contact isn't nil.

If it is nil, then we're going to return true.

Returning through means the secondary controller is going to be discarded.

So in this case, if we rotate back and the secondary controllers contact properties

nil, then it's discard it and we see the master list.

If you run this app now using a seven plus simulator,

and you rotate the device, you'll see that we get the expected behavior.

All right, so here we have a 7 plus simulator and you can't see much because

it's blurred, but I'm going to go to hardware and rotate left.

And you'll see now that we have the master detail view side by side and

they're both table view controllers.

Now at this point, there's no information in the master to select so

obviously there's not going to be any information in the detail controller.

So if we rotate back, we would like to see the primary view

on top rather than the detail and that is the behavior we get.

Now, this was a large detour but we finally have our project properly set up

and you understand for the most part how a split view controller does things.

In the next video, let's get some data up on the screen.