We have been working on a lot of apps on mobile platforms, especially the iPhone and as I mentioned in my previous post, we keep coming back to the problem of data integrity – in the cases where there is a server component and data needs to be synced up with the server.
Apps that depend on data on a server have several options of accessing data on servers. There is the ubiquitous RSS – get and read feeds. This is great for reading data off a server but quickly loses relevance when the application has a more complex data model and the app needs to write data to the server. The problem of writing data to server is easily solved through web-services, REST services and the likes through which you can talk to a service that takes care of translating your data into the server’s database.
The problem however is keeping the data on the device in sync with the server component. This problem is prominent on mobile devices because while your app on the device is working and live, there is not guarantee of continuous sustained connectivity with the server. Network connectivity is unpredictable and unavailable based on where you are, there are other problems that may interrupt your application. For example on the iPhone, an incoming phone call may interrupt your app while the data is being synced with the server. Your app or your device may crash.
Given all these possible scenarios, how do we ensure that data on the device is always in sync with the data on the server and secondly how do we ensure the integrity of the data given the number of breakages and opportunities for data corruption given the very plausible scenarios I mentioned above.
Over the next few weeks, as we evolve and implement our solutions to this problem, I plan to write a series of posts that looks at this problem in depth and possible solutions and their feasibility. One of the obvious first things we looked at was what are apps out there currently doing to address this issue of data integrity? Answer? Surprisingly little. Most apps out there simply don’t allow the user to do anything that requires server connectivity if the apps detect that there is no connectivity. This is not a great solution, and is primitive – especially given what we have come to expect on the desktop. Solutions like Google gears and soon the offline support in HTML5 make what’s being done on the mobile platforms look primitive.
So, why are we looking at this problem now? Of course we are motivated by the fact that so many apps face this problem but there is no well defined solution and doesn’t look like anybody is looking at it. But perhaps more importantly, technologically the tools are in place at this moment in mobile platforms for us to come up with a solution. The tools and utensils are there, the ingredients are all laid out for us, nobody has come up with a recipe yet or even entered the kitchen.
The iPhone, the Android and soon the Blackberry with v5 of the Blackberry development platform have support for SQLite – a full fledged transactional light weight embeddable database engine on the device itself. The mobile platforms themselves have powerful development kits that allow us to come up with robust solutions in combination with SQLite (and other mobile database engines). The tools are there.
Over the next few weeks, I am going to describe various possible solutions and think through their feasibility and suitability through my posts. I think that would be the best way to get peer feedback and ideas as we hardly know everything there is to know and your input would be invaluable.
Keep an eye on this space.
