Skip to content

Refactor chooseAccountActivity #357

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

Merged
merged 114 commits into from
Nov 23, 2016
Merged

Refactor chooseAccountActivity #357

merged 114 commits into from
Nov 23, 2016

Conversation

SUPERCILEX
Copy link
Collaborator

@SUPERCILEX SUPERCILEX commented Oct 16, 2016

#254

TODO @samtstern:

TODO me:

Bugs fixed in this PR:

Copy link
Collaborator Author

@SUPERCILEX SUPERCILEX left a comment

Choose a reason for hiding this comment

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

This PR includes #343 so that should be merged first.

Since I deleted everything, I'll go through and explain the changes I made for you guys, but first I have a road block I need you guys to make a decision on before I continue. Other than that, things are blazing fast and sleek!

if (status.getStatusCode() == CommonStatusCodes.RESOLUTION_REQUIRED) {
try {
// TODO check the mActivity stuff
status.startResolutionForResult(mActivity, RC_CREDENTIALS_READ);
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Here's where I'm stuck. There are two options: either people using the library would have to call onActivityResult for us, or I would have to change SignInDelegate to an AppCompatFragment which would mean people using the library have to pass in an AppCompatActivity instead of being able to pass in any activity. I'm in favor of the latter because 99.9% of people are probably already using AppCompatActivity anyway since it is necessary for the Toolbar (added in API v21).

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I decided to go ahead with the AppCompatActivity thing because it is a direct subclass of Activity: https://developer.android.com/reference/android/support/v7/app/AppCompatActivity.html so there isn't really a tradeoff to the developer if they are using Activity (aka they wouldn't lose anything by switching).

@@ -176,7 +176,6 @@ public void onComplete(@NonNull Task<AuthResult> task) {
TAG, "Error signing in with previous credential"))
.addOnCompleteListener(new FinishListener(newIdpResponse));
} else {
mActivityHelper.dismissDialog();
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I removed unnecessary calls to dismissDialog() with an immediate successive finish()

GoogleApiClient.OnConnectionFailedListener {
private static final String TAG = "SmartLockBase";

protected GoogleApiClient mGoogleApiClient;
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes below:

    public void cleanup() {
        if (mGoogleApiClient != null) {
            mGoogleApiClient.disconnect();
        }
    }

@SUPERCILEX
Copy link
Collaborator Author

@samtstern Unless you have more comments, this should be ready to go.

I added RecoveryEmailSentDialog to fix the dialog being dismissed on rotation.

@SUPERCILEX
Copy link
Collaborator Author

I just fixed a leak so now it should be ready to go. 😄

Do we want to keep LeakCanary or should I remove it? I'm pro keeping it since it would help prevent cases like #396 where leak canary could have helped us catch those issues earlier.

@SUPERCILEX
Copy link
Collaborator Author

SUPERCILEX commented Nov 23, 2016

STOPSHIP: I'm pretty sure I should be requesting the permissions specified in IdpConfig here: https://github.com/firebase/FirebaseUI-Android/pull/357/files#diff-741502abb522ecd56e7c30231e015bdbR112

@@ -46,6 +46,9 @@ dependencies {
compile 'pub.devrel:easypermissions:0.2.1'
compile 'com.jakewharton:butterknife:8.4.0'
apt 'com.jakewharton:butterknife-compiler:8.4.0'
debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5'
Copy link
Contributor

Choose a reason for hiding this comment

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

+1 to keeping LeakCanary around

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Awesome!

@samtstern
Copy link
Contributor

@SUPERCILEX regarding your 'STOPSHIP' comment you only need to configure the GoogleSignInOptions with scopes if you are going to use that GoogleApiClient to use the GoogleSignInApi. From what I can tell you're only using it for the Credentials API, which means you can actually omit the addApi(GOOGLE_SIGN_IN_API) and the GoogleSignInOptions altogether.

Other than that I agree, this is looking good to go!

@SUPERCILEX
Copy link
Collaborator Author

@samtstern I think we're ready to roll!

@samtstern
Copy link
Contributor

@SUPERCILEX I agree, I'll wait for Travis' green light. This has been a marathon! Thank you so much for seeing it through.

@samtstern
Copy link
Contributor

samtstern commented Nov 23, 2016

Hate to be the bearer of bad news but found one more error! Did some manual testing and got a crash here:

SignInDelegate

    private void redirectToIdpSignIn(String email, String accountType) {
        if (accountType.equals(IdentityProviders.GOOGLE)
                || accountType.equals(IdentityProviders.FACEBOOK)
                || accountType.equals(IdentityProviders.TWITTER)) {
            IdpSignInContainer.signIn(

When I select an email credential from SmartLock, accountType == null so we get a NullPointerException.

@SUPERCILEX
Copy link
Collaborator Author

@samtstern I'm not seeing the crash. Also, the only way it could have happened is if the password from the email you selected in smart lock was null which would be weird:

if (!TextUtils.isEmpty(email)) {
    if (TextUtils.isEmpty(password)) {
        // log in with id/provider
        redirectToIdpSignIn(email, getAccountTypeFromCredential());
    } else {
        // Sign in with the email/password retrieved from SmartLock
        signInWithEmailAndPassword(email, password);
    }
}

Do you think there is something else going on?

@samtstern
Copy link
Contributor

Here's the call stack:

Attempt to invoke virtual method 'boolean java.lang.String.equals(java.lang.Object)' on a null object reference
                                                       at com.firebase.ui.auth.util.signincontainer.SignInDelegate.redirectToIdpSignIn(SignInDelegate.java:332)
                                                       at com.firebase.ui.auth.util.signincontainer.SignInDelegate.handleCredential(SignInDelegate.java:241)
                                                       at com.firebase.ui.auth.util.signincontainer.SignInDelegate.onActivityResult(SignInDelegate.java:178)

So that would imply that the password is actually empty. I believe this is a "hint" credential. The SmartLock picker sometimes shows "hints" which contain email addresses that you have used before but no passwords, basically as an advanced sort of autofill.

@samtstern
Copy link
Contributor

I'm not sure exactly why that Credential was in there, but I think we should be defensive and handle null accountType in that code branch (just fall back to email sign in).

@SUPERCILEX
Copy link
Collaborator Author

SUPERCILEX commented Nov 23, 2016

Ah, I get it. My commit fixes the crash, but I still need to figure out the flow.

@samtstern
Copy link
Contributor

@SUPERCILEX thanks for the commit to fix it. I am going to merge this PR now! That seems like a separate issue.

So which issues can I mark as "fix-implemented" now? And hopefully I will do a release with this issue on Monday (don't want to do it today in case something goes wrong, everyone is out for Thanksgiving)

@samtstern samtstern merged commit 225dffd into firebase:master Nov 23, 2016
@samtstern
Copy link
Contributor

Also 114 commits! That has to be some kind of record. This was a great effort, part of making this library a lot leaner. Excited to build on this.

@SUPERCILEX SUPERCILEX deleted the refactor-ChooseAccountActivity branch November 23, 2016 21:01
@SUPERCILEX
Copy link
Collaborator Author

Whew! We did it! I'll look for the issues that can be closed and I also created #416 to fix the smart lock email flow.

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.

onActivityResult not fired!
4 participants