Status Update
Comments
ba...@gmail.com <ba...@gmail.com> #2
Please include a sample project that reproduces your issue.
yc...@gmail.com <yc...@gmail.com> #3
Steps to reproduce:
1. Press on "Search" icon;
2. Write something;
3. Search this text, keyboard will be dismissed;
4. Tap on "Dialog" button;
5. Dissmiss dialog;
With the new 1.5.0 fragment library version text will be cleared in the search box after dismissing dialog.
In the version 1.4.1 and lower text in the search is not clearing and this is correct behaviour.
Please suggest some workarounds or how to fix this issue?
ri...@gmail.com <ri...@gmail.com> #4
yu...@gmail.com <yu...@gmail.com> #5
st...@detroitlabs.com <st...@detroitlabs.com> #6
na...@gmail.com <na...@gmail.com> #7
Hello
I raised similar issue with this ticket
This makes the SearchView unusable/broken when fragments are changed (i.e base on searchView input query)
What can we do to fix this problem? What is the progress of work on solving this problem?
ri...@gmail.com <ri...@gmail.com> #8
sk...@gmail.com <sk...@gmail.com> #9
Any idea on when it will be fixed?
sk...@gmail.com <sk...@gmail.com> #10
dn...@google.com <dn...@google.com> #11
Can you update regarding any progress on this issue.
st...@gmail.com <st...@gmail.com> #13
Branch: androidx-main
commit 50f098644adc703ae218b0b7e999629f516a0241
Author: sanura <sanura@google.com>
Date: Thu Mar 02 00:11:35 2023
Add check to only invalidate options menu when contributing menu items
FragmentManager previously appropriately only added
a MenuProvider when the host is a MenuHost **and**
we are at the root fragment that is providing the
menu items. This behavior should be mirrored when
removing a MenuProvider as well, so that only
components that directly contribute menu items will
invalidate the options menu.
Bug: 244336571
Test: all tests pass
Change-Id: I9404ee9fcc9ce6b80d70a93bea720fe4ccf583a0
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentContainerInflatedFragmentTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/OptionsMenuFragmentTest.kt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/test/FragmentTestActivity.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentActivity.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
dn...@google.com <dn...@google.com> #14
Please show what to write on gradle file.
st...@gmail.com <st...@gmail.com> #15
This has been fixed internally and will be available in the Fragment 1.6.0-alpha07
release.
gk...@gmail.com <gk...@gmail.com> #16
It's part of the material dependency, perhaps?
m4...@gmail.com <m4...@gmail.com> #17
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.fragment:fragment:1.6.0-alpha07
dg...@gmail.com <dg...@gmail.com> #18
il...@google.com <il...@google.com> #19
It says "Duplicate class found".
The IDE doesn't provide any useful explanation of what is the class that is duplicated and what to do about it.
Please help.
ga...@gmail.com <ga...@gmail.com> #20
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.fragment:fragment:1.5.6
[Deleted User] <[Deleted User]> #21
dc...@gmail.com <dc...@gmail.com> #22
@21 androidx.fragment:fragment:1.5.6 is a STABLE release. It has the fix we need. The androidx.fragment:fragment:1.6.0-alpha07 is an alpha as it says. 1.6 is "work in progress". 1.6.0 is still not a stable release. Use "alpha" only for testing
ga...@gmail.com <ga...@gmail.com> #23
ki...@gmail.com <ki...@gmail.com> #24
I've made a custom view group based on ScreenCoordinatorLayout
In bug case, Fragment.animateRemoveFragment() is called, but
ja...@planticle.com.au <ja...@planticle.com.au> #25
Still, this is was a frustrating and time consuming bug to work around, and I look forward to seeing a fix for this in the Jetpack Navigation library.
mi...@gmail.com <mi...@gmail.com> #26
We probably need to stick to activities if we want to follow material design guidelines.
I also look forward for this being fixed.
mi...@gmail.com <mi...@gmail.com> #27
mi...@gmail.com <mi...@gmail.com> #28
With the Navigation Component, and because of this limitation, is impossible to have an "slide on top" kind of transition.
ni...@webwag.com <ni...@webwag.com> #29
Currently, it's a FrameLayout which has this issue.
From NavHostFragment.java :
@Nullable
@Override
public View onCreateView(@NonNull LayoutInflater inflater, @Nullable ViewGroup container,
@Nullable Bundle savedInstanceState) {
FrameLayout frameLayout = new FrameLayout(inflater.getContext());
// When added via XML, this has no effect (since this FrameLayout is given the ID
// automatically), but this ensures that the View exists as part of this Fragment's View
// hierarchy in cases where the NavHostFragment is added programmatically as is required
// for child fragment transactions
frameLayout.setId(getId());
return frameLayout;
}
je...@gmail.com <je...@gmail.com> #30
pe...@gmail.com <pe...@gmail.com> #31
Here may be a solution:
jb...@google.com <jb...@google.com>
ap...@google.com <ap...@google.com> #32
Branch: androidx-master-dev
commit 2534c731cc31a615e4584d74327521ec8c5a8aa7
Author: jbwoods <jbwoods@google.com>
Date: Thu Jun 20 12:42:37 2019
Draw exit animations first in FragmentContainerView
ViewGroups always draw exiting view animations last. For Fragments, this
means that the exiting Fragment is always on top of all others. There
can be no interaction with entering fragments, and there is the
possiblity of a "pop" when the exit animation finishes to reveal the
Fragment underneath.
FragmentContainerView overrides the dispatchDraw and drawChild method to
force all disappearing children to be drawn first. It overrides public
methods from ViewGroup to build the proper list of transitioning views
and disappearing child views.
Test: Added units tests, tested visually in app, ./gradlew checkApi
BUG: 37036000
Change-Id: I054eaf4ae234258bc7abec22c4c8e559a2c6be71
M fragment/fragment/api/1.2.0-alpha01.txt
M fragment/fragment/api/current.txt
M fragment/fragment/api/restricted_1.2.0-alpha01.txt
M fragment/fragment/api/restricted_current.txt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentContainerViewTest.kt
M fragment/fragment/src/androidTest/res/layout/fragment_container_view.xml
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentContainerView.java
ge...@gmail.com <ge...@gmail.com> #33
[Deleted User] <[Deleted User]> #34
1. When going forward, I want exit animation to be bottom, and enter animation on top
2. When going backwards, I want exit animation on top, and enter animation on the bottom.
That way I could replicate iOS animation behavior where new fragment "comes on top" on previous, but when click back, I also want that fragment to disappear "from the top" and reveal previous fragment beneath it. android:zAdjustment sounds like something that should fix this problem, but is it working for Fragments and Navigation library?
Can anybody help me here?
il...@google.com <il...@google.com> #35
il...@google.com <il...@google.com>
bi...@gmail.com <bi...@gmail.com> #36
or...@gmail.com <or...@gmail.com> #37
"Fragments using exit animations are drawn before all others for FragmentContainerView. This ensures that exiting Fragments do not appear on top of the view."
Is our long national nightmare of improperly drawn transition animations over?
mo...@gmail.com <mo...@gmail.com> #38
^ This. I think ideally we should have a way of telling the Fragment its Z ordering during the animation. I know that are ways, but couldn't find any that works with the Navigation Components.
ma...@gmail.com <ma...@gmail.com> #39
I am experiencing the same issue for version 1.2.3 when using the "FragmentContainerView" and setting "EnterTransition" to a slide transition, and using an exisiting fade transition in "ExitTransition"?
So I am not using "FragmentTransaction.setCustomAnimations", but I guess it is supposed to work the same way?
[Deleted User] <[Deleted User]> #40
- works with setCustomAninations
- still does not work with setExitTransition / setEnterTransition
It looks like FragmentContainerView.startViewTransition is not called properly in the broken case, which causes that FragmentContainerView falls into the standard drawing path.
[Deleted User] <[Deleted User]> #41
The actual problem with setExitTransition / setEnterTransition is caused by fact that any subclass of Visibility transition (e.g. Fade, Slide, etc.), uses ViewOverlay to realize the animation when the exiting View is removed from its parent. And this is actually happening when performing replace() Fragment transaction. The trouble is than the entering view wont use ViewOverlay and will be effectively BELOW the exiting view :(
It is very sad that such basic usecases are still broken :(
I really cant believe that it was not catched earlier :(
As a workaround, one may try to write customized FragmentContainerVIew (cant inherit, because the one from Jetpack is final.... ) and write a customized set of Transitions that does not use ViewOverlay or use it in consistent manner preserving the z-order.
gc...@neptuneretailsolutions.com <gc...@neptuneretailsolutions.com> #42
Problem not fixed for Translations - suggest reopening.
My fix to allow enterTransition to act as if Hold() was working correctly. I don't enterTransition animate at all:
exitTransition = HoldBackground(resources).setDuration(duration)
enterTransition = Slide(Gravity.RIGHT).setDuration(duration)
With HoldBackground looking like this:
class HoldBackground(val resources : Resources) : Transition() {
init {
duration = resources.getInteger(android.R.integer.config_mediumAnimTime).toLong()
}
var inProgress = false
@Synchronized
override fun captureStartValues(transitionValues: TransitionValues) {
if(inProgress) return
transitionValues.view.also { exitingView ->
exitingView.parent.also { fragmentContainer ->
if(fragmentContainer is View && exitingView.width > 0 && exitingView.height > 0) {
inProgress = true
val previousBackground = fragmentContainer.background
val bitmap = Bitmap.createBitmap(
exitingView.width,
exitingView.height,
Bitmap.Config.ARGB_8888
)
exitingView.draw(Canvas(bitmap))
fragmentContainer.background = BitmapDrawable(resources, bitmap)
// Simple animator so timing matches developer animation scales
val animator = ValueAnimator.ofInt(0, 1).setDuration(duration)
animator.addListener(object : BlankAnimatorListener() {
override fun onAnimationEnd(animation: Animator?) {
fragmentContainer.background = previousBackground
inProgress = false
}
})
animator.start()
}
}
}
}
override fun captureEndValues(transitionValues: TransitionValues) {}
}
It's very likely stupidly resource intensive given it's creating a screen size bitmap... but it does happen to work.
yo...@gmail.com <yo...@gmail.com> #43
- Cancelling replace-fragment transitions, i.e. navigating up during a transition, causes the pop-exiting fragment to appear below the pop-entering fragment.
- It doesn't work with setExitTransition / setEnterTransition. Entering fragment is below the exiting fragment.
I have no words for this. Ill probably just use multiple-activities (instead of single-activity) and use activity transitions.
If someone has a solution, it will be much appreciated.
Description
ft.setCustomAnimations(R.anim.slide_in_right, R.anim.slide_out_left);
slide_in_right.xml
<?xml version="1.0" encoding="utf-8"?>
<set xmlns:android="
android:shareInterpolator="true"
android:interpolator="@android:anim/decelerate_interpolator">
<translate android:fromXDelta="100%"
android:toXDelta="0%" android:fromYDelta="0%"
android:toYDelta="0%" android:duration="400">
</translate>
</set>
anim.slide_out_left.xml
<?xml version="1.0" encoding="utf-8"?>
<set xmlns:android="
android:shareInterpolator="true"
android:interpolator="@android:anim/decelerate_interpolator"
android:zAdjustment="bottom">
<translate android:fromXDelta="0%"
android:toXDelta="-50%" android:fromYDelta="0%"<!-- -50% shows the problem, 100% does not -->
android:toYDelta="0%" android:duration="400">
</translate>
</set>
(The zAdjustment tag does nothing)
The exiting fragment will be on top of the entering fragment, which is the opposite behavior than what is expected or useful. Currently, an exiting fragment must leave the frame completely, otherwise it will be on top of the entering fragment at the end of the animation, at which point in the last frame of the animation the exiting fragment will pop out of existence. The Z order of the fragments should be reversed or made customizable. The current z ordering offers no advantages.
I am trying to achieve the material effect of putting one "page" of a fragment on top of another while moving the exiting "page" somewhat to the left (50%), rather than 100% which would give the effect of just shoving the exiting "page" to the left, not putting it under the entering fragment. There are some work arounds described here
but they don't apply to my case.