R8 full mode

Не так давно обновил проект до Gradle 8 и получил краш в релизной сборке⚪️. Все из-за включенного по умолчанию R8 full mode. Прежде чем разберемся, что поменялось, давайте для начала вспомним, кто такой этот ваш R8.

☢️ R8 — это утилита для удаления лишнего кода, его минификации и оптимизации

Как работает
⚙️ Строит граф от рутов, помеченных -keep в правилах proguard, и удаляет все до чего не смог дотянуться

Причем тут proguard
⚙️ Ранее в Android использовался аналог R8 под названием ProGuard, правила остались для совместимости

Когда запускается
⚙️ Во время сборки с включенным флагом isMinifyEnabled

Где может стрельнуть
⚙️ При использовании рефлексии или JNI

Что за full mode
⚙️ Включает более агрессивный режим и вырезает еще больше кода. Например, классы, создаваемые только через рефлексию, должны явно помечаться через -keep правило. Также R8 удаляет сигнатуру дженериков, что стрельнуло у меня в связке Retrofit + RxJava2

❗️Вообще хорошей практикой считается то, когда либа уже содержит необходимые правила для R8 и вам не нужно об этом задумываться, но так бывает не всегда. Например, GSON только с последней версии стал включать правила по-умолчанию, но и это работает не для всех кейсов.

📌 Подробнее почитать про R8 full mode и известные проблемы можно тут, но эти правила мне не помогли, поэтому в комментах напишу, что помогло.
Также если хотите глубже погрузиться в правила ProGuard, то рекомендую официальный мануал и андроидовскую доку.

Столкнулись ли вы с подобной проблемой на своем проекте❓

#Android #R8 #ProGuard

Этим летом проводили MobileUpdate в Екатеринбуржском офисе Контура☁️, где было 5 крутых докладов по мобильной разработке. А теперь все записи докладов стали доступны на YouTube🟥

🤖 Влада Шамшукаева рассказала как работать с графикой в Compose, а также о том как одну и ту же задачу можно решать совершенно разными способами

🍏 Алексей Агапов набросил, что классы и паттерны проектирования вам больше не нужны, достаточно лишь функции и знания о Functional Core / Imperative Shell.

🤖 Игорь Гордеев поведал о том как уменьшать шаблонный код с помощью KSP на примере библиотеки VisualFSM

🍏 Анастасия Чупова поделилась довольно забавной историей о фейлах при работе с диплинками в SwiftUI

🤖 И наконец Евгений Мельцайкин рассказал про плагины в Gradle, как с помощью них сократить код в ваших gradle файлах и как при этом не выстрелить себе в ногу.

Я выступал в роли программного комитета и помогал ребятам с прогонами. Все докладчики постарались на славу и определенно заслуживают ваш лайк👍

P.S. Уровень монтажа и картинки просто мое почтение

#Video #iOS #Android

Code coverage для UI тестов

⚙️ Тема анализа покрытия кода Unit тестами уже не нова, для Java уже давным-давно существует библиотека JaCoCo, для Kotlin есть официальный Gradle Plugin Kover. Оба этих инструмента позволяют анализировать ваш код и генерировать различные отчеты о его покрытии Unit тестами. Это безусловно полезные инструменты для улучшения качества вашего кода и уверенности в нем.

⚙️ Но как обстоят дела с UI тестами? Можем ли мы с помощью них проанализировать процент покрытия тестами нашей бизнес логики?

⚙️На этот вопрос ответил мой коллега из Контура, Игорь Гордеев, в своей статье на Хабре. Он рассказал, как с помощью библиотеки VisualFSM, конечных автоматов и щепотки кодогенерации сделать такое покрытие и упростить жизнь и тестировщикам, и разработчикам в тысячу раз!

Приятного чтения 🤯

#Android #Testing

Скриншот-тестирование

Практика скриншот-тестирования в Android началась еще более 10 лет назад и актуальна по сей день, за это время появилось огромное количество разных библиотек (Paparazzi, Shot, Testify и другие), но у всех библиотек есть существенный недостаток — поддержка. Всегда есть риски, что библиотеку перестанут поддерживать или будут обновлять зависимости несвоевременно.

И ребята из Тинькофф для тестирования дизайн-системы пошли другим путем, не используя сторонние библиотеки, так как все, что нужно для скриншот-тестирования уже есть в Android! (на самом деле нет)

Достаточно взять эталонный и текущий скриншот, сконвертировать все в Bitmap и попарно сравнить пиксели:

val referenceBitmap = BitmapFactory.decodeFile("assets/1.jpg")
val actualBitmap = onView(withId(R.id.mainContent)).captureToBitmap()
val isSameImage = compareBitmaps(referenceBitmap, actualBitmap)
assertTrue(isSameImage)

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

