Как стать автором
Обновить

«Я был очень негативен по отношению к корутинам»: Артём Зиннатуллин об Android-разработке

Время на прочтение 13 мин
Количество просмотров 19K
Всего голосов 34: ↑34 и ↓0 +34
Комментарии 10

Комментарии 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.

LiveData полностью совместима с Unit тестами

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 чёткий

Плюсую.

В целом, как вижу, речь идет больше о вкусовщине. Ну ок.
Было тоже самое, когда не нашел простого аналога Dagger для iOS, но организация мультипоточности мне нравится больше в iOS.
Привет Арсений, столетстозим
читал и улыбался, спасибо, что пошарил)

Пост стоит прочитать, прошу не оскорблять Айседа в комментариях, спасибо
приветы! :)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий