Proto datastore и его тестирование

👉 Типобезопасная замена SharedPreferences
👉 Protobuf в основе
👉 Поддержка корутин и своя библиотека для тестирования

Кодлаба от гугла, чтобы понять как мигрировать
Документация по proto 3

Android 15 Beta!

Семимильными шагами гугл готовится к Google I/O

👉 Edge2Edge скролл. Красиво, но мы знаем сколько боли приносит работа с Toolbar и AppBar. Убирают привычный хак setDecorFitsSystemWindows. Чего нам ждать тут?
👉 Улучшение работы с NFC. Кто сейчас в приложении это использует активно, расскажите как дела обстоят?
👉 Автоархивирование приложений, анонсировано было ранее. Возможно будем бороться так же, как боремся с doze mode
👉 Улучшенный профайлинг. Больше данных, легче отлавливать проблемы!
👉 Поддержка TalkBack для людей с ограниченными возможностями. Отлично дополняется этим постом
👉 Сквозное шифрование и повышенная защищенность фоновых процессов. Чуть больше про шифрование писал тут

Поставить Android 15 beta себе на Pixel можно тут

Уже попробовали обновленный профайлер? А Google выкатывает статью о применении его в A/B тестах

Подразумевается, что с помощью power profiler можно найти:
👉 Энергозатраный неоптимизированный код
👉 Лишние фоновые процессы

Сценарии, описанные в статье, реализуемы и с помощью стандартного профайлера. Но почему бы и не воспользоваться точной количественной метрикой?

Пятница! Если уж релизите в пятницу, то проведите дополнительные тесты, а именно Accessibility Check

Android Studio Iguana уже стабильна, а это значит вам точно доступен UI check mode, которая покажет как на разных экранах будет выглядеть ваше приложение

Подробнее с примерами и что делать, если проблемы обнаружены

Раньше, во времена XML, у нас была удобная превьюшка цветов. С приходом Jetpack Compose мы потеряли этот функционал.

Полезный плагин, который это возвращает на поля для вашего удоства! А что внутри?
👉 Превью для объектов типа Color
👉 Старый добрый color picker по клику на превью
👉 Превью для функций compositeOver, copy, convert и lerp

Библиотека свежая, поэтому не стесняйтесь оставлять issues. Исходники можно глянуть тут

Фокус как состояние: эффективный фокус-менеджмент на Android TV с Jetpack Compose.

👉 Это не стандартное решение типа Leanback или Compose for TV
👉 Основная проблема решения - фокус не является частью состояния, поэтому приходится использовать модификаторы помощи focusRequester, onFocusChanged, focusable и focusProperties
👉 Текущий фокус определен для экрана в целом
👉 Благодаря этому подходу можно легко тестировать фокус и его ожидаемое изменение
👉 Восстановление фокуса работает из коробки, так как теперь он зависит от состояния, а также становится проще отлаживать приложение

Исходя из реализации, стандартный фокус-менеджмент блокируется целиком, и подменяется реализацией через состояние. Отсюда возникают проблемы и собственные решения в списках и в иных пограничных случаях.

Продолжаем тему собеседований. Блок вопросов про многопоточность в приложении. Подойдет как для подготовки к собеседованиям, так и для использования в вопросах на собеседовании:

👉 Что такое корутины и как они связаны с потоками?
👉 Зачем вам использовать корутины?
👉 Как создать корутину и управлять ею?
👉 В чем разница между launch, async и runBlocking?
👉 Что представляет собой coroutineScope?
👉 Зачем нужны suspend функции и в чем их отличие от обычных?
👉 Как обрабатывать исключения в корутинах (кроме try-catch)?
👉 Что такое coroutineContext и coroutineDispatcher, и когда вы их используете?
👉 Как остановить выполнение корутины?

Ответы тут
Документация тут

За inline замолвите слово.. Мне, честно говоря, нечего более добавить. Если вам кажется что вы мало знаете про inline, читайте пост от @rareilly

Немного красивых замеров того как K2 ускоряет сборку. Тесты проводили над Anki-Android для чистой и инкрементальной сборки.

Как самому провести этот бенчмарк и узнать данные для вашего устройства - тут
Остальные замеры тут

Реализация кэширования с OkHttp
Ускоряем работу приложения, жертвуя возможной актуальностью данных.

👉 Кэширование API-запросов с использованием CacheControl из OkHttp помогает позволяет сохранять ответы API с заданным сроком годности, уменьшая количество API-запросов и снижая время отклика
👉 Правила кэширования могут быть установлены в зависимости от статуса интернет-соединения. Например, когда соединение активное, можно использовать кэшированные ответы за последние 30 минут, а в режиме офлайн — ответы, возраст которых составляет до 1 дня, для улучшения пользовательского опыта
👉 Механизм перехватчиков из OkHttp позволяет модифицировать HTTP-запросы и ответы, что способствует реализации правил кэширования. Функции, такие как maxAge() и maxStale(), контролируют свежесть ответов, помогая эффективно управлять кэшем

В статье приводится пример клиента, который можно прямо сейчас взять и подставить в ваш проект, чтобы сразу увидеть результат. Используете ли вы кэширование запросов в проекте?

Как написать свой плагин для Android Studio?

На удивление, все довольно просто:

1) Для проекта есть специальный шаблон в IDE
2) Настраиваем gradle-файл, устанавливая версию IDE, которая поддерживается
3) Определяем действие и прикрепляем ссылку на него в конфигурацию

class MyDemoAction : AnAction() {
    override fun actionPerformed(e: AnActionEvent) {
        val message = "Great! You just created your first action!"
        Messages.showMessageDialog(
            e.project,
            message,
            "Android Good Reads!",
            Messages.getInformationIcon()
        )
    }
}

5) Можно добавить интерфейс к плагину, разработанный с помощью Java Swing
6) Собираем плагин с помощью ./gradlew buildPlugin и делимся с командой своим новым плагином. Установка плагина проста: перейдите в Settings -> Plugins -> Installed Tab -> Gear Icon -> Install Plugin From Disk

"Зачем вам это?" На мой взгляд - для автоматизации рутинных действий внутри команды. Возможность запустить действие через кнопку с параметрами, а не командой в консоли, делает процесс более комфортным и простым

Новый нейминг для Android Studio! - Feature Drop

Вкратце:

Сначала будет представлено обновление на основе обновлений IntelliJ IDEA, а затем, в Feature Drop, обновление специфичное для Android.
AGP будет обновляться вместе c Feature Drop

В итоге:
Обновление AS и AGP в 2 раза чаще. Как вам?

Финальный шаблон версионирования:
<Год версии IntelliJ>.<Основная версия IntelliJ>.<Основная версия Studio>

Привет! Меня зовут Антон, и последние 4 месяца я пишу для вас выжимки интересных статей про Android. Кажется, пора познакомиться?

Я живу и работаю в Швеции, где мы разрабатываем приложение на KMP с Jetpack Compose сразу для обеих платформ, поэтому в выборе статей вы можете заметить больший уклон в эти технологии. Я стараюсь выбирать либо практически полезные статьи, либо интересные, а также иногда делаю разборы нововведений.

Чуть больше обо мне можно узнать тут - https://www.linkedin.com/in/akondratiuk-software-engineer

Пожалуйста, оставляйте свои реакции на постах, чтобы я мог корректировать выбор статей, что вам нравится, а что кажется не интересным!

Что такое нативная разработка?

Обсудим концепцию нативной разработки в контексте Android и iOS. Это понятие размылось с появлением кроссплатформенных технологий.

Исторически, нативная разработка относилась к приложениям, разработанным с использованием языков, специфичных для своей платформы (Java/Kotlin для Android и Objective-C/Swift для iOS). Однако с появлением дизайн-систем, акцент сместился с технической реализации на UI/UX. Использование родных системе компонентов предполагало что приложением может сойти за нативное?

Автор предлагает, что дизайн-системы и пользовательский опыт не определяют, является ли приложение нативным. Скорее это зависит от контекста платформы, для которой оно предназначено.

Современные мобильные фреймворки, такие как React Native и Flutter, предназначены для облегчения разработки приложений для мобильных платформ, но они работают в своих изолированных средах, требуя большого количества слоев абстракции для взаимодействия с системой, что может привести к избыточности и неэффективности в некоторых случаях. Можно ли это считать нативным подходом? Думаю, что нет

В отличие от этого, Kotlin выделяется как нативный язык благодаря своей архитектуре компилятора, позволяющей прямое взаимодействие с Java, Swift, JavaScript и WebAssembly. Встроенная интероперабельность Kotlin устраняет необходимость в промежуточном слое или собственной виртуальной машине, позволяя ему без проблем обмениваться объектами между платформами и генерировать нативный код для каждой целевой платформы. Получается, что Kotlin является нативным языком для разработки приложений на iOS тоже?

Итого:
Концепция нативности приложения относительна и зависит от контекста платформы, для которой она предназначена. В то время как дизайн-системы и пользовательский опыт важны, они не определяют, что означает быть нативным. Вместо этого способность к обмену памятью и стеком вызовов с базовой системой является ключевым критерием для нативной функциональности, а Kotlin соответствует этому критерию.

К слову о KMP

Заявлена официальная поддержка KMP от Google