Android Lint vs Detekt

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

Android Lint
🟢Может анализировать не только Java/Kotlin код, но и XML, Gradle и TOML файлы
🟢Благодаря UAST можно писать универсальные правила для анализа Kotlin и Java кода
🟢Сразу же подсвечивает проблемы в IDE без необходимости запускать отдельную Gradle-таску
🟢Позволяет предоставлять исправления для проблемных участков кода
🟢Можно работать с Kotlin Analysis API для углубленного статического анализа
🔘Однако Android Lint работает только в Android-модулях
🔘Синтаксис написания правил, на мой взгляд, сложнее, чем в Detekt

Detekt
🟢Позволяет писать правила для KMP проектов
🟢Community-driven подход, есть множество open-source правил
🟢Работает с разными системами сборки
🟢Есть возможность использовать type resolution для анализа типов данных
🟢Работает с PSI, так же как и в IDE-плагинах
🔘Поддерживает только анализ Kotlin
🔘Без type resolution нельзя получить полное имя класса, в отличие от Android Lint
🔘Type resolution находится в experimental статусе, и мало кто использует эти проверки в проектах

📌 Таким образом, оба инструмента для статического анализа имеют свои сильные и слабые стороны, и не стоит сбрасывать Android Lint со счетов — возможно, он подойдет вам больше в некоторых случаях, чем Detekt.

#Detekt #AndroidLint #StaticAnalysis

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

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

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

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

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

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

#Android #Regex #Xiaomi

Расскажу еще об одном интересном кейсе, который выстрелил у нас при работе с KMP. И здесь удар в спину пришел откуда не ждали — убийцей оказался SQLite 🔫

Мы используем библиотеку SQLDelight для работы с БД на Android и iOS, и в одном из приложений был реализован обычный поиск через оператор LIKE. По спецификации этот оператор является регистронезависимым для ASCII-символов, но не для символов Юникода. Например, символ æ не будет равен Æ.

Так вот, на Android все работает отлично — можно искать слова в разном регистре как на латинице, так и на кириллице. А на iOS для кириллицы регистр должен точно совпадать. При этом на iOS аналогично не работают для кириллицы другие SQL-фичи, вроде COLLATE NOCASE или функции LOWER. На этот счет в SQLDelight есть соответствующий issue.

Поэтому нам пришлось явно сохранять в БД информацию в нижнем регистре и приводить строку поиска к нижнему регистру, чтобы поиск работал корректно на обеих платформах.

Так что, если соберетесь делать локальный поиск в БД, помните об этом нюансе и не наступайте на наши грабли ❤️

#KMP #SQL #iOS

Розыгрыш билета на Podlodka Android Crew

Мы с командой в очередной раз подготовили для вас новый сезон конференции Podlodka Android Crew. В этот раз будем обсуждать Compose и разберём, что с ним произошло за три года в продакшене.

В программе будет много всего интересного:

⚙️ Доклад про опыт перехода на Compose Multiplatform
😤 Дебаты за звание лучшей навигации для Compose
😔 Собеседование по Compose с одним из участников конференции
❓ Интересный квиз в формате «Своей игры»
🚀 И много всего другого

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

Но если вы не верите в силу рандома, то можете купить билет самостоятельно со скидкой 500 руб. по промокоду adept13

Bottom Sheet починили! ⚪️

У нас в проектах уже давно нет зависимости от Material, так как используется своя дизайн-система. Это круто, но несёт одну главную проблему: ты перестаёшь следить за обновлениями в Material и исправлениями различных багов. До вчерашнего дня я был уверен, что Bottom Sheet в Material 3 всё ещё отвратительно работает и никакие проблемы там не исправили. Но оказалось, что это не так — все старые болячки там пофиксили 🤩

На видео можно заметить существенную разницу между старой и новой версией Bottom Sheet в Material 3.

P.S. Так что, видимо, надо начинать отдельный квест по копированию исходного кода этого компонента в нашу дизайн-систему 🙃

Пока мы далеко не отошли от темы Bottom Sheet, хочу снова немного побомбить на то, какой API нам предоставили разработчики этого компонента в Material 3.

Я уже как-то поднимал тему декларативного Bottom Sheet, когда решение о том, показывать его или нет, определяется исключительно состоянием. То есть мы показываем шторку, если ассоциированный с ней стейт ≠ null, иначе скрываем.

И казалось бы, в Material 3 сделали именно так: достаточно просто установить значение false в переменной showBottomSheet, чтобы скрыть его. Но тогда это произойдет без анимации сворачивания компонента⚠️

Чтобы это исправить, придется явно вызывать suspend-функцию hide, но делать это каждый раз, мягко говоря, неудобно. Можно попробовать написать свою декларативную обертку, но придется решить несколько проблем:

🔘Как сохранять контент при анимации скрытия, если стейта уже нет?
🔘Как запретить перехватывать Bottom Sheet жестом, пока он сворачивается?

