Posted by Laurence Moroney
With the release of Google Play services 8.3, we’ve made a lot of improvements to Sign-In with Google. In the first blog post of this ongoing series, we discussed the user interface improvements. Today, we will look further into the changes to the API to make building apps that Sign-In with Google easier than ever before.
Changes to basic sign in flow
When building apps that sign in with Google, you’ll notice that there are a lot of changes to make your code easier to understand and maintain.
Prior to this release, if you built an app that used Sign-In with Google, you would build one that attempted to connect to a GoogleApiClient. At this point the user was presented with an account picker and/or a permissions dialog, both of which would trigger a connection failure. You would have to handle these connection failures in order to sign in. Once the GoogleApiClient connected, then the user was considered to be signed in and the permissions could be granted. The process is documented in a CodeLab here.
Now, your code can be greatly simplified.
The process of signing in and connecting the GoogleApiClient are handled separately. Signing in is achieved with a GoogleSignInOptions object, on which you specify the parameters of the sign in, such as scopes that you desire. Here’s a code example:
GoogleSignInOptions gso = new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)
.requestEmail()
.build();
Once you have a GoogleSignInOptions object, you can use it to configure the GoogleApiClient:
Here’s where your code will diverge greatly in the new API. Now, if you want to connect with a Google Account, instead of handling errors on the GoogleApiClient, you’ll instead use an intent that is initialized using the client.
Intent signInIntent = Auth.GoogleSignInApi.getSignInIntent(mGoogleApiClient);
startActivityForResult(signInIntent, RC_SIGN_IN);
Starting the intent will give you the account picker, and the scopes permission dialog if your GoogleSignInOptions requested anything other than basic scope. Once the user has finished interacting with the dialogs, an OnActivityResult callback will fire, and it will contain the requisite sign-in information.
@Override
public void onActivityResult(int requestCode, int resultCode, Intent data) {
super.onActivityResult(requestCode, resultCode, data);
// Result returned from launching the Intent from GoogleSignInApi.getSignInIntent(...);
if (requestCode == RC_SIGN_IN) {
GoogleSignInResult result = Auth.GoogleSignInApi.getSignInResultFromIntent(data);
handleSignInResult(result);
}
}
You can learn more about this code in the Integrating Google Sign-In quickstart, or by looking at the sample code.
Silent Sign-In
To further reduce friction for users in a multi-device world, the API supports silent sign in. In this case, if your user has given authorization to the app on a different device, the details will follow their account, and they don’t need to re-give them on future devices that they sign into, unless they deauthorize. An existing sign-in is also cached and available synchronously on the current device is available.
Using it is as simple as calling the silentSignIn method on the API.
OptionalPendingResult opr =
Auth.GoogleSignInApi.silentSignIn(mGoogleApiClient);
Then, you can check the isDone() method on the pending result -- and if it returns true, the user is signed in, and you can get their status from the PendingResult. If it isn’t then you have to wait for a callback with the SignInResult
if (pendingResult.isDone()) {
doStuffWith(pendingResult.get());
} else {
// There's no immediate result ready, displays some progress indicator and waits for the
// async callback.
showProgressIndicator();
pendingResult.setResultCallback(new ResultCallback<GoogleSignInResult>() {
@Override
public void onResult(@NonNull GoogleSignInResult result) {
updateButtonsAndStatusFromSignInResult(result);
hideProgressIndicator();
}
});
}
Customizing the Sign-In Button
When building apps that Sign-In with Google, we provide a SignInButton object that has the Google branding, and which looks like this:
You can customize this button with a number of properties and constants that are documented in the API here.
The branding guidelines are available here, and they include versions of the buttons in PNG, SVG, EPS and other formats in many resolutions, including all the different states of the button. These files may be used for localization of the button, and if you need to match the style of the button to your app, guidelines are provided.
This only deals with the Android side of your app. You’ll likely have a server back end, and you may want to use the credentials on that securely.
In the next blog post, we’ll discuss how to use Sign-In with Google in server-side scenarios, including how to securely pass your credentials to your own server, and how to use Google back-end services, such as Google Drive, with the permission and credentials from users.
