We've just discovered that when we rotate the app,

we end up with two list fragments.

And what's worse is that if we keep rotating the app,

we get another new list fragment on each rotation.

So why is this happening?

Well, it's actually just Android trying to be

helpful by restoring our fragments automatically.

When we launch the app, we create our list fragment and

we add it to our UI by using the fragment manager.

Then, when we rotate the app, our fragment is automatically restored and

we create a new fragment.

To see this a little better, let's do some debugging.

Let's add a break point to our activities super.onCreate method,

and then hit the Debug button.

After a few seconds, we should be stopped at our break point.

Nice.

Notice that we have a null savedInstanceState.

Now, since we're mostly interested in what happens after we rotate the app,

let's hit the resume program button and then rotate the app.

And now we're back at our breakpoint again except

this time savedInstanceState isn't null.

Let's step into this super.OnCreate method by using this button over here.

Then let's step over this first log call.

And then let's take a look at the log.

So far so good, just the one onCreate message.

Back on the debug tab, let's step over this super call as well

and once that's done, let's check the log again.

This is what I mean when I say that the fragment will be automatically restored.

We didn't do anything and yet here we have onAttach and onCreate for our fragment.

So going back to the debug tab, if we step out of this method

to go back to main activity it becomes pretty clear where the problem is.

We shouldn't be making a new list fragment if we already have one.

Okay, let's go ahead and end this debugging session and

see how we can fix this.

Remember that when we first launched the app, savedInstantState was null.

But when we rotated it, saveInstanceState got a value.

So really all we need to do is say if

savedInstanceState is null.

Then add our fragment.

Let's quickly run this.

And if we rotate the app it looks like it worked and it did work.

This is a perfectly acceptable solution to our problem.

But depending on your app, it might not be the best solution.

What if we needed access to our list fragment instance from another method and

main activity?

We could refactor our list fragment to be a field, but

still this field is only being set when savedInstanceState is null.

To fix this above the if statement

let's create a new list fragment variable named savedFragment.

And set it equal to getFragmentManager.findFrangmentById(R.id-

.placeholder).

Then let's use Alt Enter to cast the returned fragment as a ListFragment.

The findFragmentById method takes in a resource ID and returns a fragment.

If the fragment can't be found it returns null.

The resource ID we pass in should either be the ID of the fragment

if it was added directly to the XML or

the ID of the fragment's placeholder if it was added dynamically.

Now instead of checking if savedInstanceState is null we can instead

check if savedFragment is null.

Which for now makes the code a little bit easier to read.

We look for a ListFragment and if we don't find it, we create and add a new one.

Now, let's do one last test to make sure everything is in good working order.

So if I rotate and rotate and scroll a bunch.

Nice, no double fragments.

And if we look over to the log.

We've only got one fragment on resume call, just like it should be.

Now that we've got our life cycle under control, let's go ahead and

un-extend our logging classes.

Change logging activity back to AppCompatActivity,

and over in ListFragment change LoggingFragment

back to Fragment, and remove the log call.

Then I'm going to delete the two logging classes.

But you should feel free to keep them around.

In the next video we'll start work on launching a new fragment when we receive

a tap on our ListFragment.