Flutter provider ChangeNotifier, Flutter state management

Hi, thank you for joining me.  My name is  Sergio, and today we will introduce you to state management in Flutter. Use a small code base to create design patterns for scalable applications. I use the official example in the Flutter documentation.

Now that you understand declarative UI programming and the difference between temporary state and application state, you are ready to learn simple application state management.

The provider package is easy to understand and does not use much code. It also uses concepts that apply to all other methods.

To illustrate, consider the following simple application. The application has two independent screens: catalog and shopping cart. It may be a job posting application, but you can imagine the same structure in a simple social network application or directory.

The catalog screen includes a custom application bar and a scroll view of many list items. This is an application visualized as a tree of widgets.

So we have at least 5 subclasses of Widget. Many of them need to enter a state of "belonging" to other places.

This leads to our first question: where should we put the current state of the shopping cart?
By calling methods on it, it is difficult to force changes to the widget from the outside. Even if you can make this work successful, you will fight the framework instead of letting it help you.

Shopping cart Widget.updateWith(item);

You need to consider the current state of the UI and apply new data to it. It is difficult to avoid mistakes.
In Flutter, every time its content changes, you build a new widget. Whenever it changes, it will rebuild MyCart from above.

When we say that widgets are immutable, this is what we mean. They will not change-they will be replaced.


ChangeNotifierProvider is a widget that provides ChangeNotifier instances to its descendants.


Now that CartModel is provided to the widgets in our application via the ChangeNotifierProvider declaration at the top, we can start using it.

The only parameter required by the Consumer widget is the builder. Builder is a function, it will be called whenever ChangeNotifier changes.

The best practice is to place your Consumer widget as deep as possible in the tree. You don’t want to rebuild most of the UI just because some details have changed somewhere.


We will ask the framework to rebuild a widget that does not need to be rebuilt.

For this use case, we can use Provider.of and set the listen parameter to false.

Very nice example for different architecture samples.