You really don't want to log out the user when the "application" goes in the background, any more than you log out the user of a Web app when the user switches to another tab or minimizes their browser window for a moment. If you were to do either of those things in a Web app, your users would consider your Web app to be an epic fail. Similarly, if the user gets a phone call with a wrong number, or the alarm clock goes off, they'll be rather irritated with you if they have to immediately go back in and sign in when they were just using your app 5 seconds ago. Here, by "irritated", I mean one-star ratings on the Market and nasty comments.
A Web app automatic log out is based upon inactivity, using a server session cookie.
Similarly, when I build a secured Android app, I'll be implementing an inactivity-based mechanism, perhaps something like this:
Step #1: Create a Session
class with a static singleton instance. The Session
object holds the last-accessed timestamp.
Step #2: In each activity's onResume()
, see if the Session
singleton exists. If not, it's a brand-new process, so if this isn't the authentication activity, immediately do a startActivity()
to bring up the authentication activity.
Step #3: Back in each activity's onResume()
, if the Session
object exists, call something like extend()
. This would return a boolean
, true
indicating the session is still good (and the timestamp has been updated to now), false
otherwise. If it returns false
, do the same stuff as if the Session
object were null
.
Step #4: Your authentication activity, upon success, sets up the singleton Session
object with the current timestamp.
Step #5: Your Session
class' extend()
method is where you make the determination if the session is too old.
No matter how the user gets into your application, if the session is too old (or it's a brand-new process), they are forced to authenticate. Yet, if the user briefly is interrupted -- where you and/or the user can define "briefly" -- they don't have to re-authenticate.