Comments 10
Жизненные циклы Views и ViewModels не связаны.
Как раз они связаны. ViewModel живет до onDestroy() в Activity, потом вызывается onCleared().
Что будете делать, когда у разных событий возникнут одинаковые аргументы? Расширять иерархию MyFragmentNavigation абстрактным классом? Кажется тут самое место sealed class. Вы пишите, что получился аналог Rx-BehaviorSubject-a, но RxJava хороша своей расширяемостью. Для ее существует куча операторов, можно и свой какой-нибудь написать. Если речь про взаимодействие Presenter и View не проще использовать Moxy? Там организованы похожие стратегии, которые можно расширять.
Использовать можно хоть sealed class, хоть просто class (но не data class).
Вы пишите, что получился аналог Rx-BehaviorSubject-a, но RxJava хороша своей расширяемостью.
У нас в проекте нет RxJava.
Если речь про взаимодействие Presenter и View не проще использовать Moxy? Там организованы похожие стратегии, которые можно расширять.
Здесь про MVVM, не MPV.
Я предпочитаю, делать, что то вроде такого github.com/Viacheslav01/joom2/tree/master/app/src/main/java/ru/smityukh/joom2/navigation
Есть пара вопросов:
1. Во ViewModel вам нужно показать Snackbar, который привязывается к конкретной View фрагмента. Как это реализовать в вашем случае?
2. Нужно обработать ошибку сети. Данная ошибка одновременно пришла от 5 запросов. Как показать один AlertDialog?
Вы прокидываете навигатор во ViewModel и не важно, где и как навигация будет осуществлена.
Да в этом и смысл
1. Во ViewModel вам нужно показать Snackbar, который привязывается к конкретной View фрагмента. Как это реализовать в вашем случае?
2. Нужно обработать ошибку сети. Данная ошибка одновременно пришла от 5 запросов. Как показать один AlertDialog?
Оба вопроса не имеют отношения к навигации, для них нужен свой механизм.
По факту он может быть калькой с той же навигации, по крайней мере я не вижу никаких затруднений в реализации.
Можно в принципе их развить, почему нет, получится вполне полезное обсуждение.
1) Что значит привязать к конкретной вьюхе? Вы используете снекбары, не только внизу экрана? Но и в других местах? Я за свою практику такого не встречал, но не отрицаю, что возможно где то это очень даже полезно. С своей стороны знаю, что снекбары даже при указании конкретной вьюхи все равоно будут искать подходящую вьюху по их понятиям.
2) Не совсем понятно с вопросом, т.е. я не понимаю как одна технология передачи сообщения в отличии от другой решает проблему объединения и отображения ошибок?
Оба вопроса не имеют отношения к навигации, для них нужен свой механизм.
Статья о прокидывании событий, а не о навигации. Навигацией занимается отдельный Навигатор. Поэтому и вопросы такие :)
Вообще, сама навигация происходит (должна) от одного фрагмента/активити к другому фрагменту/активити, то есть от одной View к другой. ViewModel — слой, отвечающий за данные и бизнес-логику и она не должна сама производить навигацию (конечно, разработчики могут делать что угодно и внедрять навигаторы в любое место приложения, это вопрос больше к личному предпочтению разделения отвественности, не будем холиварить на эту тему :).
Мы не производим навигацию между View(Fragment/Activity) из ViewModel, так как у них разные зоны ответственности. Вместо этого, мы отправляем события во View, в котором есть Navigator, который непосредственно управляет навигацией. И далее, если событие навигационное, с помощью Navigator-a открываются другие Fragments/Activities, а если событие локальное, но связанное с фреймворком андроид – показать Alert, Snackbar, запрос на системные пермишены – то такие события обрабатываются самим фрагментом.
Я исхожу из другого подхода, навигация как раз зона ответственности бизнес логики, а не представления. Так же как и вызов общей функциональности, такой как аутентификация, сообщения об ошибках и т.п.
Опять же такой подход значительно упрощает архитектуру, убирает лишние связи и сокращает бойлерплейт.
Позволю себе небольшое уточнение. Бизнес-логика (ViewModel) отвечает за то, в какой момент и куда необходимо переключить внимание пользователя. Грубо говоря, она просто указывает пальцем на место, которое нужно показать (разумеется, абстрактно, а не указывая конкретные классы активити/фрагментов).
В то время как представление, совершенно не рефлексируя, производит переключение в указанное место. То есть, это исполнитель, которому думать вообще не нужно.
Так что я скорее на стороне Viacheslav01.
1. Во ViewModel вам нужно показать Snackbar
И такую постановку задачи лично я считаю неверной. ViewModel максимум можно поставить задачу "Вывести сообщение пользователю". Реализация через Snackbar — подробности уровня представления.
Отправка событий из ViewModel в Activity/Fragment в MVVM