Сохранение состояния fragment android

Fragment (Фрагменты). Часть пятая

Сохранение данных

Теперь рассмотрим важный вопрос, как сохранять данные при изменении конфигурации и других операциях.

Для примера возьмём старый урок по подсчёту ворон, но на этот раз будем считать котов. Вороны вечно порхают с ветки на ветку, их сложно считать. Коты — совсем другое дело, они лежат себе на одном месте и спят. Считать их одно удовольствие.

Кажется, я поторопился со своим утверждением.

Новый проект создавать не будем, а модифицируем старый. Заодно закрепим материал.

Создадим в проекте два новых фрагмента: WithButtonFragment и WithTextViewFragment. Из названий понятно, что в первом фрагменте будет кнопка, а во втором — TextView, в котором будет отражаться информация о количестве котов.

Повторяем прошлые шаги. Создаём новый класс, наследуемся от Fragment.

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

Подключаем разметки к соответствующим фрагментам в методе onCreateView().

Для второго фрагмента напишите код самостоятельно.

Подключаем фрагменты в разметке основной активности activity_main.xml:

Не копируйте код с сайта, проделывайте операции самостоятельно через редактор в режиме Design и Text, как это объяснялось в предыдущих примерах.

Подключим кнопку в первом фрагменте.

Во втором фрагменте подключим компонент TextView и добавим метод для вывода текста.

Если мы вызовем метод changeText() с каким-нибудь текстом, то текст отобразится в TextView. Наша задача — научить фрагменты обмениваться данными через активность.

Если сейчас запустить пример, то фрагменты будут работать независимо друг от друга. Счётчик будет увеличиваться, но его значения пока не попадают во второй фрагмент и мы не можем увидеть число котов.

Напоминаю, мы не связываем два фрагмента между собой напрямую. Создаём интерфейс для этих целей.

В предыдущем примере мы создавали интерфейс внутри первого фрагмента. Для разнообразия изменим подход. Создадим новый класс через New | Java Class и в диалоговом окне для поля Kind выберем Interface. Также зададим ему имя Communicator.

Интерфейс будет состоять из одного метода.

Активность должна реализовать интерфейс.

Фрагмент с кнопкой может использовать объект интерфейса для отправки данных. Инициализируем его в новом методе onActivityCreated(), который ранее не использовали. Метод сработает, когда активность будет создана и готова к работе.

При щелчках на кнопках мы вызываем метод count(), которому передаём нужную информацию.

А сам метод в активности будет выглядеть следующим образом:

Фрагмент передаёт через метод count() данные data, а активность их принимает и передаёт их в метод второго фрагмента changeText().

Подготовительные работы завершены и можно запустить пример для проверки.

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

Теперь переходим непосредственно к теме нашего урока. Повернув экран, мы обнаружим, что данные из текстового блока пропали. Наши подсчёты — коту под хвост!

Мы можем в новой ориентации начать новый подсчёт, но повернув устройство обратно в портретный режим, снова потеряем данные.

Мы знаем, что при поворотах активность создаётся заново. Поэтому все данные сбрасываются. Чтобы сохранить данные, у фрагментов есть соответствующие методы, схожие с подобными методами у активностей. Задействуем их.

Метод onSaveInstanceState() поможет нам. Добавим метод в первый фрагмент с кнопкой.

Параметр метода outState является объектом класса Bundle и позволяет хранить различные типы в формате «ключ-значение».

У фрагментов также есть метод onCreate(Bundle savedInstanceState), где используется объект этого же класса Bundle только под другим именем savedInstanceState. Несмотря на разные имена, речь идёт об одном и том же объекте. И сохраняя данные в методе onSaveInstanceState(), мы можем их получить в методе onCreate():

