Я веду бэклог постов и в рубрике #насмотренность следующий пост должен был быть про функции-конструкторы. Но иногда нужно просто немного подождать и кто-то сделает все за тебя :) На хабре вышла статья "Конструкторы-самозванцы в Kotlin", где автор описывает варианты мимикрии функций под синтаксис конструктора и в каких случаях это может понадобиться. Спасибо ему! Мне остаётся только досыпать примеров использования в Open Source.

1️⃣ Функция-конструктор
Это просто функция высшего порядка, написаная с большой буквы, которая внутри создаёт и возвращает инстанс класса.
Полезно, если хочется дать возможность "создавать инстанс интерфейса". Объявляете интерфейс, кладёте рядом с ним функцию с таким же названием и готово, даже импортировать её отдельно не придётся. Реализация интерфейса при этом может остаться приватной. Вызовы MutableStateFlow и MutableSharedFlow в корутинах, Json в kotlinx.serialization это всё вызовы таких функций. Это помогает уменьшить API-surface, а значит упростить использование API.
Ещё один вариант использования — вместе с inline-классами. Например, у Size в Compose конструктор помечен как internal, а "создание инстанса" происходит через функцию c двумя параметрами.

2️⃣ Перегрузка Companion.invoke
Причины применения указанные в статье (контроль над созданием объекта, создание пула объектов, кэширование и т.д.) классные, но нужны примеры. Пример контроля над созданием объекта можно увидеть в PlatformVersion в ktor. То есть в зависимости от определённой логики мы можем мы либо создаём инстанс, либо возвращаем какой-то существующий.
Но часто применение более банальное — вместо вторичного конструктора. Тут я могу только догадываться почему не используется вторичный конструктор, но примеры такого применения можно увидеть в RuleSet из detekt и MockEngine из ktor. Иногда применение вместо вторичного конструктора можно оправдать тем, что логики для подготовки параметров конструктора очень много. Например в SpriteAnimation из korge (игровой движок на Kotlin).

3️⃣ <Context>.invoke()
То же самое, что предыдущий вариант, но для случая когда нужно ограничить применение invoke контекстом.
В дикой природе этот вариант я не встречал, но сам автор даёт пример применения в yatagan и рассказывает в статье зачем это понадобилось. После выхода context parameters (следующая итерация context receiver'ов) этот вариант будет выглядеть приятнее.

🤔 Как относиться к такому?
Я часто вижу хейт в сторону подобных конструкций, мол мимикрия и переопределение операторов это зло, так как порождает неявность. Да, на самом деле вызывается не конструктор, а функция, но что в этом плохого если она выполняет ту же смысловую нагрузку? Уверен, многие с чистой совестью вызывают MutableStateFlow и им не важно, что под капотом. Главное следовать принципу наименьшего удивления. Если что-то выглядит как конструктор, оно и работать должно как конструктор.
Накидайте аргументов если я не прав!

#kotlin

https://github.com/ShreyashKore/wonderous_compose

Я уже упоминал этот проект как-то раз. Очень красиво и работает на всех возможных платформах! (не надо только пробовать веб версию на мобильных устройствах)
А теперь там появились встроенные карты на всех платформах - стоит изучить 😉

#Предложка #Libs #Compose

Compose Color Preview

Наверняка вы замечали, что при работе с Compose Multiplatform в IntelliJ IDEA нет привычных превью цветов в панели слева. Одним из решений этой проблемы является Compose Color Preview — плагин, автором которого является один из подписчиков канала. Однозначно лайк 👍

Для тех, кому лень или некогда смотреть, хорошая статья на Хабре: https://habr.com/ru/companies/kts/articles/814363/

Fleet - официально IDE для KMP разработки

#kotlinconf #ide #fleet

Небольшая статья, которая поможет разобраться в разнообразии *links в Android

Всем привет!

Давно меня не было слышно, очень-очень плотно работа забрала себе :D
Но все-таки, хочется немного порадовать себя и вас. Сегодня у нас вышла новая статья по механизмам работы WebLinks, AppLinks и DeepLinks в Android. Я очень часто их путал и до конца не понимал, а в чем же отличие одного механизма от другого.

И наконец-то, совместно с @veselinaz до конца разобрались, что это и с чем едят.

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

Очень надеюсь, вам понравится!

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

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")
    }
}

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