What are the major challenges of building an iPhone application that synchronizes data with a server via web APIs?

I want to build an application that utilizes the data from a server开发者_StackOverflow中文版, and it needs to synchronize the data in the application with the data entered by other client applications. So, there are some questions:

• How to design the database schema efficiently? Should it replicate the same database schema on the server or should it add some more fields & entities?
• What are the strategies to synchronize the data, on each application start or during some idle state of the application, or something else...
• How to handle conflict of the data entered by the user within the application and data enter ed by another client application.

Any response is welcomed.

Well, you've identified the main challenges in your original question. The real answer is that this has little to do with the iPhone - database replication is just really hard.

Here are some rules of thumb I can offer:

• one-way replication of data is a million times easier than two-way replication, if you can get away with it.

• replication is always easier if the database schema is identical on the client and the server.

• to do two-way replication, you either need to store timestamps for each row on each end, or to store the complete contents of one end on the other end. (ie. the server needs to know the client's most recent status, or the client needs to know the server's most recent status).

• to allow adding rows from disconnected clients, you need to identify your rows using a GUID (or hash, eg. SHA-1), not an autoincrement field. It's possible to keep new client-added rows as "identifierless" until you sync them with the server, but that way lies madness.

• there is no actual good way to do conflict resolution. The imperfect options include last-writer-wins (last person who syncs a modified record gets their copy of the record inserted), three-way-merge (when someone sends a modified record, check which columns they have changed, and change only those columns, thus not overwriting any changes to other columns), split-into-two-records (if two people make changes to the same record, just make two records and assume someone will fix it eventually), and "ask the user" (which is technically the most sound, but requires a lot of UI work and users rarely understand what a conflict even is).