При повороте фрагмент сохранит значение счётчика, перезапустится и восстановит значение счётчика. Если запустить пример, то увидим следующее. Щёлкнем несколько раз по кнопке и повернём экран. Данные сбросятся и мы снова увидим пустой текст. Но стоит нам нажать на кнопку, то увидим, что отсчёт пошёл не сначала, а продолжил со своего последнего значения. Мы видим, что первый фрагмент запоминает свои данные. А второй фрагмент пока тупит. Поможем ему.

Добавим новую переменную mData, которая будет хранить текст сообщения. У метода onCreateView() также есть параметр savedInstanceState класса Bundle, позволяющий извлечь сохранённые данные.

А текст мы сохраним в методе onSaveInstanceState(). В методе changeText() добавим строку кода, чтобы текст брался из новой переменной. Теперь при первом запуске всё работает как прежде. При повороте текст из mData сохраняется в методе putString() и восстанавливается через getString().

После этих изменений программа больше не теряет своих данных и можно спокойно считать котов. Я стал смотреть на гифку и считать. Через 8 минут 16 секунд последний кот выпрыгнул в окно и в итоге получилось 154578 котов. Перепроверьте.

Источник

Сохранение состояния фрагментов (Fragment)

Распространенной проблемой является некорректное поведение приложения при повороте девайса. Дело в том что при повороте Activity-host (Activity которое является родителем для фрагмента) уничтожается. В тот момент когда этот процесс происходит FragmentManager отвечает за уничтожение дочернего фрагмента. FragmentManager запускает методы угасающего жизненного цикла фрагмента: onPause(), onStop() и onDestroy().

В случае если в контроллере нашего дочернего фрагмента, к примеру, есть объект Media-Player, то в методе фрагмента Fragment.onDestroy() экземпляр нашего звонко играющего Media-Player-а прервет воспроизведение медиа данных. Первое, что приходит в голову, сохранить состояние объекта Media-Player вызвав Fragment.onSaveInstanceState(Bundle), что сохранит данные, а новое Activity загрузит их. Однако, сохранение состояния объекта MediaPlayer и его последующее восстановление, все равно, прерывает воспроизведение и заставляет акул ненависти сновать в головах пользователей.

Сохранение Fragments

Благо, у Fragment присутствует механизм, при помощи которого экземпляр Media-Player может “пережить” изменение конфигурации. Переопределив метод Fragment.onCreate(. ) и задав свойство фрагмента.

Свойство retainInstance фрагмента, по дефолту, является false. Это означает, что при поворотах девайса Fragment не сохраняется, а уничтожается и создается по новому вместе с Activity-host. При вызове setRetainInstance(true) фрагмент не уничтожается вместе с его хостом и передается новому Activity в не измененном виде. При сохранении фрагмента можно рассчитывать на то, что все его поля (включая View) сохранят прежние значения. Мы к ним обращаемся, а они уже есть и все. Используя этот подход можно убедится в том, что при повороте девайса наш объект MediaPlayer не прервет свое воспроизведение и пользователь не будет психовать.

Повороты и сохраненные фрагменты

Теперь стоит взглянуть более подробно на то, как работают сохраненные фрагменты. Fragment руководствуется тем обстоятельством, что представление фрагмента может уничтожаться и создаваться заново без необходимости уничтожать сам Fragment. При изменении конфигурации FragmentManager уничтожает и заново собирает представление фрагментов. Аналогично ведет себя и Activity. Это происходит из соображений что в новой конфигурации могут потребоваться новые ресурсы. На случай, если для нового варианта существуют более подходящие ресурсы, представление строится «с нуля».

FragmentManager проверяет свойство retainInstance каждого фрагмента. Если оно дефолтное (false), FragmentManager уничтожает экземпляр фрагмента. Fragment и его представление будут созданы заново новым экземпляром FragmentManager принадлежащем новой активности.

Что же происходит если значение retainInstance равно true. Представление фрагмента уничтожается но сам фрагмент остается. Создастся новый экземпляр Activity, а затем и новый FragmentManager который найдет сохраненный Fragment и воссоздаст его View.

