Hey, guys. 1
So we've been talking a lot about the viewDidLoad or viewWillAppear, or viewDidDisappear which 2
are some of the methods that you saw only just in the last lesson, but we haven't really learned much 3
about these. 4
So in this lesson, I want to talk about the lifecycle methods of a ViewController. And just as we humans 5
are born and we eventually die, 6
so do ViewControllers. And they have a lifecycle with certain key moments that we can tap into and 7
we can write code to specify what should happen in those moments. 8
The first thing that happens is the view gets loaded up. 9
So in this case, all of the IBOutlets, IBActions, all of the view related objects gets connected up 10
and is now accessible. 11
Now, it's really important to note that the viewDidLoad method is only called once when the view is 12
created, whereas the next method that we'll see in the lifecycle can get called many times. 13
So after the view has been loaded up, then the next thing that the operating system will call is 14
viewWillAppear, and this is called just before the view actually shows up on the screen. 15
So the user is not yet able to see anything, but it is, however, a good time point for us to be able to 16
hide or show certain UI components like what we did in our FlashChat app when we hid the navigation 17
bar because the user is not yet able to detect any changes in the view, and it's only when the next step 18
gets called which is viewDidAppear, 19
are they able to actually see things on the screen. 20
And at this point, if you tap into this method, then the view is already on screen and the user is already 21
able to see the ViewController. 22
So this is a good time point to, for example, start a countdown timer if you were going to do that on 23
the screen or start an animation, 24
anything that the user can detect, basically. Now after viewDidAppear, 25
the user might do something to trigger the next method which is viewWillDisappear. 26
Say, for example, if they navigate it back or if they somehow dismissed this current ViewController, then 27
this is the first method that's going to be called to allow you to write some code to prepare for this 28
event. 29
So, for example, you probably want to stop your animations and you might want to change the appearance 30
of UI, 31
say, for example, like when we hid our navigation bar. 32
Now, the step after viewWillDisappear is, of course, viewDidDisappear, 33
and at this point, the view is already off the screen 34
and this is, basically, the last moment where we get to change anything about that previous view before 35
it disappears off the screen. 36
Now, just because the view has disappeared, it doesn't mean that it has been deallocated or has been 37
deleted from the memory of the phone. And in fact, as you'll see in the next demonstration viewDidDisappear, 38
literally, just means that the user can't see it. 39
It doesn't say anything about whether if the ViewController is going to be destroyed or if it's just 40
going to be kept in the background in the navigation stack. 41
So I've created a really simple example where I've added all of these possible methods that we can override 42
from viewDidLoad to viewDidDisappear, and I've added a print statement in each of them to show you 43
when they get called. 44
And I've linked up a second ViewController which basically has the same code all of those lifecycle 45
methods. 46
But instead, it says, "VC2 viewDidLoadCalled." 47
So this allows us to have a realtime view as to which of these methods are being called when. 48
Now, if we take a quick look at the Main.storyboard, you can see that it's a really simple interface, 49
it's just got two ViewControllers: 50
ViewController1 and ViewController2. 51
And the first one has a button which has a segue that navigates the second one. 52
And on the second screen, I've got Back button, which then calls the dismiss method which allows us 53
to go back to ViewController1, and it will destroy and dismiss this second ViewController. 54
So let's go ahead and run our app and see what's being called when. 55
Now, let me just go ahead and expand this area, so you can see the order of things. 56
The first thing that happens is on VC1, viewDidLoad gets called, and then viewWillAppear, and 57
then viewDidAppear. 58
Now, it's going to hold still until the user performs some sort of action. 59
So for example, I might click on the next button which is going to take me to the second ViewController. 60
Now, in this case, the ViewController2 gets loaded up, and then viewWillAppear, and viewDidAppear 61
gets called. 62
And finally, when I click on back, what will happen is that the viewWillDisappear and viewDidDisappear 63
will get called from the second ViewController. 64
Now, you might be wondering, well, why is viewDidDisappear or viewWillDisappear not being called from 65
VC1? 66
Well, it's because when we navigate over, the segue is set up in such a way that our ViewControllers are 67
displayed like cards one on top of each other. 68
So, in fact, that previous ViewController hasn't really disappeared, 69
right? 70
And all it's doing is just hiding there in the background and it hasn't fully disappeared. 71
Now, you'll notice that as soon as I click on the second ViewController and start pulling it down, 72
ViewControllerWillDisappear gets called in preparation for the event where ViewController2 is going 73
to disappear. 74
But if I was to go here and I was to change the segue, so from the default Show to Present Modally, 75
and then change the Presentation type to Full Screen, so that the second view completely covers the previous 76
view, and that ViewController1 actually does, in fact, disappear from the phone. 77
So let's run this as it is now. 78
And, again, we get viewDidLoad, 79
viewWillAppear, viewDidAppear. 80
But now notice how once the second view controller is fully covering the previous view controller, 81
we're getting viewWillDisappear being called and, eventually, the VC1 viewDidDisappear 82
gets called once it can no longer be seen. 83
Notice how if I keep going back and forth between these two view controllers, were getting this VC1 84
viewWillAppear and viewDidAppear being called many times, 85
right? 86
And that's because it does appear and disappear quite a few times, but you'll notice that the viewDidLoad 87
for VC1 only gets called once and that's the first time it gets loaded up, 88
and that's because it's always living there in the background. 89
It's not getting destroyed. 90
It's just being covered. 91
Whereas when I click back on the second view controller, it is, in fact, getting destroyed and it is disappearing 92
for good, instead of just hiding out somewhere. 93
Now, this brings us to an interesting point and a really common source of confusion. 94
Say, for example, because we have this segue that goes between the next button on VC1 over to VC2 95
if I was to go into ViewController1 and add a prepare for segue method, then this is going to 96
get triggered as soon as that segue happens. 97
So let's create a destination VC from the segue.destination property, and we're going to downcast 98
that as a ViewController2. 99
Now, if this is at all confusing, just be sure to take a look back at the previous lessons where we covered 100
the segues and down casting in more detail. 101
So, now that I've got hold of a reference to the destination ViewController which is basically going 102
to be a ViewController2 type, notice how here I've got an IBOutlet that's linked to a UILabel and 103
that corresponds to this label right here. 104
Well, what if I wanted to prepare for segue by tapping into this destinationVC and setting its label 105
to have a text of "Hello." 106
So let's go ahead and run this code and only if you can predict what happens. 107
So we've got our standard viewDidLload, viewWillAppear, 108
viewDidAppear being called, and now as soon as I click Next, it triggers the segue, and it should if 109
our code was working. It should try to set that destinationVC's label. And you can see right here that 110
this destinationVC is a ViewController2 data type, and it is a living breathing object. But at this 111
point in time that UILabel has still not been created and nor has it been linked up to the ViewController, 112
so if I try to run this code, I actually get a fatal error and a crash, and it's because it found nil 113
when it was trying to access that label. 114
This is why the viewDidLoad method is really, really useful, and we use it so much in our iOS development. 115
It's because this time point inside these curly brackets, if you decide to write some code that's related 116
to the view, say, a label or a button, or anything that's on screen, you are guaranteed that it has already 117
been set up and created. 118
If you were to write label.text = "hello," then you are guaranteed that this will not fail, 119
because at this time point, the view has already loaded up, and that means that label is available for 120
you to change. So I've included this project as a GitHub repository in the course resources page. 121
So if you wanted to download it and have a play around with it, then feel free to do so. 122
Alternatively, you can also just create these methods yourself. 123
It doesn't take too long. But if you want to save yourself a bit of time, it's also there for you as well.