ЕГ
объясняю почему
Size: a a a
2020 November 28
VP
как ты будешь это шарить без di? или хотя бы сервис локатора
У меня будет синглтон, в котором будут лежать модули в маке со скоупами, если кратко
ЕГ
500 экранов, даже если не будет кодогенерации сборка +15 минут
VP
без даггера не обойтись
Можешь уточнить в каких проектах
OP
без даггера не обойтись
А как же koin?)
ЕГ
придется распиливать 500 экранов на многомодульность
VP
А как же koin?)
+))
ЕГ
даггер единственный di который поддерживает многомодульность через component dependencies
ЕГ
koin не поддерживает многомодульность
SV
А как же koin?)
потонешь в бойлерплейте =)
ЕГ
а если не будет многомодульонсти, будет жопа с билда таймрм
I
koin не поддерживает многомодульность
??
ЕГ
и тем более koin это сервис локатор а не di
I
koin не поддерживает многомодульность
modules {
module из другого модуля
}
?
module из другого модуля
}
?
VP
а если не будет многомодульонсти, будет жопа с билда таймрм
При наличии множества библиотек с кодогеерацией возможно
ЕГ
При наличии множества библиотек с кодогеерацией возможно
а без них некуда
ЕГ
как минимум Room
VP
и тем более koin это сервис локатор а не di
Не все ли равно? Главное есть IoC контейнер. Зачем держаться за определенный подход, если и другой подход так же решает эту задачу?
С
Как выглядит класс репозитория, когда заводить БД избыточно, а грузить каждый раз данные с бекенда, при открытии экрана не хочется?
Я сейчас прямо в репозитории кеширую полученные объекты, получается так:
Нормальный вариант?
Я сейчас прямо в репозитории кеширую полученные объекты, получается так:
fun getAccount(): Single<Account> =
if (accountCache != null)
Single.just(accountCache)
else api.getAccount("")
.doOnSuccess { accountCache = it }
Нормальный вариант?
ЕГ
Не все ли равно? Главное есть IoC контейнер. Зачем держаться за определенный подход, если и другой подход так же решает эту задачу?
обмазывание некрасивым кодом