-
Notifications
You must be signed in to change notification settings - Fork 295
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
Cleanup App Switch #1381
Cleanup App Switch #1381
Conversation
Co-authored-by: scannillo <[email protected]>
@@ -19,6 +19,9 @@ import BraintreeCore | |||
/// - Warning: This property is currently in beta and may change or be removed in future releases. | |||
var enablePayPalAppSwitch: Bool = false | |||
|
|||
/// exposed for mocking in tests | |||
var application: URLOpener = UIApplication.shared |
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.
IMO it's a little strange for VaultRequest to do the app installed inspection. It adds logic into our "model" type
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.
Agree, but it also felt odd that we were overriding a property in the client to ensure we don't pass the app switch params if the app is not installed here:
braintree_ios/Sources/BraintreePayPal/BTPayPalClient.swift
Lines 336 to 338 in 6a375f2
if !self.payPalAppInstalled { | |
(request as? BTPayPalVaultRequest)?.enablePayPalAppSwitch = false | |
} |
Do you know where else this logic could live that would make more sense? We could potentially pass it as a property when we call parameters()
similar to universalLink
. Curious to hear your thoughts.
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.
IMO the way it exists now is the highest separation of concerns (business logic in PayPalClient, model only in VaultRequest)
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.
Would we be okay passing it through here instead? I don't think changing a param in the model is the best separation of concern either. This came up when @richherrera was looking through the implementation for Android and this was a point of confusion.
public override func parameters(with configuration: BTConfiguration, universalLink: URL? = nil) -> [String: Any] { |
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 also agree with Sammy. It's correct—after reviewing the iOS implementation, I didn’t understand why the model had "enablePayPalAppSwitch" set to false, no matter if I configured it as true. I also agree with you, Jax, that modifying this method isn't ideal. I think we could leave it as it is.
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 understand the concern now - currently we're changing the merchant-facing VaultRequest. enablePayPalAppSwitch
setting without them knowing, which could be confusing. Jax I like the idea of injecting into the parameters()
method more than having a reference to UIApplication
in the VaultRequest
!
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 exactly - sorry I realize I should have done a better job of explaining the intent of the change initially. Pushed the change here: 893d736
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!!
@@ -45,8 +45,8 @@ struct BTPayPalApprovalURLParser { | |||
return nil | |||
} | |||
|
|||
init?(body: BTJSON, linkType: String?) { |
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.
👍
…cation from VaultRequest
init?(body: BTJSON, linkType: String?) { | ||
if linkType == "universal", let payPalAppRedirectURL = body["agreementSetup"]["paypalAppApprovalUrl"].asURL() { | ||
init?(body: BTJSON) { | ||
if let payPalAppRedirectURL = body["agreementSetup"]["paypalAppApprovalUrl"].asURL() { |
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 EditFI work, we are not using payPalAppApprovalUrl
because app switching is not in scope yet for that work stream. But if the gateway returns this value as well as approvalURL in generate_edit_fi_url
response, using this Parser we would get payPalAppRedirectURL
instead of the approvalURL
. For right now for the draft on a branch (editFI-gateway-endpoints), I just forced the web Url fetching by passing in linkType as nil (or could have passed in "deepLink" ). I guess I can use something else to get the webURL.
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.
Is the gateway returning a payPalAppApprovalUrl
for the edit FI endpoints? Because they should not be and we should raise that if so. This was only ever added because when we were working off of stage we always got a payPalAppApprovalUrl
regardless of eligibility and was just never cleaned up. See old convo here: #1271 (comment). I tested the experience in this PR and no longer see this behavior with the app uninstalled.
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.
The Gateway specs on Confluence show: Response - agreementSetup {tokenId, paypalAppApprovalUrl, approvalUrl}
as response for edit FI url endpoint. Maybe the doc is not updated or maybe it's supposed to return just approval url. I will check with you and Gateway team tomorrow.
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.
Okay, then removing the link type will not impact that flow and we should not need to pass in a link type, it will always fail this first check for a payPalAppApprovalUrl
and move on to the next block which includes the web URL.
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've posted the question on the collaboration channel so we can clarify with them.
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.
Fwiw we also have to opt in to the app switch flow for the Gateway to return that property, so I would expect it only exists to future proof this feature. We need to pass them everything here to say the merchant opted into app switch which we won't be doing for Edit FI currently:
braintree_ios/Sources/BraintreePayPal/BTPayPalVaultRequest.swift
Lines 56 to 64 in 38297e4
if enablePayPalAppSwitch, let universalLink { | |
let appSwitchParameters: [String: Any] = [ | |
"launch_paypal_app": enablePayPalAppSwitch, | |
"os_version": UIDevice.current.systemVersion, | |
"os_type": UIDevice.current.systemName, | |
"merchant_app_return_url": universalLink.absoluteString | |
] | |
return baseParameters.merging(appSwitchParameters) { $1 } | |
} |
The gateway only returns a payPalAppApprovalUrl
if those properties are passed AND the merchant is eligible on the gateway side.
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.
Great! thank you for the clarification. I do want to make sure that this is true for editFI endpoint as well since there are no details given in the specs. I want to clarify that payPalAppApprovalUrl
will return a nil value or not exist at all for generate_edit_fi_url
endpoint if these parameters are not passed. And these parameters are not mentioned for generate_edi_fi_url
endpoint.
What you are saying makes sense though.
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 sure! Will be good to clarify but shouldn't block this PR. If the gateway does something weird we can make the necessary updates in the Edit FI branch.
Summary of changes
LinkType
to enumlinkType
into Approval URL parserChecklist
[ ] Added a changelog entryAuthors