The author of sync-mobile has added another post that discusses scheduling strategies for synchronisation of data. In this post they outline three strategies for scheduling or kicking off a sync:
- SMS – There is definitely a risk that messages can be delayed or might never reach the target but on most networks this latency/risk is pretty low. In fact in NZ they use SMS as a mechanism for paying for parking – the latency is 5-10 seconds which is usually adequate for most scenarios. Don’t forget that Windows Mobile 5+ now has the notification engine means that you can write managed code using the .NST Compacty Framework to intercept SMS messages, even if you application isn’t running!
- HTTP/TCPIP – Their main point with this strategy is that battery life is a premium which I would have to agree with. There is also the additional cost of network traffic (for those countries like Australia/NZ where data is still expensive). This said, since the release of the Security and Messaging Feature Pack for Windows Mobile 5 we have had Direct Push email – this basically establishes a connection to the Exchange server that remains open even when the device goes into standby. There is a great article on MSDN that discusses how you can use this technique in your application. In my experience the drain on battery power is actually not that bad using this technique.
- Scheduled Sync – Ok, now we are talking – this is a technique I have used a couple of times. The biggest issue here is that in managed code any sort of timer you use has the issue that it won’t be triggered if your device has gone into standby (which it is likely to do in order to extend battery life). This is where you really need the power of the Smart Device Framework from the guys at OpenNETCF so you can use the Large Interval Timer in order to wake your application up.
It would be great to hear what other techniques people use in order to trigger synchronisations – do you monitor network availability, sync on application startup/usage or do you have other business rules that drive when you synchronise. Do you detect what type of network you are connected to and determine whether you should sync based on the cost of the network (see the Mobile Client Software Factory – Disconnected Service Agent and Connection Monitor blocks for quite a nice implementation of this)