RUMM-3500 View tracking gap#1578
Conversation
ef3a127 to
27a7901
Compare
|
|
||
| if (event is RumRawEvent.StartView && !stopped) { | ||
| startForegroundView(event, writer) | ||
| lastStoppedViewTime?.let { |
There was a problem hiding this comment.
Won't this be triggered every time there is a gap between a stopView and startView on a manual instrumentation?
That would hinder our ability to properly assess if this gap is closed in automatic tracking strategies.
Seems like this telemetry should be moved closer to the automatic strategies so it's not influenced by manual calls to the API.
There was a problem hiding this comment.
This would indeed, but the tracking strategy and view scope are completely independent from one another. If we were to move this detection in the view tracking strategy itself, we'd have to duplicate the logic three times.
We do have the information of the view tracking strategy in the configuration telemetry event, meaning we can exclude orgs using manual tracking if need be to know where the gap is coming from.
There was a problem hiding this comment.
Makes sense.
It would be better if we could do it before sending the telemetry in the first place but detecting if we have an automated view tracking strategy in place here would create unwanted dependencies.
27a7901 to
07777fb
Compare
Codecov Report
@@ Coverage Diff @@
## develop #1578 +/- ##
===========================================
+ Coverage 83.42% 83.50% +0.08%
===========================================
Files 437 437
Lines 14910 14945 +35
Branches 2230 2233 +3
===========================================
+ Hits 12438 12479 +41
+ Misses 1885 1877 -8
- Partials 587 589 +2
|
| currentFragmentExtras(activity) | ||
| ) | ||
| ) | ||
| // expectedEvents.add( |
There was a problem hiding this comment.
This expected events is removed. Apparently the JUnit Runner's callActivityOnStop doesn't properly forward the fragment's onStop() to the fragment lifecycle listeners.
426e347 to
48a80c3
Compare
48a80c3 to
e6890ed
Compare
| // endregion | ||
|
|
||
| companion object { | ||
| private const val STOP_VIEW_DELAY_MS = 200L |
There was a problem hiding this comment.
I see that this constant is defined here but also in other places. Should we unify to a SSOT incase we want to modify the delay later on?
|
|
||
| private companion object { | ||
| private const val REPORT_FRAGMENT_NAME = "androidx.lifecycle.ReportFragment" | ||
| private const val STOP_VIEW_DELAY_MS = 200L |
| // endregion | ||
|
|
||
| internal companion object { | ||
| private const val STOP_VIEW_DELAY_MS = 200L |
5 participants
What does this PR do?
Delay the view stopping event to prevent gaps between views
Motivation
A non zero gap (~100ms) exists when navigating between fragments/activities. This is because a Fragment/Activity's
onResumeis called some time after the previous one'sonPause. This would leave a short period of time during which errors and resources would not be tracked because no Active view was available.Additional Notes
Thoughts about additional implementation of this feature :
Review checklist (to be filled by reviewers)