State Management With Provider

The Flutter team recommends that beginners to Flutter development use Provider for state management. But what is Provider exactly, and how do you use it?

Provider is a UI tool. If you’re confused about the differences between architecture, state management and UI tools, you’re not alone. This tutorial will help you understand the concepts and give you a blueprint for building real apps. It might even help you become a millionaire in the process!

In this tutorial, you’ll learn the ins and outs of managing states with Provider by creating a currency exchange app called MoolaX. While building this app, you’ll elevate your Flutter development skills from beginner to intermediate level by learning how to:

• Architect your app.
• Implement a Provider.
• Manage app state like a pro.
• Update the UI based on app state changes.

Getting Started

Download the project by clicking the Download Materials button at the top or bottom of the page. You’ll learn more from this tutorial by following along step-by-step than you will if you only read through it.

This tutorial uses Android Studio, but Visual Studio Code will work fine as well.

Moola X will let you select and convert between different currencies. Here’s what it will look like when you’re done:

Open the starter project by navigating to the starter folder and clicking Get dependencies when Android Studio prompts you to do so.

The starter project already includes some code so you can finish this project in a single tutorial. However, the tutorial will walk you through how to create each part so that you can follow the same pattern when you make your own apps.

Run the app now and you’ll see this:

It doesn’t do much yet.

But before you add some code, first some theory on the purpose of Provider. :]

Architecting Your App

If you haven’t heard about the principles of clean architecture, please read about them before continuing.

The goal is to keep core business logic separate from the UI, database, network and third-party packages. Why? The core business logic doesn’t change frequently, while all the others often do.

The UI shouldn’t communicate directly with the web. You shouldn’t scatter direct calls to the database across your app. Everything goes through the business logic from a single location.

What does this mean? It gives you a plug-in architecture. You can swap one database framework for another and the rest of the app doesn’t even know there was a change. You can replace your mobile UI with a desktop UI and the rest of the app doesn’t care. This is useful for making scalable, maintainable and testable apps.

State Management and Provider

The Moola X app architecture follows this principle. The business logic in the middle handles the calculations related to currency exchange. Local storage, the web API, and the UI along with Flutter and Provider, are all completely separate from the business logic and from one another.

The local storage uses shared preferences, but that’s an implementation detail that doesn’t affect the rest of the app. Likewise, where the web API gets its data doesn’t matter to the rest of the app.

This next part is important to understand: The UI, Flutter, and Provider are all contained in one part of the app. Flutter itself is a UI framework and Provider is a widget for that framework.

Is Provider the architecture? No.

Is Provider the state management? No, not in this app anyway.

The state is the current value of the app’s variables. These variables are part of the business logic, grouped and managed by model objects. Thus, the business logic manages the state, not Provider.

So, what is Provider?

It’s a state management helper. It’s a widget that makes some value – like a state model object – available to the widgets below it.

A Consumer widget, which is also part of the Provider package, listens for changes in the value and then rebuilds the widgets below itself when changes occur.

See the Manage State with Provider video series for a fuller explanation of state and Providers. There are many different kinds of Providers, most of which are outside the scope of this tutorial.

Communicating With the Business Logic

This tutorial follows an architectural pattern inspired by FilledStacks. It separates the architecture cleanly without being overly complicated.

Furthermore, this tutorial simplifies the setup to make it more accessible to beginners.

For communication between the UI and the business logic, the architecture is similar to MVVM (Model View ViewModel).

The model is the data from a source like a database or the web. The view is the UI, like a screen or widget. The view model is the business logic sitting between the UI and the data. It provides data in a form that the UI can present, but it knows nothing about the UI itself. This differs from the MVP architecture. The view model also doesn’t know where the data comes from. That’s abstracted away.

In MoolaX, each screen will have its own view model. The data will come from both the web and local storage. Classes to handle that are called services because they do some work for the business logic.

Here is a diagram that closely resembles the architecture of Moola X.

Note these points:

• The UI screens listen for changes in the view models. They also send events to the view models.
• The view models don’t know any details about how the UI looks.
• The business logic interacts with an abstract currency service. It doesn’t know anything about the local storage or the web. This type of architecture is sometimes called a data repository.

Enough theory. It’s time to make this app!

Creating the Core Business Logic

Take a look at the project folder structure in Android Studio (be sure to choose the Project view in the Project pane and not the Android view):

Note that the main folders, business_logic, services and ui closely mirror the architectural diagram that you saw above.