Widget-Async-Bloc-Service: A Practical Architecture for Flutter Apps
Difficulty level: Intermediate/advanced. All opinions are my own.
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
ChangeNotifierto 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:
The Widget-Async-BLoC-Service Pattern
Shorthand: WABS (which is cool because it contains my initials :D)
This architectural pattern comes in four variants.
NOTE: aside from the Widget item, the BLoC and Service items are both optional.
In other words: you can use or omit them as appropriate on a case-by-case basis.
Now, let’s explore the full implementation with a more detailed diagram:
First of all, this diagram defines three application layers:
- The UI layer: this is always necessary as it is where our widgets live.
- The data layer (optional): this is where we add our logic and modify state.
- The service layer (optional): this is what we use to communicate to external services.
Next, let’s define some rules for what each layer can (and cannot) do.
Rules of play
This is where we put our widgets.
Widgets can be stateless or stateful, but they should not include any explicit state management logic.
An example of explicit state management is the Flutter counter example, where we increment the counter with
setState() when the increment button is pressed.
An example of implicit state management is a
StatefulWidget that contains a
TextField managed by a
TextEditingController. In this case we need a
TextEditingController introduces side effects (I discovered this the hard way), but we are not managing any state explicitly.
Widgets in the UI layer are free to call sync or async methods defined by blocs or services, and can subscribe to streams via
Note how the diagram above connects a single widget to both the input and output of the BLoC. But we can use this pattern to connect one widget to the input, and another widget to the output:
In other words, we can implement a producer → consumer data flow.
The WABS pattern encourages us to move any state management logic to the data layer. So let’s take a look at it.
In this layer we can define local or global application state, as well as the code to modify it.
This is done with business logic components (BLoCs), a pattern first introduced during DartConf 2018.
BLoC was conceived to separate the business logic from the UI layer, and increase code reuse across multiple platforms.
When using the BLoC pattern, widgets can:
- dispatch events to a sink
- be notified of state updates via a stream
According to the original definition, we can only communicate with BLoCs via sinks and streams.
While I like this definition, I find it too restrictive in a number of use cases. So in WABS I use a variant of BLoC called Async BLoC.
Just like with BLoCs, we have output stream(s) that can be subscribed to.
However, the BLoC input(s) can include a synchronous sink, an asynchronous method, or both.
In other words, we go from this:
The asyncrhonous method(s) can:
- Add zero, one or more values to the input sink.
- Return a
Future<T>with a result. The calling code can
awaitfor the result and do something accordingly.
- Throw an exception. The calling code can detect this with
try/catchand show an alert if desired.
Later on, we will see a full example of how useful this is in practice.
More on BLoCs
An Async BLoC can define a
Stream pair, or the equivalent
Observable if using RxDart.
If we want, we can even perform advanced stream operations, like combining streams with
combineLatest. And just to be clear:
- I recommend having multiple streams in a single BLoC if they need to be combined in some way.
- I discourage having multiple
StreamControllers in a single BLoC. Instead, I prefer breaking up the code in two or more BLoC classes, for better separation of concerns.
Things we should/shouldn’t do in the data layer / BLoCs
- BLoCs should only contain pure Dart code. No UI code, no importing Flutter files, or using a
- BLoCs should not call 3rd party code directly. This is the job of service classes.
- The interface between Widgets and BLoCs is the same as the interface between BLoCs and services. That is, BloCs can communicate directly with service classes via sync/async methods, and be notified of updates via streams.
Service classes have the same input/output interface as BLoCs.
However, there is one fundamental distinction between services and BLoCs.
- BLoCs can hold and modify state.
- Services can’t.
In other words, we can think of services as pure, functional components.
They can modify and transform data they receive from 3rd party libraries.
Example: Firestore service
- We can implement a
FirestoreDatabaseservice as a domain-specific API-wrapper for Firestore.
- Data in (read): This transforms streams of key-value pairs from Firestore documents into strongly-typed immutable data models.
- Data out (write): This converts data models back to key-value pairs for writing to Firestore.
In this case, the service class performs simple data manipulation. Unlike BLoCs, it doesn’t hold any state.
A note about terminology: Other articles use the term Repository when referring to classes that talk to 3rd party libraries. Even the definition of the Repository pattern has evolved over time (see this article for more info). In this article, I don’t make a clear distinction between Service and Repository.
Putting things together: the Provider package
Once we have defined our BLoCs and services, we need to make them available to our widgets.
I really like its simplicity. Here is how to use it to add an authentication service:
And this is how we could use it to create a BLoC:
Note how the
Provider widget takes an optional
dispose callback. We use this to dispose BLoCs and close the corresponding
Provider gives us a simple and flexible API that we can use to add anything we want to our widget tree. It works great with BLoCs, services, values and more.
I’ll talk in more detail about how to use
Provider in some of my upcoming articles. For now, I highly recommend this talk from Google I/O:
A real-world example: Sign-In Page
Now that we have seen how WABS works conceptually, let’s use it to build a sign in flow with Firebase authentication.
Here is a sample interaction from my Reference Authentication Flow with Flutter & Firebase:
A few observations:
- When sign-in is triggered, we disable all buttons and show a
CircularProgressIndicator. We set a
trueto do this.
- When sign-in succeeds or fails, we re-enable all buttons and restore the title
Text. We set
loading=falseto do this.
- When sign-in fails, we present an alert dialog.
Here is a simplified version of the
SignInBloc used to drive this logic:
Note how the public API of this BLoC only exposes a
Stream and a
This is in line with our definition of Async BLoC.
All the magic happens in the
signInWithGoogle() method. So let’s review this again with comments:
Just like a normal BLoC, this method adds values to a sink.
But in addition to that, it can return a value asynchronously, or throw an exception.
This means that we can write code like this in our
This code looks simple enough. And it should be, because all we need here is
And yet, this is not possible with the “strict” version of BLoC that only uses a sink and a stream. For reference, implementing something like this in Redux is… uhm… not fun! 😅
Async-BLoC may seem like a small improvement to BLoC, but it makes all the difference.
A note on handling exceptions
By the way, another possible way of handling exceptions would be to add an error object to the stream, like so:
Then, in the widget class we could write code like this:
However, this is bad for two reasons:
- It shows a dialog inside the builder of the
StreamBuilder. This is not great because the builder is only supposed to return a widget, and not execute any imperative code.
- This code lacks clarity. The place where we show the error is completely different from the place where we sign in.
So, don’t do this, and use
try/catch as shown above. 😉
Can we use WABS to create an
Of course. As I said before:
- BLoCs can hold and modify state.
- Services can’t.
However, their public-facing APIs obey the same rules.
Here’s an example of a service class for a database API:
We could use this API to write and read data to/from Cloud Firestore.
The calling code could define this method to write a new
Job to the database:
Same pattern, very simple error handling.
Comparison with RxVMS
In this article, I have introduced Widget-Async-BLoC-Service as an adaptation of existing architectural patterns in Flutter.
WABS is most similar to the RxVMS pattern by Thomas Burkhart.
There is even a close match between the individual layers:
The main differences between the two are that:
- WABS uses the Provider package, while RxVMS uses the GetIt service locator
- WABS uses simple
asyncmethods to handle UI events, while RxVMS uses RxCommand.
RxCommand is a powerful abstraction to handle UI events and updates. It removes the boilerplate code required to create a
Stream pair with BLoCs.
It does however come with a bigger learning curve. For my use cases Async-Bloc does the job and is simpler, despite a bit of extra boilerplate.
I also like that WABS can be implemented without any external libraries (aside from the Provider package).
Ultimately choosing one or the other depends on your use cases, but also personal preference and taste.
Should I use BLoCs in my apps?
BLoCs come with a steep learning curve. To understand them, you need to also be familiar with Streams and
When working with streams, there are various considerations to make:
- what is the connection state of the stream? (
- is the stream single or multiple subscription?
StreamSubscriptionalways need to be disposed
- dealing with nested
StreamBuilders can lead to thorny debugging issues when Flutter rebuilds the widget tree
All of this adds more overhead to our code.
And when updating local application state (e.g. propagating state from one widget to another), there are simpler alternatives to BLoC. I plan to write about this on a follow-up article.
In any case, I found BLoCs very effective when building realtime apps with Firestore, where the data flows from the backend into the app via streams.
In this scenario, it is common to combine streams or perform transformations with RxDart. BLoCs are a great place to do this.
This article was an in-depth introduction to WABS, an architectural pattern that I have been using for some time in multiple projects.
Truth be told, I have been been refining this over time, and I didn’t even have a name for it until I wrote this article.
As I said before, architectural patterns are just tools to get our job done. My advice: choose the tools that make more sense for you and your projects.
And if you use WABS in your projects, let me know how it works for you. 😉
The example code from this article was taken from my Reference Authentication Flow with Flutter & Firebase:
In turn, this project complements all the in-depth material from my Flutter & Firebase Udemy course. This is available for early access at this link (discount code included):
- Provider package
- Pragmatic State Management in Flutter (Google I/O’19)
- RxVMS a practical architecture for Flutter Apps
- RxVMS foundations: RxCommand and GetIt
- Flutter / AngularDart — Code sharing, better together (DartConf 2018)