android-Supporting Tablets and Handsets

Typically, all you need to do is design your UI to be flexible and optimize some elements for different sizes by providingalternative resources (such as alternative layouts that reposition some views or alternative dimension values for views). 

With Android 3.0 (API level 11), Android introduced a new set of framework APIs that allow you to more effectively design activities that take advantage of large screens: the FragmentAPIs.

Android 3.0 also introduced ActionBar, which provides a dedicated UI at the top of the screen to identify the app and provide user actions and navigation.

Before you continue with this guide, it's important that you first read the guide to Supporting Multiple Screens. That document describes the fundamental design principles for developing a UI that supports different screen sizes and densities with flexible layouts and alternative bitmaps, respectively.

>Here are a few guidelines that will help you create an app that provides an optimized user experience on both tablets and handsets:

1.Build your activity designs based on fragments that you can reuse in different combinations—in multi-pane layouts on tablets and single-pane layouts on handsets.(Fragment)

2.Use the action bar, but follow best practices and ensure your design is flexible enough for the system to adjust the action bar layout based on the screen size.(Action Bar)

3.Implement flexible layouts, as discussed in the Best Practices for supporting multiple screens and the blog post, Thinking Like a Web Designer.

>Note: Aside from one feature in the action bar, all the APIs needed to accomplish the recommendations in this document are available in Android 3.0. Additionally, you can even implement the fragment design patterns and remain backward-compatible with Android 1.6, by using the support library—discussed in the side bar below.

If you want to use fragments in your application and remain compatible with versions of Android older than 3.0, you can do so by using the AndroidSupport Library (downloadable from the SDK Manager).

The most effective way to create a distinct user experience for tablets and handsets is to create layouts with different combinations of fragments, such that you can design "multi-pane" layouts for tablets and "single-pane" layouts for handsets.

>The approach you choose depends on your design and personal preferences. The first option (one activity; swapping fragments) requires that you determine the screen size at runtime and dynamically add each fragment as appropriate—rather than declare the fragments in your activity's XML layout—because you cannot remove a fragment from an activity if it's been declared in the XML layout. When using the first technique, you might also need to update the action bar each time the fragments change, depending on what actions or navigation modes are available for each fragment. In some cases, these factors might not affect your design, so using one activity and swapping fragments might work well (especially if your tablet design requires that you add fragments dynamically anyway). Other times, however, dynamically swapping fragments for your handset design can make your code more complicated, because you must manage all the fragment combinations in the activity's code (rather than use alternative layout resources to define fragment combinations) and manage the back stack of fragments yourself (rather than allow the normal activity stack to handle back-navigation).

 depending on the size of the screen:

• On a tablet-sized screen, the Activity A layout contains both Fragment A and Fragment B.
• On a handset-sized screen, the Activity A layout contains only Fragment A (the list view). In order to show the details in Fragment B, Activity B must open.

<?xml version="1.0" encoding="utf-8"?><LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"  android:orientation="horizontal"  android:layout_width="match_parent"  android:layout_height="match_parent"  android:id="@+id/frags">    <!-- "Fragment A" -->  <fragment class="com.example.android.TitlesFragment"            android:id="@+id/list_frag"            android:layout_width="@dimen/titles_size"            android:layout_height="match_parent"/>    <!-- "Fragment B" -->  <fragment class="com.example.android.DetailsFragment"            android:id="@+id/details_frag"            android:layout_width="match_parent"            android:layout_height="match_parent" /></LinearLayout>

To avoid directly calling one fragment from another, define a callback interface in each fragment class that it can use to deliver events to its host activity, which implements the callback interface. When the activity receives a callback due to an event (such as the user selecting a list item), the activity responds appropriately based on the current fragment configuration.

For example, Activity A from above can handle item selections depending on whether it's using the tablet or handset layout like this:

