Why use Fragment#setRetainInstance(boolean)?

Question

I find Fragment#setRetainInstance(true) confusing. Here is the Javadoc, extracted from the Android Developer API:

public void setRetainInstance (boolean retain)

Control whether a fragment instance is retained across Activity re-creation (such as from a configuration change). This can only be used with fragments not in the back stack. If set, the fragment lifecycle will be slightly different when an activity is recreated:

• onDestroy() will not be called (but onDetach() still will be, because the fragment is being detached from its current activity).
• onCreate(Bundle) will not be called since the fragment is not being re-created.
• onAttach(Activity) and onActivityCreated(Bundle) will still be called.

Question: How do you as a developer use this, and why does it make things easier?

Unfold

similar question with good info: Understanding Fragment's setRetainInstance(boolean) – Analiese

onDestroy() will be called if the device is low on memory – Blomquist

Answer 1

How do you as a developer use this

Call setRetainInstance(true). I typically do that in onCreateView() or onActivityCreated(), where I use it.

and why does it make things easier?

It tends to be simpler than onRetainNonConfigurationInstance() for handling the retention of data across configuration changes (e.g., rotating the device from portrait to landscape). Non-retained fragments are destroyed and recreated on the configuration change; retained fragments are not. Hence, any data held by those retained fragments is available to the post-configuration-change activity.

Scrawly

@Scrawly - If you create a new fragment in an Activity and that Activity is recreated, how do avoid creating a new fragment again? – Tague

@Neil: See if the fragment exists (e.g., findFragmentById()). Don't recreate it if it exists. – Scrawly

@Scrawly If the fragment is a bit heavy with views and memory usage, what do you think a good developer should do? – Salangi

@androiddeveloper: Views aren't an issue, so long as the fragment is not directly holding onto them, as they are always discarded and recreated. I'm not quite certain how a fragment itself would be "heavy" in terms of "memory usage" -- do you have an example? – Scrawly

@Scrawly If the fragment holds its views so that it won't have to re-create them (in the onCreate() method), it might take some memory. However, I think it's ok to use softReference/weakReference for this task instead, right? – Salangi

@androiddeveloper: "If the fragment holds its views so that it won't have to re-create them (in the onCreate() method), it might take some memory" -- you are welcome to attempt to re-parent the widgets into the new activity, but I have had zero luck with that. AFAIK, you need to recreate the widgets in onCreateView(). "However, I think it's ok to use softReference/weakReference for this task instead, right?" -- what task? – Scrawly

@Scrawly It is possible. You check the parent of the view that was stored before (check for null of course) and if there is a parent, you remove the fragment from its parent. Of course, it might not work well on some cases so you always have to put the fragments in a single layout and never put other views in the layout. About the "task" I meant the fact of avoiding re-creation of views without any problems. – Salangi

@Scrawly Is it possible to make a call setRetainInstance(true) in onCreate()? – Crary

@e.shishkin: It should be. I rarely implement onCreate() in a fragment, so I have not tried it. – Scrawly

@Crary You can call it anytime you want. Technically you don't even need to call it in the lifecycle methods (although this is generally not something you would ever want/need to do). – Kuo

will this apply to a ListFragment if a user needs to dive into a hierarchy, then "getRetainInstance()" if the user hits the back button? Or is the general practice to use "addToBackStack" to recreate a past ListFragment if it's a two pane app? – Lutanist

@whyoz: Sorry, but I have no idea what you are talking about. – Scrawly

ListFragment 1 (click listView row, commit transaction) >>> ListFragment 2 >>> (click) BACK BUTTON >>> retrieve/restore ListFragment 1 without reloading data – Lutanist

@Scrawly will it helpful in re-opening app from recent apps list and retain the state of fragment? – Cyclopean

@Raghavendra: Only if the process was still around. – Scrawly

@Scrawly thanks for your reply. Can you give me solution for my problem. I have a Fragment which contains a listview when I hit home button and suppose if GC is initiated I lost my data which is listview when I try to open the app again its crashing. can you help me in this – Cyclopean

Answer 2

It's very helpful in keeping long running resources open such as sockets. Have a UI-less fragment that holds references to bluetooth sockets and you won't have to worry about reconnecting them when the user flips the phone.

It's also handy in keeping references to resources that take a long time to load like bitmaps or server data. Load it once, keep it in a retained fragment, and when the activity is reloaded it's still there and you don't have to rebuild it.

Excrete

Nice. But what if we need to refresh them? – Nonplus

Am I wrong in thinking that this is what a Singleton of some sort would normally do? – Bladdernose

@Bladdernose yes. A Singleton is another way of doing it. Singletons are considered "anti-patterns" and some people are hesitant to use them. Fragments also have the advantage of being tied to the lifecycle of the activity so you get lifecycle events. You can destroy the resource if the user leaves the app for example (which can also be done with Singleton but takes more code). – Excrete

Answer 3

Added this answer very late, but I thought it would make things clearer. Say after me. When setRetainInstance is:

FALSE

• Fragment gets re-created on config change. NEW INSTANCE is created.
• ALL lifecycle methods are called on config change, including onCreate() and onDestroy().

TRUE

• Fragment does not get re-created on config change. SAME INSTANCE is used.
• All lifecycle methods are called on config change, APART FROM onCreate() and onDestroy().
• Retaining an instance will not work when added to the backstack.

Don't forget that the above applies to DialogFragments as well as Fragments.

Querulous

can you add reference to Retaining an instance will not work when added to the backstack. ? – Anticyclone

@Anticyclone here: developer.android.com/reference/android/app/… – Salangi

How can I restore the fragment's state in case it was added to the back-stack ? the savedInstanceState is null, and I can't use setRetainInstance ... – Salangi

Answer 4

The setRetainInstance(boolean) method is deprecated, use ViewModels instead.

The setRetainInstance(boolean) method on Fragments has been deprecated as of Version 1.3.0 of fragment API.

With the introduction of ViewModels, developers have a specific API for retaining state that can be associated with Activities, Fragments, and Navigation graphs. This allows developers to use a normal, not retained Fragment and keep the specific state they want retained separate.

This ensures that developers have a much more understandable lifecycle for those Fragments (one that matches all of the rest of their Fragments) while maintaining the useful properties of a single creation and single destruction (in this case, the constructor of the ViewModel and the onCleared() callback from the ViewModel).

Anonymous