FEAT: Add version of withSentryObservableEffect that has better inter… #3411
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
📜 Description
This PR adds a version of
NavHostController.withSentryObservableEffect
that accepts aSentryNavigationListener
as a parameter to support better navigation tracing in apps that make use of both Fragments and Compose.💡 Motivation and Context
A challenge with the existing Navigation and Compose Navigation integrations is that, in the testing I've done, they seem to clobber each other. My guess as to why is because each listener will try to register itself as the integration, meaning that you only get one. Additionally, even if the instances didn't clobber each other, navigation history will end up separated between instances, as the Compose version will only have the nav destinations for Compose, whereas the fragment version will only have the destinations for fragments. This makes it hard to put traces back together for apps that make use of both fragments and compose navigation and navigate between the two.
Thankfully, the fix is pretty simple and is implemented here. I added a new version of
withSentryObservableEffect
that accepts aSentryNavigationListener
as a parameter, which allows consumers of the SDK to pass the same version of theSentryNavigationListener to
withSentryObservableEffectwhen using the compose integration as they do to
navController.addOnDestinationChangedListener` when adding the integration for fragment navigation tracing.There is one possible downside to this approach. Specifically, the trace origin will show up as
navigation
for compose navigation instead ofcompose
, but I personally don't see this as an issue.💚 How did you test it?
Tested locally; and we'll likely ship an internal version of this to prod at Maven before this is merged
📝 Checklist
sendDefaultPII
is enabled.🔮 Next steps
needs a review from the Sentry team