Основной сценарий использования исключений в Kotlin – логические ошибки (далее – нарушение контракта). Если в какой-то момент программа попала в состояние, в котором она не должна оказаться, то выкидывается исключение.
Часто для этого используются функции
check()
, require()
и error()
. Доку тут я пересказывать не буду, про отличия можете почитать сами.В случае, если возникла ошибка, которую необходимо обработать, – не нужно использовать исключения. Используйте nullable-типы или sealed interface.
Иногда, правда, заранее неизвестно, является ли определённая ошибка нарушением контракта или той, которую необходимо обработать. В таком случае предлагается делать 2 варианта для функции, как это делает стандартная библиотека Kotlin:
•
fun String.toInt(): Int
, если отличный от Int ввод является нарушением контракта•
fun String.toIntOrNull(): Int?
, если необходимо обработать сценарий некорректного вводаPlease open Telegram to view this post
VIEW IN TELEGRAM
Ох, это самое интересное, и самое спорное. IOException – точно не является нарушением контракта, но IOException любят и в JetBrains. Так, например, даже в новых библиотеках, написанных с нуля (имею ввиду ktor), активно используются эти исключения. Т.е. для таких исключений делается исключение (pun intended).
Аргументация такова: если бы после каждого IO-вызова нужно было бы проверять была ли выполнена операция успешно, то у нас было бы много бойлерплейта. Поэтому на IO-запросы нужен единый для всего приложения паттерн для обработки исключений. Обычно это делается на границе между низкоуровневой сетевой логикой и высокоуровневой доменной логикой. Для меня эта граница находится в репозитории (в архитектурном смысле). Все классы-репозитории возвращают
kotlin.Result
и не имеют права кидать никаких исключений.То, чего нет в статье Романа, но лично я предпочитаю для пущей явности: все функции, которые потенциально кидают IOException, я помечаю суффиксом
OrThrow()
. Таким образом, я всегда вижу функции, которые могут выкинуть исключение IOException, и каждый раз при их вызове мне не нужно лезть в документацию или помнить, кидает ли конкретная функция исключение.Please open Telegram to view this post
VIEW IN TELEGRAM
👍4 2 1
tg_image_3548592563.png
320.8 KB
Please open Telegram to view this post
VIEW IN TELEGRAM
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 дизайн-систему, из-за чего приложения будут выглядить менее естественными.
А как думаете вы?
Не так давно произошло большое событие – вышла стабильная версия 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 дизайн-систему, из-за чего приложения будут выглядить менее естественными.
А как думаете вы?
Media is too big
VIEW IN TELEGRAM
Написали небольшой проект для кодирования азбуки морзе, протестировали его с помощью фаззи тестинга. Интересно, как фаззи тестирование в данном случае не просто генерирует рандомные тест-кейсы, но и запоминает неуспешные, автоматически повышает 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👍8❤6 6🔥2
🔴️️️️️️ Стрим в 17:00 МСК в субботу
Расскажем про то, как можно реализовать мультиплатформенную систему плагинов с Kotlin DSL.
Посмотрим на то, как можно реализовать удобное создание и использование кастомной системы плагинов с использованием фишек языка. И покажем какие есть основные способы создания кастомной системы плагинов на стороне платформы и как можно было бы сделать плагины сразу на нескольких платформах. Попишем плагины разными способами и определим каким способом будет лучше всего это сделать.
Поставьте себе уведомление, если интересно, а пока можете посмотреть прошлые стримы.
Telegram | YouTube | Twitch
Расскажем про то, как можно реализовать мультиплатформенную систему плагинов с Kotlin DSL.
Посмотрим на то, как можно реализовать удобное создание и использование кастомной системы плагинов с использованием фишек языка. И покажем какие есть основные способы создания кастомной системы плагинов на стороне платформы и как можно было бы сделать плагины сразу на нескольких платформах. Попишем плагины разными способами и определим каким способом будет лучше всего это сделать.
Поставьте себе уведомление, если интересно, а пока можете посмотреть прошлые стримы.
Telegram | YouTube | Twitch
Explicit Backing Fields: новая итерация
Когда мы хотим объявить некоторую изменяющуюся сущность с приватным доступом в рамках класса и при этом сделать дублирующее поле, которое позволяет получить публичный доступ к полю извне только для чтения, мы обычно писали два поля.
И по аналогии с неявными теневыми полями (implicit backing fields), предлагается ввести понятие "явные теневые поля". На YouTrack уже давно был proposal, о котором подробнее почитать можно тут. В нём предлагается добавить возможность переписать вышеописанный код при помощи одного поля, сократив количество кода. Но недавно началась новая итерация proposal-а, в котором слегка упростили фичу.
Когда мы хотим объявить некоторую изменяющуюся сущность с приватным доступом в рамках класса и при этом сделать дублирующее поле, которое позволяет получить публичный доступ к полю извне только для чтения, мы обычно писали два поля.
И по аналогии с неявными теневыми полями (implicit backing fields), предлагается ввести понятие "явные теневые поля". На YouTrack уже давно был proposal, о котором подробнее почитать можно тут. В нём предлагается добавить возможность переписать вышеописанный код при помощи одного поля, сократив количество кода. Но недавно началась новая итерация proposal-а, в котором слегка упростили фичу.
1 7❤2 2🎉1
Как попробовать самим?
Действительно ли фича упростит код или она просто будет ненужным сахаром, из-за которого будет сложнее войти в язык новичкам. Будет ли мешанина старых и новых подходов?
Вы можете опробовать эту фичу сами уже сейчас, для этого добавляем компиляторный флаг
Подробнее про мотивацию, предыдущие итерации и фидбек других участников сообщества можно глянуть в дискуссии на GitHub.
Действительно ли фича упростит код или она просто будет ненужным сахаром, из-за которого будет сложнее войти в язык новичкам. Будет ли мешанина старых и новых подходов?
Вы можете опробовать эту фичу сами уже сейчас, для этого добавляем компиляторный флаг
-XXLanguage:+ExplicitBackingFields
в build.gradle.kts.Подробнее про мотивацию, предыдущие итерации и фидбек других участников сообщества можно глянуть в дискуссии на GitHub.
1 6👍2 2
Две новые библиотеки
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
Media is too big
VIEW IN TELEGRAM
Показали основные способы реализовать возможность расширять функциональность приложения сторонними разработчиками. Посмотрели как можно сделать разработку плагинов удобнее при помощи 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
👍6 5🔥2 2
🔴 Стрим в воскресенье в 19:00
Присоединяйтесь на стрим по обсуждению Telegram-ботов! В это воскресенье мы соберёмся не только с Эмилем, но и с специальным гостем: Лёшей Овсянниковым.
Лёша – автор библиотеки🤖 ktgbotapi, которая по моему мнению превосходит все существующие библиотеки под Kotlin в плане идиоматичности. А ещё он как-то умудряется совмещать это с фулл-тайм работой 😅️️️️️️
Напишем тестового бота, поговорим о библиотеке и о жизни опенсорс разработчика. Ставьте уведомление, делитесь с друзьями, и до встречи на стриме!
Telegram | YouTube | Twitch
Присоединяйтесь на стрим по обсуждению Telegram-ботов! В это воскресенье мы соберёмся не только с Эмилем, но и с специальным гостем: Лёшей Овсянниковым.
Лёша – автор библиотеки
Напишем тестового бота, поговорим о библиотеке и о жизни опенсорс разработчика. Ставьте уведомление, делитесь с друзьями, и до встречи на стриме!
Telegram | YouTube | Twitch
Please open Telegram to view this post
VIEW IN TELEGRAM
Как бы вы отнеслись к добавлению статиков в Kotlin? (смотрите пост ниже)
Anonymous Poll
9%
Не знаю, что такое статики
38%
Что? В Kotlin же есть компаньоны, разве статики не в Java?
38%
Понимаю, какие кейсы могут покрыть статики, но решение – затыкание дыр, а не полноценная фича
15%
Статики – нужная фича
В Kotlin всерьёз рассматривают добавление static-функций и ведут обсуждение с коммьюнити. Пропозал: здесь, обсуждение: здесь.
Основные мотивации две:
• Разрешить делать статические функции-расширения на типы без компаньона
• Разрешить создавать статические функции без необходимости создавать объект
На этом канале мы высказываем наше мнение,
Самое адекватное предложение на данный момент – преобразовать статики-затычки в органичную фичу неймспейсов. Неймспейсы (пространства имён) уже есть в Kotlin: это пространство имён внутри пакета, класса, файла или даже функции. Концепция неймспейсов будет гармонично сосуществовать с объектами, и решать вышеперечисленные проблемы.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2