Access google plus client from multiple activities

Question

I'm developing an application in which i have integrated google plus. So far Its working fine, I am able to retrieve the user profile.

But now i want to do the following:

1)I have two activity signInActivity and shareActivity.

2)If user is already signin using signInActivity then it should not ask for signin again in shareActivity and should directly share the content.

3)If user is not signedin in the signInActivity and try to share data using shareActivitythen app should signin the user and then only share the data. In this case if user goes back to the signInActivity then app should show that "you have already signedin"

In short i want user signin to be Central within application so that if it is alrady signedin it should be accessible from any activity.

I have heard about the access token but i dont know how to use it and document says that it expires in an hour which is not what i want.

How can i make central google plus signin? is it possible? or i need to authenticate user in each activity?

Answer 1

Managing a separate instance of GoogleApiClient in each activity will not result in the user being asked to sign in multiple times.

Google+ Sign-in (ie. GoogleApiClient) provides an interface to the Google accounts on the device and the Google Play services core service - it doesn't have state per GoogleApiClient instance. So once a device account has been authenticated for your app, new instances of GoogleApiClient will access the same state. GoogleApiClient is specifically designed to be a lightweight way to access the central state managed by Google Play services.

You're in luck regarding access tokens! Google Play services takes care of all token management for you. So although access tokens only last for one hour, as you say, if you try to use your PlusClient to access a Google API and your access token has expired, Google Play services will transparently request a new access token for you and complete the call.

Take a look at the first part of this Google I/O talk for more details:

http://www.youtube.com/watch?v=_KBHf1EODuk

Answer 2

0. TL;DR

For the impatient coder, a working version of the following implementation can be found on GitHub. This is the same answer written on another Stack Overflow post.

After rewriting the login activity code several times in many different apps, the easy (and not so elegant) solution was create the Google API client as a Application class object. But, since the connection state affect the UX flow, I never was happy about with this approach.

Reducing our problem only to the connection concept, we may consider that:

1. It hides the Google API client.
2. It has finite states.
3. It is a (rather) unique.
4. The current state affect the behavior of the app.

1. Proxy Pattern

Since the Connection encapsulates the GoogleApiClient, it will implement the ConnectionCallbacks and OnConnectionFailedListener:

@Override public void onConnected(Bundle hint) {     changeState(State.OPENED); }  @Override public void onConnectionSuspended(int cause) {     changeState(State.CLOSED);     connect(); }  @Override public void onConnectionFailed(ConnectionResult result) {     if (currentState.equals(State.CLOSED) && result.hasResolution()) {         changeState(State.CREATED);         connectionResult = result;     } else {         connect();     } } 

Activities can communicate to the Connection class through the methods connect, disconnect, and revoke, but their behaviors are decided by the current state. The following methods are required by the state machine:

protected void onSignIn() {     if (!googleApiClient.isConnected() && !googleApiClient.isConnecting()) {         googleApiClient.connect();     } }  protected void onSignOut() {     if (googleApiClient.isConnected()) {         Plus.AccountApi.clearDefaultAccount(googleApiClient);         googleApiClient.disconnect();         googleApiClient.connect();         changeState(State.CLOSED);     } }  protected void onSignUp() {     Activity activity = activityWeakReference.get();     try {         changeState(State.OPENING);         connectionResult.startResolutionForResult(activity, REQUEST_CODE);     } catch (IntentSender.SendIntentException e) {         changeState(State.CREATED);         googleApiClient.connect();     } }  protected void onRevoke() {     Plus.AccountApi.clearDefaultAccount(googleApiClient);     Plus.AccountApi.revokeAccessAndDisconnect(googleApiClient);     googleApiClient = googleApiClientBuilder.build();     googleApiClient.connect();     changeState(State.CLOSED); } 

2. State Pattern

This is a behavioral pattern the allow an object to alter its behavior when its internal state changes. The GoF Design Patterns book describes how a TCP connection can be represent by this pattern (which is also our case).

A state from a state machine should be a singleton, and the easiest away of doing it in Java was to create Enum named State as follows:

public enum State {     CREATED {         @Override         void connect(Connection connection) {             connection.onSignUp();         }         @Override         void disconnect(Connection connection) {             connection.onSignOut();         }     },     OPENING {},     OPENED {         @Override         void disconnect(Connection connection) {             connection.onSignOut();         }         @Override         void revoke(Connection connection) {             connection.onRevoke();         }     },     CLOSED {         @Override         void connect(Connection connection) {             connection.onSignIn();         }     };  void connect(Connection connection) {} void disconnect(Connection connection) {} void revoke(Connection connection) {} 

The Connection class holds the context, i.e. the current state, which defines how the Connection methods connect, disconnect, and revoke will behave:

public void connect() {     currentState.connect(this); }  public void disconnect() {     currentState.disconnect(this); }  public void revoke() {     currentState.revoke(this); }  private void changeState(State state) {     currentState = state;     setChanged();     notifyObservers(state); } 

3. Singleton Pattern

Since there is not need to recreate this class repeatedly, we provide it as a singleton:

public static Connection getInstance(Activity activity) {     if (null == sConnection) {         sConnection = new Connection(activity);     }      return sConnection; }  public void onActivityResult(int result) {     if (result == Activity.RESULT_OK) {         changeState(State.CREATED);     } else {         changeState(State.CLOSED);     }     onSignIn(); }  private Connection(Activity activity) {     activityWeakReference = new WeakReference<>(activity);      googleApiClientBuilder = new GoogleApiClient            .Builder(activity)            .addConnectionCallbacks(this)            .addOnConnectionFailedListener(this)            .addApi(Plus.API, Plus.PlusOptions.builder().build())            .addScope(new Scope("email"));      googleApiClient = googleApiClientBuilder.build();     currentState = State.CLOSED; } 

4. Observable Pattern

The Connection class extends Java Observable, so 1 or more activities can observe the state changes:

@Override protected void onCreate(Bundle bundle) {     connection = Connection.getInstance(this);     connection.addObserver(this); }  @Override protected void onStart() {     connection.connect(); }  @Override protected void onDestroy() {     connection.deleteObserver(this);     connection.disconnect(); }  @Override protected void onActivityResult(int request, int result, Intent data) {     if (Connection.REQUEST_CODE == request) {         connection.onActivityResult(result);     } }  @Override public void update(Observable observable, Object data) {     if (observable != connection) {         return;     }     // Your presentation logic goes here... }