Pull to refresh
17
0
Дмитрий @Dimezis

Senior Android Software Engineer

Send message

Варианты 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.
:)
Мы обсуждаем пример из статьи, а не спорим как должно быть
Чтобы на одном из них был блокирующий IO, а на другом гонялись в это время любые другие таски
Ок, понятно что имелось в виду, согласен.

Но опять же, реактивное программирование здесь не при чем.
Такое поведение достигается за счет планировщика с 2+ тредами, но не за счет «реактивности». Можно сделать то же самое, используя, например, обычный ExecutorService в Java.

Поэтому «отсутствие переключения контекста» — никак не основное преимущество RP.
Да, но это никаким образом не относится к реактивному программированию и тому, что написал автор. Nio можно с любым подходом использовать
Как такой же фрагмент кода будет работать в реактивном стиле? Нить исполняет вычисления, посылает HTTP-запрос и вместо того чтобы заблокироваться и при получении результата синхронно обработать его, описывает код (оставляет callback) который должен быть исполнен в качестве реакции (отсюда слово реактивный) на результат. После этого нить продолжает работу, делая какие-то другие вычисления (может быть, как раз обрабатывая результаты других HTTP-запросов) без переключения контекста.

Основное преимущество здесь — отсутствие переключения контекста

Это фантастика какая-то. Какой-то поток все равно должен заблокироваться во время IO и ждать результат. Если это не тот же самый поток, произойдет точно такое же переключение контекста. Чтобы переключения не было, блокироваться и выполнять callback должен тот же поток, а в этом смысла нет в данном случае.

Просто таски в Rx* выполняются на планировщиках, но переключение контекста с ними такое же реальное, как и при любом другом подходе.
Потому что как правило, это более гибко и лучше масштабируется.
Об этом часто пишут в книгах, например Design Patterns
Не совсем так, кто сказал, что вьюха отдетачилась именно на моменте когда у нас запрос еще делается, она может отдетачиться когда, вызвался метод subscribe и выставилось состояние, но при этом метод navigateToMainView еще не вызвался

Нет, это невозможно.
Детач и вызов setState происходит в одном и том же треде. Последовательно. В setState вы сразу делаете переход navigateToMainView. Либо вы отдетачитесь и теряете стейт, либо вы на этот стейт переходите и потом детачитесь. Никакого рейс кондишина здесь не может быть.
Поэтому в статье и рассматривался такой сценарий, в реальности решали задачу сложнее, как видно в конце статьи.

Я имею в виду, что в сложных задачах писанины еще больше.

Вьюха может отдетачится, и метод перехода не вызовится

Если вьюха отдетачится, и переход не вызовется, то у вас и состояние это теряется.
При детаче вы отписываетесь от чейна, значит onComplete/onNext не вызовется, и соответственно этот код — тоже.
setState(new LoginCompleteState());


При этом вся прелесть в том что мы не храним флаги в презентере, а решается на уровне объектов наших состояний.

Это хорошо, но мой посыл не то, что состояния — это плохо, а то что не нужно каждое состояние делать Parcelable и извращаться с их сохранением. Особенно когда часть этих состояний и так сохранится без вашего участия.
Я бы, наверно, конкретно задолбался писать столько кода для таких простых вещей. Особенно если учесть, что этот пример с логином — один из самых тривиальных сценариев.

Во-первых, не стоит пытаться сохранить в SavedInstanceState все на свете.
В большинстве случаев, все уже сделано за вас. Стек активити и фрагментов сохраняется, состояния EditText, включая Error — тоже.

Какой смысл заморачиваться с сохранением состояния а-ля «нажал на кнопку Login»? Какова вероятность, что вас процесс резко убъется посреди реквеста? Вместо этого стоило бы лучше подумать о том, чтобы этот реквест не делался заново при перевороте экрана, например.

То же самое с состоянием LoginComplete. В какой ситуации вам нужно восстановить это состояние из бандла? Вы либо уже открыли следующий скрин, и соотвественно стэк активити восстановится после смерти процесса, либо вы отменили реквест и не перешли в это состояние вообще.

Фрагмент с кэшем для одного типа данных, еще и не типобезопасным — тоже такое себе удовольствие.

А еще обилие бесполезных пустых и Base классов не делает вашу архитектуру Clean.
В двух словах — вряд ли, это все-таки SDK.

Плохо практически все, начиная с 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 имеет несколько дизайн просчетов…

Вообще многовато проблем для комментария, но статью я не сильно хочу писать, т.к. в ней нет особого смысла, просто будет нытье какое-то :)

Information

Rating
Does not participate
Location
Kraków, Malopolskie, Польша
Date of birth
Registered
Activity