Kotlin Meta
246 subscribers
57 photos
2 videos
1 file
55 links
Всякое разное интересное про язык программирования Kotlin и около него.

Чатик: @kotlinmetachat.
Мы на YouTube: https://youtube.com/@KotlinMeta.
Мы на Twitch: https://twitch.tv/kotlinmeta.
Download Telegram
🔐 Безопасное API

Основной сценарий использования исключений в Kotlin – логические ошибки (далее – нарушение контракта). Если в какой-то момент программа попала в состояние, в котором она не должна оказаться, то выкидывается исключение.

Часто для этого используются функции check(), require() и error(). Доку тут я пересказывать не буду, про отличия можете почитать сами.

В случае, если возникла ошибка, которую необходимо обработать, – не нужно использовать исключения. Используйте nullable-типы или sealed interface.

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

Иногда, правда, заранее неизвестно, является ли определённая ошибка нарушением контракта или той, которую необходимо обработать. В таком случае предлагается делать 2 варианта для функции, как это делает стандартная библиотека Kotlin:

fun String.toInt(): Int, если отличный от Int ввод является нарушением контракта

fun String.toIntOrNull(): Int?, если необходимо обработать сценарий некорректного ввода
Please open Telegram to view this post
VIEW IN TELEGRAM
1
🌐 IOException

Ох, это самое интересное, и самое спорное. IOException – точно не является нарушением контракта, но IOException любят и в JetBrains. Так, например, даже в новых библиотеках, написанных с нуля (имею ввиду ktor), активно используются эти исключения. Т.е. для таких исключений делается исключение (pun intended).

Аргументация такова: если бы после каждого IO-вызова нужно было бы проверять была ли выполнена операция успешно, то у нас было бы много бойлерплейта. Поэтому на IO-запросы нужен единый для всего приложения паттерн для обработки исключений. Обычно это делается на границе между низкоуровневой сетевой логикой и высокоуровневой доменной логикой. Для меня эта граница находится в репозитории (в архитектурном смысле). Все классы-репозитории возвращают kotlin.Result и не имеют права кидать никаких исключений.

То, чего нет в статье Романа, но лично я предпочитаю для пущей явности: все функции, которые потенциально кидают IOException, я помечаю суффиксом OrThrow(). Таким образом, я всегда вижу функции, которые могут выкинуть исключение IOException, и каждый раз при их вызове мне не нужно лезть в документацию или помнить, кидает ли конкретная функция исключение.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍421
tg_image_3548592563.png
320.8 KB
📊 Финализируем всё таким графом, который можно себе сохранить и поделиться с другом
Please open Telegram to view this post
VIEW IN TELEGRAM
73❤‍🔥2👍1
Live stream started
🔴️️️️️️ Мы в прямом эфире

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

Telegram | YouTube | Twitch
👍421
Live stream finished (2 hours)
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 дизайн-систему, из-за чего приложения будут выглядить менее естественными.

А как думаете вы?
9👍5🔥41
Media is too big
VIEW IN TELEGRAM
📹 kotlinx.fuzz: новая библиотека для тестирования от JetBrains – Запись стрима.

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

⚠️ Под всеми нашими видео будут тайм-коды. Их можно найти в описании. Ютуб не даёт разбивать на секции видео для маленьких каналов :(

Секции:

00:00 - Читаем блог-пост от JetBrains
19:30 - Пишем азбуку морзе и fuzz-тестируем
1:00:33 - Улучшаем код благодаря fuzz-тестам
1:14:34 - Смотрим презентацию про kotlinx.fuzz
1:38:34 - Мысли в слух о будущем

YouTube
Please open Telegram to view this post
VIEW IN TELEGRAM
50👍866🔥2
🔴️️️️️️ Стрим в 17:00 МСК в субботу

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

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

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

Telegram | YouTube | Twitch
8👍531
Explicit Backing Fields: новая итерация

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

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

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

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

Подробнее про мотивацию, предыдущие итерации и фидбек других участников сообщества можно глянуть в дискуссии на GitHub.
16👍22
Live stream started
🔴️️️️️️ Мы в прямом эфире

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

Telegram | YouTube | Twitch
1043👍1
Live stream finished (1 hour)
🧑‍💻 Apple объявляет о поддержке интеропа Swift <-> Java

Две новые библиотеки SwiftKit и JavaKit сделают проще вызов Java-функций из Swift и наоборот. Почему это интересно нам, Kotlin-разработчикам? Ну, потому что будут всё больше распространяться новости, что Swift идёт по пути Kotlin и можно будет писать кроссплатформенные приложения под Java также, как и на Kotlin под Swift. И это не так.

В чём главное различие? Swift решает вопрос интеропа на уровне библиотеки. Kotlin же – на уровне компилятора. Основной бонус, который мы из-за этого получаем, – это очень гладкая интеграция. Если в настроенном проекте есть Kotlin и Swift файлы, то их декларации будут общими между двумя файлами. Swift будет видеть все функции/классы/интерфейсы Kotlin и сможет их вызывать/реализовывать. И наоборот. Swift <-> Java Interoperability работает по другому принципу. Для каждого вызова Java из Swift (и наоборот) необходимо написать специальный метод-обёртку, который работает через JNI. Что можно было делать и раньше, но занимало больше кода. Никакой новой возможности не появлось.

Это означает, что в Kotlin для использования Swift-библиотеки достаточно подключить её из spm или cocoapods. И т.к. пространство имён становится общее между Swift и Kotlin, никаких дополнительных действий делать не надо. И такое удобство возможно только в Kotlin, ибо он компилируется под нужную платформу, а, соответственно, имеет доступ к пространству имён этой платформы. Swift же не компилируется и не будет компилироваться в Java-bytecode, а в таком варианте уровень интеропа всегда будет отставать.
Please open Telegram to view this post
VIEW IN TELEGRAM
842👍1
Media is too big
VIEW IN TELEGRAM
📹 Как сделать систему плагинов на Kotlin?

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

00:00 – Что за плагины мы будем смотреть?
04:22 – Схематично разбираем систему плагинов
21:40 – Рассматриваем Raycast как пример приложения с плагинами
23:34 – AIDL: объективно самый лучший способ создавать плагины
39:00 – Альтернатива Raycast от Эмиля под Android (Gester)
1:10:44 – Kotlin DSL: теория
1:17:48 – Kotlin DSL: практика
1:24:50 – Exteragram: плагины для Telegram-клиента на Python
1:28:30 – Рассматриваем плагин для поиска приложений в Gester
1:33:03 – Всем удачи, всем пока

YouTube
Please open Telegram to view this post
VIEW IN TELEGRAM
👍65🔥22
🔴 Стрим в воскресенье в 19:00

Присоединяйтесь на стрим по обсуждению Telegram-ботов! В это воскресенье мы соберёмся не только с Эмилем, но и с специальным гостем: Лёшей Овсянниковым.

Лёша – автор библиотеки 🤖 ktgbotapi, которая по моему мнению превосходит все существующие библиотеки под Kotlin в плане идиоматичности. А ещё он как-то умудряется совмещать это с фулл-тайм работой 😅️️️️️️

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

Telegram | YouTube | Twitch
Please open Telegram to view this post
VIEW IN TELEGRAM
136👍3
Live stream scheduled for
🏝 Это первоапрельская шутка полноценный пропозал, прошедший несколько итераций

В Kotlin всерьёз рассматривают добавление static-функций и ведут обсуждение с коммьюнити. Пропозал: здесь, обсуждение: здесь.

Основные мотивации две:

• Разрешить делать статические функции-расширения на типы без компаньона
• Разрешить создавать статические функции без необходимости создавать объект

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

Самое адекватное предложение на данный момент – преобразовать статики-затычки в органичную фичу неймспейсов. Неймспейсы (пространства имён) уже есть в Kotlin: это пространство имён внутри пакета, класса, файла или даже функции. Концепция неймспейсов будет гармонично сосуществовать с объектами, и решать вышеперечисленные проблемы.

💬 Предыдущие 2 абзаца – это личное мнение. Оно не верное, оно очень упрощённое, оно может отличаться от вашего. Поэтому призываю в комментарии обсуждать! И не забудьте про ссылки на оригинальные пропозалы и обсуждение, они тоже интересные.
Please open Telegram to view this post
VIEW IN TELEGRAM
2