Best practice for nested fragments in Android 4.0, 4.1 (<4.2) without using the support library

I'm writing an app for 4.0 and 4.1 tablets, for which I do not want to use the support libraries (if not needed) but the 4.x api only therefore.

So my target platform is very well defined as: >= 4.0 and <= 4.1

The app has a multi-pane layout (two fragments, one small on the left, one content fragment on the right) and an action bar with tabs.

Similar to this:

Clicking a tab on the action bar changes the 'outer' fragment, and the inner fragment then is a fragment with two nested fragments (1. small left list fragment, 2. wide content fragment).

I am now wondering what's the best practice to replace fragments and especially nested fragments. The ViewPager is part of the support library, there's no native 4.x alternative for this class. Appear to be 'deprecated' in my sense.

• http://developer.android.com/reference/android/support/v4/view/ViewPager.html

Then I read the release notes for Android 4.2, regarding ChildFragmentManager, which would be a good fit, but I am targeting 4.0 and 4.1, so this can't be used either.

ChildFragmentManager is only available in 4.2

• http://developer.android.com/about/versions/android-4.2.html#NestedFragments
• http://developer.android.com/reference/android/app/Fragment.html#getChildFragmentManager()

Unfortunately, there are hardly any good examples out there that show best practices for fragments usages without the support library, even in the entire Android developer guides; and especially nothing regarding nested fragments.

So I am wondering: is it simply not possible to write 4.1 apps with nested fragments without using the support library and everything that comes with it? (need to use FragmentActivity instead of Fragment, etc.?) Or what would be the best practice?

---

The problem that I am currently having in the development is exactly this statement:

• http://developer.android.com/about/versions/android-4.2.html#NestedFragments

> The Android Support Library also now supports nested fragments, so you > can implement nested fragment designs on Android 1.6 and higher. > > Note: You cannot inflate a layout into a fragment when that layout > includes a <fragment>. Nested fragments are only supported when added > to a fragment dynamically.

Because I put define the nested fragments in XML, which apparently causes an error like:

Caused by: java.lang.IllegalArgumentException: Binary XML file line #15: Duplicate id 0x7f090009, tag frgCustomerList, or parent id 0x7f090008 with another fragment for de.xyz.is.android.fragment.CustomerListFragment_

At the moment, I conclude for myself: even on 4.1, when I don't even want to target the 2.x platform, nested fragments as shown in the screenshot are not possible without the support library.

(This might actually be more of a wiki entry than a question, but maybe somebody else has managed it before).

Update:

A helpful answer is at: https://stackoverflow.com/questions/6672066/fragment-inside-fragment/6672688#6672688

Limitations

So nesting fragments inside another fragment is not possible with xml regardless of which version of FragmentManager you use.

So you have to add fragments via code, this might seem like a problem, but in the long run makes your layouts superflexible.

So nesting without using getChildFragmentManger? The essence behind childFragmentManager is that it defers loading until the previous fragment transaction has finished. And of course it was only naturally supported in 4.2 or the support library.

Nesting without ChildManager - Solution

Solution, Sure! I have been doing this for a long time now, (since the ViewPager was announced).

See below; This is a Fragment that defers loading, so Fragments can be loaded inside of it.

Its pretty simple, the Handler is a really really handy class, effectively the handler waits for a space to execute on the main thread after the current fragment transaction has finished committing (as fragments interfere with the UI they run on the main thread).

// Remember this is an example, you will need to modify to work with your code
private final Handler handler = new Handler();
private Runnable runPager;

@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState)
    return inflater.inflate(R.layout.frag_layout, container, false);
}

@Override
public void onActivityCreated(Bundle savedInstanceState)
{
    super.onActivityCreated(savedInstanceState);
    runPager = new Runnable() {

        @Override
        public void run()
        {
          getFragmentManager().beginTransaction().addFragment(R.id.frag_container, MyFragment.newInstance()).commit();
        }
    };
    handler.post(runPager);
}

/**
 * @see android.support.v4.app.Fragment#onPause()
 */
@Override
public void onPause()
{
    super.onPause();
    handler.removeCallbacks(runPager);
}

I wouldn't consider it 'best practice', but I have live apps using this hack and I am yet to have any issues with it.

I also use this method for embedding view pagers - https://gist.github.com/chrisjenx/3405429

The best way to do this in pre-API 17 is to not do it at all. Trying to implement this behavior is going to cause issues. However that is not to say that it cannot be faked convincingly using the current API 14. What I did was the following:

1 - look at communication between fragments http://developer.android.com/training/basics/fragments/communicating.html

2 - move your layout xml FrameLayout from your existing Fragment to the Activity layout and hide it by giving a height of 0:

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
		  xmlns:tools="http://schemas.android.com/tools"
		  android:layout_width="fill_parent"
		  android:layout_height="fill_parent">
