Add new experimental api to customize the currently visible screen name. #857
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.
This adds a new api to the
SplunkRumBuilder
calledsetExperimentalCurrentScreenCustomizer()
. A user can use this to pass a customizer which allows them to take full control over determining the name of the current screen. A new interface calledCurrentlyVisibleScreen
is introduced, to prevent additional use of or coupling to the existing upstreamVisibleScreenTracker
. Additionally, a newSpanProcessor
calledCurrentlyVisibleScreenAttributeSpanProcessor
is added (to replaceScreenAttributesAppender
), which does not couple to theVisibleScreenTracker
but instead uses an instance ofCurrentlyVisibleScreen
.Specifying the "current screen name" can be done thought delegation to the existing/default
CurrentlyVisibleScreen
instance and/or through screen tracking mechanism a user might wish to build.This is an alternate approach to #851 that does not subclass
VisibleScreenTracker
. Instead, it uses the more established OpenTelemetry java pattern of allowing the user to pass a customizer. This customizer is given control of determining the name of the "currently visible screen".This approach is NOT opinionated about specific frameworks (such as Jetpack compose), and there is no built-in tracking of lifecycle for unknown components. The user of this new experimental API is responsible for tracking their own navigation state and determining when a "screen" has changed, and to generate the appropriate events (create, pause, destroy, whatever their framework offers).