Тут спор так и не закончился, где же все таки лучше?)

думаю каждый должен ответить для себя сам, вот это сообщение раскрывает текущую ситуацию:
"тут есть мнения и нет консенсуса, поищите по истории чата. Основные позиции это "кто делает действие, тот и знает, на каком ему треде выполняться" vs "кто вызывает действие, тот и знает, где ему выполняться" с разными вариациями. Лично мне нравится observeOn писать там, где идёт подписка, и subscribeOn там, где создаётся сам Observable."

Вообще я считаю, что консенсус быть должен. Здравый смысл подсказывает, что вызывающему должно быть интересно только то, в каком потоке придет результат, а по каким потокам будет гулять функция, которую вызвали, это её детали реализации. На корутинах особенно это видно.

тогда при использовании MVP presenter делает observeOn, а репозиторий ответ с сети принимает subscribeOn ?

Ага

Имхо, куда лучше иметь некий инструмент для контроля всего этого.
Банальный SchedulerProvider в интеракторах отлично справляется.

ну вот консенсуса и нету) мне тоже более понятно когда в презентере и репозитории

Как то разбросанно получается, rx длинные итак читать сложно

Ну и не очень хорошо, когда идеологически одинаковая логика разбредается по разным местам.

Вместо "поменять поток вот тут" будет "поменять тут или вон там"

В Москве таксисты отказываются ехать в китай город... 😊 А в аптеках кончились маски, но ничего страшного, вместо масок можно на голову надеть кастрюлю. Эффект будет тот же 😂

а можно пример кода?

Под рукой конкретно такого нет, но суть почти как тут:

https://github.com/android10/Android-CleanArchitecture/blob/master/domain/src/main/java/com/fernandocejas/android10/sample/domain/interactor/UseCase.java

В интерактор передаётся сущность, которая знает где обработать сам запрос и где обработать результат. Почти всегда передаётся один и тот же (ио + мейн), но в случае чего всегда можно заменить.

спасибо, этот пример видел, хотел ещё реализацию посмотреть

и мои пять копеек - Room и Retrofit дают вполне удобные инструменты, чтобы совсем спрятать потокинг от разработчика - останется только решить, хочешь ли ты, чтобы бизнес-логика работала на определенных потоках (api.getMyShit().observeOn(domainThreadScheduler)) или пофиг - поэтому я тоже за указание потока как можно ближе к исполнителю

Так, ну если спор закончен, то я бы хотел спросить про MVI, насколько я понял там есть некий объект state на который подписывается вью. В чем принципиальное отличие от MVP у которого будет один метод setState()? Ну или я может просто все неправильно понял про MVI)

MVI довольно неудачное название для этой архитектуры, т.к. сразу идёт сравнение с MVP\MVVM.
На деле вся суть именно в работе через стейт, в SSOT, редюсер и вся эта шняга.

Как ты это будет связывать с View уже дело десятое.

Vally Solo, пожалуйста, нажмите на кнопку ниже в течение указанного времени, иначе вы будете кикнуты. Спасибо! (60 сек)

есть у меня fragment + viewModel, но сейчас сильно перегруженные, fragment 600cтр, Vm = 300стр, короче все херово, с сервером работы нет, только с бд, по бд кода мало, все во viewModel, там все норм. почти весь код это логика view-шек, то открой , то спрячь. тут текст так покаж, там так, короче как это лучше всего можно распределить по классам, и вообще как это делается

Есть активность -> добавляется фрагмент A методом replace
У этого фрагмента A есть view pager -> соответственно два фрагмента добавляются используя child fragment manager
Далее я из фрагмента A перехожу в фрагмент B (добавляю в стек)
В фрагмент B я добавляю(тоже replace) дочерний фрагмент (пусть будет C)
У фрагмента C также есть вью пейджер в которых 2 фрагмента - также юзаю child fragment manager.
Проблема: мне нужно из фрагмента C вернуться на A. Когда я это делаю, то фрагмент A инициализируется(все методы жизненого цикла отрабатывают), но не показывается. В чем может быть причина?