<FrameLayout android:id="@+id/content"
		  android:layout_width="300dp"
		  android:layout_height="match_parent" />


<FrameLayout android:id="@+id/lstResults"
			 android:layout_width="300dp"
			 android:layout_height="0dp"
			 android:layout_below="@+id/content"
			 tools:layout="@layout/treeview_list_content"/>


<FrameLayout android:id="@+id/anomalies_fragment"
			 android:layout_width="match_parent"
			 android:layout_height="match_parent"
		android:layout_toRightOf="@+id/content" />

3 - Implement the interface in the parent Fragment

	OnListener mCallback;

// Container Activity must implement this interface
public interface OnListener 
{
	public void onDoSomethingToInitChildFrame(/*parameters*/);
	public void showResults();
	public void hideResults();
}

@Override
public void onAttach(Activity activity) {
	super.onAttach(activity);

	// This makes sure that the container activity has implemented
	// the callback interface. If not, it throws an exception
	try {
		mCallback = (OnFilterAppliedListener) activity;
	} catch (ClassCastException e) {
		throw new ClassCastException(activity.toString()
				+ " must implement OnListener");
	}
}

@Override
public void onActivityCreated(Bundle savedInstanceState) 
{
    super.onActivityCreated(savedInstanceState);

	mCallback.showResults();
}

@Override
public void onPause()
{
	super.onPause();

	mCallback.hideResults();
}

public void onClickButton(View view)
{
    // do click action here
    
	mCallback.onDoSomethingToInitChildFrame(/*parameters*/);
}

4 - Implement the interface in the parent Activity

public class YourActivity extends Activity implements yourParentFragment.OnListener {

public void onDoSomethingToInitChildFrame(/*parameters*/)
{
	FragmentTransaction ft = getFragmentManager().beginTransaction();
	Fragment childFragment = getFragmentManager().findFragmentByTag("Results");
	if(childFragment == null)
	{
		childFragment = new yourChildFragment(/*parameters*/);
		ft.add(R.id.lstResults, childFragment, "Results");
	}
	else
	{
		ft.detach(childFragment);

		((yourChildFragment)childFragment).ResetContent(/*parameters*/);

		ft.attach(childFragment);
	}
	ft.commit();

	showResultsPane();
}

public void showResults()
{
	FragmentTransaction ft = getFragmentManager().beginTransaction();
	Fragment childFragment = getFragmentManager().findFragmentByTag("Results");
	if(childFragment != null)
		ft.attach(childFragment);
	ft.commit();

	showResultsPane();
}

public void showResultsPane()
{
	//resize the elements to show the results pane
	findViewById(R.id.content).getLayoutParams().height = ViewGroup.LayoutParams.WRAP_CONTENT;
	findViewById(R.id.lstResults).getLayoutParams().height = ViewGroup.LayoutParams.WRAP_CONTENT;
}

public void hideResults()
{
	//resize the elements to hide the results pane
	findViewById(R.id.content).getLayoutParams().height = ViewGroup.LayoutParams.MATCH_PARENT;
	findViewById(R.id.lstResults).getLayoutParams().height = 0;

	FragmentTransaction ft = getFragmentManager().beginTransaction();
	Fragment childFragment = getFragmentManager().findFragmentByTag("Results");
	if(childFragment != null)
		ft.detach(childFragment);
	ft.commit();
}

}

5 - Enjoy, with this method you get the same fluid functionality as with the getChildFragmentManager() function in a pre-API 17 envoronment. As you may have noticed the child fragment is no longer really a child of the parent fragment but now a child of the activity, this really cannot be avoided.

I had to deal with this exact issue due to a combination of NavigationDrawer, TabHost, and ViewPager which had complications with usage of the support library because of TabHost. And then I also had to support min API of JellyBean 4.1, so using nested fragments with getChildFragmentManager was not an option.

So my problem can be distilled to...

TabHost (for top level)


