Changes

Jump to: navigation, search

CloudServices/Sync/FxSync/Developer/ClientAPI

544 bytes removed, 23:13, 21 February 2011
Writing a Store class
== Writing a Store class ==
Your The Store class object (which extends <tt>Store</tt>, as defined in <tt>services/sync/modules/storesengines.js</tt>) has the job of creating and maintaining a set of Record objects from the underlying data. The store must also make updates to the underlying data itself, to keep the data up-to-date with the user's latest changes, when the store is instructed to do so.
The majority of the code you write for syncing a new data type will most likely be in the Store class.
Each Record that the Store keeps track of must be identified by a unique ID. This can be a true GUID (Globally Unique ID), but it doesn't have to be -- it only has to be unique among all records in the store) called GUID. Depending of what type of data you're working with, you might already have GUIDs built into your data that you can make use of. (So if an ID used for a bookmark record in the bookmark store is reused for a tab record in the tab storeIf not, thatyou may have to invent your own mapping from data objects to GUIDs as long as it's fineconsistent. In this case, it is highly recommended to use <tt>Utils.makeGUID()</tt> helper:
Nevertheless, most of the code refers to them as GUIDs, so I'll use GUID for the rest of this article.
 
Depending of what type of data you're working with, you might already have GUIDs built into your data that you can make use of. If not, you may have to invent your own mapping from data objects to GUIDs. In this case, you will probably find the <tt>makeGUID()</tt> function (in Utils) useful:
 
Cu.import("resource://services-sync/util.js");
// ...
let newGuid = Utils.makeGUID();
You can assign GUIDs to items in whatever way you see fitIn either case, as long as you are consistent with the mapping. It's entirely up to your Store class to define and maintain this mapping. Also keep in mind ensure that although the data will be encrypted on the server, the GUIDs are public, so don't put passwords into them or anythingURL friendly (base64url is a recommended alphabet).
Your Store class object '''must''' implement the following methods:
*<tt>itemExists(id)</tt>
*<tt>createRecord(id, uricollection)</tt>
*<tt>changeItemID(oldId, newId)</tt>
*<tt>getAllIDs()</tt>
*<tt>remove(record)</tt>
You may also find it useful to override other methods of the base classimplementation, depending on what you're doing. Since this is a lot of methods to write, I'll break them down one by one in for example <tt>applyIncomingBatch</tt> if the following sub-sectionsunderlying storage for your data supports batch operations.
=== createRecord ===
The <tt>createRecord( guidid, uri collection )</tt> method gets called by the engine to request a new record for an item with a given GUID. It's your Store's responsibility to instantiate a Record object (of the class you defined earlier), assign the given GUID, and return it.
=== itemExists(guid) ===
<tt>remove(record)</tt>
:The argument is a record which has been remotely deleted; your Store should locate the matching local item and delete it. (Don't rely on the record that is passed in to this method having any of its attributes set correctly except for <tt>.id</tt>. The <tt>.id</tt> should be al you need, anyway.)
 
<tt>applyIncomingBatch</tt>
:TODO
=== Example Store class skeleton ===
// Return true if an item with given guid exists in the store.
},
createRecord: function(guidid, uricollection) {
record = new FooRecord(uri);
// Look up the data corresponding to this guid, by the mapping
Canmove, confirm
725
edits

Navigation menu