Original subtitles

0 Now in the last lesson we used our scratch.dart file to learn more about futures and async and await. 1

But we don't need this file anymore so you can either delete it or you can keep it around for reference 2

in the future. 3

It won't affect your project. 4

Now let's head back into our loading screen and if we take a look at the code now, it should make a bit 5

more sense to you. 6

You can see that we're creating a new geolocator object that comes from geolocator.dart. And then 7

we're using that object to get the current position. We're calling getCurrentPosition 8

and this is a method that's inside geolocator. And we provide the amount of accuracy we want for this 9

location. 10

And we're going to choose low so that we don't use up all the battery. And because it takes time to get 11

the current position 12

this method is asynchronous and it will happen independently of whatever else you decide to try and 13

do. But because in most cases we can only proceed forwards with for example printing the position we 14

got back or with using that position in getting some weather data, 15

then we're adding the async keyword to modify our function. And that gives us access to the await keyword 16

which basically says wait until this completes before you continue doing anything. If we didn't have 17

this await keyword, then we could still have a position but it won't be an actual position. 18

It will be a future position. 19

It's just like that order number. 20

It will have a value in the future 21

once this process completes. But at the point where this code is called or when it's triggered, this is 22

just a receipt. 23

It's not an actual coffee. 24

And right now if I was to print out this position variable, it won't be an actual position that actually 25

comes out. And we can show that by changing this from running scratch.dart to main.dart. 26

And now if I press run and I go ahead and click on get location, then you can see that what's being printed 27

in my console on the main.dart, so we can close down scratch.dart 28

if you want, is an instance of future position. This is kind of like you promise your friends to go and 29

grab them a coffee and all you did is come back with the receipt. 30

Now they're not going to want the receipt. 31

They're going to want the actual coffee. 32

So that's why we're adding that await keyword in front of the method call to say that, wait for this 33

to finish before you assign this value to the position. 34

So that way we actually get an actual position or an actual coffee, rather than just the promise of a 35

coffee that's going to be there in the future. 36

And now if I click on get location, you can see the actual location gets printed rather than just a future. 37

So it's all very well and good that we can get the location when we press on this button. 38

But what if we wanted the location as soon as our screen loads up? Because in our weather app, as soon 39

as we open up the app, it's going to trying and detect our location and based off that location, it's gonna 40

get the weather. 41

It doesn't make sense to force the user to press a button to say get weather or get location, 42

that seems a bit extra. So how would I call get location if I wanted it to happen as soon as my screen 43

loads up? Well in order to do this 44

we have to learn about widget lifecycles. 45

We know that stateless widgets are basically just like very simple Lego blocks right? 46

You can't saw them in half, 47

you can't change them. 48

You can't do anything with them unless you decide to destroy them and create a new one. 49

And you have to keep destroying and creating new ones every time you want a change in a stateless widget. 50

So for these widgets, their lifecycle methods are very simple. There's only one that you should be concerned 51

about and that's the build method. When the widget gets built 52

this method will be called and inside here, 53

you will create whatever appearance or widget you want to show up on screen. 54

Now on the other hand, we also have our stateful widgets and we know that these stateful widgets can 55

be combined and we can track the state using a state object. 56

Now that state object is there keep track of variables such as what is the configuration of my widgets, 57

what are the properties of my widgets. 58

And I can change all of those variables by using a set state and it will update my app. Now 59

in this case, the state object actually lives a lot longer and so it's got more lifecycle methods. 60

There is an init state, which gets triggered when that state initially gets initialized. 61

There's of course the build method which gets triggered when the widgets are actually built and will 62

show up on screen. And then there's a deactivate method which gets called when that stateful widget 63

gets destroyed. 64

So just as we humans are born and we grow up we go through different life stages and then we also die, 65

so do our stateful widgets. But we can tap into each of those stages in the lifecycle if we wanted different 66

things to happen at various times. 67

Now I just want to show you when these lifecycle methods will get triggered. And to do so, I'm pulling 68

up that previous file that we had, the navigation demo that we used earlier on. 69

Now you don't have to write any of the code, 70

I just want to show you what actually happens. 71

It's enough to just follow along. Here we still got our screen 1 which is a stateless widget. 72

We've got our screen 2 which is currently a stateful widget. And I've made our app start out at a screen 73

1 which is the first route. 74

So when I run my app, I head over to the screen 1 which only has a single button that pushes me onto 75

screen 2. 76

