Rich Errors не заменяют sealed interface, а делают работу с неудачными сценариями проще, чем это можно достичь с sealed interface. И это я бы назвал Game Changer-ом для распространения подхода Errors as Values.

Для полноценной замены Union-типов, возможно, стоит ожидать нового удобного синтаксиса для sealed interface из этого тикета в YouTrack.

Rich Errors также не заменяют исключения, и они всё ещё нужны в своей нише, а именно – логические ошибки программиста. Подобно тому, как работает panic в Go и Rust, и fatalError в Swift.

🔴️️️️️️ Стрим в 17:00 МСК в субботу

Расскажем про fuzz-тестирование и про новую библиотеку kotlinx.fuzz для написания таких тестов.

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

Telegram | YouTube | Twitch

🔴️️️️️️ Мы в прямом эфире

Расскажем про то, как находить больше багов с помощью fuzz-тестирования с помощью новой библиотеке kotlinx.fuzz для написания таких тестов.

Telegram | YouTube | Twitch

Production-ready Compose Multiplatform

Не так давно произошло большое событие – вышла стабильная версия CMP под iOS. JetBrains заявляет, что Compose Multiplatform теперь является стабильным и KMP сейчас является полным решением для мобильной разработки – от общей бизнес логики вплоть до общего нативного UI.

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

До этого на рынке доминировали технологии по типу Flutter или React Native, которые рекламируются как компромисс в виде лишения возможности использовать платформенно-специфичное API в в обмен на кроссплатформенный UI. Теперь появилась стабильная технология, которая позволит писать кроссплатформенный UI с возможностью вызывать любые platform-specific API.

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

И самое главное, с чем могут возникнуть проблемы при написании кроссплатформенного UI – соответствие гайдлайнам конечных платформ. Есть некоторые библиотеки для CMP с поддержкой material 3/human design, но эти стандарты отличаются друг от друга и всё равно финальная вёрстка будет отличаться на конечных платформах. Тут вступает в силу трейд-офф, по которому вы должны писать свою platform-agnostic дизайн-систему, из-за чего приложения будут выглядить менее естественными.

А как думаете вы?

🔴️️️️️️ Стрим в 17:00 МСК в субботу

Расскажем про то, как можно реализовать мультиплатформенную систему плагинов с Kotlin DSL.

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

Поставьте себе уведомление, если интересно, а пока можете посмотреть прошлые стримы.

Telegram | YouTube | Twitch

Explicit Backing Fields: новая итерация

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

И по аналогии с неявными теневыми полями (implicit backing fields), предлагается ввести понятие "явные теневые поля". На YouTrack уже давно был proposal, о котором подробнее почитать можно тут. В нём предлагается добавить возможность переписать вышеописанный код при помощи одного поля, сократив количество кода. Но недавно началась новая итерация proposal-а, в котором слегка упростили фичу.

Как попробовать самим?

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

Вы можете опробовать эту фичу сами уже сейчас, для этого добавляем компиляторный флаг -XXLanguage:+ExplicitBackingFields в build.gradle.kts.

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