Комментарии 52
Здравствуйте! Скажите, пожалуйста, разработка сейчас ведется исключительно на Kotlin? Используется ли шаблон MVI? Хотелось бы еще узнать, как скоро можно ожидать hiring event в команду Android-разработчиков в Лондоне? Спасибо
Привет, подумываю перекатиться с фронтенда в мобильную разработку (на Android), поделитесь советами какие могут быть сложности и вообще с чего начать (или может отговорите?))?
Добрый день! На мой взгляд решение хорошее. Трудности могут возникнуть по следующим моментам:
- Другая модель приложений и экранов и их жизненные циклы
- Многопоточная среда
- Отсутствие декларативного UI как стандарта — Jetpack Compose ещё в разработке, пока доминируют императивные подходы
- Статическая типизация может доставлять неудобства первое время
Начать я бы посоветовал с вступления в следующие Телеграм-каналы, где всегда можно задать вопрос:
- Kotlin Start
- Kotlin Community
- Android Developers
- Android Architecture
- Если надумаете использовать MVICore: https://t.me/joinchat/C0b_YlOkm3y_bIEv-z7--g
Далее я бы рекомендовал разобраться с Java в Android, как с языком, так и с виртуальной машиной. Потом Android SDK, Котлин, архитектурные шаблоны (MVI, MVVM, и т.д.).
Можно начать с банального developer.android.com/guide, или взять какой нибудь видео курс где все по шагам и собрано в одном месте www.udemy.com/courses/search/?q=android%2Bkotlin” ~15$.
Советую посмотреть в сторону Android Academy (бесплатные курсы от действующих разработчиков) плейлист на курс от новичков и телеграм канал сообщества. Скоро будет бесплатный онлайн курс, думаю, это как раз то, что Вам нужно
Скажите, пожалуйста, а в iOS вы используете аналог MVICore? Или какие-то другие фреймворки/подходы, если да то какие?
Место, за ответ! А чем обоснован такой выбор?
Почему не использование общие подходы к архитектуре? Бизнес не страдает от этого?
*спасибо.
Ребята, возможно вопрос достаточно холиварный и сложный, но все же, почему в iOS и Android различаются подходы? arkivanov рассказывал, что у вас получилось Android приложение полностью на новую архитектуру перевести и сейчас осталось буквально немного легаси на чистой архитектуре. Что в это время делала iOS часть команды? Почему не шарили экспертизу? Не удалось убедить? Какие аргументы были не использовать MVI в iOS? Ваш подход к MVI и MVVM не особо противоречат другу. Да, и почему в iOS (ссылку на старую статью прислал wiruzx ) самописная реактивщина?
Вопрос, видимо, к bivy, как к Head of Mobile
Ребята, возможно вопрос достаточно холиварный и сложный, но все же, почему в iOS и Android различаются подходы? arkivanov рассказывал, что у вас получилось Android приложение полностью на новую архитектуру перевести и сейчас осталось буквально немного легаси на чистой архитектуре. Что в это время делала iOS часть команды? Почему не шарили экспертизу? Не удалось убедить? Какие аргументы были не использовать MVI в iOS? Ваш подход к MVI и MVVM не особо противоречат другу. Да, и почему в iOS (ссылку на старую статью прислал wiruzx ) самописная реактивщина?
Вопрос, видимо, к bivy, как к Head of Mobile
Привет Саша!
Изначально платформы у нас были изолированы, ситуация начала меняться 2-3 года назад. К тому времени на Андроиде было несколько итераций экспериментов и получился зоопарк подходов/архитектур с которым было сложно работать, поэтому был активно запущен процесс поиска решения и унификации.
В iOS ситуация сложилась иначе, зоопарк был меньше и ситуация оставалась контролируемой. Плюс на данный момент iOS команда еще смотрит на SwiftUI и Combine, и не хочет попасть в ситуации когда новые архитектурные паттерны придется менять на корню, после того как эти технологии станут стандартом де-юре и де-факто. Мы в целом подумываем над подобным шагом и на iOS, но как всегда чтобы нужно учитывать cost/benefit/long-term-impact)
Изначально платформы у нас были изолированы, ситуация начала меняться 2-3 года назад. К тому времени на Андроиде было несколько итераций экспериментов и получился зоопарк подходов/архитектур с которым было сложно работать, поэтому был активно запущен процесс поиска решения и унификации.
В iOS ситуация сложилась иначе, зоопарк был меньше и ситуация оставалась контролируемой. Плюс на данный момент iOS команда еще смотрит на SwiftUI и Combine, и не хочет попасть в ситуации когда новые архитектурные паттерны придется менять на корню, после того как эти технологии станут стандартом де-юре и де-факто. Мы в целом подумываем над подобным шагом и на iOS, но как всегда чтобы нужно учитывать cost/benefit/long-term-impact)
Исторически так сложилось, что мы использовали разные подходы к архитектуре в разных частях приложения.
У нас был MVC, MVP и MVVM и только относительно недавно мы договорились использовать MVVM повсеместно.
Почему не использование общие подходы к архитектуре?
Я думаю, основная причина в том, что в iOS команде не было MVI энтузиаста, который бы форсил эту тему.
Бизнес не страдает от этого?
Мне не кажется, что бизнес страдает от разных подходов к архитектуре на разных платформах, по крайней мере до тех пор, пока мы не начали шарить UI код между ними.
Да, и почему в iOS самописная реактивщина?
Мы используем MVVM без RX-extensions, по-этому до сих пор нам хватало маленького самописного Observable :)
C приходом Combine, будем потихоньку перебираться на него.
Здравствуйте, интересует пара вопросов:
— часто ли приходится прибегать к NDK и в каких ситуациях это приносило заметный выигрыш?
— используете ли для мониторинга/аналитики in-house или сторонние продукты?
— часто ли приходится прибегать к NDK и в каких ситуациях это приносило заметный выигрыш?
— используете ли для мониторинга/аналитики in-house или сторонние продукты?
Здравствуйте,
- Мы не используем NDK в нашем клиентском коде, нативный код у нас только от сторонних библиотек, таких как WebRTC для видеозвонков или TensorFlow для фото-верификации. В целом, не думаю, что у нас есть места, где NDK могло бы заметно помочь с производительностью, а минусов со стороны поддержки такого кода больше.
- Для мониторинга и аналитики в основном используем in-house тулы: своя система для аналитических событий, сбора перфоманс метрик, своя краш репортинг система. Иногда прибегаем к сторонним продуктам: например, некоторые метрики из Google Play аналитики нельзя получить своими средствами.
Привет, а для WebRTC используете камеру которая внутри самой гугловой либы? Или что-то внешнее? Если ту которая из коробки нет ли с ней проблем?
Здравствуйте, используем стандартную камеру, проблем с ней не наблюдали, она достаточно стабильная и работает хорошо даже на старых устройствах.
Что используете для UI тестирования? Какой фреймворк, раннер.
Сами тесты мы пишем на стандартном Espresso с применением удобной библиотеки описания view от Avito.
Из-за того, что у нас очень много gradle-модулей и UI-тестов в них, и все тесты прогоняются для каждого «пулл-реквеста», мы сделали свой форк раннера Marathon. Оригинальная версия этого раннера решает проблемы стабильности прохождения тестов (при тысячах UI-тестов это отдельная боль), собирает очень удобные репорты и даже сохраняет видео прохождения теста. И наш форк позволяет запускать весь набор тестов из всех модулей полностью параллельно друг другу.
Казалось бы, оригинальный марафон тоже умеет запускать тесты одновременно, зачем нам нужен свой форк? Проблема в том, что марафон не запускает тесты из следующего модуля, пока не закончатся все тесты предыдущего модуля. И такая стратегия запуска может оставить десятки эмуляторов без нагрузки, если в модуле очень мало тестов.
Наши iOS-коллеги не используют марафон, так что мы починили это только для gradle-плагина. API нашего марафона тоже изменился, так что без дополнительной работы запустить его на iOS-проектах не получится.
Вот например, таймлайны трёх запусков тестов на двух агентах (по четыре эмулятора на каждом):
А вот так они проходят с нашим форком:
Пока полный прогон занимает приемлемое время на одной машине, но, поскольку количество тестов у нас удваивается каждые полгода, мы рассматриваем вариант масштабирования раннера сразу на несколько серверов с эмуляторами.
Из-за того, что у нас очень много gradle-модулей и UI-тестов в них, и все тесты прогоняются для каждого «пулл-реквеста», мы сделали свой форк раннера Marathon. Оригинальная версия этого раннера решает проблемы стабильности прохождения тестов (при тысячах UI-тестов это отдельная боль), собирает очень удобные репорты и даже сохраняет видео прохождения теста. И наш форк позволяет запускать весь набор тестов из всех модулей полностью параллельно друг другу.
Казалось бы, оригинальный марафон тоже умеет запускать тесты одновременно, зачем нам нужен свой форк? Проблема в том, что марафон не запускает тесты из следующего модуля, пока не закончатся все тесты предыдущего модуля. И такая стратегия запуска может оставить десятки эмуляторов без нагрузки, если в модуле очень мало тестов.
Наши iOS-коллеги не используют марафон, так что мы починили это только для gradle-плагина. API нашего марафона тоже изменился, так что без дополнительной работы запустить его на iOS-проектах не получится.
Вот например, таймлайны трёх запусков тестов на двух агентах (по четыре эмулятора на каждом):
А вот так они проходят с нашим форком:
Пока полный прогон занимает приемлемое время на одной машине, но, поскольку количество тестов у нас удваивается каждые полгода, мы рассматриваем вариант масштабирования раннера сразу на несколько серверов с эмуляторами.
Накинуть ПР в марафон не хотите? Добавить флаг конфигурации с реализацией. Или форк ушел слегка дальше чем это изменение?
Какао пробовали?
Изначально планировали, но, к сожалению, мы сильно поменяли код и теперь требуются достаточно большие изменения в iOS реализации. Мы на iOS не используем Marathon, поэтому не уверен что в ближайшее время найдутся ресурсы чтобы поправить это.
Kakao рассматривали при выборе библиотек для UI тестирования, но в итоге остановились на библиотеке от Avito. Одна из причин почему не выбрали Kakao — большая вербозность с вложенным DSL синтаксисом.
Kakao рассматривали при выборе библиотек для UI тестирования, но в итоге остановились на библиотеке от Avito. Одна из причин почему не выбрали Kakao — большая вербозность с вложенным DSL синтаксисом.
За счет чего происходит монетизация в дейтинге вообще и в баду — в частности?
Привет! Есть несколько вопросов, про дизайн систему и как вы с ней работаете.
1. Как давно вы используете подход с дизайн системой? Как много времени прошло с момента когда вы поняли, что она нужна до момента когда устаканились все процессы работы с дизайнерами с использованием дизайн системы?
2. От кого пошел интент на разработку с помощью дизайн системы? Если от разработки, то как дизайн отреагировал, на то, что сейчас им нужно думать еще и про дизайн систему и как получилось их уговорить.
3. Как устроена ваша дизайн система. Есть ли разделение на core часть (где скажем общая палитра сервиса и шрифты) и на платформенные части. Есть ли разделение внутри платформы на какие-то подчасти, например примитивы (тексты, лоадеры, простейшие вьюшки, кнопки) и на ui-компоненты (например сложные карточки)
4. Как построен процесс разработки нового экрана с использованием дизайн системы. То есть именно что и когда вы делаете, как разработка в этом участвует с момента того например как пришла задача на разработку нового экрана до момента когда команда разработки начинает писать код.
5. Как у вас устроен процесс определения что является компонентом дизайн системы а что нет.
6. Есть ли у вас какие-то критерии по которым вы определяете что вот эти две похожие (визуально) вьюшки это должен быть один компонент а вот эти нет. Это делает только разработка или вместе с дизайном, как построен процесс.
7. Какая тулза используется для хранения дизайна и дизайн системы. В ее использовании применяются ли какие-то возможности тулзы для использования дизайн системы (имею ввиду ссылки на компоненты и т.д.)
8. Действительно ли процесс разработки с дизайн системой приносит выгоду в скорости глобально и в быстром изменении компонентов.
9. Как построен процесс, кто и когда сообщает, что в дизайн системе произошли изменения, например какого-то отступа (например есть отступ padding-normal и вот дизайнеры решили, что он не 16 а скажем 24 становится, кто когда и как уведомляет, что он изменился и как дальше построен процесс разработки и проверки)
10. В дизайне где лежит дизайн система как-то помечается, что компонент еще не реализован на в коде приложения.
11. Есть ли в дизайн системе подробная спецификация для каждого компонента (состояния, зависимые отступы, стили компонента например для темной и светлой темы)
12. Используете ли вы в дизайн системе цветовые токены
13. Есть ли у вас отдельные именованные токены для отступов и соответствующие им размерности
14. Есть ли у вас отдельные именованные токены для стиля написания текста и соответствующие им массивы значений
зы: было бы круто посмотреть небольшой пример как используется у вас дизайн система на примере дизайн+код, то есть очень бы хотелось посмотреть небольшой кусок того как хранится дизайн система, что там оформлено и как и как вы в коде интерпретируете дизайн систему.
1. Как давно вы используете подход с дизайн системой? Как много времени прошло с момента когда вы поняли, что она нужна до момента когда устаканились все процессы работы с дизайнерами с использованием дизайн системы?
2. От кого пошел интент на разработку с помощью дизайн системы? Если от разработки, то как дизайн отреагировал, на то, что сейчас им нужно думать еще и про дизайн систему и как получилось их уговорить.
3. Как устроена ваша дизайн система. Есть ли разделение на core часть (где скажем общая палитра сервиса и шрифты) и на платформенные части. Есть ли разделение внутри платформы на какие-то подчасти, например примитивы (тексты, лоадеры, простейшие вьюшки, кнопки) и на ui-компоненты (например сложные карточки)
4. Как построен процесс разработки нового экрана с использованием дизайн системы. То есть именно что и когда вы делаете, как разработка в этом участвует с момента того например как пришла задача на разработку нового экрана до момента когда команда разработки начинает писать код.
5. Как у вас устроен процесс определения что является компонентом дизайн системы а что нет.
6. Есть ли у вас какие-то критерии по которым вы определяете что вот эти две похожие (визуально) вьюшки это должен быть один компонент а вот эти нет. Это делает только разработка или вместе с дизайном, как построен процесс.
7. Какая тулза используется для хранения дизайна и дизайн системы. В ее использовании применяются ли какие-то возможности тулзы для использования дизайн системы (имею ввиду ссылки на компоненты и т.д.)
8. Действительно ли процесс разработки с дизайн системой приносит выгоду в скорости глобально и в быстром изменении компонентов.
9. Как построен процесс, кто и когда сообщает, что в дизайн системе произошли изменения, например какого-то отступа (например есть отступ padding-normal и вот дизайнеры решили, что он не 16 а скажем 24 становится, кто когда и как уведомляет, что он изменился и как дальше построен процесс разработки и проверки)
10. В дизайне где лежит дизайн система как-то помечается, что компонент еще не реализован на в коде приложения.
11. Есть ли в дизайн системе подробная спецификация для каждого компонента (состояния, зависимые отступы, стили компонента например для темной и светлой темы)
12. Используете ли вы в дизайн системе цветовые токены
13. Есть ли у вас отдельные именованные токены для отступов и соответствующие им размерности
14. Есть ли у вас отдельные именованные токены для стиля написания текста и соответствующие им массивы значений
зы: было бы круто посмотреть небольшой пример как используется у вас дизайн система на примере дизайн+код, то есть очень бы хотелось посмотреть небольшой кусок того как хранится дизайн система, что там оформлено и как и как вы в коде интерпретируете дизайн систему.
1. 2. 3. Здесь рекомендую серию статей от нашего лида по дизайн системе, который изначально предложил внедрить ее. From zero to Cosmos part 1. Так же можно посмотреть выступление Android разработчика Mobiconf. Scalable UI.
4. После того как разработан дизайн, дизайнер создает схему (в виде изображения) с разбиением дизайна на компоненты системы. Затем схему проверяет разработчик, сопоставляя компоненты из дизайн системы с тем, что есть в коде. В случае чего, выделяется дополнительное время на доработку/добавление компонента.
5. Если элемент планируется использовать часто (общаемся с продуктами и дизайнерами), мы обсуждаем возможность включить ее в дизайне систему.
6. Тут нет секретов, все основано на общении и здравом смысле. В каждой команде платформ есть “UI Committee” с 2 — 3 разработчиками, которые помимо своих повседневных задач так же отвечают за связь дизайн системы с кодом платформы. Мы обсуждаем с ними и с дизайнерами. Если происходят споры можно пообщаться и с самим лидом дизайн системы.
7. На данный момент система хранится в виде веб сайта.
8. Глобально для большого и долгосрочного проекта — да. Когда есть стандарты, мы меньше думаем что использовать, как писать код, пушим чтобы дизайнеры использовали элементы из дизайн системы и можем избегать дублирования кода, новые разработчики тратят меньше времени что б разобраться в компонентах, так же это помогает и в тестировании habr.com/ru/company/badoo/blog/479970
9. Все относительно просто. Дизайнер сделал изменение -> рассказал об изменениях “UI Committee” платформ -> создали тикет -> доработали.
10. Не помечается, если приходит дизайн с таким компонентом, выделяем время на разработку этого компонента.
11. Есть, ну и конечно, бывает, что сталкиваемся с новыми кейсами и по ходу дела дорабатываем систему.
12. 13. 14. Токены используем, об этом можно подробнее узнать вот здесь habr.com/ru/company/badoo/blog/491948
4. После того как разработан дизайн, дизайнер создает схему (в виде изображения) с разбиением дизайна на компоненты системы. Затем схему проверяет разработчик, сопоставляя компоненты из дизайн системы с тем, что есть в коде. В случае чего, выделяется дополнительное время на доработку/добавление компонента.
5. Если элемент планируется использовать часто (общаемся с продуктами и дизайнерами), мы обсуждаем возможность включить ее в дизайне систему.
6. Тут нет секретов, все основано на общении и здравом смысле. В каждой команде платформ есть “UI Committee” с 2 — 3 разработчиками, которые помимо своих повседневных задач так же отвечают за связь дизайн системы с кодом платформы. Мы обсуждаем с ними и с дизайнерами. Если происходят споры можно пообщаться и с самим лидом дизайн системы.
7. На данный момент система хранится в виде веб сайта.
8. Глобально для большого и долгосрочного проекта — да. Когда есть стандарты, мы меньше думаем что использовать, как писать код, пушим чтобы дизайнеры использовали элементы из дизайн системы и можем избегать дублирования кода, новые разработчики тратят меньше времени что б разобраться в компонентах, так же это помогает и в тестировании habr.com/ru/company/badoo/blog/479970
9. Все относительно просто. Дизайнер сделал изменение -> рассказал об изменениях “UI Committee” платформ -> создали тикет -> доработали.
10. Не помечается, если приходит дизайн с таким компонентом, выделяем время на разработку этого компонента.
11. Есть, ну и конечно, бывает, что сталкиваемся с новыми кейсами и по ходу дела дорабатываем систему.
12. 13. 14. Токены используем, об этом можно подробнее узнать вот здесь habr.com/ru/company/badoo/blog/491948
НЛО прилетело и опубликовало эту надпись здесь
Здравствуйте! Спасибо за вопросы!
Ответить на них нам помогла руководитель продуктовой группы Badoo — Люба Вязникова:
Ответить на них нам помогла руководитель продуктовой группы Badoo — Люба Вязникова:
- В продукте мы фокусируемся на инструментах, которые помогают пользователям узнать друг друга лучше, чтобы знакомиться и создавать отношения. Лайв был прекрасной частью продукта, но фокусировался (и работал) больше на развлечение, чем на построении отношений между людьми, будь то дружба или свидания.
- Спасибо за фидбэк! Мы регулярно мониторим отзывы пользователей и смотрим на данные по использованию фичей, чтобы не перегружать продукт и пользователский опыт, а фокусироваться только на самых полезных инструментах. Фильтры — однозначно один из главных фокусов на ближайшее время, следите за обновлениями.
- Такой логики в продукте точно нет. Если вы расскажете подробнее, возможно, станет понятно, в чем проблема.
Привет! Расскажите, как у вас в компании выстроены процессы разработки, коммуникация сотрудников, IT инфраструктура. Какие интересные инструменты используете в работе (кроме стандартных, типа Android Studio). Интересно было бы узнать, насколько больно перекатывать крупное приложение на Kotlin (и больно ли вообще)?
Процесс разработки новой функциональности начинается с задачи от продукт-менеджера. Он полностью описывает, как должен работать новый функционал, условия, при которых этот функционал должен активироваться, базовые тексты.
Дальше в работу вступает специальная команда MAPI, которая разрабатывает протокол общения между клиентом и сервером, описывает, как должен вести себя клиент в той или иной ситуации. Затем это проходит ревью у команд, которые будут все реализовывать. Если нужен дизайн, то дизайнер делает специальный тикет с описанием, где указано, какие компоненты из дизайн-системы нужно использовать, и какие токены для них. Это тоже проходит ревью у разработчиков.
Коммуникация, наверное, как у всех: почта, чат, трекер задач. В былые времена еще можно было подойти и обсудить что-то за чашкой чая :)
Про IT-инфраструктуру: есть разные команды которые отвечают за релиз, внутренние сервисы, тестовое окружение и так далее. Все процессы стараемся автоматизировать.
С инструментами все более-менее стандартно, разве что есть разные сервисы мониторинга, нотификации в чат, автоматизированные релизы мобильных приложений(можно прочитать тут habr.com/ru/company/badoo/blog/509238), remote builds для Android разработчиков.
По моему мнению, в процессе миграции на Kotlin нет ничего сложного. Kotlin и Java могут существовать одновременно в одном проекте, т. е. нет необходимости переписывать весь код, чтобы начать использовать Kotlin. Разве что некоторые вызовы Kotlin кода из Java могут выглядеть некрасиво, и возможно некоторое увеличение времени сборки. Мы просто стали писать новые фичи на Kotlin, оставив старый код на Java. Со временем старый код подвергается рефакторингу и переписывается уже на Kotlin.
Дальше в работу вступает специальная команда MAPI, которая разрабатывает протокол общения между клиентом и сервером, описывает, как должен вести себя клиент в той или иной ситуации. Затем это проходит ревью у команд, которые будут все реализовывать. Если нужен дизайн, то дизайнер делает специальный тикет с описанием, где указано, какие компоненты из дизайн-системы нужно использовать, и какие токены для них. Это тоже проходит ревью у разработчиков.
Коммуникация, наверное, как у всех: почта, чат, трекер задач. В былые времена еще можно было подойти и обсудить что-то за чашкой чая :)
Про IT-инфраструктуру: есть разные команды которые отвечают за релиз, внутренние сервисы, тестовое окружение и так далее. Все процессы стараемся автоматизировать.
С инструментами все более-менее стандартно, разве что есть разные сервисы мониторинга, нотификации в чат, автоматизированные релизы мобильных приложений(можно прочитать тут habr.com/ru/company/badoo/blog/509238), remote builds для Android разработчиков.
По моему мнению, в процессе миграции на Kotlin нет ничего сложного. Kotlin и Java могут существовать одновременно в одном проекте, т. е. нет необходимости переписывать весь код, чтобы начать использовать Kotlin. Разве что некоторые вызовы Kotlin кода из Java могут выглядеть некрасиво, и возможно некоторое увеличение времени сборки. Мы просто стали писать новые фичи на Kotlin, оставив старый код на Java. Со временем старый код подвергается рефакторингу и переписывается уже на Kotlin.
Привет, читала про MVICore, насколько я поняла, вся бизнес-логика инкапсулирована в Feature, и они взаимодействуют друг с другом (а так же их может быть несколько на экран). Хотелось бы увидеть более advanced примеры кода, чем sample у вас в репозитории на гитхабе :) ну или хотя бы на пальцах узнать как конкретно взаимодействуют две фичи на абстрактном примере.
MVICore выступает базовым инструментов на поверх которого строятся более сложные решения. Для простых экранов достаточно одной фичи на экран, которая держит всю логику. Из минусов этого подхода — мы не сможем переиспользовать какую-то более мелкую часть фичи в другом контексте.
В данный момент мы используем компоненты (RIBs), у которых есть чёткий контракт взаимодействия, внутри которых находится фича, которая содержит нужную бизнес логику.
Я распишу на примере такого компонента, где есть коммуникация между рибами.
1. Компонент, который позволяет выбрать элемент из списка и сообщить о выбранном элементе родителю.
2. Компонент, который отображает ввод номера телефона вместе со страной (с возможностью сменить страну на другую)
3. Компонент, который связывает эти 2. Сообщает о том, что 2ой хочет выбрать элемент, возвращает выбранный элемент из 1ого компонента 2ому.
Мы можем заменить рибы на фрагменты и добьёмся того же.
Допустим у вас на экране одновременно отображаются 2 фрагмента, которые позволяют выбрать страну на первом фрагменте, и она отобразится на 2ом фрагменте. В таком случае у нас есть 2 независимые ничего не знающие друг о друге фичи (которые живут внутри фрагментов) и некий родитель, который их связывает между собой.
В данный момент мы используем компоненты (RIBs), у которых есть чёткий контракт взаимодействия, внутри которых находится фича, которая содержит нужную бизнес логику.
Я распишу на примере такого компонента, где есть коммуникация между рибами.
1. Компонент, который позволяет выбрать элемент из списка и сообщить о выбранном элементе родителю.
2. Компонент, который отображает ввод номера телефона вместе со страной (с возможностью сменить страну на другую)
3. Компонент, который связывает эти 2. Сообщает о том, что 2ой хочет выбрать элемент, возвращает выбранный элемент из 1ого компонента 2ому.
Мы можем заменить рибы на фрагменты и добьёмся того же.
Допустим у вас на экране одновременно отображаются 2 фрагмента, которые позволяют выбрать страну на первом фрагменте, и она отобразится на 2ом фрагменте. В таком случае у нас есть 2 независимые ничего не знающие друг о друге фичи (которые живут внутри фрагментов) и некий родитель, который их связывает между собой.
Какие решения используете для теханалитики (краши, анализ производительности и т. п.)?
Есть планы отказаться от нативной разработки и перейти на кросс-платформенные фреймворки типа flutter?
Какие вопросы задаете на собеседованиях мидлам? :)
Есть планы отказаться от нативной разработки и перейти на кросс-платформенные фреймворки типа flutter?
Какие вопросы задаете на собеседованиях мидлам? :)
Для технической аналитики мы используем своё внутреннее кроссплатформенное решение Gelato. Сделать своё мы решили из-за того, что у всех существующих систем присутсвуют те или иные ограничения (например, AppCenter не принимает более 60 сообщений об ошибке в минуту, а Crashlytics сохраняет не более восьми отчётов за сессию). Также это позволяет нам реализовывать любые хотелки, от фильтрации по специфичным полям, до улучшенных алгоритмов группировки отчётов.
Для анализа производительности мы сделали opensource-проект Jinba. Если коротко, этот инструмент позволяет размечать в коде начало и конец события, и затем во время выполнения измеряет продолжительность этого события. По этим данным строятся статистические графики, на которых заметно улучшение или ухудшение производительности. Подробнее можно посмотреть в нашем докладе или в этих слайдах.
Планов отказываться от нативной разработки у нас нет. Но мы с интересом исследуем возможность использования Kotlin Multiplatform. Про это у нас уже есть несколько статей (например, Архитектурный шаблон MVI в Kotlin Multiplatform, часть 1).
А по поводу вопросов на собеседовании — лучше один раз увидеть, чем сто раз услышать.
Для анализа производительности мы сделали opensource-проект Jinba. Если коротко, этот инструмент позволяет размечать в коде начало и конец события, и затем во время выполнения измеряет продолжительность этого события. По этим данным строятся статистические графики, на которых заметно улучшение или ухудшение производительности. Подробнее можно посмотреть в нашем докладе или в этих слайдах.
Планов отказываться от нативной разработки у нас нет. Но мы с интересом исследуем возможность использования Kotlin Multiplatform. Про это у нас уже есть несколько статей (например, Архитектурный шаблон MVI в Kotlin Multiplatform, часть 1).
А по поводу вопросов на собеседовании — лучше один раз увидеть, чем сто раз услышать.
Хей. Мы с коллегами ранее тестировали машинное обучение на вашем приложении. Скажите, те несколько человек, которые посещают аккаунт в момент его создания — они боты или это просто в бизнес-логике зашито? Если мне и коллегам показалось — скажите, мы поймем ;)
Спасибо за вопрос!
У нас нет ботов в продуктах и мы не создаем искусственных пользователей. Совершенно непонятно, зачем это вообще можно было бы делать — в Badoo почти полмиллиарда зарегистрированных пользователей и несколько десятков миллионов активной месячной аудитории. Все люди, с которыми взаимодействуют наши пользователи, — это реальные люди.
У нас нет ботов в продуктах и мы не создаем искусственных пользователей. Совершенно непонятно, зачем это вообще можно было бы делать — в Badoo почти полмиллиарда зарегистрированных пользователей и несколько десятков миллионов активной месячной аудитории. Все люди, с которыми взаимодействуют наши пользователи, — это реальные люди.
Привет! Расскажите более подробно о видео стриминге в Badoo. Какие библиотеки/компоненты используете для трансляций в мобильных приложениях Android/iOS, на вебсайте, а также на бэкенде? Используете какие-нибудь готовые решения типа Wowza/Nimble/Red5 или у вас все написано с нуля на собственном движке? Спасибо.
Тажке интересует вопрос как вы модерируете трансляции на предмет наличия эротики/порно. Сервис трансляций каждые 5-10 секунд выдергивает кадры из трансляции и отправляет на анализ в нейросетьTensorflow или есть модераторы?
НЛО прилетело и опубликовало эту надпись здесь
Да, сервис 18+, но что на это скажет AppStore/GooglePlay?
НЛО прилетело и опубликовало эту надпись здесь
На вебкамах контент тоже создают пользователи, но почему-то их нет в AppStore/GooglePlay. С чат-рулеткой немного проще потому, что там можно смотреть одновременно только одну трансляцию и нельзя посмотреть список всех трансляций на одной странице.
Это все в теории или у вас есть опыт в запуске таких приложений/вебсайтов?
Это все в теории или у вас есть опыт в запуске таких приложений/вебсайтов?
Cейчас видеостриминг отключен, там использовались комбинированные решения, в том числе и WebRTC, который мы сейчас используем в видеозвонках, по поводу использования WebRTC в видеозвонках у нас есть статья.
Есть ли корреляция между скиллом программирования и количеством дам?
Подскажите, а как справляетесь с начальным состоянием в фичах mvicore, чтобы оно не порождало дальше события по цепочке связей?
Т. е. Грузится экран, инициализируются фтчи и начинабтся ненужные инит состояния.
Привет!
1. Как у вас происходит процесс релиза? Используете какие-то системы или передаёте apk через флешку?)
2. Как быстро происходит внедрение новых инструментов google? Уже используете, например, data binding или navigation components?
1. Как у вас происходит процесс релиза? Используете какие-то системы или передаёте apk через флешку?)
2. Как быстро происходит внедрение новых инструментов google? Уже используете, например, data binding или navigation components?
- По расписанию создается новая ветка релиза, собирается apk, прогоняются все автоматические тесты. Далее тестировщик делает финальное ручное тестирование. Если блокирующих багов не найдено, то начинается процесс публикации. Публикация происходит постепенно с 1%. Если в дальнейшем будут найдены баги которые необходимо пофиксить в текущем релизе(сломалась целиком часть функционала, увидели большое количество запросов которые спамят сервер), то создаются задачи для их исправления которые будут замержены в текущий релиз, после чего он будет опубликован заново. Процесс публикации автоматизирован и требует минимальных усилий со стороны QA. В качестве CI используется TeamCity, артефакты хранятся удаленно, флешку использовать нет необходимости :) Также есть ежедневная автоматическая публикация beta версий после завершения всех тестов. Про автоматизацию релизов совсем недавно вышла статья.
- Из AndroidX используем не так уж и много: AppCompat, View библиотеки(ConstraintLayout, RecyclerView, и тд), Fragment, Biometric, совсем недавно стали интегрировать Room. Планов по интеграции новых пока нет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ask me anything! Задай вопрос Android-команде Badoo