2

More to the point, in onCreate/onCreateView I am already calling FragmentManager.findFragmentByTag() to lookup any existing instance of my fragment, and it seems to find it.

So what is the point of putFragment/getFragment? Does it save something extra or cause additional lifecycle stuff to happen? Is it just an alternative to findFragmentByTag() that does more or less the same thing? Because it seems to me that the fragment is being automatically saved for me without needing to use FragmentManager.putFragment().

Kevin Lam
  • 445
  • 3
  • 9
  • Please refer to http://stackoverflow.com/questions/6446961/when-to-use-fragmentmanagerputfragment-and-getfragment – Lei Guo Dec 02 '14 at 02:28
  • That question is not the same as this question, nor do its answers refer to FragmentManager's innate state saving behavior in any way. **Edited question title to make this more clear – Kevin Lam Dec 02 '14 at 02:49

2 Answers2

3

So what is the point of putFragment/getFragment?

According to the current implementation, what putFragment(Bundle bundle, String key, Fragment fragment) do is put the index of a fragment into the bundle with the parameter key. And then getFragment(Bundle bundle, String key) get the fragment at the same index which can be retrieved from the bundle with the same key. A Fragment has its index in the FragmentManager only after it is added to it, so putFragment() can be called on a Fragment only after it is added.

Does it save something extra or cause additional lifecycle stuff to happen?

It save the index of a Fragment only, no more things else, nor do it cause any additional lifecycle stuff.

Is it just an alternative to findFragmentByTag() that does more or less the same thing?

Yes, I thik so.

According to the current implementation, what putFragment/getFragment does can be achieved with findFragmentByTag() too. But the function of putFragment/getFragment are quite limited because you can't use them without the bundle parameter, means you must call putFragment() in onSaveInstanceState().

Lei Guo
  • 2,550
  • 1
  • 17
  • 22
  • Thanks for this more detailed reply. I guess with put/get maybe it's easier to read in some cases than using findFragmentByTag()... anyway I will probably keep using tags, because it gracefully handles scenarios where a fragment may or may not be added. – Kevin Lam Dec 02 '14 at 07:27
0

Seems like putFragment/getFragment its just a safe way of storing fragments and its states inside fragment manager without displaying it.

For example you have 2 fragments that stored in your activity fields. You displaying one of them and than replace it another after that you change orientation of screen. Fields in your activity are reinited but fragment that currently displayed saved its state and other don't. But if you store fragments inside fragment manager you will have two fragments with actual states.

Stepango
  • 4,721
  • 3
  • 31
  • 44
  • My understanding is that using replace is equivalent of removing the fragment from the FragmentManager, and that putFragment() can only be run on fragments currently added to the fragmentmanager? – Kevin Lam Dec 02 '14 at 02:55
  • @HunterGuy2 thats right but actually it's two separated storages. If you add fragment via transaction it means you display it and store inside fragment manager but when you use put/get you just store it without displaying, separately from visible fragments – Stepango Dec 02 '14 at 08:37
  • my point was that I don't think you can use put if it isn't already added, and if it's added then it doesn't matter. – Kevin Lam Dec 03 '14 at 19:52