IssueTracker

I've been using the new FragmentFactory, added in androidx.fragment 1.1.0-alpha01, to use Dagger constructor injection for creating Fragment instances. It seems to be working well so far and is a big improvement over doing field injection.

It would be nice to have a overloads of FragmentTransaction.add() and replace() that take a Fragment class (instead of a Fragment instance).

This would improve the symmetry between how fragments are instantiated during restore, where the user code isn't involved in how FragmentFactory.instantiate() is called; and how they're instantiated and added in code, as typically done on onCreate/onViewCreated.

A motivating example in Kotlin - a Fragment that adds two child fragments.
The Activity has set a FragmentFactory. I'd like to use the same FragmentFactory during initial creation as will get used for restoration. I can't just call the default constructor on the Fragments, because there is none -- dagger is creating a provider that injects some dependencies. Doing this manually means grabbing the FragmentFactory from the FragmentManager and calling instantiate().
////
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    super.onViewCreated(view, savedInstanceState)
    if (savedInstanceState == null) {
        val fragmentFactory = childFragmentManager.fragmentFactory
        childFragmentManager.beginTransaction()
            .replace(R.id.map_container, fragmentFactory.instantiate(this.javaClass.classLoader!!, MapFragment::class.java.name, null))
            .replace(R.id.details_container, fragmentFactory.instantiate(this.javaClass.classLoader!!, DetailsFragment::class.java.name, null))
            .commitNow()
    }
}
////

This would be much nicer if I didn't have to create the Fragment instance directly here (ie if the FragmentTrasaction handled creating the fragment using the FragmentFactory). This might look like this:
////
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    super.onViewCreated(view, savedInstanceState)
    if (savedInstanceState == null) {
        childFragmentManager.beginTransaction()
            .replace(R.id.map_container, MapFragment::class.java))
            .replace(R.id.details_container, DetailsFragment::class.java))
            .commitNow()
    }
}
////
The benefit being that I don't have to write the code to create the Fragments.

In some ways, this 2nd code snippet is similar to passing the information needed by androidx.fragment.app.FragmentState, so the same information can be used to initially create the Fragment as would get used to restore it. This means that the creation and restoration code paths are similar, which helps to make sure the app is doing this consistently.

Suggested new overloads:
FragmentTransaction.add(@NonNull Class<? extends Fragment> fragmentClass, @Nullable Bundle args, @Nullable String tag)
FragmentTransaction.add(@IdRes int containerViewId, @NonNull Class<? extends Fragment> fragmentClass, @Nullable
Bundle args, @Nullable String tag)
FragmentTransaction.add(@IdRes int containerViewId, @NonNull Class<? extends Fragment> fragmentClass, @Nullable Bundle args)
FragmentTransaction.add(@IdRes int containerViewId, @NonNull Class<? extends Fragment> fragmentClass) // null args
FragmentTransaction.replace(@IdRes int containerViewId, @NonNull Class<? extends Fragment> fragmentClass, @Nullable Bundle args, @Nullable String tag)
FragmentTransaction.replace(@IdRes int containerViewId, @NonNull Class<? extends Fragment> fragmentClass, @Nullable Bundle args)
FragmentTransaction.replace(@IdRes int containerViewId, @NonNull Class<? extends Fragment> fragmentClass) // null args

The reason for passing the classes (rather than string class names) is to make misspellings a build error and aid the IDE with refactorings.

Component used: androidx.fragment
Version used: 1.1.0-alpha04