Наш сохраненный фрагмент открепляется (detached) от предыдущей Activity и продолжает жить но уже не имея Activity-host.

Соответственно, переход в сохраненное состояние происходит при выполнении следующих условий:

• для фрагмента был вызван метод setRetainInstance(true)
• Activity-host уничтожается для изменения конфигурации (обычно это поворот девайса)

В этом случае Fragment живет совсем недолго от момента отсоединения от своей первой Activity до передачи его в пользование к немедленно созданной нового Acticvity.

Сохранение фрагментов: действительно так хорошо?

Сохраненные фрагменты: ведь правда, удобно? Да! Действительно удобно. На первый взгляд они решают все проблемы, возникающие с уничтожением Activity и фрагментов при поворотах. При изменении конфигурации устройства для подбора наиболее подходящих ресурсов создается новое представление, а в вашем распоряжении имеется простой способ сохранения данных и объектов.

В таком случае возникает вопрос, почему не сохранять все фрагменты подряд и почему фрагменты не сохраняются по умолчанию? Невольно складывается впечатление, что Android без энтузиазма относится к сохранению Fragment-ов в UI. Мне не ясно, почему это так.
Стоит отметить, что сохраненный Fragment продолжает существовать только при уничтожении Activity — при изменения конфигурации. Если Activity уничтожается из-за того, что ОС потребовалось освободить память, то все сохраненные фрагменты также будут уничтожены.

Пора поговорить и об onSaveInstanceState(Bundle)

Такой подход является более распространенным в борьбе с проблемой потери данных при поворотах. Если ваше преложение с легкостью отрабатывает эту ситуацию то все благодаря работе поведения onSaveInstanceState(. ) по дефолту.

Метод onSaveInstanceState(. ) проектировался для решения сохранения и восстановления состояния пользовательского интерфейса приложения. Как я думаю, Вы догадались — есть основополагающее различие между этими подходами. Главное отличие между переопределением Fragment.onSaveInstanceState(. ) и сохранением Fragment-а — продолжительность существования сохраненных данных.

В том случае, если вы преследуете цель сохранить данные на то мгновение пока происходит изменение конфигурации, сохранение фрагмента потребует существенно меньшей работы.Это особенно справедливо при сохранении объект- разработчику не нужно беспокоиться о том, реализует ли объект Serializable.

Но в том случае, если данные должны существовать дольше, сохранение фрагмента не поможет. Если Activity уничтожается для освобождения памяти после бездействия юзера, все сохраненные фрагменты уничтожаются так же, как и их не сохраненные родственники.

Источник

Android фрагмент — Как сохранить состояния представлений во фрагменте, когда другой фрагмент помещается поверх него

В FragA андроиде фрагмент (скажем ) добавляется в backstack, а другой фрагмент (скажем FragB ) попадает на вершину. Теперь на ответный удар FragA приходит наверх и onCreateView() называется. Теперь я находился FragA в определенном состоянии, прежде чем FragB меня оттолкнули.

Мой вопрос, как я могу восстановить FragA его предыдущее состояние? Есть ли способ сохранить состояние (например, в Bundle) и если да, то какой метод мне следует переопределить?

В примере фрагмента руководства FragmentList вы можете найти:

Который вы можете использовать позже, как это:

Я новичок во Фрагментах, но это похоже на решение вашей проблемы;) OnActivityCreated вызывается после возврата фрагмента из стека назад.

Фрагменты onSaveInstanceState(Bundle outState) никогда не будут вызваны, пока активность фрагмента не вызовет его на себе и на прикрепленных фрагментах. Таким образом, этот метод не будет вызываться до тех пор, пока что-то (обычно вращение) не заставит активность SaveInstanceState и не восстановит ее позже. Но если у вас есть только одно действие и большой набор фрагментов внутри него (с интенсивным использованием replace ) и приложение запускается только в одном ориентированном действии, то оно onSaveInstanceState(Bundle outState) может не вызываться в течение длительного времени.

