MVVM in flutter for front-end app development – let’s talk scalability

MVVM is an architecture design pattern and stands for Model-View-ViewModel. MVVM in Flutter is one of the best-recommended architectures for building a front-end app. There is always a need to derive the best suitable architecture for an app, considering functional requirements, features, behavior, and some NFRs like codebase being scalable, maintainable, testable, secure, plug and play, etc.

But why does application architecture matter anyway for a business?

A reliable architecture ensures scalability, maintainability, and testability. A successful, thriving app business:

• Keeps plugging in and plugging out features with changing business and user needs.
• Adheres to new app store policies and new Mobile OS updates.
• Delivers quality releases bi-weekly/monthly.

Let us take a look at scalability with a real-world example. Have you ever wondered what is at the bottom of a Google search result? The answer is more search results. This is called infinite scrolling behavior with paginated data.

Let us examine how this happens with a Flutter MVVM architecture example. We will fetch data from GitHub REST API to display a list of all Tetris app repositories with infinite scrolling enabled (paginated search results). We will further plug out this feature as a future business use case and see how the MVVM architecture helps plug out (scale down) the infinite scroll feature. We will also cover the codebase at a high level and highlight some portions of the code in depth.

Before we get started, here are some pre-requisites:

• Knowledge of MVVM architecture.
• Build and run Flutter code.
• SOLID principles: S – Single Responsibility Principle (SRP), O – Open-Close Principle (OCP), L – Liskov Substitution Principle (LSP), I – Interface Segregation Principle (ISP), D – Dependency Inversion Principle (DIP).

Let us look at the Flutter projects folder structure:

The top-level folder (githublisting) signifies a business use case or epic. The folders under it are divided into three, resembling the terms Model, View, ViewModel.

• model folder – contains the code to make a REST API call and fetch data from the GitHub server.
• view folder – contains the UI code.
• viewModel folder – contains the presentation logic for the UI.

The third party libraries used are:

• infinite_scroll_pagination – 3.2.0.
• http – 0.13.3.

For infinite scroll behavior, we use two specific APIs – PagedListView widget and Pagingcontroller.

Now let us see a cross-section of the View, ViewModel, and Repository classes together.

The table above demonstrates the steps for wiring between the View, ViewModel, and Repository classes.

The details of the steps are as below:

Step 1: Initialize Repository class dependency in ViewModel

Step 2: Set PagingController’s addPageRequestListener in ViewModel’s constructor to respond to View’s pagination requests

Step 3: Add a getter method that returns PagingController Object to be consumed by the View class

Step 4: Create Async Call to the Repository class in addPageRequestListener

Initially, the list is loaded with the first set of items from GitHub API. As and when the user scrolls to the bottom of a list, a loading indicator is shown while next set of items regarding Tetris repositories gets fetched from Github API.

Let us see visually how the View, ViewModel, and Repository classes talk to one another.

PagedListView widget from the UI class sends a request to the ViewModel layer, which sends the request to the Repository layer to get the data from a REST API endpoint.

The wiring of all three layers of Model, View, and ViewModel will now respond to new pagination requests asynchronously.

PagingController, in combination with PagedListView, does two things under the hood.

• It understands if a user is scrolling toward the end of a page.
• It knows which page needs to be fetched next.

A downscaling business use case

Consider a future business use case where the pagination feature needs to be plugged out due to changing user needs. Only the first page is to be shown on the same screen, and no data is to be fetched when the user scrolls to the bottom of the list.

• We will remove the pagination library since the pagination feature is no more required.
• Modify view and viewmodel classes to use FutureBuilder.

Let us visualize how the View, ViewModel, and Repository classes talk to one another now.

Only the View and ViewModel classes were subjected to change. Still, the rest of the business logic for that epic remained unaffected.

Conclusion

Front-end app development is subjected to evolving business needs. With MVVM architecture used in front-end technology, such as Flutter, we can build modular apps that are scalable, testable, and performant with great agility.

Are you able to get the best out of your mobile apps? Nous mobility consultants enable you with mobile app development strategies based on Flutter or other cross-platform frameworks to help you deliver cost-effective, secure, customized, scalable Enterprise Mobility Solutions.