Dev Easy Notes

{1/2} Сразу скажу, что не вижу смысла просто копировать документацию к ViewModel. Потому как с ними работать и как их использовать уже есть тысячи статьей и я просто внизу приведу список того, что считаю более менее норм. Тут я хочу просто разобрать основную проблему которую они решают, рассмотреть как они работают под капотом и в чем разница м/у тем же Moxy. 

Итак, погнали. Проблема, которую решает ViewModel – сохранение состояние экрана без сохранения в Bundle. Например, из-за размера или по причине того, что в Parcelable не сохранишь вещи вроде Disposable. Разумеется разработчики задумались, а каким образом можно сохранить данные между переворотами. 

Вначале использовали retain fragment о которых мы уже говорили. По понятным причинам от этой идеи начали отказываться и стали все просто сохранять в статику, которая живет пока, живет весь процесс приложения. Сохраняли кто как умеет, крутые ребята делали через Scope DI, не крутые прям так напрямую и сохраняли в статические поля. Все понимали что разработчики нуждаются в хорошем удобном инструменте для решения этой задачи. 

И пара пацанов из no name галеры запилили Moxy. Библиотека Moxy взлетела на расцвете архитектуры MVP. Разумеется были и другие похожие решения, но это был самый хайповый инструмент. Сейчас это уже считается пережиток прошлого и некоторые компании даже стесняются признаваться, что у них он до сих пор используется. Недостатка у Moxy всего два это кодогенерация и сильная завязка на архитектуру MVP. 

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

Спустя какое-то время, Гугл после увидел, что у разработчиков есть нужна в адекватном инструменте для сохранения состояния и запилила ViewModel. Разработчикам из гугла потребовалось 8 лет чтобы это увидеть. С такой скоростью адекватное API для клавиатуры мы увидим примерно к 28 году. 

В 2017 году пришел Гугл и сказал что MVP параша, и нормальные ребята используют MVVM. Помимо этого, они любезно как раз сделали все для использования этого подхода. MVVM это не разработка гугла, это придумали Microsoft еще тогда когда у всех были Nokia, но об этом как-нибудь потом.

👏25👍4😁3

www.tgoop.com/dev_easy_notes/159

2.11K viewsedited  Sep 1, 2022 at 10:40

{1/2} Сразу скажу, что не вижу смысла просто копировать документацию к ViewModel. Потому как с ними работать и как их использовать уже есть тысячи статьей и я просто внизу приведу список того, что считаю более менее норм. Тут я хочу просто разобрать основную проблему которую они решают, рассмотреть как они работают под капотом и в чем разница м/у тем же Moxy. 

Итак, погнали. Проблема, которую решает ViewModel – сохранение состояние экрана без сохранения в Bundle. Например, из-за размера или по причине того, что в Parcelable не сохранишь вещи вроде Disposable. Разумеется разработчики задумались, а каким образом можно сохранить данные между переворотами. 

Вначале использовали retain fragment о которых мы уже говорили. По понятным причинам от этой идеи начали отказываться и стали все просто сохранять в статику, которая живет пока, живет весь процесс приложения. Сохраняли кто как умеет, крутые ребята делали через Scope DI, не крутые прям так напрямую и сохраняли в статические поля. Все понимали что разработчики нуждаются в хорошем удобном инструменте для решения этой задачи. 

И пара пацанов из no name галеры запилили Moxy. Библиотека Moxy взлетела на расцвете архитектуры MVP. Разумеется были и другие похожие решения, но это был самый хайповый инструмент. Сейчас это уже считается пережиток прошлого и некоторые компании даже стесняются признаваться, что у них он до сих пор используется. Недостатка у Moxy всего два это кодогенерация и сильная завязка на архитектуру MVP. 

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

Спустя какое-то время, Гугл после увидел, что у разработчиков есть нужна в адекватном инструменте для сохранения состояния и запилила ViewModel. Разработчикам из гугла потребовалось 8 лет чтобы это увидеть. С такой скоростью адекватное API для клавиатуры мы увидим примерно к 28 году. 

В 2017 году пришел Гугл и сказал что MVP параша, и нормальные ребята используют MVVM. Помимо этого, они любезно как раз сделали все для использования этого подхода. MVVM это не разработка гугла, это придумали Microsoft еще тогда когда у всех были Nokia, но об этом как-нибудь потом.

BY Dev Easy Notes