Lines Matching refs:back
13 <li>Fragments have their own lifecycle, state, and back stack</li>
71 fragment transaction, you can also add it to a back stack that's managed by the
72 activity—each back stack entry in the activity is a record of the fragment transaction that
73 occurred. The back stack allows the user to reverse a fragment transaction (navigate backwards),
86 how fragments can maintain their state when added to the activity's back stack, share
98 to modify the activity's appearance at runtime and preserve those changes in a back stack
170 the user might not come back).</dd>
186 incorporate a fragment dialog into the back stack of fragments managed by the activity,
393 <li>Pop fragments off the back stack, with {@link
395 <li>Register a listener for changes to the back stack, with {@link
412 android.app.FragmentTransaction}. You can also save each transaction to a back stack managed by the
434 to a back stack of fragment transactions. This back stack is managed by the activity and allows
438 state in the back stack:</p>
446 // and add the transaction to the back stack
457 saved to the back stack so the user can reverse the transaction and bring back the
465 back stack as a single transaction and the <em>Back</em> button will reverse them all together.</p>
477 destroyed when the transaction is committed and the user cannot navigate back to it. Whereas, if you
480 back.</p>
673 fragment has been removed from the activity but added to the back stack. A stopped fragment is
690 stored in its respective back stack. An activity is placed into a back stack of activities
691 that's managed by the system when it's stopped, by default (so that the user can navigate back
693 href="{@docRoot}guide/components/tasks-and-back-stack.html">Tasks and Back Stack</a>).
694 However, a fragment is placed into a back stack managed by the host activity only when you