0

I'm trying to implement a timeout mechanism for a user's login session in my app ie. If user has not interacted with my app for say 10 mins then when he uses the app next (regardless of whether the app was previously in the background or currently in the foreground) he should be taken to the login screen.

My current implementation uses:
- a singleton instance of a Java Thread (call it 'TimeoutThread') from my 'BaseActivity' (all my activities except the LoginActivity extend BaseActivity)
- so the singleton 'TimeoutThread' will be started only the first time any post-login activity starts up.
- 'TimeoutThread' will simply keep track of the 'lastUserInteractionTimeStamp' inside a while() loop with a Thread.wait()... so it wakes up every 2 secs, checks if the (currentTime-lastUserInteractionTimeStamp) is greater than say 10 mins and if yes then it'll trigger some callback if callback object is not null (the callback is made null whenever the app goes into background, etc)

This method works fine right now.

My concern is that since this thread wakes up every few secs (Thread.wait() inside a while(true) loop) even when the app goes into the background (eg. user presses Home button), it will cause a battery drain.

I've been unable to find a good link to explain the effects of keeping such a thread. I did find links for power optimization, scheduling recurring tasks etc (pasted below) but couldn't directly find my answer there.
https://developer.android.com/training/monitoring-device-state/index.html
Scheduling recurring task in Android

Can anyone critique this approach / suggest a better one ?

Community
  • 1
  • 1
dangling_refrenz
  • 325
  • 3
  • 12
  • Use AlarmManager with a Service. The worker thread by itself could end up getting killed by the system. Also, may I ask why you're timing the user out? Is this a security feature? Or a feature because you don't want your server to be overwhelmed? – Stephan Branczyk Mar 09 '15 at 05:12
  • Just for basic security. I did read about AlarmManager and Service but that would wake the app even if the device was in sleep mode and that seems overkill for me. Since I keep track of the 'lastUserInteraction' timestamp, it doesn't matter if my app is never woken up while it is in the background because whenever it does come into foreground, the Timeout thread will run and see that we're past the timeout period and trigger the callback. And in case the app was killed and restarted, the timeout expiry doesn't matter – dangling_refrenz Mar 09 '15 at 05:14
  • Actually, there is no need for a worker thread or an AlarmManager, you could just check the last time the user used the app when the user tries to restart or resume the UI thread of your application. And you wouldn't need a thread for that. – Stephan Branczyk Mar 09 '15 at 05:16
  • Ahh that's a good point, I totally forgot to mention another thing - while the app is in foreground, this thread also checks for a 'LogoutWarning' interval (which is less than the timeout interval) and shows a warning dialog to the user. So I guess I could just keep the thread for doing that warning part and use your suggestion to check for timeout and trigger the logout flow from the BaseActivity's onResume(). Thanks ! – dangling_refrenz Mar 09 '15 at 05:20
  • 1
    Don't use a LogoutWarning. Use the same period of time. And please, whatever happens, do not use a modal dialog. If the session your server gives you is too short, the Android system should just be able to re-authenticate without user intervention. Also, if the user is already using a security pattern/pin on his phone, you should avoid presenting the user with a second login screen. One is more than enough. There is a reason apps like Square and Mint are getting far better user reviews than most other banking apps. Most banking apps do exactly what you're doing. – Stephan Branczyk Mar 09 '15 at 05:25
  • Ok will look into that too, it does kinda make sense though it would be dependent on use cases for certain apps. BTW suppose I did actually have to use a background thread for like this one for some hypothetical use case, do you have any idea about the battery impact of that (ie. would it be against good design to do that, etc) ? – dangling_refrenz Mar 09 '15 at 06:33
  • Also, if you would put your comments as an answer then I can accept that answer. Thanks ! – dangling_refrenz Mar 09 '15 at 06:34
  • Thanks, but there is no need. If I did provide an answer I would feel the need to actually work on it to make it better, even if you do accept it. And I'd rather not. – Stephan Branczyk Mar 09 '15 at 06:46

0 Answers0