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

Если вы хотите сделать хорошую архитектуру, то используйте эту схему и строго соблюдайте правила, без каких-либо исключений.

В этой серии статей я расскажу о внутреннем устройстве Android  —  о процессе загрузки, о содержимом файловой системы, о Binder и Android Runtime, о том, из чего состоят, как устанавливаются, запускаются, работают и взаимодействуют между собой приложения, об Android Framework, и о том, как в Android обеспечивается безопасность.

Привет! Я Даниэль Халиулин, технический менеджер продукта в Тинькофф. Отвечаю за надежность и производительность нашего основного приложения — мобильного банка. Руковожу двумя одноименными командами, которые занимаются производительностью и надежностью. Расскажу про направления SRE и Observability в мобильных приложениях.

В компании ИВИ, ведущем онлайн-кинотеатре, наша команда разработчиков занимается созданием приложения для платформы Android. Недавно мы успешно выпустили версию для Android TV, используя инновационный инструмент — Jetpack Compose. Несмотря на то, что библиотека Compose для ТВ еще находится в альфа-версии, мы хотим поделиться своим опытом, рассказать о трудностях, с которыми столкнулись, и обратиться к вопросу: стоит ли использовать Jetpack Compose, особенно для ТВ-приложений?

Небольшое предисловие от команды ОК: Последний пост на Хабре от Одноклассников был написан ещё в декабре прошлого года. Мы пропали отсюда на 8 месяцев, но это не означает, что за это время с Одноклассниками ничего не происходило. Нами по-прежнему пользуется несколько десятков миллионов человек ежемесячно, мы по-прежнему один из самых высоконагруженных сервисов на Java в мире. Мы обновили позиционирование, отсняли десятки эпизодов собственных шоу, отказались от оценок под фото :)

Мы решили вернуться на Хабр после долгого отсутствия и сразу с рассказом о своем проекте, который назвали Tracer. О том, что это, рассказывает руководитель направления Android-разработки в проекте ОК Кирилл Попов.

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

 Что надо знать, чтобы успешно применять-реализовать многопоточность (Multithreading) в своей программе? Мне кажется есть некоторые неудобные для изложения куски в разных описаниях потоков и того, что с ними связано, которые остаются не раскрытыми или вообще пропускаются.

Мне хочется предложить на суд читателей мое собственное понимание таких неудобных аспектов, связанных с применением многопоточности для практического программирования, которое накопилось у меня за пару десятилетий успешного применения этой самой многопоточности на всех уровнях разработки от Embedded и аппаратно-ориентированных уровней до C#, WPF, Java высокоуровневых фронт-ендов.

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

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

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

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

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

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

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

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

У нас в проекте с незапамятных времён для DI используется Dagger. И в целом он нас всем устраивает. Ну, разве что кроме одного маленького пунктика — скорость сборки с kapt. Он прилично увеличивает время сборки. Казалось бы, смирись, страдай, прими ситуацию. Но относительно недавно Yandex представили библиотеку для Dependency Injection. Имя ей Yatagan. У неё есть две важных особенности — она спроектирована быть похожей на Dagger по API, и одна из её целей — меньше влиять на время сборки. Меньшее время сборки — это всегда хорошо, а значит, стоит её как минимум попробовать. 

На Google I/O 2021 продемонстрировали фичу, которая позволяет динамически менять цветовую схему приложения в зависимости от его контента. Но ни в документации, ни в официальных примерах не оказалось использования этого подхода или API, которое делало бы это на уровне отдельного экрана или элемента.

Ведущего android-разработчика red_mad_robot Рому Чорыева это не устроило, и он для этой цели решил разработать собственное простое решение, — а теперь рассказывает об этом в статье.

Привет! Я Максим Коробов, руководитель отдела разработки мобильного приложения Тинькофф. В статье расскажу о том, как проходит отбор кандидатов на вакансии разработчиков iOS и Android, что спрашивают на первичном и техническом интервью и какие задачи предлагают решать во время практической секции. 

Материал будет полезен разработчикам, которые ищут точки роста, интересуются проектами в крупных компаниях или хотят работать именно в Тинькофф. Если это про вас, не переключайтесь. 

По данным ВОЗ, в мире более миллиарда человек обладает с той или иной формой инвалидности. Поэтому Accessibility, или доступность, — важная штука в разработке программного обеспечения, особенно под мобильные платформы.

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

Сегодня — про Accessibility в Jetpack Compose: в нём сделать доступный графический интерфейс приложения ещё легче, чем на View. Разбираемся, как устроена поддержка доступности в Compose и какие особенности учесть при разработке.

Что за зверь такой этот бенчмаркинг Android-приложений? Разберемся с тем, для чего он нужен, погрузимся в детали работы Jetpack Benchmark Library и получим знания для написания первого бенчмарк-теста. 

Помогать в этом деле буду я, Диана Федотова, Android-разработчица из Технократии.

Всем привет! Меня зовут Максим Бредихин, я Android-разработчик в Тинькофф. А это — вторая статья серии об интересных моментах из Fragment API, о которых вы, возможно, не знали.

Готовьте вкусности, сегодня я расскажу, как (не) создавать новые инстансы фрагментов.

Всем привет! Меня зовут Максим Бредихин, я Android-разработчик в Тинькофф. В этой серии статей я расскажу об интересных моментах из Fragment API, о которых вы могли не знать. Материал будет полезен как начинающим разработчикам, так и закаленным в боях с багами девелоперам.

Усаживайтесь поудобнее, мы начинаем!

Я провел в изучении JMM много часов и теперь делюсь с вами знаниями в простой и понятной форме.

В этой статье мы подробно разберем Java Memory Model (JMM) и применим полученные знания на практике. Да, в интернете накопилось достаточно много информации про JMM/happens-before, и, кажется, что очередную статью про такую заезженную тему можно пропускать мимо. Однако я постараюсь дать вам намного большее и глубокое понимание JMM, чем большинство информации в интернете. После прочтения этой статьи вы будете уверенно рассуждать о таких вещах как memory ordering, data race и happens-before. JMM — сложная тема и не стоит верить мне на слово, поэтому большинство моих утверждений подтверждается цитатами из спеки, дизассемблером и jcstress тестами.