Is using Fragment's setRetainInstance(true) really a good practice to handle rotation change

Question

I'm referring to Why use Fragment#setRetainInstance(boolean)?

The reason I ask so is for Activity to handle rotation, Official Activity Documentation encourages us to let Activity shut-down and restart during rotation.

android:configChanges Lists configuration changes that the activity will handle itself. When a configuration change occurs at runtime, the activity is shut down and restarted by default, but declaring a configuration with this attribute will prevent the activity from being restarted. Instead, the activity remains running and its onConfigurationChanged() method is called. Note: Using this attribute should be avoided and used only as a last-resort. Please read Handling Runtime Changes for more information about how to properly handle a restart due to a configuration change.

Any attempt to change this Activity default behavior seems to be bad practice. To avoid Activity from reloading time consuming data structure during restarting, we make make use of onRetainNonConfigurationInstance and getLastNonConfigurationInstance. - Official Handling Runtime Changes

However, when comes to handling rotation in Fragment, does Google give us different recommendation? They do not want us to shut down and restart Fragment?

public Object onRetainNonConfigurationInstance ()

This method was deprecated in API level 13. Use the new Fragment API setRetainInstance(boolean) instead; this is also available on older platforms through the Android compatibility package.

1. Why does Google encourage us to shut down and restart Activity during rotation, but encourage us to retain Fragment during rotation?
2. If setRetainInstance(true) is good in handling rotation, why don't Google make it as Fragment's default behavior?

Answer 1

• Configuration changes: when suddenly screen becomes much wider and much less in height (typical landscape), it is apt for a visual component to update its display and more intelligently use the screen available. Another examples of config change are user sliding the hardware keyboard, device language changing, and so on. why re-start :

  • Android components favor declarative layout, you load a bunch of XML layouts, and work from there. Finding every View and re-arranging/updating it in real time will be a mess, not to mention the re-wiring of all the event handlers and other custom View code. Its way easier to reload another bunch of layout files.

  • Also, In Android, Activities kind of live at the mercy of system, so naturally, Activity life cycle is so designed (and recommended) that it is capable of re-creating itself on demand , any time, just as it was before it was destroyed. This pattern accommodates all re-starts, those due to configuration changes as well. If you make your Activities and Fragments capable of maintaining an eternal state, configuration changes won't be that much of a problem.

  • Retain state data (Models), not the stuff displaying it (UI and Views).

• setRetainInstance(true): It is recommended only to be used with fragments that do not hold any reference to anything, that will be recreated on rotation. This means you should not use it on any Fragment that holds Context, Views, etc. A typical Visual fragment does. But it is very useful with Fragments that hold objects like running Threads, AsyncTasks, Data Collections, loaded assets, fetched results etc. This method helps in using a non visual Fragment, as a detachable holder, for non Context-dependent objects of an Activity.