Skip to content
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

Merged
merged 9 commits into from
Aug 9, 2024
Merged

Cleanup App Switch #1381

merged 9 commits into from
Aug 9, 2024

Conversation

jaxdesmarais
Copy link
Contributor

Summary of changes

  • Move LinkType to enum
  • Remove logic to pass linkType into Approval URL parser
  • Move app installed check into Vault Request

Checklist

  • [ ] Added a changelog entry

Authors

@jaxdesmarais jaxdesmarais requested a review from a team as a code owner August 5, 2024 15:16
@@ -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
Copy link
Contributor

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

Copy link
Contributor Author

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:

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.

Copy link
Contributor

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)

Copy link
Contributor Author

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] {

Copy link
Contributor

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.

Copy link
Contributor

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!

Copy link
Contributor Author

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

Copy link
Contributor

@richherrera richherrera left a 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?) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

init?(body: BTJSON, linkType: String?) {
if linkType == "universal", let payPalAppRedirectURL = body["agreementSetup"]["paypalAppApprovalUrl"].asURL() {
init?(body: BTJSON) {
if let payPalAppRedirectURL = body["agreementSetup"]["paypalAppApprovalUrl"].asURL() {
Copy link
Contributor

@KunJeongPark KunJeongPark Aug 7, 2024

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.

Copy link
Contributor Author

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.

Copy link
Contributor

@KunJeongPark KunJeongPark Aug 7, 2024

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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:

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.

Copy link
Contributor

@KunJeongPark KunJeongPark Aug 8, 2024

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.

Copy link
Contributor Author

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.

@jaxdesmarais jaxdesmarais merged commit cc7317f into main Aug 9, 2024
7 of 8 checks passed
@jaxdesmarais jaxdesmarais deleted the cleanup-app-switch branch August 9, 2024 14:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants