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

Screen event recorded is out of sync if a event is fired right before a screen view event #425

Open
drayan85 opened this issue Mar 1, 2021 · 2 comments
Assignees
Labels
priority:medium On the roadmap. type:defect Bugs or weaknesses. The issue has to contain steps to reproduce.

Comments

@drayan85
Copy link

drayan85 commented Mar 1, 2021

Describe the bug

Especially when an event is triggered right before an activity navigation.

We suspect it is because screen_view event from the track method is collected in an Executor thread.

https://github.com/snowplow/snowplow-android-tracker/blob/1.7.1/snowplow-tracker/src/main/java/com/snowplowanalytics/snowplow/tracker/Tracker.java#L534-L538

However, the tracking of screen_view is not done in the Executor thread.

https://github.com/snowplow/snowplow-android-tracker/blob/1.7.1/snowplow-tracker/src/main/java/com/snowplowanalytics/snowplow/tracker/Tracker.java#L528-L531

So it is possible for the recording of screen_view to be executed first. By the time the previous track method retrieves the screen_view context, it is already out of date.

To Reproduce
Steps to reproduce the behavior or code snippets that produce the issue.

Tracker.TrackerBuilder trackerBuilder = new Tracker.TrackerBuilder(/** **/);
Tracker snowPlowTracker = Tracker.init(trackerBuilder.build());

// In ActivityA.onResume()
ScreenView.Builder<?> screenView = ScreenView.builder()
        .activityClassName("ActivityA")
        .name("ActivityA")
        .build();
snowPlowTracker.track(screenView); // seq 1

// User presses a button to navigate to ActivityB

Structured.Builder<?> builder = Structured.builder()
    .category("navigate")
    .label("ActivityB")
    .build();
snowPlowTracker.track(builder); // seq 2

// Start ActivityB

// In ActivityB.onResume()

ScreenView.Builder<?> screenView = ScreenView.builder()
        .activityClassName("ActivityB")
        .name("ActivityB")
        .build();
snowPlowTracker.track(screenView); // seq 3

Expected behavior

seq event.type screen.activity screen_view.name structEvent.category structEvent.label
1 screen_view ActivityA ActivityA
2 event ActivityA ActivityA navigate ActivityB
3 screen_view ActivityB ActivityB

But what we observed is:

seq event.type screen.activity screen_view.name structEvent.category structEvent.label
1 screen_view ActivityA ActivityA
2 event ActivityB ActivityB navigate ActivityB
3 screen_view ActivityB ActivityB

Notice that seq2 is recorded as if it is triggered from the next screen (ActivityB).

Screenshots
N/A

Device informatoin (please complete the following information):

  • Device: In All Tested Android Devices (Oneplus 6, Pixel 4, Razer)
  • OS: Android9, Android 10, Android 11
  • Version: SnowPlow 1.7.1

Additional context

  • We did not enable screenviewEvents to auto record the screen views (.screenviewEvents(false))
@drayan85 drayan85 added the type:defect Bugs or weaknesses. The issue has to contain steps to reproduce. label Mar 1, 2021
@AlexBenny
Copy link
Contributor

Thanks @drayan85 to raise this issue.
We noticed the problem and planned a fix that would improve all the internal state management of the tracker.
We are close to release the version 2.0 of both iOS and Android trackers.
Just after that we will work on this fix in one of the minor versions we planned.
I don't have a clear ETA at the moment. I'll keep you updated here about further details on that.

@AlexBenny AlexBenny self-assigned this Mar 1, 2021
@AlexBenny AlexBenny added the priority:medium On the roadmap. label Mar 1, 2021
@drayan85
Copy link
Author

drayan85 commented Mar 1, 2021

@AlexBenny, Thanks for your reply and Please update when this fix added to the release so we can update our mobile SDKs respectively.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority:medium On the roadmap. type:defect Bugs or weaknesses. The issue has to contain steps to reproduce.
Projects
None yet
Development

No branches or pull requests

2 participants