Google has rolled out Google Play Services SDK 11.6.0, which introduces major changes to how the APIs are structured. The company is deprecating one API while decoupling another. The idea is to reduce the amount of boilerplate code needed to use the APIs -- something everyone can be happy about.
Google claims the changes being made to Google Play Services SDK 11.6.0 will make the APIs therein easier to use, thread-safe, and more efficient when it comes to memory. Google is putting the Task model to use in order to provide better separation of the activity that takes place within the APIs. Task was first put to use as a programming model in Firebase and Google says it was fairly well received.
The three main aspects of the Google Play Services SDK are to provide authentication, convert users, and handle multi-player invitations.
Authentication is now handled explicitly via the Google Sign-In client. Google says this makes it more clear when controlling the authentication process, especially when attempting to separate between a Google identity and a Play Games identity. Users' games profile contains a gamer tag (username) and an avatar for display. The actual identity of the user is protected. Google suggests this eliminates the need for sers to consent to sharing more personal details that might scare them away from signing in. Reducing friction during sign-in is clutch when it comes to onboarding users.
Only one user account can be signed in at a time. Google says it's good practice to attempt a silent sign-in when users resume activity. Doing so in the background, without affirmative action on the part of the user, reduces the time to get to gameplay. If users have signed out of Play Games, however, they will be prompted to sign back in. The API lets developers add a separate intent for signing in if they wish. Signing in is handled by the GoogleSignIn.getLastSignedInAccount() method, while signing out is handled by calling GoogleSignInClient.signOut().
There are some changes to how calling the Game Services API is handled. Under the old method, it was accessed from a static field on the Games Class and it returned a PendingResult. The PendingResult class has been replaced by the Task class. Google says developers will "gain all the goodness" of the Task API without worrying about the GoogleApiClient lifecycle management. This pattern is repeated for all the new APIs.
The last major change is the introduction of a new API class called GamesClient. This handles support methods and provides access to the multiplayer invitation object when games are launched from notifications. Using the GamesClient API should call the signInSilently() tool to process the invitation and seamlessly sign the user in. Google says GoogleApiClient is no longer used, so invitations are accessed through explicit API calls.
"The change from the GoogleApiClient usage to a more loosely coupled API clients usage will provide benefits of less boilerplate code, more clear usage patterns, and thread safety," concluded Google.
Google suggests developers take a look at its suggested best practices.