DEV Community: Nour El-Din Shobier

Intro to MVVM architecture in Flutter using PMVVM package

Nour El-Din Shobier — Tue, 24 Aug 2021 20:28:21 +0000

Flutter is easy to pick up and start with coding. For small projects, low-quality code will not be a problem for the team, but as the codebase of the project increases over time, you will end up with complicated classes, code duplicates, and views containing business logic. Therefore, it's important to utilize architectural patterns in your project to keep your code loosely coupled, maintainable, and easy to test.

By definition, an Architecture Pattern expresses a fundamental structural organization or schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.

Since architectural patterns are platform-agnostic, in this article we’ll see how an architectural pattern such as MVVM can be applied to a Flutter project and significantly improve the code quality.

Dive into MVVM ⚙️

MVVM stands for Model-View-ViewModel, it originated from Microsoft and was heavily used in writing Windows Presentation Foundation (WPF) applications. MVVM facilitates the separation of the widgets (the view) from the business logic (the model) using view models.

We need three major pieces in MVVM. These pieces are:

View

It represents the UI of the application devoid of any application logic. The view model sends notifications to the view to update the UI whenever the state changes.

View Model

Which holds the state and the events of the view. Additionally, It acts as a bridge between the model and the view.

The view model is platform-independent and doesn't know its view. Therefore, it can be easily bound to a web, mobile, or desktop view.

Model

Holds app data and the business logic (e.g. local and remote data sources, model classes, and repositories). They’re usually simple classes.

Advantages ✔️

We can summarize the advantages of MVVM into the following:

Your code will be more easily testable.
Your code will be further decoupled (the biggest advantage.)
The project is even easier to maintain.
Your team can add new features even more quickly.

MVVM using PMVVM package

PMVVM is a Flutter package for simple and scalable state management based on the MVVM pattern, it uses Provider & Hooks under the hood. PMVVM serves the same purpose as BloC, but unlike BloC it doesn’t require too much boilerplate.

It's worth mentioning that the package adopts some concepts from the Stacked package, but with a much simpler and cleaner approach.

When should you use it? 👌

To keep it simple, use the MVVM whenever your widget has its own events that can mutate the state directly e.g: pages, posts, ...etc.

Usage 👨‍💻

The best way to get to know PMVVM is to get your hands dirty and try it out. Let's look at the code:

Build your ViewModel.

class MyViewModel extends ViewModel {
  int counter = 0;

  // Optional
  @override
  void init() {
    // It's called after the ViewModel is constructed
  }

  // Optional
  @override
  void onBuild() {
    // It's called everytime the view is rebuilt
  }

  void increase() {
    counter++;
    notifyListeners();
  }
}

You can also access the context inside the ViewModel directly.

class MyViewModel extends ViewModel {
  @override
  void init() {
    var height = MediaQuery.of(context).size.height;
  }
}

Declare MVVM inside your builder.

class MyWidget extends StatelessWidget {
  const MyWidget({Key key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return MVVM<MyViewModel>(
      view: (context, vmodel) => _MyView(),
      viewModel: MyViewModel(),
    );
  }
}

Build your View.

// StatelessView

class _MyView extends StatelessView<MyViewModel> {
  /// Set [reactive] to [false] if you don't want the view to listen to the ViewModel.
  /// It's [true] by default.
  const _MyView({Key key}) : super(key: key, reactive: true);

  @override
  Widget render(context, vmodel) {
    return Column(
      mainAxisAlignment: MainAxisAlignment.center,
      crossAxisAlignment: CrossAxisAlignment.center,
      children: <Widget>[
        Text(vmodel.counter.toString()),
        SizedBox(height: 24),
        RaisedButton(onPressed: vmodel.increase, child: Text('Increase')),
      ],
  );
}

// HookView

class _MyView extends HookView<MyViewModel> {
  /// Set [reactive] to [false] if you don't want the view to listen to the ViewModel.
  /// It's [true] by default.
  const _MyView({Key key}) : super(key: key, reactive: true);

