When we should update app with crucial data?

Question

I need to update local db on device with content stored in the external db via internet. This app will be used for making the orders, so the prizes of items must be actual for all the time. At the moment, I have smth like starting screen when we see nice pictures with progress bar and some kind of announcements. Firstly I take from external server the version of db and If it's equal to local version I go to menu screen. If it's not equal I update my local db and then go to the main manu. This screen is only opened when we lunching the app.

I describe how I see WP lifecycle

The application is lunching only first time and to get lunching event next time we need to close app by back button and not always it works like that. I'm not sure but I think when we very quickly start app and close it, the app is deactivated not closed.

When user goes to other app, our app goes to dormant state and when we go to our app back it will be activated (not lunched)

Here is the picture which shows application lifecycle

I took this picture from this site:http://blogs.msdn.com/b/lindsay/archive/2012/04/10/hackready-phone-episode-3-of-7-understanding-windows-phone-s-application-lifecycle-and-state-management.aspx

And my question is when we should update our app?

We can't give a chance to make an order with older data(prizes/products). User can keep our app for weeks in dormant state and in meantime the prize can goes up or down. On the other hand when we would check for updates every time when our app become activated we create a lot of traffic and It would be awkward for user. ( the user is so important person here, because he would be play with it).

What you think about informing app about updates by sending push notification. When the app gets notification, it just showing the update screen and make the job ;) I think It would be the best way, because the app don't need to ask for updates server every time and we don't miss any new content.

Any suggestion and points of view, how would you solve this problem will be priceless for me.

Answer 1

What a great question: When should you update data on the client to ensure that it's always up to date for the person using the app?

Unfortunately, there is no absolute answer to this question that will cover all scenarios for everybody.

It's easiest to handle this situation if price changes happen on a predictable basis, such as overnight or at certain times, and/or on certain days of the week.

If we know that prices only change at certain times of day (or week) we can limit unnecessary network traffic (and therefore delays in using the app) by just checking if we haven't checked since the last time that prices may have changed.

If building an app using Silverlight technologies (which will be the case if targeting 7.X, 8.0 & possibly 8.1) then you should check on app start up when either the Launching or Activated events are fired.
Of course the price may be changed while the app is in use. In this situation you could send a push notification to the app while it is running to tell it to update the data. You may also need to handle the situation where a purchase is attempted but such a notification hasn't been received or yet been acted upon. More on that below.
It is not possible to send a message to such an app when it is not running to have it automatically trigger getting the latest data.

If you want to check in the background (when the app is not running) then you'll need to use a Periodic Background Agent which can download the latest data ready for when the app is next used.

If building an app for Windows Phone 8.1 and using the new application framework (i.e. not Silverlight) then it is possible to trigger a background task to download the latest data from a notification message. You may also want to trigger checking on device starting in case any notifications were missed when the device was not on.
On app start-up you should check for the latest data after an activated or resuming event to check when navigating to (starting) the app.

With any of the above techniques, you can't be sure that the app will have received a message to notify it to update the data, or run the background task to check for the latest data or even been able to get to the server to get the latest data when the app is not running. This is why it makes sense to check on start-up in addition to any checking that is done in the background.

Ultimately, if the price can be changed at any time and the latest price must be used/honoured, it will be necessary to check that the values which are being used on the client with the latest server prices and products when a purchase is actually made. (In reality you'll probably be checking this anyway to make sure that a product that is discontinued or out of stock is not being ordered.)
This should be in addition to any other work that is done to synchronize data at other times.

Answer 2

Hm, i think you shouldn't bind to the app's activation... what if to check for updates every time user is going to make a new order or if he is going to update his current shopping cart? Probably not the whole newest prices, but some kind of hash first, and in case it is different - then pull the whole updated pricing. That seems to be the minimum necessary cases when user should know the latest prices.

Kinda

var serverHash = DataSetvice.PullHash(); // Get the latest hash from the server. Very short message containing only hash (or datastamp)
if (deviceHash != serverHash)
     var updatedPrices = DataService.PullPrices();