Предлагаем продолжить добрую традицию Ask me anything на Хабре и поговорить про разработку Android-приложений. Сегодня и завтра Android-команда Badoo будет на связи и ответит на любые вопросы о разработке и тестировании приложений с многомиллионной аудиторией, даст советы начинающим и расскажет про особенности платформы. Если вы столкнулись с какой-то проблемой или у вас есть вопрос по теме, пишите нам!



Обещаем ответить на все комментарии первого уровня, которые появятся здесь до 16:00 17 июля по московскому времени, а по возможности — и на более поздние.

Немного фактов о нас. Badoo и Bumble — одни из самых популярных дейтинг-сервисов в мире: только в Google Play у нас 210 млн скачиваний. В Android-приложениях больше 1,3 млн строк кода. В Android-команде больше 20 разработчиков. Основной язык разработки — Kotlin, архитектурные паттерны — MVI и RIBs, база данных — SQLite.

Под катом — подробнее о нашей команде и о темах, на которые мы можем поговорить.

UPD: Мы завершаем AMA и прощаемся. Спасибо всем за вопросы!

Несколько лет назад мы в Badoo начали использовать MVI-подход к Android-разработке. Он был призван упростить сложную кодовую базу и избежать проблемы некорректных состояний: в простых сценариях это легко, но чем сложнее система, тем сложнее поддерживать её в корректном виде и тем проще пропустить баг. 

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

Наш коллега Zsolt Kocsi (Medium, Twitter) из лондонского офиса рассказал, каким образом с помощью MVI мы строим независимые компоненты, которые легко переиспользовать, какие преимущества мы получаем и с какими недостатками нам пришлось столкнуться при использовании этого подхода.

Всем привет! Меня зовут Анатолий Варивончик. Я работаю в Badoo уже больше года, а мой общий стаж Android-разработки — более пяти лет.

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

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

Всем привет! Меня зовут Анатолий Варивончик, я Android-разработчик Badoo. Сегодня я поделюсь с вами переводом второй части статьи моего коллеги Zsolt Kocsi о реализации MVI, которую мы ежедневно используем в процессе разработки. Первая часть здесь.

Чего мы хотим и как мы это сделаем

В первой части статьи мы познакомились с Features, центральными элементами MVICore, которые можно переиспользовать. Они могут обладать максимально простой структурой и включать всего один Reducer, а могут стать полнофункциональным средством для управления асинхронными задачами, событиями и многим другим.

Каждая Feature отслеживаема — есть возможность подписаться на изменения её состояния и получать уведомления об этом. При этом Feature можно подписать на источник ввода. И в этом есть смысл, ведь с включением Rx в кодовую базу у нас и так появилось множество наблюдаемых объектов и подписок на самых разных уровнях.

Именно в связи с увеличением количества реактивных компонентов пришло время поразмышлять о том, что мы имеем и можно ли сделать систему ещё лучше.

Haskell является полностью функциональным и чрезвычайно лаконичным языком. Любой, кто когда-нибудь пробовал писать код на Haskell, замечает, насколько он получается более кратким и изящным, чем написать то же самое на императивном языке. Добиться такого же на Java, на мой взгляд, невозможно, но Kotlin позволяет продвинуться в этом направлении и примерить на себе полностью функциональный стиль. Мы можем вывести все сложные функции, которые нам могут понадобится из стартового базиса 3-х наиболее известных функций: map, filter, reduce. Кроме этого я создал репозиторий, который вы можете изучить и посмотреть тесты.

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

На Хабре уже есть похожие статьи на тему сборки Android приложения с помощью Jenkins. Ключевыми особенностями/дополнениями текущей будет следующее:

1. Мы установим Jenkins на удалённую Linux машину, где отсутствует UI.
2. Мы будем собирать приложение из приватного репозитория.
3. Мы решим проблему сборки приложения из ветки имя которой нам не известно.
4. После сборки .apk файлов мы отправим их в Fabric и оповестим тестировщиков.
5. После отправления в Fabric мы опубликуем приложение на Google Play.
6. Защитим задачи по публикации приложения от запуска тестировщиками.