​​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.

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

​​Flow под капотом
#flow

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

Автор утверждает, что сама концепция Flow — проще, чем многие разработчики думают: под капотом описано много простых механизмов, которые после объединения и выдают то, что мы привыкли видеть при использовании Flow.

Для понимания всего, автор делает несколько простой лямбда-функции, которую, постепенно усложняя, превращает в подобие того, что мы видим во Flow.

​​KMM — UI State management
#kmm

Классный цикл статей, где автор рассматривает управление состоянием View при помощи архитектуры MVI, причём и на iOS и на Android при помощи KMM.

В первой статье автор рассказывает о базовых принципах MVI и вводит те понятия, которые там используются: State, Event, SideEffect, а также делает базовую инмплементацию на примере простенького приложения. Будет полезно, если вы не очень хорошо знакомы с MVI.

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

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

​​Равенство объектов в Java и Kotlin
#kotlin

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

Наиболее интересно посмотреть на кейсы, где разные подходы к проверке на равенство могут привести к плохим результатам.
Например, в Java надо быть внимательным при наследовании одного объекта от другого и их дальнейшего сравнения: в этом случае не равные по сути объекты могут оказаться равными по функции equals(). Любопытен и тот факт, что функция сравнения часто может оказаться менее производительной, чем кажется на первый взгляд.

В Kotlin было интересно посмотреть про кейс использования массивов в data-классах.

Пара выводов из этой статьи:

1️⃣ Проверьте, можно ли обойтись без переопределения функций equals/hashCode. Это может помочь в производительности сравнения функций.

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

3️⃣ Если не получается использовать принцип Composition over inheritance, то проверьте правильность использования функций equals в абстрактном и наследуемом классах.

​​Testing Kotlin coroutines on Android
#tests

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

Для тестов нужно добавить специальную зависимость kotlinx.coroutines.test, после которой становятся доступными сразу несколько полезных функций.
Например, функция runTest позволяет обернуть существующий код на coroutines и выполнить его.

Кроме этого, добавляются тестовые Dispatchers, которые используются только в тестах. В статье описывается, какие типы существуют, а также как корректно применить их к существующему коду.

​​Переменные при сборке проекта

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

1️⃣ Дано: некая переменная, которая может меняться в зависимости от разных билдов.

2️⃣ Заводим эту переменную в build.gradle и прописываем ей дефолтное значение, например:
def isVariable = false

3️⃣ Дальше добавляем проверку на наличие этой переменной в свойствах, которые будем передавать в командной строке при сборке.
if (project.hasProperty('isVariable')) {
isVariable = project.property('isVariable').toBoolean()
}

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

4️⃣ Начинаем сборку билда и передаём нужную нам переменную. По желанию, их может быть несколько.
./gradlew assembleQaRelease -PisVariable=true.

На этом, в целом всё, может быть и эта фича будет кому-то полезна. 🤓

​​Отмена долгих операций
#coroutines #kotlin

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

В качестве примера были взяты Coroutines, что здорово.
Даже если в проекте вам не обязательно делать все операции отменяемыми, автор довольно годно рассматривает различные состоятия Coroutines, какое поведение будет при отмене, если имеются дочерние задачи, да и в целом, как сделать отмену контролируемой. 👌🏻