FragmentTransaction

Static library support version of the framework's android.app.FragmentTransaction. Used to write apps that run on platforms prior to Android 3.0. When running on Android 3.0 or above, this implementation is still used; it does not try to switch to the framework's implementation. See the framework SDK documentation for a class overview.

commit

Schedules a commit of this transaction. The commit does not happen immediately; it will be scheduled as work on the main thread to be done the next time that thread is ready.

A transaction can only be committed with this method prior to its containing activity saving its state. If the commit is attempted 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 from its state. See commitAllowingStateLoss() for situations where it may be okay to lose the commit.

commitAllowingStateLoss

Like commit but allows the commit to be executed after an activity's state is saved. This is dangerous because the commit can be lost if the activity needs to later be restored from its state, so this should only be used for cases where it is okay for the UI state to change unexpectedly on the user.

commitNow

Commits this transaction synchronously. Any added fragments will be initialized and brought completely to the lifecycle state of their host and any removed fragments will be torn down accordingly before this call returns. Committing a transaction in this way allows fragments to be added as dedicated, encapsulated components that monitor the lifecycle state of their host while providing firmer ordering guarantees around when those fragments are fully initialized and ready. Fragments that manage views will have those views created and attached.

Transactions committed in this way may not be added to the FragmentManager's back stack, as doing so would break other expected ordering guarantees for other asynchronously committed transactions. This method will throw IllegalStateException if the transaction previously requested to be added to the back stack with addToBackStack(String).

A transaction can only be committed with this method prior to its containing activity saving its state. If the commit is attempted 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 from its state. See commitAllowingStateLoss() for situations where it may be okay to lose the commit.

commitNowAllowingStateLoss

Like commitNow but allows the commit to be executed after an activity's state is saved. This is dangerous because the commit can be lost if the activity needs to later be restored from its state, so this should only be used for cases where it is okay for the UI state to change unexpectedly on the user.

detach

Detach the given fragment from the UI. This is the same state as when it is put on the back stack: the fragment is removed from the UI, however its state is still being actively managed by the fragment manager. When going into this state its view hierarchy is destroyed.

replace

Replace an existing fragment that was added to a container. This is essentially the same as calling remove(Fragment) for all currently added fragments that were added with the same containerViewId and then add(int, Fragment, String) with the same arguments given here.

Parameters

containerViewId

Int: Identifier of the container whose fragment(s) are to be replaced.

replace

Replace an existing fragment that was added to a container. This is essentially the same as calling remove(Fragment) for all currently added fragments that were added with the same containerViewId and then add(int, Fragment, String) with the same arguments given here.

Parameters

containerViewId

Int: Identifier of the container whose fragment(s) are to be replaced.

runOnCommit

Add a Runnable to this transaction that will be run after this transaction has been committed. If fragment transactions are optimized this may be after other subsequent fragment operations have also taken place, or operations in this transaction may have been optimized out due to the presence of a subsequent fragment transaction in the batch.

If a transaction is committed using commitAllowingStateLoss() this runnable may be executed when the FragmentManager is in a state where new transactions may not be committed without allowing state loss.

setCustomAnimations

Set specific animation resources to run for the fragments that are entering and exiting in this transaction. These animations will not be played when popping the back stack.

This method applies the custom animations to all future fragment operations; previous operations are unaffected. Fragment operations in the same FragmentTransaction can set different animations by calling this method prior to each operation, e.g:

setCustomAnimations

Set specific animation resources to run for the fragments that are entering and exiting in this transaction. The popEnter and popExit animations will be played for enter/exit operations specifically when popping the back stack.

This method applies the custom animations to all future fragment operations; previous operations are unaffected. Fragment operations in the same FragmentTransaction can set different animations by calling this method prior to each operation, e.g:

setReorderingAllowed

Sets whether or not to allow optimizing operations within and across transactions. This will remove redundant operations, eliminating operations that cancel. For example, if two transactions are executed together, one that adds a fragment A and the next replaces it with fragment B, the operations will cancel and only fragment B will be added. That means that fragment A may not go through the creation/destruction lifecycle.

The side effect of removing redundant operations is that fragments may have state changes out of the expected order. For example, one transaction adds fragment A, a second adds fragment B, then a third removes fragment A. Without removing the redundant operations, fragment B could expect that while it is being created, fragment A will also exist because fragment A will be removed after fragment B was added. With removing redundant operations, fragment B cannot expect fragment A to exist when it has been created because fragment A's add/remove will be optimized out.