Telegram Web
🏝 Delight SQL Viewer - KMP библиотека для Android, iOS и Desktop, чтобы смотреть и редактировать содерживаемое БД, управляемой SQLDelight, напрямую из приложения 🤯

Для работы Viewer надо добавить зависимость в проект и провести простую интеграцию с вашей БД

Автор решения также написал статью (4м) на русском с демонстрацией возможностей

#kotlin #kmp #sqlite #android #ios #desktop
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Как устроены Kotlin Compiler Plugins и что они могут сделать с Kotlin кодом в процессе компиляции

#kotlin
Metro — Kotlin DI фреймворк, вдохновленный Dagger, Anvil и Kotlin-Inject. Принципиальное отличие — работает через плагин компилятора, а не KSP. Пока нет релизов, всё в разработке.

Мне его только что прислали. Буду разбираться и пробовать, расскажу о нём на 🪙 Boosty

#kotlin #kmp #di
Please open Telegram to view this post
VIEW IN TELEGRAM
💉 Koin Annotations 2.0 Stable

Koin Annotations — надстройка над Koin для описания зависимостей с помощью аннотаций и последующей генерации части графа для них.

Что нового в движке:
👉 Совместимость с KSP2
👉 Улучшена работа компилятора DI кода
👉 Улучшена генерация кода
👉 Полноценная поддержка KMP проектов
👉 Шаринг описаний зависимостей между модулями проектов
👉 Работает с Koin 4.0, Kotlin 2.0.21 и KSP 2.0.21-1.0.28

Новые фичи для разработчиков:
👉 Создание собственных аннотаций квалификаторов
👉 Автоматические биндинги
👉 ComponentScan работает сквозь Gradle модули
👉 Аннотации над ViewModel (работает с Jetpack и KMP)
@KoinViewModel
class MyViewModel(deps: Deps): ViewModel()


Ссылка без VPN

#kotlin #kmp #di #koin
Please open Telegram to view this post
VIEW IN TELEGRAM
Поддержите Koin IDE плагин на Product Hunt. Команда проделывают большую работу и точно заслуживает поддержки от сообщества!

#kotlin #koin #ide #androidstudio
🏝 Автоматизация проверки архитектурной правильности вашего кода

Для Kotlin есть классный инструмент - Konsist, который позволяет писать тесты по структуре кода в проекте. Например, можно проверить, что все UseCase находятся в нужном пакете:
class UseCaseKonsistTest {
@Test
fun `every use case resides in use case package`() {
Konsist
// Задаем скоуп всего проекта
.scopeFromProject()
// Получаем все классы
.classes()
// Фильтруем классы
.withNameEndingWith("UseCase")
// Проверяем, что они находятся в нужном пакете
.assertTrue { it.resideInPackage("..domain.usecase..") }
}
}


Можно писать более сложные проверки для классов, интерфейсов, функций, свойств, Generic типов и многого другого. Надо будет использовать его для моего FrameIO.

Использовали его? Делитесь впечатлениями!
Еще не применяли? Пишите, чем может быть полезным для вашего проекта или, наоборот - нет смысла
в утилите

#kotlin #архитектура
Please open Telegram to view this post
VIEW IN TELEGRAM
🏝 Как делать минималистичный API интерфейс с помощью extension fun

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

Например, интерфейс Flow из Kotlin выглядит так:

interface Flow<out T> {
suspend fun collect(collector: FlowCollector<T>)
}

fun interface FlowCollector<in T> {
suspend fun emit(value: T)
}


Почему это хороший подход?
👉 Минимализм и ясность интерфейса. Один метод в интерфейсе ясно показывает суть контракта, облегчает понимание и поддержку.
👉 Гибкость расширения API. Можно добавлять бесконечное количество новых операторов без изменения интерфейса и нарушения обратной совместимости.
👉 Удобство и читаемость. Цепочки вызовов выглядят компактно, легко читаемы и следуют единому стилю, принятому в Kotlin.

Плюсы подхода
Простое масштабирование библиотеки, благодаря гибкости Kotlin Extension-функций.
Лёгкость в написании и поддержке тестов, так как расширения можно тестировать отдельно.
Улучшение читаемости клиентского кода благодаря последовательной и понятной структуре вызовов.
Простые и понятные API интерфейсов в типах

Минусы подхода
⚠️ Сложность в управлении видимостью и областью применения расширений. Пользователь может запутаться в большом количестве операторов.
⚠️ Ограничение на возможность переопределения методов. Расширения не переопределяются, что может осложнить кастомизацию.

Когда лучше использовать методы интерфейса вместо расширений?
Обычно в интерфейс стоит помещать:
👉 Фундаментальные методы, которые описывают самую суть интерфейса.
👉 Методы, для которых критично переопределение и которые могут требовать разных реализаций в разных имплементациях.
👉 Функции, критичные к производительности, так как их реализация через расширения иногда менее эффективна.

Когда методы стоит делать как расширения
Явными кандидатами для функций через расширения к интерфейсу - те что имеют реализацию по умолчанию и просто вызывают другие функции этого же интерфейса

interface Container {

val childCount: Int

// Не имеет смысла как функция интерфейса
fun isEmpty(): Boolean = childCount == 0
}

// Дополнительное расширение, которое не нужно как часть API интерфейса
fun Container.isEmpty(): Boolean = childCount == 0


💬 Делитесь в комментариях используете ли вы такой подход при проектирование API

#kotlin
Please open Telegram to view this post
VIEW IN TELEGRAM
🏝 Обновили Kotlin Roadmap (февраль 2025)

Ключевые приоритеты разработки:
👉 Развитие возможностей языка: более высокие абстракции, лучшая производительность, более чистый код, повышение эффективности обработки данных.
👉 Kotlin Multiplatform: релиз "Kotlin to Swift Export", упрощение настройки проектов и создание KMP библиотек.
👉 Улучшение опыта сторонних контрибьюторов в экосистеме Kotlin.

#kotlin
Please open Telegram to view this post
VIEW IN TELEGRAM
Что нового в Kotlin за последние полгода?

👉 Поддержка отладки inline-функций в Android на уровне компилятора Kotlin
👉 Поддержка XCode 16 для KMP
👉 Публичная документация по API Kotlin Gradle Plugin
👉 Рабочая из коробки отладка для Kotlin/WASM
👉 Новое KMP API для Atomic
👉 Новые руководства для авторов библиотек

#kotlin
В ближайшие полгода в Kotlin Multiplatform будет много интересного:

👉 Первый публичный релиз прямого экспорта Kotlin в Swift (возможно, сторонние плагины для этого больше не понадобятся).
👉 Включение по умолчанию Concurrent Mark and Sweep (CMS) GC (быстрее и эффективнее).
👉 Реализация нового поколения формата распространения KMP библиотек (упрощение формата в фокусе).
🔥 Возможность объявлять зависимости KMP проектов в блоке dependency на уровне проекта, а не в DSL Kotlin плагина.
👉 Унификация работы inline функций между всеми стабильными таргетами (сейчас есть отличия в JVM).
👉 Включение инкрементальной компиляции klib артефактов по умолчанию.
👉 Стабилизация кросс-компиляции klib на разных платформах, что улучшит опыт разработчиков, работающих не на Mac.

У KMP даже есть свой дорожная карта разработки.

#kotlin #kmp
🐘 Планируемые улучшения в Gradle при работе с 🏝 Kotlin

👉 Поддержка Gradle Project Isolation (подробнее об этой функции здесь)
👉 Улучшение отчетов по компиляции Kotlin
👉 Поддержка Declarative Gradle
👉 Улучшение интеграции инструментов Kotlin/Native в Gradle
👉 Выпуск стабильных аргументов компилятора в Gradle DSL для упрощения конфигурации проектов на Kotlin и KMP

#kotlin #gradle
Please open Telegram to view this post
VIEW IN TELEGRAM
Channel photo updated
Совсем недавно наткнулся на полную официальную доку по API Gradle плагина Kotlin Multiplatform

#kotlin #kmp #документация
Please open Telegram to view this post
VIEW IN TELEGRAM
Новое DSL на замену Gradle Application плагина

В Kotlin 2.1.20 появилось новое экспериментальное DSL для замены функций Gradle Application плагин (несовместим с KMP Gradle плагин, начиная с Gradle 8.7)

kotlin {
jvm {
@OptIn(ExperimentalKotlinGradlePluginApi::class)
binaries {
// Configures a JavaExec task named "runJvm"
// and a Gradle distribution for the "main" compilation in this target
executable {
mainClass.set("foo.MainKt")
}

// Configures a JavaExec task named "runJvmAnother"
// and a Gradle distribution for the "main" compilation
executable(KotlinCompilation.MAIN_COMPILATION_NAME, "another") {
// Set a different class
mainClass.set("foo.MainAnotherKt")
}

// Configures a JavaExec task named "runJvmTest"
// and a Gradle distribution for the "test" compilation
executable(KotlinCompilation.TEST_COMPILATION_NAME) {
mainClass.set("foo.MainTestKt")
}

// Configures a JavaExec task named "runJvmTestAnother"
// and a Gradle distribution for the "test" compilation
executable(KotlinCompilation.TEST_COMPILATION_NAME, "another") {
mainClass.set("foo.MainAnotherTestKt")
}
}
}
}


#kotlin #gradle #kmp
Пример работы нового Common Atomic API из Kotlin 2.1.20

@OptIn(ExperimentalAtomicApi::class)
suspend fun main() {
// Initializes the atomic counter for processed items
var processedItems = AtomicInt(0)
val totalItems = 100
val items = List(totalItems) { "item$it" }
// Splits the items into chunks for processing by multiple coroutines
val chunkSize = 20
val itemChunks = items.chunked(chunkSize)
coroutineScope {
for (chunk in itemChunks) {
launch {
for (item in chunk) {
println("Processing $item in thread ${Thread.currentThread()}")
processedItems += 1 // Increment counter atomically
}
}
}
}


#kotlin
2025/06/29 22:37:10
Back to Top
HTML Embed Code: