Open to other features?

[yschimke]

Feature suggestion, feel free to close.

Would it make sense to consider this an entry point to various preview enhacements? There is reusable code for detecting interactive previews.

I'm imagining

• in non interactive mode - default to invisible, or smaller indication of feature availability
• in interactive mode, allow toggling between constraints explorer and other features. Maybe applying dynamic themes? or annotating some components?

These rarely get to the level of justifying a new project. So I'm curious if this will only ever be constraints explorer?

[zach-klippenstein]

Dynamic themes seems like something that would be good to use multipreviews for? Or maybe I'm thinking of something else. I'm not sure what you mean by “annotating some components”.

I was kinda hoping something like this could eventually find its way into Android Studio itself, since it would be nice to have this automatically available for every preview without having to add a library and modify code. Which would also probably be true for many of the things you're thinking of. I think a few AS feature requests could come out of this:

1. Hard-code tools like this into AS one-by-one.
2. Let @Preview annotations specify decorator functions:
   • Allow 3P code to easily decorate their previews without wrapping the actual code.
   • Could also play real well with multipreviews.
   • Could exclude decorators from the other preview features like bounds drawing, code navigation, animation debugging, etc.
   • Decorators could specify their own @PreviewParameters.
3. Provide more access to preview state via composition locals. LocalInspectionMode is just a boolean, but it would be nice to have an authoritative indication that we're in interactive mode, or animation debug mode, etc. so we wouldn't have to use hacks to figure that out.

Back to your request: I'm a bit reluctant to make a single function a grab bag of tools since that raises more UX questions, eg how do you select between them? Solvable but I just whipped this up on a Saturday and didn't really want to invest a lot more time in it than that. Maybe worth releasing a "preview tooling helper" library, but the "trick" for detecting preview interactive mode is just waiting a frame so a library feels a bit much just for that.

Maybe something in the middle could work:

@Composable fun PreviewDecorator(
  vararg decorations: PreviewDecoration,
  content: @Composable () -> Unit
)

fun interface PreviewDecoration {
  @Composable fun Decorate(
    interactive: Boolean, // or maybe no flag, only call decorators in interactive mode
    content: @Composable () -> Unit
  )
}

Then ConstraintsExplorer could be refactored to be a PreviewDecoration and consumers could write their own preview wrapper function that configures the decorations they care about and use it in all their previews. And projects that want to build their own decorations could use the same wiring. Idk, this still feels half-baked to me.