Проблема, друзья. Реактивщина везде, её слишком много и уже никому от неё не спрятаться. Мы с вами все умеем написать ASyncTask, Service или ContentProvider (я в это верю!). Все можем повернуть битмапу или сгонять на сервер за данными. Это все довольно очевидно. Но ещё МЫ ДУМАЕМ, что можем готовить реактивищну правильно. Это далеко не всегда так.

Что такое правильное реактивное программирование на Android?



– Добрый день. Расскажи в двух словах о себе. Где работаешь, чем занимаешься, когда начал продвигать реактивный подход?

— Привет. Меня зовут Матвей Мальков (на хабре lNevermore ). Я Android-разработчик уже, наверное, лет 5-6. Конкретно сейчас я занимаюсь Scala-разработкой в одном стартапе. Стартап находится в Москве и о нём я говорить особо много не могу. Но суть в том, что это будет такая комьюнити-платформа, наподобие Телеграма. И её я, собственно, пишу под Android на Scala.

Первый проект, который я полностью перевел на RxJava, у меня был в компании 2GIS. Архитектура, база, работа с сетью — всё. После этого начал активно продвигать фреймворк RxJava и реактивный подход в целом на конференциях. Сейчас пишу на Scala, где использую вовсю функциональный подход, а в свободное время интересуюсь новостями реактивного мира.

– Пользователи Хабрахабра наверняка в курсе концепции реактивного программирования. Расскажи про особенности этой парадигмы на Android и про реактивные потоки данных.

– В программировании под Андроид довольно много особенностей, связанных с реактивным программированием. Я как раз хотел бы сказать о том, что не все принципы реактивного программирования, о которых мы попозже подискутируем, хорошо ложатся на Андроид. Чтобы не быть голословным: есть такое понятие как масштабируемость, под которой обычно понимается масштабируемость на большое количество нод, то есть это какая-то серверная масштабируемость. В Андроиде же это всего лишь масштабируемость на треды, что не есть «настоящая маштабируемость». И она не даёт такого большого мощного импакта на систему в целом. Хотя, конечно, всё равно даёт, но по-другому.

Ещё одна особенность заключается в том, что очень много в Андроиде завязано на императивщину. То есть на мутабельность, на изменяемость данных, и конкретно из-за неё очень сложно всё это завернуть в реактивные потоки. Это приводит к тому, что приходится делать много хаков, что всё очень усложняет. Императивность Android заставляет большое количество разработчиков использовать такие вещи, как сабжекты, которые вообще-то были задуманы и сделаны для того, чтобы сращивать мир реактивный и мир императивный. Но по факту, на самом деле, все пользуются им для того, чтобы что-то легко завернуть в Observable, Это обычно происходит в ущерб архитектуре, особенно на длинной дистанции, на больших проектах. Получается мешанина из императивщины и абы как сделанной на ней реактивщины. А всё потому, что многим людям просто лень сделать правильно или они не знают, как именно правильно.

На самом деле, это в общем-то всё, потому что в правильной архитектуре под Андроид взаимодействие с сетью, кэширование и вообще вся общая бизнес-логика не должна быть завязана на какие-то андроидные части. Поэтому собственно это просто бизнес-логика, которая работает, как и в любых других проектах. Не только в андроидных.