От State к Event: как два sealed class закрывают архитектуру Android-экрана в Kotlin

Решение отправки ивентов через MutableSharedFlow может стрельнуть в кейсе, когда происходит смена конфигурации (смена темы, языка, поворот экрана) и эмитятся два ивента - т.к. extraBufferCapacity = 1, первый ивент может не дойти до UI.

Решение через Channel в этой ситуации выглядит более надежным, т.к. без подписчика он будет ждать отправки ивентов, при этом после отправки он не отправит ивент повторно - как нам и нужно. Одна особенность - подписчик модет быть один, но в кейсе с экраном это как раз ок. Реализация много где была описана, выглядит примерно так:

private val _events = Channel<Event>()
val events: Flow<Event> = _events.receiveAsFlow().flowOn(Dispatchers.Main.immediate)

Уменьшаем написание boilerplate с помощью File Templates

Тем временем, вышла вторая часть, где на примере описывается работа инструмента :)

Уменьшаем написание boilerplate с помощью File Templates

Вы про AI-инструменты для автокомплита в IDE? Они решают немного другую проблему - предлагают дополнить код в уже существующем файле. File Templates (не путать с Live Templates) - это про возможность сгенерировать в пару кликов дерево из директорий и файлов с предзаполненным шаблонным кодом. В следующей части как раз буду разбирать на примере, будет более понятно на что инструмент способен и для чего нужен :)

Прочие оптимизации кода Gradle Convention Plugins, выводы по результатам использования подхода

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

Согласен, при публикации плагинов FQN - это must have.
Вместе с тем, для плагинов, которые используются только в рамках конкретного проекта , если FQN длинный, такой нейминг может трудно запоминаться или быть не совсем удобным в использовании.

По второму пункту - да, можно располагать -gradle.kts файлы и в подпапках, а не в корневой папке, но важно не забыть при использовании плагина дописывать путь через точку где он лежит, т.е. если у файла такое расположение - io/github/dmitriy1892/conventionplugins/android.base.config.gradle.kts , то при использовании в plugins-блоке в build.gradle.kts -файлах нужно указывать так:

plugins {   
    id("io.github.dmitriy.conventionplugins.android.base.config")
}

Скорее всего, из-за такого не совсем очевидного момента (и возможных неудобств в использовании, если запихать файл слишком глубоко в директории), подход с хранением -gradle.kts файлов в не-рутовых папках и не возымел широкого распространения :)

Gradle Convention Plugins: как облегчить себе жизнь и уменьшить boilerplate в gradle-файлах

Как понимаю, этот extension помог решить проблему? :)

Создание плагинов и переиспользуемых частей в .gradle.kts-файлах и Kotlin extension-функциях

Спасибо за отзыв, рад что помог!

buildSrc - это тоже вариант, но у него есть свои ограничения и недостатки в части кэширования сборки и пр. :)

Возможно, это поможет с подключением: при использовании композитных сборок (composite builds) вместо buildSrc самый важный момент - это правильно прописать подключение модуля с плагинами в основной проект. В файле settings.gradle.kts основного проекта нужно указывать не include(":convention-plugins:base"), а includeBuild("convention-plugins/base") - без двоеточий, как обычный путь до директории, где лежит build.gradle.kts-файл модуля с плагинами (довольно часто встречающаяся ошибка)

Gradle Convention Plugins: как облегчить себе жизнь и уменьшить boilerplate в gradle-файлах

Судя по логу ошибки, в модуле :plugins:base есть sourceSet test (папка test), для которого не задан android-плагин... Удалите и попробуйте синхронизировать проект. Если проект выложен в публичный репозиторий, было бы проще разобраться

Gradle Convention Plugins: как облегчить себе жизнь и уменьшить boilerplate в gradle-файлах

Как раз вчера вышло - welcome :)

Пишем простенький DI для Android приложения

Хорошая статья, было интересно почитать. Я бы еще обозначил пару важных моментов:

1. В реализации функции `Di.instance()` было бы неплохо бросать более понятную ошибку, что класс такой-то не зарегистрирован в графе. Ну и в случае миграции ключей зависимостей с простых `KClass` на составные (по типу как в Koin), может появиться еще одна ошибка о том, что возвращаемый тип не совпадает;

2. Стоит отметить, что c `Map`-ой фабрик не получится сделать проверку графа зависимостей во время компиляции и есть риск упасть в рантайме с такой реализацией DI.