  @override
  Widget render(context, vmodel) {
    return Column(
      mainAxisAlignment: MainAxisAlignment.center,
      crossAxisAlignment: CrossAxisAlignment.center,
      children: <Widget>[
        Text(vmodel.counter.toString()),
        SizedBox(height: 24),
        RaisedButton(onPressed: vmodel.increase, child: Text('Increase')),
      ],
    );
  }
}

More about PMVVM🎯

The init lifecycle method is called by default every time the view model dependencies are updated. To init the ViewModel only once and ignore dependencies updates, set initOnce of the MVVM builder to true.
You can use context.fetch<T>(listen: true/false) which is equivalent to Provider.of<T>(context)
To make the view ignore the state notifications from the ViewModel , set reactive to false when you are constructing the StatelessView or HookView :

class _MyView extends StatelessView<MyViewModel> {
  const _MyView({Key key}) : super(key: key, reactive: false);
  ....
}

ViewModel Lifecycle methods (All of them are optional)

/// - A callback after [ViewModel] is constructed.
/// - The event is called by default every time the [ViewModel] view dependencies are updated.
/// - Set [initOnce] of the [MVVM] as [true] to ignore dependencies updates.
void init() {}

/// A callback when the [build] method is called.
void onBuild() {}

/// A callback when the view disposed.
void onDispose() {}

/// A callback when the application is visible and responding to user input.
void onResume() {}

/// A callback when the application is not currently visible to the user, not responding to
/// user input, and running in the background.
void onPause() {}

/// - A callback when the application is in an inactive state and is not receiving user input.
/// - For [IOS] only.
void onInactive() {}

/// - A callback when the application is still hosted on a flutter engine but
///   is detached from any host views.
/// - For [Android] only.
void onDetach() {}

Patterns 🧩

In this section Let's discuss some patterns that can help your view model to access your widget properties:

Naive approach: Using cascade notation to initialize your view model with the widget properties. The problem with this approach is that your view model becomes non-reactive when the widget's dependencies (properties) are updated.

class MyWidget extends StatelessWidget {
  const MyWidget({Key key, this.varName}) : super(key: key);

  final String varName;

  @override
  Widget build(BuildContext context) {
    return MVVM<MyViewModel>(
      view: (context, vmodel) => _MyView(),
      viewModel: MyViewModel()..varName = varName,
    );
  }
}

Clean approach: similar to ReactJS, you should create a properties class, in which all your widget properties are kept.

my_widget.props.dart

class MyWidgetProps {
  MyWidgetProps({required this.name});

  final String name;
}

my_widget.vm.dart

class MyWidgetVM extends ViewModel {
  late MyWidgetProps props;

  @override
  void init() {
    props = context.fetch<MyWidgetProps>();
  }
}

my_widget.view.dart

class MyWidget extends StatelessWidget {
  MyWidget({
    Key? key,
    required String name,
  })  : props = MyWidgetProps(name: name),
        super(key: key);

  final MyWidgetProps props;

