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

Почему одни приложения мы обожаем, а другие не хотим лишний раз открывать? Почему заходим в Телегу 20 раз на дню, а английский изучаем именно через Дуолинго?

Эта статья для дизайнеров и продактов, которые хотят понять, чем их любимые цифровые продукты отличаются от просто удобных.

В этой статье:

• Когда юикса стало недостаточно?

• Что такое User Joy?

• Зачем нам думать про кайф?

• Как измерять кайфовость?

• С кого брать пример?

• 15 способов достижения кайфа.

• Что поменять в дизайн-процессе?

Всем привет! Меня зовут Юрий Шабалин, я один из основателей компании Stingray Technologies. Мы разрабатываем платформу анализа защищенности мобильных приложений iOS и Android.

Сегодня я хотел бы снова затронуть тему безопасности сетевого взаимодействия между приложением и его серверной частью. На эту тему написано немало, но комплексной статьи, отвечающей на самые разные вопросы, начиная от того, что же такое SSL, до того, как работает атака MiTM и как от нее можно защититься, я еще не встречал (а может, просто плохо искал). В любом случае, мне бы хотелось поделиться своими мыслями на этот счет и внести свою малую долю в русскоязычный контент на эту тему.

Статья может быть полезна для разработчиков, которые хотят понять, как устроен процесс прикрепления (пиннинга) сертификатов и специалистам по анализу защищенности мобильных приложений.

Привет! Сегодня с вами Максим Кругликов из Surf Android Team с переводом статьи про устройство аннотаций в Kotlin и три основных механизма их обработки: процессинг, рефлексию и lint.

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

- Делать свою или взять готовую? Прыг.

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

- Версионировать компоненты или всю библиотеку? Прыг...

И ещё много таких «прыгов».

Давайте подготовимся к сложному контенту. Закроем глаза, успокоимся и представим идеальную дизайн-систему. Представили? Умные компоненты, продуманные паттерны, подробная документация. Автоматическая генерация кода. Кайф? А то! Только такая дизайн-система оставит нас без работы.

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

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

Рассказываю про наш тернистый путь к собственному генератору токенов дизайн-системы.

SwiftUI имеет отличный API для стилизации view независимо от их реализации. В этом посте мы рассмотрим, как мы можем стилизовать пользовательские view таким же образом.

В прошлом году в ходе нескольких эпизодов на Swift Talk мы продемонстрировали, как создать собственный степпер для увеличения и уменьшения значения. Он был похож на Stepper в SwiftUI, но с API, который делает его стильным.

Этот пост является кратким изложением того, что мы рассмотрели тогда, а также несколькими приёмами, которым мы научились с тех пор, чтобы наши пользовательские стили view (представление, вью, вьюшка) работали ещё лучше, как built‑in (встроенные) в SwiftUI. В последующем посте мы рассмотрим несколько более продвинутых вариантов использования.

Рассмотрим, как реализовать ползунок для переключения между страницами с красивой анимацией.

Термином «дизайн-система» в IT давно никого не удивишь. Компании систематизируют дизайн продуктов, придумывая свои или используя чужие инструменты для управления стилями, паттернами и компонентами. 

Badoo не является исключением: с помощью нашей дизайн-системы Cosmos мы поддерживаем общие принципы дизайна для четырёх приложений, работающих на четырёх платформах. 

Одна из первых и основных вещей, с которой начинается работа по созданию дизайн-системы, — это токены (или переменные), которые определяют значения разных сущностей системы. 

Как это работает? Например, у вас есть приложение для двух платформ. Вместо того чтобы для каждой заново указывать в CSS-файле размер и стиль шрифтов, вы можете хранить эти значения в JSON-файле, который легко преобразуется в код для любой платформы. В дальнейшем этот файл можно использовать и в других проектах с другими кодовыми базами. 

Несмотря на потенциал дизайн-токенов, во многих компаниях их структура остаётся довольно простой, что сильно ограничивает возможности их применения. 

Я хочу поделиться адаптированным переводом статьи моего коллеги Кристиано Растелли (Cristiano Rastelli), который несколько лет развивает дизайн-систему Cosmos. На примере своего опыта он показывает, как работать с токенами более эффективно: добавлять метаданные и использовать их для описания свойств компонентов. 

