Интересная уязвимость. Но можно было бы наверное исправить её, сделав сам диалог запрос слегка прозрачным. Тогда перекрыть уже будет не так просто, наложение будет бросаться в глаза мне кажется)
А нам и не надо) Мы работу работаем) Кратко задать вопрос или кратко ответить на него. Всё по делу, без воды и прочего. Созвоны на случай, если текст печатать дольше чем сказать. На потрещать на жизнь кто хочет — бары, конференции, митапы.
Ну так 10-15 лет назад всё это было. И почему-то раньше это называлось проще — процесс знакомства с командой/менеджером/тулзами/софтом. И всё же было ок. Из этого не делали ракет сайенс:) Без модных слов, исследований и фокус групп)
Это всё действительно нужно? Просто странно, в эти конторы зачастую надо пройти достаточно мощные собесы, чтобы потом нянчиться с сотрудником как с джуном без опыта..
которые обладали очень медленным перфомансом при поиске выбранных элементов
Привет, а в чём были просадки производительности? В любом случае все такие решение приводят к использованию map подобных штук… а её производительность при нормальных условиях — достаточная для этой задачи точно)
Да даже если бэк там совсем днище, то надо не очень много разрабов, чтобы сделать хороший "фасад", который предоставит норм апи. Что делают остальные — загадка..
всё упиралось в необходимость доработок бэка, на которые у нас не было ресурсов.
Т.е. иметь овер 100 человек только в мобильной команде — норм, а дорабатывать по сути "ядро" системы — нет ресурсов?) Это как так?)
Мобильное приложение выступало аналогом браузера или тонкого клиента — отображало то, что отдавал бэкенд.
Так это ж server-driven-ui. К нему как раз многие и стремятся, чтобы управлять приложением, а вы от него ушли как раз по причине выше?)
Бэкенд не разрабатывается только под мобильное приложение или только под сайт. Мы идём в сторону омниканальности и унификации.
А разве это не хуже? Такое обычно приводит к тому, что не удобно всем. Скажем частый костыль — вместо одного запроса к серверу, нужно делать два, чтобы "смержить" нужные данные… потому что "апи не заточено под конкретную задачу конкретной платформы"
Так чем вас не устраивает текущий ЖЦ у view? Да может он не оптимальный для задачи. Но в среднем по больнице работать всё будет.
Есть вью на экране — подписались, нет — отписались..
Посмотрите как работает ViewModel внутри. Там похожая идея внутри. Может вам внутри вью создавать собственный скоуп, который вы будет использовать, и который будете закрываться когда вью детачится.
Только onCompletion вроде будет вызываться только если скоуп закроется…
Также ещё у SharedFlow есть onSubscription + subscriptionCount свойство. Но я их не смотерл сам ещё.
И сейчас можно проще. Возьмём описанный в статье сценарий.
Если вы такие вещи делаете каждый день, то да, стоит заморочиться и сделать мини фреймворк, чтобы в будущем жилось легче. А если нет? Если такую штуку вам надо реализовать 1 раз в 2 года? Тогда решение упрощается в 10 раз, и не надо никаких велосипедов — хардкодите 5 фрагментов между собой и простенький класс для хранения результата.
Любой похожий пошаговый динамический сценарий отлично ложится на реализацию стейт машины.
Т.е. текущий завершаемый шаг сам знает какой шаг запустить следующим на основе результата и сможет передать валидные данные необходимые следующему шагу.
Сейчас, например, при более сложном сценарии ваш класс ApplicationScenario превратится в месиво условий..
АЧХ за 62000р видимо в комплект не входит даже) Надо доплатить?)
Интересная уязвимость. Но можно было бы наверное исправить её, сделав сам диалог запрос слегка прозрачным. Тогда перекрыть уже будет не так просто, наложение будет бросаться в глаза мне кажется)
Они же написали — "Получить и узнать"! Отвечать никто не обещал же:)
А нам и не надо) Мы работу работаем) Кратко задать вопрос или кратко ответить на него. Всё по делу, без воды и прочего. Созвоны на случай, если текст печатать дольше чем сказать. На потрещать на жизнь кто хочет — бары, конференции, митапы.
Ну так 10-15 лет назад всё это было. И почему-то раньше это называлось проще — процесс знакомства с командой/менеджером/тулзами/софтом. И всё же было ок. Из этого не делали ракет сайенс:) Без модных слов, исследований и фокус групп)
Это всё действительно нужно? Просто странно, в эти конторы зачастую надо пройти достаточно мощные собесы, чтобы потом нянчиться с сотрудником как с джуном без опыта..
Привет, а в чём были просадки производительности? В любом случае все такие решение приводят к использованию map подобных штук… а её производительность при нормальных условиях — достаточная для этой задачи точно)
Да даже если бэк там совсем днище, то надо не очень много разрабов, чтобы сделать хороший "фасад", который предоставит норм апи. Что делают остальные — загадка..
Т.е. иметь овер 100 человек только в мобильной команде — норм, а дорабатывать по сути "ядро" системы — нет ресурсов?) Это как так?)
Так это ж server-driven-ui. К нему как раз многие и стремятся, чтобы управлять приложением, а вы от него ушли как раз по причине выше?)
А разве это не хуже? Такое обычно приводит к тому, что не удобно всем. Скажем частый костыль — вместо одного запроса к серверу, нужно делать два, чтобы "смержить" нужные данные… потому что "апи не заточено под конкретную задачу конкретной платформы"
Так чем вас не устраивает текущий ЖЦ у view? Да может он не оптимальный для задачи. Но в среднем по больнице работать всё будет.
Есть вью на экране — подписались, нет — отписались..
Ну либо надо менять подход. Не делать умную View, а передавать данные в неё из вне..
См.выше мой коммент про скоупы как раз)
Посмотрите как работает ViewModel внутри. Там похожая идея внутри. Может вам внутри вью создавать собственный скоуп, который вы будет использовать, и который будете закрываться когда вью детачится.
Только onCompletion вроде будет вызываться только если скоуп закроется…
Также ещё у SharedFlow есть onSubscription + subscriptionCount свойство. Но я их не смотерл сам ещё.
Самое примитивное внутри view — сохранять джобу после collect, и отменять её, когда вью детачится от window
У Flow есть onStart/OnComplete события. Не то?
lifecycleScope.launchWhenStarted может вам помочь
И сейчас можно проще. Возьмём описанный в статье сценарий.
Если вы такие вещи делаете каждый день, то да, стоит заморочиться и сделать мини фреймворк, чтобы в будущем жилось легче. А если нет? Если такую штуку вам надо реализовать 1 раз в 2 года? Тогда решение упрощается в 10 раз, и не надо никаких велосипедов — хардкодите 5 фрагментов между собой и простенький класс для хранения результата.
Любой похожий пошаговый динамический сценарий отлично ложится на реализацию стейт машины.
Т.е. текущий завершаемый шаг сам знает какой шаг запустить следующим на основе результата и сможет передать валидные данные необходимые следующему шагу.
Сейчас, например, при более сложном сценарии ваш класс ApplicationScenario превратится в месиво условий..
Почему не рассмотрели вариант со стейт машиной?
Всё верно. Но не забывайте, что текущий вариант вылизывался 10+ лет под типичные юзкейсы приложений.