Widget-Async-Bloc-Service: A Practical Architecture for Flutter Apps

Last updated 138 days ago by Andrea Bizzotto

flutter

Introduction

State management is a hot topic in Flutter right now.

Over the last year, various state management techniques were proposed.

The Flutter team and community have not (yet) settled on a single “go-to” solution.

This makes sense, because different apps have different requirements. And choosing the most appropriate technique depends on what we’re trying to build.

Truth be told, some state management techniques have proven very popular.

  • Scoped Model is known for its simplicity.
  • BLoCs are also widely used, and they work well with Streams and RxDart for more complex apps.
  • Most recently at Google I/O, the Flutter team showed us how to use the [Provider](https://pub.dev/packages/provider) package and [ChangeNotifier](https://api.flutter.dev/flutter/foundation/ChangeNotifier-class.html) to propagate state changes across widgets.

Having multiple choices can be a good thing.

But it can also be confusing. And choosing a technique that will work and scale well as our apps grow is important.

What’s more, making the right choice early on can save us a lot of time and effort.

My take on state management and app architecture

Over the last year I’ve been building a lot of Flutter apps, big and small.

During this time, I have encountered and solved many problems.

And I have learned that there is no silver bullet for state management.

However, after building things and taking them apart over and over, I have fine-tuned a technique that works well in all my projects.

So in this article I introduce a new architectural pattern that I have defined by:

  • borrowing a lot of ideas from existing patterns
  • tweaking them to suit the needs of real-world Flutter apps

Before we see what this pattern looks like, let me define some goals.

This pattern should:

  • Be easy to understand, once the fundamental building blocks are clear
  • Be easy to replicate when adding new features
  • Build upon clean architecture principles
  • Work well when writing reactive Flutter apps
  • Require little or no boilerplate code
  • Lead to testable code
  • Lead to portable code
  • Favour small, composable widgets and classes
  • Integrate easily with asynchronous APIs (Futures and Streams)
  • Scale well with apps that increase in size and complexity

Out of the existing state management techniques for Flutter, this pattern builds most heavily on BLoCs, and is quite similar to the RxVMS architecture.

Without further ado, I am pleased to introduce:

Read full Article