Что такое jetpack android
Введение в Jetpack Compose
Что такое Jetpack Compose
Jetpack Compose представляет современный тулкит от компании Google для создания приложений под ОС Android на языке программирования Kotlin. Jetpack Compose упрощает написание и обновление визуального интерфейса приложения, предоставляя декларативный подход.
Jetpack совместим с существующим набором библиотек Android, которые можно использовать в стандартных проектах на Java и Kotlin для написания приложений под Android. Отличительной же чертой Jetpack Compose является то, что он предлагает кардинально другой подход к созданию приложений.
Прежде всего, Jetpack Compose предлагает использовать язык Kotlin и все его преимущества. Соответственно для работы с тулкитом необходимо иметь базовые знания данного языка. Для этого можно обратиться к руководству по языку Kotlin на этом сайте.
Jetpack уменьшает объем кода.
Jetpack Compose предлагает декларативный API, который является более интуитивным.
Установка средств разработки
Здесь же мы можем указать место для установки Android SDK, если путь по умолчанию нас не устраивает.
Первое впечатление от Android Jetpack Compose
После того, как на Google IO 2019 я увидел доклад про Android Jetpack Compose, захотелось сразу же его попробовать. Тем более, что подход, реализованный в нём, очень напомнил Flutter, которым я интересовался ранее.
Сама библиотека Compose находится в пре-альфа стадии, поэтому доступно не так много документации и статей про нее. Далее я буду полагаться на несколько ресурсов, которые мне удалось найти, плюс открытые исходники библиотеки.
Что такое Android Jetpack Compose?
Раньше весь UI в Android был основан на классе View. Так повелось с первых дней Android. И в связи с этим накопилось множество легаси и архитектурных недостатков, которые могли бы быть улучшены. Но сделать это достаточно сложно, не сломав весь код, написанный на их основе.
За последние годы появилось множество новых концептов в мире клиентских приложений (включая веяния Frontend-а), поэтому команда Google пошла радикальным путём и переписала весь UI-уровень в Android с нуля. Так и появилась библиотека Android Jetpack Compose, включающая в себя концептуальные приёмы из React, Litho, Vue, Flutter и многих других.
Давайте пройдемся по некоторым особенностям существующего UI и сравним его с Compose.
1. Независимость от релизов Android
Существующий UI тесно связан с платформой. Когда появились первые компоненты Material Design, они работали только с Android 5 (API21) и выше. Для работы на старых версиях системы необходимо использовать Support Library.
Compose же входит в состав Jetpack, что делает его независимым от версий системы и возможным для использования даже в старых версиях Android (как минимум с API21).
2. Весь API на Kotlin
Раньше приходилось иметь дело с разными файлами, чтобы сделать UI. Мы описывали разметку в xml, а затем использовали Java/Kotlin код, чтобы заставить ее работать. Затем мы снова возвращались в другие xml-файлы для того чтобы задать темы, анимацию, навигацию,… И даже пытались писать код в xml (Data Binding).
Использование Kotlin позволяет писать UI в декларативном стиле прямо в коде вместо xml.
3. Composable = Композитный: использование композиции вместо наследования
Создание кастомных элементов UI может быть довольно громоздким. Нам необходимо унаследоваться от View или его потомка и позаботиться о многих важных свойствах перед тем, как он правильно заведется. Например, класс TextView содержит около 30 тысяч строк Java-кода. Это связано с тем, что он содержит множество лишней логики внутри себя, которую наследуют элементы-потомки.
Compose подошел с другой стороны, заменяя наследование композицией.
Padding как нельзя лучше подойдет для иллюстрации того, о чем речь:
В существующем UI для того, чтобы отрисовать TextView c отступами в 30dp :
нам нужно написать следующий код:
Это означает, что где-то внутри TextView.java или его суперклассов содержится логика, которая знает, как посчитать и отрисовать отступы.
Давайте посмотрим, как можно сделать то же самое в Compose:
Преимущества
Таким образом, Text отвечает только за отрисовку непосредственно текста. Он не знает про то, как считать отступы. С другой стороны, Padding отвечает только за отступы и ничего больше. Он может быть использован вокруг любого другого элемента.
4. Однонаправленный поток данных
Использование Compose поможет решить эти проблемы, так как в его основе заложен принцип однонаправленности. Изменение состояния будет обрабатываться внутри фреймворка: мы просто отдаем модель данных внутрь. Кроме того, компонент в Compose теперь не меняет свое состояние самостоятельно. Вместо этого он только вызывает callback, и теперь это задача приложения изменить UI.
5. Улучшение отладки
Так как теперь весь UI написан на Kotlin, теперь можно дебажить UI. Я не попробовал это сам, но в подкасте говорили, что в Compose работают дебаггер и точки остановки.
Хватит слов, покажите код
Я знаю, хочется поскорее увидеть, как выглядит UI в коде (спойлер: очень похоже на Flutter, если вы пробовали писать на нем).
1. FrameLayout vs Wrap + Padding + Background
Переиспользуем наш пример выше и попробуем сделать этот TextView с отступами в 30dp и бирюзовым фоном:
Теперь посмотрим на код, который делает то же самое в Compose:
Здесь появляется несколько новых вещей. Так как Text знает только про рендеринг текста, он не заботится об отступах и фоне. Поэтому, чтобы добавить их, нам нужно использовать три отдельные функции:
Легко. Но немного отличается от существующей UI-системы, к который мы все привыкли.
2. Вертикальный LinearLayout vs Column
Код будет выглядеть так:
Вложенные в Column элемент будут расположены вертикально друг под другом.
2a. Отступы
2b. Интервалы
Мы можем также добавить немного отступов между Text и Button :
Как выглядит наш экран теперь:
2c. Горизонтальный LinearLayout vs Row
Поместим вторую кнопку рядом с первой:
Внутри Row две кнопки будут расположены горизонтально. WidthSpacer добавляет расстояние между ними.
2d. Gravity vs Alignment
Выровняем наши элементы по центру, как это делает gravity в текущем UI. Чтобы показать diff, я закомментирую старые строки и заменю их новыми:
2d. Замечание
Более сложные элементы, такие как RecyclerView или ConstraintLayout находятся в разработке: поэтому я не смог найти пример с ними в демонстрационных исходниках.
3.Стили и темы
Вы, вероятно, заметили, что кнопки выше по умолчанию фиолетовые. Это происходит потому, что они используют стили по умолчанию. Рассмотрим, как работают стили в Compose.
MaterialTheme позволяет кастомизировать тему для элементов.
Например, я могу изменить основной цвет темы (primary color) на каштановый следующим образом:
Теперь наш экран будет выглядеть так:
Другие цвета и шрифты, которы можно поменять: MaterialTheme.kt#57
Rally Activity содержит хороший пример, как можно кастомизировать тему: source code to RallyTheme.kt
Что посмотреть/почитать
Если вы хотите большего, вы можете собрать проект-образец по инструкции тут.
Как пишут пользователи Windows, сейчас не существует официального способа запустить Compose, но есть неофициальный гайд из kotlinlang Slack.
Вопросы про Compose можно задать разработчикам в канале #compose kotlinlang Slack.
Оставляйте другие ссылки в комментариях — самые полезные добавлю сюда.
Выводы
Разработка этой библиотеки идет полным ходом, поэтому любые интерфейсы, показанные здесь могут быть изменены. Остается еще множество вещей, про которые можно узнать в исходном коде, как например @Model и Unidirectional data flow (однонаправленный поток данных). Возможно, это тема для будущих статей.
Погружение в Jetpack Compose
Всем привет. Перед уходом на выходные спешим поделиться с вами еще одним переводом, подготовленным специально для студентов курса «Android-разработчик. Продвинутый курс».
Пробуем новый UI-фреймворк для Android-приложений
В течение последних нескольких лет, участвуя во многих мобильных проектах, мне приходилось использовать различные технологии, например, такие как Android, ReactNative и Flutter. Переключение с ReactNative обратно на классический Android вызвало у меня смешанные чувства. Возвращение к Kotlin прошло хорошо, но я очень скучал по UI-фреймворку React. Небольшие повторно используемые компоненты, с помощью которых создается пользовательский интерфейс, великолепны и обеспечивают большую гибкость и скорость разработки.
Вернувшись в классический Android, мне нужно было беспокоится о том, чтобы сохранить иерархию View как можно более однообразной. Из-за этого трудно по-настоящему посвятить себя компонентному подходу. Это делает копипаст более заманчивым, что приводит к более сложному и менее поддерживаемому коду. В конечном итоге мы удерживаем себя от экспериментов с пользовательским интерфейсом, которые могли бы улучшить UX.
Android раскрывает Jetpack Compose. Иллюстрация: Эмануэль Багилла (Emanuel Bagilla)
Jetpack Compose спешит на помощь
Поэтому после просмотра What’s new in Android с конференции Google I/O 2019 я сразу же начал разбираться с Compose и постарался больше узнать о нем. Compose — это инструментарий реактивного пользовательского интерфейса, полностью разработанный на Kotlin. Compose выглядит очень похоже на существующие фреймворки пользовательских интерфейсов, такие как React, Litho или Flutter.
Нынешняя структура UI-фреймворка Android существует с 2008 года, и со временем стала более сложной, ее довольно тяжело поддерживать. Jetpack Compose стремится начать все с начала с учетом философии современных компонентов. Фреймворк написан с учетом следующих основных целей:
Простое приложение с Compose: Hello World
Давайте посмотрим на код простого приложения «Hello World» с Jetpack Compose.
Введение состояния
Управление потоком данных и состояниями может быть сложной задачей. Чтобы проиллюстрировать, насколько это легко с Compose, давайте создадим простое приложение-счетчик.
Для работы с состояниями Jetpack Compose использует идеи других современных UI-фреймворков, таких как Flutter и React. Существует однонаправленный и реактивный поток данных, который заставляет ваш виджет обновляться или «перекомпоновываться».
В примере выше мы добавляем кнопки «Add» и «Subtract» вместе с лейблом, отображающим текущее количество нажатий. Как вы можете видеть в примере ниже, обновляя состояние «amount», виджеты разумно перекомпоновываются при изменении состояния.
Запуск демо-приложения
Состояние amount инициализируется с помощью +state < 0 >. Пытаясь выяснить, что это за колдовство, я залез в исходный код. Это мое мнение, хотя я все еще не уверен, что до конца все понимаю.
Пользовательские модели состояний
Вместо использования +state <> для создания модели отдельного значения мы также можем создать пользовательскую модель с помощью аннотации @Model. Мы можем улучшить наше приложение-счетчик, разделив его на более мелкие виджеты и передав модель другим виджетам, которые обновляются и отображают состояние этой модели.
Больше никаких view
Важно понимать, что виджеты Jetpack Compose не используют под капотом view или fragment, это всего лишь функции, которые рисуют на холсте. Плагин Compose Compiler обрабатывает все функции с аннотацией @Composable и автоматически обновляет UI-иерархию.
Layout Inspector инспектирует приложение Jetpack Compose.
Все элементы являются виджетами
Совсем как у Flutter, в Compose все элементы — это виджеты. Более сложные виджеты были разбиты на элементарные виджеты с четкими обязанностями. Поэтому даже padding, spacers и так далее являются виджетами. Например, если вы хотите добавить отступ вокруг кнопки, просто оберните ее в padding виджет:
Соединение кода с пользовательским интерфейсом
Соединять Kotlin-код с UI-виджетами очень легко. Например, если вы хотите показать пользовательский интерфейс, которые повторяется или зависит от каких-то условий. Так, вы можете легко отобразить список имен, как показано ниже.
Это действительно мощная фича, но вы должны быть осторожны, чтобы не запрограммировать слишком много логики на уровне пользовательского интерфейса.
Совместимость с вашими Android-приложениями
Compose разработан таким образом, что вы можете добавить его в уже существующее приложение и постепенно перенести некоторые части вашего UI в новый фреймворк. Приведенные выше примеры добавляют Jetpack Compose UI к одному activity. Также вы можете встроить Compose-виджеты в существующий XML layout с помощью аннотации GenerateView :
Заключение
Я в восторге от Compose, потому что он уменьшает растущие страдания, которую я испытываю при разработке под Android. Он помогает быть более гибким, фокусироваться на создании удобного пользовательского интерфейса, а четкая ответственность также позволяет избежать ошибок.
У Compose впереди долгий путь, на мой взгляд, его можно будет использовать в продакшене не раньше чем через год или два. Тем не менее, я думаю, что сейчас подходящий момент, чтобы взглянуть на Jetpack Compose. Создатели активно ищут фидбек, на этом этапе все еще можно вносить изменения. Все отзывы помогут улучшить этот новый фреймворк.
Прочитайте мою статью «Try Jetpack Compose today», чтобы узнать, как подключить пре-альфа Compose. Также, я думаю, вам очень интересно будет посмотреть видео по шаблонам декларативного интерфейса с Google I/O.
Я с нетерпением жду, когда смогу использовать Compose в реальных Android-приложениях!
Вот и все. Ждем ваши комментарии и отличных всем выходных!
Jetpack Compose — как легко построить UI на Android
В июле этого года вместе с Android Studio Arctic Fox вышла одна из долгожданных библиотек — Jetpack Compose. Она позволяет создавать пользовательский интерфейс в декларативном стиле и обещает быть революцией в построении UI.
Разбираемся, так ли это на самом деле, какие у библиотеки преимущества и недостатки. Подробности — в статье.
Преимущества Jetpack Compose
Jetpack Compose — это набор инструментов для разработки UI в Android-приложении. Он призван ускорить и упростить разработку пользовательского интерфейса, избавить от лишнего кода и соединить модель реактивного программирования с лаконичностью Kotlin.
Сразу с места в карьер — какие есть преимущества у библиотеки:
1. Меньше кода. Jetpack Compose позволяет писать меньше кода, а значит разработчик может больше фокусироваться на проблеме, с меньшим количеством тестов и дебага, а значит и багов.
2. Интуитивно понятный. Compose использует декларативный API — разработчику нужно лишь сказать, что сделать, а все остальное ляжет на плечи библиотеки.
3. Удобство внедрения. Compose совместим с любым существующим кодом. Например, можно вызвать Compose-код из вьюх (view) и, наоборот, вьюхи из Compose. Многие библиотеки вроде Jetpack Navigation, ViewModel и Coroutines уже адаптированы под Compose, что позволяет сравнительно быстро внедрить его в свой код. Кроме того, Android Studio Arctic Fox поддерживает превью создаваемых вьюх.
4. Имеет обширный инструментарий. Jetpack Compose позволяет создавать красивые приложения с прямым доступом к Android Platform API и build-in поддержкой Material Design, тёмной темы, анимаций и других крутых штук.
Далее пройдёмся по основным аспектам библиотеки и посмотрим, как сильно повышается производительность приложения.
Подключение к проекту
Чтобы подключить Jetpack Compose к проекту, необходимо указать некоторые строки кода в своем build.gradle.
В рутовом объявим переменную с версией Compose:
Здесь мы указываем, что в проекте будем использовать Jetpack Compose и объявляем необходимые зависимости (подробнее про зависимости можно почитать в официальном гайде).
Дальше всё просто. В активити (activity) объявлем Composable-функцию, строим иерархию вьюх с указанием необходимых атрибутов и смотрим результат.
Пройдемся по коду. Я написал две реализации вёрсток различной сложности:
1. Простая реализация
Добавляет TextView в вёрстку с текстом с конкатенацией Hello и аргумента, переданного в Greeting.
Важно отметить, что имена Composable-функций начинаются с заглавной буквы. Это соглашение по наименованию функций, поэтому если писать со строчной, то студия будет подсвечивать неверный нейминг.
2. Более сложная реализация
Этот вариант представляет собой скролящийся экран, который содержит изображение, текст и кнопку. Рассмотрим некоторые особенности:
Необходимо объявить Scroll State. Только не обычный, а тот, который позволяет сохранять состояние скролла сквозь рекомпозицию — rememberScrollState().
Column представляет собой ViewGroup с вертикальным расположением элементов.
Modifier позволяет управлять атрибутами, добавлять декорации и поведение к вьюхам.
Остальное интуитивно понятно. И это как раз одна из ключевых особенностей Jetpack Compose — даже если вы не использовали библиотеку ранее, то всё равно с ней разберётесь.
Добавить вьюхи в активити можно через extension setContent <>, например:
В общем-то, создание UI выглядит действительно просто. Теперь определим, насколько сильно оптимизируется приложение и как быстро пользователь увидит окончательный экран.
Для тестирования воспользуемся библиотекой Jetpack Benchmark, о которой, кстати, тоже рассказывали в отдельной статье. Код теста выглядит так:
Протестируем три версии установки вьюхи в активити:
При передаче ресурса в setContentView.
При передаче вьюхи в setContentView.
Итоги тестирования можно посмотреть в таблице: левый столбец — название теста, правый — время на выполнение:
Android Jetpack: превращаем приложения в ракеты
Война… Война никогда не меняется. Так, война за красивый и работающий код идет постоянно. И на каждую сложную задачу рождается свое оружие: кто-то делает его под себя, а кто-то пользуется готовыми инструментами. Разработка под Android не исключение. На нашей конференции AppsConf 2018 мы обсудим, как и чем сейчас интереснее всего пользоваться, где можно споткнуться и что интересного есть в огромном арсенале средств разработки, который Google наконец начал приводить в порядок. Основные темы докладов можно посмотреть на нашем сайте, а пока мы попросили рассказать Google Developer Expert Дениса Неклюдова и Александра Смирнова о новом инструментарии Android Jetpack, который был представлен в мае этого года.
 Александр Смирнов, 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 (через несколько месяцев после конференции).
А анонсы всех событийи полезные материалы, включая будущие конференции, анонсы лучших докладов, приглашения на митапы, расшифрованные доклады и полезные статьи, мы публикуем в нашем списке рассылки.