Summary

The web content presents Fred Grott's personal architecture layout for the lib folder in Flutter app projects, emphasizing a clear approach to state management and reactive implementation, with a focus on debunking the myth that Flutter is solely an application framework and providing a structured layout for better architectural decisions.

Abstract

Fred Grott introduces his custom architecture layout for organizing the lib folder of Flutter applications, aiming to simplify state management and reactive programming. He argues that Flutter, contrary to popular belief, is not just an application framework but requires a well-thought-out architecture to handle both view-state and domain-state effectively. Grott's layout is designed to separate concerns by categorizing files into directories such as app, data, modules, screens, shared, etc. This structure is intended to facilitate the identification and resolution of architectural challenges, particularly in managing the reactive nature of Flutter applications. He also provides resources, including his GitHub repository flutter_rose_glasses, which contains code samples and will accompany his upcoming book on Flutter application development and design.

Opinions

Grott believes that Flutter's reactive nature complicates state management by mixing business logic with state-container widgets, which he sees as a problem to be addressed.
He suggests that the term "managers" is more appropriate than "controllers" or "presenters" for stateful widgets in Flutter, as they better represent the mixed role of business logic and state management.
Grott emphasizes the importance of a clear architecture layout to make informed decisions about which patterns and techniques to use for state management and reactive programming.
He points out that the command architecture pattern is not suitable for Flutter due to the lack of control over the rendering view event.
Grott's approach to architecture is pragmatic, focusing on the practical benefits of organizing code in a way that exposes the most pressing issues to be solved in application development.
He acknowledges the importance of capturing both direct and indirect events from the state-container widget to maintain an accurate "event-truth" of the application, which is crucial for debugging and designing application behavior.
Grott's work is not prescriptive; it offers a suggested lib folder structure that highlights architectural problems worth solving, rather than dictating specific architecture patterns to use.
He is collecting all his Medium article sample code in a centralized repository to make it easily accessible for developers, enhancing the learning experience and providing practical examples.

An Architecture Layout

I am showing my own architecture layout for the lib folder of my flutter app projects and getting in-depth into how Flutter implements reactive. You will find my layout an easy way to keep clear-headed about all the state management and architecture implementations and solutions.

The Source

Both the fapp_template and the fproject_layout are git-submoduled in my flutter_rose_glasses git repo at:

https://github.com/fredgrott/flutter_rose_glasses

The fapp_template git-repo is just the standard flutter app template create output. The fproject_layout is then the lib architecture layout and the rest of my standard flutter project set-up. And, I will go over the rest of my project setup in another article.

To see what work is ahead I have to destroy a Flutter Myth.

The Biggest Flutter Myth

The biggest Flutter Myth is that it’s an Application Framework. What does that mean?

All reactive front end frameworks have this problem of how to handle and manage two different state event groups:

App = UI(view-state) + UI(domain-state)

View-State is just the event states connected to an individual view; whereas, domain-state is the full application state.

Google in its implementation of Reactive complicates this, let me show you how.

Google’s Implementation Of Reactive In Flutter

So now you might understand why I am showing the code from the standard flutter app template:

In widgets, we only have final fields as everything is to be immutable, which is one of the foundations of reactive in that it’s the new instance that reacts and changes. Where then is the new instances of the counter variable set up then?

It’s set up in a state-container that happens to be of the stateful-widget type. That means that the business logic is mixed up in a state-container widget. And, yes that is a problem as well as we have to move the business logic out of the state-container widget.

Because Flutter is not an application framework we have no implied application architecture and do not know what every architecture implementation and technique we will use to solve these problems.

What is the architecture layout I came up with for the lib-source-folder?

The Layout

The layout I came up with is generally this:

lib/main.dart

  app/

    data/

      models/

         counter_mixin.dart
      repositories/

      services/

    modules/
      my_app.dart

    routes/

    screens/

        myhomepage/

          views/

          managers/
            my_homepage.dart

         statecontainers/

           my_homepage_state.dart

     shared/
     themes/
     translations/

Because we only have the state configuration in a stateful widget and the business logic mixed up in the state-container widget; we cannot call the stateful widget a controller or presenter. Hence, the use of term managers.

It makes more sense to have the pages of the app defined as screens than modules and then define modules as the app module that sets up the app themes of the application.

Then we have global stuff grouped into their own category such as themes, translations, and shared.

The Benefits

One of the benefits is that one can see more clearly the low-hanging fruit in what one should implement in architecture choices. An example is using a mixin as a cheap way to enforce, indirectly, the contract of the model counter starting at zero.

The second benefit is that you get a more clear picture of the work ahead in the architecture implementation choices one has to make. In this case, it goes back to this original reactive equation:

App = UI(view-state) + UI(domain-state)

We do not have any direct method of observation to know when rendering a view changes the state of the view or state of the full application. Our architecture implementation choices then become one of how accurate and useful we can make the state-event record in representing both the view-state and domain-state changes reflecting the full event details of the application.

Because we already know that this is a framework where we do not control the rendering view event; then it becomes apparent that the command architecture pattern is not a useful pattern to use in solving such problems.

In other words, if we better organize how we capture the direct and indirect events generated from the state-container widget then we will reach the goal of our architecture implementation in having an accurate event-truth of the application. The not only impacts debugging the behavior of the application but also the planning and design of the application behavior.

Conclusion

This is not a suggestion about what architecture patterns you should use. It’s only a suggested layout of the lib-source folder that you can see what problems are worthwhile to solve in methodically caring about the architecture patterns and choices you have to make in your application development process.

I should mention that I am collecting all my Medium.com article sample code at

fredgrott/flutter_rose_glasses

This is the companion repo to my Medium Articles and the upcoming Flutter Application Development and Design book…

github.com

Every code sample is git-submoduled, so you do not have to go searching for it. At, the same time; my sample apps for my first flutter application development book called, Flutter Through Rose Glasses, will be posted there.

Because, Flutter is not an Application Framework; you can expect me to cover architecture-and-state-management-patterns such as Cubit, Provider, Bloc, Riverpod, GetX, and many other solutions as I ramp up to pushing out my first flutter development book.

Resources

flutter rose glasses https://github.com/fredgrott/flutter_rose_glasses

General Flutter and Dart resources:

Flutter Community Resources https://flutter.dev/community

Flutter SDK https://flutter.dev/docs/get-started/install

Android Studio IDE https://developer.android.com/studio

MS’s Visual Studio Code https://code.visualstudio.com/

Flutter Docs https://flutter.dev/docs

Dart Docs https://dart.dev/guides

Google Firebase Mobile Device TestLab https://firebase.google.com/docs/test-lab

Trademark Notice

Google LLC owns the following trademarks; Dart, Flutter, Android, Roboto, Noto. Apple Inc owns the trademarks iOS, MacOSX, Swift, and Objective-C. Apple Inc owns trademarks to their fonts of SF Pro, Sf Compact, SF mono, and New York. JetBeans Inc owns the trademarks to JetBeans, IntelliJ, and Kotlin. Oracle Inc owns the Java trademark. Microsoft Inc owns the trademarks of MS Windows OS and Powershell. Gradle is a trademark of Gradle Inc. The Git Project owns the trademark to Git. Linux Foundation owns the trademark of Linux. Smartphone OEM’s own trademarks to their mobile phone product names. To the best of my ability, I follow the brand and usage guidelines with the above-mentioned trademarks.

About Fred Grott

I’m the crazy SOB who as a former android mobile developer is starting to write about flutter mobile app development, design, and life(see Eff COVID-19 and GOP ). Will I reach the pivotal One Million Medium monthly viewers mark? Sit back and watch. Find me on social platforms such as Xing, LinkedIN, Keybase, and Twitter.