Size: a a a

2019 April 19

YS

Yuri Shmakov in RxPM
#вакансия #москва #спб #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
источник

L

Leo in RxPM
Ничоси
источник

L

Leo in RxPM
Это победа, ребята 👍
источник

DG

Dmitriy Gorbunov in RxPM
Yuri Shmakov
#вакансия #москва #спб #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
Юра, это правда?)
источник

MZ

Mikhail Zisman in RxPM
👍
источник

YS

Yuri Shmakov in RxPM
Ну я думаю, да 😄
источник

DG

Dmitriy Gorbunov in RxPM
Yuri Shmakov
Ну я думаю, да 😄
Без собеседования возьмут?)
источник

VC

Vasili Chyrvon in RxPM
Yuri Shmakov
#вакансия #москва #спб #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
Юра ворвался прям! Приветосы тебе. 👋
источник
2019 April 20

c

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

L

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

L

Leo in RxPM
Просто дергаешь его методы у себя и радуешься
источник

L

Leo in RxPM
По аналогии с существующими имплементациями
источник

c

cellphone jesus in RxPM
Я имею в виду что у делегата нужно вызвать методы attach detach...
источник

L

Leo in RxPM
Попробуй чекнуть как реализован PmSupportFragment
источник
2019 April 21

c

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

DG

Dmitriy Gorbunov in RxPM
cellphone jesus
Мне бы хотелось подставить мой диалог в dialogControl + что бы в нем была pm-ka. Возможно ли так сделать?  У меня нет подходящего делегата, поэтому я не понимаю от какого класса мне наследоваться. От фрагмента?
Леша, в текущей версии библиотеки так сделать не получится. Если тебе нужна ПМ-ка в диалоге, то нужно создавать делегат для DialogFragment. DialogControl спроектирован для простых алертов.
источник
2019 April 28

UH

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

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

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

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

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

VC

Vasili Chyrvon in RxPM
Untamed Horse
Возник вопрос о том, как правильно предоставлять 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. Используешь ли ты Клин или хотя бы есть у тебя репозиторий?
источник

UH

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

UH

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