Detailed Design of IBS

Figure 7-11 shows the sequence diagram of how developers can publicize their applications.

After developers create their applications, they can upload the gadget XML and related images to our application market. For each uploaded gadget, the application market extracts all the external URLs, creates a list of them, and create local URLs of them for offline browsing; the list of external URLs are referenced by the Offline Layer later when this application is installed by any user. Since most of the functionalities of IBS are provided via JavaScript interfaces, it is very easy to use them within gadgets. Also, developers can use the

72

Content Adaptation Layer if they want to include some external Web content into their applications. By using the Authoring Tool, developers can login to IBS, specify which application uses the result, decide whether single page or the whole domain is applied, choose the important regions of current Web page, and store the tailoring result to the Content Adaptation Layer.

Figure 7-11. The sequence diagram of application publication

Figure 7-12 shows how users can install applications of IBS. For each time a user decides to install an application, the application market asks the Offline Layer to prepare for offline Web content. Two ways are supported for preparing offline data: normal Web page processing and RSS feed processing. When processing normal Web pages, the URLs specified by

73

applications are the target pages directly; however, in the case of RSS feed processing, the RSS feed is only an index, which contains multiple URLs for multiple targets. Therefore, the Offline Data Provider has to acquire the RSS feed first, parse it, and download all the Web content of all the targets referenced from it with the Web Crawler if a RSS-feed type of URL is specified in application. Since the Web Crawler craws Web content via the Page Tailoring Service of Content Adaptation Subsystem, the returned Web content is adapted based on the application ID and developer ID. In this way, users can download the adapted Web content for offline browsing directly from the Offline Layer.

Figure 7-12. The sequence diagram of application installation

One of problems of Google Gears is that it doesn’t provide any synchronization mechanism; it leaves this problem to the developers, since different applications usually have different synchronization requirements. However, it implies that developers have to provide an online

74

server and design their own synchronization mechanisms by themselves. In IBS, we provide a simple and basic synchronization service so that developers can use this service directly without maintaining their own online servers.

Table 7-2. The database schema of the table AppSync AppSync

In IBS, all the user data for application synchronization is stored in the AppSync table shown as Table 7-2. Each record of this table maintains the user ID, application’s ID, developer’s ID, a key-value pair of values, and the latest time when it is updated. Moreover, we provide a table manager which provides some basic operations such as insert, update, and delete, so that developers can use this table easily. The AppSync table is implemented within both the Local DB on the mobile device and Offline Data Storage, and the table manager is implemented within the Offline Data Agent on mobile device and the Offline Data Provider. During the synchronization process, the Sync Service checks that if there are two records have the same UserID, DeveloperID, AppID, and Key values in these two tables then replaces the older record with the newer one.

75

Figure 7-13. The sequence diagram of using the to-do list application

A “to-do list” application is designed for demonstrating the capability of Offline Layer. To-do list is a list which includes several tasks which should be finished. Although it is simple, it is useful for users to have an overview of tasks; therefore, users can easily decide the priorities of tasks and arrange their time properly. A to-do list can be implemented as an application of IBS so that it can be executed offline on mobile devices. The sequence diagram of using it is shown in Figure 7-13. After installing this application, users can execute it in offline mode, and add new items into their to-do lists. The local offline data is synchronized with the online

76

server when users execute this application again in online mode. In the implementation of the to-do list application, each item from each user is recorded into a record of the AppSync table.

For each record, a hash value of item content is chosen as the Key value, and the Value value is the content of item. If any item is deleted, Value is set to null, but Key remains the same;

this record is deleted during the synchronization process. If any item is edited, the value of Key is not re-hashed until it has been synchronized.

Figure 7-14. The sequence diagram of using the RSS reader application

We design a RSS reader application of BBC News for demonstrating the capability of Content Adaptation Layer. Figure 7-14 shows the sequence diagram of using the RSS reader application. In the gadget of this application, a JavaScript function is invoked for preparing

77

for Web pages with the type of RSS feed specified. Also, since we use the Authoring Tool to indicate that all the Web pages which are under the specified domain and accessed by this application should be tailored based on a selected pattern, all the returned Web pages are adapted for mobile devices during the online updating process. Moreover, before downloading each Web page, the Offline Layer checks that whether this article exists in the Offline Data Storage; if it exists, then it will not be downloaded again to speed up the updating process. For online execution, if users want to browse external Web pages with adapted content, they can set our Page Tailoring Service of Content Adaptation Layer as Web proxy; in this way, no matter these pages are browsed online or offline, they are adapted for mobile devices.