Saving Fragment State (Fragment)
A common problem is the incorrect behavior of the application when turning the device. The fact is that when you turn the Activity-host (Activity which is the parent for the fragment) is destroyed. At the moment this process occurs, the FragmentManager is responsible for the destruction of the child fragment. FragmentManager runs methods of a fragment fading life cycle: onPause () , onStop () and onDestroy () .
If in the controller of our child fragment, for example, there is a Media-Player object, then in the fragment method Fragment.onDestroy () an instance of our sonorous player playing Media-Player will interrupt the playback of media data. The first thing that comes to mind is to save the state of the Media-Player object by calling Fragment.onSaveInstanceState (Bundle) , which saves the data, and the new Activity loads it. However, preserving the state of the MediaPlayer object and its subsequent restoration, anyway, interrupts playback and causes sharks to hate war in the heads of users.
Fortunately, Fragment has a mechanism by which an instance of Media Player can “ survive ” a configuration change. By overriding the Fragment.onCreate (...) method and setting the fragment property.
The fragment's retainInstance property, by default , is false. This means that when the device turns around, the Fragment is not saved, but is destroyed and created in a new way along with the Activity-host. When you call setRetainInstance (true), the fragment is not destroyed along with its host and is transferred to the new Activity in an unchanged form. When saving a fragment, you can count on the fact that all its fields (including View) retain the same values. We turn to them, and they already exist and that's it. Using this approach, you can make sure that when you rotate the device, our MediaPlayer object will not interrupt its playback and the user will not freak out.
')
Now it's worth taking a closer look at how the saved fragments work. Fragment is guided by the fact that the representation of a fragment can be destroyed and re-created without the need to destroy the Fragment itself. When you change the configuration, the FragmentManager destroys and reassembles the fragment view. Similarly behaves and Activity. This is due to the considerations that new resources may be required in the new configuration. In case there are more suitable resources for the new version, the presentation is built from scratch .
FragmentManager checks the retainInstance property of each fragment. If it defaults (false), the FragmentManager deletes the fragment instance. Fragment and its representation will be recreated by a new instance of the FragmentManager belonging to the new activity.
What happens if the retainInstance value is true . The representation of the fragment is destroyed but the fragment itself remains. A new instance of the Activity will be created, and then a new FragmentManager will be created that will find the saved Fragment and recreate its View.
Our saved fragment is detached (detached) from the previous Activity and continues to live, but no longer having an Activity-host.
Accordingly, the transition to the saved state occurs when the following conditions are met:
In this case, Fragment lives quite briefly from the moment of disconnection from its first Activity to its transfer to use for an immediately created new Acticvity .
Saved fragments: is it true, is it convenient? Yes! Really comfortable. At first glance, they solve all the problems that arise with the destruction of the Activity and fragments during turns. When you change the device configuration to select the most appropriate resources, a new view is created, and at your disposal there is an easy way to save data and objects.
In this case, the question arises, why not save all fragments in a row and why fragments are not saved by default? One gets the impression that Android without enthusiasm relates to the preservation of Fragments in the UI. It is not clear to me why this is so.
It should be noted that the saved Fragment continues to exist only when the Activity is destroyed - when the configuration changes. If the Activity is destroyed due to the fact that the OS needed to free up memory, then all saved fragments will also be destroyed.
This approach is more common in dealing with the problem of data loss during turns. If your proposal easily handles this situation, then all thanks to the work behavior of onSaveInstanceState (...) by default.
The onSaveInstanceState (...) method was designed to solve save and restore the state of the user interface of the application. I think you guessed it - there is a fundamental difference between these approaches. The main difference between redefining Fragment.onSaveInstanceState (...) and saving Fragment-a is the duration of the stored data.
In the event that you want to save data for a moment while the configuration changes, saving a fragment will require significantly less work. This is especially true when saving an object developer does not need to worry about whether the object is Serializable.
But in the event that the data should exist longer, saving the fragment will not help. If the Activity is destroyed to free up memory after the user’s inaction, all saved fragments are destroyed in the same way as their not saved relatives.
So, if there is data in the Activity or in Fragment that must exist for a long time, they should be tied to the lifetime of the activity, overriding the onSaveInstanceState (Bundle) method to save the state and restore it later.
If in the controller of our child fragment, for example, there is a Media-Player object, then in the fragment method Fragment.onDestroy () an instance of our sonorous player playing Media-Player will interrupt the playback of media data. The first thing that comes to mind is to save the state of the Media-Player object by calling Fragment.onSaveInstanceState (Bundle) , which saves the data, and the new Activity loads it. However, preserving the state of the MediaPlayer object and its subsequent restoration, anyway, interrupts playback and causes sharks to hate war in the heads of users.
Saving Fragments
Fortunately, Fragment has a mechanism by which an instance of Media Player can “ survive ” a configuration change. By overriding the Fragment.onCreate (...) method and setting the fragment property.
@Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setRetainInstance(true); } The fragment's retainInstance property, by default , is false. This means that when the device turns around, the Fragment is not saved, but is destroyed and created in a new way along with the Activity-host. When you call setRetainInstance (true), the fragment is not destroyed along with its host and is transferred to the new Activity in an unchanged form. When saving a fragment, you can count on the fact that all its fields (including View) retain the same values. We turn to them, and they already exist and that's it. Using this approach, you can make sure that when you rotate the device, our MediaPlayer object will not interrupt its playback and the user will not freak out.
')
Turns and saved fragments
Now it's worth taking a closer look at how the saved fragments work. Fragment is guided by the fact that the representation of a fragment can be destroyed and re-created without the need to destroy the Fragment itself. When you change the configuration, the FragmentManager destroys and reassembles the fragment view. Similarly behaves and Activity. This is due to the considerations that new resources may be required in the new configuration. In case there are more suitable resources for the new version, the presentation is built from scratch .
FragmentManager checks the retainInstance property of each fragment. If it defaults (false), the FragmentManager deletes the fragment instance. Fragment and its representation will be recreated by a new instance of the FragmentManager belonging to the new activity.
What happens if the retainInstance value is true . The representation of the fragment is destroyed but the fragment itself remains. A new instance of the Activity will be created, and then a new FragmentManager will be created that will find the saved Fragment and recreate its View.
Our saved fragment is detached (detached) from the previous Activity and continues to live, but no longer having an Activity-host.
Accordingly, the transition to the saved state occurs when the following conditions are met:
- setRetainInstance (true) was called for the fragment
- Activity-host is destroyed to change the configuration (usually it is the turn of the device )
In this case, Fragment lives quite briefly from the moment of disconnection from its first Activity to its transfer to use for an immediately created new Acticvity .
Saving Fragments: Really So Good?
Saved fragments: is it true, is it convenient? Yes! Really comfortable. At first glance, they solve all the problems that arise with the destruction of the Activity and fragments during turns. When you change the device configuration to select the most appropriate resources, a new view is created, and at your disposal there is an easy way to save data and objects.
In this case, the question arises, why not save all fragments in a row and why fragments are not saved by default? One gets the impression that Android without enthusiasm relates to the preservation of Fragments in the UI. It is not clear to me why this is so.
It should be noted that the saved Fragment continues to exist only when the Activity is destroyed - when the configuration changes. If the Activity is destroyed due to the fact that the OS needed to free up memory, then all saved fragments will also be destroyed.
It's time to talk about onSaveInstanceState (Bundle)
This approach is more common in dealing with the problem of data loss during turns. If your proposal easily handles this situation, then all thanks to the work behavior of onSaveInstanceState (...) by default.
The onSaveInstanceState (...) method was designed to solve save and restore the state of the user interface of the application. I think you guessed it - there is a fundamental difference between these approaches. The main difference between redefining Fragment.onSaveInstanceState (...) and saving Fragment-a is the duration of the stored data.
In the event that you want to save data for a moment while the configuration changes, saving a fragment will require significantly less work. This is especially true when saving an object developer does not need to worry about whether the object is Serializable.
But in the event that the data should exist longer, saving the fragment will not help. If the Activity is destroyed to free up memory after the user’s inaction, all saved fragments are destroyed in the same way as their not saved relatives.
Finally
So, if there is data in the Activity or in Fragment that must exist for a long time, they should be tied to the lifetime of the activity, overriding the onSaveInstanceState (Bundle) method to save the state and restore it later.
Source: https://habr.com/ru/post/280586/
All Articles