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

Feature request: ability to always skip provider choice #1825

Closed
ubragg opened this issue Aug 23, 2020 · 6 comments
Closed

Feature request: ability to always skip provider choice #1825

ubragg opened this issue Aug 23, 2020 · 6 comments

Comments

@ubragg
Copy link
Contributor

ubragg commented Aug 23, 2020

I'm interested in using FirebaseUI for all of its many great features except that I'd like to not use the provider selector UI and instead trigger the experience using my own buttons for each provider on my own login screen, as my login screen has other functionality that can't be expressed in XML alone (as far as I have determined).

I was able to do this by wiring up each of my Google, Apple, and Facebook buttons to the following code:

   activity.startActivityForResult(
        AuthUI.getInstance()
            .createSignInIntentBuilder()
            .setAvailableProviders(Collections.singletonList(new AuthUI.IdpConfig.XXXXXBuilder().build()))
            .build(),
        requestId);

Because I only ever call this with a single provider, and set the (singleton) providers list separately for each button, it always skips the AuthMethodPickerActivity, and this works perfectly in the common case.

The problem is that when a user that has an account with Google tries to sign in with Facebook, and they run into the issue described in #301, rather than gracefully resolving it by having them sign in with Google, in my case, it fails with a developer error, because a given flow can't fall back on the other providers unless they're in the list that started the flow.

I have investigated many ways to address this, and am still trying to figure out a way to work around it, but it seems the easiest fix for this to be supported at the library level would be one of the following:

  • Add a setNeverShowSignInMethodScreen() option akin to setAlwaysShowSignInMethodScreen() that simply uses the first one in the list to start, and falls back to the others only if necessary.
  • Allow the ability to launch the flow with a full list of providers, but with one specified as the default to start with to bypass the select screen.

I'm even happy to submit a pull request if any of these suggestions would have a chance to be accepted.

As for short term fixes, I'd love suggestions for that too. I have tried to override FlowParameters (which in the current state of things would simply require me to be able to override shouldShowProviderChoice() to always return true), but to get there I'd need to also override AuthUI.SignInIntentBuilder, which I can't seem to do because it has a private constructor. I've even tried making a custom UI that's just a transparent or themed activity with invisible buttons that I click programmatically when it starts, but that has some issues when the user backs out of the flow, since they get to a blank page, plus it's quite a bit more hacky than I'd like.

@ubragg
Copy link
Contributor Author

ubragg commented Aug 23, 2020

Proposed implementation: ubragg@5a735fb

@samtstern
Copy link
Contributor

@ubragg thanks for the feedback and feature request. I think this would be best expressed as setDefaultProvider(...) to let us know to skip the AuthMethodPickerActivity and go straight into the flow for a certain provider.

@samtstern samtstern added this to the 6.3.1 milestone Aug 28, 2020
@ubragg
Copy link
Contributor Author

ubragg commented Aug 28, 2020

I agree that would be a cleaner API. Shall I go ahead and prepare a pull request doing it that way?

@samtstern
Copy link
Contributor

@ubragg sure if you're willing to send a PR I'd be happy to review it! Please target the version-6.4.0-dev branch which I am creating right now.

@ubragg
Copy link
Contributor Author

ubragg commented Aug 31, 2020

OK, I'll give it a shot.

@samtstern
Copy link
Contributor

This has been released in version 6.4.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants