Flutter. MVP.

Since the last article, I finished several new proofs of concept (POCs) and learned more about Flutter and Clean Architecture.

Although Clean Architecture is a universal approach that can be successfully implemented on every platform, Flutter, with the flexibility of Dart, makes working with it a real pleasure. In this article we’re discussing the “presentation” layer in Clean Architecture. I prefer implementing it with the Model-View-Presenter (MVP) pattern.

For this post, I’m taking code from Getting Your Hands Dirty with Flutter: Project Setup + Authorization. We’re rewriting it to fit the MVP standards, thus avoiding the vexing process of creating UI.

The full code from this article is available here. Now let’s see how I wrote it.

We start with a basic screen state, the one discussed in the article about basic Flutter animations. It handles the app header, which is inherited by all the other screens. However, the previous implementation wasn’t abstract enough, so I replaced class properties with abstract methods. Here’s how it looks now:

Let’s implement an MVP module of the authorization screen. The first step is to implement Contract, but Dart doesn’t have such categories as interface and protocol, so we’re doing it with abstract classes:

As you can see, the View of Contract includes:

• two abstract methods to build the initial UI and show informational pop-ups
• three abstract getters for text editing controllers
• two abstract setters for the callback (invoked when buttons are clicked)
• one abstract setter for the binding object of state properties.

Presenter contains the init View method for the initial UI setup (which we mentioned before) and two action methods.

Now let’s see how we’re using View and Presenter instances in the Stateful Widget, a.k.a. the authorization screen.

As you might remember from the article about authorization, we held all state properties directly in the State class. However, this won’t work for MVP. Instead, I created a new Auth State Properties object, which is added to State and View through composition in order to initialize and update UI.

Let’s take a look at the Screen state implementation:

Magic happens within the void initState() method, where we initialize View with BuildContext and State Properties, and Presenter with an instance of View and the State itself.

Now, View and Presenter have full management of UI and handle all user interactions.

Pay attention to the presenter.initView(this)() method. As it returns VoidCallback, we’re seeing JavaScript-like syntax.

The last thing left to do is pass the built-in View to the Stateful Widget screen. You can see it done in the Widget content() method, where we’re invoking view.buildContent().

Take a look at actual implementations of Contract instances:

The implementation of View is simple, and you might be used to it from dealing with MVP in general. We’re:

• setting up callbacks for the buttons clicked
• setting up listeners for input changes
• building an API to update UI and show informational pop-ups.

The implementation of Presenter is a bit trickier:

Note the VoidCallback initView(SignInState state) method, which you’ve already seen in the State object. We’re making the initial UI setup by assigning values to state properties and using proper functions to setup user interaction callbacks.

You can see the void toggle() and void confirm() methods invoked with user actions. They are updating UI with the void reState(VoidCallback callback) method and should communicate with the Model. However, proper implementation of the “domain” and “data” layers is a matter of a whole other post, so we’re not looking into it today.

In the end, we have a small, easy to read, reuse and expand module. I should say that the code snippets in this post are my own take on the MVP implementation in Flutter, and I will really appreciate any suggestions or remarks you might have about them.

As for the question whether I would personally use MVP in a real Flutter app, the answer is that I might, but not very often. The thing is, MVVM in combination with either Stream Builders or MVI is a more natural integration for the Flutter’s infrastructure.

Thanks for reading, and I hope you found something useful. Please, comment below if there’s a particular topic in Flutter that you’d like me to cover.