гарантий любых сохранения поведения в будущем) и хреново документированное
Аргументы - для передачи новых данных во фрагмент. при вызове. Но у нас же слои и прочее? Тогда в репозитории доступны данные о состоянии в нужныв момент туда сохраненные нами же
у меня стойкое ощущение, что вы отвечаете мне, но при этом я каждый раз замечаю ваши ответы случайно, т.к. вы не отвечаете на мои сообщения всё ещё не понимаю, каким боком здесь репозиторий
и SavedInstanceState и Arguments являются bundle
можно руками сохранить state в arguments, но потом его руками и нужно вынимать (зачем?)
а то из savedInstanceState ногами достают
не подумал :D
Так, завязывай
это мы так любезничаем :)
Он просто уже довольно долго тут тянет этот малоосмысленный разговор
разница в том, что в restoreState нужно еще доставить arguments
прочел. Вполне осмысленный. Вопрос в том, почему один и тот же механизм применяется 2 раза в классе. Можно ли использовать 1?
так мне люди отвечают, а дальше диалог завязывается
из удобства - доступ к сохраненным состояниям вне методов
а в restoreInstanceState сразу передается savedInstanceState
доступ вне фрагмента к его внутреннему состоянию?
вне метода, который получает в кач-ве параметра состояние, а не фрагмента но так-то да, потенциальная проблема - внутреннее состояние торчит наружу через getArguments()
не понял вне какого метода. getArguments() можно получить по всему фрагменту в любом месте
Обсуждают сегодня