Size: a a a

Android Architecture

2021 June 19

A

Andrey in Android Architecture
ну скорее нет, viewmodel по идее и должна стыковать юзкейс с вьюхой, зачем еще что то дополнительно городить? есть какие то кейсы где такой адаптер оправдан?
источник

AN

Alexandr Nevyantsev in Android Architecture
Ну, например если приложение большое, много вьюмоделей, а недавно стали использовать флоу и надо как-то конвертировать данные из флоу в лайвдаты
источник

L2

LDev 21 in Android Architecture
Сейчас изучаю MVP и вижу, что во View создают экземпляр класса презентера, передавая ему экземпляр модели, создавая её во View. Это нормально, что она во View создаётся?
источник

L2

LDev 21 in Android Architecture
С другой стороны, её негде больше создать
источник

AN

Alexandr Nevyantsev in Android Architecture
Ага, граф зависимостей начинается со вью
источник

L2

LDev 21 in Android Architecture
Я правильно понимаю, что на каждый View требуется по одному своему делегату, кроме MVC? Т.е в MVVM на каждое View свой ViewModel, в MVP на каждый View свой Presenter?
источник

L2

LDev 21 in Android Architecture
Только в MVC 1 контроллер может быть на несколько View?
источник

JF

Jorik Fat in Android Architecture
Вы про инстансы или про классы?
источник

L2

LDev 21 in Android Architecture
Про классы
источник

JF

Jorik Fat in Android Architecture
можно и 1 presenter на N View
и с MVVM так же
источник

L2

LDev 21 in Android Architecture
Но это же при условии если поведение View примерно одинаковы?
источник

JF

Jorik Fat in Android Architecture
например если это список элементов с пагинацией и кликом. Какая разница какие там элементы
источник

JF

Jorik Fat in Android Architecture
именно
источник

L2

LDev 21 in Android Architecture
Т.е, если подытожить. В случае, когда View примерно с одинаковым поведением, можно использовать 1 презентер, который условно для какого-то из View может быть перегружен тем функционалом, который использует другой View. Т.е 1 презентер, много инстансов, но параметры разные принимают. А в случае, если View имеют разное поведение, то целесообразно на каждый из них иметь по своему презентеру. Правильно?
источник

JF

Jorik Fat in Android Architecture
верно
источник

L2

LDev 21 in Android Architecture
Ещё хотел узнать. Как Clean Arhitecture соотносится с этими паттернами? Она подразумевает их и не противоречит им?
источник

P

Pavel in Android Architecture
Clean подразумевает на уровне UI какой-нить MVx.
источник

P

Pavel in Android Architecture
Clean - это больше про общую структуру приложения. От data (http, db, etc.) до UI.
На UI уровне можно использовать любой MVx паттерн, который больше нравится
источник

L2

LDev 21 in Android Architecture
Это про структуру приложения в целом, включая серверную часть, правильно? Ведь MVx тоже про структуру всего приложения, но только клиента
источник

P

Pavel in Android Architecture
Нет, серверная часть - совсем про другое :)
источник