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

#КодКрашТест #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