Status Update
Comments
il...@google.com <il...@google.com>
ks...@gmail.com <ks...@gmail.com> #2
sa...@gmail.com <sa...@gmail.com> #3
This looks like the icon is either getting cropped OR it is getting scrolled (same as other items such as Display > Lock screen display > Lock screen pop has a scrollable content inside). Do you know what is the case here?
In terms of solutions, assuming we need to keep all the elements, we can:
1. shrink the icon
2. let is scroll, and leave it WAI
co...@gmail.com <co...@gmail.com> #4
1. Can we shrink the icon to fit in the smallest UI scenario? (1/3 screen)?
-Is it possible to make the icon scalable? Or do we want to swap the icon to the smaller size?
2. If #1 is problematic, we could have a scroll bar for the description and icon area following our framework. Which is not ideal in this case.
co...@gmail.com <co...@gmail.com> #5
Branch: androidx-master-dev
commit 32ad78e0ee659091e9074cc588d0759cd8b01d38
Author: Kevin Chyn <kchyn@google.com>
Date: Thu Jul 18 16:50:08 2019
Allow the FingerprintDialog to be scrollable
Fixes: 126367887
Test: Split screen, BiometricPromptDemo, dialog scrolls
Change-Id: Id14f116391c8ebfe27f1a7e6c40516ea0383221a
M biometric/res/layout/fingerprint_dialog_layout.xml
ez...@gmail.com <ez...@gmail.com> #6
It's not a perfect transition, but better than nothing
Thanks for the code
he...@gmail.com <he...@gmail.com> #7
ru...@gmail.com <ru...@gmail.com> #8
I suppose it must be separate from navigation component.
It could be part of
androidx.compose.animation
or new one androidx.compose.transition
ru...@gmail.com <ru...@gmail.com> #9
Because, not everybody uses compose navigation. There are third party libraries which best suits for some use-cases. For example, we used Decompose which is multi-platform library. Transition could be managed by parent @Composable function.
sj...@gmail.com <sj...@gmail.com> #10
Hi, I know some people like me are waiting to see how this develops, and Ian Lake shared an update on Slack today which I thought was very helpful:
[Transitions in navigation-compose are] definitely coming. How transitions in Compose work is that you need to hold onto all state until the exit transition actually completes (otherwise the state just instantly disappears). That's very different from the View world where a snapshot of the Views would be animated out. It means some infrastructural work is needed in Navigation to support that delayed removal of state, but it has also meant that we've been working very closely with @Doris Liu on exactly what that transition APIs should look like to set you up for future work like shared elements, etc.
st...@gmail.com <st...@gmail.com> #11
Thanks
il...@google.com <il...@google.com> #12
Re #11 - Navigation Compose is not in beta - it is currently at
This is still planned for the first stable release of Navigation Compose.
ap...@google.com <ap...@google.com> #13
Branch: androidx-main
commit e37b6354cba41416f933bf9402bd153be5bc3dac
Author: Jeremy Woods <jbwoods@google.com>
Date: Tue Mar 30 10:50:52 2021
Add Box container and modifiers to NavHost
NavHost currently does not have a container composable destinations and
just takes the shape of whatever compose it is placed in. Really, you
always want to wrap a NavHost in a Box since that ensures that the
destinations share the same window. This will become even more important
once we introduce transitions, where wrapping a NavHost with something
like a column would result in the entering and exiting destinations
being stacked horizontally in drawing order instead of layered on top
of each other.
This change wraps the destination composable in a Box, and NavHost now
takes modifiers that are passed to that Box.
RelNote: "`NavHost` now accepts a `Modifier`, which is passed down to
the composable container that wraps the destination composables."
Test: All existing tests pass
Bug: 172112072
Change-Id: I85aca06d44b0a1f55b7a8ef5ca7dae34577d28fa
M navigation/navigation-compose/api/api_lint.ignore
M navigation/navigation-compose/api/current.txt
M navigation/navigation-compose/api/public_plus_experimental_current.txt
M navigation/navigation-compose/api/restricted_current.txt
M navigation/navigation-compose/build.gradle
M navigation/navigation-compose/integration-tests/navigation-demos/src/main/java/androidx/navigation/compose/demos/BottomBarNavDemo.kt
M navigation/navigation-compose/samples/src/main/java/androidx/navigation/compose/samples/NavigationSamples.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/NavHost.kt
ng...@gmail.com <ng...@gmail.com> #14
I can see the MR merged... Any plans to release this feature?
lo...@gmail.com <lo...@gmail.com> #15
ba...@gmail.com <ba...@gmail.com> #16
Transition for Compose Navigation is not taken into account.
The commit google fixed is adding a Box container to that of navigation composable but it still doesn't solve the issue of transition for two composable when used with navigation component.
For transition between two composable, we now have to use AnimatedVisibility to provide slide In / Slide Out, but it should not be used. We really need a way to animate the composable.
If I missed anything kindly clarify.
da...@gmail.com <da...@gmail.com> #17
This issue isn't market as fixed.
My guess is that the box modification + injected modifier will allow adding modifiers to handle transitioning between screens.
de...@gmail.com <de...@gmail.com> #18
ra...@gmail.com <ra...@gmail.com> #19
why delayed again and again?
de...@gmail.com <de...@gmail.com> #20
Why not give
ap...@google.com <ap...@google.com> #22
Branch: androidx-main
commit 8194329aa262cf1e5759c76129a2845d0b74f675
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Jun 16 17:14:30 2021
Add transition apis to NavigatorState
Added the addWithTransition and popWithTransition APIs to the
NavigatorState. These APIs provide an OnTransitionComplete callback for
doing the actual add/pop once some action has been completed (after a
transition).
Relnote: "You can now use the add/popWithTransition APIs to add or pop a
destination aynchronously."
Test: all existing tests pass
Bug: 172112072
Change-Id: Ic4d7cc6530bf576c4d812d1fd0c5a2697874d384
M navigation/navigation-common/api/api_lint.ignore
M navigation/navigation-common/api/current.txt
M navigation/navigation-common/api/public_plus_experimental_current.txt
M navigation/navigation-common/api/restricted_current.txt
M navigation/navigation-common/src/main/java/androidx/navigation/NavigatorState.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
M navigation/navigation-testing/src/androidTest/java/androidx/navigation/testing/TestNavigatorStateTest.kt
M navigation/navigation-testing/src/main/java/androidx/navigation/testing/TestNavigatorState.kt
ap...@google.com <ap...@google.com> #23
Branch: androidx-main
commit 6a6cfa99a3e857318e82cf1b7401835de1b65ede
Author: Jeremy Woods <jbwoods@google.com>
Date: Mon Jun 21 12:06:50 2021
Use push instead of add for NavigatorState
Changing the name from add to push to symmetry with the pop API.
RelNote: "The `add` function in `NavigatorState` has been renamed to
`push`. All current calls to `add()` will need to be changed to push()."
Test: ./gradlew checkApi
Bug: 172112072
Change-Id: Ie89fcbcf0753d6918f91450e322b156ff2fd6e9b
M navigation/navigation-common/api/current.txt
M navigation/navigation-common/api/public_plus_experimental_current.txt
M navigation/navigation-common/api/restricted_current.txt
M navigation/navigation-common/src/main/java/androidx/navigation/Navigator.kt
M navigation/navigation-common/src/main/java/androidx/navigation/NavigatorState.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/ComposeNavigator.kt
M navigation/navigation-fragment/src/main/java/androidx/navigation/fragment/DialogFragmentNavigator.kt
M navigation/navigation-fragment/src/main/java/androidx/navigation/fragment/FragmentNavigator.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
M navigation/navigation-testing/src/androidTest/java/androidx/navigation/testing/TestNavigatorStateTest.kt
M navigation/navigation-testing/src/main/java/androidx/navigation/testing/TestNavigatorState.kt
ap...@google.com <ap...@google.com> #24
Branch: androidx-main
commit cab838c721195adf0f7ef7236c29a970f608d17d
Author: Jeremy Woods <jbwoods@google.com>
Date: Mon Jul 12 01:21:06 2021
Add Transitions to Navigation Compose
Now that we have the new Navigator APIs from base navigation we can
properly delay destroying destinations until after transitions have been
completed. This means that viewModels will survive if a transition is
canceled and we can properly support animations in Navigation Compose.
RelNote: "Navigation compose now always uses Crossfades when navigating
through destinations."
Test: NavHostTest
Bug: 172112072
Change-Id: I07049268d9c78bfbc6bb49f94bf2a1284d4f1180
M navigation/navigation-common/src/main/java/androidx/navigation/NavBackStackEntry.kt
M navigation/navigation-compose/build.gradle
M navigation/navigation-compose/src/androidTest/java/androidx/navigation/compose/NavHostTest.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/ComposeNavigator.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/NavHost.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
b9...@gmail.com <b9...@gmail.com> #25
Sorry I don't get the point. Why always uses Crossfades effect? Could we change to different transition effect?
ap...@google.com <ap...@google.com> #26
Branch: androidx-main
commit 013d94b69530f18051a4df9674dc7a08d52022f0
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Jul 21 11:57:44 2021
Fix popWithTransition in TestNavigatorState
When we popWithTransition the entry being popped should remain in a
CREATED state before being the transition is completed and the entry
coming to the top of the back stack should remain in the STARTED state
until its transition is completed.
This change adds the logic to ensure we hold the entries in their proper
state while the transition is happening.
RelNote: "When calling `popWithTransition()` from `TestNavigatorState`
the entries will now have the proper state while the transition is
running before it receives the `onTransitionComplete()` callback."
Test: modified TestNavigatorStateTest
Bug: 172112072
Change-Id: I66cddae843f476c19ac3a6c40a7cd5031355768a
M navigation/navigation-testing/src/androidTest/java/androidx/navigation/testing/TestNavigatorStateTest.kt
M navigation/navigation-testing/src/main/java/androidx/navigation/testing/TestNavigatorState.kt
ap...@google.com <ap...@google.com> #27
Branch: androidx-main
commit e3b742c6b338c04f6be0e6560c39c878376ad3ca
Author: Jeremy Woods <jbwoods@google.com>
Date: Fri Jul 16 16:22:09 2021
Mark destination navigating away from as transitioning
When navigating forward with transitions, although we don't hold the
lifecycle of the entry being kept on the back stack above CREATED during
the transition, we should still mark it as transitioning until its
transition is actually complete.
RelNote: "When navigating away from a `NavBackStackEntry` and using the
`pushWithTransition` API, the `NavigatorState` will now properly mark
the previous entry as transitioning."
Test: modified test
Bug: 172112072
Bug: 194301889
Fixes: 191870023
Change-Id: If0543dd1c20e7338078115e98b5585623f9b8f1c
M navigation/navigation-common/api/current.txt
M navigation/navigation-common/api/public_plus_experimental_current.txt
M navigation/navigation-common/api/restricted_current.txt
M navigation/navigation-common/src/main/java/androidx/navigation/NavigatorState.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/ComposeNavigator.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/NavHost.kt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavBackStackEntryTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
M navigation/navigation-testing/src/androidTest/java/androidx/navigation/testing/TestNavigatorStateTest.kt
M navigation/navigation-testing/src/main/java/androidx/navigation/testing/TestNavigatorState.kt
M testutils/testutils-navigation/src/main/java/androidx/testutils/TestNavigator.kt
ag...@xmartlabs.com <ag...@xmartlabs.com> #28
I am experiencing an issue with the transition. When my app is opened, the splash is shown and on exit transition it has a broken crossfade. Also, after this, no interaction is registered by the app. This issue is introduced in 2.4.0-alpha05
sw...@gmail.com <sw...@gmail.com> #29
cf...@gmail.com <cf...@gmail.com> #30
I am experiencing the same issue as
@Composable
fun ScreenThatRequiresAuth(navController: NavController, authenticated: Boolean) {
if (authenticated) {
// emit UI content for this screen
} else {
navController.navigate("login-screen")
}
}
no longer works because the navigation no longer happens instantaneously, so navController.navigate("login-screen")
is called repeatedly on subsequent recompositions as the animation proceeds. Therefore we are indefinitely navigating and crossfading, resulting in that visual glitch. If there is no way navigate without an animation anymore, then alpha05 breaks most implementations of this officially recommended pattern. My current workaround is to navigate inside of a LaunchedEffect
block so that it doesn't happen again on recompositions while animating the transition. The UI content of ScreenThatRequiresAuth
is still not shown if we have no auth, but now it is less clean than an if/else statement:
@Composable
fun ScreenThatRequiresAuth(navController: NavController, authenticated: Boolean) {
LaunchedEffect(authenticated) {
if (!authenticated) {
navController.navigate("login-screen")
}
}
if (authenticated) {
// emit UI content for this screen
}
}
This works, it just means that the login screen has to fade in from nothing, which may look awkward, and now the code required to implement this pattern is less straightforward. Since we should not be showing ScreenThatRequiresAuth
at all if there is no auth, it doesn't make sense to fade it out -- this transition should happen without an animation. When will this be possible?
je...@gmail.com <je...@gmail.com> #31
Navigating on recomposition seems like an anti pattern to me. I think calling 'navigate' should only happen upon a UI event. If you want to show a login screen, you should probably check if the app has persisted credentials and then either show the log-in (if there are no credentials) screen or the main screen (if there are some).
The composable could look like this:
@Composable
fun ContentView(
registration: Registration
) {
when (registration) {
is Registration.Registered -> MainView(...)
else -> OnboardingView(...)
}
}
Navigation is then happening inside the MainView composable and the OnboardingView composable. There you have your destinations like such:
@Composable
fun MainView(
...
) {
val navController = rememberNavController()
val actions = remember(navController) { NavActions(navController) }
NavHost(navController = navController, startDestination = Destinations.Home) {
composable(Destinations.Home) {
HomeView(
profileSelected = { navController.navigate(route = Destinations.Profile) },
...
)
}
...
}
}
Handling the credentials could be done in a separate class, which is instantiated in an activity:
sealed class Registration {
class Registered(val credentials: Credentials): Registration()
object Onboarding: Registration()
}
class AppState(private val persistence: Persistence): ViewModel() {
companion object {
var registration by mutableStateOf<Registration>(Registration.Onboarding)
private set
}
init {
load()
}
private fun load() {
val credentials = persistence.readCredentials()
registration = if (credentials != null)
Registration.Registered(credentials)
else
Registration.Onboarding
}
fun setCredentials(credentials: Credentials) {
persistence.saveCredentials(credentials)
registration = Registration.Registered(credentials)
}
}
jb...@google.com <jb...@google.com> #32
As of compose 1.0.1
many of the @Experimental
.
In the interest of providing a solution for Navigation with custom Compose Animations as soon as possible, we opted to provide a new module in 1.1.0
, we will move the implementation back into the Jetpack Navigation library
from Accompanist Navigation Animation
.
The bug we will use for tracking folding the APIs back into Jetpack Navigation is
For more details, see the
me...@gmail.com <me...@gmail.com> #33
Should we still be using Accompanist Navigation Animation? We're on Compose 1.2.0-beta02 by the way.
jo...@gmail.com <jo...@gmail.com> #34
I would like to do something like navigationController.navigate(AnotherScreen(name: String, anotherArgument: Boolean), animated = NavigationAnimation.Push) and thats it.
To achieve a push animation which is used so often in apps, it's way too hard to achieve.
bl...@gmail.com <bl...@gmail.com> #35
#34 I found it's easier & much more flexible to just implement your own navigation solution. It need not be super complicated in Compose. The Jetpack nav library really isn't worth the hassle.
jo...@gmail.com <jo...@gmail.com> #36
lo...@gmail.com <lo...@gmail.com> #37
I can't understand why you have such a negative view on compose and the navigation approach given. I use the
Description
Version used: 1.0.0-alpha01
Devices/Android versions reproduced on: All
Provide a way to navigate composable screens with animations (slide, fade etc')