Fixed
Status Update
Comments
il...@google.com <il...@google.com>
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #2
Project: platform/frameworks/support
Branch: androidx-master-dev
commit df318e2b31a94cc5e84deb9f0ae5bb085d457f19
Author: Ian Lake <ilake@google.com>
Date: Wed Jul 03 13:50:41 2019
Allow add() or replace() that take a Class
Rather than manually construct a Fragment to
pass it into a FragmentTransaction's add() and
replace() methods, leverage the FragmentFactory
already set on the FragmentManager to instantiate
the Fragment.
Besides allowing us to build reified versions of
these methods for Kotlin users, it also ensures
that both the intial creation and recreation
go through the same path.
Test: updated tests
BUG: 126124987
Change-Id: I726aee9a82d22c8803cf5e7aec858539c12d40bc
M fragment/fragment-ktx/api/1.2.0-alpha02.txt
M fragment/fragment-ktx/api/current.txt
A fragment/fragment-ktx/src/androidTest/java/androidx/fragment/app/FragmentTransactionTest.kt
A fragment/fragment-ktx/src/main/java/androidx/fragment/app/FragmentTransaction.kt
M fragment/fragment/api/1.2.0-alpha02.txt
M fragment/fragment/api/current.txt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentTransactionTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/BackStackRecord.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentTransaction.java
https://android-review.googlesource.com/1011464
https://goto.google.com/android-sha1/df318e2b31a94cc5e84deb9f0ae5bb085d457f19
Branch: androidx-master-dev
commit df318e2b31a94cc5e84deb9f0ae5bb085d457f19
Author: Ian Lake <ilake@google.com>
Date: Wed Jul 03 13:50:41 2019
Allow add() or replace() that take a Class
Rather than manually construct a Fragment to
pass it into a FragmentTransaction's add() and
replace() methods, leverage the FragmentFactory
already set on the FragmentManager to instantiate
the Fragment.
Besides allowing us to build reified versions of
these methods for Kotlin users, it also ensures
that both the intial creation and recreation
go through the same path.
Test: updated tests
BUG: 126124987
Change-Id: I726aee9a82d22c8803cf5e7aec858539c12d40bc
M fragment/fragment-ktx/api/1.2.0-alpha02.txt
M fragment/fragment-ktx/api/current.txt
A fragment/fragment-ktx/src/androidTest/java/androidx/fragment/app/FragmentTransactionTest.kt
A fragment/fragment-ktx/src/main/java/androidx/fragment/app/FragmentTransaction.kt
M fragment/fragment/api/1.2.0-alpha02.txt
M fragment/fragment/api/current.txt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentTransactionTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/BackStackRecord.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentTransaction.java
il...@google.com <il...@google.com> #3
We've added overloads for add and replace that take a Class and use FragmentFactory to instantiate a Fragment instance from the class name as well as Kotlin reified methods to do the same without requiring you type YourFragment::class.java. This will be available in Fragments 1.2.0-alpha02.
lu...@ozrunways.com <lu...@ozrunways.com> #4
Thanks for the explanation and link to the changeset, that's better than my original suggestion. Looking forward to trying it.
ap...@google.com <ap...@google.com> #5
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 9bfc29b0becb32aa98d135f59be47db13d82a2a0
Author: Ian Lake <ilake@google.com>
Date: Tue Jul 16 16:48:32 2019
Add optional Bundle to FragmentTransaction Class APIs
When adding or replacing a Fragment with a
Class<? extends Fragment> (added in b/126124987 ), allow
developers to pass in an optional Bundle of arguments.
In FragmentTransaction itself, the methods take
a @Nullable Bundle, ensuring that developers are
aware that they are expected to pass arguments through
that method if they want them set.
In the Kotlin extensions, the Bundle is the last
parameter, with a default value of null.
Test: updated tests
Fixes: 137684600
Change-Id: Ic492556e92031d2116d394b561002f338e5b1824
M fragment/fragment-ktx/api/1.2.0-alpha02.txt
M fragment/fragment-ktx/api/current.txt
M fragment/fragment-ktx/api/restricted_1.2.0-alpha02.txt
M fragment/fragment-ktx/api/restricted_current.txt
M fragment/fragment-ktx/src/androidTest/java/androidx/fragment/app/FragmentTransactionTest.kt
M fragment/fragment-ktx/src/main/java/androidx/fragment/app/FragmentTransaction.kt
M fragment/fragment/api/1.2.0-alpha02.txt
M fragment/fragment/api/current.txt
M fragment/fragment/api/restricted_1.2.0-alpha02.txt
M fragment/fragment/api/restricted_current.txt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentTransactionTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentTransaction.java
https://android-review.googlesource.com/1053563
https://goto.google.com/android-sha1/9bfc29b0becb32aa98d135f59be47db13d82a2a0
Branch: androidx-master-dev
commit 9bfc29b0becb32aa98d135f59be47db13d82a2a0
Author: Ian Lake <ilake@google.com>
Date: Tue Jul 16 16:48:32 2019
Add optional Bundle to FragmentTransaction Class APIs
When adding or replacing a Fragment with a
Class<? extends Fragment> (added in
developers to pass in an optional Bundle of arguments.
In FragmentTransaction itself, the methods take
a @Nullable Bundle, ensuring that developers are
aware that they are expected to pass arguments through
that method if they want them set.
In the Kotlin extensions, the Bundle is the last
parameter, with a default value of null.
Test: updated tests
Fixes: 137684600
Change-Id: Ic492556e92031d2116d394b561002f338e5b1824
M fragment/fragment-ktx/api/1.2.0-alpha02.txt
M fragment/fragment-ktx/api/current.txt
M fragment/fragment-ktx/api/restricted_1.2.0-alpha02.txt
M fragment/fragment-ktx/api/restricted_current.txt
M fragment/fragment-ktx/src/androidTest/java/androidx/fragment/app/FragmentTransactionTest.kt
M fragment/fragment-ktx/src/main/java/androidx/fragment/app/FragmentTransaction.kt
M fragment/fragment/api/1.2.0-alpha02.txt
M fragment/fragment/api/current.txt
M fragment/fragment/api/restricted_1.2.0-alpha02.txt
M fragment/fragment/api/restricted_current.txt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentTransactionTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentTransaction.java
Description
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::
.replace(R.id.details_container, fragmentFactory.instantiate(this.javaClass.classLoader!!, DetailsFragment::
.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