Hey all, I’m looking for a way to traverse the layout tree at runtime. Something like findById in test tools, does such a thing exist?

Generally it’s best to use

Modifier.testTag

for that sort of thing

It’s more complex unfortunately, I’m needing to create custom “test tags” and then reference them at runtime. We have custom compose components that we want to tag for analytics

Layout inspector uses APIs like`CompositionData`’s

asTree

and

mapTree

methods, you could try that but those are only intended for tooling so i’m not sure how reliable they’ll be for tests

Oh thats what I’m looking for I think, we have the tests worked out, its scanning the tree at runtime for our custom components that I’m stuck on

so at runtime the

CompositionData

stuff might not work at all? I think some of that data is only generated in debug mode, and even then only when a certain flag is set, and it has a huge performance cost

It very well may be the wrong approach I’m newer to this. Im more accustomed to view binding where you reference the id lol

1. How do you generate tags? 2. How do you actually need to consume the tags? E.g. do you have some logic that runs a callback when a tagged view becomes visible, or something else?

Right now, tags will be strings in our composable functions within our library. Not sure which approach is best here but leaning towards a modifier extension function. Needing to pass Library project name, library version and component name all as strings. When that library is used in an application (and analytic calls are triggered) we need to check the screen for our custom components by capturing those tags. We are the first project to create a pure compose library and app at my company

Ok, so you have some external polling mechanism that asks “what tagged views are on screen right now” – correct?

Not yet, but that’s the idea.

So what I would probably do is build a modifier that registers for that signal and uses its LayoutCoordinates to lazily figure out if it’s visible or not and report itself.

Oh ok, then apply that modifier to each component I want to track

exactly

Can I apply that to the component at the library level or would I need to do that in the application that consumes the lib?

Does your library already have some root composable wrapper it expects the app to use? If so, you could put it in there. Otherwise, I would either: 1. Expose

LocalAnalyticsController

and

AnalyticsController

from your library and ask the consuming app to provide an instance however it likes, or 2. Make

LocalAnalyticsController

private, expose

AnalyticsController

, and expose a

@Composable fun AnalyticsControllerProvider(controller: AnalyticsController)

function that your consuming app must use. (1) is simpler, and also allows your library consumers to consume the

LocalAnalyticsController

which may be good (for flexibility) or bad (if you want to control how it’s used).

Beautiful, I’ll give it a go! You mind if I DM you if I get too deep?

go ahead