Jetpack Compose *

Технологии 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), готовые к подключению, а также были бы легко расширяемыми и переиспользуемыми для разных приложений компании.

В предыдущих статьях мы рассматривали технические и архитектурные аспекты при создании Kotlin Multiplatform SDK, но немаловажной частью остается работа с UI и ресурсами в таком SDK, особенно если он поставляется сразу в несколько продуктов.

Да, в Compose Multiplatform есть базовая работа с ресурсами: можно работать со строками, картинками и файлами по аналогии с Android проектами, однако что делать, когда для каждого продукта под одним и тем же ключом локализации должна срываться своя строка? В этой статье мы поделимся своим подходом и инсайтами.

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

В предыдущих статьях (раз и два) мы рассмотрели, почему выбрали Kotlin Multiplatform для нашего SDK, а также подробно разобрали базовую архитектуру проекта, включая core-модули и организацию Kit-ов. Теперь настало время погрузиться в самое интересное — архитектуру отдельной фичи и то, как мы организовали взаимодействие между модулями.

Эта статья будет особенно полезна тем, кто хочет понять, как на практике реализовать feature-first подход в KMP проекте, как правильно организовать DI, навигацию и работу с ресурсами в многомодульной архитектуре.

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

В прошлой статье было много текста о том, почему мы стали смотреть в сторону кроссплатформенной разработки и почему мы в Instories выбрали именно Kotlin Multiplatform (далее — KMP) для своего решения.

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

Мы выбрали использовать многомодульную архитектуру, чтобы каждая фича была инкапсулирована в своем модуле и не влияла на другие фичи, а также разделили проект на несколько крупных пакетов: kits, core и feature. В данной статье мы рассмотрим первые два пакета с технической точки зрения, а также поделимся причинами и инсайтами для выбранных решений.