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

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

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

Transcript

1. Архитектура для шаблона 1 Семён Белялов Datasolution bouxroix@gmail.com telegram: @bouxroix
2. О чем доклад? 1. Freemarker templates 2. Наша архитектура, и что потенциально может делать шаблон 3. Пример создания шаблона нового экрана, реализующего нашу архитектуру и делающего максимально много 4. For fun шаблон нового проекта или модуля 2
3. Предыдущий доклад 3 https://youtu.be/H-gRJ3xsan0
4. Что было в том докладе? 1. Подробное освящение структуры freemarker шаблонов 2. Создание шаблоном fragment и presenter 3. Базовые классы с moxy 4. Подготовленные к конфигурации DI 5. Создание recycler adapter 4
5. Почему бы нам не создать свои шаблоны, которые делают максимально много? 5
6. Требования к шаблонам 1. Использование наших базовых классов 2. Формирование основных архитектурных слоев (пары класс интерфейс) 1. UI: views, viewmodels 2. Domain: interactors 3. Data: repositories 3. Автоматическая конфигурирование DI 4. Работа с навигацией 6
7. Приоритеты 1. Компилируемость после работы шаблона (работа из коробки) 2. Простота шаблона (без лишнего неиспользуемого функционала) 3. Максимальная ответственность шаблона 4. Clean архитектура с DI 7
8. Компоненты приложения 8
9. 1. Добавление скоупа с основными компонентами приложения 9
10. 2. Добавление вью к существующему скоупу. Shared viewmodel 10
11. 3. Добавление интерактора и/или репозитория к существующим скоупам 11
12. Разработку приложения можно описать комбинацией этих сценариев Основные сценарии в разработке 12 1. Добавление нового scope с view, viewmodel, interactor, и repository 2. Добавление вью к существующей скоупу (shared view model) 3. Добавление интерактора или репозитория к существующим скоупам
13. 13 Краткая структура шаблонов https://habr.com/ru/company/redmadrobot/blog/274897/
14. 1. template.xml ui вид и изменяемые параметры 2. globals.xml.ftl переменные на основе template 3. recipe.xml.ftl команды с шаблонами файлов 4. *.ftl шаблоны файлов 14 Краткая структура шаблонов
15. 1. <instantiate/> Создает файл по шаблону 2. <merge/> Изменение файла шаблоном 3. <copy/> Копирует файлы (ресурсы) 15 recipe.xml.ftl
16. Шаблон НЕ может мержить .kt файлы, .xml .gradle может 16
17. Наш стек технологий 1. Kotlin 2. Jetpack (viewmodel, livedata, databinding, navigation, etc) 3. DI Toothpick 17 Создаем шаблоны нашей конфигурации
18. Создаем шаблоны нашей конфигурации 18
19. Шаблон новой фичи 1. Все зависит от screenName, фрагмент, xml, viewmodel interactor repository. (Даже title в туллбаре и label в nav graph) 90% случаев будет называться так, остальное исключение 2. addToolbar addList Как boolean позволяет выбирать 4 варианта фрагмента максимально лаконично 3. Считаем что сценарий когда не нужен репозиторий редким, а когда не нужен и интерактор еще реже 4. Делаем single activity, генерятся только фрагменты 19
20. Например фрагмент 20
21. Layout xml 21
22. Списки с databinding 1. Простые списки отличаются друг от друга только layout xml 2. Один базовый адаптер 3. Не нужен шаблон адаптера 22
23. Shared view model 23 https://developer.android.com/topic/libraries/architecture/viewmodel#sharing
24. Shared view model 24
25. Предполагаем single activity 25 Одно AppActivity Так проще шаблон, он генерит только фрагменты, и возможно так грамотнее.
26. Nav component 26
27. DI scopes 27
28. Очень удобно и просто привязать feature scope к жц viewmodel 1. viewmodel просто реализует данный делегат 28 DI: Toothpick
29. DI: Toothpick 29 Весь новый скоуп объявляется в новых файлах, шаблон идеально ложится.
30. DI: Если был бы Dagger 2 30 Для всех действий он требует редактировать существующие файлы, component, module или application
31. DI: Если был бы Koin 31 Для всех действий он требует редактировать существующие файлы, application, module
32. Dagger, koin, toothpick и шаблоны 1. Действие добавление фичи. Koin и dagger в любом случае требуют менять module, .kt файл, что шаблон делать не может. В toothpick эта логика в новых файлах. При конфигурировании скоупа старый код не меняется. Принципиальное отличии toothpick. 32
33. View вне DI скоупа 1. Реализация shared view model без изменения скоупа 2. Независимость скоупов с shared view model 3. Простота привязывания жц скоупа к вьюмодели 33 Плюсы 1. Отсутствие провайдинга зависимостей в конструктор вьюмодели Минусы
34. Генерируемые файлы 1. Добавление нового скоупа 2. Добавление вью к существующему скоупу 34 Итоговая ответственность шаблона
35. Шаблон новой фичи 35
36. Шаблон новой фичи 36 template.xml
37. Шаблон новой фичи 37 globals.xml.ftl
38. Шаблон новой фичи 38 recipe.xml.ftl
39. Шаблон новой фичи 39 Viewmodel.kt.ftl
40. Nav component и шаблон 40 Это xml и шаблон может его мержить
41. Мерж app_nav_graph.xml шаблоном 41
43. Раздельные ресурсные директории 43 Удобно когда они генерятся автоматически
44. Создаем шаблон нового проекта или модуля 44
45. Создаем шаблон нового проекта, модуля 1. В template <category value="Application" /> Определяет шаблон нового проекта или модуля. 5. Нельзя добавлять такие шаблоны, только заменять 45
46. Пробуем сделать шаблон нового проекта или модуля 46
47. Пробуем сделать шаблон нового проекта или модуля 1. <category value="Activity" /> По нему формируется список предложенных активити 2. При клике создать новый проект или новый модуль последовательно применяется 2 шаблона. category application и category activity 47
48. Formfactor 48
49. Результат 49
50. Шаблон нового проекта 50 Добавляем к шаблону нового экрана базовые классы и AppActivity screen_globals.xml.ftl screen_recipe.xml.ftl Переиспользуем
51. Результаты 1. Были созданы шаблоны которые делают максимально много 2. Они простые и работают из коробки (новый проект частично) 3. Они используют наш стек технологий 4. https://github.com/roixa/RoixArchitectureTemplates 51
52. Дальнейшие планы 1. Добиться чтобы шаблон новый проекта работал идеально 2. Написать плагин. Возможно он способен сделать сценарий 3 52
53. Спасибо за внимание