Flutter architecture: implementing the MVVM pattern

Why should you care?

If you’ve been into software development for some time, you’ve probably realized that at some point an app becomes so big that it's difficult to navigate through the code and make changes. That’s why you need to make correct choices about the structure of your code and how to separate responsibilities in a manageable, testable and scalable way, meaning choosing architecture. An additional benefit is that you will have common ground with other developers on what should be where just by looking at the code base structure.

MVVM in theory

There are quite a few architecture patterns out there. One of them is MVVM, which is my personal favorite for commercial projects. Of course, you need to calibrate the type of architecture, depending on what kind of app you’re going to build. For smaller apps MVVM may be unnecessarily complex.

I won’t go into MVVM theory and diagrams, I’m sure you can find very good materials explaining the concept. We will focus on implementation but here you can find the overall picture.

Choosing dependencies

When it comes to making decisions about dependencies for a project, I’m trying to add as few libraries as possible and as least intrusive as possible. In my opinion, it’s a problem if one of the dependencies starts dictating how you develop your app. That’s why I don’t like state management libraries. What will happen if the library is no longer developed or if it changes philosophy in a way that does not suit your needs? Of course it’s your judgment call on how much you are willing to invest in one of the libraries and how they think stuff should be done.

With that in mind, this is the list of libraries that I like to use:

• Provider for implementing state management,
• Get_it with Injectable for dependency injection,
• Equatable as syntax sugar to help us work with equals.

Yes! That’s it, you don’t need any more and you’re probably already using those. I won’t be going into details of how they work as there are already many great tutorials and guides out there.

What are we going to implement?

Simple todo app, a classic one, that shows an implementation in the example that is scalable, testable, maintainable with separated responsibilities.

mvvm_app_overview from Damian Moliński

Let’s code!

First things first. Let’s define our base classes to work with state management and loop of Screen (StatefulWidget), StateData (Equatable Class) and ViewModel (ValueListenable).

As you can see, simple abstraction only requires the implementation of Equatable, so we can enforce correct equals behavior.

The role of ViewModel is to keep all of the business logic inside of it and only expose data needed by the screen to render itself. The goal is to make the screen (widget) as “stupid” as possible so it only knows how to render stuff and shouldn’t care about the origin of that data (if it came from API or DB, or any other place). In order to achieve that, we’re going to leverage the ValueListenable interface that screen can listen to and redraw whenever StateData changes.

Luckily, we can use another wonderful class: ValueNotifier. It also implements ValueListenable so it can play a role of delegate for our ViewModel. Additionally, it makes sure that no unnecessary redraws will take place thanks to its implementation of the set value property. Take a look at this snippet: that’s why StateData needs to implement Equatable so this part can work properly.

Let’s move to screen (AKA StatefulWidget).

Again, nothing complex going on here. We’re creating ViewModel inside initState, disposing it later at dispose, so we can “clean up”. The important part is happening inside the build method because this is where each screen will expose StateData for its widgets so they can draw the base from that information. 

Don’t worry about ViewModelFactory for now. We’ll come back to dependency injection later.

Ok, let’s take a look at how we can use those classes to implement the first screen – the list of todo items.

We’ll make it in the right order: from defining StateData to implementing ViewModel which can provide that StateData to a Screen that knows how to render StateData.

Please notice that we’re not saying for example – isLoading – but showLoading. It’s not the same. Remember that we’re trying to make the screen know as little as possible. The screen shouldn’t care if we’re fetching data from API or DB. Its only concern is whether Progress should be rendered or not! It’s important.

Now let’s move to HomeViewModel in its entirety and then we can talk about the particularly important parts.

An interesting bit is the _updateState function. Notice how all parameters are optional so you can update only parts like in _updateList. This is also the only place where stateData is created and here we can keep business logic for the screen.

Now it’s time for Screen. I’d like to start with implementing smaller components to then put everything together. We do have 3 properties in HomeData so we will need at least 3 widgets that depend on them. But how do we access HomeData? With Selector from Provider! Let’s take a look.

Selector from HomeData that selects bool is all you need. Implementing builder is as simple as wrapping the CircularProgressIndicator inside the Visibility widget which depends on the selected value from our state. That’s it!

Dependency injection

How do we create the ViewModel? Everything is based on the combination of 3 packages: provider, get_it and injectable. As you saw HomeViewModel is marked with @injectable which means that injectable can provide it to get_it which knows how to create instance of that type but to make the example of the above work, we need to implement two more classes: 

1. ViewModelFactory for creating ViewModel instances
2. GlobalProvider so Screen can access ViewModelFactory from BuildContext.

ViewModelFactory is as simple as asking get_it to create the following instance:

and GlobalProvider is a widget we’re wrapping the entire app with for easy context access.

Please take a look at the entire project in the link below, it will clarify a lot of things.

Conclusion

Hopefully, after reading this article you will think twice before adding a state management library to your flutter project. 

Ask yourself a question: Do I really need a library? Am I willing to let it dictate how to structure my code? Sometimes the answer is yes, but this is not the only answer possible. Freedom of implementation is really important in the long run and this approach gives you as much freedom as possible.

Bonus

Here is the full project code for you to take a look: MVVM_APP.