All language subtitles for 002 Why Two Classes_en

In the last section, we spoke about some of the weird syntax right here, we're going to now have a

very quick discussion and talk about why we had such a painful refactor to take our app over to a stateful

widget.

In other words, why did we have to create two separate classes right here?

And why did our App Widget have to have a create state method tied to it?

Well, let's take a look at a diagram that's going to help us understand what's going on.

OK, so this is a flow diagram of what would happen if we did not did not have a stateful widget.

That's the key.

OK, so this is how life would be if we did not have stateful widgets.

So let's walk through the flow here.

At the very start, Flutter would decide to look at our app and render our widget on the screen of our

device.

Now will assume that our state lists widget of app right here.

Again, this is considering the case.

We did not have a stateful widget would create a new instance of our app widget.

That app widget might have a counter variable assigned to it of zero.

And so that new app widget would display the number zero on the screen.

So then maybe at some point in time, a user presses that button and that increments the value of counter

to one.

Now, here's the key part.

If Flutter then decided to re render our application, it would create a new instance of our app widget,

so we would now have two instances of the app class and play.

We have the old copy that now has a counter value of one assigned to it, but flutter when it re rendered

our application, created a second instance of app, and that second instance has the initial value

of counter assigned to it of zero.

Flutter throws away the old copy of app, and it decides to now use the new one to represent our app

widget on the screen of the device.

And so when Fluttery renders our application with this new copy of app, we still have the zero value

of counter.

And so we still see zero on the screen.

Now, the real key here, the key thing to understand is why Flutter decides to create a new instance

of our app widget.

And the best way I can show you that is by pointing out the build method right here.

So whenever Flutter tries to render our application, it's wouldn't you call the built method on every

widget that we have inside of our application.

When you look at this build method, you'll notice that every single widget that we create inside of

here is created from scratch.

So material app right here is a new instance of the material app class.

This is a new instance of scaffold, a new instance of text, a new instance of floating action button.

So every time that flutter decides to re render our application, it is creating a new instance of these

widgets.

So all the old instances get thrown away and we create these new ones.

And when we get this new instance of this widget, it comes with a completely reinitialize set of instant's

variables.

So if we did not have stateful widgets, we would never see any changes appear on the screen of our

device.

OK, so let's now talk about what's happening, thanks to the fact that we do have stateful, which

is, you know, what's happening now that we have these two separate classes.

All right.

So slightly different flow diagram here.

So this is with stateful widgets.

So we start off again with flutter, deciding to render our app on the screen, not the device.

It creates a new instance of the app widget, so here's the app widget right here, like that's the

top class, this one right here.

When that widget is created, when the output is created, flutters, then going to automatically call

the create state method on that widget.

So the state method that you and I defined, so that's create state right here inside of create state,

we create a new instance of app state and return it from that method.

Flutter is going to take that app state object that we just created and it cashes it, so it holds onto

it and it does not throw it away, then whenever a user presses that button, the counter will increment

by one.

And because you and I called set state inside of our app, State Widget Flutter decides to render our

application.

So at that point, a new instance of the app widget is created just as it did before, over on this

diagram.

But the old copy of our state is kept around, so we are not creating a new copy of App State because

that app State Object gets cached and it sits around no matter how many times Flutter decides to render

our application.

Because upstate does not get Virender or something, because upstate does not get recreated, its instance

variables do not get reset or they don't get initialized back to their starting values.

So we then re render our app widget, but it uses this original copy of app states where the counter

value is still set to one.

I think another diagram that might be helpful to take a quick glance at is this one right here.

So here's our widget tree again.

At the very top, we've got that app widget.

So that's the original one right here, the first class we put together.

And any time the app is first created, we produce a new instance of App State through the create state

method.

So this widget right here, that first class we put together, this thing is going to be thrown away,

recreated many times in the life cycle of our application.

But the app state object over here only created one time and then we hold on to it for as long as our

app is running or until we decide that we don't want to render this widget on the screen anymore.

OK, so hopefully that gives you a better idea of why we have to create two classes right here, it's

all because whenever Flutter decides to render our application, it's going to throw away this widget

and it's going to try to recreate it.

If we recreated it, then we would lose all the data that we had tied to that widget previously.

So by making sure that we have this great state method right here, along with a separate app state

class, we're going to hold on to our instance of the state that has created, no matter how many times

our application is rendered.

All right, so I think we got a better idea of what's going on here, so let's take a quick pause and

we'll continue in the next section.