-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Comments
Proposed implementation: ubragg@5a735fb |
@ubragg thanks for the feedback and feature request. I think this would be best expressed as |
I agree that would be a cleaner API. Shall I go ahead and prepare a pull request doing it that way? |
@ubragg sure if you're willing to send a PR I'd be happy to review it! Please target the |
OK, I'll give it a shot. |
This has been released in version |
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:
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:
setNeverShowSignInMethodScreen()
option akin tosetAlwaysShowSignInMethodScreen()
that simply uses the first one in the list to start, and falls back to the others only if necessary.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 overrideshouldShowProviderChoice()
to always return true), but to get there I'd need to also overrideAuthUI.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.The text was updated successfully, but these errors were encountered: