​​Understanding Gradle - The Fundamentals
#новичкам #gradle

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

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

Отличный курс для новичков, не так часто встретишь что-то действительно хорошее в видео формате.

​​Высокая производительность с Kotlin
#kotlin

Думаю, что не открою секрет, если скажу, что пользователям важно хорошо работающее приложение. Конечно, есть исключения в виде приложений, которые работают ужасно, но при этом имеют массу положительных отзывов: видимо, польза от них перевешивает их отвратительную работу и качество. 🤫

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

Вот вам статья, где автор рассказывает о том, что в себя включает понятие «производительность», на какие вещи стоит обратить внимание нам, а также какие средства языка Kotlin использовать, чтобы писать более эффективный код.

Советы крутые, можно найти для себя полезные штуки 🔥.

​​Jira на Github Actions
#cicd

Я тут последние несколько дней активно вникаю в тему настройки CI на Github Actions, и был удивлён, что в Jira нельзя передвинуть несколько задач одновременно, если вы каким-то образом получили этот список из вашего PR.

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

Если посмотреть, что делается под капотом этого Action, то по сути — это вызов API и совершение парочки запросов для того, чтобы передвигуть задачку. Свой Action писать не хотелось, поэтому решил написать свою gradle таску, которая сделает всё за нас.

1️⃣ Для начала, выполните запрос:
GET https://domain.atlassian.net/rest/api/3/issue/TASK-123/transitions,
чтобы получить идентификатор колонки, в которую вам надо перекинуть задачу. Нам надо поле id, а чтобы выполнить запрос — необходимо создать пароль в настройках и авторизоваться в Headers через Base Auth.

