We've had a lot of crashes coming from this library on Android 11 and vivo devices:

Caused by: java.lang.NoSuchFieldException: No field mKeyedTags in class Landroid/view/View; (declaration of 'android.view.View' appears in /system/framework/framework.jar!classes3.dex)
	at java.lang.Class.getDeclaredField(Class.java)
	at radiography.internal.ComposeViewsKt.<clinit>(ComposeViewsKt.java:14)
	at radiography.internal.ComposeViewsKt.isComposeAvailable(ComposeViewsKt.java:0)
	at radiography.ViewStateRenderers.<clinit>(ViewStateRenderers.java:58)

The offending usage is:

ImmutableList<ViewStateRenderer> renderers =
    ImmutableList.of(
        ViewStateRenderers.ViewRenderer,
        ViewStateRenderers.textViewRenderer(true, 128),
        ViewStateRenderers.CheckableRenderer);

Can you please advise how to handle this?

Based on #70.

• Makes the standard text value renderer also render compose text, so there's only one place to configure text rendering.
• Merges LayoutIdRenderer into ComposeViewRenderer, since layoutId can be on any Composable and there's no reason to have it separate.
• Renames the parameters to textViewRenderer to be more concise.

Fixes #62.

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.

After the updates to the android-emulator-runner to run on 2 cores. It looks like the tests are running well on API 30: https://github.com/AfzalivE/radiography/pull/1/checks?check_run_id=2040687033

API 23 timed out in that run but 30 went well.

These are failing on main, as well as on the last two PRs. Doesn't seem to be related to a code change.

radiography.test.RadiographyUiTest > when_showDialog_then_hierarchyHasTwoWindows[test(AVD) - 11] FAILED 
	expected to be true
	at radiography.test.RadiographyUiTest.waitForFocus(RadiographyUiTest.kt:142)

radiography.test.RadiographyUiTest > when_onlyFocusedWindow_then_hierarchyHasOnlyDialog[test(AVD) - 11] FAILED 
	expected to be true
	at radiography.test.RadiographyUiTest.waitForFocus(RadiographyUiTest.kt:142)

I think testTag is better-suited for this purpose, layoutId is really only meant for communicating with a particular custom parent layout. But I used the implementation for a new example in the README of how to write a custom filter.

This was initially done in #45, but then was reverted in #51 to support older consumers for now. We will probably upgrade to 1.4 after the 2.0.0 release.

This reverts the changes to stdlib call sites made in 0a0f4d266537f8bdc78fa94cc4f9166a790d2376.

This change ensures the library is still consumable from projects built with kotlin 1.3.

Some discussion on Kotlin Slack about this, using Kt 1.4 with apiVersion = "1.3" isn't enough, and using Kt 1.3 setting languageLevel = "1.4" won't work either.

It is said in README that the project has Jetpack Compose support as well. But the subtitle limits the scope to Android View. It gives wrong impression that it only works with the View system of Android.

This change allows filters to be written which not only exclude certain subtrees, but also which only include certain subtrees.

It has three parts:

1. Change ViewFilter's matches method to return a three-value type instead of a boolean, where the third value means don't include this view, but include its children.
2. Give ComposeLayoutInfo a pointer to its parent.
3. Write a filter for compose that returns "include only children" for all nodes that don't have a parent which matches a certain test tag.

Open questions

• [ ] Is the new ViewFilter API acceptable?
• [ ] Should viewFilterFor still accept a boolean lambda instead of all 3 values, since the third value is likely not needed by most filters and it would allow more readable single-expression filters.
• [ ] Is searching up the tree on every node an acceptable cost?
• [ ] This approach requires the filter to be aware of all types that are visitable - a composable nested in an Android view nested inside a composable would also need to walk up the inner View hierarchy so that it included the complete subtrees. Would a better approach to make the filter stateful, so it could set an internal flag while visiting children that match? This would also be more efficient, since it wouldn't need to walk up the parent chain for every node. However it requires a slightly bigger change to the filter API.

One way to solve the last point would be to pass an arbitrary value down the filter chain:

fun interface ViewFilter<S> {
  fun matches(view: Any, filterState: S): Pair<FilterResult, S>
}

fun startFromTestTag(testTag: String): ViewFilter =
  viewFilterFor<ComposeLayoutInfo> { layoutInfo, alreadyMatched ->
    if (alreadyMatched || (testTag in testTags)) {
      Pair(INCLUDE, true)
    } else {
      Pair(INCLUDE_ONLY_CHILDREN, false)
    }
  }

We could also then provide two versions of viewFilterFor, a simple one (no filter state, boolean return) and a complete one (same signature as the above method). One issue with this is that the returned filter state value would be ignored if the result is EXCLUDE, so a sealed class might be better for the result than an enum at that point:

sealed class FilterResult<out S> {
  class Include<S>(val filterState: S) : FilterResult<S>()
  class IncludeOnlyChildren<S>(val filterState: S) : FilterResult<S>()
  object Exclude : FilterResult<Nothing>()
}

Fixes #58.

They should "match" non-View nodes, and only filter when the node is actually a View. This behavior is never exercised right now, but would cause any of the existing filters to filter out all compose nodes when compose support is added.

The scanning implementation is making decisions on threading that aren't optimal:

1. It scans for view roots from the calling thread
2. But then it always performs the scanning of each hierarchy from the main thread (but only if they're Android views). There's one post to the main thread per Android root view and each gets 5 seconds for the traversal, so if the main thread is blocked and we have N windows we could wait N * 5 seconds.

This change moves these decisions around threading behavior to the callers, with a default provided configuration that matches the previous behavior, except there is a single post and the root scanning is done as part of it.

Both the README and sample app (XML layouts) says the Filter should use it to match the view:

viewFilter = { it !is LinearLayout }

Or this doesn't work, it being an AndroidView. it.view must be used instead:

viewFilter = { (it as ScannableView.AndroidView).view !is LinearLayout }

Hello,

I was wondering if this lib could eventually be used for something very similar to Snapshot testing?
Very similar to Shot, but instead of screenshots with a textual output?

Feel free to close if this is completely out of scope.

Thanks in advance

Many compose Modifiers explicitly describe themselves and their parameters in a human-readable way for the AndroidStudio LayoutInspector via InspectorInfo. This would probably be useful data to show in Radiography outputs.

This introduces a new module, slot-table-inspector, which provides two composable functions for peeking under the Compose hood to look at the slot table. They can be used like this:

@Composable fun App() {
  val inspectorState = remember { SlotTableInspectorState() }
  var showInspector by remember { mutableStateOf(false) }

  // This defines the content to inspect (roughly).
  SlotTableInspectable(inspectorState) {
    Column {
      Button(onClick = {
        inspectorState.captureSlotTables()
        showInspector = true
      }) {
        Text("Inspect")
      }
    }
  }

  if (showInspector) {
    Dialog {
      // This reads the slot tables from all SlotTableInspectables and displays them.
      SlotTableInspector(inspectorState)
    }
  }
}

This change also adds it into the sample app. To play with it, just check out this branch and run the Compose sample app! (It works best on a tablet.)

https://user-images.githubusercontent.com/101754/129277048-52f46ffb-ca3b-403e-8546-3dbae1764aa3.mp4

https://user-images.githubusercontent.com/101754/129277637-115bb98e-1922-492c-ad8b-682d1bb643c3.mp4

TODO

• [ ] Write some UI tests.
• [ ] Better name for the module/artifact than slot-table-inspector?
• [ ] Naming of composable functions?
• [ ] Package of stuff in new module?
• [ ] Make the stuff in the new module experimental/opt-in.
• [ ] Add a section to the repo README about this API.

Note: there's more work to make this not Android dependent. Notably refs to the WindowManager which likely belong to displayName for Views instead (?)