session replay: use new apis for screen capture, add support for screenshot capture #93
Conversation
Augustyniak
changed the title
| override fun captureScreenshot() { | ||
| // This implementation is required for the SDK to support screenshot capture on Android. | ||
| // As currently implemented, the function must emit a session replay screenshot log. | ||
| // Without this emission, the SDK is blocked from requesting additional screenshots. |
| processLifecycleOwner.lifecycle.removeObserver(this) | ||
| } | ||
| override fun captureScreen() { | ||
| val skipReplayComposeViews = runtime?.isEnabled(RuntimeFeature.SESSION_REPLAY_COMPOSE) |
There was a problem hiding this comment.
why is runtime nullable? shouldn't it just be passed at construction time
There was a problem hiding this comment.
added a TODO to the property. TL;DR; is that it cannot be nonnullable since runtime can be created only after the Rust logger is created and SessionReplayTarget is one of the arguments of Rust logger creation method call.
There is another TODO for making SessionReplayTarget an argument of Rust logger start method call as opposed to Rust logger creation method call.
There was a problem hiding this comment.
That 2nd TODO seems more relevant now that none of the recurrent loggers are managed at the platform level (resource utilization and now replay). Hopefully we can get to that todo next.
| * @param replayMapperConfiguration Map used to matching third party Android views to Bitdrift view types. | ||
| */ | ||
| data class SessionReplayConfiguration @JvmOverloads constructor( | ||
| val captureIntervalMs: Long = 3000, | ||
| val replayMapperConfiguration: ReplayMapperConfiguration? = null, |
There was a problem hiding this comment.
🤔 apparently this is the only part of the configuration left, which makes the entire nested structure unnecessary complicated. not much to do now but leaving this message for posterity: we should simplify this
There was a problem hiding this comment.
yea, I almost removed it but then realize that we actually depend on the replayMapperConfiguration for some of the customers.
| when (event) { | ||
| Lifecycle.Event.ON_CREATE -> replayModule.create(context) | ||
| Lifecycle.Event.ON_START -> replayModule.start() | ||
| Lifecycle.Event.ON_STOP -> replayModule.stop() |
There was a problem hiding this comment.
where did we land on not capturing replay wireframes when the app is in the background? you just went ahead and removed it?
There was a problem hiding this comment.
I verified that capturing works when you tap home button or tap back button. I would need your help to verify that it works (doesn't crash) when the application launches in the background.
For cases when the app is backgrounded the session replay doesn't see any views and that makes us NOT to emit session replay log so effectively speaking the end behavior is just as it used to be.
Fixes BIT-4005
nullasSessionReplayConfiguration.