Доброе утро! Google начал рассылать письма счастья о необходимости поддержки 16kb page и дедлайне 1 ноября. Если у вас есть аккаунт разработчика - проверяйте состояния ваших приложений!

Более подробно писали вот тут: https://android-developers.googleblog.com/2025/05/prepare-play-apps-for-devices-with-16kb-page-size.html

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

Заменил я ее связкой Roborazzi (robolectric) + Compose Preview Scanner.

В чем идея:
Robotazzi в целом умеет в скриншот тестирование хорошо, но для этого надо писать тесты, а я не хочу! Я хочу лениво, у меня ведь много превьюшек моих компонентов в коде.

Compose Preview Scanner как раз и закрывает эту проблему, сканируя вашу androidMain/screenshotTest/commonMain (да! да! Поддерживает даже CMP) директорию на наличие превьюшек. В самих репозиториях исчерпывающий гайд, но я очень рекомендую посмотреть на примеры реализации

Про автоматизацию Roborazzi тестов почитать можно тут

Опасности Jetpack Compose State

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

👉 Вы использовали remember, но как только экран покрутили - данные потерялись
👉 В приложении LazyColumn дергается на обновлении данных
👉 При навигации между экранами стейт теряется
👉 Любое обновление состояние вызывает полную рекомпозицию дерева

Не рекламы ради, а рекомендация каналов моих бывших коллег.

@fewideas раньше мы вместе в Ökko работали и Степа был разработчиком, который перешел из разработки в менеджмент. Сейчас он продакт в Авиасейлс

@mazurov_channel мы вместе работали в аутсорсе над мобильными приложениями. Сейчас Марк в Стокгольме и рассказывает как живется разработчику в Швеции

Это уютные авторские каналы, которые я и сам читаю. Рекомендую!

Серия статей про Model View State Machine. "Новый" подход к разработке. Полезно посмотреть как бывает.

👉 Intro
👉 Создавая state машину
👉 Делаем side эффекты (Скоро)
👉 Создаем вложенный state (Скоро)
👉 Используем и переиспользуем state машину (Скоро)

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

Сделал апку offline-first. Какие архитектурные решения применил

👉 API-First → Local-First. Теперь БД это единый источник правды
👉 Синхронизая базы с бекендом. До:

UI -> Вызов API -> Показать результаты

После:

UI -> Сохранить в БД -> Очередь на синхронизацию -> Пуш на сервер (при появление сети)

👉 Разрешение конфликтов. Комбинация из алгоритмов Last Write Wins, Timestamps and Merge, CRDTs. Основная сложность об которую ломаются все offline first приложения
👉 Не забудьте поменять UI, чтобы не запутать пользователя

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

Следующая Canary версия - выдра!

Kotzilla update

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

Доступно как из веб, так и из плагина

Вчера завозил в проект dependabot. Для тех кто не в курсе:
Автоматическое обновление зависимостей с прогоном ваших CI actions в гихабе. Позволяет снять головную боль и забыть про регулярное обновление зависимостей, слежкой за минорными версиями. Поддерживает gradle version catalog

Пару лет назад даже писал статью в linkedin об этом

Немножко годноты с последней Preview для Android Studio

Отдельный функционал для:
- Генерации экрана со скриншота
- Возможности доработки изменений на скриншоте
- Фиксов ошибок
- Превью и фиксов превью ошибок

Кстати, теперь можно использовать локальные модели, если Gemini недоступен или не хочется за него платить

По клику на гифку открывается нормальная ее версия

Visiblity API в Compose 1.9

Представили новые модификторы для отслеживания видимости элементов: onVisibilityChanged, onFirstVisible

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

// onVisibilityChanged
LazyColumn {
  items(feedData) { video ->
    VideoRow(
        video,
        Modifier.onVisibilityChanged(minDurationMs = 500, minFractionVisible = 1f) {
          visible ->
            if (visible) video.play() else video.pause()
          },
    )
  }
}

// onFirstVisible
LazyColumn {
    items(100) {
        Box(
            Modifier
                // Log impressions when item has been visible for 500ms
                .onFirstVisible(minDurationMs = 500) { /* log impression */ }
                .clip(RoundedCornerShape(16.dp))
                .drawBehind { drawRect(backgroundColor) }
                .fillMaxWidth()
                .height(100.dp)
        )
    }
}

До нового апи мы парсили стейт для получения того же функционала:

LaunchedEffect(listState) {
    snapshotFlow { listState.layoutInfo.visibleItemsInfo.map { it.key }.toSet() }
        .collect { visibleIds ->
            // Сравнение с предыдущим состоянием и получение колбека
        }
}

Оффициальный анонс: https://android-developers.googleblog.com/2025/08/whats-new-in-jetpack-compose-august-25-release.html

В версии 1.9.2 поправили баг с пропавшими ивентами смены состояния

Ваш лучший мобильный разработчик - медленный

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

👉 Рассматривают 2 типа разработчиков. Первый быстро решает задачи, продакты им довольный, не задает лишних вопросов. Растит продукт с точки зрения бизнеса. Второй работает медлено, постоянно все уточняет, рисует диаграммы и пишет "никому не нужные" тесты.

👉 Учитывают экономику скрытых дефектов, и покрытие тестами для предотвращения потерь. Вложение в архитектуру, как снижение стоимости изменений. Менторинг как вложение в команду. Коммуникация, как предотвращение переписывания кода.

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

👉 Предлагают мерять продуктивность разработки через SPACE и DORA

К какой стороне вы себя относите?