Skip to content
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-2355 Add Session Replay lifecycle callbacks #993

Conversation

mariusc83
Copy link
Member

What does this PR do?

In this PR we are adding the Session Replay application lifecycle callbacks which will be controlled from the SessionReplayFeature level through the Public API.
We are also adding the base Recorder - Processor architecture, preparing the steps for the next PR where we're going to capture the screen snapshot and send it to the processor.

Motivation

What inspired you to submit this pull request?

Additional Notes

Anything else we should know when reviewing?

Review checklist (to be filled by reviewers)

  • Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
  • Make sure you discussed the feature or bugfix with the maintaining team in an Issue
  • Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

@mariusc83 mariusc83 self-assigned this Jul 21, 2022
@mariusc83 mariusc83 force-pushed the mconstantin/rumm-2355/create-and-integrate-session-replay-hooks branch from 2a27976 to 19ef3d2 Compare July 21, 2022 14:16
@xgouchet xgouchet added the size-large This PR is large sized label Jul 21, 2022
@mariusc83 mariusc83 force-pushed the mconstantin/rumm-2355/create-and-integrate-session-replay-hooks branch 2 times, most recently from 94205c2 to 6d80acd Compare July 22, 2022 08:13
@mariusc83 mariusc83 marked this pull request as ready for review July 22, 2022 08:17
@mariusc83 mariusc83 requested a review from a team as a code owner July 22, 2022 08:17
Base automatically changed from mconstantin/rumm-2265/create-json-schemas-for-session-replay to feature/session-replay-vo July 22, 2022 08:17
@mariusc83 mariusc83 force-pushed the mconstantin/rumm-2355/create-and-integrate-session-replay-hooks branch from cf87ff5 to 808031a Compare July 22, 2022 09:38
// region Internal

private fun registerCallback(context: Context) {
if (context is Application) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can declare context as Application type directly and avoid this check

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah but it doesn't follow the pattern for all the other features. If we do this it will make sense to change this also for RumFeature, LogsFeature, etc.


// Then
verify(mockSessionReplayLifecycleCallback)
.register(appContext.mockInstance)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we verify unregister here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

damn yes

// Then
countDownLatch.await(5, TimeUnit.SECONDS)
verify(mockSessionReplayLifecycleCallback)
.register(appContext.mockInstance)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems like verification of unregister is missing

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup, copy pasted from the first one :)


// Then
verify(mockSessionReplayLifecycleCallback)
.register(appContext.mockInstance)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also we need to check that unregister was called once.

// When
repeat(3) {
Thread {
testedFeature.stopRecording()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

test says startRecording, but stopRecording is called here

Comment on lines 24 to 25
) : ViewTreeObserver
.OnDrawListener {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
) : ViewTreeObserver
.OnDrawListener {
) : ViewTreeObserver.OnDrawListener {

) : ViewTreeObserver
.OnDrawListener {
private var currentOrientation = Configuration.ORIENTATION_UNDEFINED
private val trackedActivity: WeakReference<Activity> = WeakReference(activity)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we need to use WeakReference if we know activity lifecycle and can just release trackedActivity property when activity goes into a destroyed state?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I know but I want to be better safe than sorry. I want to totally avoid keeping those references and it will not be too costly to just use WeakRefs

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem with weak references is that they can be collected at some point and everything will stop working all of the sudden, recording will just stop, it is very hard to debug such things.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way I know is that they will never be destroyed if they still have a strong reference from somewhere in the process. @xgouchet I really want also your input here, should we keep WeakRefs or just go with direct reference and hope that will never go into trouble.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, I refreshed my knowledge (didn't use WeakReference for a long time) and that is true: they are cleared only when referent is weakly reachable.

So I guess we can keep them. But still, I'm curious why do we need it when we have a complete access to the lifecycle.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, we can debate this, waiting for @xgouchet's opinion also.

Application.ActivityLifecycleCallbacks {

internal var recorder: Recorder = ScreenRecorder(SnapshotProcessor())
internal val resumedActivities: WeakHashMap<Activity, Any?> = WeakHashMap()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why we use WeakHashMap if we can properly control the reference to the activity by listening to the lifecycle?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above

}

@Test
fun `M stop recording all resumed activities W W unregisterAndStopRecorders()`() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
fun `M stop recording all resumed activities W W unregisterAndStopRecorders()`() {
fun `M stop recording all resumed activities W unregisterAndStopRecorders()`() {

Comment on lines 51 to 58
lateinit var mockActivity: Activity
lateinit var mockDecorView: View
lateinit var mockWindow: Window
lateinit var mockResources: Resources
lateinit var configuration: Configuration
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can also use Mock annotation here directly?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Usually I use that but whenever I want to stub a method inside I use mock { }

@codecov-commenter
Copy link

codecov-commenter commented Jul 22, 2022

Codecov Report

Merging #993 (b7158ed) into feature/session-replay-vo (f175f09) will increase coverage by 0.09%.
The diff coverage is 84.34%.

❗ Current head b7158ed differs from pull request most recent head 0ca3a80. Consider uploading reports for the commit 0ca3a80 to get more accurate results

@@                      Coverage Diff                      @@
##           feature/session-replay-vo     #993      +/-   ##
=============================================================
+ Coverage                      82.85%   82.94%   +0.09%     
=============================================================
  Files                            298      306       +8     
  Lines                           9772     9853      +81     
  Branches                        1595     1616      +21     
=============================================================
+ Hits                            8096     8172      +76     
+ Misses                          1194     1184      -10     
- Partials                         482      497      +15     
Impacted Files Coverage Δ
...com/datadog/android/sessionreplay/recorder/Node.kt 0.00% <0.00%> (ø)
...oid/src/main/kotlin/com/datadog/android/Datadog.kt 72.34% <50.00%> (-2.08%) ⬇️
...android/sessionreplay/recorder/SnapshotProducer.kt 50.00% <50.00%> (ø)
.../kotlin/com/datadog/android/v2/core/DatadogCore.kt 65.85% <66.67%> (+1.45%) ⬆️
...g/android/sessionreplay/recorder/ScreenRecorder.kt 84.62% <84.62%> (ø)
...d/sessionreplay/recorder/RecorderOnDrawListener.kt 86.36% <86.36%> (ø)
...id/sessionreplay/SessionReplayLifecycleCallback.kt 92.31% <92.31%> (ø)
...oid/sessionreplay/internal/SessionReplayFeature.kt 96.00% <94.12%> (-4.00%) ⬇️
...droid/sessionreplay/processor/SnapshotProcessor.kt 100.00% <100.00%> (ø)
...m/datadog/android/sessionreplay/recorder/IntExt.kt 100.00% <100.00%> (ø)
... and 8 more

@mariusc83 mariusc83 force-pushed the mconstantin/rumm-2355/create-and-integrate-session-replay-hooks branch 2 times, most recently from 209a40a to b7158ed Compare July 25, 2022 07:06
Copy link
Member

@0xnm 0xnm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm!

@mariusc83 mariusc83 force-pushed the mconstantin/rumm-2355/create-and-integrate-session-replay-hooks branch from b7158ed to 0ca3a80 Compare July 25, 2022 08:34
@mariusc83 mariusc83 merged commit 4e78a34 into feature/session-replay-vo Jul 25, 2022
@mariusc83 mariusc83 deleted the mconstantin/rumm-2355/create-and-integrate-session-replay-hooks branch July 25, 2022 11:39
@xgouchet xgouchet added this to the internal milestone Dec 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
size-large This PR is large sized
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants