 Hello guys so in this video we are going to start with the provider so first of all we will just go with a basic definition that provider is a wrapper around inherited widget to make them easier to use and more reusable. So this is basically the official definition that I have taken it. So here if you talk about inherited widget the inherited widget is basically a base class that allow those classes to extend the information under the tree from it. You can simply extend the inherited widget class and you can also maintain the state like the provider is doing. So if you say simply it is used for state management. So let's move ahead and talk about state management. So whenever we maintain the state we have used so far this set state method and this set state method is basically used for maintaining the ephemeral state of the app but we have global state as well and in order to maintain the global state we have different options like we have blog we have provider we have get access we have radix and so on. So let's talk about ephemeral state and global state a little more. So what we use whenever we want to maintain the state of a screen then we use this ephemeral state and whenever we have to maintain the state of multiple screens then we refer with a global state. So far we have used ephemeral state where we have called set state and maintain the state of a particular screen but if you want to maintain the state of multiple screens then you have to refer to global state. So let's move next. Now let's take an example for example we have this main screen. So this is going with the flow of going to screen one from screen one you can go to screen two from screen two you can go to screen three. Same way from main screen you can go to screen four as well from screen four you can go to five and from five you can go to six. Now let's try to understand with one example. For example if you want to send the state from screen one state is basically it can be any data okay. So let's say I have modified some data on screen one and I want to send it to screen three so what we can do so. So in order to do so what we can do if you want to just pass it from screen one to screen three you don't have direct flow over there. So you need to go through with screen two okay. So you will send your data from screen one to screen two by calling this constructor like we are navigating. So whenever we use navigator.push replacement or push so we just pass the constructor of a particular screen. So with that constructor we can pass this data. So this data will be passed to screen two and from screen two you can call screen three and you can pass that data coming from screen one. So this is how you can maintain the state between multiple screens. This is a one way. So now here we have a little problem for example let's say I want to send data from screen three to screen five. So since there is no direct connection between these how you will send data. So we cannot call screen five from screen three but we want to maintain the data available or modified in screen three which can be accessible to screen five as well. So in order to do so we need to use global state. So what we can do so we can save our data from screen three to our global state. So once it is stored anyone can access it. So let's say screen five want to get the data so it can simply read it from global state. So that's where the global state comes into the picture. So let's move next. Now the question comes why provider. So first reason is it is used for global state management. So we have seen the problem with ephemeral state in this example like if you don't have a flow between screens you cannot pass your data you cannot maintain your data. So that's why this is one of the reason we use provider for global state management. Then another benefit is that it can separate the logic part your business logic from UI. So in set state we were writing the UI part over there in the file and the logic as well is written in the same file. So the provider does what it just separate your business logic from UI parts so that it should not mix and it would be easy to modularize the app and test the app as well. Next reason is the benefit of using provider is it rebuilds only required widget instead of the whole screen. So we were using set state earlier which is very costly because what it does it rebuilds the whole screen whenever we call set state method. So whenever it builds the whole screen all the UI elements are re-rent on the screen. This gonna be easy thing if we don't have much data on the screen but if we have a complex screen then it gonna decrease the performance of the app. So this means whenever we call set state in order to update the state the build method is called and all the widgets are built again and re-rented on the screen. So that is what the problem with set state that is also one of the reason we prefer provider. So that's all for this video in the next video we will see that how the app humeral state rebuilds the whole widget tree even after a little UI change and we will also see how the provider gonna manage the global state and how the provider gonna help us by re-renting only the required UI component instead of rebuilding the whole widget tree and also we will see how the provider gonna separate the business logic part from the UI part. So that's all for this video. Thank you.