To-do Flutter приложение, в рамках проектной деятельности во время участия в Школе мобильной разработки Яндекса.

State management: bloc

Dependency injection: dino

Database: hive

Network: dio, retrofit

Для запуска интеграционных тестов необходимо ввести команду: flutter pub run melos run integration_test

Для работы с архитектурой (генерации и обновления структур) используется CLI, пока что не опубликованный в открытый доступ. В любом случае, это не мешает компиляции и просмотру кода.

Пользователь взаимодействует с локальной БД приложения, после чего выполняется асинхронная операция синхронизации с API. Это позволяет работать с приложением максимально быстро и плавно, без необходимости ожидания подгрузки информации, либо завершения действий (создания, изменения, удаления задачи).

Если синхронизация не удалась (нет интернета, ошибка сервера и тд), то операция повторяется каждые 5 секунд, пока не окажется успешной.

В состоянии простоя, приложение синхронизирует локальную БД с данными из API каждую минуту. Также синхронизация проводится при открытии приложения, изменении состояния подключения к сети и возврате в приложение из background.

В локальной БД хранятся не только задачи, но и состояния несинхронизированных с API изменений. При синхронизации происходит слияние данных из API с несинхронизированными изменениями из локальной БД.

Решение конфликтов при слиянии происходит по стратегии, направленной на минимализацию возможного ущерба. Это позволяет отменить удаление задач, если экземляр задачи в синхронизированной копии на сервере окажется более актуальным, чем в локальной копии (либо наоборот, на устройстве актуальнее чем на сервере), в которой была запрошена операция удаления.

Например, если пользователь удалил задачу на устройстве 1 без доступа к сети, а на устройстве 2, которое может синхронизироваться с API, изменил данную задачу, то при следующей успешной синхронизации на устройстве 1 удаление будет отменено, что позволит не потерять актуальные изменения.

Также, если на устройстве с доступом к сети удалить задачу, а потом внести изменения в экземпляре данной задачи на другом устройстве, и провести синхронизацию с API, то задача будет восстановлена на сервере.

Адреса:

• Список задач: todoapp:https://todoapp/
• Открыть задачу по id: todoapp:https://todoapp/task/:taskId
• Открыть окно создания задачи: todoapp:https://todoapp/task/create

Структура проекта представляет собой монорепозиторий (workflow), состоящий из нескольких модулей (app, core, task).

Каждый модуль в свою очередь состоит из трёх слоёв: domain, infrastructure и presentation. Каждый слой находится в отдельном пакете и имеет строго определенные зависимости от других слоёв.

Всего выделяется три слоя:

• domain: самый чистый слой, содержащий модели и сервисы предметной области, иными словами, наиболее чистую бизнес-логику;
• presentation: слой, представляющий графическую составляющую приложения и логику взаимодействия с пользователем. Может содержать виджеты, страницы и сервисы, необходимые для этого слоя. Зависит от слоя domain и использует его публичные сервисы для реализации пользовательского опыта;
• infrastructure: слой, зависящий от всех остальных слоёв и имеющий наиболее полную картину всего модуля. В нём реализуются некоторые сервисы предметной области и слоя презентации, которые нельзя или не следует реализовывать там, где они объявлены. Например, в этом слое происходит всё взаимодействие с внешними источниками данных: их получение, отправка, маппинг.

Изоляция слоёв с помощью пакетов позволяет в полной мере задействовать принцип инверсии зависимостей на практике: невозможно использовать сервис или модель в том слоё, для которого она не предназначена по Dependency Rule.

Каждый слой имеет свой Pubspec файл, что позволяет использовать зависимости из pub.dev только в тех местах, где это нужно. Можно также прописывать и зависимости между слоями, но для автоматизации и предотвращении ошибок используется CLI, генерирующий pubspec_overrides.yaml на основе modulespec.yaml, который находится в корне каждого модуля.

Модули также могут зависеть друг от друга. Тогда слои зависимого модуля соответственно зависят от слоёв модуля-зависимости.

Модули app и core являются обязательными и генерируются автоматически. Модуль core является зависимостью для всех остальных слоев, а модуль app нужен для того, чтобы интегрировать другие модули, если нет возможности создать для интеграции отдельный модуль.

Помимо модулей, в проекте также есть пакет todo_app, который является точкой входа. Он импортирует все модули, задействованные в приложении (все их слои) и собирает в итоговое приложение. По сути это и есть основной пакет приложения, поэтому в Pubspec файле проекта можно указать основную информацию — описание приложения, версию.

• Тёмная тема
• Локализация
• Navigator 2.0
• Firebase App Distribution
• Firebase Crashlytics
• Remote Config: переключение цвета важности
• Firebase Analytics
• Анимации
• Поддержка горизонтальной ориентации
• Deeplink
• Поддержка больших экранов
• Unit-тесты
• Интеграционные тесты
• Flavors (Testing, Production)