2

Create app with a Fragment containing a Button id=button In 

  @Override
    protected void onStart() {
        super.onStart();
        getSupportFragmentManager()
                .beginTransaction()
                .add(R.id.activity_main, new Testfrag())
                .commitNow();
        View b = findViewById(R.id.button);

    }

b is returned as the button and the fragments onCreateView is called before the end of the method. But in

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
 FragmentManager fm=  getSupportFragmentManager();
       fm.beginTransaction()
          .add(R.id.activity_main, new Testfrag())
        .commitNow();
   View b = findViewById(R.id.button);
}

b is null and the fragments onCreateView is not called until after the method ends. This may be a "feature" but there is nothing about it in the documentation.

Why does commit Now behave differently in onCreate - doesn't call onCreateView until later and onStart (or any other event handler) where onCreateView is called synchronously?

W4R10CK
  • 5,502
  • 2
  • 19
  • 30
Mike James
  • 749
  • 6
  • 9

1 Answers1

1

I'm honestly surprised the first one works.

If I had to wager, it's the FragmentManager doesn't call the Fragment lifecycle callbacks beyond the point of the Activity's current life cycle. From onCreate() it will call onAttach() then onCreate() on the Fragment. At some point between onCreate and onStart, the FragmentManager will complete the layout process by calling onCreateView() on every Fragment that has been committed so far. Then it will call onStart() on every fragment when the Activity has started.

If you were to commit a Fragment in a later callback, say, onResume(). The FragmentManager will need to set up the Fragment all the way up to the certain that point, so it's going to go down the lifecycle onAttach(), onCreate(), onCreateView(), onViewCreated(), onStart(), and finally onResume() all at once. Now the Fragment would be caught up to the rest of the Activity.

Generally speaking, there's usually no reason for an Activity to have direct access to a Fragment's internal View elements. The Fragment handles the view events. If necessary, passes the events back up to the Activity. This allows you to alter the Fragment's layout however you want without having to modify the Activity. It also lets you re-use a Fragment in different Activities.

DeeV
  • 35,865
  • 9
  • 108
  • 95
  • This is an interesting idea and documentation of how Activity and Fragment life cycles fit together isn't clear. However if you include a Fragment using the tag then the FragmentManager does call onCreateView while in the Activitys OnCreate. I will see if I can find out more about how the two lifecycles sync. – Mike James Jan 10 '17 at 18:43
  • @MikeJames I've found it's best to not link the two lifecycles together at all. The lifecycles of a Fragment gets really complex when using a ViewPager for example. Think of them as two separate entities. – DeeV Jan 10 '17 at 18:45
  • I can see that ignoring any sync between Activity and Fragment lifecycle is a simplification when you are thinking about designing a Fragment but in this case it has been suggested that it is essentiall to understanding what is happening. The hypothesis is that the Activity will not "push" the Fragment's state further than it would naturally be at the time. Still trying to figure out how to see if this is indeed what is happening. – Mike James Jan 11 '17 at 10:18