Note: I have moved my flutter app design writing to my substack which is free to subscribe at:
Fred's Flutter Newsletter | Fred Grott | Substack
Google Flutter GDEs are not doing this and the CodeLabs code demos fail at this. Simply showing how to fill the…
If I was a developer and design advocate at Google, this is the Flutter State Management Guide I would write for the Flutter SDK documents. I just happen to have more time and more expertise at getting to the heart of the matter.
This is the developer side of what you need to master, and of course at a later time I will cover the design side you need to know to get hired as a Flutter App developer. Now, onward to Flutter State Management!
The Observer Pattern
State management in Flutter is not the Dart OOP state pattern:
As that only holds state but leaves state management wide open to solve. Instead, the OOP pattern of observer is where we start our Flutter State Management journey. This is the plain vanilla Dart OOP observer pattern:
The general problems with this are how we use it widgets, as the way widgets have been implemented with both stateless and stateful widgets is a mutable way of widget replacement in the widget tree to render the configuration changes. This means that it leak prone if we do not dispose of the observer part if the observer is also mutable.
Thus, the Google Flutter SDK team came up with a specialized observer component called notifiers that dispose listeners to avoid memory leaks: