DIY: Твоя собственная библиотека для инъекции зависимостей

Лучший способ понять, какая библиотека для инъекции зависимостей вам нужна, — начать писать свою! Автор пишет DI-библиотеку и применяет ее на достаточно простом, но прикладном кейсе.

👉 Анти-паттерн. Если вы протаскиваете зависимость через десятки классов, только ради использования в последнем
👉 Автор изобретает заново шаг за шагом Google Guice, затем Dagger 1 и в конечном счете Dagger 2. Достаточно показательно, как приходили к существующим решениям в библиотеках
👉 Интересно было посмотреть, как генерируются factory-классы через KSP
👉 Красивая работа с аннотациями, которую можно рассматривать в отрыве от статьи

А что вы используете в проекте?

Оптимизация запуска приложения

Уже оптимизировали все запросы на старте приложения, а оно все равно долго запускается?

👉 Едим слона по частям и определяем корректные метрики для измерения старта приложения. Firebase в помощь
👉 Холодный/Горячий/Теплый старт - разделяем их и анализируем изменения по каждому отдельно
👉 Утаскиваем инициализацию тяжелых библиотек и content provider, не нужных на старте, на поздний этап с помощью Startup Library
👉 Генерируем Baseline Profiles, что приводит к небольшому приросту в 7 процентов
👉 Делаем дамп в профайлере, загружаем в Perfetto и ищем самые широкие столбцы - они отнимают больше всего времени
👉 Если в отображении много пропусков, добавляем trace в самые неочевидные для вас места
👉 Обращаем внимание на то, как рендерятся стартовые экраны. Возможно, стоит воспользоваться ViewStubs, чтобы предотвратить ненужные перетасовки лейаута?
👉 Для простых экранов LinearLayout немного быстрее, чем ConstraintLayout, если вы еще используете xml

Разбираем поддержку ресурсов в Compose Multiplatform

Недавнее обновление библиотеки Compose принесло улучшенную работу с ресурсами. Разбираемся, что и как!

👉 После обновления зависимостей в папке commonMain создаем composeResources
👉 По аналогии с ресурсами в Android создаем папки для ресурсов: drawable, font, values
👉Обращение к ресурсам аналогично R классу в Android:

Res.drawable.icon_one

👉 У новых ресурсов есть поддержка языков, по аналогии с ресурсами в нативном Android. То есть values-es является рабочим вариантом для локализации KMP приложения на испанский

Не забываем что это альфа релиз, ложка дегтя:
😡 Проблемы с плагином, исправлено в 1.6.0-dev1405
🤔 .ttf шрифты не работают, конвертируйте в .otf
😡 Нет поддержки plurals
😡 Res класс очень нестабилен и иногда не генирируется (пересборка проекта помогает)

UPD: Шрифты работают, issue

38 частых ошибок в Compose

Боитесь перехода на Compose? Слышали о большом количестве проблем, которые возникли даже до его релиза? Предлагаю развеять свои страхи и поискать их в этой статье. В ней представлена большая подборка известных страхов, проблем а также их решений:

💪 Проблемы с производительностью, обработкой состояний, рекомпозицией
💪 Утечки памяти, асинхронная работа, оптимизация работы с памятью
💪 Темы, стили
💪 Работа со сторонними библиотеками, локализация

С помощью этого списка можно довольно подробно разобраться в большом количестве ситуаций по схеме: Проблема - Анализ - Пример кода - Решение

Multiplatform magic: One Codebase, Three Platforms

Завершаем неделю статей про Jetpack Compose, рассмотрев пример кросс-платформенного приложения на KMP

👉 Отличный пример, чтобы понять, как работает KMP и как его можно приложить к вашему проекту. Используется и многопоточность на корутинах,и SQL база данных,и работа с API
👉 Стек технологий: ktor, compose, coroutines и sqldelight
👉 В этом примере используется API, а не SDK, что позволяет прикинуть как это будет выглядеть в вашем приложении с вашим REST API
👉 В конце статьи видео того как это работает на Android, iOS и Desktop

