Комментарии 27
В первый раз на хабрахабре вижу статью на 70% состоящую из баззвордов.
Сейчас это уже штука, которая выстрелила и знание желательно в нормальных вакансиях.
знание желательно в нормальных вакансиях
Не знаю, где вы смотрите вакансии, но зашел на jobs.dou.ua, из 60 вакансий по android слово "rxjava" встречается в 3-х. "Rx" нет нигде. То есть, 5% вакансий. И не факт, что эти 3 — самые нормальные.
в правильной архитектуре под Андроид взаимодействие с сетью, кэширование и вообще вся общая бизнес-логика не должна быть завязана на какие-то андроидные части
Вот это мнение меня всегда удивляло. Мы пишем под android, значит, надо завязываться на это, оптимизироваться под это, использовать там структуры данных из библиотеки саппортов ради скорости, компоненты системы. Это ж мобилка, здесь не до архитектурного оверхеда, надо память экономить, батарейку, а не гонять данные по слоям туда-сюда, как в clean architecture
Это вовсе не оверхед, и никак оно на производительность приложения в худшую сторону не влияет. Другое дело, что приложение у вас становится четко декомпозированным, разбитым на модули. Плюс вы сможете покрывать свой код тестами, что придаст большую стабильность коду. Еще вы сможете легко разбивать какую либо задачу между разработчиками — один на ui, один на бизнес-логику, другой на data-уровень.
Вообще преимуществ у чистой архитектуры много. Другое дело — чтобы понять их и прочувствовать, нужно садиться, пробовать и писать. Иначе ну никак. Количество абстракций и уровней всегда будет пугать. Но разобравшись, понимаешь, что все это необходимо и нужно.
никак оно на производительность приложения в худшую сторону не влияет
Вы замеряли? :) Как бы чем больше объектов мы создаем, тем больше работы у GC. Как минимум.
Еще вы сможете легко разбивать какую либо задачу между разработчиками — один на ui, один на бизнес-логику, другой на data-уровень
Ну, во-первых, 3 разработчика на одно android-приложение — это многовато. Во-вторых, на обычном каком-нибудь rest-клиентике "бизнес-логики" — минимум (поэтому xamarin не слишком популярен — количество общего кода не во всяких там корпоративных приложениях невелико, а интерфейс для каждой платформы надо свой делать), поэтому лишний слой нужен очень редко.
Понятное дело, архитектура нужна, но не в таком виде. Мне понравились несколько примеров. Из них хотелось бы выделить недавно появившийся гугловый, в котором ветка clean есть, но она выглядит самой перегруженной.
Архитектуру вполне можно организовать и на основе компонентов android: contentprovider-ов/observer-ов, service-ов, но это, вилите ли, не модно :)
Или вот philm. Даже несмотря на то, что давно не обновлялся, этот репозиторий содержит очень стройный код.
2. Нет, не замерял. Но у GC больше работы, это да. Вопрос только в том, на сколько критично и велико это увеличение. Мне кажется, вообще не критично. Но опять таки, лучше измерить.
3. 3 разработчика на одно приложение — это нормально. Как и пять) Приложения то разные бывают. Вообще очень разные. И какой бы не был rest-клиент, все начинает меняться, когда вам необходимо эти данные кешировать, синхронизировать. Мне в этом отношении очень нравится подход, как был в конкурсе Telegram — https://vk.com/durovschallenge?w=wall-55882680_69. Суть в том, что есть некая нативная библиотечка с API. И эта библиотеска полностью берет на себя вопросы кеширования, синхронизации. Единое такое решение для всех платформ для data-уровня.
4. То, что можно все организовать на contentprovider-ов/observer-ов, service-ов, никто не спорит) Но я вот, честно говоря, не знаю, на сколько это будет поддаваться тестированию. С Clean architecture вы каждый слой спокойно можете покрыть юнит тестами (кроме ui) без дополнительных тулзов, так как там нет android компонент.
Посмотрите эти примеры. Дают вполне нормальное представление, как Rx может помочь)
Если говорить про понимание, то, возможно, саам стоит начать с лекций и видео каких-нибудь. Из довольно много и про Android и про iOS, про веб фронтенд и даже про бекенды. Там частенько бывают вещи, которые раскрывают всю суть реактивного подхода
Посмотрите выступление Эрика Мейера — может, станет понятнее:
https://www.youtube.com/watch?v=sTSQlYX5DU0
Занятно, кстати: очередная статья, в которой "реактивщина" незаметно приравнивается к Rx (окей, здесь еще Akka Streams припомнили, но это тоже поток событий). Хотя Кун — один из авторов цитируемого Reactive Manifesto, — скажем, считает акторы не менее жизнеспособной моделью.
Другое дело, что для Android все таки сильно чаще используется именно RxJava или RxKotlin или еще что из Rx.
Кстати, акторы и streams идут на самом деле достаточно параллельно, как мне кажется. Никто же не запрещает их вместе использовать их в одном проекте и они хорошо могут вместе работать.
Но соглашусь, что чаще говорят именно про RxJava и меньше про другие фреймворки и подходы.
Я не приравнивал Rx к самому подходу.
Ага. Статья с заголовком "The Art of Rx" и тизером "Что такое правильное реактивное программирование на Android?"
Никто же не запрещает их вместе использовать их в одном проекте
Да понятно, что никто не запрещает, но вот только многие люди уже уверенно считают, что Rx и реактивное программирование — это одно и то же. Хотя как Rx позволяет, например, достичь resiliency — это открытый вопрос.
гайдлайны
импакт
сабжекты
мутабельность
импрувмент
Без мутабельности и импрувментов можно было и обойтись в тексте, да. Но это транскрипт с записи речи, а с языка мне и не хочется их убирать, поэтому так и вышло.
The Art of Rx