0

After spending a fair bit of time figuring out that the reason my fragments chosen from a drawer layout weren`t displaying sometimes due to the choreographer skipping frames (I was using transaction.replace rather than show/hide) it made me wonder -- what are the situations where one would want to use replace rather than show/hide or detach/reattach? My problem went away when I switched to using show/hide btw.

Taken from this thread I got this on what happens when you call FragmentTransaction.replace():

Android will effectively perform a sequence of FragmentTransaction.remove(...) (for all Fragments currently added to that container) and FragmentTransaction.add(...) (for your supplied Fragment). Removing a Fragment from the FragmentManager will cause the Fragment to be destroyed and its state will no longer be managed. Most noticeably, when you re-add the Fragment all of the views will have been reset. Note: since you are reusing the same Fragment instance, the Fragment will still keep the value any instance variables.

and from this thread I got that it is probably better to show/hide rather than replace if you plan on using that fragment again. My question is, in which situations do you use FragmentTransaction.Replace()? The only place I could see it really being useful is for something you know you won`t need again, kind of like a dialog picker with options but I use dialog fragments for those situations.

Does anyone use FragmentTransaction.replace regularly, and if so, why did you choose that over another method? Cheers

Community
  • 1
  • 1
TwinPrimesAreEz
  • 1,699
  • 1
  • 12
  • 16

1 Answers1

1

It maybe useful, for example, when implementing a deep fragments hierarchy in Multi-pane pattern (when click on item in the right fragment moves it to the position of the left).

Also, since hiding a Fragment keeps it in FragmentManager, it maybe expensive if you have a heavy content in it or hide multiple instances. Calling remove() or replace() and properly saving fragment's state is more Android-way, I think.

Dmide
  • 6,422
  • 3
  • 24
  • 31
  • That makes sense. I only have a few apps (they are for internal company use, not on the market) and none of them have really 'heavy' content. OTOH, with one having only two(!!) fragments with relatively lite content, I was getting skipped frames when using .replace to switch between them which seemed odd to me – TwinPrimesAreEz Feb 21 '14 at 19:45
  • It's really odd and I can't say anything specific without details. In your case I think show/hide is viable option. – Dmide Feb 21 '14 at 19:56
  • Yeah it was really odd but show/hide works well. BTW could you elaborate on what some drawbacks might be to keeping a bunch of heavy fragments in the fragmentmanager? Thx – TwinPrimesAreEz Feb 21 '14 at 20:06
  • 1
    well it's unlikely to get an OutOfMemoryError (you need to have a really heavy fragments or a really big amount of them) but you'll increase memory overhead which will be visible to users in app info, what might be disturbing for some users. Also if you have some periodic actions performing in fragments it'll also hit CPU. you're welcome, up-votes are welcome too :) – Dmide Feb 21 '14 at 20:15
  • 1
    gotcha;) It`s probably a balancing act if you have apps on the market; ex: I use the call of duty ghosts app on my phone. There is one fragment that they are clearly replacing each time it is called and the problem is that it takes sooo long to load that navigating to and from that fragment is unbearably slow. I personally would way rather see that app using more memory than have to wait 15+ seconds for a fragment to load. Personal preference I guess. It would be interesting to see how many people prefer performance vs. battery life – TwinPrimesAreEz Feb 21 '14 at 20:27