Причины было две:
1. Я хотел поработать с вьюшками на уровне measure/layout. До этого я знал лишь как работать с View.onDraw().
2. RecyclerView отображает элементы последовательно друг за другом. В моем же случае между ними могут быть пробелы. Я мог бы извратиться, добавив вью типа Space между ними, или, возможно, установка marginTop для каждого элемента сделала бы дело, или же использование RecyclerView.ItemDecoration решило бы вопрос. Но в итоге я решил, что это чересчур большой костыль, с учетом того, что ещё и анимацию слияния придётся как-то добавлять в эту кашу, поэтому RecyclerView я отбросил ещё на первых этапах продумывания задачи.
Может знает кто, что должны делать полностью беспилотные автомобили в случае аварии на дороге (например, когда на дорогу упало дерево)? В ситуации с автопилотом, авто бы попросило помощи у водителя. А здесь как?
А каким образом Вы сохранили ViewModel при повороте экрана от уничтожения, используя Dagger Scope? Насколько я знаю, Scope на самом деле не добавляет никакой логики при инжекции. Оно как бы «логически» определяет, что данный Component будет жить столько же, сколько Scope.
Т.е., создав Component внутри Fragment, при повороте экрана Component также будет уничтожен и затем пересоздан. Единственный способ — хранить его отдельно, в каком-нибудь Синглтоне. Но в таком случае можно не заморачиваться и хранить в Синглтоне сразу ViewModel.
Или я чего-то о Dagger не знаю? Перечитал документацию по нему — не нашел способа сохранять Component при поворотах экрана.
Хм, а если иначе?
Что если он не Сатоши, но решил ему помочь, посчитав, что если привлечет внимание СМИ, в какой-то момент Сатоши решит «хм, надо бы ему помочь да и от себя след отвлечь» и проведет транзакцию, а Крейг вдруг скажет «вот, вчерашняя внезапная транзакция с кошелька Сатоши — моя»?
Если вы о Extra-части, то, как я уже упомянал, код был написан мною ещё в самом начале изучения Rx. Поэтому я пошел против соглашения и решил не блокировать Observable после первого же Exception, ибо в моём случае Exception не являлся чем-то плохим. Того же можно было бы достигнуть, обернув auth() в try/catch, чего я тогда не сделал и, в итоге, получил такое странное поведение.
Вы правы, я действительно поначалу не искал решения подобной задачи в гугле (о чём и упомянул в статье).
Довольно долгое время я использовал именно RelativeLayout, т.к. помимо картинки и текста были ещё какие-то элементы, которые все вместе хорошо умещались внутри самого layout'а. Я даже не задумывался, что можно сделать как-то иначе.
Однако, когда потребовалось штамповать картинку&текст в больших объемах и без соседних элементов — я по привычки начал с layout'ов, затем пожалел об этом, и только потом нашел drawableLeft у TextView.
Полагаю, со стороны это действительно незначительным пунктом для статьи.
Да это же заслуживает masterprice из всех кюветов андроида! Просто невероятно!
Пожалуй, вставлю в статью ветку с этим рассуждением в таком случае, ибо просто с наскоку сказать нечто вроде «а вы знаете, документация врёт» — не выйдет.
Хм, возможно действительно это называется не так. Я столкнулся с этим конечно же не благодаря тому, что дожидался момента нехватки памяти. Я использовал опцию Don't Keep Activities в dev-настройках. Гугл говорит, что:
Tells the system to destroy an activity as soon as it is stopped (as if Android had to reclaim memory). This is very useful for testing the onSaveInstanceState(Bundle) / onCreate(android.os.Bundle) code path, which would otherwise be difficult to force. Choosing this option will probably reveal a number of problems in your application due to not saving state. For more information about saving an activity's state, see the Activities document.
«if Android had to reclaim memory» — возможно тут я недопонял, в каких именно случаях андроид хочет выгрузить лишь Activity, а не цельный App.
Изначально я собирался описать это отдельным кюветом, но потом решил оставить только Fragment.isRemoving(), а об этом упомянуть вскользь… зря видимо :)
По поводу вашего примера. Я упомянул не кнопку back, а Up Navigation. Это иное. Оно работает по принципу Intent.FLAG_ACTIVITY_CLEAR_TOP. То есть, будет следующее:
Юзер свернул приложение и сейчас для него верно: Back Stack: Activity1 -> Activity2 -> Activity3.
Произошла нехватка памяти и Activity1, Activity2 и Activity3 получили Activity.onDestroy() с Activity.isFinishing() равное false.
В обычной ситуации юзер просто возвращается в приложение, где воссоздается Activity3, затем нажимает кнопку back, из-за которой воссоздается Activity2 и уничтожается Activity3 с Activity.isFinishing() равное true. Однако это не наш случай. Activity3 имеет возможность при помощи Up Navigation вернуться к Activity1. В итоге, когда юзер вернется в приложение и нажмет на Up Navigation, будет:
1. Воссоздано Activity3
2. Уничтожено Activity3
3. Воссоздано Activity1
4. Вычищен stack
Думаю, тут вы уже и сами догадались. Activity2 было утеряно, а последний его вызов Activity.onDestroy() был с Activity.isFinishing() равное false. Это и есть неприятная ситуация о которой я упомянул.
onPageFinished() может сработать раньше, чем контент действительно доступен. В соответствующем пункте я оставил ссылки на stackoverflow с обсуждением этого вопроса. Вот один из тамошних комментариев.
Да, вы правы. Не совсем удачно подобрал картинку. На деле бывает нужно уместить сразу 2-3 поля в одну строку (типа такого или такого). Насколько мне известно, в TableLayout этого сделать нельзя (кстати, тут же и советуют RelativeLayout и LinearLayout от которых вы отреклись. Подобные советы вижу довольно часто и сам когда начинал использовал именно LinearLayout'ы)
Кажется картинка под этой надписью без фильтрации? Ошибка или я неверно понял? Ожидал, что буква R будет без лесенки из-за поворота текстуры
От Jack'а отказались.
LayoutManagerещё не писал. Надо будет посмотреть, как оно бы через него реализовывалось.1. Я хотел поработать с вьюшками на уровне measure/layout. До этого я знал лишь как работать с
View.onDraw().2.
RecyclerViewотображает элементы последовательно друг за другом. В моем же случае между ними могут быть пробелы. Я мог бы извратиться, добавив вью типаSpaceмежду ними, или, возможно, установкаmarginTopдля каждого элемента сделала бы дело, или же использованиеRecyclerView.ItemDecorationрешило бы вопрос. Но в итоге я решил, что это чересчур большой костыль, с учетом того, что ещё и анимацию слияния придётся как-то добавлять в эту кашу, поэтомуRecyclerViewя отбросил ещё на первых этапах продумывания задачи.Может знает кто, что должны делать полностью беспилотные автомобили в случае аварии на дороге (например, когда на дорогу упало дерево)? В ситуации с автопилотом, авто бы попросило помощи у водителя. А здесь как?
Т.е., создав Component внутри Fragment, при повороте экрана Component также будет уничтожен и затем пересоздан. Единственный способ — хранить его отдельно, в каком-нибудь Синглтоне. Но в таком случае можно не заморачиваться и хранить в Синглтоне сразу ViewModel.
Или я чего-то о Dagger не знаю? Перечитал документацию по нему — не нашел способа сохранять Component при поворотах экрана.
Что если он не Сатоши, но решил ему помочь, посчитав, что если привлечет внимание СМИ, в какой-то момент Сатоши решит «хм, надо бы ему помочь да и от себя след отвлечь» и проведет транзакцию, а Крейг вдруг скажет «вот, вчерашняя внезапная транзакция с кошелька Сатоши — моя»?
Довольно долгое время я использовал именно RelativeLayout, т.к. помимо картинки и текста были ещё какие-то элементы, которые все вместе хорошо умещались внутри самого layout'а. Я даже не задумывался, что можно сделать как-то иначе.
Однако, когда потребовалось штамповать картинку&текст в больших объемах и без соседних элементов — я по привычки начал с layout'ов, затем пожалел об этом, и только потом нашел drawableLeft у TextView.
Полагаю, со стороны это действительно незначительным пунктом для статьи.
Пожалуй, вставлю в статью ветку с этим рассуждением в таком случае, ибо просто с наскоку сказать нечто вроде «а вы знаете, документация врёт» — не выйдет.
«if Android had to reclaim memory» — возможно тут я недопонял, в каких именно случаях андроид хочет выгрузить лишь Activity, а не цельный App.
По поводу вашего примера. Я упомянул не кнопку back, а Up Navigation. Это иное. Оно работает по принципу Intent.FLAG_ACTIVITY_CLEAR_TOP. То есть, будет следующее:
Юзер свернул приложение и сейчас для него верно: Back Stack: Activity1 -> Activity2 -> Activity3.
Произошла нехватка памяти и Activity1, Activity2 и Activity3 получили Activity.onDestroy() с Activity.isFinishing() равное false.
В обычной ситуации юзер просто возвращается в приложение, где воссоздается Activity3, затем нажимает кнопку back, из-за которой воссоздается Activity2 и уничтожается Activity3 с Activity.isFinishing() равное true. Однако это не наш случай.
Activity3 имеет возможность при помощи Up Navigation вернуться к Activity1. В итоге, когда юзер вернется в приложение и нажмет на Up Navigation, будет:
1. Воссоздано Activity3
2. Уничтожено Activity3
3. Воссоздано Activity1
4. Вычищен stack
Думаю, тут вы уже и сами догадались. Activity2 было утеряно, а последний его вызов Activity.onDestroy() был с Activity.isFinishing() равное false. Это и есть неприятная ситуация о которой я упомянул.