DataDog
Taps not always associated with the correct fragment
Thanks for taking the time for reporting an issue!
Describe what happened Include any error message or stack trace if available.
I noticed that in the RUM UI, taps are often not associated with the fragment they belong to. I don't see the fragment information being sent for a tap in the sdk, it seems like it might be associated with the most recent 'View Load'? I played around with the code a bit and was able to more reliably determine the correct fragment in handleTapUp like this:
target.findFragment<Fragment>().javaClass.name
Steps to reproduce the issue:
Tap things in the app and then look at RUM
Describe what you expected:
These MaterialCardViews are actually both in InvestHomeFragment:
| Tap | stash-androidstash-android | Tap on Retirement Portfolio on screen com.stash.bottomnav.BottomNavContainerFragment |
|---|---|---|
| Tap | stash-androidstash-android | Tap on Personal Portfolio on screen com.stash.features.invest.portfolio.ui.fragment.InvestHomeFragment |
| -- | -- | -- |
Additional context
- Android OS version: 14
- Device Model: pixel 4 xl
- Datadog SDK version: 1.17.1
- Versions of any other relevant dependencies (OkHttp, …):
- Proguard configuration:
- Gradle Plugins:
Hello @GetsEclectic! Thanks for reporting the issue. Indeed actions are always associated with the current active RUM view, and we are making our best effort to find the element which was tapped.
As far as I understand from the table you've provided both Personal Portfolio and Retirement Portfolio elements are in the com.stash.features.invest.portfolio.ui.fragment.InvestHomeFragment actually (meaning Retirement Portfolio doesn't actually belong to com.stash.bottomnav.BottomNavContainerFragment)? So that the name of the element tapped is correct, but the view ownership is wrong. Do I understand it the right way?
In RUM all the actions are living (=linked) in the scope of the view which was started previously, it is not possible to re-link the action to another view (which may be not even reported to RUM).
In this particular case where multiple fragments can co-exist on the screen it is hard to say which one is the "the most real" one with automated view tracking strategies, so some manual tuning is needed: you can try to provide the custom predicate with the view tracking strategy to filter out fragments which shouldn't be reported as RUM view.
In your particular case I guess com.stash.bottomnav.BottomNavContainerFragment can be filtered out.
Let me know if it works for you.
I can't just filter out BottomNavContainerFragment unfortunately because it does have 4-5 buttons that can be tapped. It looks like calling findFragment() on the target does a better job of attributing it to the correct fragment.
Unfortunately we don't have a way to specify view name in the RUM action tracking API, because it may break the core concepts of RUM: for example the view submitted to startAction call may not be reported to RUM yet, etc. That it why all the RUM actions are reported in the scope of the view which was started earlier (and of course if there are multiple fragments starting at the same time, it may be the case that the last one started is not expected one).
Yeah sounds like it wouldn't be a small change, it might be valuable to be able to supply a 'suggested' fragment which could be overridden? I think it's pretty common that screens contain multiple fragments?
Looking from the high perspective it is indeed not a simple problem to tackle, simply because of the fragment lifecycle: they can be started in the different order and at the different time. We could provide some predicate supplying the list of fragments detected and asking to provide the active one, but then we have to wait for all fragments to become active, which may skew some performance metrics and bring other problems or inconsistencies.
I'll add this problem to the backlog, will see what we can do about it.