Proposal: Allow fully customized XML layouts for the AuthMethodPickerActivity

[samtstern]

Proposal

Allow developers to pass their own XML resource for the main login screen:

AuthUI.getInstance().createSignInIntentBuilder()
    // ...
    .setTheme(...)
    .setMainLayout(R.xml.my_custom_layout) // If not provided, default used
    .build()

We would define an implicit public API specifying which resource IDs need to be present in that XML screen in order for us to add controls to it, such as:

• A ViewGroup for us to add the sign-in provider buttons
• A TextView for the Terms of Service and Privacy Policy disclosure
• A ProgressBar to show loading operations
• An option to use your own sign-in buttons and just let us add click listeners.

Note that this proposal only affects the first screen. The rest would still be governed by the setTheme() attribute. There are too many other screens, and their functionality is too complex, to allow for full user customization of every one.

Rationale

We have gotten many requests to be able to customize the main UI more such as:
#1383, #753, #619, #266, #236, #229

When looking at popular Android apps, the sign-in method selection screen is often a showcase for the brand and the UI varies from app to app. There's no way to add more "options" to our system to encompass all use cases.

Here are some examples of screens from other apps that I like and would like to enable. While we can't enable every single feature shown in these screenshots, we can at least allow developers to get most of the way there and create an immersive look and feel without writing anything besides XML.

cc @bojeil-google @morganchen12 @lsirac @SUPERCILEX

[SUPERCILEX]

I think you're right. The main issue I see is that all those screenshots have data which would probably be downloaded dynamically. If we really wanted to support as many use cases as possible, we'd probably have to create a service which gives devs access to the view hierarchy so they can do animations, dynamic stuff, whatever. I'm using a service for the full account linking PR and I've been wanting to do something similar for the email sign-up page to allow custom field add/removal and validation.

In any case, this seems like a step in the right direction to me. 👍

[cutiko]

Greetings

I think this is a great improvement, is what I would expect as customization. I would like to suggest something about this:

which resource IDs need to be present in that XML

That seems prone to human error, a formal structure that represents the layout could be useful:

public class AuthLayout {
       @LayoutRes
        private int layout;
        @IdRes
        private int facebookBtn, googleBtn, emailBtn;
        //Constructors, getters and setters...
}

This way we have to only be careful to have one id for each provider

[dimipaun]

In addition to this, we should export the building blocks of this screen so that users can easily recreate it -- this would solve all these problems and more!

For example, we want to add additional login buttons (e.g. Login with XYZ) which is basically impossible to do right now as the building blocks of this page are not public.

[samtstern]

@cutiko that's a good idea! It would avoid having XML as an implicit API and use something more explicit.

@dimipaun we'd love to do something like that but right now it's really hard because we're managing a whole stack of Activities. Without owning the root activity, there are some things we can't do. It may be possible to define an interface so that anyone could make their own root activity, but that's a non-goal right now.

[samtstern]

@iamyaoxi has started working on this using the suggestions of everyone here.