Managing State in Flutter

Sep 22 2022 · Dart 2.17, Flutter 3.0, Android Studio Chipmunk

Part 2: Use Provider

15. Learn Other Provider Features

Episode complete

About this episode
Leave a rating/review
See forum comments
Cinema mode Mark complete Download course materials
Previous episode: 14. Use Multiple Providers

Get immediate access to this and 4,000+ other videos and books.

Take your career further with a Kodeco Personal Plan. With unlimited access to over 40+ books and 4,000+ professional videos in a single subscription, it's simply the best investment you can make in your development career.

Learn more Already a subscriber? Sign in.

Transcript: 15. Learn Other Provider Features

Provider is a rich state management solution so it should come to no surprise that Google recommends it for all your state management needs. Yet, this part of the course, only covered some of the more well known features of the library. In this episode, you’ll get an overview of some of the other features as well as some important things to consider before incorporating Provider into your own project.

First off, you were introduced to a few different provider types. You learned about the regular Provider which returned a regular object though object changes do not fire off a rebuild. Then you learned about the Change Notifier that uses change notifier object to notify when an object’s state has changed, causing a rebuild. The multi-provider allows us to provider multiple providers to be used later on in the widget tree.

Those were the types covered but there are a few other provider types.

First, there is the future provider. This provider will cause only a singular rebuild being from the result of a future. For instance, you may fetch some data over the network.

If you need a continuous stream of updates, then you have the Stream provider at your disposal. Whereas a future provider will rebuild only once, the stream provider will rebuild over a series of times.

Then, we have the proxy provider. The proxy provider allows us to combine the values of multiple providers that acts as a singular provider. This is helpful when you have multiple types of objects that have dependencies on one or another.

A listenable provider is used for listenable objects that causes a rebuild over state changes. The ChangeNotifierProvider is actually a subclass of the Listenable provider, so generally, you’ll just use the change notifier provider but if you need finer control of the implementation say working with the animation than you have the Listenable provider in your toolbox.

So as you can see, Provider provides a lot of functionality, and the best place to learn more about it is from the official documentation. Besides giving a complete breakdown of the classes, the documentation provides a nice overview of how to use the API and how and how-not to use it.

Which raises one final important discussion. Should you consider using Provider in your next project. At the time that this course was recorded, Provider is the Google recommended state management solution. It doesn’t replace inherited widgets, but rather, builds on top of them. Or better put, “Inherited Widgets for humans”.

But, during the recording of this course, Remi Rousselet, the author of the Provider package noted that he consider’s the package deprecated, and that people should use his followup state management solution called Riverpod.

Riverpod is like Provider - in fact, the name Riverpod is an anagram of Provider, but the key difference is that Riverpod does not use inherited widgets. This means, you can use Riverpod outside the context of Flutter so if you have other Dart projects that require a state management solution, then Riverpod will work fine. Another feature with Riverpod is that it provides compile time checking as opposed to Runtime checking.

That said, switching to Riverpod can be a big ask for some developers who bristle at the thought of using third party dependencies. If you plan on supporting an app for the next five to ten years, can you guarantee that Riverpod will still be stable or will it also be deprecated in favor of another approach. Is it better to use the tools provided by the framework versus using another person’s code. That’s really up to you, but you should give the question some thought as at the end of the day, you are the person responsible for your code.

That said, there are lots of different state management solutions that aim to solve the issue of state management in different ways. Each solution is unique which may work well for some apps, but not work well for others. It would behove you to learn about these solutions and how and where they may apply. After all, the more tools you have in your toolbox, the better Flutter developer you’ll be.