I came across an issue that should be all too common but strangely I don’t find much info about it.
Use case:
While app is in foreground a refresh is started
User minimizes the app
Some time passes by
User opens the app again
A “welcoming” timeout message is shown
This is not the best UX since the user didn’t initiate the refresh (or even if he did, it was so high on his priorities that he chose to go do something else )
How do you deal with this situation?
One obvious solution is to check app state in the request callback and skip the user alert if app is just coming to foreground. However, this doesn’t look very elegant and my intuition tells me that there should be a better way of handling this situation. Completely skipping the whole callback is not always an option as sometimes we need to update the UI (remove a loading indicator for example).
Generally, I try not to show any network errors when (a) the user didn’t initiate AND (b) the network operation isn’t critical AND (\c) the error is network availability related (not because of real server issues – like a bad request). So, an app-initiated refresh would be an example. There’s not much consequence to failing and we can just try again when the network is available.
When I show a network error, I try to make them non-modal – meaning something like a toast that self-clears or an indicator.
Doing that, I haven’t felt it necessary to worry about backgrounding effects – if you are still worried about it, what you have done is pretty much how you have to do it with normal requests. You could use Notification Center if the coupling is worrying you.
I don’t recommend it (because usually it’s overkill), but you can initiate fetches that complete out-of-process and continue in the background (meaning, they will succeed in your scenario). This works really well for long uploads because backgrounding in the middle is really common and it would be a critical failure. This talk has a pretty good overview: While Your App Was Sleeping: Background Transfer Services
)