A modern programming language that makes developers happier.

kotlinlang

Why do need to call `setContent(Recomposer.current()) {}` in fragments? and if we must pass a Recomposer as a parameter, in which scenario would I need to pass another Recomposer? say `setContent(Recomposer.new()){}` . If not, why is `Recomposer.current()` not a default parameter value in `setContent`?

It's part of moving away from `Recomposer.current()` altogether and reworking a bit of how creating a composition works in general. `Recomposer.current()` will be deprecated sometime in the future.

We're probably going to remove the `ViewGroup.setContent` extension altogether in favor of some sort of public `AbstractComposeView` that accepts a composable function as a required constructor parameter

Since the current extension has to create one anyway, and today it's just an added layer of view hierarchy

That will pave the way for both a concrete `ComposeView` that would have a public `setContent` function, plus it could be a subclass for generated view subclasses from single composables

And we can do the recomposer wire-up a bit differently there

More concretely though, `Recomposer.current()` is thread-specific, and binding to the current thread by default has been a source of issues in other Android APIs over the years. Being explicit is better here. However when you're talking about the Activity extension, Activity UI always is bound to the ActivityThread - the main thread.

And when it comes to the future view APIs mentioned above, we can do some more contextual recomposer autodiscovery

Thanks for the perfect elaborations you gave. And that makes sense a lot. In a nutshell, how is the API `AbstractComposeView` going to look like?

```class MyView : AbstractComposeView({
   // . . . composables here
})```

Might be closer to something like
```class MyView @JvmOverloads constructor(
  context: Context,
  attrs: AttributeSet? = null
) : AbstractComposeView(context, attrs) {
  @Composable
  override fun Content() {
    // ...
  }
}```
