Архитектура для шаблона

Архитектура для шаблона

Белялов Семён, Datasolution at #MOSDROID 18 Argon

Есть замечательный инструмент freemarker template. Генерируемый им код значительно облегчает жизнь. Собственно, поговорим об этом. Я покажу вариант clean архитектуры с использованием шаблонов, которые делают максимально много. А именно: создание экрана, основных архитектурных слоев, DI и навигации. Поговорим о том, какие есть ограничения этого инструмента, и как это отражается на его использовании или на архитектуре. Пытаемся выжать из шаблонов максимум. И результат — сами шаблоны и их реализация. Также создадим шаблон нового проекта, for fun.

916b2b50d1c958f9ed1c008623065b8a?s=128

MOSDROID

July 19, 2019
Tweet

Transcript

  1. 2.

    О чем доклад? 1. Freemarker templates 2. Наша архитектура, и

    что потенциально может делать шаблон 3. Пример создания шаблона нового экрана, реализующего нашу архитектуру и делающего максимально много 4. For fun шаблон нового проекта или модуля 2
  2. 4.

    Что было в том докладе? 1. Подробное освящение структуры freemarker

    шаблонов 2. Создание шаблоном fragment и presenter 3. Базовые классы с moxy 4. Подготовленные к конфигурации DI 5. Создание recycler adapter 4
  3. 6.

    Требования к шаблонам 1. Использование наших базовых классов 2. Формирование

    основных архитектурных слоев (пары класс интерфейс) 1. UI: views, viewmodels 2. Domain: interactors 3. Data: repositories 3. Автоматическая конфигурирование DI 4. Работа с навигацией 6
  4. 7.

    Приоритеты 1. Компилируемость после работы шаблона (работа из коробки) 2.

    Простота шаблона (без лишнего неиспользуемого функционала) 3. Максимальная ответственность шаблона 4. Clean архитектура с DI 7
  5. 12.

    Разработку приложения можно описать комбинацией этих сценариев Основные сценарии в

    разработке 12 1. Добавление нового scope с view, viewmodel, interactor, и repository 2. Добавление вью к существующей скоупу (shared view model) 3. Добавление интерактора или репозитория к существующим скоупам
  6. 14.

    1. template.xml ui вид и изменяемые параметры 2. globals.xml.ftl переменные

    на основе template 3. recipe.xml.ftl команды с шаблонами файлов 4. *.ftl шаблоны файлов 14 Краткая структура шаблонов
  7. 15.

    1. <instantiate/> Создает файл по шаблону 2. <merge/> Изменение файла

    шаблоном 3. <copy/> Копирует файлы (ресурсы) 15 recipe.xml.ftl
  8. 17.

    Наш стек технологий 1. Kotlin 2. Jetpack (viewmodel, livedata, databinding,

    navigation, etc) 3. DI Toothpick 17 Создаем шаблоны нашей конфигурации
  9. 19.

    Шаблон новой фичи 1. Все зависит от screenName, фрагмент, xml,

    viewmodel interactor repository. (Даже title в туллбаре и label в nav graph) 90% случаев будет называться так, остальное исключение 2. addToolbar addList Как boolean позволяет выбирать 4 варианта фрагмента максимально лаконично 3. Считаем что сценарий когда не нужен репозиторий редким, а когда не нужен и интерактор еще реже 4. Делаем single activity, генерятся только фрагменты 19
  10. 22.

    Списки с databinding 1. Простые списки отличаются друг от друга

    только layout xml 2. Один базовый адаптер 3. Не нужен шаблон адаптера 22
  11. 25.

    Предполагаем single activity 25 Одно AppActivity Так проще шаблон, он

    генерит только фрагменты, и возможно так грамотнее.
  12. 28.

    Очень удобно и просто привязать feature scope к жц viewmodel

    1. viewmodel просто реализует данный делегат 28 DI: Toothpick
  13. 30.

    DI: Если был бы Dagger 2 30 Для всех действий

    он требует редактировать существующие файлы, component, module или application
  14. 31.

    DI: Если был бы Koin 31 Для всех действий он

    требует редактировать существующие файлы, application, module
  15. 32.

    Dagger, koin, toothpick и шаблоны 1. Действие добавление фичи. Koin

    и dagger в любом случае требуют менять module, .kt файл, что шаблон делать не может. В toothpick эта логика в новых файлах. При конфигурировании скоупа старый код не меняется. Принципиальное отличии toothpick. 32
  16. 33.

    View вне DI скоупа 1. Реализация shared view model без

    изменения скоупа 2. Независимость скоупов с shared view model 3. Простота привязывания жц скоупа к вьюмодели 33 Плюсы 1. Отсутствие провайдинга зависимостей в конструктор вьюмодели Минусы
  17. 34.

    Генерируемые файлы 1. Добавление нового скоупа 2. Добавление вью к

    существующему скоупу 34 Итоговая ответственность шаблона
  18. 42.
  19. 45.

    Создаем шаблон нового проекта, модуля 1. В template <category value="Application"

    /> Определяет шаблон нового проекта или модуля. 5. Нельзя добавлять такие шаблоны, только заменять 45
  20. 47.

    Пробуем сделать шаблон нового проекта или модуля 1. <category value="Activity"

    /> По нему формируется список предложенных активити 2. При клике создать новый проект или новый модуль последовательно применяется 2 шаблона. category application и category activity 47
  21. 50.

    Шаблон нового проекта 50 Добавляем к шаблону нового экрана базовые

    классы и AppActivity screen_globals.xml.ftl screen_recipe.xml.ftl Переиспользуем
  22. 51.

    Результаты 1. Были созданы шаблоны которые делают максимально много 2.

    Они простые и работают из коробки (новый проект частично) 3. Они используют наш стек технологий 4. https://github.com/roixa/RoixArchitectureTemplates 51
  23. 52.

    Дальнейшие планы 1. Добиться чтобы шаблон новый проекта работал идеально

    2. Написать плагин. Возможно он способен сделать сценарий 3 52