Является ли использование Fragment setRetainInstance (true) действительно хорошей практикой для обработки изменения вращения

Я имею в виду, зачем использовать Fragment # setRetainInstance (boolean)?

Причина, по которой я спрашиваю об этом, заключается в том, что Activity обрабатывает ротацию, официальная документация по работе побуждает нас отключать Activity и перезапускать ее во время ротации.

android: configChanges Отображает изменения конфигурации, которые будут обрабатывать сама деятельность. Когда во время выполнения происходит изменение конфигурации, активность отключается и перезапускается по умолчанию, но объявление конфигурации с этим атрибутом предотвратит перезапуск активности. Вместо этого активность остается запущенной и вызывается метод onConfigurationChanged(). Примечание. Использование этого атрибута следует избегать и использовать только в качестве последнего. Пожалуйста, прочитайте "Обработка изменений времени выполнения" для получения дополнительной информации о том, как правильно обрабатывать перезапуск из-за изменения конфигурации.

Любая попытка изменить это поведение по умолчанию по умолчанию кажется плохой практикой. Чтобы избежать активности при перезагрузке временной структуры данных во время перезапуска, мы используем onRetainNonConfigurationInstance и getLastNonConfigurationInstance. - Официальные изменения времени выполнения

Однако, когда приходит к обработке вращения во Фрагменте, Google дает нам разные рекомендации? Они не хотят, чтобы мы закрывали и перезапускали Фрагмент?

public Object onRetainNonConfigurationInstance()

Этот метод устарел на уровне API 13. Вместо этого используйте новый API-интерфейс фрагмента setRetainInstance (boolean); это также доступно на старых платформах через пакет совместимости с Android.

  1. Почему Google побуждает нас отключать и перезапускать Activity во время ротации, но поощрять нас удерживать фрагмент во время вращения?
  2. Если 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).