Комментарии 10
какие-нибудь Architecture Components — очень спорный набор вещей, которые уже были реализованы в сообществе пять лет назад
Подозреваю, что к этому месту у многих возникло жгучее желание возразить
Желание-то возникло, но немного неясно, чему возражать. Потому что конкретных аргументов против Architecture Components как-то не увидел. Поэтому возражу с тем же уровнем аргументации — LiveData и ViewModel с компонентов идеально подпирают вековые костыли андроида.
Конкретных аргументов против Architecture Components не было тк короткое интервью и это был завершающий вопрос на засыпку, по сравнению, скажем, с корутинами.
Я еще и в новогоднем выпуске AndroidDev подкаста наговорил про половину библиотек из androidx, тоже без аргументации) может потом будет отдельный выпуск про это, но это к nekdenis
Попробую кратко сформулировать аргументы сейчас:
ViewModel Factory в arch components как-то очень "весело" дружится с DI, вот пример, который копируют почти во все тестовые задания, что я видел на собеседованиях, это какая то дичь и люди не могут объяснить как это работает
LiveData это, пожалуй, самая странная часть arch components. Это как писать на всё рксовых сабжектах или EventBus. Зачем это нужно когда есть Rx непонятно, харкодится на main поток, просто жесть)
Что хуже, LiveData рекомендуется к использованию с ViewModel и люди пихают в проекты и LiveData, и RxJava и сейчас еще и корутины, ад, спасибо что без AsyncTask)
На момент представления ViewModel в сообществе уже были матерые MVP, MVVM, MVI, etc библиотеки и куча статей о том, как делать кастомные варианты подобного дизайна
MVI/Redux убирает необходимость во ViewModel, люди миксуют их, но имхо там достаточно ретейнить текущий стейт объект и запускать редюсер с этим стейтом после поворота, посмотрим как оно приживется
Room чёткий, у меня никаких претензий, возможно, сейчас я бы сказал что SQLDelight это всё таки более интересный вариант, но Room кажется более декларативным (а еще есть StorIO, спасибо Диме Никитину)
то что сказал в интервью
Добавлю что LiveData внутри завязана на Handler, и как прогонять unit-тесты?
Самое неприятное, что теперь решение ViewModel + LiveData считается де-факто стандартом. Большинство доверяют только Гуглу и смотреть в сторону намного лучших MV*-решений даже не хотят. Тот же PM или MVVM несложно реализовать на RxJava.
MVVM для Андроид, на мой взгляд более предпочтителен, т.к. бизнес-логика может изменять view-стей не думая о жизненном цикле представления, databinding автоматически синхронизирует модель представления и view, раньше использовали observable field и RxLifecicle для передачи обновления во view, сейчас перешли на LiveData она значительно упрастило это взаимодействие, т.к. отлично биндится в разметку и учитывает жизненный цикл если нужно подписаться из активити к примеру.
вот пример, который копируют почти во все тестовые задания, что я видел на собеседованиях, это какая то дичь и люди не могут объяснить как это работает
Дык это проблема кандидатов, а не ViewModel?
Зачем это нужно когда есть Rx непонятно, харкодится на main поток, просто жесть)
Дык затем, что Rx — это не панацея :) Возможно, прозвучит удивительно, но Rx нравится не всем. И не всем нравится пропихивать его во все слои приложения. А Main поток хардкодится, ибо LiveData и создавалась, внезапно, для постинга в main поток, а не для функциональщины. Можно воспринимать ее как бустнутый ObservableField из DataBinding. Для замены RxJava гугл создавал Agera (вот этот шаг действительно был беспощаден в своей бессмысленности).
Что хуже, LiveData рекомендуется к использованию с ViewModel и люди пихают в проекты и LiveData, и RxJava и сейчас еще и корутины
Опять же вопрос к тем, кто это делает. Но с другой стороны, когда View не содержит логики и просто рендерит передаваемую модель, то Rx для общения между ViewModel и View не нужна. LiveData автоматически отписывает View от обновлений, что убирает необходимость вручную добавлять все в какой-нибудь CompositeDisposable.
На момент представления ViewModel в сообществе уже были матерые MVP, MVVM, MVI, etc библиотеки и куча статей о том, как делать кастомные варианты подобного дизайна
Google и не сказали бросать все и бежать к их реализации. Но MVVM — это ведь не Kotlin, проще написать полностью подконтрольный вариант, чем рекламировать какой-нибудь Moxy :)
MVI/Redux убирает необходимость во ViewModel
Не всем нравится MVI/Redux, что удивительно, но факт.
Room чёткий
Плюсую.
В целом, как вижу, речь идет больше о вкусовщине. Ну ок.
«Я был очень негативен по отношению к корутинам»: Артём Зиннатуллин об Android-разработке