2️⃣ Создаём таску в gradle, а в неё передаём список задач и токен для авторизации будущих запросов, например так:
def taskNumbers = project.properties['items'].split(',').toUnique()
def jiraToken = project.properties['jira_token’].

Лучше передать сразу base64 от нашей базовой авторизации, а сам токен хранить в secrets на вашем CI.

3️⃣ Выполняем запрос:
for(taskNumber in taskNumbers) {
def body = "{ \"transition\": { \"id\": \"$transactionId\" } }"
def req = new URL("https://domain.atlassian.net/rest/api/3/issue/TASK-$taskNumber/transitions").openConnection()
req.setRequestMethod("POST")
req.setRequestProperty("Content-Type", "application/json; charset=UTF-8")
req.setRequestProperty("Authorization", "Basic $jiraToken")
req.setDoOutput(true)
req.getOutputStream().write(body.getBytes("UTF-8"))
println "Status code: ${req.getResponseCode()} for task $taskNumber"
}

Если вы всё сделали правильно, то вы получите 204 код и ваша задача перейдёт в нужную вам колонку. 😌

Дальше можно выполнить эту таску на CI:
./gradlew moveJiraTasks -Pitems=123,456 -Pjira_token=token

Полный текст таски можно взять тут.

​​JankStats Library
#library

Тут появилась любопытная библиотека от Google для анализа производительности приложений — JankStats.

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

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

​​Ruler от Spotify
#tools

Тут ребята из Spotify поделились любопытной наработкой для определения размера текущего apk-файла и его детального анализа.
Вообще размер apk — довольно важная метрика для приложения, ведь далеко не везде есть дешёвый и стабильный Интернет, поэтому потенциальные пользователи могут запросто отказаться от загрузки приложения, если его размер будет слишком большим.

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

Альтернатива — их собственное решение, которое называется Ruler. Выглядит всё довольно хорошо: на выходе получается html-страничка с детальной информацией о состоянии приложения, учитываются модули и разные бандлы для конкретной версии устройства.

​​Контракт для работы Android и Design команд
#design

Лайтовая статья, где автор делится советами для организации работы команды дизайнеров и разработчиков.

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

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

​​Kotlin Multiplatform — ATOM
#kmm

Тут ребята из Jetbrains сделали новый подскаст, где будут делиться последними новостями из мира KMM.
Обещают, что выпуски будут появляться раз в месяц, и уже доступен первый из них.

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

​​Процесс сборки Android
#android

Довольно хороший набор статей, где автор делится о том, как происходит процесс сборки ваших приложений под Android: как устроена компиляция ресурсов приложения, исходного кода, оптимизация ресурсов и т.д.

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

​​Koin 3.2 Beta & Roadmap на 2022
#koin #kotlin

Тут не так давно опубликовали Roadmap для весьма крутой и популярной библиотеки для DI — Koin.

Во-первых, теперь выпуск новой версии будет происходить раз в полгода, примерно как это делает Kotlin. То есть в этом году будет прекращена поддержка 2.x версий, 3.1.x до конца первого квартала этого года, а 3.2 скоро станет основной. Подобные циклы релизов позволят более планомерно обновлять эту библиотеку у себя в проекте.

Во-вторых, у Koin появилась спонсорская поддержка от компании Kotzilla, что даёт возможность тратить больше времени на разработку и поддержку этого проекта.

Ну и обновления в версии 3.2: появилась фича, называемая constructor DSL , которая позволяет добавлять компоненты без исполозования функции get(), добавляя всё только по имени класса.

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

Также добавилась поддержка новой Kotlin Native Memory Model.

Больше про изменения можно почитать тут.

​​Kotlin: парочку best practices
#kotlin

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

Описывать всё, что есть долго, поэтому вот вам ссылка на статью, где много примеров кода и отличных советов.

​​Rich Text в Jetpack Compose
#jetpack #compose

Тут подписчик подкинул классную статью, где довольно исчерпывающе описываются возможности для применения стилей текста в Jetpack Compose.

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

Автор рассказывает про множество свойств текста, использование TextStyle, добавление стилей через AnnotatedString.

​​Используйте Data Classes вместо Pairs
#kotlin

В языке Kotlin, да и не только в нём, есть классы, которые называются Pair и Tripple. По сути, они созданы для того, чтобы передавать два или три объекта.

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

fun getCoffee(): Pair<Roast, Size>

При вызове функции мы получаем:
val coffee = getCoffee()
print(“A ${coffee.second}, ${coffee.first} roast coffee.“)

Если добавить ещё и третий объект, то читать становится ещё сложнее.
Решение — как можно меньше использовать Pair, а вместо него использовать data-классы. Да, придётся создать дополнительный класс, однако вы получите бонусы в виде нормальной читаемости кода и возможности быстро его расширить.

Чуть больше примеров кода можно найти тут.

​​Annotations для Koin
#koin

Тут недавно появилась новость о новом проекте от создателей Koin — Annotations. Теперь отдельной зависимостью можно добавить возможность создавать модули и компоненты при помощи аннотаций. Всё также работает и в KMM.

Есть @Single, @Factory, @KoinViewModel, @Scoped, а сама библиотека уже в стадии beta. Обещают, что аннотации фактически никак не повлияют на время сборки проекта, хотя обязательно надо посмотреть, как оно будет на практике.

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

​​Play Time with Jetpack Compose
#jetpack #compose

Тут команда Google делится интересным опытом перехода от старого подхода на xml на Jetpack Compose.

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

Ребята решили переписать UI на Jetpack Compose, и у них получилось значительно уменьшить кодовую базу, примерно на 50%. Также ощутимо выросла продуктивность при написании кода и производительность всего приложения, в том числе анимаций.

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

​​Gradle Plugins
#gradle

В мире Android существует довольно плохо освещённая тема — написание плагинов к Gradle. Для многих разработчиков написание своих плагинов выглядит крайне сложным и непонятным. Поэтому, мы часто просто забиваем на этот довольно полезный инструмент, который может помочь оптимизировать много рутинных действий.

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

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

​​Notification runtime permission Android 13
#android

Не успели большинство телефонов обновиться до Android 12, как нам уже нужно думать о новом обновлении на Android 13. 🤔

Одним из важных обновлений в новой ОС будет запрос разрешений на отправку пользователю уведомлений от приложения. Штука очень важная☝️ да и обработка выглядит совсем не сложной.

Вот небольшой гайд о том, как лучше обработать показ разрешений пользователю.

​​Pixel perfect Android app
#design #android

Для многих не станет новостью то, что хороший дизайн — это важная часть приложения.

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

Тестирование хорошего UI/UX — это не самая простая задача: у нас есть много локалей, различных размеров шрифта, тёмная и светлая тема, ориентации.
Вот полезная статья, где описываются инструменты, при помощи которых можно протестировать все эти штуки.

Из неё узнал о существовании языков с псевдолокалями, которые добавляют в привычный нам язык диалекты, а также то, что, например, немецкий язык содержит примерно на 30% больше текста, чем остальные языки. 🥸
Так что — самое время посмотреть, не разорвало ли ваши View на некоторых из языков.

​​Clipt

Совсем недавно мне приходилось тестировать фичу, в которой важно было постоянно копировать текст с Mac на Android-устройство.

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

Немного погуглив, нашёл решение, которое, возможно, пригодится и вам.
Есть плагин для Google Chrome, который называется Clipt. Сначала устанавливаете плагин и приложение на Android, потом через учётную запись Google связываете два устройства, чуть настраиваете то, когда и что надо копировать, и вот у вас общий буфер обмена. 🙌🏻

​​Android 12: Data Access Rationale
#android

В Android 12 появилась фича под названием Data Access Rationale. Далеко не все разработчики используют её в своих приложениях, хотя штука довольно важная.

По сути, это Activity, которая даёт информацию пользователю о том, для чего нужно то или иное разрешение. Её можно открыть в информации о приложении прямо из системы, а также в Privacy Dashboard.

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

Кажется, что это действительно важный и логичный шаг в прозрачности использования фич, требующих разрешение: не всегда понятно, почему приложение запрашивает доступ к той или иной фиче, а подобное объяснение здорово повысит лояльность пользователя. 🤞🏻

​​Как измерить производительность Compose?
#compose

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

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

Итоговый отчёт работает в релизном билде и состоит из нескольких файлов:
• общая статистика по приложению;
• детальная статистика по каждой из функциий;
• csv-версия этой же статистики;
• информация о стабильности каждой из написанных функций.

Каждый раз мы получаем информацию о нескольких параметрах: Restartable, Skippable, Immutability & stability. Дальше, смотря на эти параметры, мы можем понять, что можно улучшить: например, если функция restartable, но не skippable, то стоит посмотреть, какие параметры являются входящими в эту функцию и почему компилятор считает некоторые из них unstable.

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