Allow processing browser switch redirect without requiring an Activity instance

[erawhctim]

Is your feature request related to a problem? Please describe.

The problem is a scoping issue: PayPalClient is effective Activity-scoped, since it needs an Activity reference in its constructor, but onBrowserSwitchResult() doesn't actually need an Activity reference at all and could be Application-scoped.

Describe the solution you'd like.

I'd like to separate concerns of the PayPalClient (and it's underlying dependencies, BraintreeClient and BrowserSwitchClient) a bit so that I can call PayPalClient.onBrowserSwitchResult() without requiring an Activity instance.
From what I can tell, BraintreeClient and BrowserSwitchClient can both satisfy the needs of onBrowserSwitchResult() with only a Context reference (since they end up calling Context.getApplicationContext() internally), but since is routed through the PayPalClient, there's no way to call onBrowserSwitchResult() today without requiring an Activity.

If I could just construct a BraintreeClient and call BraintreeClient.onBrowserSwitchResult() directly, that would work (but that function is restricted/internal).

My use case revolves around certain UI screens that observe the results of the browser redirect being re-used in multiple Activities, depending on which app flow originated the PayPal account creation flow. I would prefer to handle the browser redirects and forward them into the SDK in one place (in a BroadcastReceiver or some other Application-scoped object) instead of configuring the browser redirect to work with multiple Activities, but that doesn't seem possible today.

My ideal solution(s):

1. Separate out the onBrowserSwitchResult() part of the PayPayClient into some new object (e.g. PayPalBrowserRedirectClient) that only requires a Context
2. Keep PayPalClient as-is, and offer a different way to send browser redirect results into the BraintreeClient or its underlying BrowserSwitchClient

[erawhctim]

Another alternative option: It looks like I can just construct my own BrowserSwitchClient and forward my redirect results into that directly, circumventing the PayPalClient and BraintreeClient, but that requires a requestCode that's internal to BraintreeCore 😞

[sshropshire]

Hey @erawhctim thanks for the request. We're working on a v5 beta release soon and we'll make sure to consider this as a feature add on.

It's worth calling out that application-context-enabled browser switching will force the Chrome Custom Tab (CCT) to be launched in a new task and there is no way to close the custom tab browser programmatically, so the CCT window will dangle in the user's task manager until they close it.

If you would like to provide more information about your use-case please do as well, or we may reach out when the beta is ready to see if it's something your app can use.

[erawhctim]

Good to know, thanks for the response!

I can give you some more details on how our screens/PayPal usage is set up, maybe there's an alternative SDK usage that you can pinpoint that I've missed:

We have a main activity that hosts mostly all screens, and we have a few additional Activities that are presented modally on top of the main activity. We have a few payment-related Fragments that can exist within either the main Activity or one of the misc. modally-presented Activities (depending on the UI flow), and those Fragments need to initiate the "vault" flow for vaulting a PayPal account (via PayPalClient.tokenizePayPalAccount(Activity, request(...)) and be able to respond to browser redirects.

Our main Activity is configured with launchMode:singleTask, so the browser redirect clears the modally-presented Activity on top and brings the main Activity from the background to the top of our stack. Perhaps this problem is exacerbated by the main Activity's launchMode, or the way we've configured our application and how it launches multiple Activities.

[sshropshire]

@erawhctim got it so the PayPal vault Fragment parent activity may be one of several possible Activity subclasses provided by your app?

The vault Fragment should be able to access the parent activity by using requireActivity(), but it sounds like the deep link response logic may be complex because you'd have to register all of the activities as deep link targets in the AndroidManifest.xml ? Let me know if I'm following correctly.

There may be away to handle this in the current version using custom URL schemes. Either way we may offer application-context enabled browser switching in the future, so it's helpful to know what the dream scenario is for your particular app architecture.

[erawhctim]

because you'd have to register all of the activities as deep link targets in the AndroidManifest.xml

Exactly right! This is the strategy we landed on, and it's working well in our testing (but configuring each Activity with it's own Activity-scoped SDK and manifest declaration is a bit of a pain).

Browser switching via App Context might ease that burden slightly, but the current setup is totally manageable (given we don't add new screens with PayPal support very often).

Thanks for the help thinking through this 🤝