⚙️ Новый API `retain` в Compose: сохраняем сложные объекты при смене конфигурации

Compose 1.10 представляет новую функцию retain, которая заполняет важный пробел между существующими API управления состоянием. Теперь можно сохранять объекты между изменениями конфигурации без необходимости их сериализации!

- remember — сохраняет между рекомпозициями ❌ смена конфигурации
- rememberSavable — сохраняет между пересозданиями активити ⚠️ требует сериализации
- retain — сохраняет при смене конфигурации ✅ без сериализации ❌ не работает при убийстве процесса

@Composable
fun MediaPlayer() {
    val applicationContext = LocalContext.current.applicationContext
    
    // ExoPlayer будет сохранен при повороте экрана
    val exoPlayer = retain { 
        ExoPlayer.Builder(applicationContext)
            .setSeekBackIncrementMs(5000)
            .setSeekForwardIncrementMs(5000)
            .build()
    }
    
    // Воспроизведение не прервется при смене конфигурации
    DisposableEffect(Unit) {
        onDispose { exoPlayer.release() }
    }
    // ...
}

Под капотом сохранение объекта происходит через механизм ViewModel и имеет такой же цикл жизни

Фича разработана при активном участии AndroidDev-сообщества, особенно команды Circuit. Отличный пример того, как обратная связь разработчиков влияет на развитие платформы!

#Compose #AndroidDev

⚙️ Dejavu — тесты на рекомпозицию в Compose

Мэтт МакКенна выпустил библиотеку, которая превращает рекомпозиции в обычные test assertions. Dejavu решает проблемы постоянного мониторинга за рекомпозияцими без изменений в продакшн-коде — только Modifier.testTag(), который скорее всего у вас уже есть:

// Пример теста
@get:Rule
val composeTestRule = createRecompositionTrackingRule()

@Test
fun incrementCounter_onlyValueRecomposes() {
    composeTestRule.onNodeWithTag("inc_button").performClick()

    composeTestRule.onNodeWithTag("counter_value")
        .assertRecompositions(exactly = 1)

    composeTestRule.onNodeWithTag("counter_title")
        .assertStable() // ноль рекомпозиций
}

Когда тест падает, получаете структурированный отчёт:

UnexpectedRecompositionsError: testTag='product_header'
  Composable: demo.app.ui.ProductHeader (ProductList.kt:29)
  Expected: exactly 0 recomposition(s)
  Actual: 1 recomposition(s)

  All tracked composables:
    ProductListScreen = 1
    ProductHeader     = 1  <-- FAILED
    ProductItem       = 1

  Recomposition timeline:
    #1 at +0ms — param slots changed: [1] | parent: ProductListScreen

  Possible cause:
    1 state change(s) of type Int
    Parameter/parent change detected (dirty bits set)

Видно какой composable, сколько раз рекомпозировался и почему. Под капотом используется CompositionTracer API из compose-runtime 1.2.0, никаких Gradle-плагинов и байткод-манипуляций. Запускается как instrumented тест.

🐱 Dejavu Github

#Android #AndroidDev #Compose #JetpackCompose

⚙️ Анимации в Jetpack Compose LazyColumn: почему это сложнее, чем кажется

Наткнулся на отличный разбор от ребят из Т-Банка — они переписывали главный экран с XML+View на Compose и столкнулись с проблемой, которую многие, думаю, обходят стороной.

Суть: есть LazyColumn, в нём элемент с animateContentSize(). Когда элемент расширяется по высоте, нижние карточки не успевают сместиться в такт — небольшой, но заметный рассинхрон.

Казалось бы — поменяй spring на tween, синхронизируй тайминги и готово. Спойлер: нет.

1️⃣ Замена на линейный tween — разницы визуально почти ноль. Скорость placementSpec тоже не влияет на смещение нижних айтемов при ресайзе верхнего.

2️⃣ Установка placementSpec = null — синхронизация появляется, но полностью ломает анимацию перемещения айтемов. Не вариант.

3️⃣ Попытка написать свой модификатор — обречена с самого начала. LazyLayoutAnimationSpecsNode помечен как internal, а внутренний LazyLayoutItemAnimator, который реально управляет анимациями, недоступен снаружи. Скопировать код не выйдет — каст по типу вернёт null, и вся механика рассыпается. Форкать 5000+ строк LazyColumn — очевидно нет.

Самое интересное — анимация удаления при кастомной реализации не работает в принципе: к моменту DisposableEffect.onDispose элемент уже удалён из дерева. А стандартный animateItem работает на уровне layout-фазы и может буквально «удерживать» элемент в дереве до окончания анимации.

Итог у команды — оставили RecyclerView для списка, айтемы внутри на Compose. Костыль, но рабочий, пока Google не откроет нужные API. Issue уже создан, подписывайтесь если сталкивались.

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

#Android #Compose #AndroidDev #JetpackCompose #Анимация

🐱 Tracey - чёрный ящик для Compose-приложения

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

Не сразу понял куда её применить, но пришла идея интеграции в флоу автоматического прокликивания экрана:

Разрабатываешь фичу локально, кликаешь руками, что-то идёт не так. Вместо того чтобы объяснять разработчику или агенту на словах "я нажал сюда, потом перешёл туда, потом кнопка не сработала" — просто скидываешь ему дамп сессии из Tracey. Он сам восстанавливает картину и сразу работает с контекстом, а не с твоим пересказом.

Структурированный контекст для дебаг-сессии с агентом, чтобы дать четкую информацию.

Библиотека на версии 0.0.2, только вышла, в продакшен пока не потащу. Но для этапа разработки и связки с AI-агентами идея выглядит рабочей.

#Compose #Android #AndroidDev

🐱 Kompass — ещё одна навигация для Compose Multiplatform

Да, у нас уже есть Jetpack Navigation 3 с официальной поддержкой KMP. Тем не менее авторы Kompass смотрят на проблему иначе, и идея тут любопытная.

Суть в том, что вся навигация строится на чистых редукторах. Любой переход — это State + Command → State, без побочных эффектов. Вот как это выглядит в коде:

// Граф описывает, какие экраны в нём живут и как рендерятся
class MainNavigationGraph : NavigationGraph {
    override fun canResolveDestination(id: String) =
        id in setOf("home", "profile")

    @Composable
    override fun Content(entry: BackStackEntry, destination: Destination, navController: NavController) {
        when (destination) {
            is MainDestination.Home -> HomeScreen(navController)
            is MainDestination.Profile -> ProfileScreen(navController)
        }
    }
}

// Хост принимает список графов и рендерит текущий экран
@Composable
fun AppNavigation() {
    val navController = rememberNavController(
        startDestination = MainDestination.Home
    )
    KompassNavigationHost(
        navController = navController,
        graphs = persistentListOf(MainNavigationGraph())
    )
}

// Навигация из экрана
navController.navigate(
    entry = BackStackEntry(destinationId = "profile", scopeId = newScope())
)

// Возврат с результатом
navController.pop(result = ProfileResult(userId = "123"))

NavigationState и BackStackEntry иммутабельны, поэтому всю навигацию можно покрыть обычными unit-тестами без инструментации: создаёшь NavigationHandler, кидаешь команду, проверяешь стейт.

Особенности:
👉 Таргеты — Android, iOS, Desktop (JVM).
👉 Scopes вместо ViewModel. rememberScoped<T> живёт ровно пока BackStackEntry в стеке, автоматически чистится при pop.
👉 Multi-graph. Несколько независимых графов с собственными лейаутами. Из коробки есть поддержка master-detail для планшетов.
👉 Дип-линки. Через DeepLinkHandler — типизированный парсинг URI в NavigationCommand.
🛠 Библиотека ещё в активной разработке

#KMP #ComposeMultiplatform #Navigation #Kotlin #AndroidDev

⚙️ skydoves выпустил Compose HotSwan v2 Beta для Android: заменить весь экран без рестарта приложения

v1 умел одно — применять изменения значений без rebuild: цвет, padding, текст, размеры — результат за секунду, приложение живёт. Добавить composable, переставить layout, поменять control flow — всё это шло в полный rebuild.

v2 убирает эту границу. Без рестарта приложения: добавляем и удаляем composable-функции, меняем структуру layout, переписываем conditional UI. И главное — заменяем целый экран на совершенно другой код. Навигационный стек и remember-состояние сохраняются.

Технически v2 запускает изменения через собственный интерпретатор, обходя ограничения ART на переопределение классов — тот же подход, что у Flutter. При слишком глубоких изменениях деградирует плавно: сбрасывает composition с сохранением rememberSaveable и ViewModel, в крайнем случае рестартит Activity. Полный rebuild нужен только при изменении сигнатур функций, иерархии классов и inline-функций.

В v2 также MCP-сервер: AI-агент триггерит reload, снимает скриншот с устройства, итерирует по вариантам. Claude Code и Cursor работают из коробки через file watcher.

Поставить: IDE-плагин вручную с бета-канала Marketplace + Gradle-плагин 2.0.0-beta01:

[plugins]
hotswan-compiler = { id = "com.github.skydoves.compose.hotswan.compiler", version = "2.0.0-beta01" }

Инструмент платный инструмент, лицензия и цены на hotswan.dev/pricing.

Такого охвата hot reload в нативном Compose ещё не было. Аргумент Flutter про быстрый feedback loop заметно слабеет.

#Compose #JetpackCompose #AndroidDev

⚙️ Новый релиз Material3 Adaptive 1.3.0

Новая библиотека adaptive-navigation3. Теперь можно легко строить адаптивные Material-интерфейсы в связке с Navigation 3. Что внутри:

Scene Strategies
👉 ListDetailSceneStrategy + rememberListDetailSceneStrategy — канонический list-detail
👉 SupportingPaneSceneStrategy + rememberSupportingPaneSceneStrategy — supporting pane
👉 В ListDetailPaneScaffold и SupportingPaneScaffold. Теперь поддерживают margins и edge-to-edge.
🔄 RTL-поддержка для pane expansion.
tive:adaptive-navigation3:1.3.0")

🔗 Полный changelog

#AndroidDev #JetpackCompose #Material3