Chapter 2 Background
2.1 Google Gadget
2.1.3 A sample of Google Gadget
The simplest gadget is just a few lines of code. This gadget displays the message
“Hello, world!”
Figure 2-1 Sample of Google Gadget
Note the following about the "Hello World" example:
Because Google Gadgets are specified in XML. The first line is the standard way to start an XML file.
The <Module> tag indicates that this XML file contains a gadget.
The <ModulePrefs> section in the XML file specifies characteristics of the gadget, such as title, author, preferred sizing, and other optional features. The users of this gadget cannot change these attributes.
The <Content type="html"> indicates that the gadget's content type is HTML.
The <! [CDATA[ ... ]]> is used to enclose HTML when a gadget's content type is html. It tells the gadget parser that the text within the CDATA section should not be treated as XML. The CDATA section typically contains HTML and JavaScript.
2.2 Google Gears
2.2.1 Introduction of Google Gears
Google Gears is an open-source browser extension. It supports for off-line web applications, can be used in desktop computers or handheld devices. Applications can obtain resources form the local storage that we pre-fetch it. It can be used for full text search in a database. It uses asynchronous JavaScript [12] operations to help improve responsiveness of application.
Google Gears API contains a variety of different components, so that web browsing has more new features. The more significant elements of Gears such as for example:
LocalServer: Provide a local server cache and application resources (In HTML, JavaScript, images mainly)
Database: Database stores data locally in a fully-searchable relational database
WorkerPool: Low resource consumption of asynchronous operation, maintain the interactive response of Web Application
Opera Mobile 9.51 (Presto build 2.1.0+) (Windows Mobile 6 touch screen only)
2.2.2 System architecture and off-line theory of Google Gears
Google Gears for development purposes is how to make web applications to reach off-line browsing. However, to promote off-line feature, there are always some issues that must be considered:
I. How to set the data layer
II. Decide when to take online or offline, or connection strategy III. Select how applications present in on-line or off-line state IV. How to construct the synchronization functionality
We illustrate in accordance with the above four issues as following:
I. How to set the data layer
The traditional web applications, users should be through the application programming interface to send requests directly with the remote server. There is no data layer between the two settings:
Figure 2-1 Traditional requests
Google Gears join the data layer on the local side; it is an access point to store information what applications request for. So the remote data will have a place to store on the local side. And then, the application interface will obtain information sources from remote capture, change to obtain the data layer. As shown below:
Figure 2-3 Join the data layer
Then add data switch layer, used to determine the source of pages of information is from an data layer (locally),or directly from the Internet (external) to obtain, it still can both use; when the information of data layer needs update, this layer can decide when to write data locally, or sent to Server for synchronization. As shown below:
Figure 2-4 Data Switch layer
Google Gears use another way to create a new local data layer; the layer uses a Gears database instead of going to the web server for data. In the off-line case, data switch layer request information for the Local Data Layer, and then Local Data Layer get webpage data from the Google Gears database:
Figure 2-5 Database of Google Gears
II. Decide when to take on-line or off-line, or connection strategy
Off-line web technology need to consider when to use local information or replace the server directly connected at different timing, known as the "connection strategy".
Although the better efficiency is that access information from the local, but actually, a local server, not all suitable to replace the information provided by remote server.
For example:
Source server for the real-time stock quote system
Server contains huge amount of information
Based on the speed of local side is faster than the remote, so the better approach is still possible store by the local side. In comparison, the greater amount of information stored on the need to synchronize the greater amount of information.
III. Select how applications present in on-line or off-line state
There are two modes that applications are displayed or not in off-line state.
The two kinds of differences:
The application displays off-line mode:
There will be some differences between on-line and off-line state. Sometimes users need to switch the mode themselves.
Such as: Google Reader: It will connect with server in on-line state or use local offline storage. Information will be synchronized each time when the users switch. This model is relatively easier to implement. Drawback is that users need to remember to do mode switching, or sudden off-line will be no information available; if the network quality is unstable, users need to get alternative use for the model.
The application does not display off-line mode: There will not be any significant difference. The user does not need to switch connection mode, the program will operate automatically.
Such as: GearPad: It is destined for off-line execution environment, so at any time if we lose network connectivity will not be affected. This model allows users to ignore the state of mode switching network, even in the unstable network can continue to use as usual. Drawback is not easy to implement, we need to avoid consuming too many resources for background synchronization,
then decrease the overall performance. Synchronous operation has nothing to do with user activity, so testing difficult.
IV. How to construct the synchronization functionality
Usually, through the operation of program, the contents of the local and server will be different, when the connection of network works, the contents need for synchronization; synchronous operation mode can be used manually or background.
However, Google Gears does not provide synchronization engine, which must implement by the application developer according to their own development.
Manual synchronization
As the manual synchronization is not at definite time, so every time they must pay attention to the problem of load limits. In addition, users may not understand the situation on the network, only find the network is not available when they try to synchronize, or forgot to synchronize before they enter an environment which network is not available. Manual synchronization with easy to implement, but require user participation features.
Background synchronization
In a network available environment, the application can be continued synchronization between the local side and server, and detect the network connection before doing synchronization. In such way, if a sudden failure or instant off-line, we still can maintain the latest information.
Below is the Google Gears chart includes background synchronization.
Figure 2-6 Sync Engine of Google Gears
2.2.3 The information security of Google Gears
Google Gears [15] uses the Same Origin Policy [19], which specifies the source of information on the local side for access. In order to protect users, each site for the first time produce off-line information before, the warning dialog will be presented, every web sites is essential that users permission to the implementation of Google Gears.
All the local information will differentiate their accounts; it cannot be used interchangeably in order to protect personal privacy.
2.2.4 The functions of Google Gears API
The functions of Google Gears API all are summarized as follows:
Factory: The Factory class is used to instantiate all other Gears objects.
Database module: It provides browser-local relational data storage for web application...
HttpRequest module: Let the WorkerPool have ability of HTTP request.
LocalServer module: It allows a web application to cache and serve its HTTP resources locally, without a network connection.
Timer module: It’s a timer to provide time records for the use of other API.
WorkerPool module: This API allows web applications to run JavaScript code in the background, without blocking the main page's script execution.
2.3 Apache Shindig
2.3.1 What is Apache Shindig?
Apache Shindig is a server-side-based Web application platform and can be rendered Widget XML into html code.
Apache Shindig provides two languages (Java, PHP) reference implementation in this project; we constructed a PHP version of the implementation.
Shindig itself is divided into four main parts:
1. Gadget Container JavaScript:
Required for general gadget JavaScript, and manage security, communication, UI layout, and feature extensions.
2. Gadget Rendering Server:
It is used to render Gadget XML format into JavaScript and Html.
3. OpenSocial Container JavaScript: We don’t use it in this thesis.
4. OpenSocial Data Server: We don’t use it in this thesis.
2.3.2 Five different servlets in Apache Shindig
Shindig contains 5 different servlets, which are described below:
Each servelts is the subclass of HttpServlet, and serve as independent entry points at runtime.
1. GadgetDataServlet:
It takes requests for loading social data from file into DataObjects.
It takes requests for OpenSocial APIs.
2. GadgetRenderingServlet:
It converts Gadget Xml into HTML.
In this thesis, we must do some fix in this part.
3. Proxy Servlet:
It provides URL Gadgets to connect to the remote URL, and fetches the contents then turns into JSON format and sends it back.
In this thesis, we must understand how the Proxy Servlet fetches the remote contents and then make some amendments for our system.
4. JsServlet:
It is used for Loading JavaScript libraries from external sources in URL gadgets.
5. RpcServlet
It is used to handle RPC metadata requests.
Figure 2-7 The Class diagrams of these five servlets
2.4 Related Works
In order to understand the other's platform with our differences and know what we should take care when we implement such a platform.
The following sections we will introduce several other related applications platform.
And also provides Html 5 [20] introduction to understand how we use the next generation browser and the possibility of making web application
2.4.1 Yahoo! Go
When an Internet company wants to provide mobile services, he must face a problem that is a large number of mobile phone operating system, and different brands of cell phones have their specific functions, or different browser set in numerous mobile phones. In order to solve this problem, Yahoo! Go offers an environment (a Java-based phone application) for the current site can be simple and easy for operators
to put their services on mobile phones, and not worry about what underlying technology used in the background. But to achieve this goal, Yahoo! may own a lot of compatibility issues to overcome. Actually, Yahoo! announced in late December 2009 that Yahoo! Go along with technical support for it would be discontinued on January 12, 2010. About January 22nd, Yahoo! Go no longer works.
Yahoo! Go aims to their application in each mobile phone can run normally, it must be compatible with the operating system of various mobile phones. He must be for different mobile phones or browsers to be adjusted to ensure that the function is normal and display successfully. As long as the phone supports Yahoo mobile developer platform, website operators just follow the development of specifications in accordance with written Widget; it will be able to provide existing web services for mobile phone users who have installed Yahoo! Go software.
Figure 2-8 Yahoo! Go software
Yahoo! GO has a lot of services covered the basic news browse, read mail, weather forecasts, even to view the latest Flickr photos. Other features include Yahoo search engine, we can easily search for other sites, as long as input the site name, for
example, enter: 01, mobile search will bring Mobile01 website link, click on the link, we can immediately visit the site; Other built-in features include Yahoo News, entertainment, finance, weather, sports, it would be a RSS receive service, not to endure lengthy downloads or start connections, we can update at any time the latest current affairs of life.
Yahoo! Go uses Widget for the conceptual design. Widget is designed to immediately access the site resources. Furthermore, taking into account the small window, it is designed to let user reading comfortable. The developers can use Yahoo! Widget tool produces self-developed Widget. Yahoo! Widget is a technology using a JavaScript open source platform, to support Windows and MacOS X operating system. Yahoo Widget tool provides thousands of desktop mini-applications, these tools in the Yahoo Widget platform to run mini-applications, called the Widget tool. By these Widget tools, users can link to Yahoo's web services to obtain all the required personal information.
Yahoo! Go developed to version 3.0, open advertiser embedded advertising, and to provide external developers to use Yahoo's Widgets functionality, design more diverse content for mobile users, so that external developers can put into the keyword advertising to create revenue.
2.4.2 Web Page Tailoring Tool
As mobile devices become more popular, the opportunity to use them to go to the Internet becomes more and more. However, the vast majority of pages are designed
screen size limit, the user might always have to scroll in very inconvenient way.
Although some websites specifically for mobile devices provide an additional mobile version, but through this approach, Web developers should spend more time to design and maintain the same sites; In addition, some commercial web pages that will let original content of the page to re-layout, for example: let Web into long strips in order to remove the scroll trouble. However, the re-layout the web pages may not be able to allow users to quickly find the desired information, because still there is some unimportant information.
Figure 2-9: Page Tailor in Web browser
In view of this, Chi-Yang Tsa from National Chiao Tung University [21] creates a web system to help users to get what portion they want to read. The system can determine Web pages according to users’ personal preferences. And it facilitates the mobile user to read the small screen.
The main principle is to allow users to use JavaScript to select what part they want to read. As the Dom tree [22] of html can be expressed as an internal way, so this tool will be transform the areas user selected into a Dom tree path, and save to the database.
When users actually access, they will set up a Muffin server [23] of this system as a proxy server. This server is a World Wide Web filtering system written entirely in Java that can filter any HTTP data sent and received by user's Web browser. This system is rewritten muffin server and according to the Dom tree path which is saved in the database as a basis for filter data. Users only set a range once and the other pages in the same path of the web can be made by the same set to do filter.
2.4.3 HTML 5
HTML 5 is a new network standard, aiming to replace the existing HTML 4.01, XHTML 1.0 and DOM Level 2 HTML standards. It hopes to reduce the need for browser plug-in-based rich internet application, such as Adobe Flash, Microsoft Silverlight [24], and Sun JavaFX [25] needs.
HTML 5 provides some new elements and attributes to reflect modern usage of the typical Web site. Some of them are technically similar <div> and <span> label, but has some meaning, such as <nav> (navigation block) and <footer>. The tags will help search engines to index order, small screen devices and the visually impaired. It provides new functionality for other new requirements, such as <audio> and <video>
tag. Some HTML 4 tags will be removed, including the tags used solely for display, such as <font> and <center>, because they have been replaced by CSS.
Currently Firefox, Google Chrome, Opera and Safari (version 4 and above) has supported HTML5 technology.
Here is a list of the APIs of HTML 5:
• The Contacts API provides a local SQLite database as the core, this way, people in the Client-side can have a simple SQL database for information, so let the front page to access it.
Web Storage:
A Name-Value-based data storage area used for HTML & JavaScript, the information stored there will continue to be a local database file, even turn off the Browser will not disappear, it can be used as a storage area similar Cookie.
Chapter 3 System Design
Figure 3-1: Overview
3.1 Overview
At first, Application Developers write Widget according to their needs. Because we use Apache Shindig which is an Open Source to be modified as a Mobile Desktop Server, so as long as follow the standard Google Widget rules, the widget they write can be easily used in our system.
Application Developer may put the complete picture which is required for the development of the Widget and RSS list xml or the website information on their Application Server.
functionality required to conduct and support Google Gears are able to be included in the form of JavaScript in the Widget XML file.
This system process is as follows:
Step1：
When the developer completed development of its own widget, then they can through the entrance page we set up to upload the icon which is representative of this widget and the widget xml into our server.
In addition, if the widget produced by developer will get the information through the remote server side that we can use tailor tool to set the information provided by remote server, in order to let remote server's Web content more suitable for the mobile platform.
Step2：
In this step, user can through our entrance pages to select want the widget they want, including each user and their selected widget will be recorded in the our server's database (this database created and designed by us).
Step3：
Our Widget engine will be obtained in accordance with developer upload widget xml, parse each of which tab is based on remote xml, and he crawled down (in order to meet the gears in the mechanism), then to rewrite the contents inside.
Step4：
The Widget engine adapted by us will let the remote xml crawled by step3 to do an extra parse, and according to the link found after parse, send these http-request for
each one. After the response received, and we will go through a proxy server to do extra tailor treatment
Step5：
Under the environment of the mobile user when the selection has been completed, as long as the first connected to the our server can get their widget
Step6：
In the first through to our server to get users’ own widgets, Server will keep the content of html required by off-line state in the Gears of the local layer, so that the future for off-line use. In addition to the first access, the rest of the time only when the content of html changes, then we just verify the content of local layer
Sync：
If the developer’s widget designed to record some of the specific items needed (ex:
If the developer’s widget designed to record some of the specific items needed (ex: