views:

111

answers:

3

I am developing a Windows Phone app where users can update a list. Each update, delete, add etc need to be stored in a database that sits behind a web service. As well as ensuring all the operations made on the phone end up in the cloud, I need to make sure the app is really responsive and the user doesn’t feel any lag time whatsoever.

What’s the best design to use here? Each check box change, each text box edit fires a new thread to contact the web service? Locally store a list of things that need to be updated then send to the server in batch every so often (what about the back button)? Am I missing another even easier implementation?

Thanks in advance,

+1  A: 

You might want to look into something similar to REST or SOAP.

Each update, delete, add would send a request to the web service. After the request is fulfilled, the web service sends a message back to the Phone application.

Since you want to keep this simple on the Phone application, you would send a URL to the web service, and the web service would respond with a simple message you can easily parse.

Something like this:

http://webservice?action=update&id=10345&data=...

With a reply of:

Update 10345 successful

The id number is just an incrementing sequence to identify the request / response pair.

Gilbert Le Blanc
+2  A: 

Hi Will,

Data updates to your web service are going to take some time to execute, so in terms of providing the very best responsiveness to the user your best approach would be to fire these off on a background thread.

If updates not taking place (until your app resumes) due to a back press is a concern for your app then you can increase the frequency of sending these updates off.

Storing data locally would be a good idea following each change to make sure nothing is lost since you don't know if your app will get interrupted such as by a phone call.

You are able to intercept the back button which would allow you to handle notifying the user of pending updates being processed or requesting confirmation to defer transmission (say in the case of poor performing network location). Perhaps a visual queue in your UI would be helpful to indicate pending requests in your storage queue.

You may want to give some thought to the overall frequency of data updates in a typical usage scenario for your application and how intensely this would utilise the network connection. Depending on this you may want to balance frequency of updates with potential power consumption.

This may guide you on whether to fire updates off of field level changes, a timer when the queue isn't empty, and/or manipulating a different row of data among other possibilities.

General efficiency guidance with mobile network communications is to have larger and less frequent transmissions rather than a "chatty" or frequent transmissions pattern, however this is up to you to decide what is most applicable for your application.

Mick N
That's what I thought. Was hoping that someone would point me to a sync framework on the phone that just does the work. I think I'll implement a local storage queue that gets written to every time a UI action occurs (to improve speed) then have a background thread that fires every "n" seconds and synchronizes the server.
will
A: 

There is the Microsoft Sync Framework recently released and discussed some weeks back on DotNetRocks. I must admit I didnt consider this till I read your comment.

I've not looked into the sync framework's dependencies and thus capability for running on the wp7 platform as yet, but it's probably worth checking out.

Here's a link to the framework.

And a link to Carl and Richard's show with Lev Novik, an architect on the project if you're interested in some background info. It was quite an interesting show.

Mick N