07-39 Build 2-Pane Tablet UI

07-39 Build 2-Pane Tablet UI

By taking the knowledge that we
learned about overriding resources

in other folders,

we'll walk through the code together on
how to build up the two-pane tablet UI.

First remove the values W820dp folder
because we don't need to provide

specific logic when for when the current
orientation is greater than 820dp.

Then go ahead and
make the layout XML changes.

Then create a new
layout SW 600dp folder.

And then add a new file
called activity_main.

We use the same file name as in
the base layout folder activity_main so

that this one overrides the behavior
specifically on tablets.

To see the code for this file you
can check out the gist below.

Essentially it's a horizontal linear
layout that can hold a forecast fragment

on the left and
a detail fragment on the right.

Now's a good time to talk about
static verses dynamic fragments.

In our implementation the forecast
fragment is the static fragment because

we're defining it in the XML layout no
matter what orientation or device size

we know that we're going to need a
forecast fragment in the main activity.

On the other hand, we only declare
a container for the detail fragment, but

not the actual fragment.

It's initialized with different
arguments each time as a dynamic

fragment, so it's better to
dynamically create and add that

fragment in a fragment transaction
in the main activity Java code.

That way the fragment manager can keep
track of those initialization arguments

and pass those back to us on,
after device rotation.

Then we need to update
the one pane UI layouts so

that they're consistent
with the two pane case.

So in the activity main file for
the base layout folder this used to be

a frame layout we're going to
declare it as a forecast fragment.

That way it will match the two pane UI,

where this also is declared
as a fragment in the XML.

That way the main activity never has
to worry about dynamically adding

the forecast fragment.

In the main activity
on create view method.

Since the fragment is already inside
this layout we can just remove this so

we don't dynamically add it again.

Similarly we modify the activity detail
layout in the base layout folder

we change the frame layout ID
to be weather detail container.

So that it matches the container
view id in the two pane UI case.

The pattern here is that
the detail fragment will always be

added to a container called
weather_detail_container,

both in the two pane, and one pane case.

Since we changed the name
of the container,

we should also update
the detail activity.

This is only used in one pane mode.

Here's where we change
the container name.

In the one pane mode the detailed
activity will add the detail fragment

dynamically to this container.

After we modify the layout we
should update the main activity so

we dynamically add the detail fragment.

In the main activity on create method we
check for the presence of the weather

detail container in the layout to know
whether this is a two pane UI or not.

We keep track of this information
in a Boolean called mTwoPane.

Remember that we start with the letter
m, because it's a member variable.

In this case,
the Boolean should be true.

So we go ahead and
create a new detail fragment, and

add it to the weather_detail_container.

We commit the change by using
a fragment transaction,

which Rado introduced earlier.

Otherwise If the detail container
is not present in the layout, then

the boolean should be false, meaning
that this is a one-pane UI for phones.

In this case, the detail activity will
handle showing the detail fragment.

Notice for the two-pane case that
we check if the saved instant state

bundle is null.

If the save instant save
bundle is not null,

then we don't create a new one,
and here is the reason why.

Say you want to rotate the device.

Before the activity and

fragments get torn down, we store
information in save state bundles.

Then after the orientation change,
the system restores the activity and

the fragments,
by passing back the same bundle, so

that it can be recreated
with the same state.

That means if the bundle exists,
then we should let the system

handle restoring the detail fragment,
and we can skip this code.

Once a detail fragment
is added dynamically.

Make it show some placeholder
data just for testing purposes.

Later we'll plumb through the right
logic, so that it can display the right

information for
the selected date on the left.

Modify the detail fragment so

that it doesn't expect the incoming
intent to have a data URI.

In this case,
the detail fragment will just fall back

to some placeholder data
that we have in our XML.

The reason the intent could be blank
is because the detail fragment

can now exist within the main activity.

And the main activity isn't
launched with a URI for

only one date like the detail
activity is normally launched with.

Once you make the changes for

the wire frames this is what
the app should look like.

The reason it doesn't show
an icon here is because

we removed the icon from being
hard-coded in the layout.

But once this data is populated
dynamically in a later section,

it should show up again.