И вот список рекомендаций из их доклада про что нужно помнить:
▫️Подготовьте storybook и используете эти же состояния компонентов для тестирования
▫️Сделайте удобный тулинг для обновления эталонных скриншотов и просмотра диффа скриншотов
▫️Используйте CI как единый источник правды для создания эталонных скриншотов, так как на разных процессорах графика может отличаться
▫️Избавляйтесь от запуска тестов на эмуляторе, в этом может Robolectric с режимом @GraphicsMode(NATIVE)
▫️Подумайте о генерации тестов через KSP

Но, что если ваш проект полностью написан на Jetpack Compose? Неужели нет других вариантов скриншот-тестирования? Об этом расскажу в следующем посте, так что stay tuned!

#Testing #SnapshotTesting #Android

Бессмертное приложение

Продолжим разбирать доклады с предыдущего Mobius. И сегодня поговорим о том, как пережить force stop и запустить приложение после его установки из стора без действий пользователя.

Мы знаем, что если пользователь принудительно остановит в настройках приложение, то без повторного его открытия все фоновые операции будут недоступны, в том числе и пуши. Но эту проблему можно частично решить, для этого нам понадобится ContactsProvider и Account Synchronization.

1. Регистрируем в манифесте provider с метадатой ContactDirectory. Тогда при открытии приложения "Контакты" ContactsProvider опросит всех, у кого есть эта метадата, соответственно поднимется наш провайдер и вызовется метод onCreate у Application даже без первичного запуска приложения.

<meta-data
    android:name="android.content.ContactDirectory"
    android:value="true" />

2. Далее мы можем зарегистрировать свой SyncAdaper для синхронизации аккаунтов, он может не иметь никакой логики, главное включить автоматический и периодичный синк. Тогда система сможет при синхронизации аккаунтов сама пробудить процесс даже после force stop!

Но согласитесь, это же не бессмертие, а больше похоже на некромантию? Убиваем и воскрешаем процесс через какое-то время 💀

Однако есть способ по-настоящему пережить force stop, правда работает он не гарантировано и ни в каких продакшн приложениях лучше его не использовать ⚠️

Суть в том, что у системы есть 40 попыток, чтобы убить процесс с периодичностью 5мс, и если мы будем за это время создавать новые процессы, то система в теории просто сдастся. То есть процессы будут поднимать друг друга пока не пройдет достаточно времени, чтобы система оставила их в покое. Посмотреть на это безумие можно в репозитории.

Всем разработчикам долгоживущих приложений, а пользователям соболезнования по поводу батарейки в их смартфонах 🫡

#Android #UnderTheHood

Custom Quick Settings tiles

Забавно, что являясь Android разработчиком, мне очень редко приходится решать задачи, связанные с самой платформой и ее фичами, и, думаю, я такой не один. Но недавно появилась потребность добавить свою кастомную плитку для приложения в шторку с быстрыми настройками.

Каждая такая плитка представляет из себя специальный сервис под названием TileService. Это особый вид bound сервиса, который имеет свои особенности жизненного цикла и все нюансы подробно описаны в гайде.

Проблема только в том, что нашел я этот гайд уже после того как сам разобрался, что к чему, ведь по запросу TileService отдавало все что угодно: скудную документацию, статьи подозрительного качества, но только не гайд 😒

Главное, что нужно знать, что обновлять плитку можно только в промежутке между onStartListening() и onStopListening() и по умолчанию этот промежуток соответствует поведению, когда плитка видна на экране у пользователя, что выглядит довольно логично и похоже на то, как мы подписываемся на стейт в UI, но Google почему-то рекомендует явно запрашивать listening state 🤔. Как по мне, первый способ является более удобным, но разумеется все зависит от конкретного кейса.

⚠️Однако я столкнулся с одной проблемой, само по себе взаимодействие с TileService не переводит ваше приложение в состояние foreground и вы можете столкнуться с различными ограничениями системы. В моем случае помог запуск отдельного foreground сервиса из TileService.

💬А используете ли вы данную функциональность в своих приложениях? Если да, то какие сценарии вы туда выносите?

#Android
@kotlin_adept

Топ 4 незаметных бага при смене стека

Помните я похвастался, что переписал проект с RX на корутины без багов? Так вот я соврал 😼

Ну или не совсем, так как баги не связаны напрямую с асинхронщиной, поэтому давайте посмотрим на топ незаметных багов при смене стека технологий.

1️⃣ Переходя с Rx на корутины у вас может сломаться Retrofit, при этом только для специфичных кейсов, когда в ответе приходит код 204, Retrofit начинает воспринимать успешный ответ как ошибку из-за отсутствия Body.

2️⃣ Переходя с Retrofit на Ktor проверьте все экстеншены для определения сетевых ошибок, зависимость на OkHttp у вас останется, но работать экстеншены перестанут так как исключение уже будет не HttpException, а ResponseException.

3️⃣ А также проверьте места, где возвращается Response, а не Body, в Retrofit это всегда успешная операция вне зависимости от ответа, в Ktor же это будет ошибкой, если выставлен флаг expectSuccess.

