MatrixAdapt | Logiciel de gestion d'Entreprise, Création et référencement des sites web

Seo Master present to you: 2013, By: Seo Master

Seo Master present to you: 2013, By: Seo Master

Seo Master present to you: 2013, By: Seo Master

Seo Master present to you: On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices built on HTML5. We shared the behind-the-scenes story through this blog and decided to share more of our learnings in a brief series of follow up blog posts. In the last two posts, we covered everything you need to know in order to make effective use of AppCache. This week, we'll be having some fun and trying to disect the inner workings of AppCache by looking at the database it uses to store its resources. Before we start though, I'd like to point out one tip that can be useful while debugging AppCache related problems on the iPhone: how to clear your Application Cache.

There are two steps involved here:

1. Go to Settings->Safari and tap "Clear Cache".
2. Open Safari and terminate it by holding down the home screen button for 10 seconds.

The first step is pretty intuative. The problem is that the browser does not immediately notice that the cache has been cleared, and so needs to be restarted.

Now onto the fun stuff! There is no way to inspect the application cache from within the browser. However, if you are using the iPhone Simulator to develop your webapp, you can find all of the Application Cache resources and metadata in a SQLite3 database located at:

~/Library/Application Support/iPhone Simulator/User/Library/Caches/com.apple.WebAppCache/ApplicationCache.db

Let's have a look at what is contained within this database.

$ sqlite3 ApplicationCache.db
SQLite version 3.4.0
Enter ".help" for instructions
sqlite> .mode column
sqlite> .headers on
sqlite> .tables
CacheEntries        CacheResourceData   CacheWhitelistURLs  FallbackURLs      
CacheGroups         CacheResources      Caches              SchemaVersion     
sqlite> select * from CacheGroups;
id          manifestHostHash  manifestURL                                        newestCache
----------  ----------------  -------------------------------------------------  -----------
1           906983082         http://mail.google.com/mail/s/?v=ma&name=sm        1 

The CacheGroups table holds an overview of what manifests exist. A manifest is identified by its URL and the manifestHostHash is used to track when the contents of a manifest changes.

sqlite> select * from Caches;
id          cacheGroup
----------  ----------
1           1      

Here you can see that I have only one cache in my database. If the Application Cache was in the middle of updating the cache, there would be a second entry listed here for the cache currently being downloaded.

sqlite> select * from CacheEntries limit 1;
cache       type        resource  
----------  ----------  ----------
1           2           1       

The CacheEntries table holds a one-to-many relationship between a cache and resources within it.

sqlite> select * from CacheResources where id=1;
id          url                                          statusCode  responseURL            
----------  -------------------------------------------  ----------  -----------------------
1           http://mail.google.com/mail/s/?v=ma&name=sm  200         http://mail.google.c...

mimeType             textEncodingName  headers data
-------------------  ----------------  --------------
text/cache-manifest  utf-8             


sqlite> .schema CacheResourceData
CREATE TABLE CacheResourceData (id INTEGER PRIMARY KEY AUTOINCREMENT, data BLOB);

This shows what information is stored for each resources listed in a manifest. As you can see the CacheResources and CacheResourceData tables contain everything that is needed in order to simulate a network response to a request for a resource. Let's see exactly what is stored in the database for Mobile Gmail's database.

sqlite> select type,url,mimeType,statusCode from CacheEntries,CacheResources where resource=id;
type        url                                             mimeType             statusCode
----------  ----------------------------------------------  -------------------  ----------
2           http://mail.google.com/mail/s/?v=ma&name=sm     text/cache-manifest  200       
4           http://mail.google.com/mail/images/xls.gif      image/gif            200       
4           http://mail.google.com/mail/images/pdf.gif      image/gif            200       
4           http://mail.google.com/mail/images/ppt.gif      image/gif            200       
4           http://mail.google.com/mail/images/sound.gif    image/gif            200          
4           http://mail.google.com/mail/images/doc.gif      image/gif            200       
4           http://mail.google.com/mail/images/graphic.gif  image/gif            200       
1           http://mail.google.com/mail/s                   text/html            200       
4           http://mail.google.com/mail/images/generic.gif  image/gif            200       
4           http://mail.google.com/mail/images/zip.gif      image/gif            200       
4           http://mail.google.com/mail/images/html2.gif    image/gif            200       
4           http://mail.google.com/mail/images/txt.gif      image/gif            200   

