Two-way sync with iPhone and web service

Question

Yes, I know that there are several issues related to synchronizing with iPhone and web databases, but none of them helped me. I also did a lot for googling, but rarely came across information about two-way synchronization. Maybe I just used the wrong keywords.

---

I am creating an application right now and I came up with the idea of ​​adding two synchronizations to my application and my web service. My first thought was that it would be ridiculously easy, but it turned out that it was not so simple. I found a couple of problems and some solutions to my problems, but I would like to hear from you guys if these souls will create other problems or if these solutions will be good or bad.

The idea of ​​my application helps me synchronize my notes, which I will take with my iPhone at work or at home using a web application. These two ends should always be synchronized, because I do not know which device (iPhone or computer) I will use to edit, edit or just read my notes.

What I have on both sides:

For my web service (and web application) I will use rails and I think mysql is on the DB side. On iPhone, I will use SQLite DB with Objective-C wrapper (FMDB). Both will exchange data via JSON (using the JSON framework on the iPhone side).

My ideas so far:

• The primary key must be unique on both sides.

  I will use the UUID as the primary key. I think this is a unique solution on both sides and it will not make any duplicates (at least I hope).

• Changes for data changes

  Each change will be saved as a revision using the SHA1 key, which I will create from date + note data . The audit object also includes the following information:

  • the date
  • which notes that the object belongs to this version
  • Changes made on which device?
  • what sings? (usually I'm not sure if I include this information).

My "solution" so far I will track every modification (create, update, delete) in the histroy table with revisions on both sides. On the iPhone side, I first update my history table from the web database, and then commit my changes to the web database. That should work, right?

This doesn't sound so bad to me, but my question here is how can I handle conflicts? I do not want to disturb the user with messages on how to deal with conflicts.

Overview of my questions:

• Is my “decision” good or bad? What should I change to make it better?
• How can I handle change conflicts so that the user does not notice them?
• Do you have any resources that I could read about a two-way approach?

EDIT:

Thank you all for your answers. Now I know that I am not alone with this “problem”, and there is no simple and suitable solution for all applications. I assume that so far I am well versed in my ideas or decisions, and I will try to come up with synchronization rules.

My idea is still: I will develop it as simple as possible and I will use it for my needs. Solve the problems that I discovered when using and syncing. After that, I will invite my friends to check and solve the problems that they have. I think that this way I can find real rules for synchronizing my data with the Web, because I see what people really do and where the problems are.

What do you think?

Answer 1

"It depends".

Everyone loves this line in their answers.

Two-way synchronization comes down mainly to conflict resolution. And only you, as an application developer, can come up with conflict resolution rules.

Without conflicts, synchronization is very simple.

One-way synchronization is “easy” because it simply synchronizes in two ways, except that conflict rules always favor one side. "Make it look." A simple rule.

A clear two-way synchronization is not so complicated, you just need to record the specific changes that were made, and when they are done, then when you synchronize, you take this change log on each side, merge them into one log, and then apply this log to each side since the last time they were in sync.

With certain changes, I do not mean "recording changes" because it is too coarse. Rather, you want to know what the "lastName" record has changed. It has changed on 01/01/2011 12:23:45.

When participant A says that lastName changed to "Johnson" on 01/01/2011 12:22:45, and side B says lastName changed to "Smith" on 01/01/2011 12:22:46, then " Smith "is the right answer because it is the last.

But wait, did you see what happened there? I just pulled the rule out of thin air. "Last victories." Perhaps this does not work for you, maybe you have different rules. "It depends".

So, really, it all comes down to the rules. You can make it as small as you want. There will always be conflicts. What are the rules for?

So, you need to decide what your application is.

Answer 2

In fact, I believe that the only problem in any two-way synchronization occurs only in case of conflict. Indeed. Take, for example, any version control system (svn, cvs, git, etc.). They resolve this conflict in more detail because they break the file itself and they check for line conflicts, so changes in two different parts of the file are not considered conflicts. However, I believe that this solution would not be feasible, because it is a pain for its implementation :))

If you decide to handle conflicts at the level of notes, rather than lines, then perhaps at the end of the day you will need to find some kind of business rule that determines what happens when changes occur that lead to a conflict. Features:

• Use the latest change. Redefine the elder. It is easy.

• The solution that Dropbox uses, I saw it a couple of times when we changed the same document on several computers, is that it creates several files that add a suffix, so that users know about changes in several machines. Something like this you could easily do with notes.

I'm not sure I helped though ... Moszi