Last week I wrote about Mobile Cloud Computing and potential problems related to server throughput. Another problem mobile developers need to think about is what to do when a request to the server fails. You need to try again at some time but when?, how many times? and at what point do you give up and ask the user to ‘try again later’?
There’s a classic situation that when a server request fails, the app (or sometimes the user) re-tries too soon and this, in itself, can compound the problems because the server ends up with too many requests to handle that prevents the server from recovering.
However, the above is an extreme and rare case. We have to remember that most of the time the failure is because the phone is outside data coverage and the request never reaches the server. In this case, trying again probably won’t work anyway. Then there’s the added complication of whether the request is related to something the user has done (and is waiting) or whether it is being done in background.
In almost all cases where the user is waiting, it’s usually best to pass the retry back to the user. This way they can position themselves so as to get better data coverage. In cases of background requests, if the operation isn’t time critical (the app or the server doesn’t need the data soon) then it’s sensible and easy to wait a relatively long period (hours) before retrying. If the data is time critical then you usually need some kind of backoff strategy to prevent a) depleting the battery due to continually trying and b) if the request is getting through to the server, prevent the server from being overloaded. Most backoff strategies involve increasing the time between successive retry failures and also sometimes having some kind of ‘give up’ strategy where the user needs to be told connection isn’t possible. Having said all this there isn’t ‘one case fits all’ and it’s down to your apps’ particular circumstances.
This kind of stuff is usually left to the developer. However, in many cases, it has side effects on the user experience, the server side and answers provided by end user support. It’s best done upfront as part of the requirements/design but even when it isn’t it should be documented openly somewhere so everyone knows what should be happening.