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 started extracting some logic from our main dirt file over to this new custom
app widget that we have started working on, we got through comment number one up here.
And we're now going to continue with the second step, which is the second coming right here.
So in the second step, we need to create a class that is going to extend the base stateless widget
class to do so.
We're going to first just write out the code for this and we'll talk about what it's doing.
So the code that we need right here is a class app extends stateless widgets.
OK, you might see a little red squiggly under that that says missing concrete implementation.
You can completely ignore that error message.
Right now, we're going to fix that up in just a moment.
What's more important is what's going on with the syntax right here and even more importantly, what
a stateless widget is.
So, first off, the syntax.
This defines a new class called app that's going to take all the functionality inside of the base class
of stateless widget and add some additional methods.
In instance, variables on top.
This right here is classic object oriented programming, so we're taking a base class and extending
it with some additional functionality, we would now refer to our class app as a subclass of stateless
widget.
OK, so the idea of extending a class, again, classic Opta to programming, not the worst thing in
the world, what is a little bit more confusing is exactly what a stateless widget is.
So let's take a look at a diagram that's going to clarify that.
So in the last couple of sections, I've been using the term widget over and over and over, a widget
and flutter is not only a concept of something that controls some element that gets displayed on the
screen of our mobile device, but it's also a class.
So in flutter there is a class called Widget and it contains a bunch of functions and different instance
variables that assisted in showing some content on the screen of our device.
From this widget class, there are two subclasses.
One is called Stateless Widget and the other one is called stateful.
There's one difference between these two classes and it solely comes down to whether or not the widget
that we're trying to create is going to maintain its own state or its own data.
So if we are creating a custom widget where we expect our which to to never have to like essentially
maintain its own source of data, we will create a stateless widget.
If we expect to have to create a custom widget that's going to eventually have to control its own source
of data or go fetch its own data or somehow generate and maintain its own state, we will instead create
a stateful widget.
Now, if these terms of, like maintain data and state don't make any sense to you, that's totally
fine.
Let me try putting this a different way.
If you are trying to create a widget, as we are right here, and you expect this thing to eventually
have to maintain its own local instance variable, that has to change over time, like, let's say we're
making some counting application.
And for that, we would want to make some like counter variable.
That starts off at zero and then we would maybe want to increment this counter over time, if you expect
to have to write code like this right here, then you do not want a stateless widget.
We only use a stateless widget when we do not expect to have to add in an instance variable that's going
to change.
In our case, our app widget for right now does really not appear to have any data tied to it that's
going to change over time.
Now, once we add in this idea of fetching images and whatnot, maybe that's going to change.
But right now, just for what we have at this point in time, it has no data tied to it that's going
to change.
And that's why I chose to use a stateless widget right here rather than a stateful widget.
OK, so that's step number two.
Now, let's again take a quick break, we're going to come back to the next section and we're going
to start working on this build method thing right here.
So quick break and we'll see you in just a minute.
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.