-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[Reader] reader_accessed event not triggerered when app is resumed #19960
[Reader] reader_accessed event not triggerered when app is resumed #19960
Conversation
📲 You can test the changes from this Pull Request in WordPress by scanning the QR code below to install the corresponding build.
|
📲 You can test the changes from this Pull Request in Jetpack by scanning the QR code below to install the corresponding build.
|
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 found a behavior that I am not 100% sure we want, so I added a comment in the appropriate part of the code.
@@ -1135,7 +1131,7 @@ protected void onResume() { | |||
|
|||
if (mBottomNav != null) { | |||
PageType currentPageType = mBottomNav.getCurrentSelectedPage(); | |||
trackLastVisiblePage(currentPageType, mFirstResume); | |||
trackLastVisiblePage(currentPageType); |
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.
In case we don't want to track on orientation changes, one idea is to keep some flag and add some logic related to saving and restoring instance state. I didn't double check, but these seem to be the Lifecycle callbacks order during orientation change, so we can probably differentiate between:
- Orientation change with app in foreground (
onSaveInstanceState
called beforeonStop
) -> should not track the event again when reaching this line insideonResume
; - App in background and killed by the system to reclaim memory (
onSaveInstanceState
called afteronStop
) -> should track the event again when reaching this line insideonResume
.
But this is just something I thought now, there might be other ways of making sure we track only when we want.
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.
Good catch, thanks
I'm fixing it
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.
Noticed some events that are tracked twice.
When I tap on the Reader Tab the first time
- Tracked: reader_accessed
2024-01-23 09:34:15.463 16331-16331 WordPress-STATS com.jetpack.android.prealpha - Tracked: reader_filter_sheet_item_selected
2024-01-23 09:34:15.518 16331-16331 WordPress-STATS com.jetpack.android.prealpha - Tracked: reader_filter_sheet_item_selected
2024-01-23 09:34:15.810 16331-16331 WordPress-STATS com.jetpack.android.prealpha - Tracked: reader_following_shown
I see 2 distinct reader_filter_sheet_item_selected
events tracked in analytics.
Rotate the device
Every time i rotate the device i see 2 new reader_filter_sheet_item_selected
events, together with deep_link_not_default_handler
event, bumped to analytics.
- Tracked: deep_link_not_default_handler, Properties: {"interceptor_classname":"org.wordpress.android.WPComPostReaderActivity"}
2024-01-23 09:35:42.628 16331-16331 WordPress-STATS com.jetpack.android.prealpha - Tracked: reader_filter_sheet_item_selected
2024-01-23 09:35:42.676 16331-16331 WordPress-STATS com.jetpack.android.prealpha - Tracked: reader_filter_sheet_item_selected
Open the single post details view
The event reader_article_rendered
is tracked multiple times.
- Tracked: reader_post_card_tapped, Properties: {"blog_id":0,"feed_id":35393375,"follow":true,"source":"following"}
2024-01-23 09:40:11.089 16331-16331 WordPress-STATS com.jetpack.android.prealpha - Tracked: app_reviews_significant_event_incremented, Properties: {"source":"opening_reader_post"}
2024-01-23 09:40:11.451 16331-16331 WordPress-STATS com.jetpack.android.prealpha - Tracked: reader_article_opened, Properties: {"follow":true,"feed_id":35393375,"feed_item_id":5086693692,"is_jetpack":false,"site_type":"blog"}
2024-01-23 09:40:11.599 16331-16331 WordPress-STATS com.jetpack.android.prealpha - Tracked: reader_article_rendered, Properties: {"follow":true,"feed_id":35393375,"feed_item_id":5086693692,"is_jetpack":false,"site_type":"blog"}
2024-01-23 09:40:11.623 16331-16331 WordPress-STATS com.jetpack.android.prealpha - Tracked: reader_article_rendered, Properties: {"follow":true,"feed_id":153742481,"feed_item_id":5086695973,"is_jetpack":false,"site_type":"blog"}
Going back to the reader from the Single post details view
I see the event reader_accessed
is tracked again. Not sure we'd like to bump this again here.
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.
Thanks for finding these tracking issues, @daniloercoli
Since they're not related to this PR, I've created a new issue to take care of it.
Generated by 🚫 dangerJS |
Thanks for the review, @thomashorta I've fixed the issue you've mentioned and now the event is not tracked when the screen orientation changes. It's still tracked when the system kills the app and the Activity is recreated (I've tested this using |
Generated by 🚫 Danger |
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.
Thanks for the addition of the "isChangingConfiguration" check, it looks like it works as desired now!
I see @daniloercoli added some other concerns about other Reader analytics events that are being triggered multiple times (#19960 (comment)). I think it would be worth taking a look at them, but as another GH issue/PR, as it is not in the scope of the current PR.
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!
Fixes #19278
To Test:
1 - Install JP and sign in;
2 - Verify the selected tab correct analytics event is tracked:
3 - Send the app to background (e.g. tap home button) and open it again: the event from step 2 should be tracked again (previously this wasn't happening);
4 - Repeat steps 2-3 with the four tabs.
Regression Notes
Potential unintended areas of impact
What I did to test those areas of impact (or what existing automated tests I relied on)
What automated tests I added (or what prevented me from doing so)
Activity
.PR Submission Checklist:
RELEASE-NOTES.txt
if necessary.UI Changes Testing Checklist: