Android Live 🤖

Media Performance Class Level
#google

Google опубликовали статью о своём опыте использования Media Performance Class (MPC) в контексте работы Google Maps.

Недавно вышел стабильный релиз Jetpack Core Performance library, который позволяет получить актуальный MPC для текущего устройства.
Под капотом — класс PlayServicesDevicePerformance, который запрашивает Google Play Services о текущем уровне MPC. По сути, всё довольно просто.

В статье описан кейс Google Maps, где разработчики начали использовать полупрозрачные окна только на высокопроизводительных устройствах, чтобы обеспечить лучший UX для разных категорий пользователей. Вероятно, у вас тоже есть подобные высокотребовательные фичи?

Не уверен, что у этого подхода нет альтернатив, особенно учитывая обязательное наличие Play Services для работы. Что думаете? 🤔

ViewModel под капотом
#viewmodel #code

Полезная статья, объясняющая, как устроен всем известный ViewModel под капотом.

После изучения вы сможете легко написать собственный аналог ViewModel (но лучше не использовать его в боевых проектах) или разобраться, как внутренние компоненты связаны со скоупом, что такое AutoCloseable и CloseableCoroutineScope.

Люблю подобные статьи про внутренние части всем известных компонентов.

Legacy Shmegacy
#code

Legacy — популярное слово, которое часто ассоциируется с «плохим» кодом. В проектах часто есть участки кода, куда не хочется заглядывать или править баги, но до переписывания руки так и не доходят. Но задумывались ли вы, как появляется legacy? Ведь в большинстве команд опытные и умные инженеры, которые хотят, чтобы их проект был только лучше.

Автор статьи смотрит на legacy не как на код, а как на наше отношение к этому коду.

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

В статье рассказывается, как избежать появления legacy-кода в проектах и сделать жизнь команды проще. Так что — не плодите legacy, а потихоньку избавляйтесь от него, делая код чище и проще. 🥰

Optimised Out в Kotlin Coroutines
#kotlin #coroutines

Иногда при отладке coroutines можно увидеть сообщение «optimised out», из-за которого debugging усложняется.

Это связано с особенностями работы Kotlin coroutines и их преобразования в state machine. В таких случаях переменные, которые больше не нужны после точки остановки, очищаются, и становятся невидимыми для отладки. Кроме того, при использовании inline также выполняются оптимизации, скрывающие ненужные переменные.

Однако существует простая настройка, которая позволяет увидеть эти переменные и значительно упростить debugging. 🥳

Друзья, поздравляю вас с наступающим Новым годом! 🎅

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

Себе желаю исправиться и писать здесь регулярно. А вам желаю, чтобы все ваши желания исполнились, а новый год принёс как можно больше позитивных моментов! 🎄

GitHub Wrapped
#git

Под конец года попался клёвый сервис для анализа активности в Github.
И как раньше никому эта идея не приходила в голову?

Если вдруг не учитываются приватные репозитории — в настройках профиля надо выбрать «Include private contributions on my profile».

Делитесь в комментариях своей статой, будем мериться сравнивать коммиты.

When и Guard Conditions
#kotlin

С релизом Kotlin 2.1.0 появился апдейт для when — guard conditions. Эта новая фича улучшает читаемость кода, делая его более наглядным.
Давайте рассмотрим на примере, что она делает.

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

sealed interface HttpResult {
    data class Success(val response: String) : HttpResult
    data class Failed(val statusCode: Int) : HttpResult
}

Если включить Guard Conditions, то проверка в when специальных юзкейсов будет выглядеть так:

when (response) {
    is HttpResult.Success -> println("Success")
    is HttpResult.Failed if response.statusCode == 503 -> println("Maintenance")
    is HttpResult.Failed -> println("Failed with code ${response.statusCode}")
}

Как мы видим, одну ошибку от бэка мы обработали без добавления if внутри условия:

when (response) {
    is HttpResult.Success -> println("Success")
    is HttpResult.Failed -> {
        if (response.statusCode == 503) {
            println("Maintenance")
        } else {
            println("Failed with code ${response.statusCode}")
        }
    }
}

Похоже, что стало удобнее, но нужно попробовать на практике.
Чтобы включить фичу, надо убедиться, что K2 Compiler включен, а потом добавить опцию:

kotlin {
    compilerOptions {
        freeCompilerArgs.add("-Xwhen-guards")
    }
}

Чуть больше информации можно найти тут.

Про App Signing
#google #useful

Не все разработчики знают, что в Google Play можно изменить подпись приложения.

Это может быть полезно, если вдруг вы потеряли текущую подпись, или Google сгенерировал подпись для aab за вас — но сейчас надо делать обновление из других магазинов или APK.

Для управления подписями зайдите в Test and release -> Setup -> App signing. Нас интересует App Signing Key Certificate, который следует сравнить с текущим сертификатом. Если нужно сравнить с APK, используйте следующую команду:

apksigner verify --print-certs app.apk

Изменить подпись можно только с учётной записи владельца. Консоль предложит несколько вариантов, включая использование текущего сертификата.

При помощи утилиты perk.jar, которая, к слову, довольно глючная, надо выполнить команду, которая будет довольно детально описана после выбора пункта.
Если получите ошибку, попробуйте запустить утилиту на более старой версии JDK.

После успешного выполнения команды, надо загрузить обновлённый сертификат в консоль. И на этом всё. 🫡

Какие особенности есть?

1️⃣Подпись можно менять только раз в год, и изменения нельзя откатить. Поэтому обязательно проверьте всё несколько раз, прежде чем продолжить.

2️⃣Обновление ключа будет работать только для API версии выше 32. Для остальных версий оно будет проигнорировано, и сборки будут использовать старый ключ.

Подробнее об изменении подписи можно почитать тут.

In Memory of Stiver
#java #jetbrains

Наверняка многие из вас слышали о смерти создателя «Флибусты» — Стивера, но не все знают, что он был отличным разработчиком и внёс значительный вклад в развитие языка программирования Java.

Недавно JetBrains выпустила статью в блоге о техническом вкладе Стивера.
Если кратко, он был автором декомпилятора Fernflower. Увлёкшись внутренним устройством виртуальной машины Java, Стивер пришёл к выводу о несостоятельности существующих декомпиляторов и создал собственный инструмент.

Со временем Fernflower был включён в IntelliJ IDEA, а код стал opensource. Этот инструмент сэкономил множество часов разработчикам и значительно упростил их работу.

Вот таким талантливым человеком был Стивер. Спасибо JetBrains за то, что рассказали об этом и продолжают развивать отличный инструмент!

Coil 3.x
#kotlin #compose

Отличная новость — вышла новая версия Coil, которая теперь поддерживает Kotlin Multiplatform на Android, JVM, iOS, macOS, JavaScript и WASM! Конечно, с поддержкой Compose Multiplatform. 🔥

Изменений немало:
🔴можно выбрать библиотеку для работы с сетью: Ktor или OkHttp. Без добавления зависимости будет работать только загрузка локальных или статичных изображений.;
🔴поменялся пакет для библиотеки, теперь надо мигрировать на io.coil-kt.coil3, что, в целом, не сложно сделать;
🔴в мультиплатформе всё отлично: помимо работы с Compose, заявлена полная поддержка coil-svg, а coil-gif и coil-video обещают добавить чуть позже (пока только на Android);
🔴целый ряд небольших, но важных изменений.

Как вам обновление? Используете эту библиотеку?

Kotin: in и out, ковариантность и контрвариантность
#kotlin #новичкам

Про in и out написано много, но новички всё равно часто путаются. К тому же, опрос выше показал, что многие разработчики не до конца понимают эту тему. Между тем, знание этой темы даёт ряд преимуществ, и на собеседованиях её часто спрашивают.

Вот одна из хороших статей на эту тему. В статье на примерах рассматривается использование in и out в generic-типах, рассказывается о том, как это было в Java, и приводятся основные юзкейсы, связанные с генериками.

Если вы новичок, то рекомендую прочитать, а профи — наверняка вы и так всё это знаете. 🫡

Друзья, с Днём программиста! 💻🎉

Знаю, вы тут есть, и сегодня наш профессиональный праздник

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

Желаем вам вдохновения, новых вызовов и ещё больше успешных решений! Продолжайте менять мир!

P.S. на фото тортик от жены в честь праздника 🖤

Data Object
#kotlin

С недавних пор IDEA (а именно с Kotlin 1.9) начала подчёркивать традиционный object и рекомендует заменить его на странный data object. Что за зверь такой и что он нам даёт? Давайте разберёмся.

При использовании sealed class или sealed interface мы могли добавлять разные стейты внутри его. Они могли быть как data class, так и object. Например:

sealed interface ProfileScreenState {
    data class Success(val username: String): ProfileScreenState
    object Error: ProfileScreenState
    object Loading: ProfileScreenState
}

Однако, если мы захотели бы вывести результат в лог, то с data class все получилось бы хорошо, а вот с object — не очень: мы бы увидели только адреса, например:

com.dataobjects.example.ProfileScreenState$Loading@6d03e736
Success(username=exampleUser1)
com.dataobjects.example.ProfileScreenState$Error@5fd0d5ae

Можно было бы обмазаться старым добрым toString() для каждого объекта, но вместо этого — самое время использовать data object, где эта проблема полностью решена.

Хоть обновление и минорное, но заметно добавляет удобства при работе с подобными классами. 🔥

Maven Central Portal в 2024 году
#gradle

С марта 2024 года публикация своей библиотеки через OSSRH портал больше недоступна, и публикация на Maven Central сейчас работает иначе.

Если вам есть необходимость публикации своей библиотеки — есть свежая инструкцикя, где по шагам описываются все нюансы публикации в текущих реалиях. Вдруг понадобится.

Перенос приложения в Google Play
#google

Впервые делал перенос приложения с одного Google Dev аккаунта на другой.
Это может понадобиться по нескольким причинам, но, кажется, основная — это изменение всяких юридических данных компании.

И, как бы страшно это ни звучало — сделать перенос приложения довольно просто. Есть даже официальная дока от Google, как это сделать и которой, в принципе, достаточно.

Если кратко, то вам надо создать, оплатить и верифицировать новый аккаунт, а затем сделать request на перенос из вашего первого аккаунта.

Обязательно посмотрите, что можно перенести, а что нельзя. По сути, перенесётся вся информация, включая описание, отзывы, оценки, сервисы (Firebase тот же). В случае нашего приложения — пришлось заново добавить тестовые группы для скачивания приложения и отправить приглашения для доступа в консоль.

Так что — всё не страшно, вдруг этот пост понадобится вам когда-то в карьере. 🤟

So You Think You Know Git
#git

В начале этой недели вдохновился видео про Git и решил поделиться им с вами.

Во всех командах, где я работал использовался Git и его знание даже не обговаривалось. В большинстве случаев хватает использования базовых сценариев и команд: типа push, pull, работа с git flow и т.д.

Однако, Git очень мощный инструмент, и тут есть невероятное количество команд, которые повышают удобство работы в команде. Вот о многих подобных командах можно узнать из видео.
Кто знает, может быть парочку из них и приживутся у вас в команде. А если и не приживутся — в любом случае где-нибудь в компании разработчиков можете понтануться знанием какой-то редкой фичи из Git 🤪

О создании Preview в Jetpack Compose

Как вы подкладываете и обновляете данные для @Preview? В статье предлагается:

👉 Хардкодить данные напрямую
👉 Класть все данные в обьект и подменять в процессе подстановки. А более аккуратный способ — это воспользоваться PreviewParameterProvider (Хорошо описано тут)
👉 Написать полноценный отдельный фабричный метод для описания состояния @Preview. Мне кажется что это оверинжениринг, только если вы не всецело полагаетесь на превью в работе
👉 Использование существующего state holder

У нас в команде решили для каждого UI-класса определять несколько mock() функций с основными кейсами. В итоге у нас есть базовые превью, а при переиспользовании всегда видны возможные коллизии на основных кейсах.

Интересное решение, а как делаете вы?

Koala: New Terminal
#androidstudio

Я постоянный пользователь Beta-версий Android Studio. Мне почему-то везёт, и я не натыкаюсь на проблемы, которые мешают работе, поэтому всегда использую их вместо релизной версии.

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

Если IDE не предложит попробовать его самостоятельно, то можно включить его в Settings/Preferences | Tools | Terminal | Enable New Terminal.

С визуальной точки зрения всё стало значительно симпатичнее, а что самое главное — теперь команды разделяются по блокам и по ним можно быстро перемещаться. 🔥
В повседневной работе это невероятно облегчает навигацию по огромной простыне списка.

Ещё одной киллер-фичей является автодополнение, удобная история команд, да и что говорить — цветовая тема и палитра.

В общем, как только обновитесь — обязательно включайте, ведь у вас появится ещё один удобный инструмент.

Тут можно почитать подробнее про все фичи, а также посмотреть на то, как всё выглядит.

Пробовали? Как вам?

Kotlin: An Illustrated Guide
#kotlin

Сайт для новичков, который стоит добавить в закладки и опытным разработчикам — Dave Leeds on Kotlin.

Мне кажется, один из самых понятных и удобных гайдов по Kotlin, который я когда-либо видел. Примеры, забавные иллюстрации, простые примеры кода. Даже если вы знаете все темы — имеет смысл перечитать, ведь не всегда мы можем объяснить всё на пальцах так, чтобы поняла ваша бабушка.
А если вы новичок — можете смело начать изучение с этого гайда.

Последняя глава про Generic, а скоро ожидается про Coroutine.

Practical Optimizations
#android #optimization

Для всех, кто любит низкоуровневые оптимизации и прочий хардкод — прекрасный доклад от Romain Guy, где он описывает целый набор оптимизаций, которые они сделали в Compose.

В целом, будет полезно всем разработчикам: можно научиться чуть лучше читать bytecode как минимум. А как максимум — сделаете крутую оптимизацию в своём проекте.

А вот тут почти то же самое, но в цикле статей, если вам так удобнее.

Sync speedup в Gradle
#gradle

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

Автор обратил внимание на добавляемые репозитории в проект и решил посмотреть на то, куда уходит время при синке. Выяснилось, что много времени уходит на попытки получения зависимостей в тех репозиториях, где их нет, из-за чего sync увеличивается по времени.

Недолгий research показал, что можно добавить параметры exclusiveContent и content для каждого из репозитория, указывая там группы репозиториев.
Ещё интересный фикс — это настройка порядка репозиториев, оказывается он тоже влияет на скорость синка. Может сгодиться как быстрый фикс.

У автора получилось уменьшить время sync с почти 6 минут до 3 минут 17 секунд, что выглядит крайне круто. 🔥

State in your Kotlin apps
#kotlin #android

Архитектуры с Unidirectional Data Flow сейчас очень популярны в большинстве современных приложений: это отличный подход, который позволяет избежать ошибок при обновлении экрана, да и разрабатывать с этим подходом удобнее, особенно большие приложения.

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

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

Кстати, автор статьи подписан на канал, так что свои вопросы по статье можете задать в комментариях. 🤓

Дизайн система Android через Figma API
#design #android #ci

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

В проектах, где я работал — мы всегда приходили к какой-то дизайн системе. Иногда не совсем удачно, но чаще это очень сильно экономило время и ресурсы всех команд.
Правда, никогда не получалось сделать обновление ресурсов через CI.

Если вы хотите добавить ещё больше автоматизации в ваш проект — можно взять за основу эту статью, где ребята рассказывают свой путь, чтобы подружить Figma и обновление некоторых элементов дизайн-системы.
Тут и небольшой обзор текущих решений, и то, как всё это дело работает в xml и Compose. 🥸

Getting to Know Koin Annotations
#koin #kmm

Полезная статья-справочник по аннотациям в моём любимом DI-фреймворке — Koin.

Тут и про Koin DSL, и про Constructor DSL, и про аннотации. А ещё — как всё же проверять зависимости в compile time.

Кстати, Koin отлично себя показывает в мультиплатформе. 😇

Использовали в своих проектах? Как вам?

Кастомный Android Lint
#androidstudio

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

Решить эту проблему предлагается в этой статье при помощи кастомного Android Lint Rule. В ней, описывается кейс, когда мы хотим использовать кастомную функцию вместо elvis-оператора.

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

RTL адаптация в Android
#android

Хорошая статья, где описывается опыт поддержки RTL-языков в Android, в том числе и на Compose.

Для тех, кто не в теме. RTL (right-to-left) — это чтение справа-налево, которое встречается в языках ближнего востока, например, арабский. LTR (left-to-right) — привычное нам чтение слева-направо.

В Android довольно неплохо поддерживаются RTL-языки, начиная с API 17, но тем не менее — есть масса кейсов, на которые стоит посмотреть при тестировании.

Был опыт адаптации приложения под RTL-языки? Вдруг вы настолько круты, что адаптировали свой pet-проект, кто знает, расскажите в комментариях. 🇦🇪

Device streaming
#androidstudio

О, тут в Android Studio Jellyfish подвезли Device streaming: фича, которая позволяет тестировать своё приложение на различных девайсах, которые находятся в дата центрах Google.

Прикольная фича, стоит обратить внимание, особенно когда выходит свежая версия Android, а на ваши устройства она ещё не прилетела. Да и специфические устройства, типа Fold тоже не каждый хочет себе покупать.

Работает аналогично обычному подключению устройства, и фича бесплатна, пока находится в alpha. Дальше всё за монету и будет учитываться время подключения к устройству.

Все детали можно почитать тут.

Ресурсы в Compose Multiplatform
#compose

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

Неплохая обзорная статья, где описываются основные изменения работы с ресурсами после свежего релиза Compose Multiplatform 1.6.0-beta01.

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

HashMap для Jetpack Compose
#compose #performance

Интересная статья, где рассказывается про минусы стандартной HashMap в контектсте использования Jetpack Compose.

При использовании mutableMapOf() под капотом создаётся LinkedHashMap(), которая довольна хороша, но имеет недостаток: при каждом новом добавлении элемента создаётся LinkedHashMapEntry, из-за чего структура не очень memory-friendly.

Ну и сходу предлагается использовать другую структуру — ScatterMap, у которой подобных недостатков нет. В статье есть и замеры, и описывается главный недостаток этого подхода: структура хоть и map-based, но не наследуется от привычного нам Map, хотя и имеет подобные ему классы.

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