Description
There is already some code in the compose repo to support running compose in desktop Swing apps (eg). It does not appear that any artifacts for this have been released publicly at the time of writing, but once they are, it would be interesting for this library to support desktop use.
To that end, the main artifact should be split in two: one that contains android-specific pieces (anything to do with View
s) and one that is generic (eg ComposeWorkflow
, WorkflowContainer
).
ViewEnvironment
ViewEnvironment
is ultimately a generic, self-contained concept without Android dependencies, but in practice the API effectively has a hard dependency on Android View
s for safety and convenience since there's no other use case for it in the core library. It might be better for this library to divorce completely from relying on it. Inside a purely Compose app, ambients can solve all the use cases of ViewEnvironment
, so I don't think we even need to design/build a replacement. The bindCompose
lambda would change to just accept a rendering. The downside of this approach for the Android-specific Compose/Workflow integration is that it reverts the very intentional decision to expose The existing ViewEnvironment
explicitly instead of hiding it in an Ambient, but perhaps the benefit of looser coupling to Android APIs is worth the risk.bindCompose
could be built in the Android-specific module if necessary.
That said, if we did want to keep the ViewEnvironment
dependency in the common module, it would depend on https://github.com/square/workflow/issues/1160.
ViewRegistry
It's not clear that a ViewRegistry
concept would even be necessary in a completely Composable app, so it's probably best to not design or build one until it's clear there's a concrete use case.
But just to jot down some thoughts: an independent ComposableFactory<R>
could be a clone of ViewFactory<R>
that has a @Composable render(R)
method instead of buildView()
. bindCompose()
returns a ComposableFactory
. There's a ComposableFactory<R>.asViewFactory(): ViewFactory<R>
that returns ComposableViewFactory
which now implements both ComposableFactory
and ViewFactory
, and fast-path logic in showRendering
looks for ComposeFactory
s instead. ComposeViewFactory
would be responsible for adapting the Android ViewEnvironment
to whatever solution we'd end up going with for the common module (either a generic ViewEnvironment
or something with ambients).