Pull to refresh

Comments 5

Зачем хранить сами фрагменты в адаптере? Они ведь и так хранятся в FragmentManager.
К тому же есть вероятность сломать логику работы FragmentStateAdapter, ведь именно он отвечает за процесс создания и переиспользования фрагментов во ViewPager.
А что будет при смене конфигурации? Адаптер будет пересоздан с пустым mapOfFragment?
Бэкстэка на каждой странице не будет, т.е. возврат с "описания тарелки" в "список тарелок" только вручную?

1. Действительно, возможно стоит хранить фрагменты в FragmentManager, а в mapOfFragments хранить ключи (Fragment.tag например). Нужно подумать над этой реализацией

2. При смене конфигурации все хорошо, если сохранить mapOfFragments или сам адаптер. Согласен, стоило обратить на это внимание

3. На каком-то этапе столкнулся с проблемой — действительно понадобился бэкстек. Решение — передавать фрагменту, который открываешь, информацию о том, к какому фрагменту нужно вернуться (ключ или ссылка). А дальше использовать уже существующую функцию replace(position, newFragment)

Да, это не лучшая логика для использования фрагментов, так делать нельзя в обычной жизни, но при совмещении ViewPager и фрагментов ситуация меняется, приходится прибегать к не самым приятным вещам.

Спасибо за хорошие вопросы)
Починил все ссылки. Так и не понял правда, почему хабр без префикса http/https не открывает, но при этом и не сообщает об неправильно введенной.

Если кто-то понимает, как нормально вставить видео с ютуба в новом редакторе, буду признателен
abstract class BaseFragment(private val layoutId: Int): Fragment()

Решение проблемы не вызывает доверия, после того как автор статьи делает у фрагментов конструктор с параметрами без использования фабрики фрагментов и хранит в адаптере «сильные» ссылки на фрагменты.
конечно, это супер грубое нарушение и за такое надо бить по рукам. по-этому есть раздел «дисклеймер», в котором отметил, что код нарочно упрощен, и все не касающееся именно поставленной задачи отброшено
Sign up to leave a comment.

Articles