Одним из недостатков KMP в настоящее время является сложности с локализацией, что было опущено в статье. Но может в ближайших релизах станет лучше?

Дедлайны в Google Play

Грядущие обновления политик в Google Play могут принести неприятности. За их несоблюдение вы рискуете быть лишенным обновлений, а затем, временно удалены из магазина. Лучше заложить в планирование исправление этих проблем заранее!

Прошедший январь
🤜 SafetyNet считается устаревшей системой. Она в основном используется для капчи старого образца и иногда используется в старых версиях библиотек Firebase, связанных с авторизацией. Это обновление требует небольших доработок на бекенде!
🤜 Ограничение на использование GenAI.
🤜 Все новые приложения должны использовать свежий API для управления подписками

Февраль
🤜 Необходимо пройти верификацию аккаунта разработчика

Май
🤜 Все приложения должны использовать новый API для управления подписками
🤜 USE_FULL_SCREEN_INTENT выдается автоматически только приложениям, которым это нужно (возможно, будет добавлен флажок в Google Play).
🤜 Новые требования для приложений, связанных со здоровьем

Август
🤜 Ограничение приложений на использование пермишна связанного с доступом к фото и видео пользователя. Переходите лучше на системный способ выбора фото, или придется доказывать Google Play что это действительно надо

- Январь 2025
🤜 SafetyNet полностью будет отключена, старые верификации капчи более не будут работать

Improving unit test performance

Прикладные советы по ускорению запуска юнит-тестов. Основная идея заключается в отключении ненужных gradle task как локально, так и на CI

👉 Если вы используете Crashlytics, выключите injectCrashlyticsBuildIds для тестов
👉 Проверьте и удалите ненужные зависимости, использующие kapt
👉 Если вы пишете тесты аккуратно и используете моки вместо DI, то вам не нужен Dagger-Hilt для unit тестов и, следовательно, kapt и kaptTest для их конфигурации
👉 Если успешно отключили Dagger-Hilt, то и плагин не нужен. Убираем dagger.hilt.android.plugin
👉 Принудительно отключаем все kapt задачи после удаления всех его конфигураций kaptTest для unit тестов

Обновление приложения до targetSdk 34

Обязательное обновление targetSdkVersion ожидается, предположительно, в августе этого года. Добавляем задачку в беклог ближайшего спринта и не переживаем о предупреждениях из Google Play

👉 Если вы используете foreground сервисы, то для них появился foregroundServiceType, который нужно будет определить в манифесте
👉 Обновление Android привело к обновлению OpenJDK до 17. А это значит что могло сломаться: регулярные выражения, ProGuard и десериализация UUID.
👉 При использования BluetoothAdapter.getProfileConnectionState требуется BLUETOOTH_CONNECT (Должен быть и в манифесте и запрашиваться в рантайме)
👉 Ограничения для Intent. Тщательно проверьте, как используется android:exported в ваших приложениях. Неявный Intent может быть отправлен только к android:exported="true”
👉 У BroadcastReceiver новый параметр - ContextCompat.RECEIVER_EXPORTED. Добавляем его в зависимости от того, как вы с ним работаете
👉 Динамически подгружаемый код должен быть помечен как readOnly перед использованием
👉 Ограничения на работу с ZipFile. Теперь будет кидаться ошибка, если в имени есть модификаторы пути до файла ".." или "/".
👉 Расширение ограничений при запуске приложений в фоне. Добавляем еще один параметр в PendingIntent.

В целом, ассистент миграции поможет вам перевести приложение на новое SDK, но лучше самостоятельно проверить, что все упомянутые моменты были переведены верно, иначе рискуете получить неверное поведение приложения или просто краш

Разбираем, что нас ждет в Android 15

