Flutter. MVVM. Начало

Доброго времени суток, дорогие читатели! Меня зовут Сурен, и я разработчик.

Поскольку моя предыдущая статья о том, как бекендер в мобильную кроссплатформу лез, не утонула в минусах, я решил продолжить делиться своим опытом познания данной замечательной технологии =)

Написано немало статей про MVVM, его реализацию на различных технологиях и на Flutter, в частности. Но мне они давались с трудом, и не было понимания, как оно в итоге работает. Возможно, сказывается особенность восприятия “Бекендера” =) Поэтому, если среди читателей есть люди с похожим складом ума, возможно эта статья поможет и Вам понять, что такое MVVM и как его реализовать на Flutter простым способом. 

Для начала немного википедии.

MVVM (Model-View-ViewModel) — шаблон проектирования архитектуры приложения. Пришел на смену шаблону MVC|MVP (Model-View-Controller/Presenter). Актуален для платформ, в которых присутствует концепция «связывания данных», позволяющая связывать данные с визуальными элементами в обе стороны. На схеме это выглядит так:

Где

• Model представляет из себя слой бизнес-логики, который включает описание фундаментальных данных, необходимых для работы приложения, и логику работы с ними.

• View является графическим интерфейсом. Подписан на изменения ViewModel, а при действиях с интерфейсом вызывает команды ViewModel для изменения данных в Модели.

• ViewModel же с одной стороны — абстракция Представления, а с другой — обёртка данных из Модели, подлежащих связыванию. То есть она содержит Модель, преобразованную к Представлению, а также команды, которыми может пользоваться Представление, чтобы влиять на Модель.

Перейдем к практике.

Для обеспечения “связывания данных” я использую связку Provider+ChangeNotifier. Provider представляет собой смесь Инъекции Зависимостей (Dependency Injection или DI) и управления состоянием, а ChangeNotifier позволяет отслеживать изменения ViewModel и перестраивать наш UI.

Построим простейший ToDoList на данном подходе и попутно будем разбираться, как он работает.

Внимание! В качестве примера для наглядности и удобства я буду реализовывать каждый виджет в одном файле, то есть и ViewModel, и View(Виджет) и его Model. Но на боевых проектах, особенно если вы работаете в команде, эти сущности нужно разносить по разным файлам.

Для начала создадим новый проект приложения на flutter. Перед нами откроется чистый проект, представляющий из себя приложение счетчик или кликер.

В main.dart у нас реализован основной метод main(), запускающий приложение MyApp, которое состоит из 1 StatefullWidget — MyHomePage, реализующего счетчик нажатий. Приложение можно запустить и проверить, что все работает. 

Но мы собрались делать ToDoList, следовательно пока оставляем main.dart. Создаем рядом новый файл todo_list_widget.dart, а в нем классы:

•  _ViewModel, реализующий ChangeNotifier,

•  ToDoListWidget, реализующий StatelessWidget,

•  _ModelState, в котором мы будем хранить состояние нашей модели.

class _ModelState {}   class _ViewModel extends ChangeNotifier {}   class ToDoListWidget extends StatelessWidget {  const ToDoListWidget({Key? key}) : super(key: key);    @override  Widget build(BuildContext context) {    var _viewModel = context.watch<_ViewModel>();    return Container();  } }

В Dart символ “_” перед именем свойства/класса/метода делает его приватным (доступным только в пределах текущего файла .dart).

Добавим файл todo_item.dart и реализуем в нем класс Модели ToDoItem. Цель — сделать некий список дел, так что свойства нужные нам в данном классе:

• name — наименование задачи (по совместительству ключ),

• done — флаг о выполнении.

Также, чтобы у нас была возможность “редактировать” элементы списка, добавим метод copyWith. Наш класс модели будет выглядеть следующим образом:

class ToDoItem {  final String name;  final bool done;    ToDoItem({    required this.name,    this.done = false,  });    ToDoItem copyWith({    String? name,    bool? done,  }) {    return ToDoItem(      name: name ?? this.name,      done: done ?? this.done,    );  } }

