AC
ту да же про вектор (svg)
Size: a a a
2020 August 21
EP
Вектор неплохо работает. Даже лучше чем на 5-ке иногда. Помню был баг с градиентами
2020 August 22
S
Singular
Как идея использовать Dagger для инициализаии ViewModel?
Хочу использовать ViewModel и Activity в 3 фрагментах
Хочу использовать ViewModel и Activity в 3 фрагментах
У меня в репе ViewModel инициализируется в DI (выше ссылку давал). Посмотри, вдруг зайдет.
S
У меня в репе ViewModel инициализируется в DI (выше ссылку давал). Посмотри, вдруг зайдет.
дай ссылку, а то найти не могу
S
Спасибо
I
Неужели это
лучше чем это 🤔
override fun onCleared() = super.onCleared().also {
selectionDisposable.dispose()
}лучше чем это 🤔
override fun onCleared() {
super.onCleared()
selectionDisposable.dispose()
}S
Неужели это
лучше чем это 🤔
override fun onCleared() = super.onCleared().also {
selectionDisposable.dispose()
}лучше чем это 🤔
override fun onCleared() {
super.onCleared()
selectionDisposable.dispose()
}То же самое. Это уже чисто вкусовщина)
КП
override fun onCleared() = super.onCleared().also {
selectionDisposable.dispose()
}
Когда очень хочется покотлить
selectionDisposable.dispose()
}
Когда очень хочется покотлить
KD
Неужели это
лучше чем это 🤔
override fun onCleared() = super.onCleared().also {
selectionDisposable.dispose()
}лучше чем это 🤔
override fun onCleared() {
super.onCleared()
selectionDisposable.dispose()
}Какой ужас 😳
I
Еще по поводу
Зачем в data класс добавлять методы, приват. свойства, конструктор, когда можно написать вот так:
ChooseShopListItem. Зачем в data класс добавлять методы, приват. свойства, конструктор, когда можно написать вот так:
data class ChooseShopListItem(
val name: String,
val thumbnail: String?,
val address: String,
val navigationQuery: String?)
fun Shop.toChooseShopListItem() = ChooseShopListItem(
name = name?.ifBlank { null } ?: "No name",
thumbnail = photos.getOrNull(0)?.thumbnail?.ifBlank { null },
address = getAddress(),
navigationQuery = getNavigationQuery())
I
Ваш Item это просто произведение более простых типов
зачем вы все усложняете своим ооп)
type ChooseShopListItem = String * String? * String * String?
зачем вы все усложняете своим ооп)
S
Еще по поводу
Зачем в data класс добавлять методы, приват. свойства, конструктор, когда можно написать вот так:
ChooseShopListItem. Зачем в data класс добавлять методы, приват. свойства, конструктор, когда можно написать вот так:
data class ChooseShopListItem(
val name: String,
val thumbnail: String?,
val address: String,
val navigationQuery: String?)
fun Shop.toChooseShopListItem() = ChooseShopListItem(
name = name?.ifBlank { null } ?: "No name",
thumbnail = photos.getOrNull(0)?.thumbnail?.ifBlank { null },
address = getAddress(),
navigationQuery = getNavigationQuery())
Можно, только зачем? Смысл этого класса не в данных, а в их применении на вью. Но вот про вычислиение один раз - мысль интересная 🤔
S
Ваш Item это просто произведение более простых типов
зачем вы все усложняете своим ооп)
type ChooseShopListItem = String * String? * String * String?
зачем вы все усложняете своим ооп)
Суть в том, чтобы не вью решал куда и какие поля в неё класть, а это стейт-класс
S
Чтобы под тесты завести
S
Но согласен, нужно этот айтем переработать
AI
Суть в том, чтобы не вью решал куда и какие поля в неё класть, а это стейт-класс
Так это же презентер. У понятия "Стейт" есть укоренившееся значение - мешок с данными.
S
Так это же презентер. У понятия "Стейт" есть укоренившееся значение - мешок с данными.
Ну ливдата накладывает свои ограничения...
Задача: изменить View со стейта А на стейт Б, но оставить вью тупой (без логики). Имеем ViewModel и LiveData. Ссылки на вью у нас нет (это противоречит самой идее ViewModel).
Я пришел к такому решению - по сути паттерн "Команда". Все что знает View - по приходу стейта нужно сделать его apply на себя.
Сами стейты и ViewModel легко покрываются тестами (можно даже ещё больше View отупить).
Какой вариант вы предлагаете для отупения View, и подведения логики представления под юнит тесты по максимуму? )
Задача: изменить View со стейта А на стейт Б, но оставить вью тупой (без логики). Имеем ViewModel и LiveData. Ссылки на вью у нас нет (это противоречит самой идее ViewModel).
Я пришел к такому решению - по сути паттерн "Команда". Все что знает View - по приходу стейта нужно сделать его apply на себя.
Сами стейты и ViewModel легко покрываются тестами (можно даже ещё больше View отупить).
Какой вариант вы предлагаете для отупения View, и подведения логики представления под юнит тесты по максимуму? )
AI
Ну ливдата накладывает свои ограничения...
Задача: изменить View со стейта А на стейт Б, но оставить вью тупой (без логики). Имеем ViewModel и LiveData. Ссылки на вью у нас нет (это противоречит самой идее ViewModel).
Я пришел к такому решению - по сути паттерн "Команда". Все что знает View - по приходу стейта нужно сделать его apply на себя.
Сами стейты и ViewModel легко покрываются тестами (можно даже ещё больше View отупить).
Какой вариант вы предлагаете для отупения View, и подведения логики представления под юнит тесты по максимуму? )
Задача: изменить View со стейта А на стейт Б, но оставить вью тупой (без логики). Имеем ViewModel и LiveData. Ссылки на вью у нас нет (это противоречит самой идее ViewModel).
Я пришел к такому решению - по сути паттерн "Команда". Все что знает View - по приходу стейта нужно сделать его apply на себя.
Сами стейты и ViewModel легко покрываются тестами (можно даже ещё больше View отупить).
Какой вариант вы предлагаете для отупения View, и подведения логики представления под юнит тесты по максимуму? )
Так сделайте презентер или назовите как хотите. Просто отдаленный класс, или вообще функция. Просто чтобы у состояния не было API. Типа fun Actions.apply(state)
AI
Или вообще operator fun Actions.invoke(State)