Старые версии библиотек в большинстве случаев не удаляют. Хочешь как раньше, загрузи и мучайся. Хочешь быть на волне, адаптируйся, развивайся. Никакого тупика нет, разве что в голове.
Реактивная архитектура, безусловно, заслуживает внимания. Более того, даже архитектура экрана, изначально использующая лишь один запрос, со временем будет расшириться.
Есть предложение по развитию этой идеи. Можно использовать Combine для всех useCase'ов + intentsFlow, в который будет эмиттиться из других функций viewModel. Из useCase будет торчать flow. Метод reload(): Unit можно добавить в каждый useCase. Если нужно форсировать перезагрузку каждый раз, можно в useCase добавить reloadFlow(): Flow<T>.
Использование use case везде — это вынужденная мера для сохранения единого стиля, консистентности и архитектуры. Если никто не запретит использовать repository напрямую, то на одном экране будут использованы use case, на другом repository во view model. А на третьем, однажды, вообще решат, что view model — ни к чему, можно запросы дергать из UI кода. Архитектура — есть архитектура. Рассуждения о том, что где-то лишнее приводит лишь к халиварам.
Если вопрос в том, что для простого приложения, по типу todo list, не нужно использовать use case, то соглашусь. MVP Todo list не предполагает логики кроме получения списка и добавления новой записи. Но позже, вероятно, может потребоваться расширение. В таком случае, для выстраивания архитектуры может быть необходимость какой-то код перенести в use case. А для того, чтобы код был идентичен, придется везде мигрировать на use case.
Мало того, что получить middle. Недавно пришлось собеседовать человека, который позиционировал себя как m+, мощное CV. А оказалось, что даже базово языка, не говоря уже о платформе, не знает.
Как можно быть продуктивным с Windows, когда столько мощных тайтлов стабильно выкатывают. Это как с PS. Как быть продуктивным, когда плойка стоит бедная, нетронутая, одинокая.
Rust - очень странный язык для извращенцев. Такое впечатление я получил после нескольких статей о нем. Конечно, у него есть много преимуществ, которыми болеет C, однако стоят ли они того комфорта и выразительности.
Да простят меня фанаты Rust, но я категорически не понимаю почему настолько намудрили, а красивый синтаксис так и не придумали. Выглядит как мертво-рожденный язык.
В любом случае, спасибо за статью. Но она не добавила ни копейки (цента) в желание хотя бы попробовать язык. Натерпелся с Ruby в свое время, хотя это азиатское изобретение — действительно полюбилось.
Ох.. давно собирался и копил силы.. и вот теперь наконец‑то решился.. с болью в сердце.. с небольшим дурманом в голове.. мам, пап, я — программист.. надеюсь вы не будете злиться...
Вот ещё идеи: когда о человеке можно сказать, что он спился или как обнаружить гея в офисе, где все - дизайнеры или пишут только под iOS... (сори, старые мемы в чате)
Да, действительно, если удалить View с экрана, а корутина была запущена во View, то необходимо проследить и отменить выполнение корутины.
Действительно если какая-то лишняя логика, особенно асинхронная, выполняется внутри View - это не очевидное и проблемное решение. Однако никто не мешает имплементировать анимацию используя корутины.
Да, я думал делать картинками или кодом, но решил сохранить в этом случае, как в оригинале. В следующий раз, постараюсь делать либо ссылку на GitHub, либо вставлять код вместо картинок.
Довольно часто мобильное приложение подтормаживает, если вы производите тяжелые задачи на основном потоке. Так же, естественно, что гибридное приложение будет работать медленнее и тяжелее, чем если бы делали нативную версию. В любом случае, думаю есть моменты, которые явно возможно поправить и приложение начнет работать стабильнее и быстрее.
А где же гифки?
Старые версии библиотек в большинстве случаев не удаляют. Хочешь как раньше, загрузи и мучайся. Хочешь быть на волне, адаптируйся, развивайся. Никакого тупика нет, разве что в голове.
Реактивная архитектура, безусловно, заслуживает внимания. Более того, даже архитектура экрана, изначально использующая лишь один запрос, со временем будет расшириться.
Есть предложение по развитию этой идеи. Можно использовать Combine для всех useCase'ов + intentsFlow, в который будет эмиттиться из других функций viewModel. Из useCase будет торчать flow. Метод reload(): Unit можно добавить в каждый useCase. Если нужно форсировать перезагрузку каждый раз, можно в useCase добавить reloadFlow(): Flow<T>.
А почему не использовать popup?
Использование use case везде — это вынужденная мера для сохранения единого стиля, консистентности и архитектуры. Если никто не запретит использовать repository напрямую, то на одном экране будут использованы use case, на другом repository во view model. А на третьем, однажды, вообще решат, что view model — ни к чему, можно запросы дергать из UI кода. Архитектура — есть архитектура. Рассуждения о том, что где-то лишнее приводит лишь к халиварам.
Если вопрос в том, что для простого приложения, по типу todo list, не нужно использовать use case, то соглашусь. MVP Todo list не предполагает логики кроме получения списка и добавления новой записи. Но позже, вероятно, может потребоваться расширение. В таком случае, для выстраивания архитектуры может быть необходимость какой-то код перенести в use case. А для того, чтобы код был идентичен, придется везде мигрировать на use case.
🤣🤣🤣🤣🤣
А что из этого российское или содружества?
Яндекс и атом )
Мало того, что получить middle. Недавно пришлось собеседовать человека, который позиционировал себя как m+, мощное CV. А оказалось, что даже базово языка, не говоря уже о платформе, не знает.
Как можно быть продуктивным с Windows, когда столько мощных тайтлов стабильно выкатывают. Это как с PS. Как быть продуктивным, когда плойка стоит бедная, нетронутая, одинокая.
Может тогда вообще постгрес сиквел
На приколе? Ничего, что хром работает в штатном режиме?!
В ближнем будущем, Яндекс Такси убирает лишнее слово — Яндекс. Теперь сервис слово зарезервировано за бессмертным сервисом.
Rust - очень странный язык для извращенцев. Такое впечатление я получил после нескольких статей о нем. Конечно, у него есть много преимуществ, которыми болеет C, однако стоят ли они того комфорта и выразительности.
Да простят меня фанаты Rust, но я категорически не понимаю почему настолько намудрили, а красивый синтаксис так и не придумали. Выглядит как мертво-рожденный язык.
В любом случае, спасибо за статью. Но она не добавила ни копейки (цента) в желание хотя бы попробовать язык. Натерпелся с Ruby в свое время, хотя это азиатское изобретение — действительно полюбилось.
Ох.. давно собирался и копил силы.. и вот теперь наконец‑то решился.. с болью в сердце.. с небольшим дурманом в голове.. мам, пап, я — программист.. надеюсь вы не будете злиться...
Вот ещё идеи: когда о человеке можно сказать, что он спился или как обнаружить гея в офисе, где все - дизайнеры или пишут только под iOS... (сори, старые мемы в чате)
Да, действительно, если удалить View с экрана, а корутина была запущена во View, то необходимо проследить и отменить выполнение корутины.
Действительно если какая-то лишняя логика, особенно асинхронная, выполняется внутри View - это не очевидное и проблемное решение. Однако никто не мешает имплементировать анимацию используя корутины.
Да, я думал делать картинками или кодом, но решил сохранить в этом случае, как в оригинале. В следующий раз, постараюсь делать либо ссылку на GitHub, либо вставлять код вместо картинок.
Довольно часто мобильное приложение подтормаживает, если вы производите тяжелые задачи на основном потоке. Так же, естественно, что гибридное приложение будет работать медленнее и тяжелее, чем если бы делали нативную версию. В любом случае, думаю есть моменты, которые явно возможно поправить и приложение начнет работать стабильнее и быстрее.
Спасибо большое за фидбек, для меня это действительно важно. Приму все пункты и в следующий раз будет намного лучше.