Skip to content

Auto-create traces for MAUI UI events #5116

@jamescrosswell

Description

@jamescrosswell

Description

Part of: NET-647

Follow-up for: #5111

#5111 only added traces for navigation events. This issue would be to follow up with traces for things like click and scroll events.

Android implementation

The Android implementation is conceptually straight forward:

  • GestureDetector.onSingleTapUp / onUp fire with the touched View
  • Get the resource name from Resources.getResourceEntryName(view.id)
  • Transaction name = ActivityName.viewId, op = ui.action.click / ui.action.scroll

Challenges in MAUI

No unified gesture callback - Android has a single GestureDetector sitting below all views. MAUI uses GestureRecognizer instances attached per-element (TapGestureRecognizer, PanGestureRecognizer, etc.). There's already an IMauiElementEventBinder infrastructure for this, but the gesture binder tests are all platform-skipped — meaning the gesture binders don't currently work in unit tests, which makes TDD harder.

No guaranteed view ID - Android has integer resource IDs → string names. MAUI has AutomationId and StyleId, which are optional and frequently unset. We'd need fallback logic (AutomationId → StyleId → type name), and the "no view ID, skip the transaction" scenario (currently marked N/A) becomes a real requirement we'd need to implement and warn about.

No ambient "current screen" name - Android reads activity.getClass().getSimpleName(). In MAUI, from inside a gesture event handler on an arbitrary element, getting the current page/route name requires either passing it as context or querying Shell.Current (which isn't always available and is a static dependency).

ScrollView vs gesture scroll - Android intercepts raw scroll gestures. MAUI's ScrollView.Scrolled fires after content scrolls, not at the gesture level. The semantics are similar enough but the plumbing is different.

Also the "ongoing screen load transaction — don't bind new UI event transaction to scope" scenario, would need to be implemented.

References

Essentially we'd need to implement something like what's covered in getsentry/sentry-java#1975 in these tests:

  • sentry-android-core/src/test/java/io/sentry/android/core/internal/gestures/SentryGestureListenerScrollTest.kt
  • sentry-android-core/src/test/java/io/sentry/android/core/internal/gestures/SentryGestureListenerClickTest.kt

Metadata

Metadata

Labels

.NETPull requests that update .net codeFeatureNew feature or requestSpans
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions