Building on Apple Sync Services
- Publishing a Schema
- Creating a Sync Schema
- Data Class Properties
- Entity Properties
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
As detailed in the previous two articles in this series (Syncing Your Data the Cocoa Way and Getting in Sync with OS X), Apple’s Sync Services, which were included with OS X 10.4 "Tiger," enable an application to synchronize data with other applications on the same computer or on another computer via .mac. This synchronization is performed by using a published schema that describes that data and how the individual pieces of data are related. This schema, known as a sync schema, is published by the application that originally designs the schema. For Apple’s applications that utilize the sync services, their schemas are available for review in the /System/Library/SyncServices/Schemas directory. Apple has also published a document describing these schemas in detail, which is available on its developer website.
If an application does not use the existing Apple schemas, it is possible to create a new schema that accurately describes the data that the application wants to make available for synchronization. This schema is generally stored inside the application’s bundle and is then published with the SyncManager when the application starts up. Based on the definitions inside that schema, the data would then be available for synchronization with devices, servers, and/or other applications.
Publishing a Schema
Once a schema has been defined, which will be detailed below, the ISyncManager needs to be passed the schema, as follows:
NSString *syncBundlePath = [[NSBundle mainBundle] pathForResource:@"myApplicationSync" ofType:@"syncschema"]; [[ISyncManager sharedManager] registerSchemaWithBundlePath:syncBundlePath];
Once the registerSchemaWithBundlePath has been called, the ISyncManager will make the schema available to any application on the system (or computer via .mac), and the data can be accessed as outlined in the previous article. If there is an update to the schema, simply re-register the syncschema, and the truth database will work out the differences between its current schema and the new schema being pushed. It is the responsibility of the developer to test this upgrade path and ensure that no data is lost in the conversion.
With this in mind, it is reasonably safe to place the registration code inside the Application’s Delegate by using the -applicationDidFinishLaunching: method. If performance becomes a consideration, it is possible to do some version checking on the schema and register the schema only when the version has changed. The specifics are left up to the reader—based on the current situation and application.