CloudServices/Sync/FxSync/Developer/ClientAPI: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 13: Line 13:
You're probably sick of writing subclasses by this point, but don't worry: this one is very easy.  I saved it for last because it requires the least code.
You're probably sick of writing subclasses by this point, but don't worry: this one is very easy.  I saved it for last because it requires the least code.


Your class must derive from the {{{SyncEngine}}} class, defined in {{{weave/modules/engines.js}}}{{{SyncEngine}}} contains a lot of code which handles logic for the core sync algorithm, but your subclass won't need to call any of this directly, unless you are overriding part of the sync algorithm to provide custom sync behavior (an advanced technique outside the scope of this article).
Your class must derive from the <tt>SyncEngine</tt> class, defined in <tt>weave/modules/engines.js</tt><tt>SyncEngine</tt> contains a lot of code which handles logic for the core sync algorithm, but your subclass won't need to call any of this directly, unless you are overriding part of the sync algorithm to provide custom sync behavior (an advanced technique outside the scope of this article).


A sample Engine class:
A sample Engine class:
const EXPORTED_SYMBOLS = ["FooEngine"];
const Cu = Components.utils;
Cu.import("resource://weave/engines.js");


  function FooEngine() {
  function FooEngine() {
Line 36: Line 30:


As you can see, there isn't actually any new code here at all; the prototype simply defines some metadata such as the Store and Tracker classes to use, and the human-readable name that will be used in the log files to identify errors and status messages coming from this engine.
As you can see, there isn't actually any new code here at all; the prototype simply defines some metadata such as the Store and Tracker classes to use, and the human-readable name that will be used in the log files to identify errors and status messages coming from this engine.
(Don't forget that you'll need to import SyncEngine and export FooEngine.  So the top of your file should include:)
const EXPORTED_SYMBOLS = ["FooEngine", /* ... etc... */ ];
const Cu = Components.utils;
// etc...
Cu.import("resource://weave/engines.js");


== Installing your classes into Weave ==
== Installing your classes into Weave ==

Revision as of 01:23, 30 January 2009

Overview

Writing a Record class

Writing a Store class

Writing a Tracker class

Writing an Engine class

Your Engine class serves to tie together your Store, Tracker, and Record classes into a bundle that the Weave sync algorithm can instantiate and use.

You're probably sick of writing subclasses by this point, but don't worry: this one is very easy. I saved it for last because it requires the least code.

Your class must derive from the SyncEngine class, defined in weave/modules/engines.js. SyncEngine contains a lot of code which handles logic for the core sync algorithm, but your subclass won't need to call any of this directly, unless you are overriding part of the sync algorithm to provide custom sync behavior (an advanced technique outside the scope of this article).

A sample Engine class:

function FooEngine() {
  this._init(); 
}
FooEngine.prototype = {
  __proto__: SyncEngine.prototype,
  name: "foo",
  displayName: "Foo",
  logName: "Foo",
  _storeObj: FooStore,
  _trackerObj: FooTracker
};

As you can see, there isn't actually any new code here at all; the prototype simply defines some metadata such as the Store and Tracker classes to use, and the human-readable name that will be used in the log files to identify errors and status messages coming from this engine.

(Don't forget that you'll need to import SyncEngine and export FooEngine. So the top of your file should include:)

const EXPORTED_SYMBOLS = ["FooEngine", /* ... etc... */ ];
const Cu = Components.utils;
// etc...
Cu.import("resource://weave/engines.js");

Installing your classes into Weave

Updating the Weave preferences screen

Making sure it works on Fennec