Война… Война никогда не меняется. Так, война за красивый и работающий код идет постоянно. И на каждую сложную задачу рождается свое оружие: кто-то делает его под себя, а кто-то пользуется готовыми инструментами. Разработка под Android не исключение. На нашей конференции AppsConf 2018 мы обсудим, как и чем сейчас интереснее всего пользоваться, где можно споткнуться и что интересного есть в огромном арсенале средств разработки, который Google наконец начал приводить в порядок. Основные темы докладов можно посмотреть на нашем сайте, а пока мы попросили рассказать Google Developer Expert Дениса Неклюдова и Александра Смирнова о новом инструментарии Android Jetpack, который был представлен в мае этого года.
Android Jetpack был представлен в мае этого года на Google I/O.
А чего вы ждали от той конференции? Ожидания оправдались?
Александр Смирнов: Я ожидал намного меньше, чем в итоге представили. Казалось, что развивать платформу с точки зрения бизнеса особо незачем. В mobile-сегменте Google добился уверенной победы в 87 % рынка с позитивными трендами, а последние несколько лет был виден выход ML в качестве их основного направления работы. Я ждал прогресса по Material Design, добавление ML-инструментов для разработчиков, выхода Constraint Layout 2.0. Но мы увидели огромный шаг в наведении порядка и поддержке разработчиков. Неожиданно порадовали новинки в AJP и начало борьбы за улучшенный Support. Привет, Android X.
Денис Неклюдов: Я придерживался главного правила поездок на продуктовые конференции: не ждать анонсов, революционных изменений, подарков — ничего, кроме встречи со старыми приятелями. Лишь бы ничего не сломали. Но нет, они представили Android X, миграция на который не самый приятный процесс в больших проектах. Но было и много позитивного. Самое ценное в Google I/O — это общение с разработчиками фреймворка и коллегами по цеху.
Какие новинки уже успели применить на практике?
Денис Неклюдов: Из AJP опробовали только миграцию на Android X. У меня в проекте проверенный набор решений, нет никакого желания спешить и внедрять новые компоненты. Просто поддержали Target SDK 28, проверили на недавнем релизе Android Pie и успокоились. Ждем, когда сделают доступными обещанные улучшения для тестирования. Jetpack сейчас — это собранные в одном месте различные маленькие библиотеки, которые иногда делают жизнь разработчиков чуть-чуть легче и приятнее. Большинство новинок пока не готовы для релизных версий приложений.
Александр Смирнов:
Из представленных новинок я попробовал все, но в production мы только обновили приложение на новый Material Design и применили Android KTX, который понравился своей простотой и удобством. Люблю схлопывать кучу кода в несколько строк. Остальное закинули в pipeline и перейдем в этому году.
Jetpack успешно выполнит поставленные задачи, и вам понравится его использовать. Но да, некоторые разделы пока что в альфе, поэтому на этапе разработки могут вылезать небольшие проблемы. Это нормально. Тащить в production инструменты в состоянии альфы я бы не рекомендовал, но с тем же Kotlin меня это не остановило.
Для Android всегда остро стоял вопрос удобной навигации.
С AJP что-нибудь поменяется?
Денис Неклюдов: В Android навигация всегда была мощной и разнообразной: Activity, Fragment, еще нужно DeepLinks обрабатывать и следить за передаваемыми аргументами. Можно легко запутаться в большой карте экранов. Google как раз стараются решить это новым Navigation, который даже встроен в Android Studio со своим реактором иерархии экранов.
Я пользуюсь самодельными решениями, которые соответствуют требованиям и общей архитектуре проекта. Пока в Navigation есть серьезные баги и он не готов к использованию в опубликованных приложениях.
Александр Смирнов: В Jetpack Google сделали серьезный шаг вперед: появился Navigation, который изменит архитектуру приложений в лучшую сторону. В крупных приложениях навигация может стать сложной настолько, что запомнить все варианты переходов нереально. А их еще нужно запрограммировать и протестировать. Было несколько альтернатив, которые пытались это решить: Cicerone, Flow, Conductor. Ни один из них не является таким функциональным.
В первую очередь стоит отметить Navigation Editor: с ним удобно строить и графическую диаграмму переходов, и приятно управлять ею с помощью мыши. Реализована удобная обработка DeepLinks с поддержкой воспроизведения всего дерева переходов. Navigation Component делит работу с DeepLinks на два кейса: Explicit и Implicit. Первые мы можем создавать сами через удобное DSL и вызывать как PendingIntent через определенное действие. Второе — это привычные нам DeepLinks, например, из браузера. Они по-разному создаются и вызываются, но идентично обрабатываются c помощью графа навигации и полной поддержки построения стека для открытия необходимого раздела. Обрабатывать DeepLinks никогда не было так просто.
В AJP была добавлена Paging Library. Как она меняет работу с RecyclerView?
Денис Неклюдов: У RecyclerView всегда был недостаток: нужно потратить много времени на решение, которое осуществит постраничную загрузку в обе стороны, да еще и с возможностью перескакивать на разные участки этого бесконечного списка. В Paging Library Google представил свое решение данной проблемы.
Александр Смирнов: Библиотека повторяет рутинную операция большинства Android-разработчиков — работу со списками. Все мы для ускорения отображения больших наборов данных разбиваем их на страницы и работаем с ними. С помощью Paging Library подобная работа становится простой, так как мы получаем реализацию из коробки. Дополнительно компонент умеет работать над загрузкой данных из нескольких источников и миксовать их. Также мы получаем интересную идею с Placeholders, когда в момент дозагрузки данных можно показать красивые заглушки вместо вечных спиннеров. Кроме того, добавлена kill-feature работа со снапшотами или нестабильными данными — компонент может сам понимать, что было изменено и какие элементы нужно закинуть в центр списка, а какие — в начало.
По сути, этот компонент был создан для работы в связке с RecyclerView, но Paging Library состоит из двух основных частей: PagedList и PagedListAdapter. Собственно, с помощью PagedList можно работать с данным порциями, загружать из нескольких источников.
Одной из новинок стал Workmanager. Как он меняет работу с фоновыми задачами?
Александр Смирнов: Он помогает планомерно уйти от всемогущих сервисов к удобному API в Jetpack: позволяет добавлять необходимость выполнения условий окружения для запуска задачи, задавать порядок выполнения задач и цепочек. Можно передавать данные в исполняемую задачу и получать из нее результат. У него три огромных преимущества: не нужен Google Play на устройстве, можно запускать задачи только при соблюдении определенных условий, можно создавать цепочки задач.
Ни один из прошлых аналогов не был самодостаточен, поэтому существовала такая библиотека, как Android-Job от Evernote, которая использовала все аналоги сразу. После появления WorkManager необходимость в них отпадает.
Денис Неклюдов: У Google получилась такая большая обертка над всеми существующими решениями для работы с фоновыми задачами. С тем, что отложенную задачу просто так в Service выполнить не удастся, разработчики столкнулись с выходом Android Marshmallow и приходом Doze Mode. Теперь приложение не может делать все, что ему вздумается. И с каждой версией таких ограничений все больше и больше. Еще с Lollipop нам доступен JobScheduler, который запускает фоновые задачи при определенных условиях и с согласия системы, но у него есть баги на ранних версиях и неясно, как с ним работать в версиях Android, где его нет. Для этого была создана обертка в виде GCM network manager и переписана еще раз в виде Firebase Job Dispatcher. Но и они оказались неидеальны — так на свет появилась их современная замена WorkManager, который берет на себя задачу выполнения фоновых задач на любой версии Android без багов.
В AJP была добавлена новая возможность — Slices. Что в ней интересного?
Александр Смирнов: В первую очередь Slices стоит показать вашему продакту и маркетологу. Они позволяют пользователю чаще видеть ваше приложение и быстрее пользоваться необходимой его частью: перейти сразу в нужный раздел, переключить необходимую фичу. Также Slices позволяют участвовать вашему приложению среди поисковой выдачи в Google Search, а также в дальнейшем смогут встраиваться в Google Assistant.
В Slices можно вывести функции, которые связаны с типом вашего приложения и его возможностями. Можно выделить три группы: навигация, выполнение задачи, возвращение к данным. В целом от Slices пользователи получают более простое и быстрое взаимодействие, разработчики — больше трафика и возможностей вернуть пользователя в приложение.
Денис Неклюдов: Признайтесь, вам давно не хватало возможности получать в приложениях информацию с интерактивными элементами из приложений прямо из поиска. Slices решают именно такую задачу, позволяя приложению декларировать UI и действия с ним, который будет встроен в сторонние приложения, в том числе и в поиск. Я очень жду, когда в интерфейсе Google Assistant на смартфоне новости будут встроены из Feedly, фотки прошлого из Timehop, мои полеты из App in the Air, маршрут до работы «Я.Навигатор» и т. д.
Для владельцев приложений это отличная возможность увеличить частоту использования их сервисов, пользователю тоже станет удобнее переключать треки в Spotify, не выходя из нового гоночного симулятора.
А какие есть ограничения?
Александр Смирнов: Slices пока сильно урезан шаблонами: куча приложений встраивается в другие и пользователю нужно понимать, что механизм взаимодействия будет другой. За универсальность всегда нужно платить. Если вы вспомните Widgets, они также были сильно ограничены. Расширение функционала, конечно же, будет, но не думаю, что от этого стоит ждать чего-то большого.
Денис Неклюдов: Соглашусь, сейчас Slices API ограничено некоторым набором возможных шаблонов, которые можно встроить в стороннее приложение, но с новыми версиями будут появляться и новые шаблоны. Разработчики специально запретили кастомные интерфейсы, чтобы иметь возможность контролировать то, как слайсы выглядят во встраиваемом приложении, и чтобы все они были консистентны.
Google добавил в AJP библиотеку для работы с KTX. Каковы ваши впечатления от нее?
Александр Смирнов: Отличный инструмент, это как раз то, чего очень долго не хватало. KTX — это набор extensions для более приятного использования Android API в повседневных задачах.
Очень рекомендую перейти на него всем Android-разработчикам, чтобы повысить продуктивность. Он дает удобство, скорость и хорошее настроение при разработке. С помощью KTX можно еще больше схлопывать boilerplate и получать аккуратный, хорошо читаемый код.
Но нужно хорошенько изучить extensions, которые KTX предоставляет, и просмотреть исходный код этих расширений, чтобы понимать, что там происходит «под капотом». А так никаких подводных камней больше нет, смело можно брать в бой.
Денис Неклюдов: Разработчики AJP пришли к правильному решению: фреймворк должен быть более дружелюбным к Kotlin. Так родился проект с набором статических функций, расширяющий синтаксис фреймворка. В Kotlin много удобных возможностей языка, и как раз extension-функции позволяют обращаться к классам фреймворка в удобной манере. К примеру, view.isVisible идет как короткая альтернатива для view.getVisibility()==View.Visible.
Там очень много различных функций, лучше посмотрите сами. Конечно, можно жить и без них, как, собственно, и без Kotlin. Но так приятнее.
Google всё активнее продвигает Kotlin. Как вы к этому относитесь?
Какие у него перспективы?
Александр Смирнов: К Kotlin я отношусь очень позитивно и с января 2016 использую как основной язык разработки на Android. За это время участвовал в миграции трех компаний с Java на Kotlin. Java, к сожалению, развивается достаточно медленно, и Kotlin для мобильной разработки — глоток свежего воздуха.
Момент, когда Kotlin станет основным языком разработки под Android, — вопрос времени. Уже появляются Android-разработчики, у которых Kotlin является первым языком разработки, а Java — что-то малознакомое. Нас ждет приятное будущее с Kotlin, во всяком случае пока Google не решит построить новую ОС, так сказать, улучшенный Android. Но это вопрос отдаленного будущего, которое не факт что наступит.
Денис Неклюдов: Не могу сказать, что Google активно продвигает Kotlin, скорее некоторые проекты, связанные с самим фреймворком, становятся дружелюбными к Kotlin. Это вовсе не означает, что в 2018-м разработчик на Java под Android — какой-то отщепенец или представитель меньшинства. Но факт, что Kotlin все увереннее и быстрее становится языком по умолчанию для разработчиков, и это не может не радовать.
Когда слышишь о Flutter — кросс-платформенном фреймворке для мобильных приложений от Google, сразу эхом доносится Kotlin Native, который компилируется как под Android, так и под iOS. Многие ждут, когда он станет языком для всего: Android, iOS, Web, Embeded… Планы у JetBrains наполеоновские. Мы же наблюдаем, репортим баги, бетатестим и получаем удовольствие от приятного языка, на который с минимальной болью нам удалось мигрировать свои проекты.
Прошло уже более трех месяцев с выхода Android AJP. Как он себя показал?
Александр Смирнов: C помощью AJP Google планировал помочь Android-разработчикам создавать высококачественные приложения еще быстрее и без зоопарка дополнительных решений. А в качестве бонуса еще сильнее упростили вход новичкам в Android-разработку. Думаю, с поставленной задачей Jetpack справился.
Получился классный набор, решающий задачи большинства разработчиков. Но точно сказать мы сможем примерно через 6–12 месяцев, когда придем к релизу большинства нововведений. Пока это останавливает многих на пути к началу использования AJP в production.
Денис Неклюдов: Google не делал AJP с нуля, а соединил много полезных наработок, которые не входят в сам фреймворк и доупаковываются в приложения их разработчиками. Это хорошая идея — объединить их все под одним модным, ярким именем. Разработчикам хорошо, что теперь есть единый ресурс, где можно найти официальное решение множества проблем. Как минимум это удобно.
Конечно, не все, что входит в этот набор, уже готово для использования в серьезных приложениях, что-то до сих пор на стадиях активной разработки и отладки. От самого фреймворка стойкое ощущение бета-версии, я уж не буду давить на больное и обсуждать IDE. Но мы в Android привыкшие.
В этом списке библиотек и решений каждый найдет для себя что-то полезное. А уж начинающим разработчикам это однозначно обязательный для ознакомления ресурс, чтобы они не наступали на известные грабли, а сначала попробовали более-менее официальные способы решения их задач.
Какие перспективы развития AJP? Что может появиться нового в следующем году?
Александр Смирнов: Сейчас мы имеем много новых разработок, поэтому в первую очередь их необходимо финализировать и стабилизировать. Затем я бы ожидал планомерного развития каждого из компонентов и инструментария, возможно незначительное добавление чего-то нового. Jetpack был шагом вперед, поэтому от следующего года я ожидаю планомерных улучшений, а вот еще через год может быть и очень интересно. Чего точно стоит ждать в следующем году, так это более плотной и удобной интеграции с Android Studio.
Денис Неклюдов: AJP будет расширяться с каждой новой решенной задачей, которую вынесли в открытый доступ. С каждой версией Android будет развиваться и основа Jetpack в виде AppCompat и Material Components. Что появится в ближайшее время — сложно сказать, я жду, когда добавят Nitrogen — пакет утилит для тестирования приложений в большом масштабе.
Глобально Google постоянно расширяет возможности браузера, к чему это может привести в перспективе?
Денис Неклюдов: Я постоянно повторяю, что не надо воспринимать некоторые шаги Google как что-то глобальное и централизованное. Если у команды Chrome достаточно ресурсов на развитие AMP, PWA, а теперь еще и WebAssembly, это не означает, что есть заговор взять и перевести всех на веб к 202… году. Как и разработка Flutter не означает, что все мы станем использовать этот фреймворк, а потом Android и вовсе будет обречен умереть, ведь сначала ChromeOS, а потом и Fuchsia захватят все устройства пользователей. Этим летом Jake Wharton выступил на Droidcon Berlin с докладом о том, как размывается линия между вебом и нативными приложениями. Из доклада можно вывести, что в современной ситуации нужно как следует поддерживать все платформы отдельно и стараться переиспользовать код между ними. Однако если вы верите, что интернет может во всем мире быть очень высокоскоростным, стабильным и дешевым, то тогда, может, и есть у веб-приложений шанс доминировать. Но пока в это слабо верится.
Александр Смирнов: Переход с нативных приложений на Progressive Web Apps — мечта миллионов веб-разработчиков, менеджеров продуктов и огромного количества других людей. Выбирая PWA-приложение вместо мобайла, компания упрощает разработку, использование, обновление и привлечения пользователей. PWA — хорошее решение для большого сегмента простых мобильных приложений, а полностью отказаться от нативной разработки мы сможем очень нескоро.
Ну а кому интересно послушать новости из мира Android разработки в живую, узнать ещё много интересного про последние коварные планы Анклава Google, пообщаться с экспертами напрямую, ждём на нашей конференции AppsConf 2018.
 Александр Смирнов, co-founder и CTO в PapaJobs, основатель сообщества Android-разработчиков MOSDROID, ведущий видеоблога «Android в лицах». |
 Денис Неклюдов, первый GDE в России, работает в Сингапуре в 90seconds.tv, центровой ведущий подкаста AndroidDev, спикер разных конференций и автор нескольких курсов по разработке. |
