Flutter State Management

July 01, 2021 Publish By : EXPERT APP DEVS 5 min read Viewed By : 714
Flutter State Management

State management is one of the key capabilities a UI framework needs to enforce well. It’s because of this that many developers have wound up developing dedicated state management libraries; the integrated solution wasn’t sufficient for them, or they desired to tweak it to their taste.

UI frameworks have when you consider that they stepped up their game to level the gambling field. Their integrated state management solutions can now fit the overall performance of present outside solutions. React, for example, delivered Hooks and Context to compete with React-Redux.

The equal has taken place in Flutter: it gives some integrated strategies to control app state. In this article, we can study a few primary but effective approaches we will use to control state in our Flutter applications.

Using setState() 

If you return back from React, you'll discover that this approach for handling state in Flutter is just like the use of the useState Hook.

setState best manages the state withinside the widget wherein it changed into declared similar to in React, in which the useState hook manages nearby state best in the component wherein it changed into created. This form of state control is known as ephemeral state. Here, this state is managed by the use of StatefulWidget and the setState() method.


ChangeNotifier is the built-in class that offers the notifyListeners() technique to inform the changes to the listeners. The ViewModel both extends or mixes this class in order that it could notify the assets changes to the View layer. 

This is a completely easy answer if you have a small range of listeners. Adding or putting off a listener is O(N) operation and dispatching notifications is O(N²) operation.

Also, every time notifyListeners() is called, all its listener widgets get rebuilt even though the assets getting used in the widget aren't changed. One answer for that is to apply the subclass of it named ValueNotifier. We can wrap all of the properties of the ViewModel which can be uncovered for the View layer with the ValueNotifier. But there are higher solutions out there.

Using Provider

A Swiss Army Knife Provider is the ideal blender of Dependency Injection and State Management. It is usually the syntactic sugar across the InheritedWidget but has to provide lots extra than that. It’s been developed by Remi Rousselet, some other must-comply with Flutter enthusiasts. In fact, he has contributed different interesting applications as nicely which you could need to test out here.

I find this package because of the LCD (Least Common Denominator) in each Flutter app we've advanced so far.

In all the above techniques, we mentioned the communication mechanism among View and ViewModel layers. The provider comes into the picture even earlier than that. 

The key duties of the Provider are:

  • Create the instance of the ViewModel someplace in the widget tree under which the widgets want access (shared or direct)
  • Persist the ViewModel instance throughout the rebuilds
  • Provide the instance of the ViewModel from the tree while needed beneath.

Using Bloc

Designing the structure of an app is regularly one of the most closely debated subjects that arises in app development. Everyone appears to have their favorite architectural pattern with an elaborate acronym.

iOS and Android Developers are properly versed in Model-View-Controller (MVC), and feature used this pattern as a default preference while developing an app. The Model and View are separated, with the Controller sending signals among them.

Flutter, however, brings a brand new reactive style that isn't always completely compatible with MVC. A version of this classical pattern has emerged from the Flutter community – BLoC.

BLoC is a short form of  Business Logic Components. The gist of BLoC is that the whole lot in the app needs to be represented as a stream of events: widgets submit events; other widgets will respond. BLoC sits in the middle, handling the conversation. Dart even comes with syntax for working with streams that are baked into the language!

The high-quality component of this pattern is that you won’t want to import any plugins or research any custom syntax. Flutter already comes with the whole lot you want.

Using Redux

Redux is a structure with a unidirectional facts flow that makes it clean to increase applications which might be clean to check and maintain.

moves get processed with a reducer, which updates the store, this is used to refresh the UI, which can also issue movements

In Redux there may be a Store which holds a State object that represents the state of the complete app. Every application event  is represented as an Action that receives dispatched to a Reducer function. This Reducer updates the Store with a new State relying on what Action it receives. And on every occasion a new State is driven through the Store the View is recreated to reflect the modifications.

With Redux most components are decoupled, making UI modifications very clean to make. In addition, the simplest business logic sits in the Reducer functions. A Reducer is a characteristic that takes an Action and the current utility State and it returns a new State item, consequently it is simple to check because we will write a unit check that sets up an initial State and checks that the Reducer returns the new and changed State.

Using MobX

MobX is a state management library that makes it easy to attach the reactive data of your app with the UI (or any observer). This wiring is absolutely automated and feels very natural.

MobX helps the unidirectional data flow. From the View layer to Actions are dispatched to ViewModel. ViewModel processes the action and mutates the state of its properties which might be denoted as Observables. The modifications withinside the observable properties are automatically detected with the aid of using the View layer and widgets get rebuild handiest if necessary! The power of selective rebuilds lies withinside the Reactions. Reaction automatically tracks the observable properties utilized in it and handiest rebuilds the widget if one of these properties receives modified withinside the ViewModel.

Need a consultation?

Drop us a line! We are here to answer your questions 24/7.