Meanwhile, with Flutter 2.0 the SnackBar code updated. This is how to invoke the showSnackBar method in Flutter 2.0 (my next video is about this kind of deprecations): ScaffoldMessenger.of(context).showSnackBar() (Yes, basically just add "Messenger" after "Scaffold")
Thank you again, I am not concerned with snackbar itself. I just wanted to understand that any widget using Context to be drawn should not run on the same class as scaffold.
wow! Hard concept to grasp. I watched 5 videos prior this one and i got more confused if anything ... your video was a revelation. Thank you ... not so hard when thigs are well explained. Truly thank you, fantastic video great explanation!
Thanks man! Surprisingly few explanations of this out there! Watching the pros bashing out builders under widgets without knowing why finally makes sense. Nice one.
The following assertion was thrown while handling a gesture: Navigator operation requested with a context that does not include a Navigator. The context used to push or pop routes from the Navigator must be that of a widget that is a descendant of a Navigator widget. When the exception was thrown, this was the stack: how to resolve this error
Hello and thank you for your explanations. So as I have clearly understood it, if a snackbar to work on first scaffold, it should not call scaffold.of(context) as it is calling on the scaffold itself, unless it is located in subtree beneth.
Yes. In this specific case, the SnackBar widget needs to use a context that CONTAINS a Scaffold (a context that has a scaffold). I say in this specific case, because the SnackBar widget specifically needs a context that contains a Scaffold. However, in most cases, you can just use the context that comes from the class (the one that comes with the method - build(BuildContext context)). So, most of the time that you use a context with a widget, the already given context (from the class) will work just fine because most widgets just want to know where in the widget tree they are located. But if you run into an error like this, where the widget or function you're trying to use wants a specific kind of context, now you can understand better what that error means. Let me know if this made it clearer or if I just confused you more lol
I had some confusion.first every widget has its own context like scaffold,material app,elevated button etc.I understand that context are just to know where I am on this widget tree like myapp-> materialapp->scaffold->container etc. My app class becomes widget while instantiated right? And do every widget has build method for example scaffold widget has build method.And finally where do we use class build method context inside the widget tree.If it doesn't work for snackbar then what is the usecase of this context.Its just a parent context (top-level) of all context
Technically, all widgets do have their own context because they extend classes that have the build method, but don't worry about that. It's not usually very relevant to be aware that some button has its own build context, and you will probably never need to access it. So, if you're confused by that, don't worry about it. The Scaffold is a different, much more important widget because it's like the blueprint/foundation of your UI. But widgets essentially use context to get information on themselves and on the rest of the widget tree. On this example, the Builder widget has its own context and you can access to it because that's one of the reasons why Builder exists. The thing with the SnackBar is that it needs a context with a Scaffold ancestor (as in, a context within a Scaffold, not before it). And the context that you get from the Class isn't the same. One is created before the return statement (the class') and the other after the return statement (the scaffold's). That is why when I used my own custom Button class/widget instead of the Builder, it still worked. The context belonged to the Button class, but it was within the Scaffold, so it did have a Scaffold ancestor. A class is a stateful/stateless widget ONLY if it's extending the StatelessWidget or StafulWidget classes. If it does extend, then yeah you can always consider it a widget. Instantiated or not. Also, the reason why all widgets have build methods, is because, again, they're extending the StatelessWidget or StatefulWidget classes. It's within those 2 classes that the build method is present. Once you create a widget and extend those classes, then notice how it always says "override" before the build method. That's because you're overriding the method from the class you extended. And for the final question: yeah, the class context doesn't work for the SnackBar specifically, but you will see that you will use the context from the class 99% of the time, so that's why it's there. You use it in many different opportunities, it's hard to say when/where. But basically, if you're really new to Flutter, always try to use the class context first. It will work most of the time. Then if you get an error you try other solutions. Let me know if I missed something or if you're still confused! (sorry for taking long to get back to you)
@@FlutterMentor You are a life saver.Nevermind for the late reply.I really appreciate that you had spent your time on explaining everything.Now I had clear understanding of Context.Its not much important to dig deeper but knowing the foundation helps in future.Never saw such a crystal clear explanation from anyone like you.Saw some other RUclipsr like Johannes, santos but that doesn't makes sense.Today I was totally pleased with your answer.I think I will poke you again in future .Thanks My Mentor
Meanwhile, with Flutter 2.0 the SnackBar code updated. This is how to invoke the showSnackBar method in Flutter 2.0 (my next video is about this kind of deprecations):
ScaffoldMessenger.of(context).showSnackBar()
(Yes, basically just add "Messenger" after "Scaffold")
Thank you again, I am not concerned with snackbar itself. I just wanted to understand that any widget using Context to be drawn should not run on the same class as scaffold.
wow! Hard concept to grasp. I watched 5 videos prior this one and i got more confused if anything ... your video was a revelation. Thank you ... not so hard when thigs are well explained. Truly thank you, fantastic video great explanation!
Thanks man! Surprisingly few explanations of this out there! Watching the pros bashing out builders under widgets without knowing why finally makes sense. Nice one.
Thanks for watching bro! And I appreciate the feedback as well, glad I could help
Ty, muito obrigado! me ajudou demais a entender o conceito de context!!!!
Great explaination...
The following assertion was thrown while handling a gesture:
Navigator operation requested with a context that does not include a Navigator.
The context used to push or pop routes from the Navigator must be that of a widget that is a descendant of a Navigator widget.
When the exception was thrown, this was the stack:
how to resolve this error
THANK YOU!
its pretty good thank you for making this
Really nice man
Hello and thank you for your explanations. So as I have clearly understood it, if a snackbar to work on first scaffold, it should not call scaffold.of(context) as it is calling on the scaffold itself, unless it is located in subtree beneth.
Yes. In this specific case, the SnackBar widget needs to use a context that CONTAINS a Scaffold (a context that has a scaffold). I say in this specific case, because the SnackBar widget specifically needs a context that contains a Scaffold.
However, in most cases, you can just use the context that comes from the class (the one that comes with the method - build(BuildContext context)).
So, most of the time that you use a context with a widget, the already given context (from the class) will work just fine because most widgets just want to know where in the widget tree they are located. But if you run into an error like this, where the widget or function you're trying to use wants a specific kind of context, now you can understand better what that error means.
Let me know if this made it clearer or if I just confused you more lol
@@FlutterMentor Cheers mate that is clear now...much appreciated...best regards...
@@danielhalmstrand2123 my pleasure, thank you for watching!
very well explained. Thanks a lot
Glad it was helpful!
I had some confusion.first every widget has its own context like scaffold,material app,elevated button etc.I understand that context are just to know where I am on this widget tree like myapp-> materialapp->scaffold->container etc. My app class becomes widget while instantiated right? And do every widget has build method for example scaffold widget has build method.And finally where do we use class build method context inside the widget tree.If it doesn't work for snackbar then what is the usecase of this context.Its just a parent context (top-level) of all context
Technically, all widgets do have their own context because they extend classes that have the build method, but don't worry about that. It's not usually very relevant to be aware that some button has its own build context, and you will probably never need to access it. So, if you're confused by that, don't worry about it. The Scaffold is a different, much more important widget because it's like the blueprint/foundation of your UI.
But widgets essentially use context to get information on themselves and on the rest of the widget tree. On this example, the Builder widget has its own context and you can access to it because that's one of the reasons why Builder exists. The thing with the SnackBar is that it needs a context with a Scaffold ancestor (as in, a context within a Scaffold, not before it). And the context that you get from the Class isn't the same. One is created before the return statement (the class') and the other after the return statement (the scaffold's). That is why when I used my own custom Button class/widget instead of the Builder, it still worked. The context belonged to the Button class, but it was within the Scaffold, so it did have a Scaffold ancestor.
A class is a stateful/stateless widget ONLY if it's extending the StatelessWidget or StafulWidget classes. If it does extend, then yeah you can always consider it a widget. Instantiated or not.
Also, the reason why all widgets have build methods, is because, again, they're extending the StatelessWidget or StatefulWidget classes. It's within those 2 classes that the build method is present. Once you create a widget and extend those classes, then notice how it always says "override" before the build method. That's because you're overriding the method from the class you extended.
And for the final question: yeah, the class context doesn't work for the SnackBar specifically, but you will see that you will use the context from the class 99% of the time, so that's why it's there. You use it in many different opportunities, it's hard to say when/where. But basically, if you're really new to Flutter, always try to use the class context first. It will work most of the time. Then if you get an error you try other solutions.
Let me know if I missed something or if you're still confused! (sorry for taking long to get back to you)
@@FlutterMentor You are a life saver.Nevermind for the late reply.I really appreciate that you had spent your time on explaining everything.Now I had clear understanding of Context.Its not much important to dig deeper but knowing the foundation helps in future.Never saw such a crystal clear explanation from anyone like you.Saw some other RUclipsr like Johannes, santos but that doesn't makes sense.Today I was totally pleased with your answer.I think I will poke you again in future .Thanks My Mentor
@@skirllexrude8170 thank you for the feedback! I'm glad I could help that's what I'm here for. Good luck in your journey
Thanks!
No problem!
That’s a more practical example. I appreciate it. But there’s too much I can’t understand lol.
I 've just tried to do print(' ${context.toString()} '). Funny.