How to correctly use Google Plus Sign In with multiple activities?

Question

What would be a good/recommended way of tying up the Google+ api client life cycle with the flow of a multi-activity app? Make the activities depend on the onConnected api client method to trigger its functionality, use it as a one-time only "activation" thing, or maybe something else entirely?

I am currently struggling to understand how to correctly use the Google+ sign in in my Android app, which has more than one activity.

The idea is, in a first phase, to use the G+ sign in just to authenticate the user and be able to get her email, to send notifications and stuff like that. Eventually I plan to roll out other Google functionality like maybe Maps or other Google Play services, so I think it's useful to implement it already.

However, my app is not behaving as expected, and I have narrowed down the issue to the fact that I have not yet understood the G+ sign in app cycle when more than one activity is present.

What is the correct or recommended way to implement this auth method? is there maybe a pattern of sorts that could guide me in the right direction?

For example, I have found a very simple diagram of the life cycle of the api client, but how does this relate to the app flow?

Initially I have a Login Activity, where I put the sign in button. Following Google's guide I am able to sign in, and when the onConnected method is called, I start the Home Activity (kinda like the dashboard or main screen of the app).

This works somewhat. For example, what would be a good way of handling the onStart and onStop for each activity? should I re-connect and re-authenticate the api client every time for every activity? So maybe its a good idea to have a BaseActivity to implement all this.

Another issue is, should I use the same api client object and pass it around somehow, or maybe store it in the Base Activity class? or should I be creating and initializing a new api client object every time?

How about just using the Login Activity to authenticate with G+ and then just get the email and store it in a local database, and flag the user as "authenticated" or "active" or something. That would prevent me from having to re-authenticate every time the app is closed or connection is suspended, even allowing for some battery savings.

The app is not really using G+ posting or any other functionality like that. Ideally it should work well offline, and only need connection for stuff like initial authentication or other one-time only things.

Any suggestions or pointers in the right direction are very much appreciated.

Edit: I have read every guide and tutorial I could find, that uses Google+, and every one of them addresses this from a single activity perspective. I would think this is a common enough problem that it would benefit from a pattern or at least a general guideline.

Answer 1

Reconnecting for each activity is absolutely fine. Broadly there are 3 ways I've seen of people implementing this:

1. Implement mostly in a baseactivity, and have the others extend that. This is connect/disconnect in each activity, but with code in only one place.
2. Implement connect/disconnect in a fragment, and include that in activities where auth is needed. This is helpful if you already have a baseactivity you can't extend (e.g. some games cases).
3. Implement a service to connect/disconnect. This can fire a broadcastintent or similar if sign in is required.

All of these work, and I've seen them all used in real world apps. The main thing to remember is to separate the 99% logic (user is either signed in or signed out, and you are being informed of that) from the relatively rare "signing in at this present moment" use-case. So for example, you might have onConnected/onConnection failed firing a lot, but mostly you are ignoring or just flipping a bit as to the state of the application. Only on a screen with a login button do you need the connection result resolution and onActivityResult stuff. Think of the google play services connection as being mostly about asking for the state of the user, rather than signing them in, and you should be fine.