Consider creating `interface WorkflowView<RenderingT: Screen>`

[rjrjr]

We could create a facade interface that just wrapped a plain old View. I don't think it's worth the effort. Feature developers basically never bump into this stuff, thanks to WorkflowViewStub and such. That will be even more true when the UI overhaul is done, I think.

But just to scratch the nerdsnipe itch, here's a sketch of what that could be.

fun <RenderingT> ViewRegistry.buildView(...): WorkflowView<RenderingT>

interface WorkflowView<RenderingT> {
  fun asView(): View
  
  fun start()

  val rendering: RenderingT
  val environment: ViewEnvironment

  fun update(
    rendering: RenderingT,
    environment: ViewEnvironment
  )
  // ...
}

fun <RenderingT> View.asWorkflowView(): WorkflowView<T>? {
  // Looks for the tag and confirms the type is right? 
}

Still thinking this would be a distraction, but I'm wavering. Dammit Steve, are you proud that you've done this to me?

Originally posted by @rjrjr in #602 (comment)

[rjrjr]

Oh my. This wouldn't have to be Android specific, or even classic-view specific. And it could require mapping methods that would replace most of the guts of DecorativeViewFactory.

interface WorkflowView<NativeViewT, RenderingT: Screen> {
  fun asView(): NativeViewT

  fun <RenderingT: Screen, RenderingU: Screen> map(
    transform: (RenderingT) -> RenderingU
  ): WorkflowView<NativeViewT, RenderingU>

  fun withEnvironmentMapper(
    updater: (ViewEnvironment) -> ViewEnvironment
  ):  WorkflowView<NativeViewT, RenderingT>
}

Besides providing an implementation where NativeViewT : android.view.View, we could also have something like:

fun interface WorkflowComposable {
  fun @Composable Content()
}

NativeViewT : WorkflowComposable

[rjrjr]

I am definitely not going to take this on as part of #195, or hold UI 1.0 hostage to it. We'll never get rid of the experimental annotation. But this would be a really nice basis for UI 2.0.

[rjrjr]

@steve-the-edwards I couldn't resist this any longer, giving it a try this week (without the NativeViewT bit so far). It seems to clean up a lot of rough edges, but haven't actually turned the key yet.

[rjrjr]

Took a stab at this in #621. It feels great, except that it's hard to preserve the fix for #597.

I think that would be easier and more robust if the transforms were built into ScreenViewFactory itself, and if Screen.buildView were replaced by Screen.getViewFactory. But that requires fixing #594, our broken ViewRegistry API.

I'm already convinced we have to do that. I guess this is the week.

[rjrjr]

Yeah, I don't think this is practical. Adding a wrapper around View instead of extending it directly is just too big a change. The spike was useful, though, inspired some other good ideas.

[rjrjr]

Finally landed a similar cleanup in #703.