![](https://habrastorage.org/files/6a6/515/92c/6a651592c2e843e28714951d14bb0f1e.png)
В статье рассматриваются основы управления зависимостями в Gradle, приводятся углублённые практические примеры, небольшие лайфхаки и ссылки на нужные места в документации.
Android Developer
Власть в блоге Технократии переходит андроид-разработчикам. Владислав Титов рассказывает, как добиться непрерывающегося UI при смене локализации.
Архитектура: искусство делать излишнее необходимым.
Фредерик Кислер
Одна из фундаментальных тем в разработке под Android это работа с UI. Понимание того, как работает UI не даст многого в практическом плане, зато уменьшит вероятность того, что вы натворите полную дичь.
Это статья должна дать хоть и не исчерпывающее представление о том как работает UI в Android, но простым языком объяснит основные концепции и на каких сущностях он построен.
Всем привет! Меня зовут Александр Гузенко, и в Тинькофф я занимаюсь всякими техническими вещами вроде CI/CD, gradle и внедрением новых подходов. Хочу рассказать вам про библиотеку, которую мы создали в команде Тинькофф Бизнеса, когда столкнулись с многословными адаптер-делегатами.
В марте Google Play стал рассылать письмо-предупреждение для разработчиков, использующих Huawei Mobile Services в своих мобильных приложениях. И в этом письме было сказано, что использование HMS в сборках для Google Play противоречит политикам стора приложений, а на решение проблемы дается 120 дней. В противном случае Google Play обещает перестать принимать обновления для таких приложений.
После получения такого “письма счастья” мы окончательно убедились, что наша единая сборка приложения для всех сторов с переключением платформенных сервисов в рантайме – не самое надежное решение в столь изменчивом мире. В общем, мы решили оперативно перейти на раздельные сборки. Особенность нашего решения в том, что мы сохранили GMS+HMS сборку приложения для AppGallery, добавив в наш проект возможность сделать чистую GMS-сборку для Google Play. Мы использовали флейворы, но в связке с многомодульностью нам удалось затащить под флейворы лишь минимальное количество кода.
В этой небольшой статье я расскажу о нашей архитектуре разделения сборок для разных сторов, проблемах, с которыми столкнулись, а еще поделюсь статистикой по активным HMS-пользователям.
Перевод обновлённого гайда Android по архитектуре приложений. Это — первая часть из пяти: обзор рекомендаций по архитектуре.
Естественным источником информации в банке о покупках клиента являются карточные транзакции – любые операции, проводимые по дебетовым или кредитным картам. При этом денежные операции клиента не ограничиваются транзакциями, проводимыми с помощью карт. Оплата ЖКХ, оплата образования, крупные покупки и другие денежные переводы – это примеры транзакций, которые никак не привязаны к карте клиента, но при этом они ассоциируются с другой банковской сущностью – расчетным счетом.
Про то, как мы в Альфа-Банке применяем карточные транзакции в моделировании, мы уже рассказывали в этом посте. Логичным развитием идеи использования карточной транзакционной истории клиента является использование данных, которые содержатся в клиентской истории транзакций расчетного счета.
Spock предоставляет 3 мощных (но разных по сути) инструмента, упрощающих написание тестов: Mock, Stub и Spy.
Довольно часто коду, который нужно протестировать, требуется взаимодействовать с внешними модулями, называющимися зависимостями (в оригинальной статье используется термин collaborators, который не очень распространён в русскоязычной среде).
Модульные тесты чаще всего разрабатываются для тестирования одного изолированного класса при помощи различных вариантов моков: Mock, Stub и Spy. Так тесты будут надёжнее и будут реже ломаться по мере того, как код зависимостей эволюционирует.
Такие изолированные тесты менее подвержены проблемам при изменении внутренних деталей реализации зависимостей.
От переводчика: каждый раз, когда я использую Spock Framework для написания тестов, я чувствую, что могу ошибиться при выборе способа подмены зависимостей. В этой статье есть максимально краткая шпаргалка по выбору механизма для создания моков.
Основой любого приложения является его главный поток. На нем происходят все самые важные вещи: создаются другие потоки, меняется UI. Важнейшей его частью является цикл. Так как поток главный, то и его цикл тоже главный - в простонародье Main Loop.
Тонкости работы главного цикла уже описаны в Android SDK, а разработчики лишь взаимодействуют с ним. Поэтому, хотелось бы разобраться подробней, как работает главный цикл, для чего нужен, какие проблемы решает и какие у него есть особенности.
Это вторая часть цикла статей по разбору главного цикла в Android. В первой части мы разобрались с тем, что такое главный цикл и как он работает. В этой же части давайте разберемся как Main Loop работает в Android SDK. Разбираться будем в контексте Android SDK версии 30.
Основой любого приложения является его главный поток. На нем происходят все самые важные вещи: создаются другие потоки, меняется UI. Важнейшей его частью является цикл. Так как поток главный, то и его цикл тоже главный - в простонародье Main Loop.
Тонкости работы главного цикла уже описаны в Android SDK, а разработчики лишь взаимодействуют с ним. Поэтому, хотелось бы разобраться подробней, как работает главный цикл, для чего нужен, какие проблемы решает и какие у него есть особенности.
Это первая часть цикла разбора главного цикла в Android. Вообще, лучший способ понять, как что-то работает - сделать это самому. Поэтому, прежде чем лезть в дебри Android SDK давайте попробуем написать свой цикл, правда без блэкджека и прочего. Наоборот, это будет минимально работоспособный цикл, но зато хорошо демонстрирующий основную логику, без лишней мишуры.
Из статьи вы узнаете про новинки Jetpack Fragment 1.4: поддержку множественного back stack, FragmentStrictMode, новый менеджер состояний Fragment. Также расскажем, какие улучшения произошли под капотом.
Недавно я наткнулся на статью о проблеме c Java-сериализацией объектов в Kotlin. Автор предложил решать её добавлением метода readResolve
к каждому объекту, который наследуется от java.io.Serializable
.
Этот способ выглядит абсолютно правильным, однако его поддержка может оказаться слишком проблематичной. С учетом того, что в нашем проекте эта проблема возникала только при использовании объектов внутри Bundle, мы решили использовать проверку через is
для каждой ветки when
-выражений в случае sealed
классов.
Тем не менее, размышляя об этом, я никак не мог понять, почему Kotlin не генерирует readResolve
в компиляторе, поддерживая singleton-свойства объектов. Мне казалось, что это работа для инструментов, а не для человека. Но раз Kotlin не добавляет эту функцию сам, мы можем ему помочь! Этим мы сейчас и займёмся.