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
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
Russian
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
Our application at the moment has one problem.
When I opened that motile sheet and I tried to enter something here, you see that this gets cleared,
the title gets cleared.
As soon as I click into the amount, if I click into the amount into the title now, the amount gets
cleared.
So something's wrong here.
By the way, of course, our amount is also a bit overlapped by the keyboard.
If we enter something into the title and that's something we'll fix later all day, if you would rotate
the device into landscape, you wouldn't really be able to work with that.
But let's take care about this later.
Once we learn how to build more responsive user interfaces for the moment, let's fix that issue of
our data getting lost when we will click into the other fields.
The fix is simple.
You need to change neutrons action.
So does widget, which renders these inputs from a state less into a state full widget, even though
we're not calling said state in here that internally changes something for flutter because the state
object in the end is treated differently then a widget object.
It's basically maintained and not rebuilt as off then easily.
And therefore you should convert neutrons action here to a stateful widget.
And thanks to those refactoring Syntex, that all is done automatically.
And now if you reload your application with that safet, if you now open that again.
Now here we can enter something and now the data is kept and we can add this and see our new transaction
here, which is of course, pretty convenient.
Now, just to clarify and make it clear why we need to make this change to a stateful widget.
It is related to what Flutter does internally.
It re-evaluates widgets from time to time.
For example, if a parent widget changes and I'll dive deeper into how Flattr evaluates your app and
when something is revaluated later in the courts, no worries.
But from time to time, flutter.
Does that ad for a state less widget.
A widget being re-evaluated means that any internally stored data is reset is lost.
That's why we lose our user input in a state less widget, because whenever it is re-evaluated by flutter,
for whatever reason, we lose to state to this kirtley stored in there, we lose our data that's stored
in there.
And for a state full widget, that's different.
Deezer, we have that separate state object, that state class.
And whilst the which it does are also would be re-evaluated by flutter, the state kind of his detached
from this and data stored in that state will not be lost if the widget that belongs to it is reevaluated
by flutter.
So we have a separation of data and the UI.
You could say and therefore we can persist data.
And it's not lost when something changes on the screen or when a flutter decides that it wants to reevaluate
that widget.
That's where our data is then persistent.
And that's why we need a state full widget here.
Now, internally here in new transaction, there is now also one important change.
We still get at transaction as our argument here, and that's inside of our widget, right at transaction
is a property in our widget, not in the state object, but in the widget.
And it needs to be there because we need to define it where we need to accept it on the constructor
of the widget, not on the constructor of the state, because the state is constructed here with the
help of create state and that's inside of the widget.
So to receive something, some data in the widget from outside, which is the case here, we receive
a pointer at the add new transaction function.
We need to accept that on the constructor of the widget.
The problem is that I want to use this function from inside the state object thereafter and not inside
my widget.
And these are two different classes.
Technically, thankfully, Flat-Rate establish that connection and gives us a special property inside
of our estate class.
It gives us this widget property and this refactoring step automatically added it with widget dot.
You can access the properties and methods of your widget class instead of your state class.
So with widget dot at t x, I can access to ads T X property, which has this function reference I get
even though I'm technically in a different class.
That's important widget.
That is a special property we haven't seen before.
It has to be named which ID and it's only available in your state classes and gives you access to the
connected widget.
And with that, we now also fixed that issue off the bottom sheet, clearing our inputs when we type
in there.
Now, one other thing we can do is that when we enter a new transaction here, that we actually all
disclose the bottom sheet as soon as we confirm it and we don't have to close it manually.
And doing that is pretty straightforward here in submit data.
After calling ADT X, you can call Navigator off context, pop.
Now, that's something we haven't seen before.
The navigator is always something I'll have a way closer look at in the navigation section of this course.
It's built into flatter and you can do a lot of awesome stuff here.
We simply use its pop method to basically close to topmost screen that is displayed and that is that
modal sheet if it's opened.
So that closes that motile sheet by popping it off.
And more on that and what it does in detail in a later section of context here is required to get access
to the right navigator or to give the navigator some meta data and context here.
Just like Widget is a special property which is available class white in your state class here, even
though you never defined a property name context, it's made available because we extend state.
So it's basically like widget.
It's a special property that is available.
And that in this case gives you access to the context of your widget widget, gives you access to the
class itself, to its properties and on context, gives you access to the context related to your widget
more or all of that later.
With that, however, we now added the functionality that we can automatically hopes that we can automatically
close our bottom model sheet once we're done.
So if I now add my new shoes here, which let's say cost ninety nine dollars.
Ninety nine.
Now you'll see that also close to molted.
With that, let's continue with our app and let's again turn our heads towards styling.
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.