представьте приложение разбитое на 3 независимых модуля, и каждый модуль юзает только свои данные, и данные смежно слоя вниз, и никак иначе

просто странно относить адаптеры для списка куда-то кроме presentation

кстати есть ещё адаптеры и для ретрофита например, на сериализацию и десериализацию данных, и это уже 100% слой data

вообще адаптер - это просто патерн, по-моему странно будет его определять ситуативно)

это раньше был просто паттерн, сейчас это обязательная фигня для списков по сути

про дату я поправил, написал об этом ниже

ну эта фигня реализуется через паттерн, как и интент - по сути, самый обычный паттерн, а когда спросишь - в первую очередь будут говорить о его роли в андроиде)

если раньше с ListView всё делали кто как хочет эти данные, то с RecyclerView это довольно унифицировано сейчас, и как можно даже пусть и какую-то utils штуки работающую со View отнести куда-то в другой слой, вы можете это отнести к utils слоя presentation например, но это точно presentation

это звучит как какие-то мысли вслух или вода какая-то )) есть факты просто, я их выше описал )

ну ты просто привел частные случаи реализации этого паттерна, кароч не хочу холиварить, я уже во всем разобрался)

Точно будет больше вопросов если вы скажете что adapter это domain или data, если вообще не скажут вам что вы нарушаете концепт, если вообще планируется его придерживаться

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

вообще паттерн это не реализация, и она не относится к коду и слоям вообще, паттерн это по сути пример(шаблон в переводе), а уже какая будет реализация, там и станет ясно к какому слою отнести, я думаю так будет правильно сказать

Всем привет
Подскажите плз как именно лучше организовать общение двух ViewModel через Repository
Задача следующая: перехожу с экрана А на экран Б, на экране Б делаю POST запрос, возвращаюсь на экран А, и экран А должен сделать GET запрос и получить обновленные данные.
Пока что не придумал ничего лучше, чем хранить в репозитории какой-то subject, и на экране Б после выполнения POST запроса я выполню GET запрос и его результат положу в subject на который будет подписана viewmodel экрана А
Звучит и выглядит очень костыльно, уверен есть способ лучше

Через sharedViewModel. Без viewmodel-ки на экране б

Иметь только одну вьюмрдельку

А что это за шаредвьюмодел?

Одна вьюмоделька на 2 экрана грубо говоря

имхо, совсем не тот случай, зачем лишний раз связывать экраны через shared VM?

вроде, то что он описал с самого начало и то, не такое костыльное, как shared vm