Варианты 2 и 4 по сути одинаковые (и немного некорректые), потому что ничто в вашем примере не указывает какой должен быть фон (android:windowBackground аттрибут в теме).
Был бы windowBackground черным, отобразился бы черный цвет. Этот фон рендерится еще до любых колбеков в Activity - можно сделать sleep хоть в Application::onCreate
Нет, все корректно. Вообще неважно какой там телефон, АПИ должно работать одинаково.
Но если вы хотите сравнить с "камерофоном", то в статье как раз написано про Pixel, у которого одна из лучших камер, и АПИ там все равно сломано, при том что ребята вроде бы в одной компании работают.
Достаточно закрыть экран бумажкой, и весь свет перейдёт в тепло
Конечно же нет. Такое произойдет только если бумажка не пропускает и не отражает свет, то есть является абсолютно черным телом, чего в принципе не бывает.
Но я как бы не пытаюсь спорить кто больше жрет - проц или экран, я понятия не имею. Просто пытаюсь донести, что нельзя все сравнивать по тепловыделению. Энергия может преобразовываться в очень разные виды
Смартфон не делает «полезную работу» (в физическом смысле этого термина
Да? А как тогда переносится заряд от батареи к компонентам?
как произведение силы на перемещение
Это механическая работа.
Но речь даже не об этом. Заставить светиться экран - это тоже затраты энергии. Энергия аккумулятора переходит в кинетическую энергию фотонов, и частично в нагрев компонентов.
Название MVI, которое, вроде как, Hannes Dorfmann придумал в 2017, по сути и является недо-Redux-ом. Никогда не понимал зачем было это по-другому называть.
Saved instance хранится в системном сервисе Activity Manager, который отвечает за создание и восстановление Activity.
То что вы можете воспроизвести это с флагом, не значит, что без флага в реальной ситуации убивается только активити. И я могу поспорить, что убивается весь процесс. И вы можете это воспроизвести кучей других способов, вроде kill через adb, лимита фоновых процессов в дев сеттингах и банальным запуском других тяжелых приложений
Вы, скорее всего, просто неправильно интерпретируете то, что видите в логах у клиентов.
Смерть процесса и потом восстановление на том же скрине — это самый обыденный сценарий, который происходит много раз на день. И это нужно поддерживать обязательно, чтобы обеспечить хороший UX. Это так же источник кучи крашей и багов, если это не тестировать.
Что вероятнее всего у вас и происходит, а не смерть отдельной Activity.
Don't keep activities уже давно бесполезна чуть менее, чем полностью, потому что эмулирует несуществующуее поведение.
Начиная с 4.0 (по-моему), Android никогда не убивает Activity по одиночку, только вместе с процессом целиком.
Последний раз обратное видел на Android 2.3.
Можете провести хоть миллион экспериментов, вы никогда не добъетесь такой ситуации даже на дохлых телефонах/эмуляторах.
Edit: в качестве теста можете сделать Activity, которая открывает такую же, и так стотыщ раз. На 2.3 старые Activity начнут умирать начиная с какого-то момента, а на 4.0+ вы просто поймаете OOM.
Но опять же, реактивное программирование здесь не при чем.
Такое поведение достигается за счет планировщика с 2+ тредами, но не за счет «реактивности». Можно сделать то же самое, используя, например, обычный ExecutorService в Java.
Поэтому «отсутствие переключения контекста» — никак не основное преимущество RP.
Как такой же фрагмент кода будет работать в реактивном стиле? Нить исполняет вычисления, посылает HTTP-запрос и вместо того чтобы заблокироваться и при получении результата синхронно обработать его, описывает код (оставляет callback) который должен быть исполнен в качестве реакции (отсюда слово реактивный) на результат. После этого нить продолжает работу, делая какие-то другие вычисления (может быть, как раз обрабатывая результаты других HTTP-запросов) без переключения контекста.
Основное преимущество здесь — отсутствие переключения контекста
Это фантастика какая-то. Какой-то поток все равно должен заблокироваться во время IO и ждать результат. Если это не тот же самый поток, произойдет точно такое же переключение контекста. Чтобы переключения не было, блокироваться и выполнять callback должен тот же поток, а в этом смысла нет в данном случае.
Просто таски в Rx* выполняются на планировщиках, но переключение контекста с ними такое же реальное, как и при любом другом подходе.
Не совсем так, кто сказал, что вьюха отдетачилась именно на моменте когда у нас запрос еще делается, она может отдетачиться когда, вызвался метод subscribe и выставилось состояние, но при этом метод navigateToMainView еще не вызвался
Нет, это невозможно.
Детач и вызов setState происходит в одном и том же треде. Последовательно. В setState вы сразу делаете переход navigateToMainView. Либо вы отдетачитесь и теряете стейт, либо вы на этот стейт переходите и потом детачитесь. Никакого рейс кондишина здесь не может быть.
Поэтому в статье и рассматривался такой сценарий, в реальности решали задачу сложнее, как видно в конце статьи.
Я имею в виду, что в сложных задачах писанины еще больше.
Вьюха может отдетачится, и метод перехода не вызовится
Если вьюха отдетачится, и переход не вызовется, то у вас и состояние это теряется.
При детаче вы отписываетесь от чейна, значит onComplete/onNext не вызовется, и соответственно этот код — тоже.
setState(new LoginCompleteState());
При этом вся прелесть в том что мы не храним флаги в презентере, а решается на уровне объектов наших состояний.
Это хорошо, но мой посыл не то, что состояния — это плохо, а то что не нужно каждое состояние делать Parcelable и извращаться с их сохранением. Особенно когда часть этих состояний и так сохранится без вашего участия.
Я бы, наверно, конкретно задолбался писать столько кода для таких простых вещей. Особенно если учесть, что этот пример с логином — один из самых тривиальных сценариев.
Во-первых, не стоит пытаться сохранить в SavedInstanceState все на свете.
В большинстве случаев, все уже сделано за вас. Стек активити и фрагментов сохраняется, состояния EditText, включая Error — тоже.
Какой смысл заморачиваться с сохранением состояния а-ля «нажал на кнопку Login»? Какова вероятность, что вас процесс резко убъется посреди реквеста? Вместо этого стоило бы лучше подумать о том, чтобы этот реквест не делался заново при перевороте экрана, например.
То же самое с состоянием LoginComplete. В какой ситуации вам нужно восстановить это состояние из бандла? Вы либо уже открыли следующий скрин, и соотвественно стэк активити восстановится после смерти процесса, либо вы отменили реквест и не перешли в это состояние вообще.
Фрагмент с кэшем для одного типа данных, еще и не типобезопасным — тоже такое себе удовольствие.
А еще обилие бесполезных пустых и Base классов не делает вашу архитектуру Clean.
Плохо практически все, начиная с View. Сырцами View, ViewGroup и ViewRootImpl можно детей пугать, об этом говорят даже ребята из гугла, которые работают над графическим фреймворком.
View знает обо всем на свете, имеет много лишнего API, которое должно быть у сабклассов, а у нее.
Были хреновые ListView, ScrollView. Решили сделать хорошо в RecyclerView, в итоге урезали некоторые фичи, нужно все так же писать тонну кода, чтобы сделать простейший список, а LayoutManager по сложности реализации может потягаться с полностью кастомной вьюхой.
Про NestedScrollView вообще молчу, в нем до сих пор столько нелепых багов, что использовать в более-менее сложном сетапе просто невозможно.
FitsSystemWindows, Window Insets, CoordinatorLayout с его Behavior, для всего приходится писать кучу костылей, чтобы оно хоть как-то вменяемо работало.
Chris Banes, главный по суппорт либе, целые гайды по костылям пишет.
Куча глобальных состояний и мемори ликов связанных с этим, начиная с абсолютно базовых вещей типа InputMethodManager.
Нет нормального API для асинхронщины. Но это по крайней мере решается библиотеками.
Bluetooth — тихий ужас.
Фрагменты — неудобное API, нет чего-то типа transaction listener, сложный lifecycle, особенно для вложенных фрагментов. А для фрагментов добавленных в XML он еще другой. Краши на коммитах после saveInstanceState, баги и лаги в анимациях перехода, рандомные краши в местах типа onCreateOptionsMenu.
Различные проблемы с клавиатурой и фокусом.
Architecture Components сейчас пытаются решить некоторые проблемы с архитектурой для отдельных скринов, сложностью жизненного цикла компонентов нетестируемым кодом.
Но все равно как-то местами криво получается. ViewModel хранится, используя retained фрагменты, LiveData имеет несколько дизайн просчетов…
Вообще многовато проблем для комментария, но статью я не сильно хочу писать, т.к. в ней нет особого смысла, просто будет нытье какое-то :)
Варианты 2 и 4 по сути одинаковые (и немного некорректые), потому что ничто в вашем примере не указывает какой должен быть фон (android:windowBackground аттрибут в теме).
Был бы windowBackground черным, отобразился бы черный цвет. Этот фон рендерится еще до любых колбеков в Activity - можно сделать sleep хоть в Application::onCreate
Нет, все корректно. Вообще неважно какой там телефон, АПИ должно работать одинаково.
Но если вы хотите сравнить с "камерофоном", то в статье как раз написано про Pixel, у которого одна из лучших камер, и АПИ там все равно сломано, при том что ребята вроде бы в одной компании работают.
Конечно же нет. Такое произойдет только если бумажка не пропускает и не отражает свет, то есть является абсолютно черным телом, чего в принципе не бывает.
Но я как бы не пытаюсь спорить кто больше жрет - проц или экран, я понятия не имею. Просто пытаюсь донести, что нельзя все сравнивать по тепловыделению. Энергия может преобразовываться в очень разные виды
Да? А как тогда переносится заряд от батареи к компонентам?
Это механическая работа.
Но речь даже не об этом. Заставить светиться экран - это тоже затраты энергии. Энергия аккумулятора переходит в кинетическую энергию фотонов, и частично в нагрев компонентов.
По какой физике вся потраченная энергия уходит в тепло? Как тогда вообще полезная работа происходит?
Я думаю человек спрашивает как может произойти вот это
Потому что никто не может заставить вас использоваться опцион, если речь не о фьючерсах.
Saved instance хранится в системном сервисе Activity Manager, который отвечает за создание и восстановление Activity.
То что вы можете воспроизвести это с флагом, не значит, что без флага в реальной ситуации убивается только активити. И я могу поспорить, что убивается весь процесс. И вы можете это воспроизвести кучей других способов, вроде kill через adb, лимита фоновых процессов в дев сеттингах и банальным запуском других тяжелых приложений
Смерть процесса и потом восстановление на том же скрине — это самый обыденный сценарий, который происходит много раз на день. И это нужно поддерживать обязательно, чтобы обеспечить хороший UX. Это так же источник кучи крашей и багов, если это не тестировать.
Что вероятнее всего у вас и происходит, а не смерть отдельной Activity.
Начиная с 4.0 (по-моему), Android никогда не убивает Activity по одиночку, только вместе с процессом целиком.
Последний раз обратное видел на Android 2.3.
Можете провести хоть миллион экспериментов, вы никогда не добъетесь такой ситуации даже на дохлых телефонах/эмуляторах.
Edit: в качестве теста можете сделать Activity, которая открывает такую же, и так стотыщ раз. На 2.3 старые Activity начнут умирать начиная с какого-то момента, а на 4.0+ вы просто поймаете OOM.
Мы обсуждаем пример из статьи, а не спорим как должно быть
Но опять же, реактивное программирование здесь не при чем.
Такое поведение достигается за счет планировщика с 2+ тредами, но не за счет «реактивности». Можно сделать то же самое, используя, например, обычный ExecutorService в Java.
Поэтому «отсутствие переключения контекста» — никак не основное преимущество RP.
Это фантастика какая-то. Какой-то поток все равно должен заблокироваться во время IO и ждать результат. Если это не тот же самый поток, произойдет точно такое же переключение контекста. Чтобы переключения не было, блокироваться и выполнять callback должен тот же поток, а в этом смысла нет в данном случае.
Просто таски в Rx* выполняются на планировщиках, но переключение контекста с ними такое же реальное, как и при любом другом подходе.
Об этом часто пишут в книгах, например Design Patterns
Нет, это невозможно.
Детач и вызов setState происходит в одном и том же треде. Последовательно. В setState вы сразу делаете переход navigateToMainView. Либо вы отдетачитесь и теряете стейт, либо вы на этот стейт переходите и потом детачитесь. Никакого рейс кондишина здесь не может быть.
Я имею в виду, что в сложных задачах писанины еще больше.
Если вьюха отдетачится, и переход не вызовется, то у вас и состояние это теряется.
При детаче вы отписываетесь от чейна, значит onComplete/onNext не вызовется, и соответственно этот код — тоже.
Это хорошо, но мой посыл не то, что состояния — это плохо, а то что не нужно каждое состояние делать Parcelable и извращаться с их сохранением. Особенно когда часть этих состояний и так сохранится без вашего участия.
Во-первых, не стоит пытаться сохранить в SavedInstanceState все на свете.
В большинстве случаев, все уже сделано за вас. Стек активити и фрагментов сохраняется, состояния EditText, включая Error — тоже.
Какой смысл заморачиваться с сохранением состояния а-ля «нажал на кнопку Login»? Какова вероятность, что вас процесс резко убъется посреди реквеста? Вместо этого стоило бы лучше подумать о том, чтобы этот реквест не делался заново при перевороте экрана, например.
То же самое с состоянием LoginComplete. В какой ситуации вам нужно восстановить это состояние из бандла? Вы либо уже открыли следующий скрин, и соотвественно стэк активити восстановится после смерти процесса, либо вы отменили реквест и не перешли в это состояние вообще.
Фрагмент с кэшем для одного типа данных, еще и не типобезопасным — тоже такое себе удовольствие.
А еще обилие бесполезных пустых и Base классов не делает вашу архитектуру Clean.
Плохо практически все, начиная с View. Сырцами View, ViewGroup и ViewRootImpl можно детей пугать, об этом говорят даже ребята из гугла, которые работают над графическим фреймворком.
View знает обо всем на свете, имеет много лишнего API, которое должно быть у сабклассов, а у нее.
Были хреновые ListView, ScrollView. Решили сделать хорошо в RecyclerView, в итоге урезали некоторые фичи, нужно все так же писать тонну кода, чтобы сделать простейший список, а LayoutManager по сложности реализации может потягаться с полностью кастомной вьюхой.
Про NestedScrollView вообще молчу, в нем до сих пор столько нелепых багов, что использовать в более-менее сложном сетапе просто невозможно.
FitsSystemWindows, Window Insets, CoordinatorLayout с его Behavior, для всего приходится писать кучу костылей, чтобы оно хоть как-то вменяемо работало.
Chris Banes, главный по суппорт либе, целые гайды по костылям пишет.
Куча глобальных состояний и мемори ликов связанных с этим, начиная с абсолютно базовых вещей типа InputMethodManager.
Нет нормального API для асинхронщины. Но это по крайней мере решается библиотеками.
Bluetooth — тихий ужас.
Фрагменты — неудобное API, нет чего-то типа transaction listener, сложный lifecycle, особенно для вложенных фрагментов. А для фрагментов добавленных в XML он еще другой. Краши на коммитах после saveInstanceState, баги и лаги в анимациях перехода, рандомные краши в местах типа onCreateOptionsMenu.
Различные проблемы с клавиатурой и фокусом.
Architecture Components сейчас пытаются решить некоторые проблемы с архитектурой для отдельных скринов, сложностью жизненного цикла компонентов нетестируемым кодом.
Но все равно как-то местами криво получается. ViewModel хранится, используя retained фрагменты, LiveData имеет несколько дизайн просчетов…
Вообще многовато проблем для комментария, но статью я не сильно хочу писать, т.к. в ней нет особого смысла, просто будет нытье какое-то :)