feat(android): Add Jetpack Compose automatic UI transaction docs

[markushi]

Add docs for automatic Jetpack Compose transactions.

Related sentry-java PR: getsentry/sentry-java#2390

TODOs

• Await release and make sure the docs use the right min-version

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
sentry-docs	✅ Ready (Inspect)	Visit Preview	Dec 19, 2022 at 7:37AM (UTC)

[imatwawana]

Suggested change

	The UI instrumentation, once enabled, captures transactions for a set of different user interactions, which include clicks, scrolls and swipes. User interaction instrumentation is available for both classic Android Views as well as Jetpack Compose UI.
	The UI instrumentation, once enabled, captures transactions for a set of different user interactions, which include clicks, scrolls and swipes. User interaction instrumentation is available for both classic Android Views as well as the Jetpack Compose UI.

[imatwawana]

I know this is still in draft, but I just made some wording and style fixes.

[romtsn]

Can we also maybe update the Jetpack Compose page? (maybe we could have subsections for navigation and UI events, or just change the wording a bit)

Also, maybe we should update the Basic Options section with the new flags (enableUserInteractionBreadcrumbs and enableUserInteractionTracing), since they live in the core SentryOptions right now?

Otherwise the PR looks good 👍

[philipphofmann]

Using the testTag for monitoring in production seems a bit awkward to me. Maybe we should define our own Modifier?

[markushi]

Good point! @romtsn and I discussed about this as well..testTag() is used for writing Jetpack Compose UI tests to identify an element within the view hierarchy. So the use case is quite similar to ours.
I see two advantages:

• it will work out of the box for any existing Composables
• there's no need for an extra API
• If we would introduce our own modifier, the users would probably end up setting the same value there as well:

Button(
    modifier = Modifier
      .testTag("button_login")
      .sentryTag("button_login") {
    ...
}

But yeah I see your point, it still could be confusing. Maybe let's wait for some user feedback and add our own API if necessary?

[romtsn]

yep - our ultimate goal would also be to automatically generate the transaction name through SAGP (either bytecode manipulation or kotlin compiler plugin), so long-term users will only need this as a fallback in rare cases, so I think it's a good middle-ground

[philipphofmann]

What about using testTag as a fallback if sentryTag is not set? So if you are already using testTag you are fine, because you don't have to set it twice. If you use both, sentryTag wins. Finally, we recommend using sentryTag. I'm also fine with not adding sentryTag in the first iteration. It's always easier to add APIs than to remove them.

[romtsn]

lgtm 🚀 just one thing about the gradle setup. @imatwawana do you want to have another look at the updated docs please?

[imatwawana]

Made some wording tweaks and fixed some formatting stuff (adding line breaks etc).