Providing Activity/Fragment name in the span name
Currently, the ActivityTracer and FragmentTracer tools create spans with only the verb as name, which causes too low cardinality when analyzing the data later on. For example, the screenshot below shows how a span of an Activity creation, followed by 2 fragment creations as children, looks like right now:
Analyzing this data might become more straightforward to do if the name of the Activity/Fragment would appear in the span name, for example:
| Created - MyActivity | ||
|---|---|---|
| Created - Fragment1 | ||
| Created - Fragment2 |
The fragment/activity name should be an attribute on the span though. This is a good candidate for us to solidify as semantic convention, IMO: Span naming for activity/fragment creation.
The fragment/activity name should be an attribute on the span though.
That's ok for me, though it would still be helpful to mention something about it in the span name as well.
This is a good candidate for us to solidify as semantic convention, IMO: Span naming for activity/fragment creation.
Sounds good, I think it might be worth mentioning it in the Client SIG as well.
Something to consider is that the Fragments are obfuscated IIRC (Activities are not), so inferring the name from the class name is suboptimal.
So there should be an approach where the user should be able to overwrite the fragment's name, like a callback that passes the fragment instance as a parameter and returns a string, by default returns the class name, but if the user sets this callback, they can return what they want, they can probably do a when/switch and compare types and return a human-readable name that makes sense.
The other option is to symbolicate the fragment's name on the server, far from ideal for a vendor-agnostic lib.
That's a great point, we definitely need to find alternatives to just getting the class name at runtime.
So there should be an approach where the user should be able to overwrite the fragment's name, like a callback that passes the fragment instance as a parameter and returns a string
Agree, I think we can use Datadog RUM's approach where the user defines Activity/Fragment during initialization.
For example:
val rumConfig = RuntimeConfig.rumConfigBuilder()
.useViewTrackingStrategy(FragmentViewTrackingStrategy(
predicate = object : ComponentPredicate<Fragment> {
override fun accept(component: Fragment): Boolean {
return allowedFragments.contains(component)
}
override fun getViewName(component: Fragment): String? {
when (component) {
is LoginFragment -> "Login Fragment"
is HomeFragment -> "Home Fragment"
else -> "Default Fragment"
}
}
}
))
.build()
Yep, that's exactly what I'd suggest