Hello wave I m experimenting a bit with compose navigation a

Question

Hello wave I m experimenting a bit with compose navigation and was wondering if I could get some insight on something before I try reinventing the wheel or doing hacky workarounds Will reply in thread with more detail

OG · Answer

Right now I have a barebones Activity which only hosts composables The root composable is a scaffold with three main tabs in the Bottom navigation bar Home | Feed | Profile Let s say you tap a card in the feed tab it should go to a FeedDetailsPage This details page should be full screen that is it shouldn t be displayed on top of the bottom navigation bar replacing the composable for that tab it should go to a new full screen composable I don t see how I can easily push up the NavController further up I don t think adding logic for the bottom bar to show hide based on current destination is the way to go either since the bar will jump and it s ugly ux xp and I don t think creating separate graphs with different nav controllers is probably right either Nested graph won t work either since that would require everything being inside the scaffold which again means the details page would have to be rendered above the tabs or I hide the tabs based on destination state which causes the bad animation I mentioned already Any other ideas Maybe I m missing something

OG · Answer

Maybe everything goes inside a top level Box that is full screen And the NavController and NavGraph is defined at this level and I have two composable nodes one which is a composable that has a scaffold and then has it s own NavGraph with the three tab composables and one for the details page

Jason Ankers · Answer

The current recommendation is to treat bottom bars as global widgets and toggle the visibility based on destination Nested nav hosts fix the animation problem when you animate between screens with without scaffold <https github com google accompanist issues 729 issuecomment 969930181|but it s not recommended> It would still be good to hear some reasoning around why the compose navigation library deliberately disallows composition at the graph level

Libor Bicanovsky · Answer

You can use dialog instead of composable inside your navhost to make it appear above everything <https developer android com jetpack androidx releases navigation 2 4 0 alpha04|https developer android com jetpack androidx releases navigation 2 4 0 alpha04>

OG · Answer

Thanks for the two threads It seems for the time being using the dialog with full screen modifier and solid background may be the only way to achieve this The GitHub issue describes exactly my problem and so it seems wrapping composables in a nav graph with a shared element is not possible yet so no easy way to deal with that jumping animation of the bottom bar when navigating to a full screen composable

Ian Lake · Answer

What do you mean by a jumping animation The only reason an animation would instantly jump cut is because you ve specifically avoided using any of the Compose animation APIs available such as AnimatedVisibility on your bottom bar

Ian Lake · Answer

If you want to animate out your bottom bar when you go to a full screen destination and coordinate that animation to happen only after the AnimatedContent transition of the content of each screen finishes that has been supported for some time <https github com google accompanist issues 633 issuecomment 942988181|https github com google accompanist issues 633 issuecomment 942988181>

Ian Lake · Answer

The issue linked above is really pointing to the underlying issue the lack of shared elements in Compose at all particularly in the case of APIs like AnimatedContent which AnimatedNavHost is just a wrapper around That s not a Navigation limitation but a level deeper below Navigation that needs to be implemented first

Ian Lake · Answer

Thankfully the Navigation team and Animation teams are perfectly in sync with how important this use case is which is why shared elements have been on the Compose roadmap since it was first published That means that we re actively talking through the shared element APIs and how they could be exposed via Accompanist Navigation Animation as soon as they become available

Ian Lake · Answer

So there certainly are UX patterns where you literally don t have the tools needed as of yet That s a gap we need to fix but we re going to fix it the right way and ensure that things like shared elements aren t just an afterthought at the Navigation level but a fundamental part of your toolkit that you can use at any level of your app Navigation included

OG · Answer

< Ian Lake> thanks for the detail explanation and all that info I took a look at your response to that link and how the new `visibleEntries` API is helpful By jump animation what I meant was without this new API you pointed out you could hide the bottom bar based on the current navigation route from the existing `currentBackStackEntryAsState ` So if A B C were composables that were shown for a respective bottom navigation tab and F was a fullscreen composable then only after F was rendered would the bottom navigation disappear and then F would recompose remeasure to fill the space the bottom bar was previously taking Now with your example in that GitHub thread with `visibleEntries` it seems once F completed it s enter animation you could then animate out the bottom bar using Animated visibility but the jump would still happen I think Because F would then recompose to fill the space previously occupied by the bottom bar giving this jump effect my poor choice of naming here haha Unless if I am understanding correctly I could use `visibleEntries ` And animate away the bottom bar as soon as I know A B or C is beginning to exit and F is beginning to enter

Ian Lake · Answer

The default transitions set on `AnimatedVisilbility` include `shrinkOut` which would smoothly animate the bar out and smoothly resize the content You d have to go out of your way to have jump cuts in Compose

Ian Lake · Answer

And it is more about timing if you want your bottom bar to start appearing disappearing as soon as the transitions start `currentBackStackEntryAsState ` is already enough It is only if you want staggered animations i e wait for one to finish before starting the next that you d need the deeper level signal you get from `visibleEntries`

OG · Answer

Nice ok I think that covers everything then Thanks again < Ian Lake>