Я знаю три возможных обходных пути.

используйте аргументы фрагмента для хранения важных данных:

Второй, но менее педантичный способ — держать переменные в синглетонах

Третий — не replace() фрагменты, а add() / show() / hide() их вместо.

Просто обратите внимание, что если вы работаете с фрагментами с помощью ViewPager, это довольно просто. Вам нужно только вызвать этот метод: setOffscreenPageLimit() .

Согласовать с документами:

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

Просто раздуйте свой взгляд на этот раз.

Я работал с проблемой, очень похожей на эту. Так как я знал, что часто буду возвращаться к предыдущему фрагменту, я проверил, был ли фрагмент .isAdded() истинным, и если да, то вместо того, чтобы делать a, transaction.replace() я просто делаю a transaction.show() . Это удерживает фрагмент от воссоздания, если он уже находится в стеке — сохранение состояния не требуется.

Следует также помнить, что, хотя это сохраняет естественный порядок для самих фрагментов, вам все равно может потребоваться обработка самого действия, которое уничтожается и воссоздается при изменении ориентации (конфигурации). Чтобы обойти это в AndroidManifest.xml для вашего узла:

В Android 3.0 и выше, по- screenSize видимому, требуется.

Лучшее решение, которое я нашел ниже:

onSavedInstanceState (): всегда вызывается внутри фрагмента, когда действие прекращается (перемещение действия от одного к другому или изменение конфигурации). Таким образом, если мы вызываем несколько фрагментов для одной и той же деятельности, тогда мы должны использовать следующий подход:

Используйте OnDestroyView () фрагмента и сохраните весь объект внутри этого метода. Тогда OnActivityCreated (): проверьте, является ли объект нулевым или нет (поскольку этот метод вызывается каждый раз). Теперь восстановите состояние объекта здесь.

Его работает всегда!

если вы обрабатываете изменения конфигурации в вашей активности фрагмента, указанной в манифесте Android, как это

тогда onSaveInstanceState фрагмент не будет вызван, и savedInstanceState объект всегда будет нулевым.

я не думаю, что onSaveInstanceState это хорошее решение. это просто использовать для деятельности, которая была уничтожена.

Начиная с Android 3.0 Fragmen был менеджером FragmentManager, условие: одно действие отображает фрагменты Мэнни, когда фрагмент добавляется (не заменяет: он будет воссоздан) в backStack, представление будет удалено. если вернуться к последнему, он будет отображаться как прежде.

Так что я думаю, что fragmentanger и транзакция достаточно хороши, чтобы справиться с этим.

Я использовал гибридный подход для фрагментов, содержащих представление списка. Это кажется производительным, так как я не заменяю текущий фрагмент, а добавляю новый фрагмент и скрываю текущий. У меня есть следующий метод в упражнении, в котором хранятся мои фрагменты:

Я использую этот метод в своем фрагменте (содержащем представление списка) всякий раз, когда на элемент списка нажимают / касаются (и поэтому мне нужно запустить / отобразить фрагмент сведений):

getFragmentTags() возвращает массив строк, которые я использую в качестве тегов для разных фрагментов, когда добавляю новый фрагмент (см. transaction.add метод в addFragment методе выше).

Во фрагменте, содержащем представление списка, я делаю это с помощью метода onPause ():

Затем в onCreateView фрагмента (фактически в методе, который вызывается в onCreateView), я восстанавливаю состояние:

В конце концов, после того, как я попробовал многие из этих сложных решений, мне нужно было только сохранить / восстановить одно значение в моем фрагменте (содержимое EditText), и хотя это может быть не самым элегантным решением, создание SharedPreference и сохранение моего состояния там работали на меня

Простой способ сохранить значения полей в разных фрагментах в деятельности

Создайте экземпляры фрагментов и добавьте вместо замены и удаления

Затем просто покажите и скройте фрагменты вместо того, чтобы снова добавлять и удалять их

Источник