Possibility to differentiate between canceled & failed sign in

[Juchar]

There is currently no possibility to differentiate between a canceled sign in (e.g. the user pressed the back button to leave the auth method picker) and a failed sign in attempt.

As far as I can see this always results in RESULT_CANCELED as a return code.

By consequence it is difficult to show an according message to the user only if the login failed, as for a canceled login I do not want to show an error message (user decided to cancel the login).

Would it be an idea to introduce something like a RESULT_SIGN_IN_FAILED return code?
Or how is this inteded to be used in general?

[SUPERCILEX]

#357 has that goal in mind: your activity would have to implement (I'm hoping to find a way around that) AuthUI.SignInResult:

public interface SignInResult {
    void onAuthUISuccess(IdpResponse data);

    void onAuthUIFailure(int resultCode);
}

You could get different failure codes from the resultCode. There is still a lot more work to be done, but I think something like that will happen by 2.0.

[Juchar]

Ok, thank you for the information.
And to break the code of conduct :) -> is there an ETA for the next release? Some milestone?

[Juchar]

I have to say that this is currently really a blocker for me regarding usability. The way it is now I have to tell the user that the sign in failed even if he consciously pressed on the back button and cancelled the sign in process.

Is there possibly at least some workaround or something similar?
Or do you possibly have a suggestion on how to handle this case from a UI point of view?

I am really a bit struggling (sorry if this is the wrong place to ask for help, please be so kind to redirect me if needed).

[SUPERCILEX]

@Juchar Haleluya! This issue will probably be fixed in v1.1.0. Sorry about not getting it done in #357 like I had originally planned. In the end, we didn't change the public api so I decided to hold back on a ResultCodes refactor.

You can check out the progress of this refactor here: #426.

[samtstern]

A fix for this issue has been released in version 1.1.0