The mobile web apps community has been systematically knocking down the barriers to building apps on web technologies. We have offline data storage, offline application cache, coming soon we will have access to devices, and files, but there is something missing: data sync.

As a web developer, I have always felt that mobile web apps are just like small web pages. If you think about web apps like that, you can see how many of our traditional FE methods can be used to build mobile apps. Data sync is a relatively new requirement for web developers. Yes, we have had server communication for a long time, in which we could transfer data, but web pages going offline for long periods of time is new.

It also doesn’t seem like we are going to get any guidance from the standards bodies. In the Dive Into HTML5, Mark Pilgrim states:

“If your application creates data or saves state, it’s up to you to store that data locally while you’re offline and synchronize it with the remote server once you’re back online. In other words, HTML5 can take your web application offline. What you do once you’re there is up to you.” (source)

While Pilgrim is not the W3C, he does have input, and was apart of the process. What it means is that it’s up to us the community to figure this out. I am writing this for a couple of reasons. First, let’s get all the prior work into the open. It’s possible somebody somewhere has figured this out, or there might be a solution that has been overlooked. Two, there are existing standards that might be used, we should take a look. Finally, there are a couple of different sync scenarios, and they might have different solutions we should take a look at a couple.

Libraries, and the greater Internet, might have the information we need, but I figured that if I couldn’t even find anything on the surface that looked close to a solution then I should ask the community first, it might save time. I was able to find a couple possible starting points. These are specific to sync.

• OData — seems to be backed by Microsoft, XML, and JSON
• FeedSync, or Simple Sharing Extensions built on top or RSS
• SyncML

These seem to have a largish amount of people behind each project. SyncML seems to be the most open, which I know is hard word to define, but they are all lacking something. I know it’s an incredibly un-technical way of assessing an idea, but I don’t see hackers using any of the above I am open to be proven wrong though. I also found a 2 year old link to a thing called AtomDB, which was going to be based on the AtomPub spec, but it’s 2 years old.

Are any of the above possible players in mobile web apps? I don’t know, I am partial to saying I don’t think so. If there isn’t anything out there we should probably try and define some of the problems that will need to be solved. I have two scenarios in mind.

The first scenario is like a text based sync. In this scenario the user has lots of textual data, like a bunch of notes, something similar to Simplenote. The user goes offline for a while. While offline they make changes to a note, and let’s say they have a shared note with a friend. This friend modifies the same note while the user is offline. Now, we have two notes with changes that aren’t in sync. The user comes back online, and then what happens? That is scenario one. I think this one could be handled by some kind of versioning scheme like git, and svn merge code.

The second one is a buisnessy one. Let’s say a traveling sales man is out selling some widgets. He has a mobile order entry device. He has an internal copy of the inventory data that stays closely in sync with the central copy until he goes offline. When he enters his order he is offline. While he is offline a co-worker in the central office takes a phone order. They both need to see the rest of the inventory. When the traveling salesmen comes back online there is now a conflict, but it can’t easily be merged — there has to be a resolution of some kind.

Mayby both of these problems are incredibly unique to their respective circumstances. Even if they are unique, there has to be repeatable patterns that can be used. There must be a way to provide a framework to handle sync, and either it exists out there, or someone needs to build it.

I would like to note that Couchio seems to be trying to fix this problem with CouchDB. They might have more to say, but they have an interesting model for how web apps could use CouchDB. For example, on the Android platform CouchDB can run as a service in the background. Your web app would be able to talk to the local CouchDB server all the time. When you device is online CouchDB will handle the data sync to an upstream database.

That would be awesome, but it’s not a standard, and it’s not everywhere. Even if they figure out how to get it on to many different devices in the future it still might take awhile, and I think we need something sooner then that.

This is a call to action, do we have a problem, is their a solution already, do we need to build something?

Via DailyJS

Welcome to part 28 of Let’s Make a Framework, the ongoing series about building a JavaScript framework.

If you haven’t been following along, these articles are tagged with lmaf. The project we’re creating is called Turing.

Last week I was talking about chaining DOM finders, jQuery style. I demonstrated a little script that duplicated a fake version of this functionality. This week I’ll start building it for real.

Please read last week’s tutorial if any of this sounds confusing, everything here draws on that.

Recap

What we want to be able to do is chain finder methods:

turing('.example').find('p')

This would find things with the class example, then the associated paragraphs. We can use turing.dom.get to implement the core functionality, but get() does not accept a “root” element, so we’ll need to add that.

Another thing is, calling turing() makes no sense, because it isn’t a function. Let’s address that while we’re at it.

The alias module will also have to be changed, because it currently wraps turing.dom.get anyway.

Tests

The implementation should satisfy the following test in test/dom_test.js:

given('chained DOM calls', function() {
  should('find a nested tag', turing('.example3').find('p').length).equals(1);
});

I should cover more methods and cases, but I’m on a tight schedule here!

Updating Core

This is simpler that you might expect. The core module currently exposes turing as an object with a bunch of metadata properties. This can be changed to a function to get the jQuery-style API. The only issue is I don’t want to make turing.dom a core requirement.

To get around that I’m going to allow an init method to be overridden from outside core. This could be handled in a better way to allow other libraries to extend the core functionality, but let’s do it like this for now:

function turing() {
  return turing.init.apply(turing, arguments);
}

turing.VERSION = '0.0.28';
turing.lesson = 'Part 28: Chaining';
turing.alias = '$t';

// This can be overriden by libraries that extend turing(...)
turing.init = function() { };

Then in the DOM library:

turing.init = function(selector) {
  return new turing.domChain.init(selector);
};

This last snippet is based on the fakeQuery example from last week.

Updating turing.dom

This is all completely taken from the fakeQuery example. The real find method in turing.domChain (which came from fakeQuery.fn) looks like this:

find: function(selector) {
  var elements = [],
      ret = turing(),
      root = document;

  if (this.prevObject) {
    if (this.prevObject.elements.length > 0) {
      root = this.prevObject.elements[0];
    } else {
      root = null;
    }
  }

  elements = dom.get(selector, root);
  this.elements = elements;
  ret.elements = elements;
  ret.selector = selector;
  ret.length = elements.length;
  ret.prevObject = this;
  ret.writeElements();
  return ret;
}

It depends on dom.get for the real work, which I covered way back in part 6 (and onwards).

The writeElements method sets each element to a numerical property, so the Array-like API is available:

$t('.example3').find('p')[0]

I also added a shorthand first() method to the same class while I was at it.

DOM Root

Setting a “root” element for dom.get looks like this:

dom.get = function(selector) {
  var tokens = dom.tokenize(selector).tokens,
      root = typeof arguments[1] === 'undefined' ? document : arguments[1],
      searcher = new Searcher(root, tokens);
  return searcher.parse();
};

An undefined property will become document, which means it can accept null. I had to make the existing find methods check for null as a special case.

Conclusion

These two chainer tutorials illustrate:

• How to create an API for jQuery-like DOM traversal
• How to create a prototype of a feature using abstracted data
• How to write a test then satisfy it with code

Adapting the fakeQuery prototype was actually surprisingly easy. And now the chainer returns domChain, we can decorate it with lots of helper methods like first() to make DOM traversal very easy.

This is far from a complete solution, but the foundations are now there.

Via DailyJS