#вакансия #москва #спб #android #kotlin #java #мобильная_разработка

📌 Название компании: Яндекс

📌 Город и адрес офиса:  Москва, Санкт-Петербург

📌 Формат работы: офис

📌 Занятость: полная

📌 Зарплатная вилка : от 80 000 ₽ до 300 000 ₽

Описание вакансии:

Мы — команда мобильной разработки Вертикалей, которая занимается развитием сервисов объявлений Яндекса (Авто.ру, Яндекс.Недвижимость, Яндекс.Работа). Мы работаем в двух городах — в Москве и в Петербурге, но это совсем не мешает нам быть той самой дружной командой, о которой пишут в вакансиях. Мы не готовы расширять эту географию или работать с удаленными сотрудниками, но готовы перевезти хороших кандидатов поближе к себе.
Мы расширяемся, потому что хотим быстрее развивать наши приложения, добавлять новые разделы, а старые делать лучше. Для этого мы ищем сильных Android-разработчиков. Мы используем Clean Architecture, MVP, RxPM и Android Components. Мы открыты для предложений по улучшению кода и архитектуры и стараемся, чтобы каждый был услышан. Мы любим Kotlin и RxJava, если вы любите их так же, как и мы, то приходите пообщаться!

Откликнуться: https://yandex.ru/jobs/vacancies/dev/dev_android_vertikali/ или v-kuznetsova@yandex-team.ru

Ничоси

Это победа, ребята 👍

Юра, это правда?)

👍

Ну я думаю, да 😄

Без собеседования возьмут?)

Юра ворвался прям! Приветосы тебе. 👋

Ребята, а кто делал bottomsheetdialog с pm-кой? От чего наследоваться что бы делегат подключить?

Так вроде прикол делегата в том, чтобы не было нужды наследоваться

Просто дергаешь его методы у себя и радуешься

По аналогии с существующими имплементациями

Я имею в виду что у делегата нужно вызвать методы attach detach...

Попробуй чекнуть как реализован PmSupportFragment

Мне бы хотелось подставить мой диалог в dialogControl + что бы в нем была pm-ka. Возможно ли так сделать?  У меня нет подходящего делегата, поэтому я не понимаю от какого класса мне наследоваться. От фрагмента?

Леша, в текущей версии библиотеки так сделать не получится. Если тебе нужна ПМ-ка в диалоге, то нужно создавать делегат для DialogFragment. DialogControl спроектирован для простых алертов.

Возник вопрос о том, как правильно предоставлять scoped-зависимости разным пм-кам.

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

Что я делаю сейчас:
Создаю инстанс DI-контейнера и поддерживаю его на уровне ЖЦ флоу фрагмента (до тех пор, пока на нем не будет вызван onDestroy с activity.isChangingConfiguration == false). В методе providePresentationModel чайлд фрагментов вытягиваю из этого DI-контейнера пм-ки. Но! Это неправильно, ведь мой способ поддержки инстанса DI-контейнера отличается от способа поддержки инстанса пм-ки через Outlast на уровне либы. Поэтому возможна ситуация, когда scoped-зависимости из этого DI-контейнера будут разными в пм-ках у разных фрагментов в рамках одного родительского фрагмента. То есть случай, когда мой инстанс DI-контейнера пересоздался, а пм-ки, которые лежат в Outlast -- нет, и тут пользователь открывает новый экран в рамках существующего флоу.

И сам вопрос:
Правильно ли я понимаю, что в силу специфики либы (использование Outlast под капотом), мне следует либо использовать Outlast для хранения DI-контейнера со scoped-зависимостями пм-ок, либо реализовать у себя такое управление ЖЦ DI-контейнера, которое соответствует тем условиям, которые прописаны в Outlast?

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

Привет, очень много написал, теряется суть вопроса. Давай я уточню.

1. Вопрос о том как сделать общие данные для нескольких PM?

2. Scoped или нет так ли важно для этого вопроса? Если да, то почему?

3. Смотрел ли ты на childPm понятие в либе? Может оно тебе зайдет.

4. Для чего именно (в 5 словах) тебе свой di для пм-ок?

5. Используешь ли ты Клин или хотя бы есть у тебя репозиторий?

1. Да.
2. Важно. Потому что я хочу давать пм-кам общий объект, который привязан к жизни некоторого родительского фрагмента этих экранов. И вопрос именно об этом.
3. Да, про childPm знаю, но не уверен, подойдет ли это в обсуждаемом мною кейсе. Подумаю над этим.
4. Создаю через даггеровский компонент пм-ки с нужными им зависимостями в providePresentationModel.
5. Да, использую. Но речь идет о данных, насчет которых я не уверен, следует ли их хранить в репозитории.

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