9

Hello everyone i want to ask what is difference between if i something write before super.onDestroyView(); and after super.onDestroyView(); see example below

Remove fragment before super.ondestoryview();

@Override
    public void onDestroyView() {

        try {
            Fragment fragment = (getFragmentManager()
                    .findFragmentById(R.id.mapviews));
            FragmentTransaction ft = getActivity().getSupportFragmentManager()
                    .beginTransaction();
            ft.remove(fragment);
            ft.commit();
        } catch (Exception e) {
            e.printStackTrace();
        }
        super.onDestroyView();
    }

Remove fragment after super.ondestoryview();

@Override
    public void onDestroyView() {
        super.onDestroyView();
        try {
            Fragment fragment = (getFragmentManager()
                    .findFragmentById(R.id.mapviews));
            FragmentTransaction ft = getActivity().getSupportFragmentManager()
                    .beginTransaction();
            ft.remove(fragment);
            ft.commit();
        } catch (Exception e) {
            e.printStackTrace();
        }

    }
Mahesh
  • 1,559
  • 6
  • 27
  • 57
  • what this method will do if i write before super.ondestroyview and after super.ondestroyview – Mahesh Dec 09 '14 at 07:03
  • 3
    https://groups.google.com/forum/#!topic/android-developers/ndsrBsIchFc. read dianne hackborn's comment – Raghunandan Dec 09 '14 at 07:04
  • 2
    possible duplicate of [Android implementation of lifecycle methods can call the superclass implementation after doing any work?](http://stackoverflow.com/questions/16925579/android-implementation-of-lifecycle-methods-can-call-the-superclass-implementati) – Eli Rising Dec 09 '14 at 07:09
  • thanks Eli Rising & Raghunandan both are help full – Mahesh Dec 09 '14 at 07:12

5 Answers5

7

If super was Fragment, than there is no difference how you do it, because Fragment's onDestroyView does nothing. But in some cases it matters.

As Dianne Hackborn said:

general rule: during any kind of initialization, let the super class do their work first; during any kind of finalization, you do your work first

P.S. IMHO it's not a good solution to remove fragment from other Fragment's onDestroyView method. That's strange, I think you should find better place for managing your fragments...

Leonidos
  • 10,482
  • 2
  • 28
  • 37
0

Helpful answer

case 1: if there is some code written in super.onDestroyView, then that code will be executed after the code you have written.

case 2: if there is some code written in super.onDestroyView, then that code will be executed first, then the code you have written will be executed.

Amrut Bidri
  • 6,276
  • 6
  • 38
  • 80
0

Here is the documentation for Fragment.java onDestroyView():

/**
 * Called when the view previously created by {@link #onCreateView} has
 * been detached from the fragment.  The next time the fragment needs
 * to be displayed, a new view will be created.  This is called
 * after {@link #onStop()} and before {@link #onDestroy()}.  It is called
 * <em>regardless</em> of whether {@link #onCreateView} returned a
 * non-null view.  Internally it is called after the view's state has
 * been saved but before it has been removed from its parent.
 */
@CallSuper
public void onDestroyView() {
    mCalled = true;
}

The important line of that documentation is: Internally it is called after the view's state has been saved but before it has been removed from its parent.

If your onDestroy() method does not need any changes to views to be saved, then I think it doesn't matter when you call super().

Rock Lee
  • 9,146
  • 10
  • 55
  • 88
  • I'm trying to find the reason why that Boolean "mCalled" goes from true, to true, and then true...all the way down the life cycle. true -> true -> true -> true, etc... ... ... unless it is set to false in-between phases, and is meant to tell the fragment whether a super was overwritten..., if this is not the case, it kinda makes no sense to me. – Delark Oct 30 '20 at 22:24
0

Your code should generally do its work after the originally intended work is done - the caveat here is if the work of the super changes the state of whatever you want to work with. That said, it does come down to a case by case basis - read the code of the super - sometimes those are already super-ing something else.

0

onDestroy() of super should be called once u have done with your clean up handling. Its a good coding practice and cause for a less buggy programming.

Taasin
  • 1
  • 2