Возвращаемся к основному. 

В стейте мы будем хранить список элементов ToDo листа. Для обеспечения иммутабельности список у нас будет “final”, а для редактирования мы будем его копировать, поэтому добавим метод “copyWith”. В нашем случае отдельный стейт выглядит как “бойлерплейт“, но для наглядности и последующего масштабирования он полезен. 

После этих манипуляций класс принял следующий вид:

class _ModelState {  final List<ToDoItem> items;    _ModelState({    this.items = const <ToDoItem>[],  });    _ModelState copyWith({    List<ToDoItem>? items,  }) {    return _ModelState(      items: items ?? this.items,    );  } }

Переходим к ViewModel, поскольку задача данного класса — быть прослойкой между интерфейсом и данными. С одной стороны мы должны в нем следить за изменениями модели и дергать перестраивание интерфейса, а с другой — должны иметь методы воздействия на эту модель. Добавим в него private свойство “_state” и дополним публичным сеттером и геттером. Геттер возвращает приватный стейт, а сеттер заменяет его новым значением и уведомляет прослушивающие виджеты при изменении стейта.

var _state = _ModelState();    _ModelState get state => _state;  set state(_ModelState val) {    _state = _state.copyWith(items: val.items);    notifyListeners();  }

“notifyListeners” — метод в классе “ChangeNotifier”, уведомляющий виджетов-слушателей об изменении модели и дающий команду перестроиться. 

Для реализации ToDo списка нам нужны следующие методы:

 addItem(ToDoItem item) {    var list = state.items.toList();    if (list.any((element) => element.name == item.name)) {      throw Error();    } else {      list.add(item);      state = state.copyWith(items: list);    }  }

 dellItem(ToDoItem item) {    var list = state.items.toList();    list.removeWhere((element) => element.name == item.name);    state = state.copyWith(items: list);  }

 toogleItem(ToDoItem item) {    var list = state.items.toList();    var index = list.indexWhere((element) => element.name == item.name);    list[index] = item.copyWith(done: !item.done);    state = state.copyWith(items: list);  }

После каждого действия мы вызываем Сеттер стейта для того, чтобы уведомить об изменении слушателей и перестроить стейт.

На первый взгляд основная логика готова, так что перейдем к View (виджету).

Пришло время добавить в проект пакет Provider. Для этого можно либо отредактировать файл pubspec.yaml, добавив в него зависимость от пакета Provider, либо выполнив команду в консоли:
flutter pub add provider — данная команда, собственно, и добавит зависимость в тот же файл и скачает пакет последней версии.

Чтобы наш виджет мог реагировать на изменение стейта, для начала обернем его в ChangeNotifierProvider. В метод создания мы передаем нашу ViewModel, а в качестве ребенка — наш Виджет. Для таких оберток удобно делать статический метод create внутри виджета, который и инициирует ViewModel и передает ее в виджет ребенка. Теперь для получения доступа к ViewModel внутри билдера виджета, мы можем ее получить через context. Для этого мы и используем пакет Provider.

class ToDoListWidget extends StatelessWidget {  const ToDoListWidget({Key? key}) : super(key: key);    @override  Widget build(BuildContext context) {    var _viewModel = context.watch<_ViewModel>();    return Container();  }    static Widget create() => ChangeNotifierProvider(        create: (_) => _ViewModel(),        child: const ToDoListWidget(),      ); }

Метод watch<ClassName>() не только отдает нам через провайдер экземпляр модели, которая была инициализирована выше по дереву виджетов, но и добавляет текущий виджет в качестве слушателя изменений в модели. То есть, когда мы в модели вызываем метод notifyListeners, наш виджет-слушатель перестраивается, за счет чего и достигается “связывание данных” между моделью и представлением.

