Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@SUPERCILEX
Copy link
Collaborator

Proposal for #1039. @samtstern What do you think? Is this something that should go in FirebaseUI Auth? Personally, I think this is huge since it means a zero-effort way for developers to provide seamless sign-in after their users upgrade devices or reinstall their apps.

PS: to try it, just sign in with Google or email, clear app data, and then press the silent sign-in button.

Signed-off-by: Alex Saveau <[email protected]>
Signed-off-by: Alex Saveau <[email protected]>
@SUPERCILEX SUPERCILEX requested a review from samtstern as a code owner March 25, 2018 20:25
@SUPERCILEX SUPERCILEX changed the title Silent sign in Add support for Firebase backed silent sign-in Mar 25, 2018
@samtstern samtstern added this to the 3.4.0 milestone Mar 26, 2018
@samtstern
Copy link
Contributor

@SUPERCILEX this is really cool, but since it's cross-device in nature it's definitely something we'd want iOS and Web support for. I know that iOS does not have SmartLock, but we could port as much of the idea as possible.

So just FYI this one could be on hold for a bit, as we have to drum up some excitement from the maintainers of those platforms.

@SUPERCILEX
Copy link
Collaborator Author

Haha, SGTM!

…-sign-in

# Conflicts:
#	app/src/main/java/com/firebase/uidemo/auth/AuthUiActivity.java
Signed-off-by: Alex Saveau <[email protected]>
@SUPERCILEX
Copy link
Collaborator Author

Lol, I seem to have broken all of my PRs. Sorry for the spammy updates! ☺️

@SUPERCILEX SUPERCILEX changed the base branch from version-3.3.0-dev to master March 28, 2018 21:50
@SUPERCILEX
Copy link
Collaborator Author

@SUPERCILEX
Copy link
Collaborator Author

SUPERCILEX commented Mar 29, 2018

I still need to add README docs

@SUPERCILEX
Copy link
Collaborator Author

@samtstern Alright, I think this PR is ready for review.

@SUPERCILEX
Copy link
Collaborator Author

@samtstern Anything holding this one back?

@samtstern
Copy link
Contributor

@SUPERCILEX nothing philosophical holding this back, I was just focusing on 3.3.1 targeted things first.

@SUPERCILEX
Copy link
Collaborator Author

Gotya, SGTM! 👍

@samtstern samtstern changed the base branch from version-3.3.1-dev to version-3.4.0-dev April 13, 2018 19:48
@SUPERCILEX
Copy link
Collaborator Author

@samtstern ready to roll?

}

final Context appContext = context.getApplicationContext();
final IdpConfig google =
Copy link
Contributor

Choose a reason for hiding this comment

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

This is kind of a funny way to get here:

  • Run through desired configs, filter out everything besides google and email
  • Then use getConfigFromIdps to get google and email out of the filtered list

Why not just use getConfigfromIdps on desiredConfigs and throw the IllegalArgumentException if google and email both end up null?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Lol, yeah, that's a much better way to do it.

.getParcelable(ExtraConstants.GOOGLE_SIGN_IN_OPTIONS);
}

final GoogleSignInOptions finalGoogleOptions = googleOptions;
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we need a separate variable to finalize?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Now we don't!

* @return a task which indicates whether or not the user was successfully signed in.
*/
@NonNull
public Task<AuthResult> silentSignIn(@NonNull Context context,
Copy link
Contributor

Choose a reason for hiding this comment

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

I am somewhat uncomfortable with all this code and chained async operations happening in one huge method block in AuthUI. Should we consider making this happen inside a ViewModel in KickoffActivity or something so that it's rotation-immune? Obviously then we couldn't directly return a Task but I think onActivityResult would be appropriate (and more consistent with our general mechanism anyway)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yeah, I don't like the number of chained tasks we have either, but I strongly disagree about the onActivityResult and ViewModel stuff. The point of this method is that it doesn't have any UI and should be done in the background (so it's up to the dev to deal with async callbacks as usual). As for rotation problems, they're up to the dev just like with any other Task. Also, I tried calling the method multiple times myself and it doesn't seem to matter besides being signed-in several times with the same credentials on the Firebase side (so the method is deterministic in that you'll just get the same result multiple times).

Do you see where I'm coming from? I literally call this method in my Application#onCreate() and I think other people will want to do something similar.

@samtstern samtstern merged commit 50a4ec7 into firebase:version-3.4.0-dev Apr 17, 2018
@SUPERCILEX SUPERCILEX deleted the silent-sign-in branch April 17, 2018 20:28
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.

3 participants