-
Notifications
You must be signed in to change notification settings - Fork 658
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
Incorporate the Activity result APIs to resolve loadPaymentData calls #8381
Conversation
…o google-pay-activity-result # Conflicts: # payments-core/src/main/java/com/stripe/android/googlepaylauncher/GooglePayLauncherActivity.kt
…ty result launcher
…-pay-activity-result # Conflicts: # payments-core/src/main/java/com/stripe/android/googlepaylauncher/GooglePayLauncherActivity.kt # payments-core/src/main/java/com/stripe/android/googlepaylauncher/GooglePayLauncherViewModel.kt
Diffuse output:
APK
DEX
|
@@ -39,10 +40,6 @@ internal class GooglePayLauncherActivity : AppCompatActivity() { | |||
GooglePayLauncherViewModel.Factory(args) | |||
} | |||
|
|||
private val errorReporter: ErrorReporter by lazy { |
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 as part of fixing the merge conflicts, the actual error reporting for some of these errors was removed. Can we fix that? Or if there are error cases that no longer exist, can we remove those cases from the ErrorReporter ErrorEvent enum?
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.
(could be fixed by sharing more code with GooglePayPaymentMethodLauncherActivity, see my comment there)
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.
Yeah, I thought I fixed these, but looks like I missed some. Good callout. I'll follow up.
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 didn't realize we had two classes that were so similar. So when I saw this missing after the rebase, I thought I fixed it. But I just added it to the other one 🤦.
I think it's probably worth having in both. And it's also probably worth consolidating these.
private fun onGooglePayResult(taskResult: ApiTaskResult<PaymentData>) { | ||
when (taskResult.status.statusCode) { | ||
CommonStatusCodes.SUCCESS -> { | ||
val paymentDataJson = JSONObject(taskResult.result!!.toJson()) |
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.
what's the impact of result being null? Will we crash?
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.
(could be fixed by sharing more code with GooglePayPaymentMethodLauncherActivity, see my comment there)
when (taskResult.status.statusCode) { | ||
CommonStatusCodes.SUCCESS -> { | ||
val result = taskResult.result | ||
if (result != null) { |
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.
ah it actually looks like this activity handles the taskResult.result being null and it reports errors, both of which are not present in GooglePayLauncherActivity. If that's not intentional, should we try to share more code between these two classes?
val statusMessage = status.statusMessage.orEmpty() | ||
errorReporter.report( | ||
ErrorReporter.ExpectedErrorEvent.GOOGLE_PAY_FAILED, | ||
additionalNonPiiParams = mapOf("status_message" to statusMessage) |
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 we include the status code here too?
After digging through this more, I think we need to rewrite quite a bit of our google pay integrations to work more seamlessly with the Android lifecycle. During that refactor, we could also attempt to reuse more of the google pay integration logic between the two. Created a backlog task to do this: https://jira.corp.stripe.com/browse/MOBILESDK-2011 |
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!
} | ||
} | ||
} | ||
} |
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 necessary for this PR, but I added kotlinx-coroutines-play-services
for GooglePayRepository
in my refactor for that class. Should we align and use that instead or vice versa by moving this extension to a core lib?
Summary
Finishing the work started in #7895
Motivation
Upgrade to the latest playServicesWallet version.
Testing