Не по теме, но почему бы не объединить все сингл лайв ивенты в один sealed?
Это хорошая идея, в соседней ViewModel я так и сделал)
Почему бы mvi уже бы не заюзать?)
bookingDataLiveData можно кастнуть к MutableLiveData и менять. там вроде должен быть метод для предотвращения этого
Не люблю MVI Да и в проекте слишком много говнокода, чтобы переписывать его на MVI На MVVM как-то попроще будет
Метод тоже кастануть мажно
> в соседней ViewModel так и сделал > не люблю mvi Ты ж в курсе, что ты почти mvi сделал? Осталось только процедуры превратить в одну, сделав msg.
ну conflatedBroadcastFlow.asFlow() делает мутабельный флоу иммутабельным, такое же для ливдаты есть, чтобы её немутабельной сделать
Да, я знаю, что это +1 шаг к MVI, но все же стейт не единый
Поздно уже не любить MVI
Почему же?) Вот когда все перейдут на Jetpack Compose, тогда уже поздно думаю)
Потому что сейчас разработка возращается к функциональному программированию и однонаправленным архитектурам. Это как не любить Rx 5 лет назад.
Бывают огромные экраны, где даже больше полей. Соответственно и лайвдат больше. Рекомендуется в таких случаях создавать не одну ViewModel, а несколько ViewModels для одного экрана.
А стоит ли запариваться по инкапсуляции и возвращать LiveData, если все равно можно кастануть объект?
Мне кажется, в данном случае во ViewModel можно объявить по одному полю для каждой LiveData. И не делать её приватной. Например: val someError = MutableLiveData<String>() Это поле Вы и будите использовать во вьюмоделе, для передаче ей значения. И во фрагменте(активити) - для получения значения.
Можно вообще рефлексию юзать и дергать любое приватное поле, суть то не в этом. Интерфейс это инструмент высокоуровневого проектирования, если ты что-то кастуешь, то скорее всего идешь против задумки "архитектора", в данном случае нарушаешь UDF.
А в чем профит нескольких ВМ? со стороны совет выглядит как, обычные SRP / SOC принципы, т.е. можно разделить просто раскидав код по разным сущностям(классам), при этом оставаясь в рамках одной ВМ, цель последней - просто переживать жц вью.
вот вернут тебе не MutableLiveData, а ActualLocationLiveData и сиди кастуй туда-сюда)
Отрицание - это как раз первая стадия принятия
представьте, что у Вас перегруженный большой экран. А ещё и detect + ktlint подключены, которые ограничивают Вас от написания чрезмерно больших классов. В таких случаях удобно разделить данный класс на несколько. "совет выглядит как, обычные SRP / SOC принципы" - Вам этого не достаточно?
вы плохо прочитали мое сообщение
Обсуждают сегодня