Комментарии 23
Зачем LiveData в вашем случае? Уже есть Flow, который также работает на скоупе жизненного цикла… Как плюс — отсутсвие маппинга Flow/Rx <-> LiveData.
Но мне кажется, что LiveData во ViewModel удобнее и проще
Вот тут хотелось бы развёрнуто… Просто я вижу много примеров как под копирку, что во вью слое используется LiveData и не могу понять преимущества.
А с учётом того, что Гугл уже активно пиарит и поддерживает корутины, то будет также активно пиарить и Flow(и судя по последним коммитам Flow уже выходит из стадии Experimental), а LiveData они задиприкейтят через какое-то время..
Здесь и видна разница между Flow и LiveData. Это разного порядка инструменты.
Flow — просто реактивный поток, способ организации следующих друг за другом событий. Он ничего в себе не хранит и при следующей подписке, в общем случае, запустит заложенный в него код заново.
LiveData — это mutable storage (цитата с IO19). Его задача — отдать последнее известное ему значение. В случае конвертации toLiveData() — последний отданный flow результат.
Итого, предположим, у Вас сетевой запрос завернут в flow{}. Без конвертации в LiveData внутри ViewModel, этот запрос будет выполняться при каждом, например, повороте экрана. LiveData решает в том числе и эту проблему.
а LiveData они задиприкейтят через какое-то время..Нет. На IO уже не один раз говорили, что это разного рода инструменты с разным назначением. Потому деприкейт если и будет, то очень не скоро.
Поспорю)
LiveData — это mutable storage
Всё это есть в любой реактивщине. В Rx — всякие PublishProcessor/BehaviorProcessor и т.д.(бывшие xxxSubject)
В Flow — пока ещё ConflatedBroadcastChannel и скорый StateFlow
К тому же есть ViewModel, которая также переживает смену конфигурации и прочее.
Плюс ко всему, LiveData используется не только как прокладка между Rx и Flow.
Например, как управляющая компонента. Или в составе той же paging library.
ConflatedBroadcastChannel и скорый StateFlowВ них еще не скоро будет интеграция с LifeCycleOwner и прочими вещами. Всё-таки Flow — часть Kotlin Coroutines, а не Android. А даже если появится, то будем использовать прокладку в виде еще одного Flow вместо LiveData так как хранить состояние в UseCase не всегда нужно и редко полезно.
К тому же есть ViewModelВы опять смешиваете инструменты)
ViewModel сама по себе не решает задачу управления View в рамках жизненного цикла. Этим и занимается LiveData. На ViewModel же ложится задача переносить эти LiveData и содержать логику, которая управляет данными в LiveData.
Оценивайте тенденции) Лично я вижу, что скорость принятия и адаптации корутин очень быстрая. А появление LiveData ждали очень много времени.
Rx я думаю, тоже скоро начнут забывать… А вот у Flow есть очень много шансов.
Даже с учётом экспериментального статуса уже сейчас есть начальная поддержка ЖЦ хотя бы для автоматической отписки.
А даже если появится, то будем использовать прокладку в виде еще одного Flow вместо LiveData так как хранить состояние в UseCase не всегда нужно и редко полезно.
Ну тут не очевидно, а зачем хранить промежуточное состояние в LiveData во ViewModel? Зачем этот промежуточный слой хранения? Состояние хорошо бы хранить только в репозитории, но хотя это добавляет проблему лишних цепочных преобразований данных при смене конфигурации.
Вы опять смешиваете инструменты
Я не смешиваю, просто выше была на мой взгляд не совсем верная формулировка, что LiveData переживает ЖЦ, но она не может его переживать просто так) Это контейнер, где она хранится переживает конфигурации.
Rx я думаю, тоже скоро начнут забывать…Если Вы о RxJava от ReactiveX, то не скоро. Я хоть и сам широко использую Flow и корутины, но вакансий, где требуют RxJava и ее сторонников на руководящих должностях еще много. Людям не просто отпускать привычное.
Зачем этот промежуточный слой хранения?Потому, что нужно разделять бизнес-логику и презентационную логику. Состояние далеко не всегда хорошо хранить в репозитории из-за того, что большинство операций повторяемые. Иначе это мало будет отличаться от поделок на EventBus 5 летней давности.
на мой взгляд не совсем верная формулировкаТут согласен. LiveData, скорее, работает с ЖЦ Observer. Обычно это View, однако та же Navigation Library предлагает интересные приемы с LiveData.
Оценивайте тенденции)Да, есть такая тенденция. Но до ее реализации еще далеко. А до тех пор стабильнее LiveData для выше обозначенных задач нет ничего, и с ней в прод еще ходить как минимум год.
Людям не просто отпускать привычное.
Как вы можете отпустить привычное, когда проект просто огромный? А дописывать новый функционал на корутинах создаст только большие проблемы.
Но речь шла именно о новых проектах. Тут, скорее, либо инерция, либо попытка доказывать профессионализм на волне чьего-то успеха.
Но тут не совсем понятно, как передавать параметры, например, если View фрагмента состоит из нескольких layout, и одному из них надо запустить команду с параметрами другого layout
Первый ответ со стеф оверфлоу) bind:viewModel="@{viewModel}" — если конечно я правильно понял вопрос
Также целесообразно использовать DataBinding везде, например, в сложных списках, в общем, BindingAdapters всегда вылезают.
Адаптеры нужны для чего-то специфического, например засетить картинку в ImageView. Адаптеры же RecyclerView засечиваются напрямую, он же работает через сеттеры обычные. Кидайте хоть TextWatcher из ViewModel
Архитектура и дизайн Android приложения (мой опыт)