Android app there is a special case, is the app running in the background when the nervous system leads to full recovery when resources app resources (to kill the app's process), then again when the app returns from background to foreground, app will restart . This case referred to as: "Memory Restart."
1, the transfer of Fragment data, it is recommended to use setArguments(Bundle args), and then in the onCreateuse getArguments()removed before the "memory reset", the system will help you to save data, it will not cause data loss. Activity and Intent principle of consistency.
2, newInstance(参数) create Fragment objects, advantages which data is caller only needs to pass the relationship, without concern for what Key transfer data Yes.
3, if you need to use objects in the host Activity Fragment recommended in your base class Fragment of an Activity definition of global variables in onAttachthe initialization. Code getActivity () appears () within onCreateView is likely to be dangerous.
(1) Each Fragment and a host Activity (inherited from FragmentActivity) will be in when you create, initialize a FragmentManager object handle nested Fragment key problem it is to sort out the stack view of these different classes.
(2) the host Activity, getSupportFragmentManager()acquired FragmentActivity FragmentManager of objects;
For Fragment, getFragmentManager()it is to obtain a parent Fragment (if not, it is FragmentActivity) of FragmentManager object, getChildFragmentManager()is to obtain their FragmentManager object.
Fragment recovery (Fragment while preventing overlapping), select getFragments () or findFragmentByTag ()
For more within a Fragment Activity, if the relationship Fragment of a "process", such as Login -> Register / Forgot Password -> fill in the information -> Go to the home page Activity. In this case, the getFragments () is the most appropriate manner, in your Activity (in a better way all your "flow" in Activity base class), write the following code:
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) { super.onCreate(savedInstanceState); if (savedInstanceState != null) { List<Fragment> fragments = getSupportFragmentManager().getFragments(); if (fragments != null && fragments.size() > 0) { boolean showFlag = false; FragmentTransaction ft = getSupportFragmentManager().beginTransaction(); for (int i = fragments.size() - 1; i >= 0; i--) { Fragment fragment = fragments.get(i); if (fragment != null) { if (!showFlag) { ft.show(fragments.get(i)); showFlag = true; } else { ft.hide(fragments.get(i)); } } } ft.commit(); } } }
The above recovery Fragment way to not only improve performance, while avoiding the Fragment overlap, the most important thing, you do not have a relationship Activity container which Fragment.
If your Activity of Fragments, not "process" relationship, but "sibling" relationship, such as QQ main interface, "news", "Contact", "dynamic", which belongs to the same level 3 Fragment relationship with the above code is inappropriate, the recovery time will eventually return to the last one, the "dynamic Fragment".
The correct approach is onSaveInstanceState()to save the current location Fragment of tag or index, at onCreate()the time of recovery is to hide the other two Fragment.
Call follows a similar transaction methods, because they run in the message queue of the problem, not enough time to run out of stack method on the transaction, which may result in abnormal phenomenon.
getSupportFragmentManager().beginTransaction() .add(R.id.container, fragment , tag) .hide(currentFragment) .commit;
正确的做法是使用主线程的Handler，将事务放到Runnable里运行。
new Handler().post(new Runnable(){
@Override public void run() { // 在这里执行Fragment事务
getSupportFragmentManager().beginTransaction() .add(R.id.container, fragment , tag) .hide(currentFragment) .commit;} });