Introduction to Flutter State Management

As Bob continues this article series on Mobile App development from an Embedded System's perspective, he tackles State and State Management in Flutter. As you will see, it is very different from what embedded engineers are used to when we think of state and that misunderstanding can cause no end of trouble if we don't understand it.

- By Bob Japenga

Over the years, I found that designing embedded systems using state machines to be a useful and powerful paradigm. There are different methods of implementing a state machine (Complete code for these is found in the Resources for this article): a table of function pointers indexed by the state (see Figure 1 for a code snippet); the “switch-case” method (see Figure 2 for a code snippet); or when using an object oriented language like C++, you can encapsulate each state in a class to represent the state and it's transitions (see Figure 3).

However, my hubris in thinking I was well versed in state machines did not prepare me for understanding state in either React Native or Flutter. As you may remember, I had two major problems with React Native: how it managed concurrency; and how it managed state. No surprise here. The same thing happened with Flutter, so let's start defining terms and see if we can unravel the mystery of states and state management in Flutter.

Everything in Flutter is made up of Widgets. And there are two kinds of Widgets: State less widgets and Widgets that change based on the state of the User Interface (UI). These are called appropriately StatelessWidgets and StatefulWidgets respectively. But wait! What do they mean by state?

REACTIVE/DECLARATIVE VS IMPERATIVE UI