Под катом — небольшой рассказ о том, как выглядят дизайн-токены в Badoo и почему они значительно упрощают процесс разработки.

Те, кто работал над крупным Android-проектом с множеством модулей, не понаслышке знают, что такие проекты могут долго собираться. Неважно, что мы делаем — исправляем баг или разрабатываем фичу, нам нужно собрать проект, чтобы увидеть, как изменения повлияли на приложение. Мы тратим время на ожидание сборки проекта, и это влияет на продуктивность. 

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

Меня зовут Олег Шелякин, я ведущий Android-разработчик в мобильном банке Тинькофф. Статья будет интересна тем, кто работает над многомодульным проектом, где количество модулей перевалило за сотню, время синхронизации измеряется в минутах, а время сборки — в десятках минут.

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

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

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

Наша команда Ozon Seller также столкнулась с этой проблемой. Мы решили собрать воедино все советы и наработки по написанию оптимизированного Compose-кода. Активное применение этих советов при оптимизации существующих экранов и написании новых существенно улучшило наши метрики: длительность лага по отношению к длительности скролла (hitch rate; чем меньше, тем лучше) экранов со списками упала в среднем с 15-19 % до 5-7 % (на 90-м перцентиле). Все эти советы и наработки мы описали в этой статье. Она будет полезна и начинающим, и опытным разработчикам, в ней подробно описаны оптимизации и механизмы Compose, а также рассказано про слабо задокументированных особенности и исправления ошибок, которые есть в других статьях. Давайте же начнём.

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

Меня зовут Михаил Лихачёв, я ведущий дизайнер VK. Расскажу, как небольшой командой адаптировали 300 экранов и систематизировали все существующие в мобильных приложениях цвета — для этого мы синхронизировали их между платформами и вынесли работу с ними в единую дизайн-систему с токенами. Поделюсь впечатлениями о том, как нам теперь с этим живётся и усложнился ли процесс дизайна.

На конференции Google I/O 2022 показали инструмент Baseline Profiles, с помощью которого можно ускорить запуск приложений после установки. Мы попробовали его у себя и получили прирост до 20% при холодном запуске приложения!

В этой статье расскажу, как внедрить инструмент, оценить его работу на production приложении, немного погружу в историю компиляторов в целом и рассмотрю более продвинутые сценарии для генерации Profile.

Демонстрировать это я буду на нашем приложении Дринкит.

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

Обожаю запах свежей мобильной разработки по утрам, дням и вечерам ??

Все примеры из статьи можно посмотреть в этом репозитории.

Вот только почему, почему ещё не все используют режим edge2edge? Разве для того я покупал огромный безрамочный телефон, чтобы смотреть на траурные черные полоски с кнопками?!

К сожалению, сейчас все еще встречаются Android-приложения, которые не поддерживают edge-to-edge. Складывается ощущение, что разработчики либо не знают об insets, либо просто не умеют их готовить. На самом деле реализовать edge-to-edge не сложно, а благодаря этой статье вы сможете разобраться с insets в разы быстрее.

Сегодня я надену специальный мобильный фартук и расскажу, что такое режим edge-to-edge в мобильных приложениях и как работать с insets в Android. А ещё мы разберём примеры обработки insets не только во view, но и в compose. Если статьи о работе с insets в view еще можно найти на просторах интернета, то информацию про работу с ними в compose можно найти только в официальной документации.

Персонализация смартфона, свежая палитра цветов Material, обновлённые компоненты — от кнопок до диалогов.

Всё это — про Material You, новую дизайн-систему от Google для мобильных и веб-приложений! Разбираем новую систему цветов и все нововведения Material.

Автотестирование View системы развивается уже достаточно давно. У нас есть множество инструментов, зарекомендовавших себя очень хорошо.  Напротив, Compose только начинает обрастать различными решениями и фреймворками, например, у kaspresso на момент написания статьи Compose находиться в раннем доступе.

Сегодня разберём в чём же особенности нативного тестирования на compose, наступим на пару граблей и напишем свои первые тесты. А в следующей статье уже будем копать вглубь и посмотрим как это всё работает под капотом.