You know what's up everyone mark right here at the slopes dot com and we've done some really cool stuff
in our apps so far we've gotten the user interface built.
We've got segues so you can go back and forth between screens.
We even now got a model built and re-actions tied to our league Visi and we don't let you go onto the
next screen unless you've selected an option which is really cool.
And then the data of course is stored in the player model.
It's a struct.
And so the next thing and possibly last thing we need to do here is actually pass data between View
controllers.
Now this is a topic that a lot of people struggle with and then they've done some really weird things
to get data talking between View controllers are going to make it really easy for you.
OK.
And the function that we're looking for here is already built in your view controller whenever you create
a new one and it's called prepare for Segway.
OK.
And when you read a function by the way.
OK.
When you get the actual function name.
All right.
It's going to look like this.
Prepare for Segway.
So this right here is the name of a parameter and this is the variable name that the parameter is going
to take on.
And so this this and this all kind of compose of the function definition of the function name.
And if you have other subsequent parameters those will also be added to the name of the function and
to show you what I mean.
So this is right here all nice ready for us.
But if I type in the word prepare OK.
Notice how it says prepare for Segway interface builder sender it's all right there boom OK.
So that's the function definition.
OK.
And it's an override function meaning the default view controller that you're inheriting from We'll
call this and we don't need to call super on this or anything like that because we're overwriting it.
Typically what that means is when you are writing and you don't call super.
It means that you don't need the view controller implementation of it you don't need that code to run.
Our code is going to take over from here.
Otherwise super would call that parent code.
OK so what we want to do is we want to see which side we were going to again remember what I said.
I said if you have multiple segues that can be triggered from a single controller you can need to check
which one is which.
And you might pass different data to different segues.
OK.
In our case we only have one so it makes it really nice but we're still going to have to write the same
code we would write if there were multiple segues.
And this is the code.
So if let And let's just say skill B C equals Segway destination as skewl B C.
All right.
Let me let me break it down.
OK.
So what we're saying here is we're doing it if let's sequence and went and flipped sequences.
OK.
Basically it will try and run an operation.
OK will try and run the statement in this case it's going to try and assign the destination view controller
into this variable or this constant.
The lead is a constant.
OK.
So it's going to try to do this if it succeeds it will execute inside the code block if it fails then
this statement will fail.
OK.
So if Segway that destination so were the failure could happen is right here.
As the as with the question mark is saying let's grab the Segway destination.
Well if you look at here at this destination by command click it destination is of type you view controller
so it's just a generic view controller.
But our destination that we want to go to is the skill of these you know skilled VC does inherit from
you a view controller.
And so with object oriented programming we can downcast a skill VC or rather a destination view controller
as a skill AVC because it does inherent.
But let's say stewe skill AVC did not inherit from you view controller it was just her own class then
this would fill but it won't in this case.
So what we're saying here is let's grab the destination that we're going to go to so it checks the Segway
for the destination view controller.
So the skill Visi in this case.
OK.
And then it's going to try and grab it.
So it's going to grab the view controller code that exists what's in our storyboard.
So this file right here OK it's going to load it in memory it's going to try and it's going to grab
it.
And of course it'll work because that's what's designed to work and it'll grab this code right here
and it's going to send it back to you and store it here in this variable.
OK.
And to prepare for Segway happens whenever a Segway is triggered this prepare function is going to be
called so it lets you do things before the Segway actually loads on the screen.
And this is where you will pass data between controllers.
So again what we're doing here is we're saying it's the skill we.
So if we can grab it successively then we're going to do something again and we had multiple controllers
that you could choose from let's say there was five different screens you might go to based on the selection.
Then what we would do is we would have like if let you know and then you know else if let And then we
would say you know other VC.
And then we would cast a different Visi and then it would go down until it finds the proper one.
And then we send the data.
OK.
So we're grabbing the next few controller we want to go to.
And if this is confusing to you it's OK.
You're just learning this takes time.
You're going to do this many times over and you can always watch this video again.
OK.
So grab the skill we see and what we want to do we want to pass data into it.
So what we're going to need to do is store a player variable in our schedule VC and we don't have one
yet so let's do that now.
So over here let's go ahead and say var player type player and let's do an pleasantly unwrapped optional.
What that means is no matter what we promise we promise that there's going to be code in there.
It's not going to be nil.
OK.
And so that's what we're promising.
And so what we're going to do is we're going to go over here and we are going to say skill Visi player
the one that we just created OK and not save the file.
Skill it up player there we go.
Now it's popping up.
OK.
So skill it up player equals player.
You're like what's going on here.
These names of the same.
Well we are referring to the player that we saved and this new controller here.
OK.
This is here in league visi.
We've set the player here and what we're doing is we are just passing this player from the screen onto
the player on the screen.
So literally this is where the handoff comes you know like footballs being handed off UK same exact
thing we're handing off the data from the player on the league.
And we're storing it in the player in the skill of the sea.
Now something really important to understand when you are in prepare for Segway this will always always
always always be called before you did load is called on the destination view controller.
So remember this very important prepare for Segway is always called before you did load on the destination
view controller.
So what you can do is you can always guarantee that data will be available in view to load if you initialized
it.
So if I was to do something like this player datt desired League.
OK if I was to do that it will not be Neal.
It can't be OK.
And it says expression implicitly coerced from string.
Now here in our player model it's because we have them as optionals And you know probably here we should
have these as implicitly unwrap the optionals as well too because we have to have data in order for
this to happen for this APTA run and this can be very confusing.
OK.
Do I make it optional do I make it implicitly unwrapped optional so remember this.
OK here is the rule.
If you can promise that data is going to be there I mean your app must have data in order to run.
Then you can make it an implicitly unwrapped optional.
If you don't know whether data is going to be there or not and that's part of your design.
OK.
It must be an optional.
OK so if you are promised data is going to be there because your app can't run without it you can assume
it's going to be there and make it implicitly unwrapped.
If there was no data in here and you tried to access it yes it would crash but you're promising that
there's going to be data there whereas the optional saying well might application design means that
there might not be data.
Maybe it's optional field who knows.
So that's the rule.
And again it could be confusing.
It takes lots of practice but you'll get it.
So this morning should go away and there we go.
And so what we're doing is we're going to print this here so let's just go ahead and run our app and
see if it actually prints as expected.
So what should happen is we're going to select the desired League.
OK.
We're going to go to the next screen and when the next screen loads we print it should show the desired
league that we selected.
Hypothetically if we wrote the code correctly
OK.
So get started.
Let's go ahead and select the women's league.
And when I click Next I should see women's printed here on the screen and sure enough it was.
OK.
So are you with me so far.
What happened was we triggered her segue.
So right here.
See this performs segue.
We triggered that from the next button right.
And we said let's load the skill AVC So this is called.
And then the very next thing that's called is prepare for segue.
And this is where we pass data from this view controller into the next using this code here and we set
the data that we need.
And it doesn't have to be in this very well we could call the function that sets it in a variable but
somehow some way we need to set data on the destination view controller then the destination view controller
which was the skill AVC in view to load our data is already ready to go.
And you could print it and use it accordingly.
So we've kind of just built the app right.
What we've done is we built an app that has three screens.
We've learned how to set data from some filt we selected a field we stored in a model and then we pass
that data model between View Controller so we can use it and you could continue to do this.
We could call another performed from Segway and another prepare and pass it on to the next one and pass
it on to the next one and then the next one.
Now if you're thinking that's a lot of work do we really want to pass data from view control of your
controller.
And I would say no later on you're going to learn how to work with some different design patterns like
the singleton pattern where you have a central source that holds all your data.
And that's a lot nicer than passing things through.
But this is a very common practice as well too.
And this is in the Apple documentation we've done everything exactly as Apple teaches in their documentation
and it's very useful So that's it for now.
This is really good stuff.
Core foundational things that you need to know everything that I've taught you on the swish app.
You have to know it now.
And if you ever want to get a job in industry you have to know everything we've done in this app by
heart.
OK.
There's nothing overly complex but the things that we have learned here you have to know by heart in
order to get a job if you don't if you don't know these things that are in this lesson you're not ready
for a job yet so you're going to need to master these very basic principles because this is what you're
going to doing most of the time in your app development.
So that's it for now.
Marc price at Dev slopes dot com.
Movin on and forward.