With this change that landed yesterday (<https://a...

# compose

[Zach Klippenstein (he/him) [MOD]]

With this change that landed yesterday (https://android-review.googlesource.com/c/platform/frameworks/support/+/1369437), it looks like the API for entering Compose from classic Android Views is moving away from setContent extension functions to the dedicated AbstractComposeView and ComposeView classes. Is the ViewGroup.setContent extension potentially going away as well? If so, will there still be a way to pass `CompositionReference`s to compositions hosted inside android views? (This issue: https://issuetracker.google.com/issues/156527485)

[Leland Richardson [G]]

It changes slightly. It means you would have to first insert an AbstractComposeView, and then setContent on it

[Leland Richardson [G]]

ViewGroup.setContent is going to go away and yhou will have AbstractComposeView.setContent

[Leland Richardson [G]]

in order to have all view subsystems work properly we have to have a view in between to handle some things properly, so the AbstractComposeView is always going to end up in the hierarchy, but we didn’t want to insert it on your behalf

[Zach Klippenstein (he/him) [MOD]]

Ok, that’s what I expected. The other part of my question was, will there still be a way to pass `CompositionReference`s in to link other compositions with this new API?

[Leland Richardson [G]]

it might take a different shape but yes

[Adam Powell]

Can you describe a little more about your use case? Part of what we're trying to do here is tighten up the ordering requirements of getting a composition up and running and also keep the lifetimes and scopes of everything easy to reason about. Would it be sufficient to have a subcomposition view with additional restrictions, perhaps that it might not be compatible with a LayoutInflater and would have to be constructed with the parent CompositionReference?

[Zach Klippenstein (he/him) [MOD]]

Would it be sufficient to have a subcomposition view

Curious what this API would look like, but I think so.

it might not be compatible with a LayoutInflater and would have to be constructed with the parent CompositionReference

Do you mean that it would not be inflatable (must be instantiated in java/kotlin code), and that you would need to pass a CompositionReference in order to instantiate (e.g. through constructor or a factory function)? That would work for my use case perfectly, assuming that child views of this view would still be able to inflate other views.

So e.g. something like this?

class SubcompositionView(
  context: Context, …,
  parentReference: CompositionReference
): AbstractComposeView(context, …) {

  fun setContent(content: @Composable () -> Unit) {
    // Set my content to content as a child of parentReference.
  }
}

[Zach Klippenstein (he/him) [MOD]]

My use case is mostly explained in that issue (https://issuetracker.google.com/issues/156527485), basically I’ve got a map of keys to View factories, and a special View type that can be used be used to lookup a factory from the map, instantiate it, and display it. I want to be able to write a view factory that defines its content as a Composable, and can display its own nested views from the map, but any nested views that are also defined as Composables should be linked as subcompositions from the parent. Not sure if that makes it any clearer.

Here’s my actual current implementation: https://github.com/square/workflow-kotlin-compose/blob/a4636fc4c740f90e34690775b67475ab4bb89905/core-compose/src/main/java/com/squareup/workflow/ui/compose/ComposeViewFactory.kt#L123-L137 (ViewEnvironment here is a concept that is basically the same thing as an Ambient map).

[Adam Powell]

yeah probably something like that. It wouldn't necessarily be an AbstractComposeView in this case.

[Adam Powell]

at a minimum we'd find this useful ourselves for things like popup and dialog content

[Zach Klippenstein (he/him) [MOD]]

Yea, I'm basically doing the same thing as those using reflection to get at private APIs now. I believe the API has been made public since, but I haven't had a chance to upgrade this library yet.