From this list, it is fairly easy to see what the meaning of the type field is. A host page has type 1, a manifest has type 2, and a normal resource has type 4. In order to know whether or not to load a page using AppCache, the browser checks this list to see if there is a URL of type 1 within it.

This concudes our three-part series on HTML5's Application Cache. Stay tuned for the next post where we will explore other areas of how we use HTML5 in Gmail. And just another reminder that we'll be at Google I/O, May 27-28 in San Francisco presenting a session on how we use HTML5. We'll also be available at the Developer Sandbox, looking forward to meeting you in person.

References
The HTML5 working draft: http://dev.w3.org/html5/spec/Overview.html

Apple's MobileSafari documentation: http://developer.apple.com/webapps/docs/documentation/AppleApplications/Reference/SafariJSRef/DOMApplicationCache/DOMApplicationCache.html

Webkit Source Code: http://trac.webkit.org/browser/trunk/WebCore/loader/appcache

By Andrew Grieve, Software Engineer, Google Mobile2013, By: Seo Master

Seo Master present to you: On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices built on HTML5. We shared the behind-the-scenes story through this blog and decided to share more of our learnings in a brief series of follow up blog posts. Last week we explained how to go about creating a simple manifest file, and how the browser uses it to load a page. This week we will go a bit more in-depth about the subject.

One of the problems we faced in creating our manifest file, was how to update it when our javascript changes. At first we thought that we might have to change one of the URLs each time we wanted to push an update. As it turns out, the URLs listed in the manifest do not have to change at all in order cause an update, changing the whitespace or a comment will also do the trick. For Gmail, we a comment in the manifest that contains a hash of all of the resources listed in the manifest. That way, if any of the resources change, the manifest will also change and cause a background update to occur for all of our clients. An example of what this looks like is shown below.

CACHE MANIFEST
# version: 3f1b9s84
jsfile1.js
... other URLs ...

There are other types of entries that are possible in a manifest, but that the iPhone does not currently support. According to the spec, there are 3 categories of URLs that can be listed in a manifest:

• Cache (what we have dealt with so far),
• Fallback,
• Network

Although fallback and network URLs are not yet supported on the iPhone, they are mostly supported in the Webkit Nightly builds. Network URLs are those that are never cached by AppCache, and that are allowed to be satisfied by the network. Fallback URLs are those that are attempted, and then satisfied by by AppCache only if the network attempt fails. Both Network and Fallback URLs are prefix matches. An example of what this looks like is shown below.

CACHE MANIFEST
jsfile1.js

NETWORK:
/images/

FALLBACK:
/thumbnails/ images/missing_thumb.jpg

This manifest tells the browser that GET requests to any URL under /images/ are allowed to hit the server. Without this being listed, GET requests for it would fail immediately. This manifest also tells the browser that URLs under /thumbnails/ are allowed to hit the server, but if they fail, satisfy the request by server missing_thumb.jpg, which will be stored in AppCache.

So far all of the features we've covered about AppCache have not needed any Javascript to use them. This is undoubtedly by design, as it makes it extremely easy to use. However, it is always useful to know what advanced functionality can be unlocked using Javascript. The Application Cache is exposed as a singleton through window.applicationCache. It provides events that can be used to indicate when updates are happening and a status property that can be one of:

• 0 - UNCACHED
• 1 - IDLE
• 2 - CHECKING
• 3 - DOWNLOADING
• 4 - UPDATEREADY

In Gmail, we use the status property to determine if the page was loaded out of AppCache, or if it was loaded from the network. In order to do this, we have the following code run at the very start of page load:

