Session expire design pattern [closed]

Not to raise this question from the dead, but since it hasn't been answered I'll give my input.

What I chose to do for this scenario was to store the creds in the keychain (or wherever, really), and then I subclassed an HTTPClient to check whether to refresh or not before every call. This way, I can identify a refresh is needed, perform it, and retry the call all in one step as well as being able to send an error block up the chain if necessary to handle any cases in which the user could NOT be refreshed accordingly.

This seems to be in line with what you are (or probably were) trying to accomplish. No need for notifications or any of that jazz, and you can write it once and reuse it throughout the entire app by sending your calls through that subclassed HTTPClient.

EDIT: Bear in mind, you should remember to allow any authentication calls to pass!

What you've asked is how to deal with session expiration. The others have answered your question. But I think you're asking the wrong question. Let me explain.

What we want is a design pattern for user sessions on iOS. We need to look at it from the point of view of the iOS device:

1. User installs the app
2. User authenticates with details and a session token is returned
3. The app then stores the (secret) session token on the device
4. Any future requests include the session token

Conclusion: Any API designed for iOS shouldn't expire the session token. It's simply kept secret on the device.

So from my experience the answer to your question about a design pattern for session expiration is basically:Do not use session expiration when using an API for iOS.

One of the biggest iOS REST API's out there is doing it this way, and I would have to agree.

You are mentioning two things in your question which seem key to answering it:

A) the app is in a state with data that could be lost if the user is not logged in.
B) the app needs to log back in to save the data.

If these are the constraints you should work around them accordingly:

1. Devise a scheme in which you can save changes locally. Keep track of the syncing state with the server.
2. If login status changes and something unexpected happens, unobtrusively alert the user and give her the opportunity to fix it.