Shulou(Shulou.com)06/01 Report--

This article mainly introduces the example analysis of mobile Web offline application, which has a certain reference value. Interested friends can refer to it. I hope you will gain a lot after reading this article.

precondition

In this article, you will develop Web applications using the latest Web technologies. Most of the code here is just HTML, JavaScript, and CSS-the core technology of any Web developer. The most important thing you need is the browser used to test the code. Most of the code in this article will run on the latest desktop browsers, with exceptions pointed out. Of course, you must also test it on mobile browsers, and you certainly want the latest iPhone and Android SDK to support this code. IPhone SDK 3.1.3 and Android SDK 2.1 are used in this article.

Why support your application to work offline?

Offline Web applications are attractive to both users and developers for several reasons. Many developers want to be able to write a Web application that runs on all the most popular smartphones, rather than writing native applications for each platform. This is convenient for developers, but that doesn't mean it's what users want. To achieve this, mobile Web applications must be able to provide many (or most) of the same features that native mobile applications can provide. Working offline must be one of the features. Some applications rely heavily on data and services from Internet-whether they are mobile Web or native applications. However, an application cannot fail completely simply because the user's connection is not good. But this is the crux of traditional Web applications.

The offline feature makes mobile Web applications similar to native applications. In addition, the offline feature has other benefits. Web browsers always cache static resources. They rely on the metadata in the HTTP response header sent by your Web server to retrieve the HTML, JavaScript, CSS, and images needed to render the page. If all the resources required to render the page are cached, the page can be loaded very quickly. However, if a resource is not cached, it will greatly slow down the page loading speed. This often happens, and it is really unbearable. Maybe a CSS file has a different Cache-Control header than all other files, or maybe the browser cannot cache because it runs out of allocated space.

With offline applications, you can ensure that all resources are cached. The browser will always load all resources from the cache, although you can also control which resources are loaded from the cache. A common Ajax trick is to add an additional timestamp parameter to the Ajax GET request (or, worse, to use POST when GET should be used) to prevent the browser from caching a response. You don't need to use this technique to support offline Web applications.

An offline application sounds great, so creating an offline application must be complicated, right? In fact, the creation method is very simple, only need to complete the following three steps:

Create an online inventory file.

Inform the browser of this manifest file.

Sets the MIME type on the server.

Offline list

The creation process involves a key file: the cache manifest of your application. This file tells the browser to cache (or not cache) the exact content. This becomes the factual source of your application. Listing 1 shows an example of a simple cache manifest.

Listing 1. Simple cache manifest

JavaScript Code copies content to the clipboard

CACHE MANIFEST

# Version 0.1

Offline.html

/ iui/iui.js

/ iui/iui.css

/ iui/loading.gif

/ iui/backButton.png

/ iui/blueButton.png

/ iui/cancel.png

/ iui/grayButton.png

/ iui/listArrow.png

/ iui/listArrowSel.png

/ iui/listGroup.png

/ iui/pinstripes.png

/ iui/redButton.png

/ iui/selection.png

/ iui/thumb.png

/ iui/toggle.png

/ iui/toggleOn.png

/ iui/toolbar.png

/ iui/whiteButton.png

/ images/gymnastics.jpg

/ images/soccer.png

/ images/gym.jpg

/ images/soccer.jpg

This file lists all the files your application needs to work properly, including HTML files, JavaScript, CSS, and images. It can also include videos, PDFs, XML files, and so on. Note that all URLs in this example are relative. Any relative URLs must be relative to the cache manifest file. In this case, the cache manifest file is located in the root directory of your Web application. Compare the directory structure in listing 2 with the relative URLs in listing 1.

Listing 2. The text version directory structure of the Web application

JavaScript Code copies content to the clipboard

Name

V images

Gymnastics.jpg

Soccer.png

V iui

BackButton.png

BlueButton.png

Cancel.png

GrayButton.png

Iui.css-logo-touch-icon.png

Iui.css

Iui.js

Iuix.css

Iuix.js

ListArrow.png

ListArrowSel.png

ListGroup.png

Loading.gif

Pinstripes.png

RedButton.png

Selection.png

Thumb.png

Toggle.png

ToggleOn.png

Toolbar.png

ToolButton.png

WhiteButton.png

Manifest.mf

Offline.html

> WEB-INF

You may have noticed that this application is using the iUI framework. This popular JavaScript+CSS toolkit is used to provide a native iPhone application look and feel to mobile Web applications. As shown in listings 1 and 2, the framework uses several images to accompany its JavaScript and CSS files. However, as long as it is listed in the list, all of these files will be cached by the browser and can be used in offline mode.

