Size: a a a

Android Architecture

2020 May 26

S

Serhei in Android Architecture
Дмитрий Рубцов 🇷🇺🔥
Нет, работа с бд идёт в data модуле
Получается что надо три типа моделей? Одни для сети и бд, которые в дата модуле, а в домеин третий тип, который юзается в presentaion
Так?
источник

ДР

Дмитрий Рубцов 🇷🇺🔥... in Android Architecture
Да
источник

S

Serhei in Android Architecture
Спасибо
источник

S

Serhei in Android Architecture
@massivemadness а ведь если модели слишком раздутые и много сложных типов то мапить каждый раз их при получении с базы - наверн снижает производительность..
источник

NM

Nikolai Melkov in Android Architecture
можно мапить только то что нужно
источник

ДР

Дмитрий Рубцов 🇷🇺🔥... in Android Architecture
Да в любом случае там счёт идёт на наносекунды (может конечно преувеличил, но на миллисекунды точно)
источник

S

Serhei in Android Architecture
Понял
источник

S

Serhei in Android Architecture
Все мапят это дело ручками или может есть средства какие то?
источник

NM

Nikolai Melkov in Android Architecture
источник

ДР

Дмитрий Рубцов 🇷🇺🔥... in Android Architecture
Нуу да, создаёшь какой нибудь object Converter и делаешь там конвертацию
источник

ДР

Дмитрий Рубцов 🇷🇺🔥... in Android Architecture
Ну по крайней мере лично я так делаю
источник
2020 May 27

AA

Ali Agzamov in Android Architecture
Алексей Ершов
Вот и вопрос, зачем шарить вьюмодель, если можно просто модель? Просто классов меньше?
источник

AA

Ali Agzamov in Android Architecture
там под примером есть список примуществ. на мой взгляд последний самый важный
источник

АЕ

Алексей Ершов... in Android Architecture
Выглядит как DI-костыль для бедных. Типа "мы не верим, что вы сможете настроить общение экранов через модель поэтому вот вам возможность подоткнуть что-то из активити". Область применения очень ограниченная.
А если я хочу из VM второго экрана слушать первый, а не из фрагмента, чтобы какую-то дополнительную логику навернуть? observeForever страшный использовать?
А если я хочу чтобы вьюмодель была пошарена на уровне родительского фрагмента?
"Fragments don't need to know about each other besides the SharedViewModel" - окей, то есть мне нужно делать модуль с пошаренной вьюмоделью и от него зависеть модулями моих фрагментов? Тут даже зависимость эту не развернешь, потому что ViewModel по интерфейсу не запровайдишь.
В общем, узконаправленное и весьма странное решение. Если оно действительно хорошо подходит под задачу - отлично, вопросов нет, но ощущение, что реально таких задач немного.
источник

AA

Ali Agzamov in Android Architecture
Алексей Ершов
Выглядит как DI-костыль для бедных. Типа "мы не верим, что вы сможете настроить общение экранов через модель поэтому вот вам возможность подоткнуть что-то из активити". Область применения очень ограниченная.
А если я хочу из VM второго экрана слушать первый, а не из фрагмента, чтобы какую-то дополнительную логику навернуть? observeForever страшный использовать?
А если я хочу чтобы вьюмодель была пошарена на уровне родительского фрагмента?
"Fragments don't need to know about each other besides the SharedViewModel" - окей, то есть мне нужно делать модуль с пошаренной вьюмоделью и от него зависеть модулями моих фрагментов? Тут даже зависимость эту не развернешь, потому что ViewModel по интерфейсу не запровайдишь.
В общем, узконаправленное и весьма странное решение. Если оно действительно хорошо подходит под задачу - отлично, вопросов нет, но ощущение, что реально таких задач немного.
источник

AA

Ali Agzamov in Android Architecture
ну или вот с хабра статья https://habr.com/ru/post/337320/
источник

АЕ

Алексей Ершов... in Android Architecture
Эти статьи описывают, как заинжектить зависимости во вьюмодель через даггер. Я не об этом говорил)
источник

AA

Ali Agzamov in Android Architecture
по пунктам не разложиш тогда?
источник

АЕ

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

AA

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