Ручной DI на Котлине? Легко! Ну, почти…

Все мы знаем, что Dagger — бич современного общества стандарт индустрии, если это касается Dependency Injection. Все мы знаем, что Dagger хоть и является мощным фреймворком, но сборка проекта с ним занимает довольно много времени, Dagger — страшный сон для многих. А что если отказаться от него? Но в пользу чего? Koin и другие сервис локаторы — так себе идея, ведь весь injection происходит в рантайме и рано или поздно приложение из-за этого упадет. Может быть писать все руками?

Именно так я подумал и решил реализовать ручной DI в своем небольшом проекте.

Итерация 1: один Gradle модуль, один граф

Концепция такова: у нас есть единый граф для всего приложения, в котором есть все зависимости приложения. Он хранится в application-классе, что дает нам единственность графа для всего приложения. (Почти) все зависимости создаются только по надобности: достигается это путем делегата lazy. Зависимости, которые нуждаются в activity(PermissionHandler), изначально имеют Noopреализацию. Они доставляются только при создании Activity. Естественно, это несет за собой и минусы: что если кто-то возьмет Noopреализацию до замены на нормальную? Это хороший (и пока не решенный) вопрос.

class Graph(private val app: Application) {     val coroutineScope by lazy { CoroutineScope(Dispatchers.IO) }      var permissionHandler: PermissionHandler = PermissionHandler.NoopPermissionHandler     val navController by lazy { createMaterialMotionNavController(app) }     val wallpaperRepository: WallpaperRepository by lazy { WallpaperRepositoryImpl(app, navController) }          // ... }  class WallManApp: Application() {     val graph by lazy { Graph(this) }     override fun onCreate() {         super.onCreate()         // ...     } }

Зависимости без начальной реализации создаются внутри activity. Так же мы прокидываем граф через CompositionLocal в compose для дальнейшего использования:

class MainActivity : ComponentActivity() {     private val graph by lazy {         (this.application as WallManApp).graph     }     override fun onCreate(savedInstanceState: Bundle?) {         super.onCreate(savedInstanceState)         graph.apply {             permissionHandler = AndroidPermissionHandler(this@MainActivity)             // ...         }                  setContent {             CompositionLocalProvider(LocalGraph provides graph) {                 // ...             }         }     } }

Как создаются вьюмодели? Очень просто! Создается extension-функция над графом для создания вьюмодели. Это дает нам разгрузить граф от ненужных функций. Так же провайдить зависимости становится легче, когда эта функция лежит в одном файле с самой вьюмоделью:

fun Graph.MainViewModel() = MainViewModel(wallpapersRepository)  class MainViewModel(     private val repo: WallpapersRepository ) : ViewModel() {   // ... }

Очень элегантно, правда? Все зависимости видны в конструкторе, а их внедрение не доставляет трудностей.

Как же доставить вьюмодель в ui? Здесь тоже все довольно просто. Создаем Composable функцию для предоставления зависимостей:

@Suppress("UNCHECKED_CAST") class ViewModelFactory(val viewModel: () -> ViewModel) : ViewModelProvider.Factory {     override fun <T : ViewModel> create(modelClass: Class<T>): T {         return viewModel() as T     } }  @Composable inline fun <reified T : ViewModel> viewModel(noinline block: @DisallowComposableCalls Graph.() -> T): T {     val graph = LocalGraph.current     return androidx.lifecycle.viewmodel.compose.viewModel(factory = remember { ViewModelFactory { graph.block() } }) } 

Этот подход создает жесткую связь между ui и графом, поэтому мы разделяем экран на две функции: с вьюмоделью и без нее. В моем случае это MVI архитектура:

@Composable fun MainScreen(modifier: Modifier = Modifier) {     val viewModel = viewModel { MainViewModel() }     val state by viewModel.state.collectAsStateWithLifecycle()     MainScreen(state, modifier) }  @Composable private fun MainScreen(   state: MainViewModel.MainScreenState,    modifier: Modifier = Modifier ) {   // ... }

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

fun Graph.WallpaperDetailsViewModel(wallpaperHashCode: Int) =     WallpaperDetailsViewModel(wallpaperHashCode, /* ... */)  class WallpaperDetailsViewModel(     private val wallpaperHashCode: Int,     // ... ) : ViewModel() {     // ... }  @Composable fun WallpaperDetailsScreen(wallpaperHashCode: Int, modifier: Modifier = Modifier) {     val viewModel = viewModel { WallpaperDetailsViewModel(wallpaperHashCode) }     val state by viewModel.state.collectAsStateWithLifecycle()     WallpaperDetailsScreen(state, modifier) }

Однако, такой подход имеет свои недостатки. При росте проекта становится все труднее поддерживать один Gradle-модуль, поэтому следует разделять фичи на отдельные модули.

Исходники итерации 1: gitlab.

Итерация 2: разделение на Gradle модули, 1 граф

Вот здесь все становится интереснее. Так как все фичи разделены на разные модули, мы как-то должны связать их в один граф. Для этого мы разделяем наш начальный граф на интерфейс и реализацию(в :di:api и :di:impl, например). Соответственно все фичи делятся на :api, :impl и :ui(опционально) примерно как на диаграмме:

Как было сказано ранее, все фичи делятся на несколько модулей:

• :api — интерфейсы и extension-фунции/проперти к этим интерфейсам(чтоб жизнь слаще была)

• :impl — реализации интерфейсов из :api

• :ui — опционально, графический интерфейс фичи. Может зависеть от :di:api для внедрения зависимостей во вьюмодели. Этот модуль не зависит от :impl!

В остальном все остается тем же самым.

И снова минусы: при росте проекта граф может сильно разрастись, поэтому его нужно разделить на подграфы.

Исходники итерации 2: gitlab.

Итерация 3: разделение графа на модули

Чтобы основной граф не выглядел так страшно, можно разделить его на feature-модули:

interface Graph {     val coreModule: CoreModule     val wallpapersModule: WallpapersModule     // ... }

Тогда реализация модуля будет выглядеть так:

interface WallpapersModule: CoreModule {     val wallpapersRepository: WallpapersRepository     // ... }  class WallpapersModuleImpl(     coreModule: CoreModule,     application: Application ) : WallpapersModule,     CoreModule by coreModule {   // ... }

Теперь мы можем менять зависимости вьюмодели с графа на соответствующий модуль:

fun WallpapersModule.MainViewModel() = MainViewModel(   wallpapersRepository )  class MainViewModel(     private val repo: WallpapersRepository, ) : ViewModel() {   // ... }

Как сделать так, чтобы можно было запустить фичу без всего графа? Убрать граф из зависимостей фичи. Здесь есть 2 стула варианта.

Вариант 1: прокидывание модуля через Compose

Для каждого модуля будем добавлять CompositionLocal, который будет проброшен где-то сверху compose-дерева.

Рядом с WallpapersModule добавляем соответствующий CompositionLocal:

interface WallpapersModule: CoreModule {     val wallpapersRepository: WallpapersRepository }  val LocalWallpapersModule =    compositionLocalOf<WallpapersModule> {      error("WallpapersModule is not provided")   }

Чтобы CompositionLocals всех модулей подтянулись, нужно создать специальный провайдер для них в :di:api и вставить его в наше Activity:

@Composable fun ProvideGraphModules(content: @Composable () -> Unit) {     val graph = LocalGraph.current     CompositionLocalProvider(         LocalCoreModule provides graph.coreModule,         LocalWallpapersModule provides graph.wallpapersModule,         // ...     ) {         content()     } }  class MainActivity : ComponentActivity() {     private val graph by lazy {         (application as WallManApp).graph     }      override fun onCreate(savedInstanceState: Bundle?) {         super.onCreate(savedInstanceState)          setContent {             CompositionLocalProvider(LocalGraph provides graph) {                 ProvideGraphModules {                     // ...                 }             }         }     } }

Чтобы вызвать эту вьюмодель, нам нужно сменить прошлый вызов новой функцией в :my_feature:ui:

@Composable inline fun <reified T : ViewModel> viewModel(noinline block: @DisallowComposableCalls WallpapersModule.() -> T): T {     return viewModelWithReceiver(LocalWallpapersModule.current, block) }

И создать viewModelWithReceiver в :core:api:

@Composable inline fun <reified T : ViewModel, R> viewModelWithReceiver(     receiver: R,     noinline block: @DisallowComposableCalls R.() -> T ): T {     return androidx.lifecycle.viewmodel.compose.viewModel(factory = remember {         ViewModelFactory {             receiver.block()         }     }) }

С помощью этих изменений мы можем убрать зависимость :di:api из :my_feature:ui. Это дает нам возможность запускать фичу без создания всего графа.

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

Исходники варианта 1: gitlab.

Вариант 2: использовать context receivers

Этот вариант гарантирует нам предоставление зависимостей.

fun Logger.allLogsByTag(tag: String): List<String> {     return allLogs().filter { it.tag == tag } }  context(Logger) fun Storage.storeAppState() {     log("Storage", "Starting storing...")     val logs = allLogsByTag("tag")     // ... }

На момент написания статью context receivers на стадии prototype. Пока эта функция ограничена Kotlin/JVM, а Jetbrains не рекомендуют использовать ее в продакшене:

The feature is a prototype available only for Kotlin/JVM. With -Xcontext-receivers
enabled, the compiler will produce pre-release binaries that cannot be
used in production code. Use context receivers only in your toy
projects. We appreciate your feedback in YouTrack.

Если вы готовы к context receivers, то подключаем флаг в build.gradle.kts:

tasks.withType(KotlinCompile::class.java) {     kotlinOptions.freeCompilerArgs += listOf("-Xcontext-receivers") }

Убираем из composable-функции вьюмодели какие-либо зависимости от графа:

@Composable inline fun <reified T : ViewModel> viewModel(noinline block: @DisallowComposableCalls () -> T): T {     return androidx.lifecycle.viewmodel.compose.viewModel(factory = remember {         ViewModelFactory {             block()         }     }) }

Добавляем контекст в функцию с вызовом вьюмодели в ui:

context(WallpapersModule) @Composable fun WallpaperDetailsScreen(wallpaperHashCode: Int, modifier: Modifier = Modifier) {     val viewModel = viewModel { WallpaperDetailsViewModel(wallpaperHashCode) }     val state by viewModel.state.collectAsStateWithLifecycle()     WallpaperDetailsScreen(state, modifier) }

В месте вызова(в навигации, например) добавляем блок with для добавления контекста:

with(graph.wallpapersModule) {     composable("WallpaperDetails/{hashcode}") {         val hashCode = ...         WallpaperDetailsScreen(hashCode)     }     // ... }

Так как под капотом context receivers — еще один (или несколько) параметр в функции, а модули не являются стабильными, то посмотрим, что нам выдал compose об этой функции:

restartable scheme("[androidx.compose.ui.UiComposable]") fun WallpaperDetailsScreen(   unstable _context_receiver_0: WallpapersModule   stable wallpaperHashCode: Int   stable modifier: Modifier? = @static Companion ) restartable skippable scheme("[androidx.compose.ui.UiComposable]") fun WallpaperDetailsScreen(   stable state: WallpaperDetailsScreenState   stable modifier: Modifier? = @static Companion )

Видим, что composable-функция, использующая context receivers, non-skippable. Критично ли это? Нет, ведь composable-функция, принимающая state — skippable. То есть при обходе дерева compose всегда будет вызывать функцию с вьюмоделью, а функцию со стейтом — только при необходимости. Подробности про оптимизацию compose-кода: статья от Ozon Tech.

Из минусов: context receivers пока нестабильны(ожидается стабилизация после прихода K2 компилятора) и работают только в JVM (то есть нет поддержки IOS и браузера). Если Jetbrains решит изменить способ вызова, то придется адаптировать весь проект под изменения.

Как костыль альтернативное решение — самим добавлять параметры в функции. Например:

context(WallpapersModule) @Composable fun WallpaperDetailsScreen(wallpaperHashCode: Int, modifier: Modifier = Modifier) {     // ... }

Заменяем на:

@Composable fun WallpaperDetailsScreen(   module: WallpapersModule,    wallpaperHashCode: Int,    modifier: Modifier = Modifier ) {     // ... }

Исходники варианта 2: gitlab.

Заключение

Более перспективным вариантом, по-моему, здесь является context receivers, они дают гарантию предоставления зависимостей.

Что мы имеем от этой реализации:

• Разрешение зависимости на этапе компиляции

• Уменьшенное время компиляции по сравнению с Dagger

• Подсветка в IDE при отсутствии каких-либо зависимостей (уменьшение feedback loop)

• Независимость от изменений в Dagger

Про минусы не забываем:

• Возможное падение приложения при использовании CompositionLocal

• Невозможность использовать на context receivers на IOS и в браузере без костылей

Легко ли было реализовать ручной DI? Довольно просто. А было ли нужно? Я оставлю этот вопрос для вас.

Советую ознакомиться с альтернативными реализациями ручного DI:

• Youtube

• Статьи: раз, два

Что делать в вашем проекте — решать прежде всего вам.