📎 Разница между лямбда-выражением и анонимной функцией

1️⃣ Синтаксис

Лямбда-выражения определяются заключением их в фигурные скобки в виде { параметры -> тело }.

Анонимные функции определяются через ключевое слово fun как обычные функции, хотя не имеют имени.

2️⃣ Поведение оператора return без метки

🔘 В лямбда-выражении использование оператора return без метки приводит к возврату из обрамляющей (внешней) функции, а не из самого лямбда-выражения (т.е. полностью завершает работу этой функции и код, указанный после оператора return никогда не выполнится). Это называется нелокальным возвратом (non-local return), и может иметь неожиданное поведение и привести к ошибкам. В лямбда-выражениях рекомендуется использовать метки для явного указания точки возврата.

🔘 В анонимной функции return без метки приводит к возврату только из самой анонимной функции (а не из внешней функции), продолжая выполнение кода после вызова анонимной функции в обрамляющей функции. Анонимные функции ведут себя как ожидается для классических функций с явным оператором return.

Таким образом, поведение оператора return без метки различается только в том, как завершается выполнение функции, в которой вызывается выражение. В лямбда-выражении, вызывающая функция завершается полностью, а в анонимной функции только сама анонимная функция.

3️⃣ Поведение оператора return с меткой

Оператор return с меткой позволяет указать точное место, из которого нужно вернуться при вызове return.

🔘 Если использовать return@label в лямбда-выражении, то возврат будет осуществляться из конкретной лямбды, к которой применена метка. Вместо нелокального возврата, который происходит при использовании return без метки, return с меткой завершит только ту лямбду, которая соответствует указанной метке, и выполнение кода продолжится после этой лямбды во внешней функции. Метка позволяет читать и понимать код проще, так как явно указывает, откуда происходит возврат.

🔘 В анонимных функциях return без метки уже осуществляет возврат из самой анонимной функции. Однако, при использовании метки return@label вы также можете контролировать возврат из анонимной функции в сложных сценариях (например, при работе с несколькими вложенными функциями).

В обоих случаях использование оператора return с меткой показывает точку возврата и делает код более явным и контролируемым.

👉 Подробнее о возврате к меткам

Библиотека мобильного разработчика

#буст #JuniorKit #Kotlin

📎 Блок инициализации (init блок)

Основной конструктор не может в себе содержать какую-либо логику по инициализации свойств (исполняемый код). Он предназначен исключительно для объявления свойств и присвоения им полученных значений. Поэтому вся логика может быть помещена в блок инициализации — блок кода, обязательно выполняемый при создании объекта независимо от того, с помощью какого конструктора этот объект создаётся. Помечается он словом init.

class Person(val name: String, var age: Int) {
    var id: Int = 0

    // require выдает ошибку с указанным текстом, если условие в левой части false
    init {
        require(name.isNotBlank(), { "У человека должно быть имя!" })
        require(age > -1, { "Возраст не может быть отрицательным." })
    }

    constructor(name: String, age: Int, id: Int) : this(name, age) {
        if (id > 0) this.id = id * 2
    }
}

По сути блок инициализации — это способ настроить переменные или значения, а также проверить, что были переданы допустимые параметры. Код в блоке инициализации выполняется сразу после создания экземпляра класса, т.е. сразу после вызова основного конструктора. В классе может быть один или несколько блоков инициализации и выполняться они будут последовательно.

class Person(val name: String, var age: Int) {
    // сначала вызывается основной конструктор и создаются свойства класса
    // далее вызывается первый блок инициализации
    init {
        ...
    }

    // после первого вызывается второй блок инициализации
    init {
        ...
    }

    // и т.д.
}

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

➡️ Подробнее в статье

🐸 Библиотека мобильного разработчика

#буст #MiddlePath #Kotlin

🐸 Библиотека мобильного разработчика

#КодКрашТест #JuniorKit #Kotlin

🐸 Библиотека мобильного разработчика

#междусобойчик #MiddlePath #Kotlin

❓ Как функции расширения работают под капотом

По своей задумке, функция расширения Kotlin — это дополнительный метод для любого объекта, даже для потенциально несуществующего (нуллабельного). Этот инструмент является прямой реализацией переопределения методов паттерна проектирования Декоратор.

ВАЖНО: В функциях расширения мы можем обращаться к любым общедоступным свойствам и методам объекта, однако не можем обращаться к свойствам и методам с модификаторами private и protected.

ВАЖНО: Функции расширения не переопределяют функции, которые уже определены в классе. Если функция расширения имеет ту же сигнатуру, что и уже имеющаяся функция класса, то компилятор просто будет игнорировать подобную функцию расширения.

Определение аналогично определению обычной функции за тем исключением, что после слова fun идет название типа, для которого определяется функция, и через точку название функции. Определим пару функций расширения к типам Int и String:

fun main() {
 
    val hello: String = "hello world"
    println(hello.wordCount('l'))   // 3
    println(hello.wordCount('o'))   // 2
    println(4.square())             // 16
    println(6.square())             // 36
}
 
fun String.wordCount(c: Char) : Int {
    var count = 0
    for(n in this) {
        if(n == c) count++
    }
    return count
}
fun Int.square(): Int {
    return this * this
}

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

fun Int.square(): Int {
    return this * this
}

Через this обращаемся к тому объекту, для которого будет вызываться функция. И затем вы можем вызвать ее следующим образом:

4.square()      // 16

Для типа String определена функция wordCount, которая подсчитывает, сколько встречается определенный символ в строке.

🐸 Библиотека мобильного разработчика

#буст #JuniorKit #Kotlin

🔍 Внедрение чистой архитектуры с помощью Kotlin

1️⃣ Уровень предметной области (основная бизнес-логика)

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

➖ Определение интерфейса репозитория

interface UserRepository {
    suspend fun getUserById(id: String): User
}

➖ Пример использования

class GetUserByIdUseCase(private val userRepository: UserRepository) {
    suspend operator fun invoke(id: String): User {
        return userRepository.getUserById(id)
    }
}

2️⃣ Уровень данных (реализация репозиториев и источников данных)

Уровень данных предоставляет конкретные реализации интерфейсов репозитория. Он взаимодействует с API, базами данных или локальным хранилищем.

➖ Источник данных

interface UserRemoteDataSource {
    suspend fun fetchUserById(id: String): User
}

class UserRemoteDataSourceImpl(private val api: UserApi) : UserRemoteDataSource {
    override suspend fun fetchUserById(id: String): User {
        return api.fetchUserById(id)
    }
}

➖ Реализация репозитория

class UserRepositoryImpl(private val remoteDataSource: UserRemoteDataSource) : UserRepository {
    override suspend fun getUserById(id: String): User {
        return remoteDataSource.fetchUserById(id)
    }
}

3️⃣ Уровень представления (UI и ViewModel)

Представление слоя отвечает за логику пользовательского интерфейса и государственного управления. Это зависит от слой домена но напрямую не взаимодействует с уровень данных .

➖ ViewModel

class UserViewModel(private val getUserByIdUseCase: GetUserByIdUseCase) : ViewModel() {

    private val _user = MutableStateFlow<User?>(null)
    val user: StateFlow<User?> get() = _user.asStateFlow()

    fun loadUser(id: String) {
        viewModelScope.launch {
            _user.value = getUserByIdUseCase(id)
        }
    }
}

🐸 Библиотека мобильного разработчика

#АрхитектурныйКод #SeniorView #Kotlin

🐸 Библиотека мобильного разработчика

#КодКрашТест #JuniorKit #Kotlin

🐸 Библиотека мобильного разработчика

#междусобойчик #JuniorKit #Kotlin

✨ Эффект ЭЛТ-экрана в Jetpack Compose

ЭЛТ-мониторы — это размытые края, линии сканирования и лёгкое свечение. Такой эффект можно воспроизвести в Compose с помощью GraphicsLayer, градиентов и размытия.

🔹 Базовый принцип

Мы один раз записываем контент во внеэкранный буфер и многократно перерисовываем его разными слоями.

val graphicsLayer = rememberGraphicsLayer()

Box(Modifier.drawWithContent {
    graphicsLayer.record { drawContent() }
}) {
    content()
}

Теперь drawLayer(graphicsLayer) можно использовать в любых эффектах.

🔹 Линии сканирования

Создаём повторяющиеся градиенты — вертикальные и горизонтальные:

private fun DrawScope.drawScanLines(alpha: Float, blend: BlendMode) {
    val c = Colors.Black.copy(alpha)
    drawRect(
        brush = Brush.verticalGradient(
            0f to c, 0.4f to c, 0.4f to Colors.Transparent, 1f to Colors.Transparent,
            tileMode = TileMode.Repeated, endY = 10f
        ),
        blendMode = blend
    )
}

Добавляем их поверх слоя:

.drawBehind {
    layer {
        drawLayer(graphicsLayer)
        drawScanLines(alpha = 1f, blend = BlendMode.DstOut)
    }
}

DstOut вычитает градиент и создаёт характерный "CRT-срез".

🔹 Размытие и свечение

Для реалистичного свечения рисуем несколько слоёв с разным blur/scale/alpha:

val blurLayers = listOf(
    Triple(5.dp, .3f, 1.02f to 1.03f),
    Triple(0.dp, .8f, 1f to 1f),
    Triple(10.dp, .6f, 1.001f to 1f),
)

Каждый слой:

Box(
    Modifier
        .matchParentSize()
        .blur(blur, BlurredEdgeTreatment.Unbounded)
        .graphicsLayer { scaleX = scale.first; scaleY = scale.second; this.alpha = alpha }
        .drawBehind {
            layer {
                drawLayer(graphicsLayer)
                drawScanLines(1f, BlendMode.DstOut)
            }
        }
)

🔹 Дрожание экрана

var shake by remember { mutableStateOf(Offset.Zero) }

LaunchedEffect(Unit) {
    while (true) {
        shake = Offset(
            Random.nextFloat() * Random.nextInt(-1, 1),
            Random.nextFloat() * Random.nextInt(-1, 1),
        )
        delay(32)
    }
}

И применяем:

.graphicsLayer {
    translationX = shake.x
    translationY = shake.y
}

🐸 Библиотека мобильного разработчика

#PixelPerfect #MiddlePath #Kotlin

🎮 Почему ваша ViewModel технически нестабильна и почему Compose не возражает

А вы знали, что почти все ViewModels нестабильны?

Когда мы только изучаем Compose,
нас учат использовать стабильный класс, а не нестабильный.

Но ViewModels нестабильны. Так почему же никто ничего не говорит о том, что мы используем нестабильные ViewModels?

🔹 Как Compose определяет стабильность?

Компилятор Compose считает класс стабильным, если:

🔘 Все его свойства (val/var) неизменяемы (val).

🔘 Или их тип «отслеживается» рантаймом Compose (например, MutableState<T>).

Взгляните на примеры:

// Стабильный класс
data class Stable(
    val a: Int, // Стабильно
    val b: MutableState<Int>, // Стабильно, отслеживается Compose
    val c: SnapshotStateList<Int> // Стабильно, отслеживается Compose
)

// Нестабильный класс
data class Unstable(
    var b: Int // Нестабильно из-за `var`
)

// "Неопределенная" стабильность
data class Runtime(
    val i: Interface // Компилятор не знает, какая реализация будет на runtime.
)

Но есть важный нюанс: это правило работает только внутри модуля, где подключен компилятор Compose.

🔹 Что происходит на границах модулей?

Допустим, вы создали стабильную data class в слое данных (data) и внедрили её в ViewModel в слое презентации.

Логично ожидать, что ViewModel тоже будет стабильным. Но на практике — нет!

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

А раз наш ViewModel зависит от репозиториев и UseCase из других модулей (domain/data), то и он сам автоматически становится нестабильным.

🔹 Так почему же нестабильный ViewModel — это норма?

Ответ простой и лежит на поверхности: мы не передаем сам ViewModel в дочерние композаблы.

Вместо этого мы:

1. Создаем ViewModel один раз наверху (например, в NavGraph).

2. Коллектим его состояние (state), которое уже является стабильным.

3. Пробрасываем это стабильное состояние вниз по дереву композиции.

@Composable
fun Screen(viewModel: TestViewModel) { // ViewModel нестабилен, и это ок
    val state by viewModel.state.collectAsState() // Состояние - стабильно

    Child(state) // Передаем стабильный state
}

@Composable
fun Child(state: TestState) { // Стабильный пропс -> рекомпозиции оптимизированы
    Text(state.data)
}

Compose-рантайм следит за изменениями в state. Сам ViewModel как объект не «пробрасывается» глубже и не триггерит лишних рекомпозиций.

🔹 Итоги

🔘 Для монолитных проектов: Это не проблема, компилятор видит все классы и корректно определяет стабильность.

🔘 Для многомодульных проектов: ViewModel почти всегда будет нестабильным из-за зависимостей из других модулей. И это нормально и безопасно, если вы передаете в композаблы не его самого, а его состояние.

Так что можете спать спокойно — с вашим кодом всё в порядке.

🐸 Библиотека мобильного разработчика

#АрхитектурныйКод #MiddlePath #Kotlin