Ну на вскидку у esp32 чипа нет конкурентов и они реально ими все завалили. Хотя я не знаю где их производят реально. Также из того чем сам пользовался - emw3165, gd32 (аналог stm32) ну и остальное по мелочам.
Как обычно качество всего не ух и ах, но в принципе пользоваться можно.
нет родных компонент к которым привыкли (pager & etc)
Медленнее работа и загрузка
Плюсы: Анимашки (что безусловно важно для банковского приложения)
Ну и понравилась архитектура mvi при условии использования viewModel :)
Лично мне хотелось бы услышать белого о том насколько просто менять приложение согласно"последним, последним" требованиям, которые изменяют навигационный стек...
В общем что-то из реальной жизни, а не мы сделали список и он заработал....
Kinesis advantage 2 не сплит, но после 5 лет использования работу без нее не представляю. Пару месяцев привыкания и теперь очень трудно на обычных работать даже непродолжительное время.
Ну и бонусом ушли проблемы с запястьем, шеей и прочим. Конечно все в комплексе, но правильная посадка начинается с клавиатуры.
Ну если бы это была официальная политика партии, то они бы опубликовали такое заявление на android.com
Ну и я бы хотел верить, что разногласия там все же есть :) Это полезно для нас :)
Я согласен, что штука похожая, но вот была отличная штука, которая наконец смогла подружится с ЖЦ view, не сильно затратная. А потом сделали похожая, только без синхронизации ЖЦ с кучей API и вариантов использования.
И многие тут же ринулись под эти знамёна. Я не против, я просто аргументов не вижу.
А сущности тут наплодили достаточно. Можно на handler и thread это все сделать, собственно лет 10 назад так и писал. А потом asynctadk, loaders, fragment, workers и теперь корутины... С тех пор не спешу с миграциями, без хороших аргументов :)
Ну это статья на medium с мнением одного человека.
Ну и суть не в этом. Такая рекомендация была и вполне была обоснована. Чем обоснован переход на flow я не вижу и даже не вижу попыток это объяснить....
Я так и не понял зачем вы сделали миграцию в сторону сложности... Гибкости я в ваших примерах не увидел. И вы правильно сказали, что flow сделан для общения между корутинами. Но у нас view <-> viewmodel.
Можно привести пример, что сделать на flow можно лучше, или удобнее в разрезе заявленной задачи. Я как flow не крутил в данном контексте им применения не смог найти. Ну т.е. можно, но зачем?
Ну и google рекомендует конвертировать flow в livedata перед передачей в view.
Насколько я понял из статьи проблемы были бы, даже если ПО выдало правильный результат, т.к. просто сделали бы меньше зазоры, которые и так сделали меньше просто на всякий случай.
Ну на вскидку у esp32 чипа нет конкурентов и они реально ими все завалили. Хотя я не знаю где их производят реально. Также из того чем сам пользовался - emw3165, gd32 (аналог stm32) ну и остальное по мелочам.
Как обычно качество всего не ух и ах, но в принципе пользоваться можно.
Все что вынес:
Минусы:
нет родных компонент к которым привыкли (pager & etc)
Медленнее работа и загрузка
Плюсы: Анимашки (что безусловно важно для банковского приложения)
Ну и понравилась архитектура mvi при условии использования viewModel :)
Лично мне хотелось бы услышать белого о том насколько просто менять приложение согласно"последним, последним" требованиям, которые изменяют навигационный стек...
В общем что-то из реальной жизни, а не мы сделали список и он заработал....
Kinesis advantage 2 не сплит, но после 5 лет использования работу без нее не представляю. Пару месяцев привыкания и теперь очень трудно на обычных работать даже непродолжительное время.
Ну и бонусом ушли проблемы с запястьем, шеей и прочим. Конечно все в комплексе, но правильная посадка начинается с клавиатуры.
Ну если бы это была официальная политика партии, то они бы опубликовали такое заявление на android.com
Ну и я бы хотел верить, что разногласия там все же есть :) Это полезно для нас :)
Я согласен, что штука похожая, но вот была отличная штука, которая наконец смогла подружится с ЖЦ view, не сильно затратная. А потом сделали похожая, только без синхронизации ЖЦ с кучей API и вариантов использования.
И многие тут же ринулись под эти знамёна. Я не против, я просто аргументов не вижу.
А сущности тут наплодили достаточно. Можно на handler и thread это все сделать, собственно лет 10 назад так и писал. А потом asynctadk, loaders, fragment, workers и теперь корутины... С тех пор не спешу с миграциями, без хороших аргументов :)
Deleted
Ну это статья на medium с мнением одного человека.
Ну и суть не в этом. Такая рекомендация была и вполне была обоснована. Чем обоснован переход на flow я не вижу и даже не вижу попыток это объяснить....
Я так и не понял зачем вы сделали миграцию в сторону сложности... Гибкости я в ваших примерах не увидел. И вы правильно сказали, что flow сделан для общения между корутинами. Но у нас view <-> viewmodel.
Можно привести пример, что сделать на flow можно лучше, или удобнее в разрезе заявленной задачи. Я как flow не крутил в данном контексте им применения не смог найти. Ну т.е. можно, но зачем?
Ну и google рекомендует конвертировать flow в livedata перед передачей в view.
Насколько я понял из статьи проблемы были бы, даже если ПО выдало правильный результат, т.к. просто сделали бы меньше зазоры, которые и так сделали меньше просто на всякий случай.
Рекомендую diptrace. Более чем удобный и условно бесплатный.