Остается не раскрытым вопрос, а что если у нас есть bottom navigate и нужно сохранят состояние viewmodel между несколькими экранами, тут хочешь не хочешь но запихаешь ее в havigate что бы она не пересоздавался при переходе между разными пунктами нижней навигации
Ну в принципе я бы в любом случае рекомендовал по возможности использовать отдельную ViewModel для каждого экрана, однако иногда и правда бывают случаи, где нужно иметь объединенную. В такой ситуации я бы создал viewModel в MainScreen (в котором расположена навигация) и передал бы ее в Navigation Composable функцию
Вопрос про устройство структуры пакетов: уже давно придумали удобную модель где есть пакет с названием екрана, и в него закидывается все что с ним связано. Зачем создавать отдельный пакет только для моделей и для скринов и тд? В будущем такое только затруднит понимание и поддержку.
Есть разные подходы по структуризации пакетов и выбор каждого разработчика что конкретно использовать. В данном проекте из-за небольшого объема такая структура позволяет избежать большого количества пакетов и выглядит более компактно. Но я согласен, что в более крупных проектах использовать feature-oriented полход будет удобнее
Уже немного сложно, по сравнению с предыдущими 3 уроками. Уловить мысль уже труднее. Понятно, что это более правильное viewmodel вынести отдельно, но блин как же от этого разрастается код. И прямо легко запутаться.
Конкретно в проекте, который упоминается в видео нет, но скоро DI там появится. А также скоро будет отдельное видео про DI и его применение. Рекомендую подписаться чтобы не пропустить
Прав. Автору и не только автору нужно научиться использовать стейтФлоу во вьюмодели и не использовать ничего с .compose в этой вьюмодели. Такое ревью не проходит. collectAsState на UI делаешь и все. mutableState и тп только на UI используется, но не вьюмодели. Юзать .compose во вьюмодели значит нарушать Separation of Concerns. Компоузовый стейт это часть юай, мы из юая только слушаем изменения логики во вьюмодели при помощи collectAsState()
@@gala3941 Ничего не мешает использовать компоузовский state во вью модели при условии использования этой вьюмодели для конкретного скрина, однако да, использовать stateflow банально удобнее. Изменение StateFlow точно таким же образом вызовет рекомпозицию компоузебла
@@programmerc1178 Я уже наелся переписывать это на проекте под стейтфлоу ввиду ряда багов, когда ты на юае получаешь совсем не то что ожидаешь при смене конфигурации и лишние рекомпозиции, лучше сразу сделать нормально и придерживаться этого. Очень плевался когда кто-то заапрувил типа который заюзал во вьюмодели mutableStateListOf на айтемы. Либо дата классом этот стейт через .апдейт и копи обновлять, либо через отдельные проперти как раньше всегда делали на хмл, не нужно эти приколы юая во вьюмодель тащить
@@programmerc1178 я уже наелся багов, когда н.п. один Алеша юзает вместо стейтфлоу mutableStateListOf на список во вьюмодели и прочие прелести, а потом у тебя десяток багов изза ломаного состояния на юае. В итоге берешь и переписываешь все полностью на стейтФлоу как положено. .compose если присутствует то только на самом юае. Либо стейт через дата класс с дефолтными значениями, апдейт и копи обновляется, либо как в хмл проектах по старому, никаких .compose не должно быть. Оставь эту злую практику бизнесменам с Юдеми и индусам
![Что такое корутины? [RU] / Мобильный разработчик](/img/n.gif)
👍👍👍
Остается не раскрытым вопрос, а что если у нас есть bottom navigate и нужно сохранят состояние viewmodel между несколькими экранами, тут хочешь не хочешь но запихаешь ее в havigate что бы она не пересоздавался при переходе между разными пунктами нижней навигации
Ну в принципе я бы в любом случае рекомендовал по возможности использовать отдельную ViewModel для каждого экрана, однако иногда и правда бывают случаи, где нужно иметь объединенную. В такой ситуации я бы создал viewModel в MainScreen (в котором расположена навигация) и передал бы ее в Navigation Composable функцию
Вопрос про устройство структуры пакетов: уже давно придумали удобную модель где есть пакет с названием екрана, и в него закидывается все что с ним связано. Зачем создавать отдельный пакет только для моделей и для скринов и тд? В будущем такое только затруднит понимание и поддержку.
Есть разные подходы по структуризации пакетов и выбор каждого разработчика что конкретно использовать.
В данном проекте из-за небольшого объема такая структура позволяет избежать большого количества пакетов и выглядит более компактно. Но я согласен, что в более крупных проектах использовать feature-oriented полход будет удобнее
Уже немного сложно, по сравнению с предыдущими 3 уроками. Уловить мысль уже труднее.
Понятно, что это более правильное viewmodel вынести отдельно, но блин как же от этого разрастается код. И прямо легко запутаться.
Важно несколько раз прогнать этот момент у себя в голове, чтобы была понятна структура. В дальнейшем это только поможет коду
Di тут есть?
Конкретно в проекте, который упоминается в видео нет, но скоро DI там появится. А также скоро будет отдельное видео про DI и его применение. Рекомендую подписаться чтобы не пропустить
это ведь MVI архитектура?
Нет, MVVM
я возможно не прав, но мне кажется, что это вызывает излишние рекомпозиции. Это так или нет? Объянсите пожалуйста
Это не так. Рекомпозиция возникает у случае изменения state независимо от того откуда он был изменён, поэтому лишних рекомпозиций не будет.
Прав. Автору и не только автору нужно научиться использовать стейтФлоу во вьюмодели и не использовать ничего с .compose в этой вьюмодели. Такое ревью не проходит. collectAsState на UI делаешь и все. mutableState и тп только на UI используется, но не вьюмодели. Юзать .compose во вьюмодели значит нарушать Separation of Concerns. Компоузовый стейт это часть юай, мы из юая только слушаем изменения логики во вьюмодели при помощи collectAsState()
@@gala3941 Ничего не мешает использовать компоузовский state во вью модели при условии использования этой вьюмодели для конкретного скрина, однако да, использовать stateflow банально удобнее.
Изменение StateFlow точно таким же образом вызовет рекомпозицию компоузебла
@@programmerc1178 Я уже наелся переписывать это на проекте под стейтфлоу ввиду ряда багов, когда ты на юае получаешь совсем не то что ожидаешь при смене конфигурации и лишние рекомпозиции, лучше сразу сделать нормально и придерживаться этого. Очень плевался когда кто-то заапрувил типа который заюзал во вьюмодели mutableStateListOf на айтемы. Либо дата классом этот стейт через .апдейт и копи обновлять, либо через отдельные проперти как раньше всегда делали на хмл, не нужно эти приколы юая во вьюмодель тащить
@@programmerc1178 я уже наелся багов, когда н.п. один Алеша юзает вместо стейтфлоу mutableStateListOf на список во вьюмодели и прочие прелести, а потом у тебя десяток багов изза ломаного состояния на юае. В итоге берешь и переписываешь все полностью на стейтФлоу как положено. .compose если присутствует то только на самом юае. Либо стейт через дата класс с дефолтными значениями, апдейт и копи обновляется, либо как в хмл проектах по старому, никаких .compose не должно быть. Оставь эту злую практику бизнесменам с Юдеми и индусам