MECHENG401:Research google gears

From Marks Wiki
Jump to navigation Jump to search

Overview

<html> <object width="425" height="355"><param name="movie" value="http://www.youtube.com/v/7cyHYEfpRVA&hl=en"></param><param name="wmode" value="transparent"></param><embed src="http://www.youtube.com/v/7cyHYEfpRVA&hl=en" type="application/x-shockwave-flash" wmode="transparent" width="425" height="355"></embed></object></html>


  • "Google Gears is an open source browser extension that lets developers create web applications that can run offline."
  • Architecture is shown below:

File:GoogleGearsOverview.jpg

  • Modality: 2 options
    • Modal applications have distinct offline versus online modes, usually indicated through some change in the user interface. The user is made aware of the state and participates in switching states in some manner.
    • Modeless applications attempt to transition seamlessly between online and offline states, without significant UI changes. The user does not need to participate in switching states, which the application does automatically.

Modules

1. LocalServer

  • Web application controlled URL cache. If requested URL already exists in the LocalServer the pages are served locally from the user's disk.
  • ResourceStores
    • Container of URLs. LocalServer can create any number of Resource Stores and a Resource Store can hold any number of URLs.
    • Updates explicitly handled by the application.
  • ManagedResourceStores
    • Same as ResourceStores but the updates are handled automatically
  • Location of cached files
    • The LocalServer stores files that your application captures in a location determined by the browser and platform.
Example) Windows Vista - Internet Explorer 

Location: {FOLDERID_LocalAppDataLow}\Google\Google Gears for Internet Explorer
Example: C:\Users\Bob\AppData\LocalLow\Google\Google Gears for Internet Explorer

LocalServer API

2. Database

  • Stores application data on local machine. Syncronization should be used to ensure data is up to date.
  • SQLite is used.
  • JavaScript file explcitly opens up a DB connection and stores necessary data into the SQLite DB.
  • Location of database - the same as LocalServer


Database API


  • Database function is the "core" function to the Archivista application. The ability to store data temporarily on local database and synchronize them with the server database is the core function.
  • SQLite supports most SQL functions. We will need to create an identical schema as the server database. This will allow us to customize the storing of temporary data on local DB and synchronizing the data with the main DB.

SQLite API

  • Example codes
<script type="text/javascript" src="gears_init.js"></script>
<script type="text/javascript">
var db = google.gears.factory.create('beta.database');
db.open('database-test');
db.execute('create table if not exists Test' +
           ' (Phrase text, Timestamp int)');
db.execute('insert into Test values (?, ?)', ['Monkey!', new Date().getTime()]);
var rs = db.execute('select * from Test order by Timestamp desc');

while (rs.isValidRow()) {
  alert(rs.field(0) + '@' + rs.field(1));
  rs.next();
}
rs.close();
</script>
  • Classes

Database class
   void      open([name])
   ResultSet execute(sqlStatement, [argArray])
   void      close()
   readonly attribute int lastInsertRowId



ResultSet class
   boolean isValidRow()
   void    next()
   void    close()
   int     fieldCount()
   string  fieldName(int fieldIndex)
   variant field(int fieldIndex)
   variant fieldByName(string fieldName)


  • Implmentation Example: we can customize the synchronization process

1. User opens up a php page that downloads page table content to the local DB. JavaScript handles the SQLite calls.
2. User goes to the site and makes changes to the data value. The changes are saved to the local SQLite DB.
3. User is online. Manual synchronization is desired as offline work can be predicted and not frequent. User, for example, clicks on a button called "Synchronize".
4. Javascript handles the calls to the local SQLite server to fetch the changed data and the calls to the MySQL server(if we're using MySQL) calls to update the changes.

3. Worker thread pool

  • synchronisation operations performed in the background.
  • Basically a JavaScript file run in background without blocking main page's script execution.
  • Workers don't share any execution state. Therefore, they are processes rather than threads.
  • Workers can communicate to each other by sending messages.
<script type="text/javascript" src="gears_init.js"></script>
<script type="text/javascript">
// main.js
var workerPool = google.gears.factory.create('beta.workerpool');

workerPool.onmessage = function(a, b, message) {
  alert('Received message from worker ' + message.sender + ': ' + message.text);
};

var childWorkerId = workerPool.createWorkerFromUrl('worker.js');

workerPool.sendMessage('Hello, world!', childWorkerId);
</script>

// worker.js
var wp = google.gears.workerPool;
wp.onmessage = function(a, b, message) {
  wp.sendMessage('Received: ' + message.text, message.sender);
}

WorkerPool API

Advantages

  • Open Source, free - no cost, and we have the source code to learn from/change/adapt as we wish.
  • Easy implementation - simple javascripts, through the API, are used to implement Google Gears enabled websites.
  • Saving html contents to local database and synchronizing that data with server database... seems like everything we need for the project.
  • Google made - it's google... made by really smart people!

Disadvantages

  • "Google Gears is currently an early-access developers' release. It is not yet intended for use by real users in production applications at this time".
  • Google Gears must be installed on every computer that needs to use application offline.
  • Currently only works through web browsers. Therefore, the client side interface to the server database must be a website.


Usage of databases

I (Nick I.) was doing research on using the SQLite DB in gears to cache information on buildings.
It appears that the work flow might have to be like this:

  • To get remote content onto a users computer
    • User clicks button on Gears enabled web page.
    • Button does an xhttp request to a web server.
    • The request might contain a string of the form, "select * from houses where name = house1", to get all the necessary data for a building.
    • The server is going to have to parse this, check the query for 'safety', and execute it on the server DB
    • The result will have to be turned into an xml message, and returned to the client.
    • The xml is parsed, the individual elements displayed as desired, and then inserted into a javascript query to store them in the local DB(if desired).


  • To get local content onto the server
    • Kind of the same but in reverse




Why all the hassle?
Google Gears has no support for querying the server database (as far as I can tell)

Retrieved from ‘https://wiki.kram.nz/index.php?title=MECHENG401:Research_google_gears&oldid=1337’