Anticipating screen size with a responsive layout

Go with the flow when you’re designing your layout to fit multiple screen sizes. A flowing, or responsive, layout skips a lot of hassle and frustration for both the designer and the user.

If you’re familiar with iOS development from a few years back, you know that back then you only had a few screen sizes to worry about: a couple of iPhone sizes, and a couple of iPad sizes. Each size required both low‐ and high‐resolution images, but that was easy enough to handle: Design for iPhone first, and then for iPad, and then plug in the low‐ and high‐resolution images in the respective versions and you were done.

Android has never been quite as simple to design for. Layouts in Android need to “flow” — that is, resize and rearrange themselves — so that they can accommodate minor (and sometimes major) differences in the width and height of users’ devices. Android developers have dozens or hundreds of ­different sizes of devices to worry about.

It’s similar to designing for websites — when you’re building a website, you can’t assume that all users will view it in browser windows that are exactly the same size (800 x 600 pixels). Users may view the site from bigger (or sometimes smaller) browser windows; your design must be flexible enough to give a good experience to the whole range of sizes. Designing for Android makes the same requirement. In fact, iOS is now moving in this same direction, and encouraging their developers to use flowing layouts as well.

So how do you perform this bit of magic? For openers, don’t try to use fixed dimensions (such as 10px or 120dp) in your layouts. Instead, favor relative dimensions, such as "wrap_content" and "match_parent" as much as possible. The idea is to achieve a responsive layout that can resize to fit the device.

The following code shows a layout that makes too many assumptions about the device it’s on:

<?xml version="1.0" encoding="utf-8”?>
<TextView xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="300px"
    android:layout_height="match_parent"
    android:lines="1"
    android:text="Occurrences of the word 'Internet' in the Gettysburg
            Address: 0 (unverified)"/>

The code has multiple problems:

• It uses a fixed‐sized TextView rather than flexible dimensions, like wrap_content and match_parent.
• It uses pixels (px) to measure size, which doesn’t scale automatically across different devices, as dp (device‐independent pixels) would.
• It hard‐codes the number of lines in TextView to 1 and doesn’t tell Android what to do with any overflow.
• It doesn’t use ScrollView, so if your layout is taller than the device screen, there’s no way to see the offscreen views.
• Generally speaking, many of your layouts should be wrapped in a single ScrollView to handle unanticipated overflow off the bottom of the screen. Exceptions include layouts that already handle scrolling, such as ListView, which shouldn’t be wrapped in a ScrollView. The example above uses only a single TextView, so it’s unlikely to need a ScrollView, but more complicated layouts should consider them.

Figure 16-1 shows the TextView from the above code. It abruptly cuts off text midsentence because of the fixed size. If the developer had used a responsive layout, the text wouldn’t have been cut off.

Fixing this particular example is easy by changing the width of the TextView and replacing android:lines="1" with android:maxLines="3":

<?xml version="1.0" encoding="utf-8”?>
<TextView xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:maxLines="3"
    android:text="Occurrences of the word 'Internet' in the Gettysburg Address:
            0 (unverified)"/>

When you’re designing your layouts, always consider the maximum size of each item in your layout. The app content can take up more space than you expect, and it’s important to anticipate these situations and plan for them rather than end up with an app that looks ugly.

Adding more fragments

Android uses fragments to help you deal with the additional real estate on tablets. The basic idea is that a typical phone activity centers on one, two, or three distinct groups of reusable onscreen items. Put each of these groups into its own fragment and it becomes easy to reuse across multiple activities.

You’re going to do exactly this — you’ll add the TaskEditFragment and the TaskListFragment from your two phone activities into a single new activity that tablet users will enjoy.

Figure 16-2 shows how Tasks fragments lay out on a phone and on a tablet.

Without fragments, you’d have to reinvent the wheel every time you wanted to make an activity that shows a list of tasks. Using fragments, just write the code once and you can reuse it as many times as you want.

Creating different layouts for different devices

The fragment is a handy feature for the designer, but how do you slice and dice fragments to show the right experience for the right device? The tablet’s relatively vast screen real estate (compared to a phone) can show one or two more fragments on a single activity.