🤜 Продолжение работы над приватностью пользователей. Privacy Sandbox призывает помочь найти баланс между конфиденциальностью и персонализацией рекламы в приложениях.
🤜 Улучшение и расширение функционала Health Connect. Например новые данные о фитнесе и питании
🤜 File integrity - Обещают также защиту от потенциальных вирусов и неавторизованных модификаций приложений. Возможно будет полезно, что бы удостовериться, что вам в приложение не подложили подделанные или повреждённые файлы
🤜 Partial screen sharing - эта функция была представлена ещё в Android 14 QPR2, теперь согласие пользователя будет требоваться для каждой сессии MediaProjection
🤜 Больше контроля над камерой. Управляем мощностью вспышки на устройстве во время съемки. А так же яркостью превью для сьемки со слабым освещением
🤜 Расширение поддержки приложений для виртуальных MIDI приложений.
🤜 Android Dynamic Performance Framework (ADPF). Появятся API для работы с режимом энергоэффективности, данными о работе GPU и CPU, а также прогнозированием температуры устройства для более детального распределения нагрузки.

Android 15, как обычно, появится на устройствах Pixel раньше всего. Следить за обновлениями тут

Примерный план работ над стабилизацией Android 15

End-To-End Testing With Robot Pattern

Можно писать тесты на компоуз в лоб, а можно применить паттерн Робот!

👉 На самом деле автор адаптировал паттерн Page Object к экосистеме Jetpack Compose
👉 Для каждого экрана, для которого хотим написать тесты, пишем обёртку с вариантами использования экрана
👉 Благодаря этому повышается читаемость тестов и переиспользование кода. Не нужно по несколько раз прописывать авторизацию, например
👉 В статье также предлагают использовать baseСlass, но будьте осторожны, чтобы это не превратилось в антипаттерн
👉 Тесты выглядят аккуратно, зацените пример на гитхабе

Четвертая бета-версия Kotlin 2.0 анонсирована! Давайте рассмотрим, как это затронет Android:

🤜 Смарткасты стали еще умнее. Теперь они применяются в области действий if, when и while, при проверке типов с помощью логического оператора or (срабатывает каст к супертипу), в inline функциях, при передаче nullable функций в функцию, а также при обработке исключений

🤜 В Kotlin DSL и интеграции с Gradle улучшения. В связи с этим, возможно, потребуется добавить папку .kotlin в файл .gitignore (Можно пройти опрос и поделиться своим опытом работы с kotlin DSL)

🤜 Кроме того, стоит попробовать использовать K2 компилятор. Баги исправляются, стабильность повышается. Подробнее можно прочитать тут

Рекомендую обновиться и изучить, что нужно исправить, что работает некорректно и где возникают ошибки. Хотя это уже не альфа-версия, ваш отчет о проблемах может помочь сделать релиз более стабильным.

Чеклист на сколько удобно использовать ваше приложение

Если ваше приложение растет большей частью органически, то это важный аспект, на который Google обращает внимание при ранжировании в выдаче.

🔎 Запускаем сканер и исправляем ошибки согласно рекомендациям Google
🔎 Проверяем, что у всех изображений есть contentDescription, а лучше помечаем так все важные view в приложении
⌨ Вашим приложением должно быть удобно пользоваться с внешней клавиатуры!
⌨ Тестируем Switch Access
🔊 Тестируем голосовое управление устройством. Google предоставляет приложение для управления всем девайсом, ваше приложение должно это поддерживать
🔎 Проверяем, что фокус в приложении ведет себя предсказуемо!
🔎 Проверяем как приложение работает с жестами, не конфликтуют ли системно заданные жесты с вашими кастомными свайпами
🔎 Проверяем поддержку функции цветовой слепоты. Ваше приложение может выглядеть совершенно иначе в этом режиме, а пользователь которому это необходимо включит ее, готово ваше приложение к этому или нет!
🔎 Поддержка изменения размера шрифта и увеличения интерфейса

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

Performance In Jetpack Compose — Stability & Immutability

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

👉 Включаем отображение количества рекомпозиций в Layout Inspector и находим проблемное место
👉 Разбираемся, является ли проблемная функция restartable или skippable compose функцией, собрав приложение с параметром -PcomposeCompilerReports.
👉 В репорте (app_release-composables.txt) находим проблемную функцию.
👉 Автор обнаружил, что передаваемые параметры помечены как unstable, что означает, что рекомпозиция будет происходить каждый раз, даже если параметры не поменялись. Для более глубокого анализа обращаемся к репорту (app_release-classes.txt)
👉 Проблема, как это часто бывает, заключается в реализации коллекций, которые помечаются как unstable. Компилятор Compose не может быть уверен в иммутабельности этих классов и маркирует их как unstable
👉 Мы можем исправить это, добавив аннотацию @Immutable или @Stable к параметру, чтобы показать Compose компилятору, что мы уверены в иммутабельности этих реализаций

Кстати, в версии 1.6 Compose появится strong skipping mode, который может снизить количество таких проблем

Разбираем как может повлиять на вашу работу релиз стабильной Android Studio Iguana

👉 Обновление AGP до стабильной версии 8.3.0. Мы в команде уже обновили и это дало небольшой буст по скорости сборки. Рекомендую запланировать в ближайший спринт
👉 Gradle Version Catalogs стал стабильным. Я рассказывал об этом у себя в LinkedIn, как мы в прошлой компании перешли на него ради более удобного автоматического обновления зависимостей. Скорость сборки незначительно уменьшилась за счет избавления от buildSrc, но удобство и скорость обновления зависимостей выросли в разы
👉 Обновили платформу IDE до 2023.2. А что это значит? Интеграция с GitLab для ревью кода, множество визуальных изменений, так что готовьтесь к тому что привычные для вас элементы управления могли исчезнуть
👉 UI Check mode. Можно быстро проверить, как ваша вьюха выглядит на большом количестве устройств. Открываем класс с @Preview и запускаем. Возможно, будет полезно для Manual QA пройтись по всем экранам таким образом и сэкономить время на проверке дизайна для разных экранов
👉 Вы могли заметить , что на полях появится небольшая звездочка. Если ваш проект связан с Firebase, то это маркер о том, что здесь произошло падение приложения на последней версии. Очень удобно исправлять сопутствующие краши. Так же App Quality Insights интегрировали с VCS, так что проще искать коммит где был написан код ломающий приложение

А какую версию вы используете на своих проектах и почему?

Ins and Outs of Kotlin Variance

Недавно обсуждали целесообразность теоретических вопросов на собеседованиях. На практике, ни одно собеседование на позиции mid+ не обошлось без вопросов о Contravariant, Covariant и Invariant. В статье разбираем более подробно, как все это устроено на примерах, чтобы не запутаться.

А вы спрашиваете об этом на собеседованиях?

Помните, как лет 5 назад взлетел архитектурный фреймворк Moxy? Многие команды внедрили его себе, а некоторые используют до сих пор. Похоже, что аналогичным обещает быть Circuit для Jetpack Compose!
Стабильная структура, которая помогает соблюдать архитектурные принципы проекта и бить по рукам разработчиков, которые отклоняются от выбранной архитектуры.

👉 В основе лежат принципы Presenter и UDF
👉 Circuit состоит из трех компонентов: Presenter, связанный с ViewModel и содержащий бизнес-логику, UI для соответствующего слоя и Screen, обеспечивающий связь между ними и создающий пару UI/Presenter
👉 Следует учитывать, что Jetpack Compose развивается очень быстро, и зависимость от данной библиотеки означает сильную зависимость от того, как быстро Slack будет развивать ее
👉 Также имеется собственная навигация, которую вы получаете вместе с этой зависимостью

На прошлой неделе мы обсуждали, как снизить количество рекомпозиций в приложении. Грамотный подход к архитектуре часто оказывает наибольшее влияние на скорость работы вашего приложения.
Если хотите попробовать или узнать больше: https://github.com/slackhq/circuit

Большинство контента сейчас про Jetpack Compose и KMP, однако, по моему опыту, компании не очень спешно переходят на новый Compose. А как дела обстоят у вас?