Under the hood of the Socket.IO + Express example

You might have seen one of the sneak preview videos on YouTube about a collaborative demo app using our scheduler with Ext JS and Sencha Touch. With our recent release of the first 2.2 beta version of Ext Scheduler, it’s now time to look under the hood of this demo application. When we were about to release the Touch Scheduler, we thought we should really put it to the test before releasing it. A few days later, we had written a collaborative app where changes are being broadcasted immediately when a task is modified. The live aspect of the application is not something you see often in web apps today but with tools like Express and Socket.IO it’s now very easy to accomplish. This post is quite long and contains lots of code, but here’s how we did it:

Setting up an Express web server

First of all, we had to setup a simple Express web server which runs on Node (you need at least Node 0.6+). Download Node.js here. We also need socket.io which you can find here. To avoid having to involve a database on the server, we simply created an in-memory array “DB” of tasks to serve as the database. It also has add/remove/update methods to support all CRUD operations. Below is the script which launches a simple Express instance on port 3000.


We then created a basic HTML index.html page which includes Ext JS, Ext Scheduler, Socket.IO and our application JS file (in the example there is also a touch version including Sencha Touch instead). Contents below:


Now to the application bootstrap part, which means adding an app.js which should work for both Ext JS and Sencha Touch. This required a little bit of normalization code but nothing really difficult.


This creates a simple Viewport and puts a scheduler inside it together with a form where you can enter your name. Let’s move on to take a peek at the App.view.SchedulerGrid class.

UI classes

As with the app.js file, we had to make sure this class could be used regardless of the underlying Sencha framework. For this view class, we had to use the constructor instead of relying on the initComponent hook since this hook doesn’t exist in Sencha Touch (instead there is an init hook). By relying on the constructor, we saved us a bit of normalization code.


There are basically just two special things about the scheduler above: When a drag operation starts, the dragged Model is marked as blocked and as the cursor is moved, the model is continuously updated until the drag operation is finished. Since we don’t want our own ‘local’ view to repaint itself on such model updates, we override the onEventUpdate method to prevent it.

Data classes

So far we have only presented the UI and the application classes. Let’s move on to where the real magic happens. First, let’s look at the underlying App.model.CustomEvent, its sources can be seen below. To have this class support both Sencha frameworks, we needed a bit of normalization code since ST uses its config system to define class members.


This model is consumed by the App.store.EventStore which is just a plain store consuming a special mixin we wrote. It defines the model to use and also initializes the socket its bound to.


Socket.IO – client side

If you have worked with regular Sencha data stores before, you’ll note we are doing things a bit different here. We’re not using any of the load/save capabilities of the data package. We’re instead letting socket.io handle all the CRUD traffic to and from the server. The contract for this mixin class can be summarized as this statement:

Observe the socket to know what others are doing, and let the others know what I’m doing

The socket API allows you to observe it using the on method, and you can use the emit to broadcast local changes.


If you read the code above, you’ll also notice a few framework normalization snippets, but all in all it’s a trivial data mixin class. The final piece of this application is the socket.io integration on the server side.

Socket.IO – server side

This is a quite straight forward piece of code. Once the socket connection is available we observe it for actions invoked on the client side (load/update/add/remove). Using the emit method of the broadcast property of the socket, we can reach all connected clients.



Finally, to visualize that someone else is moving a task bar on your screen, we placed a hand cursor for tasks that are in the ‘Blocked’ state. Next to the cursor, we also show the name of the user moving the task. This gives any observing users an extra clue about what is going on.


Summing up…

By combining our products with Ext JS, Sencha Touch, Express and Socket.IO we were able to write a cool collaborative application with realtime updates. We were also able to reuse the application code for both Sencha frameworks with only a very tiny amount of normalization code. If you like this example and find it useful (or if you have suggestions of how it can be improved), please let us know in the comments. To try it out, you need to download the Ext Scheduler 2.2 version and look in the ‘/examples/nodejs’ folder. There is an ‘index.html’ file for desktop and an ‘index_touch.html’ for touch devices.

Comments ( 2 )

Leave a Comment