  Widget build(context) {
    return Provider.value(
      value: props,
      child: MVVM<MyWidgetVM>(
        view: (_, __) => _MyWidgetView(),
        viewModel: MyWidgetVM(),
      ),
    );
  }
}

FAQ 🤔

Can I use it in production?
- Yep! It's stable and ready to rock
What is the difference between Stacked & PMVVM since both adopt the same principles?

Stacked	PMVVM
You can't access the `BuildContext` from the `ViewModel`.	`BuildContext` can be accessed inside the `ViewModel` using: - `Provider.of<T>(context)` - `context.watch<T>()` - `context.read<T>()` - `context.select<T, R>(R cb(T value))`
You should implement the `Initialisable` interface to call `initialise`.	`init` event is called by default, all you need to do is to override it (optional).
There is no `build` method in the `ViewModel`.	`onBuild` method is called by default every time the `View` is rebuilt, and you can override it to implement yours (optional).
It over-wraps `provider` with many `ViewModels` like `FutureViewModel`, `StreamViewModel`, …etc. Which `provider` & `flutter_hooks` are built to do without any wrapping.	It doesn’t over-wrap `provider` package with such classes. Instead, you can use `StreamProvider/FutureProvider` or `Hooks` which gives you the flexibility to make the most out of `provider` & `flutter_hooks`.
It has reactive & non-reactive constructors that force developers to use consumers in a specific position in the sub-tree.	It doesn’t have such concepts, all you need is to declare the `MVVM` and consume it from anywhere in the sub-tree.

Building scalable Flutter apps (Architecture, Styling, Conventions, State management)

Nour El-Din Shobier — Thu, 24 Jun 2021 01:45:20 +0000

After two years of Fluttering, I would like to share in this article the best practices that I’ve learned of how to build a scalable application.

I will not say what you should do, but what you could do. This guideline will make sure you, and anyone else maintaining the application, can find anything you’re looking for easily and intuitively.

That said, let’s discuss how you can achieve that.

1) Architecture: Feature-based

Feature is an essential concept to understand any software design. It’s also used to describe user requirements for software development. Therefore, if we structure our projects by features, it will be easier to manage the project when it grows as we construct the system with bigger units.

Organize project by features

In complex apps, it’s hard to understand how different modules collaborate. A feature-oriented architecture is helpful for this because we’ve grouped related logic (widgets|utils|pages|stores|models|..etc) into features. We don’t need to think about how the small parts work together but how features work together to construct the app. By analyzing dependencies between features the app could auto-generate understandable diagrams for developers to learn or review the project.

Features types

To keep any feature from getting polluted, it’s important to decouple the business logic of that feature from its presentation. That’s why we should split the app into two different layers:

Infrastructure features: contains all the features that are responsible for implementing the business logic of the application (e.g: auth, http, config, user, articles, events, schools, …etc.)
App features: contains all the features that are responsible for implementing the presentation of the application (e.g: auth, home, settings, user, articles, events, schools, …etc.)

Notice that auth, user, events, articles, …etc. features can be both infrastructure and app features, so what is the difference? that’s what we will discuss in the next section (Features anatomy).

Features anatomy

Infrastructure features: maintains services, repositories, models, dtos, utils, interceptors, validators, interfaces, …etc
App features: maintains pages, widgets, styles, fonts, colors, …etc.

Note: An app feature may consume multiple Infrastructure features

2) Naming conventions: Naming files

Snake case (snake_case)

snake_case is a naming style where all letters in the name are lowercase and it uses underscores to separate words in a name. In addition, in Angular, a dot is used to separate the name, type, and extension for file names. file_name.type.dart

Including the type in the file names make it easy to find a specific file type using a text editor or an IDE.

Most common files types are: .widget, .style, .service, .model, .util, .store

Create additional type names if you must but take care not to create too many.

Examples

file_name.widget.dart
file_name.style.dart
file_name.model.dart
file_name.util.dart

3) State management: Provider + MVVM

State management is a complex topic in Flutter. Each State Management approach has its characteristics and each person has different preferences. For me, Provider was the best choice because it is easy to understand and it doesn’t use much code.

That said, Provider itself isn’t enough to build scalable apps, so I ended up building my package for state management that combines both Provider and MVVM features and called it PMVVM.

P.MVVM

In PMVVM we have 3 major pieces are needed, everything else is up to you. These pieces are:

View: It represents the UI of the application devoid of any Application Logic. The ViewModel sends notifications to the view to update the UI whenever state changes.
ViewModel: It acts as a bridge between the Model and the View. It’s responsible for transforming the data from the Model, it also holds the events of the View
Model: Holds app data and the business logic. It consists of the business logic - local and remote data source, model classes, repository. They’re usually simple classes.

Advantages ✔️

Your code is even more easily testable.
Your code is further decoupled (the biggest advantage.)
The package structure is even easier to navigate.
The project is even easier to maintain.
Your team can add new features even more quickly.

When to use it 👌

To keep it simple, use the MVVM whenever your widget has its own events that can mutate the state directly e.g: pages, posts, ..etc.

Some Notes

View can't access the Model directly
View is devoid of any application logic
ViewModel can have more than one View.

Usage

1. Build your ViewModel.

    class MyViewModel extends ViewModel {
      int counter = 0;

      // Optional
      @override
      void init() {
        // It's called after the ViewModel is constructed
      }

      // Optional
      @override
      void onBuild() {
        // It's called everytime the view is rebuilt
      }

      void increase() {
        counter++;
        notifyListeners();
      }
    }