Android Jetpack был представлен в мае этого года на Google I/O.
А чего вы ждали от той конференции? Ожидания оправдались?
Александр Смирнов: Я ожидал намного меньше, чем в итоге представили. Казалось, что развивать платформу с точки зрения бизнеса особо незачем. В mobile-сегменте Google добился уверенной победы в 87 % рынка с позитивными трендами, а последние несколько лет был виден выход ML в качестве их основного направления работы. Я ждал прогресса по Material Design, добавление ML-инструментов для разработчиков, выхода Constraint Layout 2.0. Но мы увидели огромный шаг в наведении порядка и поддержке разработчиков. Неожиданно порадовали новинки в AJP и начало борьбы за улучшенный Support. Привет, Android X.
Денис Неклюдов: Я придерживался главного правила поездок на продуктовые конференции: не ждать анонсов, революционных изменений, подарков — ничего, кроме встречи со старыми приятелями. Лишь бы ничего не сломали. Но нет, они представили Android X, миграция на который не самый приятный процесс в больших проектах. Но было и много позитивного. Самое ценное в Google I/O — это общение с разработчиками фреймворка и коллегами по цеху.
Какие новинки уже успели применить на практике?
Денис Неклюдов: Из AJP опробовали только миграцию на Android X. У меня в проекте проверенный набор решений, нет никакого желания спешить и внедрять новые компоненты. Просто поддержали Target SDK 28, проверили на недавнем релизе Android Pie и успокоились. Ждем, когда сделают доступными обещанные улучшения для тестирования. Jetpack сейчас — это собранные в одном месте различные маленькие библиотеки, которые иногда делают жизнь разработчиков чуть-чуть легче и приятнее. Большинство новинок пока не готовы для релизных версий приложений.
Александр Смирнов:
Из представленных новинок я попробовал все, но в production мы только обновили приложение на новый Material Design и применили Android KTX, который понравился своей простотой и удобством. Люблю схлопывать кучу кода в несколько строк. Остальное закинули в pipeline и перейдем в этому году.
Jetpack успешно выполнит поставленные задачи, и вам понравится его использовать. Но да, некоторые разделы пока что в альфе, поэтому на этапе разработки могут вылезать небольшие проблемы. Это нормально. Тащить в production инструменты в состоянии альфы я бы не рекомендовал, но с тем же Kotlin меня это не остановило.
Для Android всегда остро стоял вопрос удобной навигации.
С AJP что-нибудь поменяется?
Денис Неклюдов: В Android навигация всегда была мощной и разнообразной: Activity, Fragment, еще нужно DeepLinks обрабатывать и следить за передаваемыми аргументами. Можно легко запутаться в большой карте экранов. Google как раз стараются решить это новым Navigation, который даже встроен в Android Studio со своим реактором иерархии экранов.
Я пользуюсь самодельными решениями, которые соответствуют требованиям и общей архитектуре проекта. Пока в Navigation есть серьезные баги и он не готов к использованию в опубликованных приложениях.
Александр Смирнов: В Jetpack Google сделали серьезный шаг вперед: появился Navigation, который изменит архитектуру приложений в лучшую сторону. В крупных приложениях навигация может стать сложной настолько, что запомнить все варианты переходов нереально. А их еще нужно запрограммировать и протестировать. Было несколько альтернатив, которые пытались это решить: Cicerone, Flow, Conductor. Ни один из них не является таким функциональным.
В первую очередь стоит отметить Navigation Editor: с ним удобно строить и графическую диаграмму переходов, и приятно управлять ею с помощью мыши. Реализована удобная обработка DeepLinks с поддержкой воспроизведения всего дерева переходов. Navigation Component делит работу с DeepLinks на два кейса: Explicit и Implicit. Первые мы можем создавать сами через удобное DSL и вызывать как PendingIntent через определенное действие. Второе — это привычные нам DeepLinks, например, из браузера. Они по-разному создаются и вызываются, но идентично обрабатываются c помощью графа навигации и полной поддержки построения стека для открытия необходимого раздела. Обрабатывать DeepLinks никогда не было так просто.
В AJP была добавлена Paging Library. Как она меняет работу с RecyclerView?
Денис Неклюдов: У RecyclerView всегда был недостаток: нужно потратить много времени на решение, которое осуществит постраничную загрузку в обе стороны, да еще и с возможностью перескакивать на разные участки этого бесконечного списка. В Paging Library Google представил свое решение данной проблемы.
Александр Смирнов: Библиотека повторяет рутинную операция большинства Android-разработчиков — работу со списками. Все мы для ускорения отображения больших наборов данных разбиваем их на страницы и работаем с ними. С помощью Paging Library подобная работа становится простой, так как мы получаем реализацию из коробки. Дополнительно компонент умеет работать над загрузкой данных из нескольких источников и миксовать их. Также мы получаем интересную идею с Placeholders, когда в момент дозагрузки данных можно показать красивые заглушки вместо вечных спиннеров. Кроме того, добавлена kill-feature работа со снапшотами или нестабильными данными — компонент может сам понимать, что было изменено и какие элементы нужно закинуть в центр списка, а какие — в начало.
По сути, этот компонент был создан для работы в связке с RecyclerView, но Paging Library состоит из двух основных частей: PagedList и PagedListAdapter. Собственно, с помощью PagedList можно работать с данным порциями, загружать из нескольких источников.
Одной из новинок стал Workmanager. Как он меняет работу с фоновыми задачами?
Александр Смирнов: Он помогает планомерно уйти от всемогущих сервисов к удобному API в Jetpack: позволяет добавлять необходимость выполнения условий окружения для запуска задачи, задавать порядок выполнения задач и цепочек. Можно передавать данные в исполняемую задачу и получать из нее результат. У него три огромных преимущества: не нужен Google Play на устройстве, можно запускать задачи только при соблюдении определенных условий, можно создавать цепочки задач.
Ни один из прошлых аналогов не был самодостаточен, поэтому существовала такая библиотека, как Android-Job от Evernote, которая использовала все аналоги сразу. После появления WorkManager необходимость в них отпадает.
Денис Неклюдов: У Google получилась такая большая обертка над всеми существующими решениями для работы с фоновыми задачами. С тем, что отложенную задачу просто так в Service выполнить не удастся, разработчики столкнулись с выходом Android Marshmallow и приходом Doze Mode. Теперь приложение не может делать все, что ему вздумается. И с каждой версией таких ограничений все больше и больше. Еще с Lollipop нам доступен JobScheduler, который запускает фоновые задачи при определенных условиях и с согласия системы, но у него есть баги на ранних версиях и неясно, как с ним работать в версиях Android, где его нет. Для этого была создана обертка в виде GCM network manager и переписана еще раз в виде Firebase Job Dispatcher. Но и они оказались неидеальны — так на свет появилась их современная замена WorkManager, который берет на себя задачу выполнения фоновых задач на любой версии Android без багов.
В AJP была добавлена новая возможность — Slices. Что в ней интересного?
Александр Смирнов: В первую очередь Slices стоит показать вашему продакту и маркетологу. Они позволяют пользователю чаще видеть ваше приложение и быстрее пользоваться необходимой его частью: перейти сразу в нужный раздел, переключить необходимую фичу. Также Slices позволяют участвовать вашему приложению среди поисковой выдачи в Google Search, а также в дальнейшем смогут встраиваться в Google Assistant.
В Slices можно вывести функции, которые связаны с типом вашего приложения и его возможностями. Можно выделить три группы: навигация, выполнение задачи, возвращение к данным. В целом от Slices пользователи получают более простое и быстрое взаимодействие, разработчики — больше трафика и возможностей вернуть пользователя в приложение.
Денис Неклюдов: Признайтесь, вам давно не хватало возможности получать в приложениях информацию с интерактивными элементами из приложений прямо из поиска. Slices решают именно такую задачу, позволяя приложению декларировать UI и действия с ним, который будет встроен в сторонние приложения, в том числе и в поиск. Я очень жду, когда в интерфейсе Google Assistant на смартфоне новости будут встроены из Feedly, фотки прошлого из Timehop, мои полеты из App in the Air, маршрут до работы «Я.Навигатор» и т. д.
Для владельцев приложений это отличная возможность увеличить частоту использования их сервисов, пользователю тоже станет удобнее переключать треки в Spotify, не выходя из нового гоночного симулятора.
А какие есть ограничения?
Александр Смирнов: Slices пока сильно урезан шаблонами: куча приложений встраивается в другие и пользователю нужно понимать, что механизм взаимодействия будет другой. За универсальность всегда нужно платить. Если вы вспомните Widgets, они также были сильно ограничены. Расширение функционала, конечно же, будет, но не думаю, что от этого стоит ждать чего-то большого.
Денис Неклюдов: Соглашусь, сейчас Slices API ограничено некоторым набором возможных шаблонов, которые можно встроить в стороннее приложение, но с новыми версиями будут появляться и новые шаблоны. Разработчики специально запретили кастомные интерфейсы, чтобы иметь возможность контролировать то, как слайсы выглядят во встраиваемом приложении, и чтобы все они были консистентны.
Google добавил в AJP библиотеку для работы с KTX. Каковы ваши впечатления от нее?
Александр Смирнов: Отличный инструмент, это как раз то, чего очень долго не хватало. KTX — это набор extensions для более приятного использования Android API в повседневных задачах.
Очень рекомендую перейти на него всем Android-разработчикам, чтобы повысить продуктивность. Он дает удобство, скорость и хорошее настроение при разработке. С помощью KTX можно еще больше схлопывать boilerplate и получать аккуратный, хорошо читаемый код.
Но нужно хорошенько изучить extensions, которые KTX предоставляет, и просмотреть исходный код этих расширений, чтобы понимать, что там происходит «под капотом». А так никаких подводных камней больше нет, смело можно брать в бой.
Денис Неклюдов: Разработчики AJP пришли к правильному решению: фреймворк должен быть более дружелюбным к Kotlin. Так родился проект с набором статических функций, расширяющий синтаксис фреймворка. В Kotlin много удобных возможностей языка, и как раз extension-функции позволяют обращаться к классам фреймворка в удобной манере. К примеру, view.isVisible идет как короткая альтернатива для view.getVisibility()==View.Visible.
Там очень много различных функций, лучше посмотрите сами. Конечно, можно жить и без них, как, собственно, и без Kotlin. Но так приятнее.
Google всё активнее продвигает Kotlin. Как вы к этому относитесь?
Какие у него перспективы?
Александр Смирнов: К Kotlin я отношусь очень позитивно и с января 2016 использую как основной язык разработки на Android. За это время участвовал в миграции трех компаний с Java на Kotlin. Java, к сожалению, развивается достаточно медленно, и Kotlin для мобильной разработки — глоток свежего воздуха.
Момент, когда Kotlin станет основным языком разработки под Android, — вопрос времени. Уже появляются Android-разработчики, у которых Kotlin является первым языком разработки, а Java — что-то малознакомое. Нас ждет приятное будущее с Kotlin, во всяком случае пока Google не решит построить новую ОС, так сказать, улучшенный Android. Но это вопрос отдаленного будущего, которое не факт что наступит.
Денис Неклюдов: Не могу сказать, что Google активно продвигает Kotlin, скорее некоторые проекты, связанные с самим фреймворком, становятся дружелюбными к Kotlin. Это вовсе не означает, что в 2018-м разработчик на Java под Android — какой-то отщепенец или представитель меньшинства. Но факт, что Kotlin все увереннее и быстрее становится языком по умолчанию для разработчиков, и это не может не радовать.
Когда слышишь о Flutter — кросс-платформенном фреймворке для мобильных приложений от Google, сразу эхом доносится Kotlin Native, который компилируется как под Android, так и под iOS. Многие ждут, когда он станет языком для всего: Android, iOS, Web, Embeded… Планы у JetBrains наполеоновские. Мы же наблюдаем, репортим баги, бетатестим и получаем удовольствие от приятного языка, на который с минимальной болью нам удалось мигрировать свои проекты.
Прошло уже более трех месяцев с выхода Android AJP. Как он себя показал?
Александр Смирнов: C помощью AJP Google планировал помочь Android-разработчикам создавать высококачественные приложения еще быстрее и без зоопарка дополнительных решений. А в качестве бонуса еще сильнее упростили вход новичкам в Android-разработку. Думаю, с поставленной задачей Jetpack справился.
Получился классный набор, решающий задачи большинства разработчиков. Но точно сказать мы сможем примерно через 6–12 месяцев, когда придем к релизу большинства нововведений. Пока это останавливает многих на пути к началу использования AJP в production.
Денис Неклюдов: Google не делал AJP с нуля, а соединил много полезных наработок, которые не входят в сам фреймворк и доупаковываются в приложения их разработчиками. Это хорошая идея — объединить их все под одним модным, ярким именем. Разработчикам хорошо, что теперь есть единый ресурс, где можно найти официальное решение множества проблем. Как минимум это удобно.
Конечно, не все, что входит в этот набор, уже готово для использования в серьезных приложениях, что-то до сих пор на стадиях активной разработки и отладки. От самого фреймворка стойкое ощущение бета-версии, я уж не буду давить на больное и обсуждать IDE. Но мы в Android привыкшие.
В этом списке библиотек и решений каждый найдет для себя что-то полезное. А уж начинающим разработчикам это однозначно обязательный для ознакомления ресурс, чтобы они не наступали на известные грабли, а сначала попробовали более-менее официальные способы решения их задач.
Какие перспективы развития AJP? Что может появиться нового в следующем году?
Александр Смирнов: Сейчас мы имеем много новых разработок, поэтому в первую очередь их необходимо финализировать и стабилизировать. Затем я бы ожидал планомерного развития каждого из компонентов и инструментария, возможно незначительное добавление чего-то нового. Jetpack был шагом вперед, поэтому от следующего года я ожидаю планомерных улучшений, а вот еще через год может быть и очень интересно. Чего точно стоит ждать в следующем году, так это более плотной и удобной интеграции с Android Studio.
Денис Неклюдов: AJP будет расширяться с каждой новой решенной задачей, которую вынесли в открытый доступ. С каждой версией Android будет развиваться и основа Jetpack в виде AppCompat и Material Components. Что появится в ближайшее время — сложно сказать, я жду, когда добавят Nitrogen — пакет утилит для тестирования приложений в большом масштабе.
Глобально Google постоянно расширяет возможности браузера, к чему это может привести в перспективе?
Денис Неклюдов: Я постоянно повторяю, что не надо воспринимать некоторые шаги Google как что-то глобальное и централизованное. Если у команды Chrome достаточно ресурсов на развитие AMP, PWA, а теперь еще и WebAssembly, это не означает, что есть заговор взять и перевести всех на веб к 202… году. Как и разработка Flutter не означает, что все мы станем использовать этот фреймворк, а потом Android и вовсе будет обречен умереть, ведь сначала ChromeOS, а потом и Fuchsia захватят все устройства пользователей. Этим летом Jake Wharton выступил на Droidcon Berlin с докладом о том, как размывается линия между вебом и нативными приложениями. Из доклада можно вывести, что в современной ситуации нужно как следует поддерживать все платформы отдельно и стараться переиспользовать код между ними. Однако если вы верите, что интернет может во всем мире быть очень высокоскоростным, стабильным и дешевым, то тогда, может, и есть у веб-приложений шанс доминировать. Но пока в это слабо верится.
Александр Смирнов: Переход с нативных приложений на Progressive Web Apps — мечта миллионов веб-разработчиков, менеджеров продуктов и огромного количества других людей. Выбирая PWA-приложение вместо мобайла, компания упрощает разработку, использование, обновление и привлечения пользователей. PWA — хорошее решение для большого сегмента простых мобильных приложений, а полностью отказаться от нативной разработки мы сможем очень нескоро.
Ну а кому интересно послушать новости из мира Android разработки в живую, узнать ещё много интересного про последние коварные планы Анклава Google, пообщаться с экспертами напрямую, ждём на нашей конференции AppsConf 2018.
Для тех, кто предпочитает изучать всё дома, у нас есть YouTube-канал, где будут выложены видеозаписи AppsConf (через несколько месяцев после конференции).
А анонсы всех событийи полезные материалы, включая будущие конференции, анонсы лучших докладов, приглашения на митапы, расшифрованные доклады и полезные статьи, мы публикуем в нашем списке рассылки.