Another key point to note in listing 1 is the version information, which is not part of the specification. In fact, it's just a comment in the file. However, having such information is critical because you can use it to inform the browser that there is a new version of your application. Imagine if you changed some HTML or JavaScript, or even just changed an image. If you do not modify the manifest, the browser will never bother to load a new version of the modified resource. The cache manifest does not expire, so all resources will remain cached unless the user clears the cache or the manifest file changes. The browser checks to see if a new manifest file exists. To indicate a new manifest file, you only need to change some or all of the existing manifest file. Going back to the example of HTML on your modification page, if you change the HTML and change the version string in the manifest file, the browser will know that the resources have been changed and download them again. Placing version numbers in comments is an easy way to manage this lifecycle.

Inform the browser about the list

To enable offline caching for your Web application, you also need to provide some information to the browser. Web browsers need to know where you want to enable caching and where to find your cache manifest file. Listing 3 shows a very simple approach.

Listing 3. Web pages with offline features enabled

XML/HTML Code copies content to the clipboard

@ import "/ iui/iui.css"

Let's do it offline

Going offline

Gymnastics

Soccer

The most important thing about this HTML is the root html element. Notice that this element has an attribute called manifest. It is this property that tells the browser that the page can work offline. The value of the manifest parameter is the URL of the cache manifest file to the Web page. Again, this URL can be a complete URL, although it is a relative (to the specified Web page) URL here. Another thing to note here is the DOCTYPE of the page. This is the canonical doctype for HTML 5 Web pages. The offline Web application specification does not force you to use this DOCTYPE;, but it is recommended that you do. Otherwise, some browsers may not recognize the page as a HTML 5 page and may ignore the cache manifest. The rest of this HTML is just a simple example of using iUI. Figure 1 shows what this page looks like on the iPhone simulator.

Figure 1. Offline Web applications running on iPhone Simulator

Screenshot showing offline Web applications running on the iPhone simulator: Sports applications with Gymnastics and Soccoer options

Testing offline applications can be a bit troublesome. If possible, the easiest way to test is to deploy your application to a Web server. You can then visit the page once, close your Internet connection, and then try to access it again. If there are any failures, you may have missed some files in the cache manifest. Before doing the above tests, you need to make some key configurations on your Web server.

Web server configuration

Listing 3 shows that you indicate the location of your cache list by using the manifest attribute on the root html element of your Web page. However, the cache manifest specification states that the browser must perform an additional verification step when downloading and processing the cache manifest, that is, to check the MIME type of the cache manifest, which must be text/cache-manifest. Typically, this means that you need to configure your Web server to set the MIME type of a static file, or you must write some code to create the file dynamically and set the MIME type. The former is certainly a more effective approach, but sometimes you need to use the latter, such as when you have no control over the server configuration (such as in a shared or managed environment). If you have control of the server and are using a Java ™application server, you can configure this parameter in the web.xml file of the Web application. Listing 4 shows an example configuration:

Listing 4. Configure web.xml to set the MIME type

XML/HTML Code copies content to the clipboard

Mf

Text/cache-manifest

Index.html

Obviously, the key part here is the mime-mapping element. In this case, your setting means that for any file that ends with the .mf extension, set their MIME type to text/cache-manifest. Of course, an even more efficient way is to provide such files from a server dedicated to providing static content, such as an Apache Web server. In a typical Apache installation, you only need to modify the mime.types file in the httpd/conf directory, as shown in listing 5.

Listing 5. Set the MIME type in mime.types

JavaScript Code copies content to the clipboard

# This file controls what Internet media types are sent to the client for

# given file extension (s). Sending the correct media type to the client

# is important so they know how to handle the content of the file.

# Extra types can either be added here or by using an AddType directive

# in your config files. For more information about Internet media types

# please read RFC 2045, 2046, 2047, 2048, and 2077. The Internet media type

# registry is at.

# MIME type Extensions

Text/cache-manifest mf

# many more mappings...

In both examples, you use mf as the extension of your manifest file, so the file is manifest.mf. This extension is optional, and you can use .manifest or .foo, as long as the extension of the manifest file matches the extension used in the mapping in your configuration file. Note that other applications and Web servers may have different configuration mechanisms. Now that you have seen the key factors in creating offline mobile Web applications using HTML 5, let's look at a more complex example to explore more features of offline mobile Web applications.

Advanced exampl

In the previous example, everything is static. It's nice to be able to see everything in offline mode, but a more typical application needs to read dynamic data from its server and Web services. To make your example more realistic, you can drag in some data from Twitter. If you have read the previous articles in this series, you will be familiar with this (see Resources). First, look at the modified HTML of this example in listing 6.

Listing 6. Modified HTML

XML/HTML Code copies content to the clipboard

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.