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.