A method of allowing two browser windows to communicate without violating cross-domain restrictions.
Comes in two flavours:
postMessage
calls to a known Window
instance.Quite simply - because you want to talk to other browser window contexts.
var activeDemo = '';
Reveal.addEventListener('slidechanged', function(evt) {
// find the active slide
var demo = $('section.present').data('demo');
if (demo && activeDemo !== demo && window.opener) {
window.opener.postMessage('demo.' + demo, '*');
}
});
Can be used to facilitate communication between two windows with no knowledge of each other.
While an interesting concept, I personally don't feel I'm getting bang for buck.
Goes beyond what can be covered in this talk.
Creating a new websocket connection (and attempting to open that connection) is really, really easy:
var socket = new WebSocket('ws://echo.websocket.org/');
And, your newly created websocket object will fire an open message when the connection is active:
socket.onopen = function() {
// ready for comms
};
Sending a message is as simple as calling the send method of a WebSocket instance:
// say hello to the websocket server
socket.send('hello');
Listen for the message event:
socket.onmessage = function(evt) {
// data is available in the data member
console.log('received data: ' + evt.data);
};
Browser support for websockets is far from stable, and in these slides I have demonstrated the native browser interface to WebSockets.
If you are writing a production app, however, you really need to include stable fallbacks to deal with non-existent or poor websocket support.
I'd recommend checking out something like Socket.IO or another similar framework that takes care of this for you.
There are quite a few server implementations of websockets in technologies from Node.js to Java.
While application server support is progressing well, you also need to have a look at what other webservers, reverse proxies, security appliances, etc sit between your customers and your app server. Support for Websockets in these layers is definitely not as well progressed.
Like the other APIs covered in this talk, initialising a new EventSource
is very simple:
var source = new EventSource('http://test.com/events');
Like the cross-document messaging and websocket APIs, an EventSource
will generate message events:
source.onmessage = function(evt) {
console.log(evt.data);
};
And you can also can create and consume custom events too. Before we have a look at that though, let's take a quick look at the event stream format.
The event stream is simply a plain text stream which contains textual event data:
data: This is the first message.
data: This is the second message, it
data: has two lines.
data: This is the third message.
Custom events in the stream have an event
specifier:
event: add
data: 73857293
event: remove
data: 2153
event: add
data: 113411
Handling these custom events is as simple as registering listeners for those specific event names:
source.addEventListener('add', function(evt) {
// handle add
}, false);
source.addEventListener('remove', function(evt) {
// handle remove
}, false);
It's important to note that Server Sent Events are subject to cross-domain security policy, and CORS support is still emerging in most browsers.
The intention is to provide:
DOM interfaces and markup used by client and service pages to create, receive, and reply to Web Intents messages, and the procedures the User Agent carries out to facilitate that process.
The proposed markup for registering a Web Intent for use looks something like:
<intent
action="http://webintents.org/share"
type="text/uri-list"
href="link.html"
disposition="inline"
title="Link Share Intent" />
An intent used in the document is defined in the head
of the document.
A Web Intent is invoked by creating a new Intent
object, and then calling the startActivity
method:
var intent = new Intent(
"http://webintents.org/share",
"text/uri-list",
[ 'http://code12melb.webdirections.org/' ]
);
window.navigator.startActivity(intent);
To keep an eye on their progress, check out:
There are definitely places where these messaging techniques may be useful for you right now.
In an experimentation context, the APIs covered today are all very accessible. Play with them you must.
If you would like to have a play with the tech, then both the slide deck and websocket demo tool are available on github: