Jetpack Compose *

Меня зовут Родион, и я уже около 2,5 лет работаю в VK Android-разработчиком в крупном многомодульном проекте с сотнями экранов и довольно большой аудиторией. Когда я попал на проект, стек был классическим и проверенным: XML-вёрстка, навигация через Cicerone, Dagger 2 для DI, Coroutines и Flow для асинхронщины, а в качестве архитектурного паттерна — MVVM. 

Рано или поздно любая растущая кодовая база упирается в потолок своих архитектурных решений. У нас этот момент настал, когда количество экранов выросло до нескольких сотен и команда начала тратить больше времени на борьбу с неконсистентным состоянием UI. Классическая связка XML + ViewBinding + MVVM работала, но с каждым новым экраном мы всё острее чувствовали её ограничения: разрозненные StateFlow, дублирование кода во фрагментах, сложность переиспользования компонентов. 

Нужно было что-то менять — пересмотреть сам подход к построению UI. Так мы начали миграцию на Jetpack Compose (который на момент начала перехода уже был стабильным и самодостаточным). Полтора года спустя, пройдя через рефакторинг базовых классов, переход с MVVM на MVI и постепенную замену содержимого всех фрагментов, мы получили стек, на котором разработка ускорилась, а баги, связанные с состоянием экрана, практически исчезли. 

Полный переход на Jetpack Compose мы разделили на три больших этапа:

- переписываем содержимое всех фрагментов на ComposeView;

- переходим с Dagger2 на Koin;

- меняем навигацию с Cicerone на Compose-навигацию.

О втором и третьем этапах кратко расскажу ниже —  в главе стратегии перехода, а на первом этапе остановлюсь подробнее.

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

Сейчас рынок переживает не лучшие времена. Уже несколько лет заблокированы основные магазины приложений. В последнее время сильно участились кибератаки на приложение банков. Но технологии могут решить эти проблемы.

В этой статье я расскажу про:

·       Наш топ технологий

·       Как улучшить кибербезопасность в приложении

·       Последние функциональные тренды

Наш топ технологий

Swift – 5 звезд

Keychain и биометрия Face ID/Touch ID работают на уровне аппаратного шифрования, и разработчикам не нужно придумывать велосипед для защиты платежей. Swift дает производительность, идеальную работу с камерой для сканирования карт и чеков, и дает полный доступ ко всем API устройства.

Для банков важна не столько скорость разработки, сколько то, чтобы под каждую платформу были свои решения. Потому что Google или Apple могут что-то менять, и, допустим, в App Store потребуется внести обходы, дополнительные функции или модификации. Технически это можно сделать и на кроссплатформе, но если банк хочет поддерживать имидж и безупречную работу, ему нужно идеальное соответствие каждой платформе. Поэтому до сих пор во многих банках основная часть приложений пишется на нативе: для Apple — Swift, для Android — Kotlin.

Поэтому при использовании Swift компании нужно также иметь отдельную команду для разработки на Android. Поэтому стоимость разработки повышает и сразу две команды делают одно и тоже.

Когда старый монолит начинает мешать процессам в разработке, первое, что обычно приходит в голову командам — это переезд на новый стек. Логика понятна: сделаем новый UI, почистим код, а дальше и разработка пойдет бодрее. Чаще всего такое решение — очень дорогая иллюзия. Потому что в бигтехе проблема обычно не в UI, а в связности компонентов, зависимости фронта от бэка, сложных релизах и фичах, которые требуют синхронной работы команды.

Мы — разработчики Surf, Android и iOS команды: Светлана Сорокина, Антон Бояркин и Алексей Рябков. Когда начали работать с Бургер Кинг над трансформацией приложения, столкнулись с похожей историей. Поэтому мы решили переписать архитектуру так, чтобы разные подрядчики могли нормально работать вместе, а продукт — развиваться быстрее.

Технологии Backend-Driven UI уже давно используются во многих компаниях, включая Альфа-Банк. Существует множество реализаций этого подхода, и недавно Google представил собственное решение — Remote Compose.

Remote Compose выглядит очень перспективной технологией. Фреймворк активно развивается и поддерживается командой Google. Однако на момент написания статьи технология всё ещё находится в alpha-версии, поэтому использовать её на проде пока рано. 

Но я изучил этот фреймворк и хочу поделиться своим опытом, а когда Remote Compose выйдет в бета-версию вы будете знать, как с ним работать

В статье разберём:

•  общую концепцию Remote Compose,
•  чем он отличается от классического BDUI,
•  какие интересные технические решения используются внутри,
•  несколько практических примеров использования.

Как я без Mac, с помощью Claude AI и GitHub Actions, создал кроссплатформенное приложение для шифрования сообщений поверх любого мессенджера. Android на Kotlin, iOS на Swift без MacBook, десктоп на Python. AES-256, три платформы, два отказа от Apple и один баг с буквой «а».

Привет, Хабр! Я Витя Строеску, последние пять лет в свободное от отдыха время занимаюсь разработкой под Android, три из которых — в команде мобильного оператора Т-Мобайл.

Поделюсь с вами опытом попытки конфигурации анимаций для айтемов у Compose LazyColumn. Мы переписывали наш главный экран с XML+View на Jetpack Compose, который состоит из списка с различного рода сложности айтемами.

В статье разберем, почему возникает рассинхрон, как устроен механизм анимаций внутри LazyColumn, почему кастомный animateItem обречен с самого начала и к какому решению мы пришли в итоге.

До пятой версии главный экран был функциональным, но визуально скучным. Типичный Material Design без характера. Я получил несколько честных отзывов — в том числе жёстких — и решил переделать всё.

Это не очередной TODO-лист и не очередной трекер расходов. Это комбайн, в котором живут задачи, заметки, бюджет, аналитика, помодоро-таймер и цели накоплений

Как я добавил 10 фич в Android-приложение за один заход: Todo Budget v4.0

Привет, Хабр! Продолжаю серию о разработке Todo Budget — Android-приложения, объединяющего задачи, бюджет, заметки и помодоро-таймер в одном месте.

Меня зовут Вячеслав, и я — «процессуальный хирург».
Сейчас адвокат. Из них 20 лет я провел по ту сторону баррикад — работал следователем, помощником прокурора и прокурором.

Моя работа в суде — не красивые речи, а поиск багов. Я берусь за дела, где система дала сбой: следствие допустило ошибку, суд закрыл глаза. Я провожу аудит материалов, нахожу фатальное нарушение (баг в процедуре) и «ломаю» приговор. Я не работаю ради процесса — я либо вижу техническую возможность отмены, либо честно говорю клиенту: «Тут WontFix».

Год назад я понял, что мне нужен инструмент, который работает так же бескомпромиссно, как я сам. Мне нужен был цифровой ассистент...

Представьте классический сценарий в мобильном приложении: пользователю нужно выбрать год рождения, час будильника или количество товаров в корзине. На iOS для таких случаев давно существует элегантное и интуитивное решение - Wheel Picker (или UIPickerView). Этот компонент стал неотъемлемой частью языка дизайна Apple. В этой статье я расскажу вам, как реализовать такой же компонент в Android.

Приготовьтесь, будет много математики!

В этой статье я бы хотел поделиться своими наработками по тому, как можно удобно совмещать библиотеку Navigation3 и Koin в Compose Multiplatform проекте и какие подводные камни есть на текущий момент.

Анимация смены темы в Android-версии Telegram на протяжении долгого времени вдохновляет разработчиков на попытки реверс-инжениринга этого красивого трюка: в сети немало подробных гайдов, как сделать подобную анимацию при помощи традиционных XML View и даже Flutter. Но реализаций этой элегантной (хоть и совершенно бесполезной) анимации на Jetpack Compose мне найти так и не удалось, что привело к созданию маленькой библиотеки для анимирования смены темы.

Вера в будущее KMP также подтолкнула меня к тому, чтобы сделать ее из коробки готовой к установке в Compose-Multiplatform проекты, с поддержкой всех основных платформ (Android, iOS, Desktop JVM, Web WASM+JS).

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

На старте написания библиотеки сами собой возникли ряд требований, которым она должна была отвечать:

Привет, Хабр! Меня зовут Иван Кузнецов, я Android‑разработчик в Кинопоиске. В прошлой статье я научил Jetpack Compose показывать рекомпозиции в реальном времени, но это был скорее учебный стенд: куча модификаторов, обёрток и примеры, которые нужно готовить вручную.

Я хотел чего‑то более полезного: чтобы IDE сама показывала, какие composable‑функции перерисовываются прямо сейчас, а какие скипаются и какие параметры реально меняются. Нажал Run — и редактор превратился в живую тепловую карту UI.

Ради этого пришлось сделать то, чего нормальные люди обычно избегают: залезть под капот Kotlin Compiler Plugin и научиться внедрять код в промежуточное представление на этапе компиляции, разобраться в битовых масках Compose и поднять TCP‑сервер внутри IntelliJ, чтобы запущенное приложение могло стучаться прямо в IDE.

Так появился Riflesso — плагин, который переносит идею Layout Inspector прямо в редактор кода и делает Compose прозрачным. В этой статье я разберу его архитектуру и покажу, как компилятор, клиентская библиотека и плагин IDE собираются в один инструмент.

Скриншот-тестирование — это метод автоматической проверки пользовательского интерфейса на визуальные регрессии. В этой статье — практическое руководство по внедрению такого подхода в Android-приложение с использованием библиотеки Roborazzi. Рассмотрим базовую настройку, интеграцию с CI, а затем расширим возможности тестов с помощью кастомизации Roborazzi.

Всем привет! Меня зовут Сергей, и я Backend Kotlin разработчик в компании занимающейся разработкой систем повышающую безопасность дорожного движения. И я расскажу, как мы с помощью Jetpack Compose и GitLab API упростили процесс деплоя на 100+ распределённых серверов, повысив при этом удобство и предсказуемость процесса.

Разрабатывая приложение под Android — мы встроили в продукт свой мессенджер и решили, что стандартные андроидные смайлики — это преступление против дизайна. Telegram и другие популярные мессенджеры давно показали, как должны выглядеть эмоции в чате, а Google всё ещё живёт в 2015-м с Noto Color Emoji.
Хотели просто подменить парочку 😎👩‍💻🙂 на свои красивые… И получили войну: курсор, который живёт своей жизнью, тофу, кернинг и полный хаос при вводе.
Эта статья — история о том, как мы прошли все круги ада и всё‑таки победили систему.

Спойлер: победили костылями.

🚀 Хотите создать регистрацию в стиле Google для своего Android-приложения? 🚀

Забудьте о скучных формах! Погрузитесь в мир плавной анимации, интуитивного дизайна и надежной безопасности – всё это с помощью Kotlin и Jetpack Compose.

✨ Что вас ждет:

Пошаговый гайд: От первых строк кода до готового результата – разберемся вместе.

Рабочий код: Не просто теория, а готовые решения для вашего проекта.

Комментарии эксперта: Поймете каждый шаг и сможете адаптировать код под свои нужды.

Секреты профессионалов: Узнаете, как сделать регистрацию не только функциональной, но и привлекательной.

💪 Не упустите шанс прокачать свое приложение! 💪

Когда только начинаешь разрабатывать под Android, самые неприятные баги появляются не из-за опечаток, а из-за систематических ошибок. Хардкод строк и цветов, корутины, которые живут сами по себе, попытки писать Compose по старинке, как старые view — всё это превращается в технический долг, который мешает развивать продукт. 

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

Вот и время для заключительной статьи этого цикла. В предыдущих статьях мы рассмотрели нашу мотивацию, всю техническую информацию и поделились инсайтами при создании масштабируемого бизнес-решения в виде кроссплатформенного SDK. В этой небольшой статье хотелось уделить внимание иным аспектам, таким как адаптация процессов команды KMP и смежных команд, которые являются заказчиками, немного поговорить про подходы к тестированию и контролю качества, CI/CD и т.д.

Кратко напомним про контекст и продукт: Instories — мобильный видеоредактор для маркетологов, SMM-специалистов и блогеров. Контекст проекта: желание получить ряд SDK (мы называем их Kit-ами, по сути это разные сборки SDK для разных продуктов, со своими ресурсами, фичами и дизайн системой) для наших уже существующих приложений, которые содержали бы в себе коробочные фичи (и бизнес-логику, и UI), готовые к подключению, а также были бы легко расширяемыми и переиспользуемыми для разных приложений компании.