0

It seems that when a fragment A is replaced by a fragment B, A.onResume() is called before stopping fragment A.

I'm performing initializations in A.onResume() and I would like to avoid calling them when A is removed.

Is it possible to:

  • avoid calling A.onResume() when replacing this fragment ?
  • detect in A.onResume() that this call is generated because the fragment is being replaced ?

here is my code for replacing the fragment:

FragmentTransaction ft = getSupportFragmentManager().beginTransaction();
ft.replace(R.id.main_content, fragment);
ft.commit();
Kain
  • 197
  • 3
  • 11
  • How are you sure that `onResume()` gets called during the replacement? – Murat Karagöz Nov 28 '16 at 13:23
  • this could be a track. The debug I did was the following: 1) note the id of the old fragment object. 2) triggering replacement 3) breakpoint at the replacement code 4) breakpoint in onresume, confirming that it's on old fragment's onResume method (id). onResume is triggered by the OS framework (moveToState). I don't see what else could trigger the onResume. But I'll investigate that track, thanks ! – Kain Nov 28 '16 at 13:31

1 Answers1

0

The problem might be in debugger itself.

If you run application with debugger you can see small dialog attaching debugger, this dialog is system dialog so for the time its shown system will act as your activity is no longer foreground activity pausing it (as well as any inner fragment you load at on create).

Try following, in your fragments print in log when resume and pause are called. Then run application without debuger.

And the easiest way to have debugger and don't have this behavior is to attach debuger after running app. :(

Inverce
  • 1,487
  • 13
  • 27
  • Thanks for your suggestion. I tried it, but even without debug, the logs showed that onResume is running on the old fragment (followed by the new one) just after de replacement. – Kain Nov 28 '16 at 15:43