4️⃣ При переходе с GSON на KotlinxSerialization убедитесь, что все опциональные поля моделей помечены nullable и имеют дефолтное значение, так как GSON мог засунуть null даже в non-nullable поле и все могло работать, если к этому полю не обращаться.

💭 А какие незаметные баги просачивались у вас при рефакторинге стека технологий?

#Android #Kotlin
@kotlin_adept

Из раза в раз Android-разработчики страдают при обновлении зависимостей в поиске совместимых версий, и мы не стали исключением. Недавно нам понадобилось обновить версию библиотеки Coil для устранения проблем с бинарной совместимостью. Однако новая версия библиотеки подтянула за собой Kotlin 2.1.0, из-за чего наш Android Gradle Plugin начал выдавать множество предупреждений, связанных с R8, и предлагал заглянуть в таблицу совместимых версий. Стоит ли говорить, что в этой таблице новой версии Kotlin не оказалось 🫥

Ну что ж, обновляем AGP до последней версии в надежде, что всё заработает. Действительно, предупреждения исчезли, но минификация перестала работать 😬

Что же произошло
В версии AGP 8.4.2 изменили механизм работы R8.

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

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

Как исправить
Правильным решением будет оставить флаг isMinifyEnabled только в application модуле. Поскольку он зависит от всех остальных модулей в приложении, минификация будет выполняться только после сборки всех модулей. Это обеспечит корректную работу минификации как для app-модуля, так и для остальных модулей.

Таким образом, оставив минификацию только для app-модуля, мы не только исправили проблему, но и ускорили сборку релизной версии, так как теперь минификация запускается только один раз.

#Android #Gradle #R8

Мы с вами говорили про отличия между платформами, но что говорить о мультиплатформе, если даже на разных Android-устройствах могут быть отличия в поведении, и явным рекордсменом по количеству особенностей являются устройства Xiaomi 🧡

Сегодня поговорим про регулярные выражения и букву ё. Кто ее только не отменял, но Xiaomi пошли дальше всех.

К нам прилетел баг, что при введении ФИО буква ё не проходит валидацию по регулярному выражению. Первое, что приходит в голову, это, что мы написали кривой regex, ведь на самом деле, если использовать такое регулярное выражение ^[а-яА-Я]*$ то буква ё не попадает в этот диапазон и нужно определять ее отдельно, но нет, дело было не в этом.

Дальше мы подумали, а что если клавиатура на Xiaomi использует какой-то другой символ ё и мы оказались правы. Действительно стандартная клавиатура использовала \u00eb символ юникода вместо \u0451

Все дело в клавиатуре, которая выбрана по умолчанию, если поменять клавиатуру на Gboard, то все будет окей. Так что перед проверкой данных нам пришлось делать замену данного символа, чтобы пройти валидацию и на бекенде 👍

Давайте порадуемся за Семëна с Xiaomi, теперь у него все будет хорошо 🫡

#Android #Regex #Xiaomi

Фоновая работа в Android и iOS

Бытует мнение, что iOS вообще не позволяет приложению выполнять какие-либо действия в фоне, но это не совсем так. В одном из наших Compose Multiplatform приложений необходимо было реализовать синхронизацию данных в фоне, и моему коллеге пришлось глубже разобраться в теме.

➖ На текущий момент не существует хорошего решения для KMP-проектов, которое предоставляло бы общий API для работы с фоновыми задачами. Это вполне объяснимо: API сильно отличаются между платформами.

🤖 Для решения задачи синхронизации данных в фоне в Android существует несколько решений, например, WorkManager, который имеет довольно удобный API и позволяет запускать задачи с интервалом не менее 15 минут. Он позволяет задать условия запуска задачи, порядок выполнения воркеров и определить поведение при повторном планировании одной и той же задачи.

🍏 В iOS есть два стула: BGAppRefreshTaskRequest и BGProcessingTaskRequest.

Первый предназначен для относительно быстрых операций длительностью до 30 секунд и может выполняться чаще, второй — для более долгих задач, которые могут выполняться в течение нескольких минут и даже часов. Разумеется, можно указать минимальное время, через которое должна быть выполнена синхронизация. В интернетах рекомендуют устанавливать интервал в один час, однако iOS конечно же не гарантирует, что задача будет выполнена вообще 🙃

С появлением SwiftUI стало удобнее работать с фоновыми задачами — достаточно запланировать их с помощью BGTaskScheduler и обрабатывать через модификатор backgroundTask. Однако, по сравнению с WorkManager, многое приходится делать вручную — например, явно обрабатывать ситуацию, когда задача уже запланирована, иначе интервал её запуска может быть сброшен.

📌 Таким образом, реализовать фоновую работу в мультиплатформенных проектах вполне возможно, но для этого потребуется написать платформенный код.

#iOS #Android #Background #KMP