Kotlin + Rx2: Реактивный и функциональный подход к разработке мобильных приложений
Именно поэтому мы обратились к Денису Неклюдову (Android GDE) и Степану Гончарову, Android-разработчикам в 90Seconds.com. В интервью будут затронуты несколько важных тем, от архитектуры мобильного приложения до применения библиотек Rx в проектах. Итак, начнем…
Денис Неклюдов
—Добрый день, Денис! Скажите, пожалуйста, на чем сфокусировано ваше внимание в контексте разработки на данный момент?
— Добрый день! Сейчас я, как и мой партнер по выступлению на Mobius Степан Гончаров, занимаюсь разработкой нового мобильного клиента для Сингапурской компании 90Seconds.com. Что больше всего мне нравится в текущем проекте, так это то, что Степан начал писать приложение с нуля и смог построить очень интересную архитектуру. Плюс ко всему, там используются все современные, можно даже сказать, модные подходы, вроде использования Kotlin в качестве языка программирования и реактивный подход к работе с данными.
— Несколько лет назад в интервью вы рассказывали о полученном статусе «Google Developer Expert» и что он значит для вас. Одна из ключевых фраз, на мой взгляд, звучала так: «А также заниматься моим любимым хобби: делиться знаниями с людьми на конференциях, в подкастах и в статьях.» Скажите, пожалуйста, вы не поменяли мнение о необходимости распространения информации и продвижения идей?
— Не поменял, и 30 выпусков нашего подкаста об Android разработке, тому отличное подтверждение. Могу поделиться другой проблемой, с которой столкнулся за эти два года, будучи в статусе GDE. Если ты выступаешь с темой «что нового в новом Android», то находится множество людей, которые сами прочитали документацию, все 20 страниц, которые ты так аккуратно свел в одну удобную презентацию, и уходят на середине со словами: «О, ну это я мог и сам прочитать». А когда ты приходишь с темой, неизвестной большинству, рассказываешь ее и видишь, что лишь малый процент аудитории вообще понимает о чем речь, ибо они не подготовлены абсолютно, а времени на вводный материал в получасовой презентации нет. И даже не факт, что люди, ушедшие с твоей первой презентации, не уйдут так же со второй.
Как раз поэтому мы решили записывать подкасты. Послушать которые будет интересно всем, ведь там мы обсуждаем проблемы всех уровней, там и новичок, и профессионал отрасли найдет полезное для себя.
— Быть в курсе самых последних событий, изменений — это ваше кредо? Влияет ли знание о грядущих изменениях в языке на приверженность определенному стилю написания кода или вы сторонник применения новейших технологий?
— Я сторонник поддержания баланса. Не выношу крайность «у нас самые новейшие библиотеки, которые еще даже не в релизе, не проверенные временем подходы». И также мне не нравится тотальный консерватизм, которым покрываются люди, за много лет опыта которых набился не один десяток шишек, при попытках испробовать новое. Нужно стараться балансировать между скоростью разработки, которая нужна бизнесу сегодня, и возможностью масштабирования, расширения и поддержания другими командами приложения, которая будет нужна бизнесу завтра.
— Все внимание сейчас сосредоточено на Android Nougat, правильно? Какие именно новшества были приняты разработчиками положительно, думаю, что за этот период с момента выхода вы уже составили свое мнение.
— На самом деле что Nougat, что Marshmallow, что на днях анонсированный Android O Developer Preview являются органичным развитием Android Lollipop, не пытаясь что-то поменять коренным образом в SDK. С одной стороны, это хорошо: чтобы поддержать новую версию ОС в приложении, не нужно много работы. Но с другой стороны, старые недостатки Android и его корневой архитектуры приносят немало боли нам день ото дня.
— Как вы считаете, применяемая архитектура MVVM «Model-View-ViewModel» занимает лидирующие позиции и считается современной технологией? Ждать ли нам изменений в этом направлении? Что можно привнести в данный архитектурный подход?
— Сложно говорить о лидирующих позициях какого-либо архитектурного подхода. Везде есть свои плюсы и минусы. Если смотреть на то, как выглядят, работают и что «под капотом» у большинства популярных в маркете приложений, то сомнений не останется о лидирующем подходе: «тяп-ляп-в-продакшен», поэтому я не считаю MVVM особенно популярным. А в Android мире, в отличие от iOS, это еще и довольно молодое направление, так как DataBinding от Google стали стабильным не так уж давно.
— Насколько я знаю, часть вашего доклада будет посвящена шаблону MVVM и его «жизни» в реактивном окружении. Расскажите, пожалуйста, это будет новый взгляд на архитектуру приложения или разбор старых подходов к проектированию под новым соусом.
— Это будет наш оригинальный взгляд, не претендующий на лучший и самый правильный, он сочетает в себе известные решения, но и имеет наши собственные наработки. Мы так делаем приложения, и нам очень нравится, мы хотим этим поделиться с нашими российскими коллегами, которых еще не покинула от безнадежности идея найти подход, который бы избавил от борьбы с многочисленными ограничениями SDK Android и жизненного цикла приложения.
— Сегодня у разработчиков огромные возможности, одновременно масса подводных камней, и за всем не уследить, особенно в больших проектах. Вам не кажется, что использование Dependency injection (DI) — отличное решение в данной ситуации?
— Да, DI — отличный способ ускорить рефакторинг. Но не нужно превращать это, так сказать, в DI головного мозга и инжектить все подряд без разбора. Мы в 90Seconds, да и в своих домашних проектах любим DI, часто реализуем его с помощью Dagger2. И всем тоже советуем в своих проектах обязательно пользоваться этим подходом. О тестируемой и позволяющей хорошо поддерживать код архитектуре будет несколько докладов на Mobius, в том числе и мой со Степаном.
— Огромное спасибо за беседу. Будем рады услышать ваш доклад.
Ждем всех на нашей презентации, будет интересно!
Степан Гончаров
— Степан, добрый день! Расскажите, пожалуйста, немного о себе и о вашей работе сейчас.— Добрый. Если очень коротко о себе, то разработкой под Android я начал интересоваться в 2008 году, еще до официального релиза 1.0, в первой половине 2009 года у меня уже было приложение в Android Market (уже мало кто помнит, что Google Play тогда так назывался) и паре других сторонних маркетах. С рекламы я заработал около 1000$ и купил свой первый телефон на Android, чтобы посмотреть, как же это приложение работает на настоящем девайсе. Параллельно, как вы уже заметили, увлекся созданием игр, одна из которых впоследствии оказалась в Android Market и App Store. Потом я переключился на разработку приложений под заказ и, посвятив этому 4 года, понял, что хочется попробовать себя в продуктовой разработке. Так я оказался в роли тим лида в одном из Сингапурских стартапов, а затем и в 90 Seconds, где мне представилась редкая возможность создать уникальное приложение с нуля, используя самые передовые технологии.
— В 2011 году вы выпустили цикл статей по созданию игр, которые однозначно привлекли читателей. Сегодня имеется спрос на данные материалы?
— К сожалению, давно не писал статей про разработку игр. Около года назад начал добавлять небольшие статьи на Medium, в основном про Kotlin и Android.
— Хотел задать вопрос, касающийся непосредственно темы нашей беседы. Не так давно я увидел переписку, касающуюся Kotlin, и мне очень понравился ваш ответ «Fortunately for me Kotlin it is a Swiss Army Knife in Java world» (Kotlin для меня — это швейцарский нож в мире Java). Вы действительно считаете Kotlin универсальным решением для разработки?
— Да, Kotlin — уникальный инструмент, который, несмотря на свои недостатки, значительно повышает продуктивность и расширяет возможности разработчиков, при этом позволяя все так же удобно работать с почти любыми Java-библиотеками.
Отличный пример использования data class и default parameters, пример, как повысить продуктивность разработчика. И еще один вариант, демонстрирующий работу со списками.
— Расскажите, пожалуйста, о ситуациях, когда применение Kotlin может повысить качество кода, его читаемость и, возможно, избавит от лишних проверок на null.
— Действительно, одно из самых заметных отличий Kotlin от Java — это Nullable типы. Необходимость явно делать проверки на null значительно повышает качество кода, но не является 100% гарантией избавления от NPE. Одна из моих самых любимых особенностей Kotlin — это набор extension функций для стандартных Java-коллекций, которые значительно упрощают работу с данными и сокращают количество кода, что в свою очередь облегчает его последующую модификацию и снижает количество потенциальных ошибок. Ну и, конечно же, делегаты, которые, в сочетании с дефолтными реализациями методов в интерфейсах, позволяют использовать композицию на 100%, чего довольно сложно добиться в Java из-за необходимости писать, а потом и поддерживать огромное количество кода.
— В сети встречается достаточно много материала о лаконичности и компактности кода на Kotlin, с этим все ясно. Но не стоит забывать и о поддержке такого кода. Всегда ли разработчик, например, на Java, быстро разберется в проекте на Kotlin? Какие вы видите проблемы/тонкости в языке, несвойственные, например, Java/Scala?
— Хоть я и начал интересоваться Kotlin еще в далеком 2012 году, я все еще считаю, что для опытного Java разработчика разобраться с Kotlin не составит труда, Денис как раз через это недавно проходил, так что сможет более подробно рассказать. Для начинающих Java разработчиков все гораздо сложнее, с моей точки зрения, глубокое знание Java просто необходимо для того, чтобы начать осваивать Kotlin.
Часто знания об особенностях работы Kotlin помогают понять, почему та или иная библиотека не работает как ожидалось. Из тонкостей стоит отметить используемый многими популярными библиотеками (например Dagger2, RxBindings) Annotation Processing, работа с которым все еще доставляет определенные неудобства, к примеру DataBinding Annotation Processor не всегда правильно понимает какой тип возвращает метод, если в Kotlin коде тип не указан явно, или к примеру Dagger2 не станет работать с generic типами без @JvmSuppressWildcards аннотаций. Также новичкам придется разобраться с необычным видом stacktrace для inline функций и корутин.
— Хотелось бы затронуть еще одну тему разработки под Android. Мы уже довольно давно слышим и читаем о преимуществах использования RxJava в приложениях. Интересно услышать ваше мнение о данной библиотеке. Я часто вижу материалы, где не всегда однозначно положительно высказываются о ReactiveX.
— Да вы правы, всегда найдутся как хейтеры, так и фанаты у того или иного подхода, rxJava тут не исключение. Я больше отношусь ко второй группе, хотя и понимаю, что сам подход, как и любой другой, имеет как преимущества, так и недостатки. Но несмотря на все недостатки, я бы рекомендовал как минимум основательно разобраться в теме каждому Android-разработчику.
— Как вы относитесь к «продолжению» RxJava в виде RxAndroid и RxBinding? Вы используете у себя в проектах данный функционал?
— Как контрибьютор RxKotlin и автор RxDataBindings, я вижу большую пользу в подобных Rx библиотеках. А RxAndroid использую в каждом из своих проектов.
RxDataBindings позволяет значительно сократить объем кода, необходимого для взаимодействия классов из DataBindings library и rxJava2.
— Подводя небольшой итог нашей беседе, хотелось бы услышать ваше мнение о тенденциях в Android-разработке на ближайшие пару лет. Продолжится ли движение в сторону реактивности, компактности и сокращения объема кода?
— Однозначно, Android-сообщество уже устало от многословности Java, особенно наблюдая за тем, как Apple продвигает Swift. Думаю, в ближайшие годы мы увидим бурный рост использования альтернативных JVM языков для Android разработки (Kotlin, Scala, Groovy, Ceylon, Clojure). Rx скорее всего продолжит укреплять свои позиции основного подхода в мобильной разработке, в ближайшие пару лет конкуренцию ему могут составить разве что подходы на основе концепции корутин, но, к сожалению, пока их поддерживает только Kotlin, и то в экспериментальном режиме.
— Спасибо огромное за беседу. Будем с нетерпением ждать ваше выступление.
Приглашаем всех на наш с Денисом доклад на конференции Mobius.
