What kind of "container" renderings do you actually use?

[zoltish]

The concept that workflows can produce any number of renderings that are bound to UI elsewhere is extremely powerful. The possibilities are endless! But what kind of "container" renderings do you actually use?

Personally I only have a few, but use them pretty much everywhere.

• BackHandlerScreen
• BackStackScreen
• KeyedScreen
• LoadingScreen
• MultiPaneScreen

[rjrjr]

That's a pretty similar list to ours, except that we also have an explosion of subclasses of (a fork of) ModalViewContainer. Working now to replace all of those with the new BodyAndOverlaysScreen.

Interesting to see LoadingScreen as a container, we don't do that. What does KeyedScreen do?

[zoltish]

Could you please elaborate on why you have so many subclasses of it? Sounds great to be able to compact them into one thing :)

The loading one is especially awesome as it wraps the content (when available) and transitions to it when it's loaded!

Keyed is my solution to keeping ui state around for a set of screens, I mostly use it for things like bottom tabs. With compose, lists and the like on the different tabs keep their positions, etc.

[rjrjr]

Keyed sounds really interesting, if you're inclined to share it.

Our problem is a combination of the old system's need to subclass ModalViewContainer for every new type of Dialog, plus a need to restrict the area of some modals to ensure they don't cover our tutorial and status bars.

Subclasses:

• PosCardContainer : ModalViewContainer is basically the PanelContainer from the old sample code.
• PosSheetContainer : ModalViewContainer does full screen dialogs.
• BottomSheetContainer : ModalViewContainer uses androidx BottomSheet.
• MortarDialogContainer provides horrible legacy support that I don't want to talk about, scars are too deep.

Today we're shipping stuff like this:

typealias RetailTabNavigationRoot =
  OrientationLockContainerScreen<
    MortarDialogContainerScreen<
      MortarDialogContainerScreen<
        PosBarsContainerScreen<
          PosCardContainerScreen<
            PosBodyAndOverlaysScreen<
              PosSheetContainerScreen<
                PosCardContainerScreen<
                  RetailTabNavigationContainerScreen<Screen>,
                  Screen
                  >,
                Screen
                >,
              Screen
              >,
            Screen
            >
          >
        >
      >
    >

Which we should be able to reduce to this:

typealias RetailTabNavigationRoot =
  OrientationLockContainerScreen<
    PosBodyAndOverlaysScreen<
      PosBarsContainerScreen<
        PosBodyAndOverlaysScreen<
          RetailTabNavigationContainerScreen<Screen>,
          Screen
          >,
        >
      >
    >

Where PosBodyAndOverlaysScreen is mapped to the stock BodyAndOverlaysScreen via ScreenViewFactory.forWrapper.

[zoltish]

Thanks for sharing! That looks like a huge improvement, Ive seen the work being done with overlays but I havent fully appreciated what the goal was .. until now. While its not the same, I had an abundance of panels in an earlier release of my app - on smaller screens they would be fullscreen dialogs, and on larger screens just big dialogs overlaying the content. The idea still seems good, but jesus, I had so many panels inside panels, and then I ran into cyclic dependencies since A would want to show B, which could also show A, and both used the panel approach for each other.

Heres KeyedScreen and my usage of it:

data class KeyedScreen(
    val key: String,
    val content: Any,
)

Which I then render with compose using:

val stateHolder = rememberSaveableStateHolder()

stateHolder.SaveableStateProvider(
    key = screen.key,
    content = {
        Render(screen.content) 
    },
)

[lucamtudor]

@zoltish how has been your experience so far with Workflow & Compose? Are you migrating from a View.java app to Compose or you started fresh?

[zoltish]

@lucamtudor Before I answer, disclaimer: Im not actually using workflow. I use something thats very similar, its basically the same concept, just implemented in a different way. I think my experience would be identical (or better) following workflow.

It has been great, I adopted it before compose was a thing and it was already the best decision I made at the time. When compose came out, I had some select struggles with performance (in the most complex screen of my app, that also changes a lot as you interact with it..). After some tweaks, performance was on point and this (+compose) is by far the best thing Ive discovered during my 10 years of Android development :) Maybe its overkill for simpler apps/scenarios, but once you get how it works, everything changes. Ill use this for everything moving forward.