ViewPager (for just one of the top level tabbed fragments)
= need for Nested Fragments (which JellyBean 4.1 won't support)

My solution was to create the illusion of nested fragments without actually nesting fragments. I did this by having the main activity use TabHost AND ViewPager to manage two sibling Views whose visibility is managed by toggling layout_weight between 0 and 1.

//Hide the fragment used by TabHost by setting height and weight to 0
LinearLayout.LayoutParams lp = new LinearLayout.LayoutParams(LinearLayout.LayoutParams.MATCH_PARENT, 0, 0);
mTabHostedView.setLayoutParams(lp);
//Show the fragment used by ViewPager by setting height to 0 but weight to 1
lp = new LinearLayout.LayoutParams(LinearLayout.LayoutParams.MATCH_PARENT, 0, 1);
mPagedView.setLayoutParams(lp);

This effectively allowed my fake "Nested Fragment" to operate as an independent view as long as I manually managed the relevant layout weights.

Here's my activity_main.xml:

<android.support.v4.widget.DrawerLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:id="@+id/drawer_layout"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context="com.ringofblades.stackoverflow.app.MainActivity">

    <TabHost
        android:id="@android:id/tabhost"
        android:layout_width="match_parent"
        android:layout_height="match_parent">
        <LinearLayout android:orientation="vertical"
            android:layout_width="match_parent"
            android:layout_height="match_parent">
            <FrameLayout android:id="@android:id/tabcontent"
                android:background="@drawable/background_image"
                android:layout_width="match_parent"
                android:layout_weight="0.5"
                android:layout_height="0dp"/>
            <android.support.v4.view.ViewPager
                xmlns:tools="http://schemas.android.com/tools"
                android:id="@+id/pager"
                android:background="@drawable/background_image"
                android:layout_width="match_parent"
                android:layout_weight="0.5"
                android:layout_height="0dp"
                tools:context="com.ringofblades.stackoverflow.app.MainActivity">
                <FrameLayout
                    android:id="@+id/container"
                    android:layout_width="match_parent"
                    android:layout_height="match_parent" />
            </android.support.v4.view.ViewPager>
            <TabWidget android:id="@android:id/tabs"
                android:layout_width="match_parent"
                android:layout_height="wrap_content" />
        </LinearLayout>
    </TabHost>

    <fragment android:id="@+id/navigation_drawer"
        android:layout_width="@dimen/navigation_drawer_width"
        android:layout_height="match_parent"
        android:layout_gravity="start"
        android:name="com.ringofblades.stackoverflow.app.NavigationDrawerFragment"
        tools:layout="@layout/fragment_navigation_drawer" />
</android.support.v4.widget.DrawerLayout>

Note that "@+id/pager" and "@+id/container" are siblings with 'android:layout_weight="0.5"' and 'android:layout_height="0dp"'. This is so that I can see it in the previewer for any screen size. Their weights will be manipulated in code during runtime, anyway.

Building on @Chris.Jenkins answer, this is the solution that has been working well for me, for removing fragment(s) during life cycle events (which have a tendency to throw IllegalStateExceptions). This uses a combination of the Handler approach, and an Activity.isFinishing() check (otherwise it will throw an error for "Can not perform this action after onSaveInstanceState).

import android.app.Activity;
import android.os.Handler;
import android.support.annotation.Nullable;
import android.support.v4.app.Fragment;
import android.support.v4.app.FragmentManager;
import android.support.v4.app.FragmentTransaction;

public abstract class BaseFragment extends Fragment {
    private final Handler handler = new Handler();

    /**
     * Removes the {@link Fragment} using {@link #getFragmentManager()}, wrapped in a {@link Handler} to
     * compensate for illegal states.
     *
     * @param fragment The {@link Fragment} to schedule for removal.
     */
    protected void removeFragment(@Nullable final Fragment fragment) {
        if (fragment == null) return;

        final Activity activity = getActivity();
        handler.post(new Runnable() {
            @Override
            public void run() {
                if (activity != null && !activity.isFinishing()) {
                    getFragmentManager().beginTransaction()
                            .remove(fragment)
                            .commitAllowingStateLoss();
                }
            }
        });
    }

    /**
     * Removes each {@link Fragment} using {@link #getFragmentManager()}, wrapped in a {@link Handler} to
     * compensate for illegal states.
     *
     * @param fragments The {@link Fragment}s to schedule for removal.
     */
    protected void removeFragments(final Fragment... fragments) {
        final FragmentManager fragmentManager = getFragmentManager();
        final FragmentTransaction fragmentTransaction = fragmentManager.beginTransaction();

        for (Fragment fragment : fragments) {
            if (fragment != null) {
                fragmentTransaction.remove(fragment);
            }
        }

        final Activity activity = getActivity();
        handler.post(new Runnable() {
            @Override
            public void run() {
                if (activity != null && !activity.isFinishing()) {
                    fragmentTransaction.commitAllowingStateLoss();
                }
            }
        });
    }
}

Usage:

class MyFragment extends Fragment {
	@Override
	public void onDestroyView() {
		removeFragments(mFragment1, mFragment2, mFragment3);
		super.onDestroyView();
	}
}

Although the OP may have special circumstances that prevent him from using the Support Library, most people should use it. The Android documentation recommends it, and it will make your app available to the widest audience possible.

In my fuller answer here I made an example demonstrating how to use nested fragments with the support library.