-
Notifications
You must be signed in to change notification settings - Fork 235
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
[App Switch] Add analytic events #1111
[App Switch] Add analytic events #1111
Conversation
linkType = if (internalPayPalClient.isAppSwitchEnabled(payPalRequest) && | ||
internalPayPalClient.isPayPalInstalled(context)) { | ||
LinkType.UNIVERSAL | ||
} else { | ||
LinkType.DEEPLINK |
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.
For PayPal in v5 all links are going to be universal/app links - we no longer support deep links
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 think this actually indicates if we fall back to the legacy (CCT) flow or are using the app switch flow
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.
That's correct, this is just for analytics purposes. In this case, we're setting the linkType
to differentiate the type of flow that's happening. If the user is eligible for AppSwitch, we send the parameter as UNIVERSAL
, otherwise, we send it as DEEPLINK
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.
Can we internally rename these to APP_LINK
and APP_SWITCH
? If we need to send certain values for analytics purposes, we could have a string value for each of these. I think it'd make things a bit clearer inside the SDK.
if (internalPayPalClient.isAppSwitchEnabled(payPalRequest)) { | ||
braintreeClient.sendAnalyticsEvent(PayPalAnalytics.APP_SWITCH_STARTED, analyticsParams) |
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.
Should this analytic event be moved up to right after the TOKENIZE_STARTED
event? I assume we want to trigger this immediately at the start of the flow
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 think we want to trigger this event right before we launch the Venice app
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.
Exactly, this event needs to be called before launching the Venice app. The callback that comes afterward (callback.onPayPalPaymentAuthRequest
) is the one that tells the fragment to launch the Venice app
if (isAppSwitchFlow) { | ||
braintreeClient.sendAnalyticsEvent( | ||
PayPalAnalytics.HANDLE_RETURN_STARTED, | ||
analyticsParams | ||
) | ||
} |
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 think this should also move to right at the start of this method (line 189)
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.
Updated: 209b57c
PayPal/src/main/java/com/braintreepayments/api/paypal/PayPalClient.kt
Outdated
Show resolved
Hide resolved
linkType = if (internalPayPalClient.isAppSwitchEnabled(payPalRequest) && | ||
internalPayPalClient.isPayPalInstalled(context)) { | ||
LinkType.UNIVERSAL | ||
} else { | ||
LinkType.DEEPLINK |
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 think this actually indicates if we fall back to the legacy (CCT) flow or are using the app switch flow
if (internalPayPalClient.isAppSwitchEnabled(payPalRequest)) { | ||
braintreeClient.sendAnalyticsEvent(PayPalAnalytics.APP_SWITCH_STARTED, analyticsParams) |
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 think we want to trigger this event right before we launch the Venice app
@@ -153,12 +153,12 @@ internal class PayPalInternalClient( | |||
.build() | |||
} | |||
|
|||
private fun isAppSwitchEnabled(payPalRequest: PayPalRequest): Boolean { | |||
fun isAppSwitchEnabled(payPalRequest: PayPalRequest): Boolean { |
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.
Should these remain public or be internal at least? Not sure if we want to make them public.
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.
These methods are from PayPalInternalClient
, which is now internal
. I changed them to public
because I need access to them for UTs. PayPalInternalClient
and PayPalClient
need them to define certain flow criteria, any suggestions? UTs are requiring these methods to be public
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.
🤔 not sure if @tdchow has a suggestion on this, ideally we'd like to keep them private. If we are going to make them public temporarily we should likely add some docstrings saying it's not covered by semantic versioning so we can update in the future.
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 believe @richherrera is correct. Even though we removed the private
modifiers, since this entire class is internal
these functions will be hidden from merchants. We're also using these functions in PayPalClient
. So we'll need to keep them as internal.
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.
Nice! Thank you both for the explanation.
PayPal/src/main/java/com/braintreepayments/api/paypal/PayPalClient.kt
Outdated
Show resolved
Hide resolved
@@ -153,12 +153,12 @@ internal class PayPalInternalClient( | |||
.build() | |||
} | |||
|
|||
private fun isAppSwitchEnabled(payPalRequest: PayPalRequest): Boolean { | |||
fun isAppSwitchEnabled(payPalRequest: PayPalRequest): Boolean { |
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.
🤔 not sure if @tdchow has a suggestion on this, ideally we'd like to keep them private. If we are going to make them public temporarily we should likely add some docstrings saying it's not covered by semantic versioning so we can update in the future.
…ient.kt Co-authored-by: Jax DesMarais-Leder <[email protected]>
* main: (54 commits) Firebase App Distribution Branch (#1182) Fix lint warnings - replace kapt with ksp, remove unused properties and resources, added Intent extension functions for handling deprecated functions (#1181) [open dev] Cleanup integration tests (#1180) Update README and CHANGELOG (#1176) App link setup docs (#1171) Revert to Braintree Merchant Server (#1173) Prepare for development Release 5.0.0 Remove BA toast from PatPal Fragment (#1172) [App Switch] Update CHANGELOG (#1166) Make pending request constructors public (#1169) [App Switch] Add analytic events (#1111) Fix 3DS Cancel (#1161) Fix `os_version` and `enablePayPalAppSwitch` (#1162) Fix analytic event timestamps (#1160) Rename handleReturnToAppFromBrowser to handleReturnToApp (#1158) Parse error messages from multiple possible fields in the error response (#1156) External Interface Access Control (#1155) Update Google Pay Integration (#1153) Batch Analytics Events by Session ID (#1152) ... # Conflicts: # CHANGELOG.md # Demo/src/main/java/com/braintreepayments/demo/PayPalFragment.java # Demo/src/main/java/com/braintreepayments/demo/PayPalRequestFactory.java # Demo/src/main/res/layout/fragment_paypal.xml # PayPal/src/main/java/com/braintreepayments/api/paypal/PayPalRequest.kt # PayPal/src/main/java/com/braintreepayments/api/paypal/PayPalVaultRequest.kt # PayPal/src/test/java/com/braintreepayments/api/paypal/PayPalVaultRequestUnitTest.java
Summary of changes
Checklist
Authors