Monday, October 14, 2013

Alternatives to long web requests with long timeouts

      ,      3 comments   
Earlier I posted about how you can't create a web request with a timeout of more than the internal maximum of 60 seconds.

I was asked on Twitter about how to have the server tell the app that there was new data for the app to display.

As I said in the original post, the exact method to use will depend on the application but here are the main techniques to consider.

Direct notification
If the app is still running and the server has some new data for the app to display the server can tell the app directly. Either by telling the app to get it or sending it directly.
  • Via a push notification (raw or toast)
  • Via a socket connection - like with SignalR ;)

Smart polling
Having the app just check if there is new data on a predetermined periodic basis isn't the best we can do.
  • If we've told the server we want some data and the server is indicating that it will be some time before the data is ready, the server should be able to provide an indication of how long it will be before the data is ready (based on typical load time, current queue size, etc.) The app can check back after that time. And, of course be given a new time if it isn't ready by then.

Offline notification
Of course if the server is taking it's time to generate (or prepare) the data the app needs then it's possible that the app might not still be running when the data is ready. In this instance the server may want to tell the user that there is data to view when they re-launch the app.
  • The obvious option here is with push notifications (toast and tile)
But less platform specific options may also be valid too. Especially if combined with a custom schema to launch directly into the app.
  • SMS
  • Email

Of course a better alternative to any of the above would be to have the data ready when the the user/app wants it. This could be done either by preparing the data in advance so it's ready when needed or by being able to prepare it very quickly.


3 comments:

  1. Fallon3:36 am

    Good lord, this is the easiest problem on the planet these days.

    The simple answer is to have the server call the client whenever the data is ready!

    It doesn't matter if it takes hours or days if you use any of the real time frameworks like SignalR or Sockets.io.

    We don't build websites that can't communicate this way unless they are of the simple variety.

    ReplyDelete
  2. Matt Lacey8:28 pm

    @Fallon yes it's a relatively simple problem but one I felt was worth writing about as I've noticed a lot of people asking about it recently.
    On Windows Phone it's also a slightly more complicated issue than other platforms as apps don't run in the background and so it's far more likely that the client won't be listening when the data is ready. The idea of having the server do anything other than prepare data when it's asked for and immediately return it is also new to a lot of people.

    ReplyDelete
  3. Fallon10:58 pm

    Good point Matt!

    ReplyDelete