Home Development for Android Saving the state of a fragment

Saving the state of a fragment

by admin

A common problem is that the application does not behave correctly when you rotate the device.The point is that when you rotate Activity-host (which is the parent for the fragment)is destroyed.At the moment when this process happens FragmentManageris responsible for destroying child fragment. The FragmentManagerruns the methods of the fading life cycle of the fragment : onPause() , onStop() and onDestroy()
If the controller of our child fragment, for example, has the Media-Player then in the fragment method Fragment.onDestroy() instance of our ringing Media-Playerwill interrupt media data playback. The first thing that comes to mind is to save the state of the Media-Player object by calling Fragment.onSaveInstanceState(Bundle) which will save the data and a new Activitywill load it. However, saving the state of the object MediaPlayer and restoring it afterwards still interrupts playback and makes hate sharks go berserk in users’ heads.

Saving Fragments

Fortunately, Fragmenthas a mechanism whereby an instance of Media-Player can " survive " configuration change. By overriding the method Fragment.onCreate(…) and specifying the fragment property.

@Overridepublic void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setRetainInstance(true);}

Property retainInstance fragment, by default , is false. This means that when you rotate the device, the Fragment is not saved, but is destroyed and created anew along with the Activity-host. When calling setRetainInstance(true) the fragment is not destroyed along with its host and is passed to the new Activity unchanged. When you save the snippet, you can expect all of its fields (including View) to retain their previous values. We refer to them and they are already there and that’s it. Using this approach, we can make sure that when you rotate the device, our object MediaPlayer will not interrupt its playback and the user will not freak out.

Rotations and saved fragments

It is now worth taking a closer look at how saved fragments work. Fragment is guided by the fact that a fragment representation can be destroyed and re-created without having to destroy the Fragment itself. When you change the configuration FragmentManager destroys and reassembles the fragment representation. Activity behaves the same way. This is due to the consideration that the new configuration may require new resources. Just in case more suitable resources exist for the new variant, the view is built " from scratch ".
FragmentManager checks the retainInstanceproperty of each fragment. If it default (false), the FragmentManager destroys the fragment instance. The fragment and its representation will be re-created with a new instance of FragmentManager belonging to the new activity.
Saving the state of a fragment
What happens if the value retainInstance is equal to true The fragment representation is destroyed, but the fragment itself remains. A new Activity instance will be created, and then a new FragmentManager will find the saved Fragment and recreate its View.
Saving the state of a fragment
Our saved fragment is detached from the previous Activity and continues to live but without an Activity-host.
Saving the state of a fragment
Accordingly, the transition to the stored state occurs when the following conditions are met :

  • method was called for the fragment setRetainInstance(true)
  • Activity-host is destroyed for configuration changes (usually a rotation of device )

In this case Fragment lives only a short time from the moment of disconnection from its first Activity before it is transferred for use to the immediately created new Acticvity

Saving fragments : really that good?

Saved snippets : really handy, isn’t it? Yes! Really handy. At first glance, they solve all the problems that arise with destroying Activity and fragments when you rotate. When you change the device configuration, a new view is created to select the most appropriate resources, and you have an easy way to save your data and objects at your disposal.
In that case, the question arises, why not save all fragments in a row and why aren’t fragments saved by default? Unwittingly, one gets the impression that Android is unenthusiastic about saving Fragments in the UI. It’s not clear to me why this is the case.
It’s worth noting that a saved Fragment only continues to exist when an Activity is destroyed – when the configuration is changed. If an Activity is destroyed because the OS needed to free up memory, then all saved Fragments will also be destroyed.

Time to talk about onSaveInstanceState(Bundle)

This approach is more common in combating the problem of data loss during rotations. If your application handles this situation with ease, it is due to the behavior of onSaveInstanceState(…) by default.
Method onSaveInstanceState(…) was designed to solve saving and restoring the state of the application’s user interface. As I think you have guessed – there is a fundamental difference between these approaches. The main difference between overriding Fragment.onSaveInstanceState(…) and saving a Fragment – the duration of the existence of the saved data.
In case you are aiming to save data for the moment while the configuration change takes place, saving a fragment will require significantly less work.This is especially true when saving an object-the developer doesn’t have to worry about whether the object is Serializable or not.
But in case the data should exist longer, saving the fragment won’t help. If Activity is destroyed to free up memory after inactivity user , all saved fragments are destroyed in the same way as their unsaved relatives.

In conclusion

So, if there is data in an Activity or in a Fragment that needs to exist for a long time, it is worth tying it to the lifetime of the activity by overriding the onSaveInstanceState(Bundle) to save the state and then restore it.

You may also like