You can use one layout containing a single activity for your phone and another layout containing multiple fragments for your tablet. For example, here’s the TaskListActivity layout for the phone size in the Tasks app:

<?xml version="1.0" encoding="utf-8"?>
<fragment xmlns:android="http://schemas.android.com/apk/res/android"
            android:name="com.dummies.tasks.fragment.TaskListFragment"
            android:layout_width="match_parent"
            android:layout_height="match_parent"
/>

And Listing 16-1 shows how you might modify the code using two ­fragments to create a two‐column layout on a tablet:

Listing 16‐1: Two‐Column Table Layout Example

<?xml version="1.0" encoding="utf-8?>"
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:orientation="horizontal"
    android:layout_height="match_parent">

<fragment
            android:id="@+id/list_fragment"
            android:name="com.dummies.tasks.fragment.TaskListFragment"
            android:layout_width="0dp"
            android:layout_weight="1"
            android:layout_height="match_parent"
/>

<fragment
            android:id="@+id/edit_fragment"
            android:name="com.dummies.tasks.fragment.TaskEditFragment"
            android:layout_width="0dp"
            android:layout_weight="1"
            android:layout_height="match_parent"
/>

</LinearLayout>

This is very similar to what you’ll do later in the chapter to put two ­fragments next to each other.

Moving the TaskListAdapter

First, go to your AndroidManifest.xml file and remove the following code:

        <activity
            android:name="com.dummies.tasks.activity.TaskListActivity"
            . . . >
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            <intent-filter>
        </activity>

The TaskListActivity will be used only on your phone. You create a ­different activity for tablets. So for that reason, you just removed it from the shared AndroidManifest.xml.

The next step is to create the phone’s AndroidManifest.xml. But before creating it, first create the phone directory by going to your src directory and creating a new directory named phone. The directory phone must match the name of the flavor you created in your build.gradle in the previous section.

Next, create a new AndroidManifest.xml file in the src/phone directory with the following contents:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" >

    <application>
        <activity android:name="com.dummies.tasks.activity.TaskListActivity" >
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>
        </activity>
    </application>

</manifest>

You just moved the TaskListActivity from the shared AndroidManifest.xml to the phone‐specific AndroidManifest.xml.

Now build and run your app to make sure you haven’t broken anything. If everything worked properly, the app should run identically to how it did before you split the AndroidManifest.xml.

Informing the Google Play Store

There is one more thing you need to do: Tell the Google Play Store that the phone version of your app should only be visible and installable on phones, not tablets. If you do not do this, the Google Play Store will show the phone app to people on tablets!

Open the src/phone/AndroidManifest.xml file and add the code in bold:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" >

    <compatible-screens>
        <!-- all small size screens -->
        <screen android:screenSize="small" android:screenDensity="ldpi" /> →6
        <screen android:screenSize="small" android:screenDensity="mdpi" />
        <screen android:screenSize="small" android:screenDensity="hdpi" />
        <screen android:screenSize="small" android:screenDensity="xhdpi"/>
        <screen android:screenSize="small" android:screenDensity="480" /> →10
        <!-- all normal size screens --/>
        <screen android:screenSize="normal" android:screenDensity="ldpi" /> →12
        <screen android:screenSize="normal" android:screenDensity="mdpi" />
        <screen android:screenSize="normal" android:screenDensity="hdpi" />
        <screen android:screenSize="normal" android:screenDensity="xhdpi"/>
        <screen android:screenSize="normal" android:screenDensity="480" /> →16
    </compatible-screens>

    <application>
        <activity android:name="com.dummies.tasks.activity.TaskListActivity" >
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>
        </activity>
    </application>

</manifest>

The compatible‐screens element is not used by Android or your app directly. It is used only by the Google Play Store to determine which devices this app is compatible with.

→ 10 Declares that your app is compatible with all five resolutions of "small" screens (ldpi, mdpi, hdpi, xhdpi, and xxhdpi). You’ll notice that instead of saying xxhdpi on line 10, we say 480. This is because, at the time of this writing, the compatible‐screens element does not yet support xxhdpi directly, so we need to use the numerical value for xxhdpi, which is 480.

→ 12—16 Does the same, but for "normal" size devices.

