diff --git a/docs/html/guide/topics/fragments/index.jd b/docs/html/guide/topics/fragments/index.jd
index d07daf47a2d58..045a1e8ae6765 100644
--- a/docs/html/guide/topics/fragments/index.jd
+++ b/docs/html/guide/topics/fragments/index.jd
@@ -6,7 +6,7 @@ page.title=Fragments
Quickview
- - Decompose application functionality and UI into reusable modules
+ - Fragments decompose application functionality and UI into reusable modules
- Add multiple fragments to a screen to avoid switching activities
- Fragments have their own lifecycle, state, and back stack
- Fragments require API Level HONEYCOMB or greater
@@ -14,12 +14,27 @@ page.title=Fragments
In this document
- - Creating fragments
- - Adding a fragment to an activity
- - Managing fragments
- - Handling the lifecycle
- - Integrating with the activity
- - Adding menus
+ - Design Philosophy
+ - Creating a Fragment
+
+ - Adding a user interface
+ - Adding a fragment to an activity
+
+
+ - Managing Fragments
+ - Performing Fragment Transactions
+ - Communicating with the Activity
+
+ - Creating event callbacks to the activity
+ - Adding items to the Action Bar
+
+
+ - Handling the Fragment Lifecycle
+
+ - Coordinating with the activity lifecycle
+
+
+ - Example
Key classes
@@ -29,100 +44,108 @@ page.title=Fragments
- {@link android.app.FragmentTransaction}
-
+A {@link android.app.Fragment} represents a behavior or a portion of user interface in an
+{@link android.app.Activity}. You can combine multiple fragments in a single activity to build a
+multi-pane UI and reuse a fragment in multiple activities. You can think of a fragment as a
+modular section of an activity, which has its own lifecycle, receives its own input events, and
+which you can add or remove while the activity is running.
-An {@link android.app.Activity} is always the window in which users interact with your
-application, but a {@link android.app.Fragment} can be responsible for distinct operations and UI
-that's embedded in an activity. So, when using fragments, your activity becomes more like a
-container for fragments that define the activity's behavior and UI.
+A fragment must always be embedded in an activity and the fragment's lifecycle is directly
+affected by the activity's lifecycle. For example, when the activity is paused, so are all
+fragments in it, and when the activity is destroyed, so are all fragments. However, while an
+activity is running (it is in the resumed lifecycle state), you can
+manipulate each fragment independently, such as add or remove them. When you perform such a
+fragment transaction, you can it to a back stack managed by the
+activity—each back stack entry in the activity is a record of the fragment transaction that
+occurred. The back stack allows the user to reverse a fragment transaction (navigate backwards),
+by pressing the BACK key.
-Fragments have their own
-set of lifecylce callback methods and recieve their own user input events. A fragment must always be
-embedded in an activity and the fragment's lifecycle is directly affected by the activity's
-lifecycle. For example, when the activity is stopped, so are all fragments in it, and when
-the activity is destroyed, so are all fragments. However, while an activity
-is active (in the "resumed" lifecycle stage), you can manipulate the lifecycle of each fragment
-independently. For example, you can add and remove fragments while the activity is active and you
-can add each fragment to a back stack within the activity—each back stack entry in the
-activity is actually a record of a "transaction" that occurred with the activity's fragments, so
-that the user can reverse the transaction with the BACK key (this is discussed more later).
+When you add a fragment as a part of your activity layout, it lives in a {@link
+android.view.ViewGroup} inside the activity's view hierarchy and defines its own layout of views.
+You can insert a fragment into your activity layout by declaring the fragment in the activity's
+layout file, as a {@code <fragment>} element, or from your application code by adding it to an
+existing {@link android.view.ViewGroup}. However, a fragment is not required to be a part of the
+activity layout; you may also use a fragment as an invisible worker for the activity.
-
+This document describes how to build your application to use fragments, including
+how fragments can maintain their state when added to the activity's back stack, share
+events with the activity and other fragments in the activity, contribute to the activity's action
+bar, and more.
-Android introduced fragments in Android X.X (API Level HONEYCOMB), with the primary intention to
-support more dynamic and flexible UI designs on large screen devices, such as tablets. Because a
-tablet has a much larger screen than a mobile phone, there's more room to interchange UI
-elements. Fragments allow that without the need for you to start a new activity or manage complex
-changes to the view hierarchy. By dividing the layout of an activity into fragments, the code
-that defines your activity becomes more modular and interchangable, allowing you to modify the
-activity's appearance at runtime and for different types of screens.
+
+Design Philosophy
+
+Android introduced fragments in Android 3.0 (API Level "Honeycomb"), primarily to support more
+dynamic and flexible UI designs on large screens, such as tablets. Because a
+tablet's screen is much larger than that of a mobile phone, there's more room to combine and
+interchange UI components. Fragments allow such designs without the need for you to manage complex
+changes to the view hierarchy. By dividing the layout of an activity into fragments, you become able
+to modify the activity's appearance at runtime and preserve those changes in a back stack
+that's managed by the activity.
For example, a news application can use one fragment to show a list of articles on the
left and another fragment to display an article on the right—both fragments appear in one
activity, side by side, and each fragment has its own set of lifecycle callback methods and handle
-their own user input events. Thus, instead using one activity to select an article and another
+their own user input events. Thus, instead of using one activity to select an article and another
activity to read the article, the user can select an article and read it all within the same
-activity.
+activity, as illustrated in figure 1.
-
+
+Figure 1. An example of how two UI modules that are
+typically separated into two activities can be combined into one activity, using fragments.
-When you use a fragment as a part of your layout, it technically lives within a {@link
-android.view.View} of the activity's layout and defines its own layout of views. You can insert a
-fragment into your activity layout by declaring the fragment in the activity's XML layout file, as
-a {@code <fragment>} element, or from your application code by adding it to an existing {@link
-android.view.View}. However, a fragment is not required to be a part of the activity
-layout—you might use a fragment as an invisible worker for the activity (more about that
-later).
-The rest of this document describes how to build your application to use fragments, including
-how fragments can contribute to the activity options menu and action bar, create context menus,
-maintain their state when added to the activity's back stack, and more.
+A fragment should be a modular and reusable component in your application. That is, because the
+fragment defines its own layout and its own behavior using its own lifecycle callbacks, you
+can include one fragment in multiple activities. This is especially important because it allows you
+to adapt your user experience to different screen sizes. For instance, you might include multiple
+fragments in an activity only when the screen size is sufficiently large, and, when it is not,
+launch separate activities that use different fragments.
+
+For example—to continue with the news application example—the application can embed
+two
+fragments in Activity A, when running on an extra large screen (a tablet, for example).
+However, on a normal-sized screen (a phone, for example),
+there's not be enough room for both fragments, so Activity A includes only the fragment for
+the list of articles, and when the user selects an article, it starts Activity B, which
+includes the fragment to read the article. Thus, the application supports both design patterns
+suggested in figure 1.
Creating a Fragment
-An implementation of the {@link android.app.Fragment} class contains code that looks a lot like
-the code in an {@link android.app.Activity}. In fact, if you're
-converting an existing Android application to use fragments, you'll move code
-from your {@link android.app.Activity} implementation into your {@link android.app.Fragment} class
-implementation, and into some of the same callback methods. A fragment contains callback methods
-similar to an activity, such as {@link android.app.Fragment#onCreate onCreate()}, {@link
-android.app.Fragment#onStart onStart()}, {@link android.app.Fragment#onPause onPause()}, and {@link
-android.app.Fragment#onStop onStop()}.
+
-If you're creating a fragment to be a modular piece of an activity UI, then your
-implementation of {@link android.app.Fragment} should include most of the same lifecycle
-callback methods traditionally implemented by the activity to initialize elements of the UI and
-save and restore state information. Usually, you'll want to implement the following methods:
+To create a fragment, you must create a subclass of {@link android.app.Fragment} (or an existing
+subclass of it). The {@link android.app.Fragment} class has code that looks a lot like
+an {@link android.app.Activity}. It contains callback methods similar to an activity, such
+as {@link android.app.Fragment#onCreate onCreate()}, {@link android.app.Fragment#onStart onStart()},
+{@link android.app.Fragment#onPause onPause()}, and {@link android.app.Fragment#onStop onStop()}. In
+fact, if you're converting an existing Android application to use fragments, you might simply move
+code from your activity's callback methods into the respective callback methods of your
+fragment.
+
+Usually, you should implement at least the following lifecycle methods:
- {@link android.app.Fragment#onCreate onCreate()}
- The system calls this when creating the fragment. Within your implementation, you should
-initialize the essential components of the fragment that should be retained when the fragment is
-paused or stopped.
+initialize essential components of the fragment that you want to retain when the fragment is
+paused or stopped, then resumed.
- {@link android.app.Fragment#onCreateView onCreateView()}
- The system calls this when it's time for the fragment to draw its user interface for the
first time. To draw a UI for your fragment, you must return a {@link android.view.View} from this
@@ -135,101 +158,117 @@ should commit any changes that should be persisted beyond the current user sessi
the user might not come back).
-Most applications should implement at least these three methods for each fragment, but there are
-several other lifecycle callback methods that you should also use in order to provide the best
-user experience when switching fragments and when the activity is paused or stopped. All of the
-lifecycle callback methods are discussed more later, in
-the section about Handling the Lifecycle.
+Most applications should implement at least these three methods for every fragment, but there are
+several other callback methods you should also use to handle various stages of the
+fragment lifecycle. All the lifecycle callback methods are discussed more later, in the section
+about Handling the Fragment Lifecycle.
-There are also a few different subclasses of {@link android.app.Fragment} that you might want
-to use:
+There are also a few subclasses that you might want to extend, instead of the base {@link
+android.app.Fragment} class:
- {@link android.app.DialogFragment}
- Displays a floating dialog. Using this class to create a dialog is a good alternative to using
-the dialog helper methods in the {@link android.app.Activity} class, because the dialog can be
-incorporated into the fragment back stack managed by the activity.
+the dialog helper methods in the {@link android.app.Activity} class, because you can
+incorporate a fragment dialog into the back stack of fragments managed by the activity,
+allowing the user to return to a dismissed fragment.
- {@link android.app.ListFragment}
- Displays a list of items that are managed by an adapter (such as a {@link
-android.widget.SimpleCursorAdapter}), similar to {@link android.app.ListActivity}. Provides methods
-for managing a list, such as the {@link
+android.widget.SimpleCursorAdapter}), similar to {@link android.app.ListActivity}. It provides
+several methods for managing a list view, such as the {@link
android.app.ListFragment#onListItemClick(ListView,View,int,long) onListItemClick()} callback to
-handle click events on list items.
+handle click events.
- {@link android.preference.PreferenceFragment}
- Displays a hierarchy of {@link android.preference.Preference} objects as a list, similar to
-{@link android.preference.PreferenceActivity}.
+{@link android.preference.PreferenceActivity}. This is useful when creating a "settings"
+activity for your application.
-However, subclassing the standard {@link android.app.Fragment} class is most common, if
-you're not creating a dialog, a list, or displaying preferences.
+Adding a user interface
-Providing a user interface
+A fragment is usually used as part of an activity's user interface and contributes its own
+layout to the activity.
-To provide a UI layout for a fragment, you must implement
-the {@link android.app.Fragment#onCreateView onCreateView()}
-callback method in your {@link android.app.Fragment} (unless your fragment is a subclass of
-{@link android.app.ListFragment}, which returns a {@link android.widget.ListView} from this method
-by default). The Android system calls {@link android.app.Fragment#onCreateView onCreateView()} when
-it's time for the fragment to draw its layout. Your implementation of this method must return a
+
To provide a layout for a fragment, you must implement the {@link
+android.app.Fragment#onCreateView onCreateView()} callback method, which the Android system calls
+when it's time for the fragment to draw its layout. Your implementation of this method must return a
{@link android.view.View} that is the root of your fragment's layout.
-The easiest way to provide your layout is to inflate it from a layout resource. To help you
-inflate a layout, the {@link android.app.Fragment#onCreateView onCreateView()} method passes a
-{@link android.view.LayoutInflater} that you can use to get your layout. For example, here's a
-simple subclass of {@link android.app.Fragment} that contains an implementation of {@link
-android.app.Fragment#onCreateView onCreateView()} that loads the fragment's layout from a
-resource:
+Note: If your fragment is a subclass of {@link
+android.app.ListFragment}, the default implementation returns a {@link android.widget.ListView} from
+{@link android.app.Fragment#onCreateView onCreateView()}, so you don't need to implement it.
+
+To return a layout from {@link
+android.app.Fragment#onCreateView onCreateView()}, you can inflate it from a layout resource defined in XML. To
+help you do so, {@link android.app.Fragment#onCreateView onCreateView()} provides a
+{@link android.view.LayoutInflater} object.
+
+For example, here's a subclass of {@link android.app.Fragment} that loads a layout from the
+{@code example_fragment.xml} file:
-public static class SimpleFragment extends Fragment {
+public static class ExampleFragment extends Fragment {
@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,
Bundle savedInstanceState) {
// Inflate the layout for this fragment
- return inflater.inflate(R.layout.simple_fragment, container, false);
+ return inflater.inflate(R.layout.example_fragment, container, false);
}
}
+
+
+
Creating a layout
+
In the sample above, {@code R.layout.example_fragment} is a reference to a layout resource
+named {@code example_fragment.xml} saved in the application resources. For information about how to
+create a layout in XML, see the User Interface
+documentation.
+
+
The {@code container} parameter passed to {@link android.app.Fragment#onCreateView
+onCreateView()} is the parent {@link android.view.ViewGroup} (from the activity's layout) in which
+your fragment layout
+will be inserted. The {@code savedInstanceState} parameter is a {@link android.os.Bundle} that
+provides data about the previous instance of the fragment, if the fragment is being resumed
+(restoring state is discussed more in the section about Handling the
+Fragment Lifecycle).
+
The {@link android.view.LayoutInflater#inflate(int,ViewGroup,boolean) inflate()} method takes
three arguments:
- - The resource ID of the layout you want to inflate
- - The {@link android.view.ViewGroup} to be the parent of the
-inflated layout (supplying this is important in order to apply layout parameters from the parent
-view)
- - And a boolean indicating whether the inflated layout should be attached to the {@link
-android.view.ViewGroup} (from the second parameter) during inflation (in this case, this
-is false because the system is already going to insert the layout into the appropriate parent
-view—doing otherwise would create a redundant view group in the final layout)
+ - The resource ID of the layout you want to inflate.
+ - The {@link android.view.ViewGroup} to be the parent of the inflated layout. Passing the {@code
+container} is important in order for the system to apply layout parameters to the root view of the
+inflated layout, specified by the parent view in which it's going.
+ - A boolean indicating whether the inflated layout should be attached to the {@link
+android.view.ViewGroup} (the second parameter) during inflation. (In this case, this
+is false because the system is already inserting the inflated layout into the {@code
+container}—passing true would create a redundant view group in the final layout.)
-The {@code container} parameter passed to {@link android.app.Fragment#onCreateView
-onCreateView()} provides the parent {@link android.view.ViewGroup} in which your fragment layout
-will be inserted, which you can use to generate layout parameters for your
-fragment layout. The {@code savedInstanceState} parameter is a {@link android.os.Bundle} that
-provides data about the previous instance of the fragment, if the fragment is being resumed
-(restoring state is discussed more in the section about Handling the
-Lifecycle.
+Now you've seen how to create a fragment that provides a layout. Next, you need to add
+the fragment to your activity.
-Adding a Fragment to an Activity
-Each fragment is embedded into the layout of its container activity as a part of the overall view
-hierarchy, whether or not it actually provides a UI. If a fragment is not embedded into the activity
-layout, then it is never created (it does not receive any lifecycle callbacks). There are two ways
-you can add a fragment to the activity layout:
+Adding a fragment to an activity
+
+Usually, a fragment contributes a portion of UI to the host activity, which is embedded as a part
+of the activity's overall view hierarchy. There are two ways you can add a fragment to the activity
+layout:
- - Declare the fragment inside the activity's layout XML file.
+
- Declare the fragment inside the activity's layout file.
In this case, you can
-specify layout properties for the fragment as if it were a view itself and the fragment's layout
-fills that space. For example:
+specify layout properties for the fragment as if it were a view. For example, here's the layout
+file for an activity with two fragments:
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
@@ -248,338 +287,286 @@ fills that space. For example:
android:layout_height="match_parent" />
</LinearLayout>
- The {@code <fragment>} element uses the {@code android:name} attribute to specify the
-{@link android.app.Fragment} class to instantiate and insert into the layout. When the activity
-layout is created, the system instantiates each fragment in the layout and calls its {@link
-android.app.Fragment#onCreateView onCreateView()} method in order to retrieve the fragment's
-layout. The {@link android.view.View} object returned by {@link
-android.app.Fragment#onCreateView onCreateView()} is then
-placed directly in the activity layout in place of the {@code <fragment>} element.
+ The {@code android:name} attribute in the {@code <fragment>} specifies the {@link
+android.app.Fragment} class to instantiate in the layout.
+
+When the system creates this activity layout, it instantiates each fragment specified in the
+layout and calls the {@link android.app.Fragment#onCreateView onCreateView()} method for each one,
+to retrieve each fragment's layout. The system inserts the {@link android.view.View} returned by the
+fragment directly in place of the {@code <fragment>} element.
Note: Each fragment requires a unique identifier that
the system can use to restore the fragment if the activity is restarted (and which you can use to
-perform fragment transactions). There are three ways to identify a fragment:
+capture the fragment to perform transactions, such as remove it). There are three ways to provide an
+ID for a fragment:
- - Supply the {@code android:id} attribute with a unique ID, in the {@code
-<fragment>}
- - Supply the {@code android:tag} attribute with a unique string ID, in the {@code
- <fragment>}
- - If neither of the previous two are provided, the system uses the ID of the container
- view.
+ - Supply the {@code android:id} attribute with a unique ID.
+ - Supply the {@code android:tag} attribute with a unique string.
+ - If you provide neither of the previous two, the system uses the ID of the container
+view.
- Or, programmatically add the fragment to an existing {@link android.view.ViewGroup}.
-
At any time while your activity is running (in the "resumed" state), you can add (and remove)
-fragments to your activity layout. You simply need to specify a {@link android.view.ViewGroup} in
-which to place the fragment.
- To make any fragment transactions in your activity (such as add, remove, or replace a
+
At any time while your activity is running, you can add fragments to your activity layout. You
+simply need to specify a {@link
+android.view.ViewGroup} in which to place the fragment.
+ To make fragment transactions in your activity (such as add, remove, or replace a
fragment), you must use APIs from {@link android.app.FragmentTransaction}. You can get an instance
-of {@link android.app.FragmentTransaction} from your {@link android.app.FragmentManager} using {@link
-android.app.FragmentManager#openTransaction()}. You can then add a fragment using the {@link
-android.app.FragmentTransaction#add add()} method, specifying the fragment to add and the view in
-which to insert it. For example:
+of {@link android.app.FragmentTransaction} from your {@link android.app.Activity} like this:
+
-MyFragment fragment = new MyFragment();
-getFragmentManager().openTransaction().add(R.id.fragment_container, fragment).commit();
+FragmentManager fragmentManager = {@link android.app.Activity#getFragmentManager()}
+FragmentTransaction fragmentTransaction = fragmentManager.{@link android.app.FragmentManager#openTransaction()};
- The first argument passed to {@link android.app.FragmentTransaction#add add()}
+
+
You can then add a fragment using the {@link
+android.app.FragmentTransaction#add(int,Fragment) add()} method, specifying the fragment to add and
+the view in which to insert it. For example:
+
+
+ExampleFragment fragment = new ExampleFragment();
+fragmentTransaction.add(R.id.fragment_container, fragment);
+fragmentTransaction.commit();
+
+
+ The first argument passed to {@link android.app.FragmentTransaction#add(int,Fragment) add()}
is the {@link android.view.ViewGroup} in which the fragment should be placed, specified by
-resource ID, and the second parameter is the fragment object.
- Once you've made your changes using
+resource ID, and the second parameter is the fragment to add.
+ Once you've made your changes with
{@link android.app.FragmentTransaction}, you must
-call {@link android.app.FragmentTransaction#commit} in order for the changes to take effect.
+call {@link android.app.FragmentTransaction#commit} for the changes to take effect.
-Example: simple fragments
+Adding a fragment without a UI
-In the last couple sections, you saw how to declare layout for a fragment and add it to an
-activity. What follows is some code that brings it all together, like a "Hello World" for
-fragments.
+The examples above show how to add a fragment to your activity in order to provide a UI. However,
+you can also use a fragment to provide a background behavior for the activity without presenting
+additional UI.
-First, here's a layout file for a fragment:
-
-<?xml version="1.0" encoding="utf-8"?>
-<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
- android:orientation="vertical"
- android:layout_width="match_parent"
- android:layout_height="match_parent" >
-<TextView
- android:layout_width="match_parent"
- android:layout_height="wrap_content"
- android:text="@string/hello" />
-<TextView
- android:layout_width="match_parent"
- android:layout_height="wrap_content"
- android:text="@string/hello" />
-</LinearLayout>
-
+To add a fragment without a UI, add the fragment from the activity using {@link
+android.app.FragmentTransaction#add(Fragment,String)} (supplying a unique string "tag" for the
+fragment, rather than a view ID). This adds the fragment, but, because it's not associated with a
+view in the activity layout, it does not receive a call to {@link
+android.app.Fragment#onCreateView onCreateView()}. So you don't need to implement that method.
-With that file saved at {@code res/layout/simple_fragment.xml}, the following {@link
-android.app.Fragment} uses it for its layout:
+Supplying a string tag for the fragment isn't strictly for non-UI fragments—you can also
+supply string tags to fragments that do have a UI—but if the fragment does not have a
+UI, then the string tag is the only way to identify it. If you want to get the fragment from the
+activity later, you need to use {@link android.app.FragmentManager#findFragmentByTag
+findFragmentByTag()}.
-
-public static class SimpleFragment extends Fragment {
- @Override
- public View onCreateView(LayoutInflater inflater, ViewGroup container,
- Bundle savedInstanceState) {
- // Inflate the layout for this fragment
- return inflater.inflate(R.layout.simple_fragment, null);
- }
-}
-
-
-And the following layout for an activity applies the fragment twice, side by side:
-
-
-<?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">
- <fragment android:name="com.example.SimpleFragment"
- android:id="@+id/list"
- android:layout_weight="1"
- android:layout_width="0dp"
- android:layout_height="match_parent" />
- <fragment android:name="com.example.SimpleFragment"
- android:id="@+id/viewer"
- android:layout_weight="1"
- android:layout_width="0dp"
- android:layout_height="match_parent" />
-</LinearLayout>
-
-
-That's it. When an activity applies the previous layout as its content, the {@code
-SimpleFragment} class is instantiated for each occurence in the layout, applying the fragment
-layout when it receives the call to {@link android.app.Fragment#onCreateView onCreateView()}.
-
-Although the fragment in this example implements only the {@link
-android.app.Fragment#onCreateView onCreateView()} callback, there are several other lifecycle
-callback methods that you should implement in your application. For example, {@link
-android.app.Fragment#onCreate onCreate()}, {@link android.app.Fragment#onPause onPause()}, {@link
-android.app.Fragment#onStop onStop()} and others that coincide with the fragment's lifecycle.
+For an example activity that uses a fragment as a background worker, without a UI, see the {@code
+FragmentRetainInstance.java} sample.
Managing Fragments
-A useful feature of fragments is the ability to add, remove, replace, and perform other
-operations on a fragment as the user interacts with the activity, alowing for more rich user
-experiences without changing activities. In order to perform these operations, you must use {@link
-android.app.FragmentTransaction} to perform fragment "transactions." You can acquire {@link
-android.app.FragmentTransaction} from your FragmentManager with {@link
-android.app.FragmentManager#openTransaction}.
+To manage the fragments in your activity, you need to use {@link android.app.FragmentManager}. To
+get it, call {@link android.app.Activity#getFragmentManager()} from your activity.
-Common transactions you can perform with fragments include:
+Some things that you can do with {@link android.app.FragmentManager} include:
-
- - {@link android.app.FragmentTransaction#add add()}
- - Add a {@link android.app.Fragment} to the {@link android.app.Activity} layout.
- - {@link android.app.FragmentTransaction#remove remove()}
- - Remove a {@link android.app.Fragment} from the {@link android.app.Activity} layout.
- - {@link android.app.FragmentTransaction#replace replace()}
- - Replace an existing {@link android.app.Fragment} with another one.
-
+
+ - Get fragments that exist in the activity, with {@link
+android.app.FragmentManager#findFragmentById findFragmentById()} (for fragments that provide a UI in
+the activity layout) or {@link android.app.FragmentManager#findFragmentByTag
+findFragmentByTag()} (for fragments that do or don't provide a UI).
+ - Pop fragments off the back stack, with {@link
+android.app.FragmentManager#popBackStack()} (simulating a BACK command by the user).
+ - Register a listener for changes to the back stack, with {@link
+android.app.FragmentManager#addOnBackStackChangedListener addOnBackStackChangedListener()}.
+
-For every transaction (or set of transactions) you perform, you must call {@link
-android.app.FragmentTransaction#commit} in order for the transactions made with {@link
-android.app.FragmentTransaction} to be applied. Before you do, however, you can call {@link
-android.app.FragmentTransaction#addToBackStack} to add the current fragment state to the
-activity's back stack, so that the user can return to the previous fragment state with the BACK key.
-For example, here's how a new fragment can replace another one, but keep the previous fragment
-in the back stack:
+For more information about these methods and others, refer to the {@link
+android.app.FragmentManager} class documentation.
+
+As demonstrated in the previous section, you can also use {@link android.app.FragmentManager}
+to open a {@link android.app.FragmentTransaction}, which allows you to perform transactions, such as
+add and remove fragments.
+
+
+Performing Fragment Transactions
+
+A great feature about using fragments in your activity is the ability to add, remove, replace,
+and perform other actions with them, in response to user interaction. Each set of changes that you
+commit to the activity is called a transaction and you can perform one using APIs in {@link
+android.app.FragmentTransaction}. You can also save each transaction to a back stack managed by the
+activity, allowing the user to navigate backward through the fragment changes (similar to navigating
+backward through activities).
+
+You can acquire an instance of {@link android.app.FragmentTransaction} from the {@link
+android.app.FragmentManager} like this:
-// Create new fragment
-Fragment newFragment = new MyFragment();
-FragmentTransaction ft = getFragmentManager().openTransaction();
-// Replace and add to back stack
-ft.replace(R.id.myfragment, newFragment);
-ft.addToBackStack(null);
-// Apply changes
-ft.commit();
+FragmentManager fragmentManager = {@link android.app.Activity#getFragmentManager()};
+FragmentTransaction fragmentTransaction = fragmentManager.{@link android.app.FragmentManager#openTransaction()};
-In this example, {@code newFragment} replaces whatever fragment is currently in the
-layout container identified by the {@code R.id.myfragment} ID. By calling {@link
-android.app.FragmentTransaction#addToBackStack addToBackStack()}, this transaction (the replace) is
-saved to the activity's back stack so that the user can reverse this change and bring back the
+
Each transaction is a set of changes that you want to perform at the same time. You can set
+up all the changes you want to perform for a given transaction using methods such as {@link
+android.app.FragmentTransaction#add add()}, {@link android.app.FragmentTransaction#remove remove()},
+and {@link android.app.FragmentTransaction#replace replace()}. Then, to apply the transaction
+to the activity, you must call {@link android.app.FragmentTransaction#commit()}.
+
+
+Before you call {@link
+android.app.FragmentTransaction#commit()}, however, you might want to call {@link
+android.app.FragmentTransaction#addToBackStack addToBackStack()}, in order to add the transaction
+to a back stack of fragment transactions. This back stack is managed by the activity and allows
+the user to return to the previous fragment state, by pressing the BACK key.
+
+For example, here's how you can replace one fragment with another, and preserve the previous
+state in the back stack:
+
+
+// Create new fragment and transaction
+Fragment newFragment = new ExampleFragment();
+FragmentTransaction transaction = getFragmentManager().openTransaction();
+
+// Replace whatever is in the fragment_container view with this fragment,
+// and add the transaction to the back stack
+transaction.replace(R.id.fragment_container, newFragment);
+transaction.addToBackStack(null);
+
+// Commit the transaction
+transaction.commit();
+
+
+In this example, {@code newFragment} replaces whatever fragment (if any) is currently in the
+layout container identified by the {@code R.id.fragment_container} ID. By calling {@link
+android.app.FragmentTransaction#addToBackStack addToBackStack()}, the replace transaction is
+saved to the back stack so the user can reverse the transaction and bring back the
previous fragment by pressing the BACK key.
-If you perform multiple transactions and call {@link
-android.app.FragmentTransaction#addToBackStack addToBackStack()}, then all transactions performed
-before {@link android.app.FragmentTransaction#commit} are added to the activity's back stack as a
-single event and the BACK key will reverse them all together.
+If you add multiple changes to the transaction (such as another {@link
+android.app.FragmentTransaction#add add()} or {@link android.app.FragmentTransaction#remove
+remove()}) and call {@link
+android.app.FragmentTransaction#addToBackStack addToBackStack()}, then all changes applied
+before you call {@link android.app.FragmentTransaction#commit commit()} are added to the
+back stack as a single transaction and the BACK key will reverse them all together.
-
-
-Handling the Lifecycle
-
-A fragment has a lifecycle that corresponds to the lifecycle of the activity in which it
-resides. For example, a fragment has callback methods {@link
-android.app.Fragment#onCreate onCreate()}, {@link android.app.Fragment#onStart onStart()}, {@link
-android.app.Fragment#onPause onPause()}, {@link android.app.Fragment#onStop onStop()}, and more.
-
-The lifecycle of the activity directly affects the lifecycle of the fragment, such that each
-lifecycle callback for the activity results in a similar callback for each fragment (for
-example, when the activity receives {@link android.app.Activity#onPause}, each fragment receives
-{@link android.app.Fragment#onPause}). However, the
-fragment's lifecycle can also change independently—but only while the activity is
-resumed (while it is in the foreground)—because you can dynamically
-add, remove, and replace fragments without any change to the lifecycle of the activity.
-
-To accomodate backward navigation with the
-BACK key, you can optionally maintain a back stack of fragment transactions, as described in the
-previous section. So, if you
-replace one fragment with another, the user can press the BACK key and view the previous
-fragment. Additionally, each fragment can maintain its own state, such that
-when the user navigates back to a previous fragment, the state of that fragment can be restored in
-the same manner as the state of an activity is restored when it is stopped and restarted.
-
-Managing the lifecycle of a fragment is a lot like managing the lifecycle of an activity. A
-fragment and an activity both have an "resumed," "paused," and "stopped" state, and they can both
-retain their state using a {@link android.os.Bundle}. The only significant difference is that an
-activity is placed into a the task's back stack by default (so that the user can navigate to
-the previous activity with the BACK key), but a fragment is placed into the activity's back stack
-only when you explicitly call {@link android.app.FragmentTransaction#addToBackStack(String)
-addToBackStack()} before you {@link android.app.FragmentTransaction#commit()} a fragment
-transaction.
-
-The order in which you perform transactions with {@link android.app.FragmentTransaction} doesn't
-matter, except:
+The order in which you add changes to a {@link android.app.FragmentTransaction} doesn't matter,
+except:
- You must call {@link android.app.FragmentTransaction#commit()} last
- If you're adding multiple fragments to the same container, then the order in which
-you add them determines the order they appear
+you add them determines the order they appear in the view hierarchy
+
If you do not call {@link android.app.FragmentTransaction#addToBackStack(String)
addToBackStack()} when you perform a transaction that removes a fragment, then that fragment is
-destroyed when the transaction is committed.
+destroyed when the transaction is committed and the user cannot navigate back to it. Whereas, if you
+do call {@link android.app.FragmentTransaction#addToBackStack(String) addToBackStack()} when
+removing a fragment, then the fragment is stopped and will be resumed if the user navigates
+back.
+
+Tip: For each fragment transaction, you can apply a transition
+animation, by calling {@link android.app.FragmentTransaction#setTransition setTransition()} before
+you commit.
+
+Calling {@link android.app.FragmentTransaction#commit()} does not perform the transaction
+immediately. Rather, it schedules it to run on the activity's UI thread (the "main" thread) as soon
+as the thread is able to do so. If necessary, however, you may call {@link
+android.app.FragmentManager#executePendingTransactions()} from your UI thread to immediately execute
+transactions submitted by {@link android.app.FragmentTransaction#commit()}. Doing so is
+usually not necessary unless the transaction is a dependency for jobs in other threads.
+
+Caution: You can commit a transaction using {@link
+android.app.FragmentTransaction#commit commit()} only prior to the activity saving its
+state (when the user leaves the activity). If you attempt to commit after that point, an
+exception will be thrown. This is because the state after the commit can be lost if the activity
+needs to be restored. For situations in which its okay that you lose the commit, use {@link
+android.app.FragmentTransaction#commitAllowingStateLoss()}.
-Coordinating with the activity lifecycle
-
-The lifecycle of an activity directly affects the lifecycle of a {@link android.app.Fragment}
-embedded in that activity. The {@link android.app.Fragment} class has lifecycle callback
-methods that match those in the {@link android.app.Activity} class.
-
-Fragments have a few extra lifecycle callbacks, however, that handle unique interaction with the
-activity in order to perform actions such as build and destroy the fragment's UI. These additional
-callback methods are:
-
-
- - {@link android.app.Fragment#onAttach onAttach()}
- - Called when the fragment has been associated with the activity (the {@link
-android.app.Activity} is passed in here).
- - {@link android.app.Fragment#onCreateView onCreateView()}
- - Called to create the view hierarchy associated with the fragment.
- - {@link android.app.Fragment#onActivityCreated onActivityCreated()}
- - Called when the activity's own {@link android.app.Activity#onCreate
-onCreate()} has finished.
- - {@link android.app.Fragment#onDestroyView onDestroyView()}
- - Called when the view hierarchy associated with the fragment is being removed.
- - {@link android.app.Fragment#onDetach onDetach()}
- - Called when the fragment is being disassociated from the activity.
-
-
-The flow of a fragment's lifecycle, as it is affected by its container activity, is illustrated
-by figure 3. In this figure, you can see how each successive state of the activity determines which
-callback methods the fragment may receive. For example, when the activity has received
-its {@link android.app.Activity#onCreate onCreate()} callback, the fragment receives no more
-than the {@link android.app.Fragment#onActivityCreated onActivityCreated()} callback. However,
-once the activity reaches the resumed state, you can freely add and remove fragments to the
-activity, so the fragment lifecycle is no longer inhibitted by the state of the activity. Yet,
-when the activity leaves the resumed state, the fragment again is pushed through its lifecycle by
-the activity (unless you explicitly destroy the fragment sooner).
-
-Figure 3. The activity lifecycle's affect on the lifecycle
-of a fragment.
+Communicating with the Activity
+Although a {@link android.app.Fragment} is implemented as an object that's independent from an
+{@link android.app.Activity} and can be used inside multiple activities, a given instance of
+a fragment is directly tied to the activity that contains it.
-Integrating with the Activity
-
-Although a {@link android.app.Fragment} is implemented separate from an {@link
-android.app.Activity} and can be used inside multiple activities, a fragment is directly tied to its
-container activity and can access the Activity instance with {@link
-android.app.Fragment#getActivity()}. So, a fragment can
-easily perform tasks such as find a view in the activity:
+Specifically, the fragment can access the {@link android.app.Activity} instance with {@link
+android.app.Fragment#getActivity()} and easily perform tasks such as find a view in the
+activity layout:
View listView = {@link android.app.Fragment#getActivity()}.{@link android.app.Activity#findViewById findViewById}(R.id.list);
-This makes it easy for your fragment to call public methods in the activity.
-
-Likewise, your activity can call public methods in the fragment when you have a reference to the
-{@link android.app.Fragment}. You can acquire a reference to the fragment with {@link
-android.app.FragmentManager#findFragmentById findFragmentById()} and cast it to your implementation of
-{@link android.app.Fragment}. For example:
+Likewise, your activity can call methods in the fragment by acquiring a reference to the
+{@link android.app.Fragment} from {@link android.app.FragmentManager}, using {@link
+android.app.FragmentManager#findFragmentById findFragmentById()} or {@link
+android.app.FragmentManager#findFragmentByTag findFragmentByTag()}. For example:
-MyFragment fragment = (MyFragment) findFragmentById(R.id.myfragment);
-fragment.refreshList();
+ExampleFragment fragment = (ExampleFragment) getFragmentManager().findFragmentById(R.id.example_fragment);
-Creating event callbacks to the activity
+Creating event callbacks to the activity
In some cases, you might need a fragment to share events with the activity. A good way to do that
is to define a callback interface inside the fragment and require that the host activity implement
-it. When the activity receives a callback, it can share the information with other fragments in the layout as
-necessary.
+it. When the activity receives a callback through the interface, it can share the information with
+other fragments in the layout as necessary.
For example, if a news application has two fragments in an activity—one to show a list of
articles (fragment A) and another to display an article (fragment B)—then fragment A must tell
the activity when a list item is selected so that it can tell fragment B to display the article. In
-this case, the following interface is defined inside fragment A:
+this case, the {@code OnArticleSelectedListener} interface is declared inside fragment A:
public static class FragmentA extends ListFragment {
...
// Container Activity must implement this interface
- public interface SelectedCallback {
+ public interface OnArticleSelectedListener {
public void onArticleSelected(Uri articleUri);
}
...
}
-Then the activity that hosts the fragment implements the {@code SelectedCallback} interface and
+
Then the activity that hosts the fragment implements the {@code OnArticleSelectedListener}
+interface and
overrides {@code onArticleSelected()} to notify fragment B of the event from fragment A. To ensure
that the host activity implements this interface, fragment A's {@link
-android.app.Fragment#onAttach onAttach()} callback method (called when
-the fragment is added to the activity) instantiates an instance of {@code SelectedCallback} by
+android.app.Fragment#onAttach onAttach()} callback method (which the system calls when adding
+the fragment to the activity) instantiates an instance of {@code OnArticleSelectedListener} by
casting the {@link android.app.Activity} that is passed into {@link android.app.Fragment#onAttach
onAttach()}:
public static class FragmentA extends ListFragment {
+ OnArticleSelectedListener mListener;
...
@Override
public void onAttach(Activity activity) {
super.onAttach(activity);
try {
- mCallback = (SelectedCallback) activity;
+ mListener = (OnArticleSelectedListener) activity;
} catch (ClassCastException e) {
- activity.finish();
- throw new ClassCastException(activity.toString() + " must implement SelectedCallback");
+ throw new ClassCastException(activity.toString() + " must implement OnArticleSelectedListener");
}
}
...
}
-If the activity has not implemented the interface, then a {@link java.lang.ClassCastException} is
-thrown and the activity is shut down. On success, the {@code mCallback} member holds a reference to
-the {@link android.app.Activity}, so that fragment A can share events with the activity by calling
-methods defined by the {@code SelectedCallback} interface. For example, if fragment A is an
+
If the activity has not implemented the interface, then the fragment throws a
+{@link java.lang.ClassCastException}.
+On success, the {@code mListener} member holds a reference to activity's implementation of
+{@code OnArticleSelectedListener}, so that fragment A can share events with the activity by calling
+methods defined by the {@code OnArticleSelectedListener} interface. For example, if fragment A is an
extension of {@link android.app.ListFragment}, each time
the user clicks a list item, the system calls {@link android.app.ListFragment#onListItemClick
onListItemClick()} in the fragment, which then calls {@code onArticleSelected()} to share
@@ -587,13 +574,14 @@ the event with the activity:
public static class FragmentA extends ListFragment {
+ OnArticleSelectedListener mListener;
...
@Override
public void onListItemClick(ListView l, View v, int position, long id) {
// Append the clicked item's row ID with the content provider Uri
Uri noteUri = ContentUris.{@link android.content.ContentUris#withAppendedId withAppendedId}(ArticleColumns.CONTENT_URI, id);
// Send the event and Uri to the host activity
- mCallback.onArticleSelected(noteUri);
+ mListener.onArticleSelected(noteUri);
}
...
}
@@ -611,38 +599,217 @@ href="{@docRoot}guide/topics/providers/content-providers.html">Content Providers
+Adding items to the Action Bar
-
-
-
-
-Your fragments can contribute action items to the activity's action bar (and menu items to the options menu)
-using the callback methods
+
Your fragments can contribute menu items to the activity's Options Menu (and, consequently, the Action Bar) by implementing
{@link android.app.Fragment#onCreateOptionsMenu(Menu,MenuInflater) onCreateOptionsMenu()}. In order
for this method to receive calls, however, you must call {@link
-android.app.Fragment#setHasOptionsMenu(boolean) setHasOptionsMenu()} during the {@link
-android.app.Fragment#onCreate(Bundle) onCreate()} callback in order to indicate that the fragment
-would like to receive a call to {@link android.app.Fragment#onCreateOptionsMenu(Menu,MenuInflater)
-onCreateOptionsMenu()}. Any action or menu items that you add from the fragment are appended to the
-existing
-items for the options menu (including those added by other fragments in the activity). The
-fragment also receives item-selected events with the {@link
-android.app.Fragment#onOptionsItemSelected(MenuItem) onOptionsItemSelected()} callback method.
+android.app.Fragment#setHasOptionsMenu(boolean) setHasOptionsMenu()} during {@link
+android.app.Fragment#onCreate(Bundle) onCreate()}, to indicate that the fragment
+would like to add items to the Options Menu (otherwise, the fragment will not receive a call to
+{@link android.app.Fragment#onCreateOptionsMenu onCreateOptionsMenu()}).
-The {@link android.app.Fragment} class also contains methods to handle context menus. You can
-register a view to provide a context menu with {@link
+
Any items that you then add to the Options Menu from the fragment are appended to the existing
+menu items. The fragment also receives callbacks to {@link
+android.app.Fragment#onOptionsItemSelected(MenuItem) onOptionsItemSelected()} when a menu item
+is selected.
+
+You can also register a view in your fragment layout to provide a context menu by calling {@link
android.app.Fragment#registerForContextMenu(View) registerForContextMenu()}. When the user opens
the context menu, the fragment receives a call to {@link
android.app.Fragment#onCreateContextMenu(ContextMenu,View,ContextMenu.ContextMenuInfo)
onCreateContextMenu()}. When the user selects an item, the fragment receives a call to {@link
android.app.Fragment#onContextItemSelected(MenuItem) onContextItemSelected()}.
-For more information, see Creating
+Note: Although your fragment receives an on-item-selected callback
+for each menu item it adds, the activity is first to receive the respective callback when the user
+selects a menu item. If the activity's implementation of the on-item-selected callback does not
+handle the selected item, then the event is passed to the fragment's callback. This is true for
+the Options Menu and context menus.
+
+For more information about menus, see Creating
Menus and Using the Action Bar.
+Handling the Fragment Lifecycle
+
+
+
+Managing the lifecycle of a fragment is a lot like managing the lifecycle of an activity. Like
+an activity, a fragment can exist in three states:
+
+
+ - Resumed
+ - The fragment is visible in the running activity.
+
+ - Paused
+ - Another activity is in the foreground and has focus, but the activity in which this
+fragment lives is still visible (the foreground activity is partially transparent or doesn't
+cover the entire screen).
+
+ - Stopped
+ - The fragment is not visible. Either the host activity has been stopped or the
+fragment has been removed from the activity but added to the back stack. A stopped fragment is
+still alive (all state and member information is retained by the system). However, it is no longer
+visible to the user and will be killed if the activity is killed.
+
+
+Also like an activity, you can retain the state of a fragment using a {@link
+android.os.Bundle}, in case the activity's process is killed and you need to restore the
+fragment state when the activity is recreated. You can save the state during the fragment's {@link
+android.app.Fragment#onSaveInstanceState onSaveInstanceState()} callback and restore it during
+either {@link android.app.Fragment#onCreate onCreate()}, {@link
+android.app.Fragment#onCreateView onCreateView()}, or {@link
+android.app.Fragment#onActivityCreated onActivityCreated()}. For more information about saving
+state, see the Activities
+document.
+
+The most significant difference in lifecycle between an activity and a fragment is how one is
+stored in its respective back stack. An activity is placed into a back stack of activities
+that's managed by the system when it's stopped, by default (so that the user can navigate back
+to it with the BACK key, as discussed in Tasks and Back Stack).
+However, a fragment is placed into a back stack managed by the host activity only when you
+explicitly request that the instance be saved by calling {@link
+android.app.FragmentTransaction#addToBackStack(String) addToBackStack()} during a transaction that
+removes the fragment.
+
+Otherwise, managing the fragment lifecycle is very similar to managing the activity
+lifecycle. So, the same practices for managing the activity
+lifecycle also apply to fragments. What you also need to understand, though, is how the life
+of the activity affects the life of the fragment.
+
+
+Coordinating with the activity lifecycle
+
+The lifecycle of the activity in which the fragment lives directly affects the lifecycle of the
+fragment, such that each lifecycle callback for the activity results in a similar callback for each
+fragment. For example, when the activity receives {@link android.app.Activity#onPause}, each
+fragment in the activity receives {@link android.app.Fragment#onPause}.
+
+Fragments have a few extra lifecycle callbacks, however, that handle unique interaction with the
+activity in order to perform actions such as build and destroy the fragment's UI. These additional
+callback methods are:
+
+
+ - {@link android.app.Fragment#onAttach onAttach()}
+ - Called when the fragment has been associated with the activity (the {@link
+android.app.Activity} is passed in here).
+ - {@link android.app.Fragment#onCreateView onCreateView()}
+ - Called to create the view hierarchy associated with the fragment.
+ - {@link android.app.Fragment#onActivityCreated onActivityCreated()}
+ - Called when the activity's {@link android.app.Activity#onCreate
+onCreate()} method has returned.
+ - {@link android.app.Fragment#onDestroyView onDestroyView()}
+ - Called when the view hierarchy associated with the fragment is being removed.
+ - {@link android.app.Fragment#onDetach onDetach()}
+ - Called when the fragment is being disassociated from the activity.
+
+
+The flow of a fragment's lifecycle, as it is affected by its host activity, is illustrated
+by figure 3. In this figure, you can see how each successive state of the activity determines which
+callback methods a fragment may receive. For example, when the activity has received its {@link
+android.app.Activity#onCreate onCreate()} callback, a fragment in the activity receives no more than
+the {@link android.app.Fragment#onActivityCreated onActivityCreated()} callback.
+
+Once the activity reaches the resumed state, you can freely add and remove fragments to the
+activity. Thus, only while the activity is in the resumed state can the lifecycle of a fragment
+change independently.
+
+However, when the activity leaves the resumed state, the fragment again is pushed through its
+lifecycle by the activity.
+
+
+
+
+Example
+
+To bring everything discussed in this document together, here's an example of an activity
+using two fragments to create a two-pane layout. The activity below includes one fragment to
+show a list of Shakespeare play titles and another to show a summary of the play when selected
+from the list. It also demonstrates how to provide different configurations of the fragments,
+based on the screen configuration.
+
+Note: The complete source code for this activity is available in
+{@code
+FragmentLayout.java}.
+
+The main activity applies a layout in the usual way, during {@link
+android.app.Activity#onCreate onCreate()}:
+
+{@sample development/samples/ApiDemos/src/com/example/android/apis/app/FragmentLayout.java main}
+
+The layout applied is {@code fragment_layout.xml}:
+
+{@sample development/samples/ApiDemos/res/layout-land/fragment_layout.xml layout}
+
+Using this layout, the system instantiates the {@code TitlesFragment} (which lists the play
+titles) as soon as the activity loads the layout, while the {@link android.widget.FrameLayout}
+(where the fragment for showing the play summary will go) consumes space on the right side of the
+screen, but remains empty at first. As you'll see below, it's not until the user selects an item
+from the list that a fragment is placed into the {@link android.widget.FrameLayout}.
+
+However, not all screen configurations are wide enough to show both the list of
+plays and the summary, side by side. So, the layout above is used only for the landscape
+screen configuration, by saving it at {@code res/layout-land/fragment_layout.xml}.
+
+Thus, when the screen is in portrait orientation, the system applies the following layout, which
+is saved at {@code res/layout/fragment_layout.xml}:
+
+{@sample development/samples/ApiDemos/res/layout/fragment_layout.xml layout}
+
+This layout includes only {@code TitlesFragment}. This means that, when the device is in
+portrait orientation, only the list of play titles is visible. So, when the user clicks a list
+item in this configuration, the application will start a new activity to show the summary,
+instead of loading a second fragment.
+
+Next, you can see how this is accomplished in the fragment classes. First is {@code
+TitlesFragment}, which shows the list of Shakespeare play titles. This fragment extends {@link
+android.app.ListFragment} and relies on it to handle most of the list view work.
+
+As you inspect this code, notice that there are two possible behaviors when the user clicks a
+list item: depending on which of the two layouts is active, it can either create and display a new
+fragment to show the details in the same activity (adding the fragment to the {@link
+android.widget.FrameLayout}), or start a new activity (where the fragment can be shown).
+
+{@sample development/samples/ApiDemos/src/com/example/android/apis/app/FragmentLayout.java titles}
+
+The second fragment, {@code DetailsFragment} shows the play summary for the item selected from
+the list from {@code TitlesFragment}:
+
+{@sample development/samples/ApiDemos/src/com/example/android/apis/app/FragmentLayout.java details}
+
+Recall from the {@code TitlesFragment} class, that, if the user clicks a list item and the
+current layout does not include the {@code R.id.details} view (which is where the
+{@code DetailsFragment} belongs), then the application starts the {@code DetailsActivity}
+activity to display the content of the item.
+
+Here is the {@code DetailsActivity}, which simply embeds the {@code DetailsFragment} to display
+the selected play summary when the screen is in portrait orientation:
+
+{@sample development/samples/ApiDemos/src/com/example/android/apis/app/FragmentLayout.java
+details_activity}
+
+Notice that this activity finishes itself if the configuration is landscape, so that the main
+activity can take over and display the {@code DetailsFragment} alongside the {@code TitlesFragment}.
+This can happen if the user begins the {@code DetailsActivity} while in portrait orientation, but
+then rotates to landscape (which restarts the current activity).
+
+
+For more samples using fragments (and complete source files for this example),
+see the sample code available in
+ApiDemos (available for download from the Samples SDK component).
diff --git a/docs/html/images/fundamentals/fragments.png b/docs/html/images/fundamentals/fragments.png
new file mode 100644
index 0000000000000..b3b7b23073e7a
Binary files /dev/null and b/docs/html/images/fundamentals/fragments.png differ
-