public class MainActivity extends Activity implements TitlesFragment.OnItemSelectedListener {    ...    /** This is a callback that the list fragment (Fragment A)        calls when a list item is selected */    public void onItemSelected(int position) {        DisplayFragment displayFrag = (DisplayFragment) getFragmentManager()                                    .findFragmentById(R.id.display_frag);        if (displayFrag == null) {            // DisplayFragment (Fragment B) is not in the layout (handset layout),            // so start DisplayActivity (Activity B)            // and pass it the info about the selected item            Intent intent = new Intent(this, DisplayActivity.class);            intent.putExtra("position", position);            startActivity(intent);        } else {            // DisplayFragment (Fragment B) is in the layout (tablet layout),            // so tell the fragment to update            displayFrag.updateContent(position);        }    }}

If Fragment B needs to deliver a result back to Fragment A (because Activity B was started withstartActivityForResult()), then the process works similarly with a callback interface between Fragment B and Activity B. That is, Activity B implements a different callback interface defined by Fragment B. When Activity B receives the callback with a result from the fragment, it sets the result for the activity (with setResult()) and finishes itself. Activity A then receives the result and delivers it to Fragment A.

> By using the standard ActionBar APIs to design your action bar, the Android system does all the work to gracefully adapt the action bar for different screen sizes. Here are some important tips to follow when creating your action bar:

• When setting a menu item to be an action item, avoid using the "always" value. In your menu resource, use"ifRoom" for the android:showAsAction attribute if you'd like the menu item to appear in the action bar. However, you might need "always" when an action view does not provide a default action for the overflow menu (that is, it must appear as an action view). However, you should not use "always" more than once or twice. In almost all other cases, use "ifRoom" as the value for "android:showAsAction" when you want the item to appear as an action item. Forcing too many action items into the action bar can create a cluttered UI and action items may overlap with other action bar elements such as the title or navigation items.
• When adding action items to the action bar with a text title, also provide an icon, when appropriate, and declare showAsAction="ifRoom|withText". This way, if there's not enough room for the title, but there is enough room for the icon, then only the icon may be used.
• Always provide a title for your action items, even if you don't enable "withText", because users can view the title as a "tool-tip" by performing a "long click" on the item—the title text appears momentarily in a toast message. Providing a title is also critical for accessibility, because screen readers read aloud the item title even when not visible.
• Avoid using custom navigation modes when possible. Use the built-in tab and drop-down navigation modes when possible—they're designed so the system can adapt their presentation to different screen sizes. For example, when the width is too narrow for both tabs and other action items (such as a handset in portrait orientation), the tabs appear below the action bar (this is known as the "stacked action bar"). If you must build a custom navigation mode or other custom views in the action bar, thoroughly test them on smaller screens and make any necessary adjustments to support a narrow action bar.

> Using split action bar

When your application is running on Android 4.0 (API level 14) and higher, there's an extra mode available for the action bar called "split action bar." When you enable split action bar, a separate bar appears at the bottom of the screen to display all action items when the activity is running on a narrow screen (such as a portrait handset). Splitting the action bar ensures that a reasonable amount of space is available to display action items on a narrow screen and also leave room for navigation and title elements at the top.

Note: Although the uiOptions attribute was added in Android 4.0 (API level 14), you can safely include it in your application even if your minSdkVersion is set to a value lower than "14" to remain compatible with older versions of Android. When running on older versions, the system simply ignores the attribute because it doesn't understand it. The only condition to adding it to your manifest is that you must compile your application against a platform version that supports API level 14 or higher. Just be sure that you don't openly use other APIs in your application code that aren't supported by the version declared by your minSdkVersionattribute.

Other Design Tips

---

• When working with a ListView, consider how you might provide more or less information in each list item based on the available space. That is, you can create alternative layouts to be used by the items in your list adapter such that a large screen might display more detail for each item.
• Create alternative resource files for values such as integers, dimensions, and even booleans. Using size qualifiers for these resources, you can easily apply different layout sizes, font sizes, or enable/disable features based on the current screen size.