Introduce support for rendering Compose hierarchies.

[zach-klippenstein]

Based on #53.

The API could probably use some improvement, but it is very low-impact and all the Compose stuff is completely invisible if you're not using Compose, and automatic if you start using it. Where the View API lets you render and filter Views, the Compose API lets you render Modifiers (including semantics, which is how Compose expresses accessibility and testing metadata), and filter by specific types of metadata: Modifier.testTag and Modifier.layoutId.

The output looks like this:

com.squareup.radiography.sample.compose/com.squareup.radiography.sample.compose.MainActivity:
window-focus:false
 DecorView { 1080×2160px }
 +-LinearLayout { 1080×2028px }
 | +-ViewStub { id:action_mode_bar_stub, GONE, 0×0px }
 | `-FrameLayout { 1080×1962px }
 |   `-FitWindowsLinearLayout { id:action_bar_root, 1080×1962px }
 |     +-ViewStubCompat { id:action_mode_bar_stub, GONE, 0×0px }
 |     `-ContentFrameLayout { id:content, 1080×1962px }
 |       `-AndroidComposeView { 1080×1230px, focused }
 |         `-Providers { 1080×1230px }
 |           `-ComposeSampleApp { 1080×1230px }
 |             +-Text { 462×52px, text-length:24, text:"The…" }
 |             +-Row { 385×67px }
 |             | +-Checkbox { 55×55px, value:"Checked" }
 |             | `-Text { 318×52px, text-length:19, text:"Che…" }
 |             +-TextField { 770×154px }
 |             | +-Box { 152×44px, layout-id:"Label" }
 |             | | `-ProvideTextStyle { 152×44px, text-length:10, text:"Tex…" }
 |             | `-ProvideTextStyle { 682×52px, layout-id:"TextField" }
 |             |   `-BaseTextField { 682×52px, text-length:13, text:"Hel…" }
 |             |     `-Layout { 682×52px }
 |             +-AndroidView {  }
 |             | `-ViewBlockHolder { 160×53px }
 |             |   `-TextView { 160×53px, text-length:9, text:"inc…" }
 |             +-Box { 659×99px, test-tag:"show-rendering" }
 |             | `-Button { 659×99px }
 |             |   `-Providers { 571×55px }
 |             |     `-Text { 571×52px, text-length:28, text:"Sho…" }
 |             `-ScrollableRow { 1222×805px, test-tag:"live-hierarchy" }
 |               `-Text { 1222×805px, text-length:1729, text:"com…" }
 +-View { id:navigationBarBackground, 1080×132px }
 `-View { id:statusBarBackground, 1080×66px }

Added a live-updating view of the hierarchy directly in the sample screen.

[zach-klippenstein]

Just rewrote and simplified all the analysis code, polished up the API and documentation, and added tests. This is ready for review.

[pyricau]

what fresh hell is this? Are you saying that if ComposeLayoutRenderers uses a function defined in ViewStateRenderers, then when loading ViewStateRenderers the classloader may also also load ComposeLayoutRenderers? If yes, something's wrong with the compiler..

[pyricau]

btw, why would initializing this class cause NoClassDefFoundExceptions ? Looks like everything here has if (!isComposeAvailable) NoRenderer

[zach-klippenstein]

My response too. Doesn't happen normally, only happens when the debugger was connected and about to stop at a breakpoint that involved ViewStateRenderers.

The NoClassDef wasn't for compose, it was for this class, because of the circular ref. VSR starts initializing, asks this class for its defaults, this class starts initializing, which calls functions on VSR which require that class to be loaded, but it's already in the process of initializing.

I'm not sure why this wasn't happening unless the debugger was connected. Anyway a better solution might just be to make the VSR.Defaults* fields initialize lazily.

[zach-klippenstein]

Tracked: #59.

[pyricau]

why all the uppercase yelling :) ?

[zach-klippenstein]

Just more consistent with the output for classic views (e.g. GONE).

[pyricau]

what's a use case for using this public API directly? Since we're saying "you probably want scan instead", would be interesting to also mention why you'd want this.

[zach-klippenstein]

Excellent question. The only use case I had for it at all was getting rid of noise from Android views in some of the UI tests. I justified making this public because the SlotTable type is so burried in the Compose API anyway that I doubt anyone would ever even see this. And if they did, they're obviously doing something weird and low-level enough that it might be useful to scan the table directly.

Having said that out loud, the warning in the kdoc seems unnecessary.

[zach-klippenstein]

Another solution to this problem, which would be much more useful for devs, would be the ability to start the scan at some point further down in the tree, similar to passing a non-root View to scan(). However that presents a few (solvable) issues:

1. Composables don't have any implicit identity, so we'd probably need to do something like for filtering and use test tags or layout IDs to identify the root.
2. The visitor infra doesn't currently support filtering nodes above, only below, so that would have to be implemented. This could also make it possible to visit Groups directly instead of using the intermediate LayoutInfo type - I'm not sure we should, since that type lets us decouple a bit from compose APIs that might change a lot, but we'd have the option.

Having thought about this more, that API makes much more sense than this one. I'll take a stab at implementing it, but would like to not block this PR on it since this API is marked as unstable anyway.

[zach-klippenstein]

Tracked: #58.

[zach-klippenstein]

We might eventually end up re-introducing this API, although I'm still for dropping it for now: #61

[zach-klippenstein]

I want to add at least one more thing, although I could do it as a follow-up. We should have integration tests that try use different versions of compose so we can validate that this library doesn't crash when a consumer updates their compose version without updating this library. Just because we can load one or two classes doesn't mean the rest of the classes will be what we expect, and we should degrade gracefully.

Update: Added test and guards in this PR.

[rjrjr]

A lot of missing copyright blocks.

[zach-klippenstein]

We are not adding copyright blocks to new files in this repo. It's not actually required for Apache 2.0, and it's been a huge pain in the ass to keep adding them in Workflow. Anvil isn't doing this either.

[rjrjr]

Can't say I read this as closely as I should, but since it's a WIP anyway…

[zach-klippenstein]

I've got two approvals, and stuff is stacking up on top of this, so I'm going to go ahead and merge. Filed issues for the comments that need follow-up.

[rjrjr]

Whoa! Does that mean I can rip them out of workflow?

…

On Fri, Aug 21, 2020, 5:53 PM Zach Klippenstein ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In radiography/src/main/java/radiography/compose/ComposeLayoutRenderers.kt <#33 (comment)>: > @@ -0,0 +1,132 @@ +package radiography.compose We are not adding copyright blocks to new files in this repo. It's not actually required for Apache 2.0, and it's been a huge pain in the ass to keep adding them in Workflow. Anvil isn't doing this either. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#33 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOMCHNNTKZKSXQUCXAESQLSB4JJVANCNFSM4P33MBJA> .