As I start working on some stuff, I have been thinking of this. Essentially when you are dealing with mobile devices, by their very nature they are disconnected in nature, and not always on a network (such as desktop or laptop). In multi-user environments, the challenge is how to you keep the data concurrent between the “online” and “offline” version? Typically there are two scenarios either you do optimistic concurrency or pessimistic concurrency. The earlier being a device (rather a client/user), submits both the currents and previous state and then the data is updated only if there have not been any changes since the device last synched. Pessimistic locking is when the application locks all the records the device intents to update - this of course is not a good idea.
But, in real life, neither of these issues are really ideal. How best to deal with situations where e.g. a sales person who is on the road could not (or does not) connect to the network to synch up and the person in the office updates the record? How do you deal with those situations. One solution is to update only the changes fields, and the rest are either rejected or the user needs to manually confirm each change and pick which ones take precedence. This along with the fact that in real life data can be segregated to some extent on a user level would suffice? Another thing to dwell upon, for most Mobile applications (especially disconnected), going the SOA way is what makes more sense. Since each time you sync up or submit something (if its on gprs for example), your client running on the device should just consume the service and really cannot be bothered by any more details than that (more on this on another post soon).
But, still seems quite fragile with lots of areas for failure. What are you thoughts? Is there a better way to do this that would make it more robust?