Writing Easy to Understand, Easy to Test, and Robust Flutter App

4 min readApr 6, 2023

There main ideas of this articles are:

Draw state machine diagram so we can visualize the flows of our app
Implement the state machine diagram into code using State Design Pattern to build a robust app
Write widget tests based on the state machine diagram

Let’s ride!

Start with the State Machine
Before writing any code, we should start with drawing the state machine diagram. The diagram will help us to visualized the flows of our application.

To draw a state machine we can have many choices but from all those choices I have tried two ways that easy to setup and used:

Using Plantuml plugin in Visual Studio Code
Using Mermaid plugin in Visual Studio Code

Using Plantuml plugin in Visual Studio Code
To use the plugin we also needs to install graphviz java package. To install it we can follow the instruction from their website. I followed their instruction to install the package using homebrew since I am a Mac user and it was very smooth. The plugin works flawlessly after that and this plugin also offers the ability to zoom the diagram, this is one strong point that is not offered by the Mermaid plugins.

Using Mermaid plugin in Visual Studio Code
This plugin is the fastest one to setup. We just need to install the plugin from VSCode market and after that we can start drawing any diagrams in a markdown file using mermaid code section. Onfortunately there are no plugins that offered the ability to zoom but the strength point is the diagram can be displayed by Github’s. You can see the diagram in this article repo here.

Based on the state diagrams above, you can easily visualize and understand the whole app flows.

Implementing the State Diagram Into Code
We can have many choices to implement the state diagram in our code. One of it is to use State Design Pattern. The whole idea of the pattern is to create a class of each boxes (or states) from the diagram into its own class and all of the class will have the state’s transitions actions as methods.

The subclasses now can respond to each states actions by following the state diagram. For instance, the AppStateStart will have to respond to appLaunched action and transition the state machine to DisplaySplashScreen state:

And the AppStateDisplaySplashScreen will have to respond to several actions and change the states:

Since each states class can choose how to respond then the diagram can be implemented strictly so we will have a robust state machine as shown on the diagram.

One very important note is, we need to sync between the substates to the parent state. For instance, in the DisplayLoginScreen state it has substates:

So the parent state needs to listen to the substates changes and once the substate has moved to their final state then it needs to trigger an action based on the substates values: