Closed mrehan27 closed 8 months ago
Attention: 105 lines
in your changes are missing coverage. Please review.
Comparison is base (
c494bb0
) 49.76% compared to head (2032b89
) 53.59%. Report is 23 commits behind head on main.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Build available to test
Version: rehan-push-click-behavior-SNAPSHOT
Repository: https://s01.oss.sonatype.org/content/repositories/snapshots/
@levibostian Yes the change prevents new activity from being tracked by CIO auto-screen tracking. The PR does exactly what is described in the task breakdown. Current approach is much better than solutions like hard-coding filters. And even if it adds a feature, it does without breaking existing functionality and requires minimal effort on our part. I don’t see any reason for not continuing with it. If you have any suggestions for improvement or see any issues with this approach, feel free to mention them. Otherwise, let’s continue the discussion in the parent ticket or on Slack.
I am open to a solution such as this one where an interface is used to determine if a screen should be tracked or not.
My hesitations come up from:
TrackableScreen
in the sample apps. If we are to begin using TrackableScreen
in the sample apps, that makes me think we are suggesting it as our recommended approach to doing automatic screenview tracking in the SDK. Especially with the use of getScreenName()
where we are returning different values for certain fragments, TrackableScreen
seems as though it's trying to fix an unrelated problem to push click behavior. I suggest we introduce a new feature such as this with a new ticket and new PR. TrackableScreen
makes it seem as though you need to use it in order for a screen to be tracked. A customer might ask, "If you do not inherit TrackableScreen
, will my screen still be tracked?". We can discuss naming if this feature is turned into a new ticket with new PR. I have an idea to suggest. Would it work for a refactor to the PR where TrackableScreen
is renamed to DoNotTrackScreen
and the interface is internal
or undocumented? If it's an interface that is currently only used internally (not used in sample apps), I would be OK with this. Then, we can expose this interface to the public and make it a documented feature in the future if we believe it's important to add.
Update: I find the rename to DoNotTrackScreen
to be optional. As long as the interface is internal and removed from sample app use, I would be OK with the solution. I do agree, I find an interface to be better then a hard-coded list of Activities.
@levibostian I actually started implementing this with DoNotTrackScreen
but ended up on TrackableScreen
. Because I think the number of changes are almost same but TrackableScreen
is more flexible. I'm okay with removing it from sample apps though if we have more votes on it.
For the interface, I don't think this can be confusing for customers because we are not yet going to add this in docs. If the customers find out the interface themselves, the doc on it already explains it is fully optional. We can discuss any improvements in docs or name on the file, if you have any ideas in my mind, please post it on TrackableScreen
so it is easier to discuss in thread.
In general, I believe that code should not be added to a sample app unless it's a public facing feature that is fully documented.
Therefore, I would approve of the PR if TrackableScreen
was internal (either in scope or a comment on it specifying that it's currently only used internally) and all references to it were removed from the sample apps.
As you have mentioned, I agree that if we do decide to make this a public feature add in the the future, naming and improvements could be discussed at that time. For internal use, this looks good to me.
helps: https://github.com/customerio/issues/issues/10830
Changes
TrackableScreen
interface to provide screen name for auto screen trackingTrackableScreen
in Java samplePending Items
Note
This is base PR for improving push click behavior. Changes planned in this PR directly are final, but will be kept in draft till the feature is complete. Further changes for the feature will be merged through more PRs into this branch and then released after final testing.