The last word on Flutter Architecture 😉

[escamoteur]

Some of you who are as long around in the community as I am know that I have published and talked about Flutter architecture in the past a lot and that I wasn’t super happy about the recommendations from the Flutter Team on architecture.

Here is my updated view on how you can structure a Flutter app

Flutter Architecture Simplified

[Nacho]

Very interesting thank you!

As a noob (as I still am), the overload of approaches and tutorials out there regarding architecture can be really confusing (and overcomplicated). The fact that some concepts are used in different ways, makes things even harder to understand.

What I take for me from it all, is ‘don’t copy things without understanding them’, ‘do what it works for you while you understand what you do’, and ‘ask politely for help if you hit a wall, the flutter community is generous and supportive’.

I can understand your pragmatic approach, so thanks @escamoteur !

[pvg]

I enjoyed your article but had to laugh at your use of the term “Manager.” I’m always dealing with students who want to call classes “Managers” when they don’t know what the classes actually do. That is, these are classes that accrue responsibilities rather than maintain a single clear one.
I’m pleased to see that you have defined your term, but I can’t help but wonder if there’s another name for the concept.
Again, thanks for the article. I look forward to trying your approach.

[escamoteur]

I know what you mean, but I honestly found no better term for it. They manage certain aspects of your business logic. Therefore they can be more than just repositories. Controllers would be another possibility but we already use controllers for Animations, Scrolling or Textfields.
So I think Manager is good term.

[escamoteur]

great to see my article on architecture on fire in reddit
https://www.reddit.com/r/FlutterDev/s/nSreqrZQs0

In case, you missed it