Является ли использование Fragment setRetainInstance (true) действительно хорошей практикой для обработки изменения вращения
Я имею в виду, зачем использовать Fragment # setRetainInstance (boolean)?
Причина, по которой я спрашиваю об этом, заключается в том, что Activity
обрабатывает ротацию, официальная документация по работе побуждает нас отключать Activity
и перезапускать ее во время ротации.
android: configChanges Отображает изменения конфигурации, которые будут обрабатывать сама деятельность. Когда во время выполнения происходит изменение конфигурации, активность отключается и перезапускается по умолчанию, но объявление конфигурации с этим атрибутом предотвратит перезапуск активности. Вместо этого активность остается запущенной и вызывается метод onConfigurationChanged(). Примечание. Использование этого атрибута следует избегать и использовать только в качестве последнего. Пожалуйста, прочитайте "Обработка изменений времени выполнения" для получения дополнительной информации о том, как правильно обрабатывать перезапуск из-за изменения конфигурации.
Любая попытка изменить это поведение по умолчанию по умолчанию кажется плохой практикой. Чтобы избежать активности при перезагрузке временной структуры данных во время перезапуска, мы используем onRetainNonConfigurationInstance
и getLastNonConfigurationInstance
. - Официальные изменения времени выполнения
Однако, когда приходит к обработке вращения во Фрагменте, Google дает нам разные рекомендации? Они не хотят, чтобы мы закрывали и перезапускали Фрагмент?
public Object onRetainNonConfigurationInstance()
Этот метод устарел на уровне API 13. Вместо этого используйте новый API-интерфейс фрагмента setRetainInstance (boolean); это также доступно на старых платформах через пакет совместимости с Android.
- Почему Google побуждает нас отключать и перезапускать Activity во время ротации, но поощрять нас удерживать фрагмент во время вращения?
- Если
setRetainInstance(true)
подходит для обработки вращения, почему Google не делает это как поведение по умолчанию Fragment?
Ответы
Ответ 1
-
Изменения конфигурации: когда экран становится намного шире и значительно меньше по высоте (типичный ландшафт), он способен визуально отображать свой дисплей и более разумно использовать доступный экран. Другими примерами изменения конфигурации являются пользовательский сдвиг аппаратной клавиатуры, изменение языка устройства и т.д. зачем начинать:
-
Компоненты Android поддерживают декларативный макет, вы загружаете кучу XML-макетов и работаете оттуда. Поиск каждого Просмотр и повторная компоновка/обновление в реальном времени будет бесполезным, не говоря уже о повторной проводке всех обработчиков событий и другого настраиваемого кода просмотра. Его способ проще перезагрузить еще одну группу файлов макетов.
-
Кроме того, в Android, активный вид деятельности на милость системы, так естественно, жизненный цикл активности настолько разработан (и рекомендуется), что он способен воссоздать себя по требованию, в любое время, так же, как это было до того, как оно было уничтожены. Этот шаблон учитывает все повторные запуски, из-за изменений конфигурации. Если вы делаете свои действия и фрагменты способными поддерживать вечное состояние, изменения конфигурации не будут проблемой.
-
Сохранять данные состояния (Модели), а не данные, отображающие его (UI и Views).
-
setRetainInstance (true): рекомендуется использовать только фрагменты, которые не содержат ссылок на что-либо, которые будут воссозданы при вращении. Это означает, что вы не должны использовать его на любом фрагменте, который содержит контекст, представления и т.д. Типичный визуальный фрагмент. Но это очень полезно для Фрагментов, которые содержат объекты, такие как выполнение потоков, AsyncTasks, сбор данных, загруженные активы, полученные результаты и т.д. Этот метод помогает использовать не визуальный фрагмент, как съемный держатель, для неконтекстно-зависимых объектов Activity,
Ответ 2
Потому что вы неправильно понимаете его использование. setRetainInstance(true)
должен использоваться только в фрагментах, которые похожи на сольные элементы/модули. Фрагмент, который обрабатывает сокеты и т.д., Не имеет графического интерфейса, действительно выигрывает от его сохранения. Фрагменты с графическим интерфейсом, вероятно, не должны использовать setRetainInstance(true)
. Также любые фрагменты, которые идут в backstack, не должны использовать setRetainIstance(true)
.
Вы можете обобщить его на любой фрагмент, который обрабатывает только данные/соединение и т.д., Должен использовать setRetainInstance(true)
. Но существует множество способов использования фрагментов, которые не будут использовать setRetainInstance(true)
.