Hi <@UJBPFB3SN>, In the example nav3 recipes for ...

# compose-android

[Archie]

Hi @Ian Lake,

In the example nav3 recipes for common ui, defines the bottom navigation on the top level scaffold outside of the NavDisplay . Am I wrong to think that common ui could be defined inside custom scenes instead?

Or is it better to defined the common ui on each destination and do SharedElementTransition on destination switching?

Whats the correct approach for this case? Thanks in advance.

[Vilgot Fredenberg]

You can use movableContentOf and shared elements transitions to persist components between scenes, while still defining them per scene. https://www.tunjid.com/articles/ui-layer-architecture-for-persistent-ui-elements-68248e8ecc8e85f53ce1aa46 is often cited for this

[Vilgot Fredenberg]

Things becomes more complicated when using scenes with multiple entries, however, since you'd then have to place the navigation component in the scene. I've not found a good solution for this yet (it seems like you have to fork SinglePaneScene and ThreePaneScaffoldScene)

[Ian Lake]

One of the features we are looking into for the Nav3 1.1 release is "Scene decorators", which feel like it'll be perfect for these kind of use cases and avoid the need to write custom scenes unless that's actually what you need

[Archie]

@Ian Lake one thing i found with moving common ui to a scene, is that business logic tied to a specific screen now has to move outside of the local screen to the scene layer.

For example, say if a screen needs to check the current screen state before confirming navigation. Because common ui is defined outside the actual screen, it doesn't have a hold of the actual screen state. I'd have to figure out a way to connect the common ui to whatever the current screen is.

Meanwhile, when I instead define each common ui in each screen, and fake the "persistence" with shared element transition, the business logic becomes local to each screen, but now common ui is tied to a per screen level and is now trickier to handle changing common ui navigation across different screen sizes.

I am not familiar with Scene Decorators yet but I'm wondering if it solves these issues?

[Ian Lake]

If you look at how entry decorators work, the decorator wraps the entry's content, which means that tools like composition locals give you a communication channel between the decorator and the entry. This same thing would apply to a scene decorator and all of the entries within a scene

[Archie]

Alright thanks @Ian Lake I'll check it out.

[Archie]

@Ian Lake just to clarify, using scenes is still the preferred/suggested way here right? (Instead of faking persistence through shared element transition.)

[Ian Lake]

What you really need to think about is what happens when you are on a large screen device e.g., when two screens are side by side. A Scene Decorator would exist outside of both individual screens so a Toolbar would span the whole space, rather than being constrained on one side

[Ian Lake]

having both screens both display a separate bottom nav doesn't sound right 🙂

[Archie]

I think I'm confusing Scene strategy with Entry Decorator. I should look at how Entry Decorators work not Scene Strategy.

[Archie]

@Ian Lake Tried implemention solution through NavEntryDecorator and found that since decorate gets called on each NavEntry, each nav entry has its own "decorate" composable. Making the common ui not really common across destinations but different instances across destinations.

I was wondering if the upcoming "scene decorator" will act the same or whether they will truly be common ui across screens.

[Ian Lake]

...yes, scene decorators will decorate Scenes, not entries. That's kind of the whole reason we want to build them for Nav3 1.1 - because they fill a gap that you can't fill with the existing APIs

[Archie]

I see. I’m looking forward to it. Nav3 has been really good. Really looking forward toward the upcoming features.