Comments on: Cocoa Tutorial: Sync Services without Core Data

By: Agent Bangla

Agent Bangla — Mon, 30 May 2011 10:02:04 +0000

Hellow Marcus,

Thanks for the great tutorial. I have found it handy as I am trying to develop an application that can read/write iCal data from Calendar.SyncSchema. I am finding it hard to understand the effects of Sync Schema relationships. Could you please help me to understand, how the schema relationships are maintained in your project or more specifically with ISyncSessionDriver? Thanks

By: newacct

newacct — Tue, 18 Jan 2011 23:13:50 +0000

for (NSString *recordID in [[self recordLookup] allKeys])

should be written as

for (NSString *recordID in [self recordLookup])

By: Ross P

Ross P — Wed, 25 Aug 2010 16:38:32 +0000

So, what does “last modified” really mean?

By: Marcus Zarra

Marcus Zarra — Wed, 25 Aug 2010 15:41:50 +0000

No, clocks can and do change so timestamps can never be trusted in syncing.

By: Ross P

Ross P — Wed, 25 Aug 2010 15:39:01 +0000

But, if the client and the truth on both on the same desktop, then all the timestamps would be using the same clock — so no issue as to clock accuracy. Plus, if “conflict resolution” can be resolved by “last modified”, then doesn’t this suggest that timestamps really are used?

By: Marcus Zarra

Marcus Zarra — Tue, 17 Aug 2010 02:12:30 +0000

I have already answered this question twice. The truth is on the desktop. There is no server. Think of MobileMe as the only existing sync client that is external to the desktop that sync services is being run on.

In addition, Core Data creates a delta file between syncs; even when the sync server is sitting right there. The delta file is a file that records what objects have changed since the last sync. Core Data then uses that delta file for the next sync to make it faster. On the desktop this file is called the fast sync file. It is part of the Sync Services framework that is added onto Core Data on the desktop.

Keeping track of timestamps is a bad idea in syncing because no two clocks are exactly the same. Keeping a delta of what has changed (Core Data actually keeps this at the entity level) is the most sane way to keep track of what needs to be synced next.

By: Ross P

Ross P — Tue, 17 Aug 2010 02:06:44 +0000

So, let’s start back at the top, and assume we are using (or trying to use) Apple Sync Services. In cases where the clients (assume Mac laptops traveling on airplanes) are NOT always connected to the server (assume a Mac desktop back at the office), a sync CANNOT take place after each change at a client, but must be done on a delayed basis. In such cases, how does Core Data KNOW that an entity or property has changed? Does it compare the “Last Modified” timestamp to the Last Sync timestamp? Does it set a flag at the entity level and then clear those flags after a successful sync? Does it set a flag at the property level and then clear those flags after a successful sync? Does it create a temporary snapshot at the beginning of a sync session and then permanently save that snapshot after the sync completes successfully?

By: Marcus Zarra

Marcus Zarra — Tue, 17 Aug 2010 01:57:28 +0000

Sync Services was built long before the iPhone was on the drawing board. It is designed for sharing data between multiple applications (two different browsers sharing bookmarks) and for sharing data through MobileMe. Both of which are extremely useful.

By: Ross P

Ross P — Tue, 17 Aug 2010 00:33:18 +0000

Then, what’s the point of Apple’s “Sync Services Programming Guide”?

By: Marcus Zarra

Marcus Zarra — Mon, 16 Aug 2010 21:36:12 +0000

There is no built in sync’ing mechanism at this time for iOS that a 3rd party developer can access. There are a few open source and other third party solutions being developed such as ZSync.

By: Ross P

Ross P — Mon, 16 Aug 2010 21:28:55 +0000

Just trying to assess the feasibility of investing in the development of an application that requires sync and might potentially be integrated with Contacts.

By: Marcus Zarra

Marcus Zarra — Mon, 16 Aug 2010 21:23:45 +0000

That is an Apple application which has absolutely nothing to do with this topic. Apple is using a PRIVATE API. They could be using Sync Services or little furry rodents. Doesn't matter, its a private API.

3rd Party Developers cannot use Sync Services on the iPhone at this time even if it does potentially exist for Apple to use.

Is there a reason you are going down this path or are you just trying to wind me up?

By: Ross P

Ross P — Mon, 16 Aug 2010 21:18:23 +0000

So, if I have an iPhone to use while traveling, and a Mac desktop back at my office, and I want to keep my Contacts in sync at all times (when I have an Internet connection for the iPhone), how do I do that?

By: Marcus Zarra

Marcus Zarra — Mon, 16 Aug 2010 21:12:58 +0000

It does not exist on the iPhone as a public API and the hooks for Core Data are also not in any of the public API. So at this time it does not exist on the iPhone.

By: Ross P

Ross P — Mon, 16 Aug 2010 21:07:44 +0000

Interesting. In Apple's Sync Services Programming Guide, it states "Users might have several computers, at home and at work, an iPhone, an iPod and other cell phones. Users will want to automatically sync data on all their computers and devices—especially, contacts and calendars which are supported on most devices."

That appears to say that sync services DOES exist on the iPhone.

By: Marcus Zarra

Marcus Zarra — Mon, 16 Aug 2010 19:44:00 +0000

There is no sync services on the iPhone.

IF there were then it would keep a delta file as I mentioned.

Without a delta file then each property of each record would need to be compared to determine what has changed.

By: Ross P

Ross P — Mon, 16 Aug 2010 19:40:25 +0000

No, I’m talking about a case where the “client” is an iPhone (for example) that may not always be connected to a server (for example, a change is made while traveling on a plane). So, when the sync does occur, the client must know what changed since the last sync. Thus, my question — how does it know what changed? Does it compare the “Last Modified” timestamp to the Last Sync? Does it set a flag at the entity level and then clear those flags after a successful sync? Does it set a flag at the property level and then clear those flags after a successful sync? Does it create a temporary snapshot at the beginning of a sync session and then permanently save that snapshot after the sync completes successfully? Does it find some other way to identify changes?

By: Marcus Zarra

Marcus Zarra — Mon, 16 Aug 2010 17:08:51 +0000

The truth database is on the same operating system as the application so the client is always connected to the server.

In addition, both sides keep track of deltas since last sync.

By: Ross P

Ross P — Mon, 16 Aug 2010 16:45:30 +0000

In cases where the clients are NOT always connected to the server, a sync CANNOT take place after each change at a client, but must be done on a delayed basis. In such cases, how does Core Data KNOW that an entity or property has changed? Does it compare the “Last Modified” timestamp to the Last Sync? Does it set a flag at the entity level and then clear those flags after a successful sync? Does it set a flag at the property level and then clear those flags after a successful sync? Does it create a temporary snapshot at the beginning of a sync session and then permanently save that snapshot after the sync completes successfully?

By: Marcus Zarra

Marcus Zarra — Thu, 28 Aug 2008 18:43:42 +0000

Thanks smorr, glad you liked the article.

BTW, if any who reads this or any other article and feels the need to respond on Twitter -- DON'T!

I will not respond to twitter comments about CIMGF. Put the comments here where they can be preserved and used by the other readers.

Thanks!