-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RUMM-3500 View tracking gap #1578
Conversation
ef3a127
to
27a7901
Compare
@@ -59,6 +61,15 @@ internal class RumViewManagerScope( | |||
|
|||
if (event is RumRawEvent.StartView && !stopped) { | |||
startForegroundView(event, writer) | |||
lastStoppedViewTime?.let { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
|
...oid-rum/src/main/kotlin/com/datadog/android/rum/internal/domain/scope/RumViewManagerScope.kt
Show resolved
Hide resolved
.../main/kotlin/com/datadog/android/rum/internal/tracking/AndroidXFragmentLifecycleCallbacks.kt
Show resolved
Hide resolved
.../main/kotlin/com/datadog/android/rum/internal/tracking/AndroidXFragmentLifecycleCallbacks.kt
Show resolved
Hide resolved
currentFragmentExtras(activity) | ||
) | ||
) | ||
// expectedEvents.add( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
48a80c3
to
e6890ed
Compare
@@ -94,4 +112,8 @@ internal open class AndroidXFragmentLifecycleCallbacks( | |||
} | |||
|
|||
// endregion | |||
|
|||
companion object { | |||
private const val STOP_VIEW_DELAY_MS = 200L |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
@@ -104,6 +117,7 @@ internal class OreoFragmentLifecycleCallbacks( | |||
|
|||
private companion object { | |||
private const val REPORT_FRAGMENT_NAME = "androidx.lifecycle.ReportFragment" | |||
private const val STOP_VIEW_DELAY_MS = 200L |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see previous
@@ -84,4 +99,8 @@ class ActivityViewTrackingStrategy @JvmOverloads constructor( | |||
} | |||
|
|||
// endregion | |||
|
|||
internal companion object { | |||
private const val STOP_VIEW_DELAY_MS = 200L |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see previous
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
onResume
is 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)