И вторая проблема самая неприятная, так как в Bottom Sheet нельзя отключить обработку жестов, пока он скрывается. Но нам обязательно нужно скрыть его, если ассоциированный стейт уже null, иначе получим неконсистентное состояние.

Как ни странно, в SwiftUI таких проблем нет — декларативная обертка пишется буквально в несколько строчек, что можно увидеть на изображении.

Обертку для Bottom Sheet из Material 3, которая отлично подходит для Slot навигации в Decompose, я уже реализовал и чуть позже поделюсь ею с вами, когда обновлю свой пример KMP-проекта.

#Compose #SwiftUI #BottomSheet

Обновил свой пример KMP-проекта SpaceXRockets, где показал как подружить Bottom Sheet из Material 3 с Decompose.

Это небольшой, но показательный пример, где можно увидеть:
🌳 Навигацию на Decompose для SwiftUI и Jetpack Compose
🎨 Интеграцию Compose Multiplatform в SwiftUI
⚙️ Работу с moko-resources
🐘 Реализацию многомодульности с изолированным DI в каждом модуле с помощью Koin

Звездочки на репозиторий приветствуются ⭐

Один из подписчиков канала, Алексей Илларионов, написал отличную статью про новый BundledSQLiteDriver из библиотеки androidx.sqlite.

В статье вы найдете:
🔘Преимущества и недостатки своей сборки SQLite
🔘Новые фичи BundledSQLiteDriver
🔘Ограничения, про часть из которых я писал ранее
🔘Замеры производительности

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

В этот раз посетил Mobius 😀 не в качестве спикера, хотя планировал сделать доклад о нашем опыте использования Compose Multiplatform в проде, но не случилось по личным обстоятельствам...

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

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

Буду сейчас принимать участие в стриме от Яндекса на Mobius, будем фиксить баги в прямом эфире.

Подключайтесь ✅

Как ускорить релизную сборку

Из всех докладов на Mobius, которые мне удалось посмотреть, могу выделить классный доклад о том, как в Т-Банке случайно ускорили релизную сборку в два раза.

Я думаю, у многих в проектах работа R8 занимает больше всего времени из всего процесса сборки, а в крупных проектах выполнение этой таски может доходить до 3 часов 🙀 — и это требует огромного количества оперативной памяти.

Так что же может значительно увеличивать длительность выполнения этой таски?

1. Неоптимальные правила
Обычно это правила с условием, например, такие встречаются в библиотеке kotlinx-serialization. На них тратится больше всего времени, нужно быть аккуратнее с такими правилами и не дублировать их в своём коде, так как правила для R8 уже поставляются вместе с библиотеками.

2. Огромное количество ресурсов
Таска shrinkResources может потреблять очень много оперативной памяти, и если в вашей дизайн-системе вы предоставляете большую библиотеку иконок, то, возможно, стоит пересмотреть подход и не тащить тысячи иконок, чтобы потом R8 не удалял их очень долго. Как вариант, можно рассмотреть загрузку иконок с CDN по запросу.

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

#R8 #Gradle

На сегодняший день есть множество либ для сканирования QR-кодов, но к сожалению, далеко не все из них справляются с разными видами Data Matrix.

Ранее мы использовали Google ML Kit, но он очень плох при сканировании Data Matrix, а из других бесплатных аналогов остается только ZXing или его адаптированная под Android версия, обе из которых уже давно не развиваются.

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

Обычно SwiftUI и Compose очень похожи между собой, и, как правило, стейт для экранов можно формировать одинаково — это очень удобно при работе с KMP.

Но иногда бывают сильные отличия в API, например, PullToRefresh: если в Compose индикатор показывается по изменению состояния, то в SwiftUI — это асинхронная таска 🤬

Недавно мы наткнулись на ещё один такой компонент — контекстное меню. На слайде видно, насколько более громоздко выглядит код на Compose, но не все так однозначно. Здесь разница в том, что, опять же, если в Compose меню показывается в зависимости от состояния, то в SwiftUI мы сразу должны знать, какие элементы отображать в этом меню, и нельзя сделать это по клику. Это неудобно, если элементы контекстного меню формируются динамически.

Чтобы исправить это, придётся в стейте сразу хранить словарь и в зависимости от типа ячейки, на которую кликнули, выбирать нужный набор значений.

💬 А какие ошибки допускали вы при формировании стейта экрана?

#Compose #SwiftUI

Маст-хэв кастомные Gradle-плагины

Если вы разрабатываете несколько приложений, то наверняка уже шарите какой-то общий код, вынося его в отдельные библиотеки или модули. Но не только общие модули могут быть полезны — можно ещё переиспользовать утилитарный код с помощью Gradle-плагинов.

Знаю, что многие, мягко говоря, не любят Gradle — и на то есть причины. Однако написание собственного небольшого плагина проще, чем кажется, особенно если делать это неправильно (привет afterEvaluate 🙃).

Вот несколько идей для плагинов, которые могут быть полезны:

1️⃣ Version Catalog — очень простой плагин, который помогает удобно переиспользовать версии зависимостей между проектами. Про него я уже как-то писал здесь.
2️⃣ Code Style — обёртка над Detekt с настроенными дефолтными и кастомными правилами.
3️⃣ Git Hook — запуск тестов и проверки кода при коммите, проверка сообщения коммита и прочее.
4️⃣ Vault — плагин для получения секретов из защищённого хранилища при первоначальной настройке проекта.
5️⃣ Publish — плагин для упрощения публикации собственных плагинов, каталога версий, Android и KMP-библиотек.

🔥 Если тема интересна — ставьте реакции, и я расскажу подробнее, как создавать такие плагины и дам рекомендации как не стоит делать.

#Gradle

🎨 Наверное, только ленивый не написал о том, что Compose Multiplatform для iOS стал Stable. Но что это значит? Действительно ли все болячки пофиксили, и можно с лёгкостью портировать любое Android-приложение на iOS?

Действительно, стало гораздо проще адаптировать какой-нибудь простой Jetpack Compose-пример на iOS, буквально перенося файлы из одной папки в другую, но с реальными приложениями всё не так гладко. И вот какие проблемы я вижу на текущий момент:

🔘Мало библиотек, которые полностью избавляют от написания платформенного кода

Во Flutter, например, есть огромное количество библиотек на любой вкус и цвет, которые покрывают все платформенные API в общем коде: работу с разрешениями, камерой, геолокацией и другими. В CMP же в большинстве случаев придётся реализовывать это нативно, что требует хотя бы минимальных знаний платформы и языка.

🔘Отсутствуют адаптивные виджеты для платформ

Сейчас «из коробки» доступны только Material-виджеты, и, несмотря на то что у многих приложений своя дизайн-система, всё равно хотелось бы адаптировать часть виджетов под платформу. Например, Android-овский PullToRefresh выглядит максимально инородно на iOS и в целом плохо дружит с физикой скролла на iOS.

🔘Производительность

В анонсе сказано, что производительность CMP сравнима со SwiftUI и, судя по графикам, даже превосходит его. Но это всего лишь один бенчмарк ленивого списка. Если вы начнёте сравнивать приложение на SwiftUI и CMP на каком-нибудь iPhone 13, то невооружённым глазом увидите разницу не в пользу Compose. Очевидно, что проблема кроется в Skia, от которой Flutter и отказался из-за проблем с производительностью. Будем надеяться, что в будущем команда CMP тоже предпримет какие-то шаги в этом направлении.

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

#ComposeMultiplatform #CMP

Каждый раз, когда приходится обновлять версии Kotlin и Compose, я чувствую себя как тот мужик из мема. 

Обновить зависимости так, чтобы ничего не отвалилось, та ещё задача, а в KMP-проектах добавляется ещё больше веселья.

Например, хотим запустить проект на Xcode 16.3 — для этого нужен Kotlin 2.1.21, а для него требуется новый KSP, в котором сломали обратную совместимость. И какая-нибудь либа в проекте, использующая KSP, благополучно перестаёт работать. 

К счастью, отключить вторую версию KSP можно в gradle.properties, и это спасёт на какое-то время:

ksp.useKSP2=false

Хуже этого только борьба с Java-версиями. Когда в каком-нибудь кастомном detekt-правиле забыли указать jvmToolchain с нужной версией, приключение на весь день точно будет обеспечено 👍

#Gradle #KSP

UI-тестирование в Compose 🎨

Если вы хотите реализовать UI-тесты в Compose, то на сегодняшний день есть три основных решения: официальная библиотека от Google и обёртки над ней — Kakao/Kaspresso и Ultron. Про официальное решение сегодня говорить не будем, а рассмотрим поближе другие библиотеки.

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

🟡Ultron выглядит довольно заманчиво: у него есть два ключевых преимущества перед конкурентами — при написании тестов на Ultron практически отсутствует какой-либо бойлерплейт-код, а также Ultron поддерживает Compose Multiplatform. Ещё из плюсов можно выделить качественную документацию. Из недостатков я бы отметил довольно небольшое комьюнити у библиотеки, а также, лично для меня, оказалось непривычным отсутствие связей parent-child между PageObject. Подробнее узнать про Ultron можно в недавно опубликованном докладе от автора библиотеки — Алексея Тюрина.

🔘Kakao/Kaspresso — проверенные временем библиотеки с большим комьюнити, но описание PageObject в Kakao до версии 1.0 требовало довольно много бойлерплейт-кода, особенно при работе с Lazy-списками. Также механизм flaky safety в Kaspresso не совсем хорошо работает с виртуальным временем в Compose-тестах. Об этом подробно рассказал Паша Стрельченко в своём докладе.

💬 А что используете вы для UI-тестирования в Compose? И оправдан ли тренд на уход от дорогих UI-тестов в проекте?

#Compose #UiTesting