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.
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
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.
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.
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.
The Featured Discussion Board Post this week is Show name from Phone Number Database for incoming call started by holehenrik
The developer wants to notify users when any “special” contacts (from a database of several thousand numbers) call the Windows Phone device. Windows Phone has no mechanism to run an application when the phone gets an incoming call so the solution is not obvious.
Following a brainstorm with other developers the original poster arrived at the solution of adding a customized contact store with all the special numbers. The contact store could be hidden in the contact list through filters in the contacts setting. In this way the user gets notified of the special numbers, but is not forced to have all the numbers displayed when sorting through their contacts.
This discussion is a good example of how just sharing your problem can often be enough to lead to you finding the solution yourself. That’s what the community is all about!
Keep those interesting questions coming!
See About Featured Discussion Board Posts for more information.
It’s quite common (I’ve seen/heard it several times) for people to want to make web requests from their app and have a very long time out. I.E. a timeout longer than 60 seconds.
Despite what you try there’s no way to do this though.
That’s right. Internally your web request will time out after sixty seconds. This means that while you can create a shorter timeout, you can’t create one longer than this.
This shouldn’t matter!
60 seconds is a lifetime on a mobile device. As a user, would you want to stare at your device for over a minute while your wait for new data to be loaded? Of course not.
But what if the server takes a long time to generate the data to return?
Then I’d suggest that this should be addressed in different ways:
- Have the server process faster.
- Have the server return some of the data initially while it prepares the rest for later.
- Have the server return some cached data while it gets the latest.
- Have the server push the data when it is available rather than relying on the app making requests for it.
Ultimately the “best” solution for this scenario will depend on your app, the data and the server. What you shouldn’t do though is have the person using your app wait any longer than they absolutely have to.
Update: See a follow up post at Alternatives to long web requests with long timeouts