So, I'm integrating with Flurry and trying to figure out when to call FlurryAgent.onEndSession(this);.
I have four activities in my app. As there is currently only one entry point/activity adding FlurryAgent.onStartSession(this, Globals.FLURRY_API_KEY); is easy. But the problem with stopping the session is the app can be closed from any one of the four activities. Also, onStop() is called each time the app changes the activity on screen.
Has suggestions on how to decide when to end the Flurry session? Taking some advice from another answer, I could use a BaseActivity class and each of my four activities would extend this, I would then place onStart() and onStop() in there. This would solve the issue of littering my code with Flurry start/stop calls but not the issue of when to stop.
My current solution is to build on the above approach and add an exit flag. The base activity will only end the Flurry session if the exit flag is set to true.
Then, in each activity I will look catch key presses such as the back button and home key. If the home or back key is pressed I will set exit to true.
This should have the correct effect but I feel it's a bit hacky.
iOS is nice, where you only need to start the session. It would probably be a good idea to refactor my four activities into one and use Fragments. What do you guys think?
You should call FlurryAgent.onStartSession from every one of your Activity's onStart methods, and onEndSession from every onStop method. As you point out, your app has multiple exit points, since the app can be backgrounded from any Activity. But for most apps following the guidelines from Google, if your user returns to the app after backgrounding it, it will return to this Activity. This should be a new session but if you only call onStartSession from your single entry point the Flurry SDK won't start a new session at that point. If you have three Activities, A, B, C all calling onStartSession and onEndSession this way, and your user navigates from A to B to C, the SDK will not report three different sessions, instead collecting the calls into a single session reported to the dashboard. Let me know if that doesn't make sense.
Using a BaseActivity to factor these calls out to an abstract class is good practice, but make sure to do the same if you use other subclasses of Activity -- BaseListActivity and so on.
(disclaimer: I work on the Android SDK at Flurry)