Why use newInstance for DialogFragment instead of the constructor?

Question

Looking at the documentation of DialogFragment, one sees the static newInstance method to initialize a new alert dialog fragment. My question is, why not use a constructor to do so, like this:

public MyAlertDialogFragment(int title) {
    Bundle args = new Bundle();
    args.putInt("title", title);
    setArguments(args);
}

Isn't this exactly the same or does it differ somehow? What's the best approach and why?

GaRRaPeTa · Answer 1 · 2015-09-09T16:59:59.763

If you create a DialogFragment that receives objects through the constructor, you will have problems when android recreates your fragment. This is what will happen:

your code creates the dialog calling the constructor you have created and passing some arguments as dependencies.
your dialog runs, and uses the dependencies that you passed though the constructor
the user closes the app
time passes, and android kills the fragment to free memory
the user opens the app again
android will recreate your dialog, this time using the default constructor. No arguments will be passed!
Your dialog will be in a undesired state. It may try to use instance variables that you expected to pass through the constructor, but as they are not there you'll get a null pointer exception.

To avoid this, you need not to rely on the constructor to establish the dependencies, but in in Bundles (arguments and saved instances). That may force you to implement Parcelable in some classes, which sucks.

EDIT: you can reproduce Android killing the app (step 4) by enabling the "don't maintain Activities" in the Development settings. That's the way to easily test it.

score 20 · Answer 2 · answered Dec 23 '12 at 14:46

20

Android relies on Fragments having a public, zero-argument constructor so that it can recreate it at various times (e.g. configuration changes, restoring the app state after being previously killed by Android, etc.).

If you do not have such a constructor (e.g. the one in the question), you will see this error when it tries to instantiate one:

Fragment$InstantiationException: Unable to instantiate fragment 
make sure class name exists, is public, and has an empty constructor that is public

Arguments given to it by Fragment.setArguments(Bundle) will be saved for you and given to any new instances that are (re)created. Using a static method to create the Fragment simply provides an easy way to setup the required arguments whilst maintaining a zero-argument constructor.

answered Dec 23 '12 at 14:46

antonyt

21,863
9
71
70

2

What if I add 2 constructors? Both public, one with zero arguments and the one with the arguments I want... Wouldn't that work too? – rfgamaral Dec 23 '12 at 15:03
5

Yes, I guess that would work too, you can use the multi-arg constructor when constructing it yourself, and then Android will use the zero-arg one when it is recreating it. Arguments will be saved properly if you used setArguments(..) in the multi-arg constructor. You really just have to keep clear in your mind what happens when the fragment is recreated - the static factory method style makes it more distinct for me, but that might be because I (and many others) am used doing it that way. Following the standard conventions will make your code easier to understand by others. – antonyt Dec 23 '12 at 15:12

score 11 · Accepted Answer · answered Dec 23 '12 at 14:45

11

If you overload the constructor with MyAlertDialogFragment(int title), the Android system may still call the default MyAlertDialogFragment() constructor if the Fragment needs to be recreated and the parameter is then not passed.

answered Dec 23 '12 at 14:45

Gunnar Karlsson

28,350
10
68
71

1

I'm confused and not sure how exactly this answers my question... Care to clarify? – rfgamaral Dec 23 '12 at 15:05
3

You asked: "My question is, why not use a constructor to do so, like this: public MyAlertDialogFragment(int title)". My answer says that if you use this constructor it may not get called if the Fragment is re-created by the Android system, and the argument you wanted passed is not passed. So don't use this approach. – Gunnar Karlsson Dec 23 '12 at 15:11
3

This answer doesn't make sense. It's perfectly valid to have a constructor for this; you just have to provide another constructor with no arguments as well. – Glenn Maynard Apr 20 '13 at 22:19
2

I assume that would cause problems for you if you rotate your device. Instead of calling your constructor it'll just call the default constructor. So, anything you intend to be setup through your overloaded constructor won't be executed. – sshaw Jul 12 '13 at 15:50
3

This answer makes sense if you do not call setArguments(Bundle) in the constructor, which is not the case here. – xesxz Jul 19 '14 at 15:55

score 4 · Answer 4 · edited Jan 08 '16 at 21:36

4

Because when android is recreating a fragment, it always uses the empty constructor, and by using newInstance() you can set data that fragment uses when recreating, for example when the screen is rotated

for example:

   public static FragmentExample newInstance(Parcelable uri) {
    FragmentExample fragmentExample = new FragmentExample();

    Bundle bundle = new Bundle();
    bundle.putParcelable("Uri", uri);
    fragmentExample.setArguments(bundle);

    return fragmentExample;
}

edited Jan 08 '16 at 21:36

Dalbergia

1,699
1
17
26

answered Dec 23 '12 at 14:44

Srokowski Maciej

431
5
15

There's no reason to have a static method; just have two constructors. – Glenn Maynard Apr 20 '13 at 22:20
4

Glenn, did you even read the answer? Two constructors will not solve the problem – Justin Jul 12 '13 at 15:48
1

Justin, did you read the question? In this case (where setArguments is called in the constructor), two constructors will certainly solve the problem. – xesxz Jul 19 '14 at 16:00

Why use newInstance for DialogFragment instead of the constructor?

4 Answers4

Linked