Привет, Хабр!

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

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

Мы открыты к общению!

Всем привет! Меня зовут Александр Гузенко, и в Тинькофф я занимаюсь всякими техническими вещами вроде CI/CD, gradle и внедрением новых подходов. Хочу рассказать вам про библиотеку, которую мы создали в команде Тинькофф Бизнеса, когда столкнулись с многословными адаптер-делегатами.

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

Я выступал с этим докладом на iOS Meetup | СберМаркет Tech, здесь его сжатая версия.

Привет, Хабр! 

Меня зовут Василий Материкин, я — Android-разработчик в QIWI. В этом посте я расскажу о применении фича-флагов в QIWI Кошельке.

Внедрение Trunk-Based Development и Feature Flags

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

Поэтому мы решили перейти на Trunk-Based Development (TBD). TBD предлагает работать в небольших ветках и, желательно, чтобы они как можно быстрее были влиты основную ветку. Для этого, конечно же, реализацию нового функционала нужно оформлять небольшими пулл-реквестами, чтобы они быстро проходили ревью и были влиты в основную ветку. Это, в свою очередь, создает другую проблему — когда в главной ветке может появиться код, который ещё не готов к релизу, но при этом нам нужно как-то релизить с этим кодом приложение. Мы же релизы выпускаем достаточно часто. И для этого TBD предлагает пользоваться такими подходами, как Branch by Abstraction (BBA) и Feature Flags (FF).

BBA позволяет выделить какой-либо функционал в отдельную абстракцию. Для этого создается интерфейс, который описывает контракт для работы с этим функционалом. Сразу же можно создать его текущую реализацию, просто скопировав код, который сейчас в продакшене. Также создается другая реализация (уже с новым функционалом) и с ней уже начинается работа. То есть обычно первый пулл-реквест при работе с фичей — это выделение кода, создается две реализации, эти изменения вливаются в главную ветку и далее продолжаем работать уже над новой реализацией. При этом в проекте (в продакшене) используется всё ещё старая реализация, пока мы не закончим работать над фичей.

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

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

В марте Google Play стал рассылать письмо-предупреждение для разработчиков, использующих Huawei Mobile Services в своих мобильных приложениях. И в этом письме было сказано, что использование HMS в сборках для Google Play противоречит политикам стора приложений, а на решение проблемы дается 120 дней. В противном случае Google Play обещает перестать принимать обновления для таких приложений.

После получения такого “письма счастья” мы окончательно убедились, что наша единая сборка приложения для всех сторов с переключением платформенных сервисов в рантайме – не самое надежное решение в столь изменчивом мире. В общем, мы решили оперативно перейти на раздельные сборки. Особенность нашего решения в том, что мы сохранили GMS+HMS сборку приложения для AppGallery, добавив в наш проект возможность сделать чистую GMS-сборку для Google Play. Мы использовали флейворы, но в связке с многомодульностью нам удалось затащить под флейворы лишь минимальное количество кода. 

В этой небольшой статье я расскажу о нашей архитектуре разделения сборок для разных сторов, проблемах, с которыми столкнулись, а еще поделюсь статистикой по активным HMS-пользователям.

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

За этим мнением скрывается простая правда — люди, которые так говорят, не умеют писать тесты. Не умеют писать их быстро; писать там, где нужно; писать так, чтобы была ощутимая польза для бизнеса. Я тоже был таким — понимал, что тесты нужны, но не понимал какие, где и как их писать. 

Рассказываю, что поменялось спустя 2 года и 4 тысячи тестов. 

Представьте: вы на собеседовании, только что закончили отвечать на кучу вопросов и были на высоте. Наконец наступает ваш черед задавать ваши вопросы работодателю. Не знаю как вы, а я в таких ситуациях часто начинал теряться и забывал самое важное, о чем стоило бы спросить. Однако, собеседование – это двустороннее общение, а значит, не только работодатель собеседует вас, но и вы – работодателя. 

Меня зовут Костя, я – Android-техлид в hh.ru, и сегодня я расскажу об идеальных вопросах от Android-разработчика на собеседовании. Объясню, почему я выбрал именно эти вопросы, на что обращать внимание в ответах работодателя, а также отвечу на них так, как мы отвечаем нашим Android-соискателям. Эта статья будет полезна не только мобильным разработчикам, но и специалистам других направлений, которые проходят собеседования.

Как компилятор Kotlin преобразует suspend код? Что получается в итоге? Разбираемся в машине состояний suspend кода.

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

Давайте сначала представимся. Мы - команда управления тестирования и контроля качества в БКС Мир Инвестиций. Наш продукт - это приложения и сайты, созданные для удобства всех желающих окунуться в мир ценных бумаг и инвестиций. Конкретно в нашем “ведомстве” приложения на IOS  и Android, сайт личного кабинета, инвест стратегии Fintarget, новостной портал BCS-Express, сайт ФГ БКС и прочее.

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

Конечно же, автоматизация наших процессов важна, ведь без этого невозможно построение действительно сильного QA отдела. Безусловно, мы встретились с множеством разнообразных проблем.

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

Начать эти рассказы мы решили с повести о становлении мобильного автотестирования. Первым “попался под руку” Android, про него и начнем.

Привет, Хабр!

Меня зовут Кирилл Васильев, и я хотел бы рассказать, как мы в QIWI внедряли Kotlin Multiplatform Mobile (KMM). 

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

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

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

В этой статье мы расскажем про принципы безопасной работы с переключателями функционала – Feature Toogles: 

— Что из себя представляют переключатели функционала и для чего их использовать.

— Какие проблемы возникают при неправильном использовании.

— Что такое «горячие» и «холодные» переключатели, и как они способны решить проблемы из прошлого пункта. 

— Реализация «холодных» toogle-ов с помощью условной компиляции и линковки.

Наверняка статья не станет откровением для опытных разработчиков, но пригодится их младшим товарищам.