Now once I'm on screen 2, I want to be able to show you when these lifecycle methods actually get called. 77

Inside our state object, I'm going to tap into a number of methods that come from the parent class, the 78

state class. One of those is the initState method. 79

And if we click on this initState, hold down CONTROL + J or CONTROL + Q, you can see that this 80

is called when an object is inserted into the tree. 81

And this means that when we create our stateful widget as soon as it's inserted into the tree, it's 82

going to call initState. 83

So this is the first thing that happens. 84

So inside here I'm going to add a print statement saying 'initState called'. And that will print whenever 85

this method gets triggered. And it will get triggered automatically at a particular stage in the life 86

of this state object. 87

Now the second one that gets triggered, 88

so the second point in the lifecycle, is going to be the build method. 89

Now inside here, I'm also going to add a print statement saying 'build called'. 90

And finally there's also another method that comes from the parent class that I want to show you which 91

is called deactivate. And deactivate will get triggered when this stateful widget gets destroyed. 92

So let's add a print statement in here as well. 93

Now let's go ahead and click run for our changes to go through. And in our console you can see that as 94

soon as I click on this button, I should head over to screen 2. 95

Now as soon as that stateful widget is created and inserted into the widget tree, initState gets 96

called. 97

So that gets printed in here. 98

And then as soon as it builds all of the widgets inside the screen which is just my button and my scaffold 99

etc. then we get billed called. Now every time I make a change in the screen or I change one of the properties 100

that the widgets depend on, then build will get called again and again and again. 101

And this is one of the most frequently used lifecycle methods. 102

But at the very end when I click on go back to screen 1, screen 2 is going to pop off, 103

that means it's going to be destroyed. 104

It will no longer exist. 105

And that is the time when deactivate will get called. 106

So there are other lifecycle methods but these are probably the most useful and the ones that you'll 107

actually come across and need when you're creating Flutter apps. 108

So we know that if we want something to happen the moment that our stateful widget is created and 109

add into the tree, then we're going to put our code inside initState. If we want something to happen 110

every single time 111

our stateful widget gets rebuilt, then we'll put it into the build method. 112

And finally if we want something to happen when our stateful widget gets destroyed, then we would put 113

the code inside the deactivate method. 114

So now using what we've learned on lifecycle methods, here's a challenge for you. 115

I want you to change our code so that the position gets printed into the console without tapping on 116

any buttons. 117

In fact you can go ahead and delete the entire contents of the scaffold. 118

What should happen is as soon as our app runs 119

and as soon as this loading screen appears inside the phone then we should see our position being printed 120

in the console. 121

And this will rely on what you've learned from this lesson. 122

Pause the video and try to complete that challenge all right. 123

So currently when we run our app all we get is just the blank screen. 124

There's nothing inside build, just a blank scaffold. 125

So we're not gonna use any buttons to trigger getting the location. 126

Instead we're going to add a initState to our loading screen. And because we know that this is going 127

to be triggered as soon as our stateful widget gets created, 128

so it's the moment that this appears on screen. 129

Now it's important to know that initState only gets called once and it's only the moment when that 130

state gets initialized and gets created. 131

But something like build even though it does get called when our widget gets built onto the screen, but 132

it gets caught every single time that our widgets rebuild. 133

So every time a piece of text changes or an image changes or this animation, then build will be called again 134

and again and again. And very often you don't want to put code in there that will get called repeatedly 135

because it's very expensive. 136

Instead we're going to put it inside initState. 137

And so inside initState, we're going to call get location. 138

And now if I go ahead and hot restart my app to make it reinitialize this particular stateful widget, 139

then you can see as soon as it goes on the screen, I get my position printed in the console. 140

I didn't have to press anything at all. So our lifecycle method are really useful if we want to tap in 141

to a particular moment in the life of our stateful widgets. If we wanted to save a piece of data just 142

before the stateful widget gets destroyed or if we want to deallocate something from memory or if we 143

want to create a new object as soon as the stateful widget gets initialized, these are the methods that 144

we can tap into to make our code run at a particular time. And in our case we're making our get location 145

method run in the moment as soon as our loading screen state gets initialized which is going to be at 146

the very start and we only make it run once. Now 147

at the moment, we're getting our location and we're importing our geolocator all inside our loading 148

screen which is kind of not its job right? 149

So in the next lesson we're going to learn more about checking to see if the user has given permission 150

to get the location. 151

And we're also going to refactor all of the location related work into our location.dart file. 152

So for all of that and more, I'll see on the next lesson.