Original subtitles

In the last section, we finished up our app, but there's a couple of highlights I want to share with

you.

We covered a ton of stuff throughout this application, so I'm just going to share some of the most

important things I want you to keep in mind as we start to move on to our next step for self import

statements.

So we saw three different types of import statements, imports, where we try to pull a code from another

package where we try to pull code from another file that you and I write and where we try to pull a

code from the standard library.

We're going to continue to write import statements of all three types on all the following applications

that we make.

Next up, what was probably the most confusing thing in this application difference between a state

list and a state full widget, stateless widgets are used any time we want to have just a presentation

widget, something that just takes data and shows it on the screen.

Every time that widgets data changes, we throw that instance of the widget away and construct a new

one with a new set of data, which is why over inside of our image list, we had marked this images

field as being final.

That meant to say that when our image list right here receives that list of images, that's it.

That's the end of it.

Never going to get a list of images again.

If we need to render the list of images, we're going to throw away our existing instance of the widget

and recreate a brand new one.

Inside of our app file over here, we have created a stateful widget because this thing had some data

tied to it that we did not want to throw away when this widget got rendered.

I remember when we make that stateful widget, we're actually kind of showing two things inside of our

widget tree.

Where is that diagram?

Right here.

So when we use that stateful widget, we still get a widget inserted into the actual widget tree, but

that thing has sets or state called on it, which creates a new instance of that app.

State class that outstay class kind of exists outside of our widget tree and it does not get thrown

away whenever the app gets rendered.

We use that app state widget to save some data to it that we didn't want to throw away any time, anything

change inside of our application.

So these two fields right here were not marked with final because we wanted to be able to change them

over time.

Now, the next big thing that we spoke about was asynchronous code handling inside of DART, so we made

use of the async O8 syntax to wait for the future.

They got return from this call right here to resolve.

Then once that thing got resolved, we then took the data from it.

We pulled the JSON out of it.

We use JSON Decode right here to turn it into a map.

And remember, a map is like a JavaScript object or a ruby hash or just a typical map data structure.

We then had made that image model to look at that map and pull certain fields out of it and try to assign

types to some of the properties that were in there.

Now, again, we did not have to strictly make this image model right here.

We made it because it allows us to apply more typing, more like, you know, programmatic typing,

not like physical keyboard typing to our application, which generally makes our code a little bit easier

to maintain.

So we made that image model, we then were able to cause our app state, which it to cause the entire

application to render itself by calling set state right here.

OK, so that's kind of the big high points I want to mention, we covered the important statements,

states less and stateful widgets and asynchronous code that we added in.

Now, one last thing I want to share with you about stateful and stateless widgets.

All the state stuff around flutter is by far one of the most chaotic pieces of flutter right now.

There's a whole variety of different patterns for managing data and changing data within your application.

This idea of stateful and stateless widgets is just one method of many that has been proposed and flutter.

But the stateful stuff, although it seems kind of complicated, is the way that is kind of recommended

by default by the authors of Flutter.

There are other patterns that are recommended by the Flutter team as well.

And we're going to look at another one of those patterns in a later application that we're going to

tackle now, this other way of handling all the state stuff.

Honestly, my personal belief is it's pretty darn complicated, but we're going to work through it together.

And I think at the end of the day, you will learn a lot not only about state management and flutter,

but you'll also learn a lot about general programming stuff as well.

So even though that later state stuff is more complicated, you will learn a lot about general programming

stuff.

So I'm really excited to get there.

OK, so enough enough for review.

Let's take a quick pause.

We'll continue in the next section and start up our next application.

So I'll see you in just a minute.