Н
Arsen CeH9
ресайклер не должен сбиваться при пересоздании вью, ты где-то криво инициализируешь его
*NestedScrollView
Size: a a a
2020 September 03
AC
если в онкриейтВью засетить ему данные, адаптер и лейаутменеджер, то он восстановится сам ну нужную позицию
AC
на счет скролвью не уверен, сейвит ли он свой стейт
Н
Recycler действительно сохрняет стейт. ошибся.
Но вот с остальным...
Но вот с остальным...
KT
Мне кажется, это уже вопрос про андроид. Тут не важно, чем вы переключаете экраны, Чичероне или чем-то другим
Н
Таки да. Проблема андроида с ЖЦ фрагментов и LifecycleObserver'a.
Просто подумал что именно тут сталкивался кто-то как это сделать по красивее)
Всем спасибо)
Просто подумал что именно тут сталкивался кто-то как это сделать по красивее)
Всем спасибо)
2020 September 11
ЭМ
Добрый день! Подскажите, пожалуйста, не совсем понял один момент с fragment factory. Если мы используем fragment factory, то мы должны отказаться от arguments и использовать только конструктор?
AD
Эдуард Марселевич
Добрый день! Подскажите, пожалуйста, не совсем понял один момент с fragment factory. Если мы используем fragment factory, то мы должны отказаться от arguments и использовать только конструктор?
нет, аргументы в любом случае нужны для передачи всяких идентификаторов, чтобы при пересозданиях фрагмента их сохранять
AD
Эдуард Марселевич
Добрый день! Подскажите, пожалуйста, не совсем понял один момент с fragment factory. Если мы используем fragment factory, то мы должны отказаться от arguments и использовать только конструктор?
ЭМ
Спасибо!
KT
впечатление такое, что гугл все только усложняет и портит, добавляя fragment factory, navigation, hilt и прочие библиотеки, вместо упрощения и добавления фич
AD
впечатление такое, что гугл все только усложняет и портит, добавляя fragment factory, navigation, hilt и прочие библиотеки, вместо упрощения и добавления фич
но ведь FragmentFactory в целом полезная штука
разве что она решает только часть проблем + добавляет немного новых
разве что она решает только часть проблем + добавляет немного новых
A
Привет, на что можно заменить последовательный вызов appRouter.exit() если нужно вернуться на три экрана назад? appRouter.backTo(targetScreen) не срабатывает
KT
должно срабатывать. проверьте ключ экрана
AD
а какие сценарии у таких переходов могут быть?
это выглядит как растаскивание знаний о соседних экранах 🙁
не то, чтобы это было смертельным, но на больших проектах может мешать
это выглядит как растаскивание знаний о соседних экранах 🙁
не то, чтобы это было смертельным, но на больших проектах может мешать
A
а какие сценарии у таких переходов могут быть?
это выглядит как растаскивание знаний о соседних экранах 🙁
не то, чтобы это было смертельным, но на больших проектах может мешать
это выглядит как растаскивание знаний о соседних экранах 🙁
не то, чтобы это было смертельным, но на больших проектах может мешать
Это по моему вопросу?
AD
Это по моему вопросу?
да, сорян, в воздух забросил сообщение
A
а какие сценарии у таких переходов могут быть?
это выглядит как растаскивание знаний о соседних экранах 🙁
не то, чтобы это было смертельным, но на больших проектах может мешать
это выглядит как растаскивание знаний о соседних экранах 🙁
не то, чтобы это было смертельным, но на больших проектах может мешать
Поэтому и не хочу несколько раз вызывать exit, а сразу указать куда нужно уйти.
AD
Поэтому и не хочу несколько раз вызывать exit, а сразу указать куда нужно уйти.
я и говорю, что это странно - почему N-ный экран знает, что где-то сзади есть ЭкранA? А вдруг там завтра будет ЭкранБ или в зависимости от условия - то ЭкранА, то ЭкранБ?
A
я и говорю, что это странно - почему N-ный экран знает, что где-то сзади есть ЭкранA? А вдруг там завтра будет ЭкранБ или в зависимости от условия - то ЭкранА, то ЭкранБ?
Не должен, нужно разобраться почему не рабоатет backTo