if (window.applicationCache.status == 0) {
  // Page was loaded from the Network.
} else {
  // Page was loaded from AppCache
}

There are also a couple of functions available, swapCache and updateCache, which we'll not go into detail on since we have not found any use for them yet.

Stay tuned for the next post where we will explore how to use the sqlite3 command-line tool to inspect the iPhone Simulator's AppCache database. And just another reminder that we'll be at Google I/O, May 27-28 in San Francisco presenting a session on how we use HTML5. We'll also be available at the Developer Sandbox, looking forward to meeting you in person.

References

The HTML5 working draft:
http://dev.w3.org/html5/spec/Overview.html

WHATWG working draft:
http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#appcache

Apple's MobileSafari documentation:
http://developer.apple.com/webapps/docs/documentation/AppleApplications/Reference/SafariJSRef/DOMApplicationCache/DOMApplicationCache.html

Webkit Source Code:
http://trac.webkit.org/browser/trunk/WebCore/loader/appcache


By Andrew Grieve, Software Engineer, Google Mobile2013, By: Seo Master

Seo Master present to you: On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices built on HTML5. We shared the behind-the-scenes story through this blog and would like to share more of our learnings in a brief series of follow up blog posts.

The HTML5 draft adds a lot of exciting functionality to browsers. Perhaps the most exciting is adding a way for websites to be launched offline. For devices that have a high bandwidth and highly available connection, offline functionality might not be so important. For web applications running on mobile devices however, being able to launch offline can dramatically improve the web application experience.
AppCache support on the iPhone is still under development, but as of firmware 2.2.1, it is usable.

To make use of AppCache, a webpage must provide a "manifest" to the browser that lists all of the URLs that it intends to use. Creating an HTML5 manifest file is extremely simple, as shown by the following example.

CACHE MANIFEST
jsfile1.js
jsfile2.js
styles.css
/images/image1.png
/images/image2.png

It is important to note that it is not necessary to list the URL of the main webpage in the manifest because it is treated as an implicit entry. However, if you have more than one top level URL that you want to be available offline, they must all be listed in the manifest. In addition, they must all set a manifest attribute on the HTML tag that points to the manifest. For example, if the manifest URL was "/sitemanifest", then each page in the site would have an HTML tag that looked like this:

<html manifest="/sitemanifest">

Finally, the manifest must be served using the content type "text/cache-manifest". And that's it!

So now that you know how to create a manifest for your site, it's a good idea to know what's going on during page load. When the page is loaded for the first time, it will load as if there is no application cache associated with it. Once it has finished loading, the browser will fetch the manifest and all resources listed in it that have not already been fetched during page load. From this point on, any GET request that your page makes that is not listed in the manifest will fail, and any GET request that is listed in it will not hit the network, but will be satisfied by the cache. Once your page is loaded into AppCache, the next time the user loads the site, all of the resources will be served out of the cache. The only GET request done on page load will be for the manifest file, in order to see if it has changed. If it has changed, then all of the resources in it are fetched in the background and will be used the next time the user refreshes the page.

Stay tuned for the next post where we will share more about what we know about AppCache and how we use it on the Gmail team. Also, we'll be at Google I/O, May 27-28 in San Francisco presenting a session on how we use HTML5. We'll also be available at the Developer Sandbox, and we look forward to meeting you in person.

References

The HTML5 working draft:
http://dev.w3.org/html5/spec/Overview.html

Apple's MobileSafari documentation: http://developer.apple.com/webapps/docs/documentation/AppleApplications/Reference/SafariJSRef/DOMApplicationCache/DOMApplicationCache.html

Webkit Source Code:
http://trac.webkit.org/browser/trunk/WebCore/loader/appcache

By Andrew Grieve, Software Engineer, Google Mobile2013, By: Seo Master

Seo Master present to you: 2013, By: Seo Master

Seo Master present to you: 2013, By: Seo Master