These two sections declare that your app will run fine on small and normal devices, but will not run on large or extra‐large devices (generally tablets).

The compatible‐screen element is a little tricky. If you want to make changes to this section, make sure you read http://d.android.com/guide/practices/screens‐distribution.html.

Creating the tablet activity class

The first step is to create the directories you need. Create the following directories inside the tablet directory:

• java
• java/com
• java/com/dummies
• java/com/dummies/tasks
• java/com/dummies/tasks/tablet
• java/com/dummies/tasks/tablet/activity

Then create a new file inside the tablet/java/com/dummies/tasks/ tablet/activity directory named TaskListAndEditorActivity.java with the following code:

public class TaskListAndEditorActivity extends Activity
    implements OnEditTask, OnEditFinished →2
{

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_task_list_and_editor);
        setActionBar((Toolbar) findViewById(R.id.toolbar));
    }

    /**
    * Called when the user asks to edit or insert a task.
    */
    @Override
    public void editTask(long id) { →16
    }

    /**
    * Called when the user finishes editing a task.
    */
    @Override
    public void finishEditingTask() { →23
    }

}

The onCreate method creates a new activity, sets its content to the activity_task_list_and_editor.xml layout (which you will create), and sets its action bar to the toolbar element.

In addition, you’ll see the following happen on these lines:

→ 2 You declare that this activity will implement the OnEditTask and OnEditFinished interfaces.

→ 16‐23 The methods from the interfaces on line 2 are defined on these lines. Currently they are empty, but you will recall from Chapters 9 and 10 that these methods are used to figure out what the fragment will do when the user asks to edit a task and finishes editing a task. You will complete these methods in a later section.

Adding the tablet layout

Next, add the layout file. Create a new directory inside the src/tablet directory called res. Inside res, create a directory named layout, and inside the layout directory create the layout file named activity_task_list_and_editor.xml:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"→2
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    android:baselineAligned="false">

    <Toolbar →8
        style="?android:actionBarStyle"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:title="@string/app_name"
        android:id="@+id/toolbar"/>

    <LinearLayout →15
                android:layout_width="match_parent"
                android:layout_height="match_parent"
                android:orientation="horizontal"
                android:baselineAligned="false">

          <fragment →21
            android:id="@+id/list_fragment"
            android:name="com.dummies.tasks.fragment.TaskListFragment"
            android:layout_width="0dp"
            android:layout_height="match_parent"
            android:layout_weight="1"/>

          <FrameLayout →28
            android:id="@+id/edit_container"
            android:layout_width="0dp"
            android:layout_height="match_parent"
            android:layout_weight="2"/>

    </LinearLayout>

</LinearLayout>

This layout consists of three main parts:

• A toolbar
• The list fragment
• A framelayout which holds your edit fragment

If you look back to Listing 16-1 at the beginning of the chapter, you’ll see that the layout is pretty similar, but instead of having two fragments in the layout, it has one fragment and one placeholder. The reason the second fragment needs to be a placeholder is because the edit fragment cannot be instantiated without knowing the ID of the task that needs to be edited. Because the ID isn’t known at the time the layout is created, you must inflate the fragment manually so that you can specify the ID. Look back at Chapter 10 and you’ll see you needed to do the same thing there for the TaskEditFragment.

Discussion of the previous code in more detail:

→ 2 A vertical LinearLayout that holds the two fragments for your tablet layout. Set baselineAligned to false as recommended by Android lint to get a tiny bump in performance. See Chapter 17 for more information about Android lint.

→ 8 The toolbar for the activity. It won’t be styled automatically, so set its style to the theme’s actionBarStyle. Also set its title to the app’s name.

→ 15 A second LinearLayout, this one arranged horizontally. This LinearLayout is used to hold the two side‐by‐side fragments.

→ 21 The list view fragment, which occupies the leftmost third of the screen. It is using one‐third of the screen because its layout_weight is set to 1, whereas the layout_weight of the other fragment on line 28 is set to 2, and 1 out of 3 is one‐third. Remember, when using layout_weight, you must set your layout_width to 0.

→ 28 The edit view fragment, which occupies the remaining two of three parts of the screen.