Комментарии 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.
Вы прокидываете навигатор во ViewModel и не важно, где и как навигация будет осуществлена.
Есть пара вопросов:
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 — подробности уровня представления.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Местоположение
Россия
Сайт
job.homecredit.ru
Численность
5 001–10 000 человек
Дата регистрации

Блог на Хабре