Теперь набросаем простенький интерфейс, аналогичный базовому виджету MyHomePage, но с той лишь разницей, что в качестве тела виджета у нас будет список. В качестве списка будем использовать ListView.builder, поскольку он рендерит только те элементы, которые видны на экране, и в целом удобен.

 @override  Widget build(BuildContext context) {    var _viewModel = context.watch<_ViewModel>();    return Scaffold(      appBar: AppBar(        title: const Text("ToDo List"),      ),      body: ListView.builder(        itemBuilder: (_, int index) => ToDoItemWidget(          item: _viewModel.state.items[index],          onDelete: _viewModel.dellItem,          onToogle: _viewModel.toogleItem,        ),        itemCount: _viewModel.state.items.length,      ),      floatingActionButton: FloatingActionButton(        onPressed: () {          showDialog(            context: context,            builder: (_) => AddTaskDialog(onFinish: _viewModel.addItem),          );        },        tooltip: 'Add task',        child: const Icon(Icons.add),      ),    );  }

В качестве элемента списка напишем виджет ToDoItemWidget, который отдаст нам CheckboxListTile (элемент списка с чекбоксом), обернутый в Dismissible (для реализации удаления свайпом), и будет пробрасывать 2 делегата: на удаление элемента из списка и на изменение состояния элемента списка (выполнено/не выполнено).

class ToDoItemWidget extends StatelessWidget {  final ToDoItem item;  final Function(ToDoItem) onDelete;  final Function(ToDoItem) onToogle;  const ToDoItemWidget({    Key? key,    required this.item,    required this.onDelete,    required this.onToogle,  }) : super(key: key);    @override  Widget build(BuildContext context) {    return Dismissible(        background: Container(color: Colors.red),        key: Key(item.name),        onDismissed: (_) {          onDelete(item);        },        child: CheckboxListTile(          value: item.done,          onChanged: (_) {            onToogle(item);          },          title: Text(item.name),        ));  } }

Для добавления элемента нам нужно сначала где-то взять название для задачи. Для этого напишем виджет AddTaskDialog. Он представляет из себя AlertDialog с текстовым полем и делегатом, который в случае успеха возвращает нам новенькую задачу, а также сообщает об ошибках через всплывающие уведомления.  

class AddTaskDialog extends StatelessWidget {  final ValueChanged<ToDoItem> onFinish;  const AddTaskDialog({    Key? key,    required this.onFinish,  }) : super(key: key);    @override  Widget build(BuildContext context) {    String? text;    return AlertDialog(      title: const Text("Add new Task"),      content: TextField(          autofocus: true,          onChanged: (String _text) {            text = _text;          }),      actions: <Widget>[        TextButton(          child: const Text("Add"),          onPressed: () {            if (text != null) {              try {                onFinish(ToDoItem(name: text!));                Navigator.of(context).pop();              } catch (e) {                ScaffoldMessenger.of(context).showSnackBar(                    SnackBar(content: Text("Task ${text!} exist!")));              }            } else {              ScaffoldMessenger.of(context).showSnackBar(                  const SnackBar(content: Text("Enter Task name")));            }          },        ),        TextButton(          child: const Text("Close"),          onPressed: () {            Navigator.of(context).pop();          },        ),      ],    );  } }

Всё. Теперь можно собрать и посмотреть, что он делает =)

Все заложенные нами кейсы работают =)

В дальнейшем можно прикрутить sqlite, добавить инициализацию и синхронизацию, и вот — простенький задачник готов (шутка).

Я специально не затронул в данной статье редактирование задач. Если захотите попробовать повторить, Вы сможете это сделать сами =)

Ссылка на репозиторий с данным примером.

В сухом остатке.

Я не утверждаю, что MVVM — это лучший шаблон проектирования для мобильных приложений на Flutter. Это пока первое, что я осознал и принял на вооружение после statefullWidget. Самое главное для меня — это его масштабируемость и применимость для достаточно больших приложений. Плюс он отвечает требованиям Чистой архитектуры. Только прошу, не рассматривайте мой пример как Архитектурный. Я показал в коде на примере приложения для чек-листа, как реализовать данный шаблон.