Tags: , , , ,

I lost the connection! No more band!

These are the most common problems that torment and plunge into the depths of despair since we are used to being on-line 24/24. Without connectivity, no more site surfing, news to read, feed to consult…right?

The new password for web 2.0 is OFFLINE, this means the possibility for our web applications to work without jams even with this modality and once the connection is brought back, all the work done will be sent on-line. As if by magic thanks to Google Gears!

Now let’s see in detail how the new invention made by the fellows of Mountain View works.


The first step is to download Gears runtime since everything is based on having an engine installed on one’s own PC. It is available for Windows, Mac and Linux and once the download has ended (after accepting license agreement) you run the installer which continues downloading the various modules and installs them onto your computer.

At this point we are “Gears enabled” and we can check it out on the project’s home page. After opening the page, a message which confirms the correct installation must be displayed.

From now on, whenever we open a web page with Gears’ browser, a pop-up windows is that grants authorization for the use of runtime is launched by the website in question saving this layout so you don’t have to confirm the pop-up every time.

The first thing Gears’ application does is verify the presence of runtime and will eventually suggest its installation on the user’s PC. To do this, all you need to do is include the gear_init.js file and the following short script:

 


Once runtime’s presence has been verified, let’s see which objects we must rely on in order to let our application run even when offline:
• LocalServer
• Database
• WorkerPool

LocalServer deals with putting the pages that need to be served in cache so that they are available even when offline and to do this, it makes available 2 different kinds of resources, ResourceStore and ManagedResourceStore. The first one is useful to capture one single element while the second one is used preferably to capture a series of pages (normally the list of these pages is specified in a manifest file which accompanies our application).

ManagedResourceStore also provides an automatic updating mechanism and if we release a new version of the applicative all we need to do is modify the manifest’s file version number in order to allow Gears to update our local copy. If something should actually go wrong, we can always give the direct command by using the checkForUpdate() call.

The Database object provides us with the instruments to implement the persistence of data on local base, using the common SQL syntax since the engine that Google has englobed is just SQLite. The result of our query is simply a recordset and so we can reiterate inside it as we do for the most common programming languages:
while (rs.isValidRow()) {
console.log(rs.fieldName(0) + ” == ” + rs.field(0));
rs.next();
}
rs.close();

WorkerPool is the final object, used for onerous computer operations and which need to be performed in the background in order to maintain the user interface responsive. It is possible to specify different processes which belong to the pool and they can communicate among themselves by using the primitive sendMessage(). On the same page, more pools can coexist without interfering one another.

Here are some projects based on Google Gears:
• Remember the milk (a todo list in 2.0 web style).
• GearPad (a web notepad) released by the same Google.
• DojoOffline (the offline version of Ajax’s famous toolkit).

…and now you’re a bit more conscious!