RedwoodView should not have Treehouse lifecycle

[JakeWharton]

This class is meant to provide a frame and integrations to the platform UI toolkit. The Treehouse loading/error stuff should exist entirely at the Treehouse layer and render within the frame–not as part of it.

Related to #1475.

[squarejesse]

I have a plan:

RedwoodView

I’m going to make loading & error screens children of the RedwoodView, rather than states of the RedwoodView:

public interface DynamicContentWidgetFactory<W : Any> {
  public fun Loading(): Widget
  public fun Crashed(throwable: Throwable): Widget
}

I’ll need to create a default implementation that uses an empty widget.

Observing Content State

With the above I still want to notify the host of code reloads and detached content. I’ll do that separately, with a new Content.State sealed class and a new property on Content:

public interface Content {
  public val state: StateFlow<State>

  sealed class State {
    public data object Detached : ContentState()
    public data object Loading : ContentState()
    public data class Attached(val loadCount: Int) : ContentState()
    public data class Crashed(val uncaughtException: Throwable): ContentState()
  }
}

Redundant?

One thing I struggled with was exposing states like Loading two ways: as a child element and as a StateFlow. But I think it’s the best option for giving the application the power to put loading state in the UI or not. We need that power in Cash App!

It should also let us avoid detaching the root view’s children, which is currently super awkward.