Size: a a a

Android Architecture

2020 May 27

АЕ

Алексей Ершов... in Android Architecture
Областью ответственности. Я придерживаюсь подхода, что одна VM отвечает за логику презентации строго одного экрана или его части. Если мы начинаем из VM делать евентбас для общения между разными частями приложения - мы добавляем ей ещё одну ответственность.
Это как тот троллейбус из булки хлеба, вроде можно, но зачем? С таким же успехом можно каждый класс в приложении унаследовать от VM) Поэтому я и говорил, что единственный аргумент за - это легкость получения пошаренного инстанса во фрагментах, если у вас нет нормального DI.
источник

T

Tepex in Android Architecture
Разница в направлении взаимодействия. Общая VM — горизонтальное, на одном уровне (как следствие — потенциальная лапша в коде). Через модель (вышестоящий слой) — вертикальное. Второе — чище и гибче с архитектурной точки зрения и стратегически лучше.
источник

AA

Ali Agzamov in Android Architecture
Tepex
Разница в направлении взаимодействия. Общая VM — горизонтальное, на одном уровне (как следствие — потенциальная лапша в коде). Через модель (вышестоящий слой) — вертикальное. Второе — чище и гибче с архитектурной точки зрения и стратегически лучше.
а фрагмент с деталями относительно фрагмента с листом как какое взаимодействие рассматривать?  как горизонтальное или вертикальное?
источник

T

Tepex in Android Architecture
В идеале — вертикальное. Но зависит от задачи. Всегда можно «срезать угол» — вопрос целесообразности.
источник

AA

Ali Agzamov in Android Architecture
Алексей Ершов
Областью ответственности. Я придерживаюсь подхода, что одна VM отвечает за логику презентации строго одного экрана или его части. Если мы начинаем из VM делать евентбас для общения между разными частями приложения - мы добавляем ей ещё одну ответственность.
Это как тот троллейбус из булки хлеба, вроде можно, но зачем? С таким же успехом можно каждый класс в приложении унаследовать от VM) Поэтому я и говорил, что единственный аргумент за - это легкость получения пошаренного инстанса во фрагментах, если у вас нет нормального DI.
ок что есть  есть идеальный вариант шеринга инстанса  между скринами тогда?
источник

AA

Ali Agzamov in Android Architecture
Tepex
В идеале — вертикальное. Но зависит от задачи. Всегда можно «срезать угол» — вопрос целесообразности.
ок. спасибо
источник

АЕ

Алексей Ершов... in Android Architecture
Почитайте дискуссию выше, там Аркадий хорошо расписал.
источник

АЕ

Алексей Ершов... in Android Architecture
Если чуток отойти мыслями от экранов, то когда вы выбираете письмо в списке писем - вы просто изменяете состояние приложения, "текущееПисьмо=1553". Этот стейт кто-то может захотеть слушать, и вашему списку писем особо не интересно, кто. А ещё его может изменить кто-то вообще другой, например, клик на пуш-нотификацию. И хорошее архитектурное решение позволит вам все эти взаимодействия легко организовать. А протаскивать ViewModel в обработчик клика по пуш-нотификации - занятие мягко говоря неблагодарное. У вас там даже активити нет)
Это то, что я имел в виду, когда говорил, что shared VM из общей задачи "передать изменение состояния от одной части приложения в другую" решает только очень конкретную подзадачу: передать событие от одного фрагмента к другому.
источник

АЕ

Алексей Ершов... in Android Architecture
При этом сделать в простом виде то же самое без shared VM даже проще - пошарить инстанс нужного класса из вашей модели на два экрана, при необходимости закрыв эту зависимость интерфейсами.
источник

АЕ

Алексей Ершов... in Android Architecture
Вывод: если приложение маленькое и простое, и модели там практически нет, и для вас работает вариант, предложенный гуглом - шарьте вьюмодели на здоровье, главное чтобы работало.
Но если приложение хотя бы сколько-нибудь сложное, особенно многомодульное, и вы планируете в нём поддерживать приличную архитектуру - лучше и эту задачу решить через приличную архитектуру.
источник

AA

Ali Agzamov in Android Architecture
Алексей Ершов
Вывод: если приложение маленькое и простое, и модели там практически нет, и для вас работает вариант, предложенный гуглом - шарьте вьюмодели на здоровье, главное чтобы работало.
Но если приложение хотя бы сколько-нибудь сложное, особенно многомодульное, и вы планируете в нём поддерживать приличную архитектуру - лучше и эту задачу решить через приличную архитектуру.
ок. спасибо
источник

AI

Arkadii Ivanov in Android Architecture
Алексей Ершов
Почитайте дискуссию выше, там Аркадий хорошо расписал.
Хм, я вроде немного другое имел ввиду) Какой-нибудь ListFragment может принимать коллбэк onItemClicked: (id) -> Unit. Предок (активити или фрагмент) передаёт этот коллбэк и открывает DetailsFragment с нужным id.
источник

АЕ

Алексей Ершов... in Android Architecture
Мне кажется мы все говорим об одном и том же, только каждый немного со своей колокольни)
источник

AI

Arkadii Ivanov in Android Architecture
Алексей Ершов
Мне кажется мы все говорим об одном и том же, только каждый немного со своей колокольни)
Ну ладно) наверно
источник

DS

Dm Savin in Android Architecture
Arkadii Ivanov
Хм, я вроде немного другое имел ввиду) Какой-нибудь ListFragment может принимать коллбэк onItemClicked: (id) -> Unit. Предок (активити или фрагмент) передаёт этот коллбэк и открывает DetailsFragment с нужным id.
А зачем фрагменту это? Он ведь просто регистрирует user input и сообщает об этом вью модели. ВМодель меняет состояние модели. Все ВМ подписанные на это изменение, загружают новые данные обновляя свои фрагменты.
Зачем фрагменту знать про логику обновления других фрагментов? Он должен знать только про свою view model. Low coupling, SOLID и все такое
источник

AI

Arkadii Ivanov in Android Architecture
Dm Savin
А зачем фрагменту это? Он ведь просто регистрирует user input и сообщает об этом вью модели. ВМодель меняет состояние модели. Все ВМ подписанные на это изменение, загружают новые данные обновляя свои фрагменты.
Зачем фрагменту знать про логику обновления других фрагментов? Он должен знать только про свою view model. Low coupling, SOLID и все такое
Какому фрагменту из трёх?
источник

DS

Dm Savin in Android Architecture
Arkadii Ivanov
Какому фрагменту из трёх?
Любому.
источник

AI

Arkadii Ivanov in Android Architecture
Dm Savin
Любому.
Я не понимаю Вас
источник

DS

Dm Savin in Android Architecture
Ну, в дискуссии обсуждался вариант (если я правильно понял), что один фрагмент каким-то образом может обрабатывать пользовательский ввод другого.
Это добавляет coupling. Зачем это делать, если у нас уже есть сущность, которая это делает (вью модел)?
источник

AI

Arkadii Ivanov in Android Architecture
Dm Savin
Ну, в дискуссии обсуждался вариант (если я правильно понял), что один фрагмент каким-то образом может обрабатывать пользовательский ввод другого.
Это добавляет coupling. Зачем это делать, если у нас уже есть сущность, которая это делает (вью модел)?
Связность между чем и чем это добавляет?
источник