Android: Fragment related pitfalls and how to avoid them

Don’t use platform fragments ( android.app.Fragment), they have been deprecated and can trigger version-specific bugs. Use the support library fragments ( android.support.v4.app.Fragment) instead.
A Fragment is created explicitly via your code or recreated implicitly by the FragmentManager. The FragmentManager can only recreate a Fragment if it’s a public non-anonymous class. To test for this, rotate your screen while the Fragment is visible.
FragmentTransaction#commit can fail if the activity has been destroyed. “java.lang.IllegalStateException: Activity has been destroyed” Why - This can happen in the wild where say right before FragmentTransaction#commit() executes, the user gets a phone call and your activity is backgrounded and destroyed. How to trigger manually - The easy way to manually test this is to add a call to Activity#finish() right before FragmentTransaction#commit. Fix - Before doing FragmentTransaction#commit(), check that the activity has not been destroyed - Activity#isDestroyed() should return false.
FragmentTransaction#commit can fail if onSaveInstanceState has been called. “java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState” Why - This can happen in the wild where say right before FragmentTransaction#commit() executes, the user gets a phone call and your activity is backgrounded and paused. How to trigger manually - The easiest way to manually trigger this behavior is to call Activity#onSaveInstanceState in your uncommitted code right before the call to FragmentTransaction#commit Fix 1 - call FragmentTransaction#commitAllowingStateLoss but that implies that your fragment would be in a different state then the user expects it to be. Fix 2 - The better way is to ensure that the code path L which leads to FragmentTransaction#commit is not invoked once Activity’s onSaveInstanceState has been called but that’s not always easy to do.
FragmentManager is null after Activity is destroyed. “java.lang.NullPointerException: … at getSupportFragmentManager().beginTransaction()” Why - This can happen when the activity has been destroyed before getSupportFragmentManager() is invoked. The common cause of this is when a new fragment has to be added in response to a user action and the user immediately backgrounds the app, again, say due to a phone call, after clicking the button before getSupportFragmentManager() is invoked. Another common case is where an AsyncTask which will call getSupportFragmentManager() in onPostExecute and while the task is engaged in the background processing (doInBackground), the activity is destroyed. How to trigger manually - call `Activity#finish()` before `getSupportFragmentManager().beginTransaction()` Fix- If getSupportFragmentManager() is being invoked in the Activity, check if it’s null. If it is being invoked inside a Fragment check if isAdded() of the Fragment returns true before calling this.
Avoid UI modifications that are not related to a FragmentTransaction with FragmentTransaction committed using commitAllowStateLoss Why - Any UI modifications like modifications of the text in a TextView are synchronous while the execution of a FragmentTransaction via `FragmentTransaction#commitAllowStateLoss()` is asynchronous. If the activity’s onSaveInstanceState is invoked after the UI changes have been made but before commitAllowStateLoss is called then the user can end up seeing a UI state which you never expected them to see. Fix - use commitNow() or hook into FragmentManager.FragmentLifecycleCallbacks#onFragmentAttached(). I will admit this I haven’t found a simpler fix for this. And this issue is definitely an edge case.

Saving Fragment State As mentioned earlier, a Fragment is re-created on activity recreation by FragmentManager which will invoke its default no-parameter constructor. If you have no such constructor then on Fragment recreation, the app will crash with “java.lang.InstantiationException: MyFragment has no zero-argument constructor”. If you try to fix this by adding a no-argument constructor then the app will not crash but on activity recreation say due to screen rotation, the Fragment will lose its state. The right way to serialize a Fragment’s state is to pass arguments in a Bundle via setArguments.

Java

1
2
3
MyFragment myFragment = new MyFragment();
myFragment.setArguments(mBundle);
return myFragment;

The Fragment code should then use the getArguments() method to fetch the arguments. In fact, I would recommend a Builder pattern to hide all this complexity.

Consider this complete example,

Java

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
public class MyFragment {

    private static final String KEY_NAME = "name";

    public static class MyFragment.Builder {
       private final Bundle mBundle = new Bundle();

       public Builder setName(String username) {
           mBundle.putInt(KEY_NAME, clickCount);
           return this;
       }

       public MyFragment build() {
          MyFragment myFragment = new MyFragment();
          // Set the username
          myFragment.setArguments(mBundle);
          return myFragment;
       }
    }

    public MyFragment() {
      // Get the user name
      @Nullable String username = getArguments() != null ? getArguments().getString(KEY_NAME, null) : null;
    }
  }

  if (!isDestroyed()) {
     // Create the Fragment
    MyFragment myFragment = new MyFragment().Builder().setName(username).build();
    // Add the Fragment
    FragmentTransaction ft = getSupportFragmentManager().beingTransaction();
    ft.add(myFragment);
    ft.commitNowAllowingStateLoss();
  }

Inside your Fragment code, if you want to decide whether it is safe to execute a UI code or not, rely on isAdded(), if it returns true, it is safe to perform UI modifications, if it returns false, then your Fragment has been detached from the activity either because it has been removed or because the host (Fragment/Activity) is being destroyed.
Callbacks To callback into the parent activity/fragment in case of action inside your Fragment, say, a user clicks, provide an interface (say, MyFragmentListener) which the holding activity/Fragment should implement. In Fragment#onCreateView() get the host via getHost(), cast it to MyFragmentListener, and store it in the instance variable of your Fragment class. Set that instance variable to null in Fragment#onDestroyView(). Now, you can invoke callbacks on this MyFragmentListener instance variable.

Backstack Backstack is nuanced and my grasp of it is still limited. What I do understand is that if you want your Fragment to react to the back key press then you should call FragmentTransaction#addToBackStack(backStackStateName) while adding the Fragment via FragmentTransaction and remove it while removing it. Removal from the back stack is a bit more nuanced. Note that, manual removal of a fragment from the back stack is not required in Activity#onBackPressed() as long as your Activity inherits from FragmentActivity.

Java

1
2
3
4
5
6
SupportFragmentManager manager = getSupportFragmentManager();
  FragmentManager.BackStackEntry entry = manager.getBackStackEntryAt(manager.getBackStackEntryCount() - 1);
  if (backStackStateName.equals(entry.getName())) {
     manager.popBackStack(backStackStateName, FragmentManager.POP_BACK_STACK_INCLUSIVE);
  }
}

Related Posts