wait... i think we can repurpose wrapper for this ...

# compose-destinations

[Suhaib Kazi]

wait... i think we can repurpose wrapper for this use-case
But i might be thinking ahead too much

But im thinking of how i can make the clicks work
For e.g switching between tabs for the bottom bar or the back navigation in topbar

[Suhaib Kazi]

This implementation has the original problem.

I dont want the bottom bar to be visible in the nestedgraphs.

[Suhaib Kazi]

i dont want the Select X Screen wrapper to be visible in the Add Y Screen

[Rafael Costa]

This is not specifically related to compose destinations. That said, that has worked well in the past and what I think the recommended solution is is to have the elements that are common to multiple screens be in a “upper level”. For example having Scaffold wrapping the NavHost and showing or hiding those scaffold elements based on the screen visible at any given moment.
If you make the elements part of the screens, they will animate and flicker when navigation happens.
If the problem you see with this is checking at that top level specific screens, you can probably find some clever way to have the screens themselves decide whether if they want to show those elements or not.

[Suhaib Kazi]

As you mentioned they are flickering when wrapped using wrapper

[Rafael Costa]

Yes because wrapper makes these part of the screen.

[Suhaib Kazi]

Achieving the 'upper level' was easy when i had all the flows in individual activities

[Suhaib Kazi]

Like Home flow activity would be separate to Add Y/Z Screen flow activity which contains many other destinations

[Suhaib Kazi]

The only reason i looked at nesting graphs is because i wanted to pass data to a NavHostGraph starting destination

Only logical solution i could see was nesting the graphs and passing data through NavArgs

[Rafael Costa]

Everything comes with tradeoffs I guess 😅
But being hard is not the reason right? You can have these screens part of different nested graphs, then you just surround the bottom and top bars with if (currentDestination.isOnGraphXYZ) (example). That’s not too hard

[Rafael Costa]

In that case, you could always pass those arguments to whatever is the container of the other NavHostGraph and then make them available to the initial destination via just passing them from the NavHost call, instead of making them navigation arguments, given that the start destination of the NavHost can’t have navigation args (but it can receive “stuff” passed from NavHost, check this: https://composedestinations.rafaelcosta.xyz/v2/arguments/nav-host-parameters)

[Suhaib Kazi]

or just call composable(Destination, XArgs: X)

[Suhaib Kazi]

maybe this works too right?

[Stylianos Gakis]

One thing you can do nowadays if you're ok with some experimental stuff is:
• Keep the state of the bottom bar at a global level above the NavHost, inside a state holding class.
• Have each screen that wants to show the bottom bar receive this state object so it will know what to render, which option is selected, what happens when you click on it etc.
• Make a common composable for that bottom bar which takes in that state holding object
• Make that shared composable use Modifier.sharedElement so that it just stays on screen if you're navigating from one screen which has it to another.
This way you don't need to do any of all this.

[Suhaib Kazi]

I agree with you @Stylianos Gakis
But my use-case currently for that specific bottom-bar is on the home flow only

I'll keep this in mind if the use-cases change.

[Rafael Costa]

@Stylianos Gakis that’s essentially having each screen show their own top or bottom bar but then using it as a shard element so that it doesn’t flicker etc.
Right?

[Rafael Costa]

If so, that could work nicely with the wrappers, probably 🤔

[Suhaib Kazi]

Wrappers are kind of implemented in a way @Stylianos Gakis mentioned
Without the SharedElement part i guess

[Stylianos Gakis]

Don't see why it's a problem if it's only present in the home flow. This works perfectly fine by only being used in a subset of destinations.

And yes, sharedElement plus using a shared state for it saved globally makes this quite easy to work with imo

[Rafael Costa]

Wrappers is just a convenient way to share “logic” or UI in screens. You can call composables that use a shared element modifier.

[Suhaib Kazi]

I was thinking to use ActivityDestinations as a way to potentially pass the data to the flow and keep that activity as a nestedGraph

But again i will loose the 'upper level' privileges for that specific flow as an activity acts as one before the actual Composables

[Ian Lake]

Shared elements is exactly the approach we'll be recommending for these use cases going forward, yep.

You want an element, visible only on a certain subset of screens (e.g., it doesn't make sense for any 'global' layer above to have to know about it) to be shared across multiple screens such that its position/contents don't have the normal transition applied to them. That's a shared element 🙂

[Suhaib Kazi]

That's great.
Share any common UI composable required across a NavGraph
Would be interesting to see how the state handling for those usecases would look like


Also just to get it out there, suppose currently we have a Scaffold for a subset to use for usecases like snackbarhost

As its not part of regular UI composables
How would that translate in the sharedelement way

[Suhaib Kazi]

P.s i do have to mention, i'm yet to dive deep into sharedElement realm.

[Stylianos Gakis]

Yeah they're super interesting, and they truly let you do some amazing things not possible before.

If you're in a rush to implement smth, I'd do it without them atm since as I mentioned they're experimental and are a bit rough around the edges still.

You need to use the latest betas to get some of the current bugs fixed, like this https://issuetracker.google.com/issues/346608857 is only fixed in the latest beta, so if you got a no betas policy you will probably have to wait a bit.

And other bugs like this https://issuetracker.google.com/issues/347520198 which isn't resolved yet so if you're using the predictive back stuff you would have to wait for this too.

[Suhaib Kazi]

This is super helpful @Stylianos Gakis
I'm in a bit of a rush honestly.

That's why i was looking at more stable ways, but I'll definitely try it out at a later stage to see how we can implement this.

As mentioned by Ian, the recommended way is going to be shared elements.

P.s Love the quality of the bug reports, good work.

[Colton Idle]

ooh. if anyone finds any new docs regarding these sharedElement transitions cases that'd be super cool to read about.

I assume https://developer.android.com/develop/ui/compose/navigation#bottom-nav would be something that would be updated if I understand the above conversation correctly. that we would not have a single bottom tab bar anymore. but instead have a bottom tab bar on each of the screens that need it directly, and use sharedelementtransition to make sure it doesn't flicker or anything when switching?

[Ian Lake]

That's the gist of it

[Suhaib Kazi]

@Colton Idle that mentioned,
Implementation wise, conceptually I'd love to be not worried about the elements that are common in a particular graph and just define it once
Rather than having to include it in every screen

[Ian Lake]

That's exactly the wrapper idea above: you write a fun NavGraphBuilder.bottomNavComposable and just use that whenever you want the destination to have a bottom nav and use composable only when you don't want a bottom nav

[Suhaib Kazi]

Makes sense
Would be interesting to see how this will look like using destinations

Also just to get clarity, the wrapper implementation of bottomNavComposable would be using the shared elements right?

[Rafael Costa]

Yes with destinations you can use the wrapper feature for the same effect. You can even create a custom @BottomNavDestination that adds that wrapper and avoid the boilerplate

[Suhaib Kazi]

I did try with the wrapper, and also the custom destination annotation, but (because no shared transition) the flicker occured, so couldn't go ahead with that.

[Rafael Costa]

Yeah it will only work if used alongside the shared element thing.

[Suhaib Kazi]

Any thoughts about integrating shared Transition in destinations? 😂

[Rafael Costa]

What do you mean?

[Rafael Costa]

you can already use them