I have just finished reading an excellent article by Forrester’s Michael Facemire who clearly ‘gets it’ with regard to Mobile Offline challenges. Much of what he writes in “Analyst Watch: Mobile’s toughest challenge” concerns two distinct but closely connected topics – Offline CRUD and Conflict Resolution. Over the years we have seen an evolution in this area from a very basic engine to those of today where individual fields on a mobile table can have different conflict behaviours (latest, platform always wins, device always wins and so on).
Around 4 years ago I remember receiving a call from a field engineer who was about to start on his 5th job of the day but could not mark the job as ‘started’. He was using an app developed in Flash Builder for Force.com and was viewing a popup offering him a choice of his record vs a new platform version of this record. He had marked a job record as ‘complete’ when he had no connection. Shortly after, an administrator had corrected the postal code on the platform record. Clearly the business did not wish to interrupt the field engineers (there were a dozen in the field running app) to think about postal codes or any other such changes and definitely did not want to give the field engineer the ultimate decision on what to do with the records. It was at this time that we started seriously thinking about improving Conflict Resolution!
Michael mentions 3 flavours of offline support. First of all ‘Client side read only cache’. This describes applications where the mobile device does not need to create/update data such as the Sales Rep producing quotes that is suggested in the example. We have seen similar apps in the field where engineers view parts and publishing house sales representatives view alternative titles to academic books. To achieve this using the MobileCaddy application you set all mobile tables to ‘Refresh Only’ as in the example below.
Michael then discusses the ‘Last Write Wins’ technique and its usefulness to applications such as Chatter. Clearly where new records are being created or updates (such as to Chatter status) aren’t critical then this is a useful technique. In MobileCaddy we can set fields to be the latest system modstamp as shown below – the system mod stamp is a Salesforce field that keeps track of the last update on the record at record level.
Because Salesforce records the system mod stamp at record level, this approach would still not help out our field Engineer. Clearly he would no longer be interrupted with a popup, but the latest created record (either his or the person in the office) would be recorded wiping losing the ‘loser’s’ changes!
Complete Transaction Synchronisation is then discussed. This is where true robustness is introduced and where a great deal of our effort at MobileCaddy has been placed. As can be seen from the screenshot above, we can give priority at field level to ‘Use Device Value’ or ‘Use Platform Value’. Then, on a conflict’ the value (at field level) is taken from the appropriate ‘side’. Harking back to our field engineer example, the postal code is set to ‘Use Platform Value’ (and is read only on the devie) and the status is set to ‘Use Device Value’. This completely solves the issue we had.
In a follow up article we will look at the special field modstamp which, we believe, provides even more control in the conflict resolution process.
As Michael says ‘Building a robust offline solution may be the most difficult development challenge in mobile.’ We feel he has hit the nail on the head there – we have enjoyed every step of the way building a solution that tackles these issues head on.
