I work on an app that has a feature in debug build...

# compose

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

I work on an app that has a feature in debug builds where we dump the entire view hierarchy of the main window in certain cases, e.g. for crash reports or manually via a special debug menu. This can be really helpful for figuring out the state of the UI when things go wrong. Is it possible to do this with Compose? What would that look like? One option would be to walk the semantics tree, although I’m not sure that would contain enough information for debugging the UI itself. Another option would be getting access to the root LayoutNode and walking the node tree, but many Composables just wrap other Composables and don’t have their own `LayoutNode`s, modifiers are often contributed from multiple composables for a single node, etc, so that’s not ideal either.

I’ve seen some work being done for Android Studio tooling around extracting some data about stuff like this by inspecting the slot table directly. Would it be reasonable to request a public API for exposing that parsing in debug builds?

[Vinay Gaba]

I’ve been thinking about a really similar use case where I need more information about the hierarchy and I strongly agree that we need a way to have that information available. +100 to this!

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

In dev16, the tooling module has an asTree() extension method on SlotTable, and this seems to return more than enough information for this kind of use case.

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

If view attribute inspection is enabled in dev tools, it even includes source locations for all the calls.

[Vinay Gaba]

this is amazing 🙏🏼

[Andrew Neal]

Yeah, man. Really nice.

[jim]

If this is intended for debug only, what is the problem with reflection?

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

Only that it's harder to maintain since it doesn't fail with compiler errors, and private APIs are more likely to change without documentation. I would totally be fine using reflection to solve this it would just be more work, and a small public API would be nice to have if possible.

[jim]

Ok, makes sense, worth considering. We generally like to provide APIs for anything we do ourselves, but this situation has some interesting considerations. We would not want such an API to be available outside of extenuating circumstances (like debug mode). If it's a real API, we would need to consider API stability, and I'm not sure if we want to officially support such an API, and we certainly don't want to give the API any sort of credibility as being a reasonable way of doing something in a production app. So it requires some thinking on our end.

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

I can file a feature request if it’s helpful to track this. I don’t have any more specific ideas at this point either, but wanted to get it on your radar.

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

A couple things that could be immediately useful here:

1. A way to turn on “source information” programmatically (ideally temporarily) for a composition that doesn’t involve connecting the Layout Inspector or turning on Debug View Attributes in dev options. This seems like something that would only be available in debug builds, so might not help for debugging production crashes, but could be helpful for local development.

2. Some way to identify data from common foundational things like remember in the output from SlotTable.asTree(), besides just matching the group name, which seems pretty brittle (any function could call itself “remember”). Maybe this is an XY question – the reason this could be helpful is that it could serve as a simple heuristic for data that might represent state that the developer cares about and would want to see in a dump of the current composition. Still playing around with other ways to guess this stuff and try to prevent a slightly-less-overwhelming view of the composition, so hoping I’ll find another way to do this.