Hello :wave: I'm experimenting a bit with compose ...

# compose

[OG]

Hello 👋
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]

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]

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]

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, 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]

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

[OG]

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]

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]

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

[Ian Lake]

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]

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]

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]

@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]

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]

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]

Nice, ok I think that covers everything then. Thanks again @Ian Lake