Afrikaans
Akan
Albanian
Amharic
Arabic
Armenian
Azerbaijani
Basque
Belarusian
Bemba
Bengali
Bihari
Bosnian
Breton
Bulgarian
Cambodian
Catalan
Cebuano
Cherokee
Chichewa
Chinese (Simplified)
Chinese (Traditional)
Corsican
Croatian
Czech
Danish
Dutch
English
Esperanto
Estonian
Ewe
Faroese
Filipino
Finnish
French
Frisian
Ga
Galician
Georgian
German
Greek
Guarani
Gujarati
Haitian Creole
Hausa
Hawaiian
Hebrew
Hindi
Hmong
Hungarian
Icelandic
Igbo
Indonesian
Interlingua
Irish
Italian
Japanese
Javanese
Kannada
Kazakh
Kinyarwanda
Kirundi
Kongo
Korean
Krio (Sierra Leone)
Kurdish
Kurdish (Soranรฎ)
Kyrgyz
Laothian
Latin
Latvian
Lingala
Lithuanian
Lozi
Luganda
Luo
Luxembourgish
Macedonian
Malagasy
Malay
Malayalam
Maltese
Maori
Marathi
Mauritian Creole
Moldavian
Mongolian
Myanmar (Burmese)
Montenegrin
Nepali
Nigerian Pidgin
Northern Sotho
Norwegian
Norwegian (Nynorsk)
Occitan
Oriya
Oromo
Pashto
Persian
Polish
Portuguese (Brazil)
Portuguese (Portugal)
Punjabi
Quechua
Romanian
Romansh
Runyakitara
Samoan
Scots Gaelic
Serbian
Serbo-Croatian
Sesotho
Setswana
Seychellois Creole
Shona
Sindhi
Sinhalese
Slovak
Slovenian
Somali
Spanish
Spanish (Latin American)
Sundanese
Swahili
Swedish
Tajik
Tamil
Tatar
Telugu
Thai
Tigrinya
Tonga
Tshiluba
Tumbuka
Turkish
Turkmen
Twi
Uighur
Ukrainian
Urdu
Uzbek
Vietnamese
Welsh
Wolof
Xhosa
Yiddish
Yoruba
Zulu
In the last section, we finished up a refactor that moved a bunch of logic from our main function inside
of the main dart file into a new custom widget that we defined inside of our app dart file.
Inside the outdoor dirt file, we created a new custom widget by defining a new class that extended
the base class of stateless widget.
We made this a stateless widget because we did not expect it to have to maintain any of its own data.
That would change over time.
That might change at some point, and it might change very shortly.
But at least for right now, it was a good place to get started.
Any time that we define a custom widget, we must define a method on that custom widget called Build
the build method has three requirements.
First off must be called built.
That's obvious enough.
Secondly, it must return a widget.
Third, it must accept a single argument that we referred to as context.
And you'll sometimes hear this referred to as the build context because that's technically the type
of the value that gets passed in.
We will eventually come back and talk a lot more about what this context thing is.
But for right now, we're just going to gloss over it a little bit.
So then inside of our build method, we assembled a new material app widget that had all of its own
custom widgets nested inside of it.
We then return the entire thing.
Then back over inside of our main dirt file, we imported the custom map widget that we just created.
We then created a new instance of that widget and passed the instance off to the run app function.
Then presumably behind the scenes run app took that instance of our app widget, and I assume at some
point time probably called this build method right here.
It got back all these definitions of what our app is supposed to look like and then rendered all those
widgets onto the screen of our mobile device, so that's a review of where we're at right now.
Now, before we move on, there's one last little concept I want to reveal here.
OK, so this is what we refer to as our widget tree, and it's a very handy way of visualizing all the
different images that are being displayed inside of our application.
So at this point, everything inside of our application is being rendered ultimately by the app widget
that we just put together.
The App Widget is returning from its build method, the material app widget.
So as a direct child to the app, we have our material app.
Then as a direct child to the material app, we have the scaffold that we put together.
Then the scaffold itself shows two widgets, the floating action button and the app bar, and each of
those are showing its own respective widgets of icon and text.
So again, this is a handy way to picture our widgets as they are built inside of our application.
And we're going to eventually create a couple of different diagrams like this to better understand the
flow of data inside of our application when we start introducing state or data that changes over time
inside of our app as well.
OK, so that's a good review.
Let's take a quick pause right here.
We're going to come back the next election and we're going to start working on the next piece of functionality
inside of our app.
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.