-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Refactor chooseAccountActivity #357
Conversation
won't compile
There was a problem hiding this 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); |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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(); |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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();
}
}
@samtstern Unless you have more comments, this should be ready to go. I added |
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. |
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' |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome!
@SUPERCILEX regarding your 'STOPSHIP' comment you only need to configure the Other than that I agree, this is looking good to go! |
@samtstern I think we're ready to roll! |
@SUPERCILEX I agree, I'll wait for Travis' green light. This has been a marathon! Thank you so much for seeing it through. |
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, |
@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? |
Here's the call stack:
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. |
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). |
Ah, I get it. My commit fixes the crash, but I still need to figure out the flow. |
@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) |
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. |
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. |
#254
TODO @samtstern:
TODO me:
hideProgress
is working with auto sign inAuthUI.AuthUIResult
will become null and a null pointer will ensue. How to get rid ofAuthUI.AuthUIResult
. Any ideas?SaveSmartLock
behavior to make sure configuration changes don't cause a null pointer exception.Bugs fixed in this PR: