В чатах по KMP часто всплывает вопрос: "Вот я Android разработчик, с чего мне начать изучать про KMP?" и, помимо официальной доки, ответить то было и нечего. Но вот появилась достаточно хорошо структурированная книга (open-source):
https://santimattius.github.io/kmp-for-mobile-native-developers-book/

Внутри примеры кода, разбор структуры и основных фреймворков. Пробовали ли KMP и что посоветуете начинающим?

Упрощенное тестирование ViewModel

Начиная с androidx.lifecycle:lifecycle-viewmodel-testing:2.9.0-alpha01 нам доступна структура ViewModelScenario для проверки того как ViewModel переживает реконфигурацию или восстановление состояния. Пример:

class MyViewModelTest {

  @Test
  fun testStateRestoration() = runTest { // this: TestScope
    viewModelScenario { // this: CreationExtras
        MyViewModel(
          scope = this@runTest,
          handle = createSavedStateHandle(),
        )
    }.use { scenario: ViewModelScenario ->
      // Устанавливаем `ViewModel` state.
      scenario.recreate()
      // Проверяем что state восстановился корректно
    }
  }
}

Совместимо с KMP!

Новая typesafe навигация в Jetpack Compose привносит новые сложности. На деле, все сильно проще. О том как делать вложенную навигацию с BottomNavBar как раз следующая статья. Внутри:

👉 Примеры 2 разделенных графов навигации
👉 Пример основного экрана с BottomNavBar
👉 Судя по всему совместимо с CMP, код будет выглядеть 1 в 1

Не стоит забывать и о документации

Опасности добавления permission READ_MEDIA_IMAGES

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

Про стирание типов!

Если кратко - вся статья про inline reified. Внутри так же примеры для noinline и crossinline. Заметил хороший практический пример про работу с crossinline, который можно было бы спросить на собеседовании на понимание:

inline fun doSomething(action: () -> Unit) {
    println("Start doSomething")
    action()
    println("End doSomething") // This might NOT be printed
}

fun test1() {
    doSomething {
        println("Inside lambda")
        return // This exits test1(), NOT just the lambda!
    }
    println("This will NOT be printed")
}

inline fun doSomethingSafely(crossinline action: () -> Unit) {
    println("Start doSomethingSafely")
    action()
    println("End doSomethingSafely") // This WILL be printed
}

fun test2() {
    doSomethingSafely {
        println("Inside lambda")
        return // This exits ONLY the lambda
    }
    println("This WILL be printed")
}

fun main() {
    println("Running test1:")
    test1() 
    println("\nRunning test2:")
    test2() 
}

Ответ:
test1() // Вывод: Start doSomething, Inside lambda
test2() // Вывод: Start doSomethingSafely, Inside lambda, End doSomethingSafely, This WILL be printed

Ещё немного про Accessibility, но теперь и в Compose

👉 Конечно, про contentDescription, это важно даже для разных состояний кнопок
👉 onClickLabel который помогает вызову TalkBack функции
👉 minimumTouchTargetSize(), если не хотите думать над кастомной областью клика для иконок

Документация про Accessibility: https://developer.android.com/develop/ui/compose/accessibility

Разбираемся в разнице между try-catch и runCatching

👉 runCatching возвращает Result, что позволяет использовать экстеншены с Result и поддерживать функциональный стиль кода
👉 runCatching это скоуп функция, поэтому все возможности скоуп функций доступны
👉 Легко заменить try-catch с пустым catch блоком на runCatching
👉 Проще отлавливать вложенные exception


Зеркало с примерами. С runCatching код выглядит чище и в одном стиле.

Защищаемся от MITM атак

Немного про безопасноть можно почитать тут OWASP Mobile 2024, а что можно предпринять, во избежании проблем:
👉 Использования HTTPS с TLS 1.2, 1.3. Валидные SSL/TLS сертификаты. Использовать HSTS (HTTP Strict Transport Security), который не позволяет свалиться обратно к HTTP

<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">yourdomain.com</domain>
    </domain-config>
</network-security-config>

👉 Certificate Pinning, для предотвращения подмены сертификата. Тут, возможно, надо чуть больше подумать над реализацией, чтобы приложение не сломалось при изменениях сертификата.

val client = OkHttpClient.Builder()
    .certificatePinner(
        CertificatePinner.Builder()
            .add("yourdomain.com", "sha256/your-certificate-hash")
            .build()
    )
    .build()

👉 Использование Strong Network Security Configuration, которое, в целом, дает все преимущества первых двух пунктов, но работает начиная с Android 7.0

<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">yourdomain.com</domain>
        <pin-set>
            <pin digest="SHA-256">your-certificate-hash</pin>
        </pin-set>
    </domain-config>
</network-security-config>

👉 Корректная валидация SSL/TLS сертификатов и отключение поддержки устаревших протоколов.

val sslSocketFactory = SSLContext.getInstance("TLSv1.3").apply { init(null, null, null) }.socketFactory
val client = OkHttpClient.Builder()
    .sslSocketFactory(sslSocketFactory, TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm()).trustManagers[0] as X509TrustManager)
    .build()

Есть ли у вас в проекте TrustManager с доверием к любым сертифкатам без лишних вопросов?

Используем UseCase как функцию из DI

Идея в том чтобы описать функцию, использующую DI для обработки входных данных. В итоге получим тестируемую функцию, которую можно переиспользовать

Пример:

public class GoodReadsUseCase @Inject public constructor(
    private val repository: Repository,
    private val manager: Manager,
    private val clock: Clock
) {

    public suspend operator fun invoke(params: Params): Boolean {
        return someServerLogic
    }
}

Ну а внутри ViewModel это будет выглядеть как то так:

public class ViewModel @Inject constructor(
    private val useCase: GoodReadsUseCase
) {
    public suspend fun read(params: Params) {
         val isBool = useCase(params)
    }
}

Удобно и понятно на что писать тесты! Используем?

HotReload теперь доступен тем, кто работает с Compose

Если вы скучаете по заброшенному и сломанному instant run, или немного завидовали друзьям с Flutter и React Native, которые обновляют UI во время разработки моментально - то теперь и вы так же можете делать с Compose!

Кстати! Недавний опрос показал, что большинство уже успело поработать с Compose, а значит эта фича приятно дополнит ваш рабочий процесс.

HotReload живет в отдельном репозитории: https://github.com/JetBrains/compose-hot-reload

Ныне популярный vibe-coding теперь и в Android Studio благодаря Firebender!

По своей сути, то же самое, что и Cursor, Trae и windsurf, но встроено внутрь Android Studio. Демо для тех кто слышит об этом впервые можно глянуть тут: https://firebender.com/

Это кратно удобнее, чем задавать вопросы в чат. Доступны как популярные модели claude-3.7, так и локально запущенные llm. Пробовали ли на своих проектах работу с AI агентами в паре?

Пишем тесты для compose навигации

Все благодаря type-safe навигации, представленной недавно. Внутри статьи вариант для старого подхода и способ миграции его на новый подход. Для тестов используется TestNavHostController, позволяющий верифицировать экран на котором находимся. Пример:

    @Test
    fun whenUserIsInBookSearch_andClickOnABook_verifyDestinationIsBookDetail() {
        // User is in BookSearch
        composeTestRule.runOnUiThread {
            navController.setCurrentDestination(NavigationRoutes.BOOK_SEARCH)
        }

        // User clicks on the first book
        composeTestRule.onAllNodesWithTag(bookCardTestTag)[0].performClick()
        assertTrue { navController.currentDestination?.route == NavigationRoutes.BOOK_DETAIL }
    }

Выглядит очень просто, в связи с чем вопрос: Тестирование навигации это тесты ради тестов или валидный способ проверки бизнес-логики?

Анализируем время сборки и рисуем графики

👉 Базовый Build Analyzer из Android studio покажет куда тратиться основная масса времени в сборке.
👉 Аналогичный репорт можно получить через ./gradlew --profile assemble[Flavor]Debug.
👉 Так же скан можно выгрузить в web и пошарить с коллегами через ./gradlew --scan. Там вы увидите более подробную разбивку по затраченному времени на тот или иной шаг сборки
👉 Gradle Profiler и благодаря его удобной функции - сценарии, можно получить наглядную статистику. Больше примеров тут

Ищем ненужные зависимости в Dagger/Hilt графе

В большом проекте - большой граф зависимостей компонентов, с лишними инжектами. Проблема решается с помощью Dagger SPI.
Автор предлагает с помощью SPI строить полное дерево зависимостей, а затем вытаскивать наружу неиспользуемые инжекты.

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

Дебажим корутины прямо в Android Studio

Дебажить асинхронщину это всегда проблема. Предлагается 3 способа:
👉 Классическое логирование println( “${msg} | currentThread: ${Thread.currentThread().name}”)
👉 VM option в конфигурации при запуске сборки: -Dkotlinx.coroutines.debug
👉 При помощи DebugProbes можно получить состояние корутины в ходе тестов. Более подробно внутри статьи (Option 4)

Очень тихо зарелизилось мощное улучшение для App Distribution - AI testing agent. Как по мне, это самое полезное для Android разработки из последних релизов в области AI. Кратко:

The App Testing agent is a test case generation, management, and execution agent powered by Gemini in Firebase. You define test goals in natural language, and the agent uses AI to understand and navigate your app, simulate user interactions, and provide detailed test results.

Прошли времена описания тестов на естественном языке (Gherkin + Cucumber). Выглядит все оч просто - вы задаете название, цель, подсказки и критерии приемки. Тесты запускаются в облаке на девайсах.