Не с MVVM, а с выделением в отдельное поле, вместо объединения в один class. Самое простое валидация по полям login, password и включение кнопки "войти". Когда они у вам в одном классе, то достаточно написать расширение для этого класса. А когда они разделены, вы либо их будете в UI проверять, что его будет нагромождать, либо будете создавать новое поле, которое будет подписываться на нужные поля.
Это больше дело привычки и удобства, чем приверженность какой-то архитектуре. Разделение на отдельные поля действительно удобен, если используешь databinding. А в Compose уже не столь удобно.
За это большое спасибо, стоит изучить и перейти уже на decompose, ибо с google navigation не так удобно
ViewModel'и можно и не выносить наружу, достаточно лишь передать данные внутрь экрана. Ведь viewmodel`и наврятли придется использовать сразу с несколькими экранами.
Не понял, что это за приватные экраны? Вы в одном модуле реализуете несколько экранов и навигацию между ними?
Под отдельно-вынесенной навигацией я подразумевал, то о чем писал выше. Отдельный модуль или модули, в которых собрана вся навигация по приложению. То есть только эти модули знают где какой экран находится и как к нему добраться. А экран лишь дергает параметры из функции, которые и передает ему навигация.
Модуль навигации должен состоять из таких вызовов: composable(route = LibraryNavTarget.Chapters.route, content = { val item = nav.getStringElement(MangaItem) ?: "" val viewModel = chaptersViewModel(item) ChaptersScreen(viewModel, nav::navigateUp) } )
А экраны так: @Composable fun ChaptersScreen( viewModel: ChaptersViewModel, navigateUp: () -> Unit) { ...
Не понимаю, почему один модуль (экран) начнет знать про другие модули (экраны) в моем видении такой навигации?
Супер-модуль навигации? Все же наверное это плохо будет. А если разбить на подмодули?
Но у вашего похода, так же плохо будет понятен граф переходов. Ведь вы вызываете метод перехода у конкретного UI элемента. На сложном экране будет проблемно искать эти вызовы. И у вас модуль экрана знает об Api другого экрана, что тоже усложнит понимание. Все же отдельно-вынесенная навигация должна быть понятнее.
Сомневаюсь, что появится одно решения для этой проблемы. Сколько не гугли, а всех свое видение и использует его только автор.
Согласен, что модуль с навигацией будет только расти при росте экранов, это неизбежно, но при это имеем полное представление и всей структуре приложения в одном модуле, но не раскиданное по другим.
Не понимаю только, как одни экраны узнают про другие, если использовать примерно такой шаблон:
fun SomeScreen ( navigateToA: (SomeParametr: String) -> Unit, ...) { } (код могу только так вставить)
Не с MVVM, а с выделением в отдельное поле, вместо объединения в один class.
Самое простое валидация по полям
login,passwordи включение кнопки "войти".Когда они у вам в одном классе, то достаточно написать расширение для этого класса. А когда они разделены, вы либо их будете в UI проверять, что его будет нагромождать, либо будете создавать новое поле, которое будет подписываться на нужные поля.
Это больше дело привычки и удобства, чем приверженность какой-то архитектуре. Разделение на отдельные поля действительно удобен, если используешь databinding. А в Compose уже не столь удобно.
За это большое спасибо, стоит изучить и перейти уже на decompose, ибо с google navigation не так удобно
Спасибо за инструменты.
Не представляю, какая каша может получится с таким количеством модулей ))
Спасибо за материал!!!
Граф зависимости модулей вы руками строите или есть удобные инструменты для этого?
Это compileSdk, а не minSdk, который и ограничивает минимальную версию для запуска
В целом вы правильно поняли меня.
ViewModel'и можно и не выносить наружу, достаточно лишь передать данные внутрь экрана. Ведь viewmodel`и наврятли придется использовать сразу с несколькими экранами.
Не понял, что это за приватные экраны? Вы в одном модуле реализуете несколько экранов и навигацию между ними?
Под отдельно-вынесенной навигацией я подразумевал, то о чем писал выше. Отдельный модуль или модули, в которых собрана вся навигация по приложению. То есть только эти модули знают где какой экран находится и как к нему добраться.
А экран лишь дергает параметры из функции, которые и передает ему навигация.
Модуль навигации должен состоять из таких вызовов:
composable(route = LibraryNavTarget.Chapters.route,content = {
val item = nav.getStringElement(MangaItem) ?: ""
val viewModel = chaptersViewModel(item)
ChaptersScreen(viewModel, nav::navigateUp)
} )
А экраны так:
@Composable fun ChaptersScreen(viewModel: ChaptersViewModel,
navigateUp: () -> Unit) { ...
Не понимаю, почему один модуль (экран) начнет знать про другие модули (экраны) в моем видении такой навигации?
Супер-модуль навигации? Все же наверное это плохо будет. А если разбить на подмодули?
Но у вашего похода, так же плохо будет понятен граф переходов. Ведь вы вызываете метод перехода у конкретного UI элемента. На сложном экране будет проблемно искать эти вызовы. И у вас модуль экрана знает об Api другого экрана, что тоже усложнит понимание.
Все же отдельно-вынесенная навигация должна быть понятнее.
Сомневаюсь, что появится одно решения для этой проблемы. Сколько не гугли, а всех свое видение и использует его только автор.
Согласен, что модуль с навигацией будет только расти при росте экранов, это неизбежно, но при это имеем полное представление и всей структуре приложения в одном модуле, но не раскиданное по другим.
Не понимаю только, как одни экраны узнают про другие, если использовать примерно такой шаблон:
fun SomeScreen ( navigateToA: (SomeParametr: String) -> Unit, ...) { }
(код могу только так вставить)
А как вам такой вариант реализации многомодульности:
Каждая такая фича (отдельный экран) ничего не знает о способе навигации, но знает куда ему надо.
И есть отдельный модуль, в котором описана структура приложения и всей навигации.
Интересно. Просто и понятно. С удовольствием ознакомлюсь со второй статьей про главный цикл Android