Fixed
Status Update
No update yet.
Comments
so...@gmail.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 1d99479f78c11b2a5189dd1b96811f469682dea8
Author: Andrey Kulikov <andreykulikov@google.com>
Date: Tue Oct 23 15:31:38 2018
Improve AndroidX TransitionSet behavior
1) Allow override values for a children of TransitionSet. For example for usages like this:
TransitionSet set = new TransitionSet().setDuration(300);
Fade fade = new Fade();
set.addTransition(fade);
fade.setDuration(100);
The result duration applied for fade transition is still 300. And it breaks all the flexibility of configuring sets.
The reason of it is clone() method which will be executed in beginDelayedTransition. And as part of clone() implementation of TransitionSet the children will be re-added to the new cloned set and set's duration will be re-applied again. To fix it I changed how we add transitions into set in clone().
2) Recently we had a bug about TransitionSet will crash during inflation if we provide duration for it via xml. I fixed similar issue for applying a part motion.
Test: added new tests for both issues
Bug: 64644617
Change-Id: Ie55dc7bd8c1dffc452988950e3a836afa9b6fa38
M transition/src/androidTest/java/androidx/transition/TransitionInflaterTest.java
M transition/src/androidTest/java/androidx/transition/TransitionSetTest.java
M transition/src/androidTest/res/transition/transition_set.xml
M transition/src/main/java/androidx/transition/TransitionSet.java
https://android-review.googlesource.com/803493
https://goto.google.com/android-sha1/1d99479f78c11b2a5189dd1b96811f469682dea8
Branch: androidx-master-dev
commit 1d99479f78c11b2a5189dd1b96811f469682dea8
Author: Andrey Kulikov <andreykulikov@google.com>
Date: Tue Oct 23 15:31:38 2018
Improve AndroidX TransitionSet behavior
1) Allow override values for a children of TransitionSet. For example for usages like this:
TransitionSet set = new TransitionSet().setDuration(300);
Fade fade = new Fade();
set.addTransition(fade);
fade.setDuration(100);
The result duration applied for fade transition is still 300. And it breaks all the flexibility of configuring sets.
The reason of it is clone() method which will be executed in beginDelayedTransition. And as part of clone() implementation of TransitionSet the children will be re-added to the new cloned set and set's duration will be re-applied again. To fix it I changed how we add transitions into set in clone().
2) Recently we had a bug about TransitionSet will crash during inflation if we provide duration for it via xml. I fixed similar issue for applying a part motion.
Test: added new tests for both issues
Bug: 64644617
Change-Id: Ie55dc7bd8c1dffc452988950e3a836afa9b6fa38
M transition/src/androidTest/java/androidx/transition/TransitionInflaterTest.java
M transition/src/androidTest/java/androidx/transition/TransitionSetTest.java
M transition/src/androidTest/res/transition/transition_set.xml
M transition/src/main/java/androidx/transition/TransitionSet.java
so...@gmail.com
Fixed and will be released in androidx.transition:transition:1.1.0-alpha1
il...@google.com
il...@google.com
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 45818ac652ba3a43b07f980cf22ab78be886d81d
Author: Ian Lake <ilake@google.com>
Date: Wed Jan 30 10:45:37 2019
Ensure that popBackStack() only pops one Fragment
When two Fragments with the same destination ID are
both added to the back stack, they previously had an
identical back stack name in FragmentManager, which
incorrectly means that popBackStack with that name
would pop both off the back stack.
By changing how we generate back stack names for
FragmentNavigator, we ensure that each back stack
name is unique and that only one Fragment will be
popped for each popBackStack() call.
Test: new FragmentNavigatorTest test
Change-Id: I26bdaeb65620001a74165a166aa74fe48cb468e6
Fixes: 123552990
M navigation/fragment/src/androidTest/java/androidx/navigation/fragment/FragmentNavigatorTest.kt
M navigation/fragment/src/main/java/androidx/navigation/fragment/FragmentNavigator.java
https://android-review.googlesource.com/890733
https://goto.google.com/android-sha1/45818ac652ba3a43b07f980cf22ab78be886d81d
Branch: androidx-master-dev
commit 45818ac652ba3a43b07f980cf22ab78be886d81d
Author: Ian Lake <ilake@google.com>
Date: Wed Jan 30 10:45:37 2019
Ensure that popBackStack() only pops one Fragment
When two Fragments with the same destination ID are
both added to the back stack, they previously had an
identical back stack name in FragmentManager, which
incorrectly means that popBackStack with that name
would pop both off the back stack.
By changing how we generate back stack names for
FragmentNavigator, we ensure that each back stack
name is unique and that only one Fragment will be
popped for each popBackStack() call.
Test: new FragmentNavigatorTest test
Change-Id: I26bdaeb65620001a74165a166aa74fe48cb468e6
Fixes: 123552990
M navigation/fragment/src/androidTest/java/androidx/navigation/fragment/FragmentNavigatorTest.kt
M navigation/fragment/src/main/java/androidx/navigation/fragment/FragmentNavigator.java
il...@google.com
This was regression introduced when fixing https://issuetracker.google.com/issues/110893637 - it is now fixed internally and will be available in the next release of Navigation.
ch...@gmail.com
This is still not fixed. Steps to reproduce:
- Be on the initial Fragment (FragmentA)
- Press device back button (the back press will be consumed but nothing appears to happen)
- Click on a view that will cause an attempt to navigate to FragmentB
- Crash
- Be on the initial Fragment (FragmentA)
- Press device back button (the back press will be consumed but nothing appears to happen)
- Click on a view that will cause an attempt to navigate to FragmentB
- Crash
il...@google.com
Re #7 - please file a new bug with a sample project that reproduces your issue.
pi...@gmail.com
Sim, eu tambem verifiquei os codigos do bug, eu achei o defeito e corrigi
Publiquei aqui:
https://pimentelservicos.app.br
Publiquei aqui:
pi...@gmail.com
Comment has been deleted.
Description
Version used: 1.0.0-alpha11
I'm seeing some strange behaviour when pressing back button and transistion back to a fragment from a fragment of the same id.
My app uses some generic fragment structures that are driven by args passed in, as such there are places like:
FragmentA -> FragmentB -> FragmentB -> FragmentC
However if the back button is pressed on the second instance of FragmentB, FragmentA is replaced in the navhost while the navgraph correctly displays in the toolbar. Forward navigation from this point however is missing from the navgraph and results in an IllegalStateException with the action 'not found' in the graph, unless the back button is pressed again (pushing the navgraph destination back to FragmentA)
Is this intended behaviour? If so is there a way to declare FragmentB as 'stackable'?