Skip to content

Flutter Developers, Stop Discussion State Management

What is the best state management in Flutter? It doesn't matter.

Posted on:July 7, 2023
5 minutes

Today I’d like to present you with 5 different topics to discuss as a Flutter developer that is not related to state management.

The Flutter community has been stuck on state management since the beginning.

There are more important topics to discuss, that will have a bigger impact on your application’s architecture than state management.

State management is a single small piece of an application’s architecture

The 5 topics we’ll discuss today is:

Disregarding these topics can leave you with a code base that is difficult to maintain and scale into a team.

Simply thinking about these topics will push you toward making better decisions as your code grows during development.

Code File Structure

Align your code file structure with the mental programming model of your application. File structure includes:

When a decision on this is made, reinforce it during code reviews, and ensure there’s a basic guide in your readme that explains your final decisions and conventions you’ve chosen.

Flutter comes with a raw navigation solution. It takes quite a lot of work to make it maintainable and scalable in your code. If you use the navigation solution as-is you end up with code that has mixed responsibilities, no separation between UI, state, and business logic, and a set of manual route definitions you have to maintain. When deciding on navigation solutions I decide based on 2 questions:

Layers of Separation

Layers of separation define where you draw lines in the architecture of your software. I keep things very simple and use the technical names of the code instead of new names. I have 4 layers in my code:

Below is a graphic of how that might look when a user interacts with our system.


Dependency Inversion Principles

This is the most common principle I’ve come across in software architectures. The simple definition is, to get objects that your code depends on from outside of the object that needs it, instead of constructing it inside of the object. I wrote an technical post about it that you can read to get a better definition of dependency inversion.

Failure to think about this almost guarantees that your code will not be unit testable, which indicates that it’s tightly coupled to its internals. This means that changes in code can have effects on other parts of the system that you cannot possible see a connection between.

Select the option you feel most comfortable with. Use my technical post above to guide you on the matter.

Responsive UI Building Approach

Depending on how much attention you pay to your application’s design and appearance, you might have different designs for different screen sizes and even orientations. Choosing your responsive building approach is important. Basically there are 2 options and a hybrid that you can choose from.

By thinking through the 5 things mentioned above you can set yourself up for a good code base, and if you’ve already started with your code, these questions and ideas should point to you which topics you haven’t considered for your code base.

These topics are quite important to me, when I ran my agency I built a framework to easily set all this up in a few seconds which is publicly available for you to use. It’s called Stacked it covers all the topics above and in combination with the responsive_builder package you’ll have the exact stack I used to build my large client’s applications.

If you want to get these in your inbox, for our newsletter.

Also check out