You can also access the context inside the ViewModel directly

    class MyViewModel extends ViewModel {
      @override
      void init() {
        var height = MediaQuery.of(context).size.height;
      }
    }

2. Declare MVVM inside your widget.

    class MyWidget extends StatelessWidget {
      const MyWidget({Key key}) : super(key: key);

      @override
      Widget build(BuildContext context) {
        return MVVM<MyViewModel>(
          view: (context, vmodel) => _MyView(),
          viewModel: MyViewModel(),
        );
      }
    }

3. Build your View.

    class _MyView extends StatelessView<MyViewModel> {
      /// Set [reactive] to [false] if you don't want the view to listen to the ViewModel.
      /// It's [true] by default.
      const _MyView({Key key}) : super(key: key, reactive: true); 

      @override
      Widget render(context, vmodel) {
        return Column(
          mainAxisAlignment: MainAxisAlignment.center,
          crossAxisAlignment: CrossAxisAlignment.center,
          children: <Widget>[
            Text(vmodel.counter.toString()),
            SizedBox(height: 24),
            RaisedButton(onPressed: vmodel.increase, child: Text('Increase')),
          ],
        );
      }

For more details, head to the package documentation

P.MVVM for Web, Mobile, and Desktop together

pmvvm works perfectly especially if your app runs on multiple platforms. All you need is to create a single view model that controls all these views:

4) Styling

In Flutter, we often make files for colors, strings, text styles, themes. This way all of these values are kept in one, easy to find a place that should make life easier for the person who gets stuck with maintaining the app.

Styling as a feature

We should group app-wide colors, fonts, themes, and animations as an app feature called styles. This approach will make all the widgets in the application consume the styles from a single source.

Example:

colors.style.dart

    abstract class CColors {
      static const white0 = Color(0xffffffff);
      static const black100 = Color(0xff000000);
      static const blue10 = Color(0xffedf5ff);
      static const blue20 = Color(0xffd0e2ff);
      static const blue30 = Color(0xffa6c8ff);
    }

text.style.dart

    abstract class CFonts {
      static const primaryRegular = 'IBMPlexSans-Regular';
      static const primaryLight = 'IBMPlexSans-Light';
      static const primaryMedium = 'IBMPlexSans-Medium';
      static const primarySemibold = 'IBMPlexSans-SemiBold';
      static const primaryBold = 'IBMPlexSans-Bold';
    }

More examples can be found Here

Widgets styling

If your widget is complex and has some reactive behavior based on specific actions (e.g: background color changes when a button is tapped), then you probably need to separate your widget colors and layout variables from the widget code.

Example:

tile.style.dart

    abstract class TileStyle {
      static const Map<String, dynamic> layouts = {
        'tile-padding': const EdgeInsets.all(16),
      };
      static const Map<String, Color> colors = {
        'tile-enabled-background-color': CColors.gray90,
        'tile-enabled-label-color': CColors.gray30,
        'tile-enabled-title-color': CColors.gray10,
        'tile-enabled-description-color': CColors.gray30,
        //
        'tile-disabled-background-color': CColors.gray90,
        'tile-disabled-label-color': CColors.gray70,
        'tile-disabled-title-color': CColors.gray70,
        'tile-disabled-description-color': CColors.gray70,
      };
    }

tile.widget.dart

 class CTile extends StatelessWidget {
  const CTile({
    Key? key,
    this.enable = true,
    ...
  }) : super(key: key);

  final bool enable;

  final _colors = CTileStyle.colors;
  final _layouts = CTileStyle.layouts;

  @override
  Widget build(BuildContext context) {
    /// styles helpers
    String cwidget = 'tile';
    String state = enable ? 'enabled' : 'disabled';

    return IgnorePointer(
      ignoring: !enable,
      child: Container(
        color: _colors['$cwidget-$state-background-color'],
        padding: _layouts['$cwidget-padding'],
        child: ....,
      ),
    );
  }
}

More examples can be found Here

Conclusion

In this article, we covered the 4 main things you need in large application development.

Here they are in summary:

Construct your application as a set of features working together.
Define the type of each dart file using file_name.type.dart.
Using MVVM to manage your state is easier than other alternatives such as BLoC.
Separate your widgets styles from the presentation code.

Source code

A full example for this article can be found here