🗑 «Пишу чистый код» и еще 50 фраз, из-за которых ваше резюме летит в корзину

Рекрутеры видят одно и то же в каждом втором резюме: «командный игрок», «работаю с современными технологиями», «обладаю аналитическим складом ума». Эти клише не просто скучны — они ставят под сомнение вашу компетентность.

Разбираем 50+ шаблонных фраз по всем IT-направлениям и показываем, как их заменить или вообще выкинуть.

👉 Читать статью

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

#MadeInProglib

🗓 Новости недели

Приготовили для вас дайджест по актуальному из мира iOS, Android и кроссплатформы.

🔵 Делаем анимацию отрисовки для SF Symbols в SwiftUI

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

🔵Всё о функциях Swift Package Manager

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

🔵 Почему моё Android-приложение крашится?

Если вы Андроид-разработчик, думаю, вам часто приходилось сталкиваться с ситуациями, когда код вашего приложения выбрасывает необрабатываемое исключение и ваше приложение закрывается. На сленге можно сказать, что «приложение крашится».

🔵 Что такое SupervisorJob в корутинах Kotlin

Из этой статьи вы узнаете, что такое SupervisorJob, как он работает и какие реальные примеры использования есть в viewModelScope и RevenueCat SDK.

🔵 Flutter Web глазами мобильного разработчика

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

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

#свежак

🤡 Побочные эффекты в Jetpack Compose — простое объяснение

В Jetpack Compose не рекомендуется напрямую вызывать не-компонуемые функции внутри composable-функций.

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

Эти обработчики позволяют безопасно взаимодействовать с внешним миром (сеть, база данных, логи и т. д.) в контролируемом виде.

Ниже приведены самые распространённые обработчики эффектов в Compose — просто и с примерами.

🔹 SideEffect

Выполняет логику после каждого успешного пересоздания (recomposition).

SideEffect {
    Log.d("TAG", "Recomposition completed")
}

Подходит для логирования, аналитики или любых операций, которые должны выполняться после отрисовки интерфейса.

🔹 LaunchedEffect

Запускает корутину, когда изменяется указанный ключ. Если происходит пересоздание и ключ меняется — предыдущая корутина отменяется, и запускается новая.

LaunchedEffect(key1 = someState) {
    fetchData()
}

Идеально подходит для вызова API или выполнения логики, зависящей от изменяющегося состояния.

🔹 rememberCoroutineScope

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

val coroutineScope = rememberCoroutineScope()
Button(onClick = {
    coroutineScope.launch {
        doSomething()
    }
}) {
    Text("Click me")
}

Для событий, инициируемых пользователем, которые не зависят напрямую от состояния или жизненного цикла.

🔹 DisposableEffect

Выполняет код при входе в композицию и очищает ресурсы при выходе из неё.

DisposableEffect(key1 = someKey) {
    startListening()

    onDispose {
        stopListening()
    }
}

Добавление или удаление слушателей, наблюдателей, освобождение внешних ресурсов и другая логика очистки.

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

#буст #JuniorKit #Android

🔒 Основные сценарии использования Mutex в Kotlin

Когда несколько корутин обращаются к общим данным или ресурсам одновременно, возникает риск гонок данных (race conditions).

Mutex (mutual exclusion) — это инструмент синхронизации, который помогает управлять доступом к общим ресурсам, гарантируя, что в один момент времени их изменяет только одна корутина.

Вот самые частые примеры, когда Mutex действительно нужен:

1️⃣ Защита разделяемого изменяемого состояния

Самый распространённый случай — безопасный доступ к общей переменной:

class CounterService {
    private var counter = 0
    private val mutex = Mutex()
    
    suspend fun increment() {
        mutex.withLock {
            counter++
        }
    }
    
    suspend fun getCount(): Int {
        return mutex.withLock {
            counter
        }
    }
}

2️⃣ Координация доступа к ресурсу

Когда несколько корутин должны поочерёдно работать с общим ресурсом:

class FileWriter(private val file: File) {
    private val mutex = Mutex()
    
    suspend fun appendLine(line: String) {
        mutex.withLock {
            file.appendText("$line\n")
        }
    }
}

3️⃣ Обеспечение последовательного выполнения

Когда операции должны выполняться строго по порядку, даже если запущены одновременно:

class OrderProcessor {
    private val mutex = Mutex()
    private val orders = mutableListOf<Order>()
    
    suspend fun processOrder(order: Order) {
        mutex.withLock {
            // Обеспечиваем последовательную обработку заказов
            orders.add(order)
            validateOrder(order)
            persistOrder(order)
        }
    }
}

4️⃣ Отложенная инициализация с защитой потоков

Обеспечивает безопасную инициализацию ресурса в асинхронных контекстах:

class DatabaseConnection {
    private var connection: Connection? = null
    private val mutex = Mutex()
    
    suspend fun getConnection(): Connection {
        if (connection != null) return connection!!
        
        return mutex.withLock {
            // Повторная проверка внутри блокировки
            connection ?: createConnection().also { connection = it }
        }
    }
    
    private suspend fun createConnection(): Connection {
        delay(1000) // Симуляция установки соединения
        return Connection()
    }
}

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

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

📱 Эмулятор vs реальное устройство

Каждый мобильщик знает этот момент: проект собран, пора тестить. И вот тут начинается священная война.

Одни запускают на эмуляторе — быстро, удобно, без лишних проводов. Другие достают свой старенький Pixel или iPhone SE, потому что «только на реальном девайсе видно настоящие лаги».

А вы на чьей стороне? 💬

❤️ — эмулятор
👍 — реальное устройство

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

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

🎁 Топ вакансий для мобильных разработчиков за неделю

Senior Android-разработчик в Маркетплейс —‍ удалёнка

Flutter-разработчик —‍ от 250 000 ₽, гибрид (Москва)

Senior IOS-разработчик —‍ от 350 000 ₽, удалёнка

Team Lead Backend Developer —‍ от 350 000 ₽, удалёнка

Team Lead Mobile Developer (Flutter) —‍ от 5 500 до 7 000 $, удалёнка

➡️ Еще больше топовых вакансий —‍ в нашем канале Mobile jobs

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

#свежак

🔍 Управление навигацией в SwiftUI с помощью NavigationPath

NavigationStack и NavigationPath в SwiftUI предоставляют мощный и гибкий способ выполнять программную навигацию в приложении. Когда вы управляете навигацией, часто возникает необходимость программно открывать (push) и закрывать (pop) экраны. NavigationPath позволяет делать это, сохраняя типобезопасность и гибкость.

🔹 NavigationStack(root:)

Инициализатор по умолчанию задаёт корень навигационной иерархии и управляет путём навигации “за кулисами”. Если вы хотите получить больший контроль и управлять навигацией программно, можно хранить путь в переменной @State и передавать его в инициализатор NavigationStack(path:root:).

Параметр path должен быть Binding<Data>, и есть два способа его использования.

1️⃣ Типобезопасная навигация

Первый способ — использовать массив определённого типа, который реализует протокол Hashable. Это удобно, если весь стек навигации основан на одном типе данных.

@State private var path: [Color] = []

NavigationStack(path: $path) {
    List {
        ForEach(colors, id: \.self) { color in
            Button {
                path.append(color)
            } label: {
                ...
            }
        }
    }
    .navigationDestination(for: Color.self) { color in
        VStack {
            color
            ...
            Button("Pop to root") {
                path.removeAll()
            }
        }
        ...
    }
}

В примере выше навигационный стек поддерживается массивом объектов Color, который выступает в роли NavigationPath. Каждый раз, когда элемент добавляется в path, модификатор navigationDestination(for:) показывает соответствующий экран. Вызов path.removeAll() очищает стек и возвращает пользователя к корневому экрану.

Этот подход идеально подходит для чистой, типобезопасной навигации с минимальной настройкой, особенно если вы работаете с одним типом данных.

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

2️⃣ Универсальный NavigationPath для нескольких типов

Если навигационный стек может содержать разные типы данных (например, Color, String или пользовательские типы), лучше использовать NavigationPath. Он работает как type-erased список данных, но при этом сохраняет достаточно информации, чтобы SwiftUI знал, какой экран показать для каждого типа.

@State private var path = NavigationPath()

NavigationStack(path: $path) {
    List {
        Section("Colors") {
            ForEach(colors, id: \.self) { color in
                Button {
                    path.append(color)
                } label: {
                    ...
                }
            }
        }
        Section("Genres") {
            ForEach(genres, id: \.self) { genre in
                Button {
                    path.append(genre)
                } label: {
                    ...
                }
            }
        }
    }
    .navigationDestination(for: Color.self) { color in
        VStack {
            ...
            Button("Pop to root") {
                path.removeLast(path.count)
            }
        }
        ...
    }
    .navigationDestination(for: String.self) { genre in
        VStack {
            ...
            Button("Pop to root") {
                path.removeLast(path.count)
            }
        }
        ...
    }
}

С NavigationPath вы можете добавлять разные типы данных в стек. Для каждого типа нужно задать отдельный navigationDestination(for:destination:), чтобы описать, как отображать соответствующий экран.

Если вы добавите значение в NavigationPath, но не определите navigationDestination для его типа,
ошибки компиляции не будет — однако пользователь увидит пустой экран с предупреждением.

Такой подход более гибкий, особенно для приложений, навигация в которых зависит от различных моделей данных.

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

#PixelPerfect #MiddlePath #SwiftUI

❓ Какой тип находится на вершине иерархии типов в Kotlin

Аналогично Object в Java, к чему можно привести любой тип в Kotlin?
Правильным ответом будет Any?.

Сам по себе класс Any это почти аналог Object, однако, благодаря поддержке nullable и не-nullable типов в Kotlin мы получили Any?. Фактически, Any? соответствует любому типу и null, а Any только любому типу.

Если по порядку:

1. Any является корнем иерархии не-nullable типов.

2. Any? является корнем иерархии nullable типов.

3. Так как Any? является супертипом Any, то Any? находится в самом верху иерархии типов в Kotlin.

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

#буст #JuniorKit #Android