The best approach to building a mobile service that's also available when the connection drops?

Question

Hopefully this question will be a good suit for P.SE since it is a whiteboard-level 'how can this be done' conceptual question.

I'm trying to build a product that needs to be available to someone on the move with a mobile device when their connection may be quite poor (due to travelling between cities where 3G coverage is stronger).

For simplicity, let's say the application is an address book.

The user must be able to add/remove/edit all contacts in the address regardless of connection state, then those changes iterated to a central server DB whenever the connection next becomes available (and any changes made on the server since the connection dropped also downloaded).

I was originally building the application with PHP/Symfony working with static pages but this new 'mobile' requirement has made me re-think my front-end technology.

I'm now looking at using EmberJS for my frontend (download all the necessary frontend templates with the initial request, then only update the dynamic parts seems like it would suit my application better than serving an entire static page (and resources) for every request).

I've been implementing Ember-Data with the standard REST Adapter which is working great with my already-existent Symfony2 API, so I've greatly reduced the amount of data being sent/received and the responsive 'feel' of the app but still need to tackle my 'no-connection-available' scenario.

Instinctively, I'm drawn to HTML5's LocalStorage functionality but can see synchronizing data between the localstorage and central DB server being a gigantic headache.

Let's say I add "Bob Smith" to the address book from my mobile when the connection is up. The connection drops. I change the name to "Bob Jones" and then change the name to "Fred Smith" using a desktop with a stable connection. When the mobile re-connects, which update takes precedence?

I saw this question regarding using multiple data adapters (REST and LocalStorage) with Ember and it looks like I'm in for a world of hurt. Should I just build a nice-responsive version of the app/service with Ember/REST Adapter, then roll native mobile apps for the on-the-move version? Will handling data persistence be easier to handle as a native app?

Answer 1

The "no connection" requirement makes me think that a web-based solution is not the best fit here. You might get it to work if the connection was lost after the initial page is shown, but what if the user turned the device on in an area with no coverage.

The best solution, in my opinion, would be a native app that stores the data locally and tries to synchronize periodically with the central database. If during such a synchronization a conflict is detected, the app should ask the user to resolve the conflict.

It might also be worthwhile to investigate existing native apps that are similar to what you are building and see in how far they already support synchronization with an external server. If you are lucky, you would only need to implement the server side of a standard synchronization protocol and have a perfectly working solution.