The configuration information of each Android device includes the screen size group to which the device belongs. The four screen size groups are small, normal, large, or xlarge.

Just as we created a specific layout resource file for landscape orientation, we can create a layout resource file targeting a particular screen size group. We associate the resource file with the desired screen size group by placing the file in the appropriately named resource folder. For example, we place a layout resource file designed for devices with a screen size group of large in the layout-large resource folder.

Screen size groups date back to the early days of Android when there was little practical experience in dealing with the wide variety of device form factors that now exist. As time has gone on and the number of Android device form factors has grown, file size groups have turned out to be a less than ideal solution. Problems with screen size groups stem from two main issues:

Size groups are still in use because they are the best option available for dealing with screen size differences on pre-API Level 13 devices. Fortunately, less than half of the Android devices in use today are pre-API Level 13, and the ratio is shrinking rapidly.

At API Level 13 (Android 3.2), Android introduced a substantial improvement over screen size groups known as resource screen size qualifiers. Resource screen size qualifiers allow us to associate resources with specific screen size requirements. With screen size qualifiers, we have a very detailed level of control over which layout resources are associated with each device form factor.

To avoid the complications inherent in the wide variety of screen pixel densities and physical screen sizes available, Android uses a canonicalized unit of measure called the density independent pixel (dp) when managing screen sizes. If you've been working with Android for any length of time, you are probably already familiar with density independent pixels as they are the preferred unit of measure when positioning and sizing views within an Android user interface.

A dp always corresponds to the physical size of a pixel on a 160 dpi device and therefore provides a consistent unit of measure independent of the physical pixel size of the device. For example, one 7-inch display device may have a physical pixel count of 1280x720 while another 7-inch display device has a physical pixel count of 1920x1080, but both devices have a dp count of approximately 1000x600. The Android platform takes care of the details of mapping between density independent pixels and the physical pixels of a device.

Android provides three types of screen size qualifiers: smallest width, available screen width, and available screen height:

Layout aliasing allows us to have just a single copy of each layout resource file. We can then provide the resource system with information as to which file to choose for each form factor.

To get started, we'll rename the activity_main.xml resource file in the layout-land resource folder as activity_main_wide.xml. We then move the file to the layout resource folder and delete the layout-land folder.

We now create a new resource folder called values-land under the res folder. To create the folder in Android Studio, follow the same steps as we used earlier to create the layout-land folder except set the Resource type: as values rather than layout.

Within this folder, we create a new resource file, the name of which doesn't matter, but the file containing values for aliasing is often named refs.xml because it contains a list of references to other resources, so that's what we'll use. To create the file using Android Studio, perform the following steps:

In the refs.xml file, be sure that there is already a root element named resources. Within that element, add an item element with a type attribute value of layout. This indicates that we're providing an alias entry for a layout resource. We set the value of the name attribute to be the name of the default layout resource, which in our case is activity_main. We then give the item element a value of @layout/activity_main_wide. The complete refs.xml resource file now appears as follows:

<resources>
  <item type=""layout"" name=""activity_main"">
    @layout/activity_main_wide
  </item>
</resources>

With this file in place, any call to load the layout resource R.layout.activity_main will instead load R.layout.activity_main_wide when the application is running on a device in landscape orientation.

To add support for devices in the large group and those with a current width of at least 600 dp, we simply create two more resource folders, values-large and values-w600dp, and copy the refs.xml file from the values-land folder to each. The layout and values resource folders now appear as shown in the following screenshot:

We now have support for all the desired form factors with no unnecessary duplication of layout resource files. We do have duplication of the refs.xml file, but it's a much simpler file than the layout resource file and is less likely to change.

The callback interface should include methods for any interaction with the fragment that may be meaningful to the activity containing the fragment. At the same time, the interface should not burden the activity with unnecessary details. The interface should be focused on application-level actions such as selecting a book rather than implementation-level actions such as tapping on a radio button. The implementation-level details should be isolated within the fragment. We should also be sure to design the interface without any preconceived ideas of what the activity will do with the notification.

In the case of BookListFragment, the only action of interest to the activity is the user selecting a book. This tells us the interface needs just a single method; we'll call the interface method onSelectedBookChanged. We know in the case of this application, the goal is to display the selected book description, so one possibility is to have the onSelectedBookChanged method include a parameter for the book description. The problem with passing the book description is that doing so limits the use of BookListFragment to just this one use case, displaying the book description. Instead, by passing an identifier for the book, BookListFragment is available for any use case in which the user selects a book. For simplicity, in our example, we'll use an array index as the identifier; in a real scenario, the identifier would more likely be a key to locate the book information within a data store or service.

We'll call our new interface OnSelectedBookChangeListener. The interface looks like this:

public interface OnSelectedBookChangeListener {
  void onSelectedBookChanged(int bookIndex);
}

The BookListFragment class needs to hide the details of user selections and instead translate each selection to a book identifier, which in our case is an array index. We first need to update the BookListFragment class to handle the radio button selections by implementing the RadioGroup.OnCheckedChangeListener interface as follows:

public class BookListFragment extends Fragment
    implements RadioGroup.OnCheckedChangeListener {

  @Override
  public void onCheckedChanged(RadioGroup radioGroup, int id)  {

  }

  // Other members elided for clarity

}

Within the BookListFragment class' onCreateView method, we set the radio group's click listener as the BookListFragment class as shown here:

public View onCreateView(LayoutInflater inflater,
    ViewGroup container, Bundle savedInstanceState) {
  View viewHierarchy = inflater.inflate(
      R.layout.fragment_book_list, container, false);

  // Connect the listener to the radio group
  RadioGroup group = (RadioGroup)
  viewHierarchy.findViewById(R.id.bookSelectGroup);
  group.setOnCheckedChangeListener(this);

  return viewHierarchy;
}

There are a number of ways to determine the book index corresponding to the selected radio button such as setting the tag value on each radio button or using a lookup table. For simplicity, we'll create a simple method containing a switch statement like the following code:

  int translateIdToIndex(int id) {
    int index = -1;
    switch (id) {
      case R.id.dynamicUiBook:
        index = 0 ;
        break;
      case R.id.android4NewBook:
        index = 1 ;
        break;
      case R.id.androidSysDevBook:
        index = 2 ;
        break;
      case R.id.androidEngineBook:
        index = 3 ;
        break;
      case R.id.androidDbProgBook:
        index = 4 ;
        break;
    }

    return index;
  }

A fragment can always access the activity on which it is placed using the getActivity method. Within the BookListFragment class' onClick method, we can use the getActivity method to access the activity, cast it to the OnSelectedBookChangeListener interface, and then call the onSelectedBookChanged method and pass it the book index for the selected radio button as shown in the following code:

public void onCheckedChanged(RadioGroup radioGroup, int id) {
  // Translate radio button to book index    
  int bookIndex = translateIdToIndex(id);

  // Get parent Activity and send notification
  OnSelectedBookChangeListener listener =
      (OnSelectedBookChangeListener) getActivity();
  listener.onSelectedBookChanged(bookIndex);
}

The BookListFragment class now completely handles notifying the parent activity of each change in the user book selection.