Les nouveautés et Tutoriels de Votre Codeur | SEO | Création de site web | Création de logiciel

seo HTML5: Still Rocking! 2013

Seo Master present to you: As announced on the chromium.org blog, we’ve just pushed a bunch of new content to our HTML5Rocks.com developer site, which launched earlier this summer.

Anyone that’s following HTML5 knows how fast things are moving! To keep you informed with all of the amazing features landing in today’s browsers, we’ve added five new articles, a heap of new resources, and a much needed RSS feed for staying tuned in. We're also revealing a new component of the site, the HTML5 Studio. It’s a collection of standalone demos that highlight hot, new HTML5 features working together.

If you'd like to contribute code, guides, or samples, we’re working on a third-party contributors guide. Please stay tuned! In the meantime, you can get in touch with us on the bug tracker or via @ChromiumDev.

2013, By: Seo Master

seo Behind the scenes: visualizing the evolution of the web 2013

Seo Master present to you:
Deroy
Sergio

This guest post is by Sergio Alvarez, Vizzuality, and Deroy Peraza, Hyperakt, in collaboration with Min Li Chan, Chrome Team

At Google I/O this year, we launched a new version of The Evolution of the Web, a project visualizing the history and pace of innovation in web technologies and browsers. The Evolution of the Web traces how web technologies have evolved in the last two decades and highlights the web community’s continuous efforts to improve the web platform and enable developers to create new generations of immersive web experiences. In collaboration with the Google Chrome team, the team at Hyperakt designed the interactive visualization while Vizzuality built it using HTML5, SVG, and CSS3.


The visualization included 43 web technology "strands" across 7 browser timelines to represent major developments on the web platform. On hover or tap, each strand is highlighted to reveal intersections that tell the story of when browser support was implemented for each new web technology. To provide additional context, we developed a secondary visualization to illustrate the growth of Internet users and traffic.


In addition, this year's design includes the option for viewing the visualization in both day and night mode, making it ideal for large-screen projection.


For the teams working on this site, it was interesting to note that we used roughly 60% of the technologies highlighted in the timeline to build this visualization:
  • We used HTML5, SVG, and canvas to draw the visualization, alongside CSS3 transforms, rotation, and perspective for immersive animation and data interaction.
  • We used CSS3 to kick off the timeline with a 3D-like animation, as well as the panning and zooming functions, toggling between day and night modes.
  • Additionally, we took advantage of the D3 JavaScript library’s interaction and visual frameworks.
In working closely with the Chrome team, we tested multiple approaches to find the best way to bring to life initial design concepts and build a sleek, responsive visualization. In fact, during the project's development, the Vizzuality team came across an SVG rendering issue that prevented the animation from running smoothly. The Chrome team looked into this bug immediately and promptly enabled a fix the following day – a glimpse at the web evolving in real-time, if you will!

We're amazed at how much the web has advanced over the last several years, and the pace of development is only accelerating. Never in the web's history has it been as exciting to be a designer or web developer, and we hope that this visualization captures some of that spirit.


Deroy Peraza is a founding partner and creative director at Hyperakt, a New York City design firm that helps change-makers tell their stories. He was born in Havana, Cuba, and lives in Brooklyn with his wife Jenna and his son Luco.

Sergio Alvarez is co-founder and lead designer at Vizzuality and CartoDB, a NYC-based company working on data analysis and visualization on stories that matter, such as climate change or biodiversity loss. He is a good runner and loves to ride his long board.

Posted by Scott Knaster, Editor
2013, By: Seo Master

seo Two new Open Web series: Open Web Podcast and This Week In HTML 5 2013

Seo Master present to you:

This week has seen two new series to cover Open Web technology. One of the messages from Google I/O was explaining how Google believes in, and is frankly betting on the Web as its platform. You should expect to see increasing examples of how we are putting our money (and effort) where our mouth is on this.

Since the Web is so decentralized, we have a deep need to communicate and discuss where we, as a collective are heading.

I have the pleasure to be joined by Alex Russell, notably of the Dojo Foundation, and John Resig, both creator of jQuery and employee of Mozilla Corp, for a new Open Web Podcast that focuses on news, events, and opinion on the state of the Open Web.

In the first episode, which you can either download directly or subscribe to, we delve into a lot of topics including new APIs and specifications, the new charge behind Firebug, the Open Web Foundation, and much more.

The early part of the podcast actually discusses the other series that started this week. Mark Pilgrim, a team-mate of mine at Google, kicked off This Week in HTML 5. Mark is taking the time to keep track of the myriad of changes to the specification, and will keep us abreast of the important features and decisions that are made by the group, head by our own Ian Hickson.

Mark discusses the big additions of Web Workers (Gears Workers standardized), and the clarification of alt tag usage in the img tag to have you using alt="{diagram}" and the like.

If you are interested in keeping up to date on HTML 5, you can subscribe to the WHATWG feed which is where Mark is doing his work.

If there is anything else that you would like to see from us, please drop us a comment below!2013, By: Seo Master

seo Optimisation data for HTML5 parser implementors 2013

Seo Master present to you:

Last month, just before I left on vacation, I posted three sets of data to help implementors of the HTML5 parser specification optimise their code. There are several implementations coming along, for example those that are part of the html5lib project and the one behind Validator.nu.

The three sets of data that I posted are all derived from parsing several billion documents from Google's Web search index using a parser I wrote in Sawzall.

The first set of data gives the relative aggregate distribution of invocations of the "in head", "in body", and "in table" insertion modes, for each of the insertion modes. This allows implementors to determine, for instance, that invoking the "in body" code while in a cell must be very efficient, while invoking the "in body" code from the "after frameset" code need not be as efficient, in case the implementor has a strategy that optimises one at the cost of another. See: documentation, data.

The second set of data gives the relative aggregate distribution of tokens for each phase/insertion mode pair. This can help implementors that are using a cascade of if statements decide on the right order for their statements. For instance, the most common token type seen in the "in body" insertion mode is character data, and the second most token is the start tag token for an a element, but the isindex start tag was almost never seen. This tells implementors that they should check for characters and a start tags long before checking for isindex tags. See: documentation, data.

The last set of data examines the number of attributes per element. It allows implementors to decide on the optimum memory allocation strategy for attributes. For example, since most elements have 9 or fewer attributes, the data structure that stores attributes can be optimised for simply having 9 attributes, using little memory, and if an element has more than this number of attributes, the implementation can switch to a separate implementation that is more memory-heaving but is optimised for large numbers of attributes. See: data.

I hope this data is useful!

2013, By: Seo Master

seo Gmail for Mobile HTML5 Series: Autogrowing Textareas 2013

Seo Master present to you: On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices. We shared the behind-the-scenes story through this blog and decided to share more of what we've learned in a brief series of follow-up blog posts. This week I'll talk about autogrowing textareas for entering large amounts of text.

When composing a long message in a web app, regardless of whether it's on a desktop or a mobile device, you really want to see as much of your draft as possible and make use of all the available screen space.
One of my biggest gripes are fixed-size textareas that restrict me to only a couple lines of visible text when my screen is actually many times larger than the size of the textarea.

In today's blog post, I'll share a JavaScript solution for textareas that automatically grow (vertically) to the size of the content. They make composing long messages much easier and, for all those iPhone users out there, takes away the need to scroll with the dreaded magnifying glass! We're working on getting this into Gmail for mobile but here it is now as a teaser of things to come.





Measuring the height of the content

The first step is to detect when the content has changed. Some solutions on the net recommend using a timer (see our previous post to find out more about timers) to check if content has changed. However, that approach is not ideal on a mobile device, where both battery life and processor power are limited.

Instead, we will listen for key-up events from the browser. This guarantees that we only measure the textarea when the content has actually changed.

<textarea id="growingTextarea" onkeyup="grow();"></textarea>

The second step is to actually measure the height of the content. There are solutions on the net that recommend keeping a copy of the content in a div and measuring the div to get the height; however, due to memory and processor limitations on a mobile device, those solutions don't scale well when the content gets large (and it's also hard to replicate textarea line wrapping behavior exactly in a div).

Therefore we will make use of the scrollHeight and clientHeight properties. For our purposes, scrollHeight is the height of all the content while clientHeight is the height of the content that's visible in the textarea (for more precise definitions, see scrollHeight and clientHeight)
function grow() {
var textarea = document.getElementById('growingTextarea');
var newHeight = textarea.scrollHeight;
var currentHeight = textarea.clientHeight;

}
One limitation of using scrollHeight and clientHeight is that we aren't able to shrink the textarea when content is deleted. When all the content of a textarea is visible, the scrollHeight is equal to the clientHeight. Therefore we aren't able to detect that our textarea is actually larger than the minimum size required to fit all the content (please do leave a comment if you think of a solution that doesn't require re-rendering the page).

Growing the textarea

To grow the text area, we modify the height CSS property:
if (newHeight > currentHeight) {
textarea.style.height = newHeight + 5 * TEXTAREA_LINE_HEIGHT + 'px';
}
Notice how we only change the height if newHeight > currentHeight. Depending on the browser, changing the height (even if it's to the same value) will cause the page to re-render. On a mobile device, we want to try our best to minimize the number of operations.

Also, we grow the textarea by five lines every time we grow. From a UI perspective, this reduces the amount of jitter when composing a message but, from a performance perspective, this reduces the number of times we need to re-render the page.

(Quick note for developers implementing this for a browser with scrollbars: you might want to modify the CSS overflow property to preventing the scrollbar from appearing and disappearing as you grow your textarea)

The complete solution

Growing textareas are easy to implement and they make composing long messages infinitely more usable. So go out there add it to all your web apps!
<script>
// Value of the line-height CSS property for the textarea.
var TEXTAREA_LINE_HEIGHT = 13;

function grow() {
var textarea = document.getElementById('growingTextarea');
var newHeight = textarea.scrollHeight;
var currentHeight = textarea.clientHeight;

if (newHeight > currentHeight) {
textarea.style.height = newHeight + 5 * TEXTAREA_LINE_HEIGHT + 'px';
}
}
</script>
<textarea id="growingTextarea"
onkeyup="grow();">
</textarea>

Previous posts from Gmail for Mobile HTML5 Series
Using timers effectively

2013, By: Seo Master

seo Mark your calendars: HTML5 hackathons 2013

Seo Master present to you:
By Mihai Ionescu, Developer Advocate

Cross-posted with the Google Commerce Blog

Over the past year, the web application ecosystem has been growing at an accelerating pace. Faster browsers and powerful web platforms like HTML5 have enabled developers to switch from native code to web based apps.

That’s why the Google Chrome and Commerce teams are holding several HTML5 Web App hackathons around the United States in early August. This is a great opportunity for developers to socialize, network, and play with the latest web APIs. During the hackathons, we'll cover the end-to-end process of developing an HTML5 application, publicizing with Chrome Web Store, and finally monetizing with In-App Payments.

In true hackathon style, participants will have the opportunity to create teams and work on a project together. At the end of the day, participants will present what they have created, and vote on the best apps or games. And of course we’ll have some awesome prizes for the winners.

The event is free of charge but space is limited. For more information and to register, please visit the location-specific links below:

August 1, 2011: New York
August 3, 2011: Chicago
August 8, 2011: Seattle
August 11, 2011: Mountain View

We’re looking forward to seeing the applications and games you build!

Mihai Ionescu is a Developer Advocate at Google helping developers build compelling applications using open web technologies. In his free time, when not skiing in the Sierras, Mihai enjoys traveling and exploring the great outdoors with his family.

Posted by Scott Knaster, Editor

2013, By: Seo Master

seo Swiffy: convert SWF files to HTML5 2013

Seo Master present to you:
By Marcel Gordon, Product Manager, Swiffy

Some Google projects really do start from one person hacking around. Last summer, an engineering intern named Pieter Senster joined the mobile advertising team to explore how we could display Flash animations on devices that don’t support Adobe Flash player. Pieter made such great progress that Google hired him full time and formed a team to work on the project. Swiffy was born!

Today we’re making the first version of Swiffy available on Google Labs. You can upload a SWF file, and Swiffy will produce an HTML5 version which will run in modern browsers with a high level of SVG support such as Chrome and Safari. It’s still an early version, so it won’t convert all Flash content, but it already works well on ads and animations. We have some examples of converted SWF files if you want to see it in action.

Swiffy uses a compact JSON representation of the animation, which is rendered using SVG and a bit of HTML5 and CSS3. ActionScript 2.0 is also present in the JSON object, and is interpreted in JavaScript in the browser. This representation makes the Swiffy animations almost as compact as the original SWF files.

Swiffy is a great example of how far the web platform has come. Swiffy animations benefit from the recent advancements in JavaScript execution speed and hardware accelerated 2D graphics in the browser. Viva la Web!

Update Sep. 8, 2011: links updated to reflect Swiffy's move out of Labs.

Marcel Gordon is the Product Manager for Swiffy, doing the make-up and carrying the drinks. On the weekends he dresses up as a pirate and takes his hamster for short walks.

Posted by Scott Knaster, Editor
2013, By: Seo Master

seo Let's make the web faster 2013

Seo Master present to you: From building data centers in different parts of the world to designing highly efficient user interfaces, we at Google always strive to make our services faster. We focus on speed as a key requirement in product and infrastructure development, because our research indicates that people prefer faster, more responsive apps. Over the years, through continuous experimentation, we've identified some performance best practices that we'd like to share with the web community on code.google.com/speed, a new site for web developers, with tutorials, tips and performance tools.

We are excited to discuss what we've learned about web performance with the Internet community. However, to optimize the speed of web applications and make browsing the web as fast as turning the pages of a magazine, we need to work together as a community, to tackle some larger challenges that keep the web slow and prevent it from delivering its full potential:
  • Many protocols that power the Internet and the web were developed when broadband and rich interactive web apps were in their infancy. Networks have become much faster in the past 20 years, and by collaborating to update protocols such as HTML and TCP/IP we can create a better web experience for everyone. A great example of the community working together is HTML5. With HTML5 features such as AppCache, developers are now able to write JavaScript-heavy web apps that run instantly and work and feel like desktop applications.

  • In the last decade, we have seen close to a 100x improvement in JavaScript speed. Browser developers and the communities around them need to maintain this recent focus on performance improvement in order for the browser to become the platform of choice for more feature-rich and computationally-complex applications.

  • Many websites can become faster with little effort, and collective attention to performance can speed up the entire web. Tools such as Yahoo!'s YSlow and our own recently launched Page Speed help web developers create faster, more responsive web apps. As a community, we need to invest further in developing a new generation of tools for performance measurement, diagnostics, and optimization that work at the click of a button.

  • While there are now more than 400 million broadband subscribers worldwide, broadband penetration is still relatively low in many areas of the world. Steps have been taken to bring the benefits of broadband to more people, such as the FCC's decision to open up the white spaces spectrum, for which the Internet community, including Google, was a strong champion. Bringing the benefits of cheap reliable broadband access around the world should be one of the primary goals of our industry.
To find out what Googlers think about making the web faster, see the video below. If you have ideas on how to speed up the web, please share them with the rest of the community. Let's all work together to make the web faster!





(Cross-posted on the Official Google Blog, and the Google Webmaster Central Blog)2013, By: Seo Master

seo HTML5 Rocks! 2013

Seo Master present to you: The term "HTML5" covers so many different topics that developers have a hard time getting up to speed on all of them. Some APIs and features are part of accepted standards, while some are still a work in progress. Additionally, there are a number of great resources out there, but most are still very hard to find. As announced on the chromium.org blog, Google is releasing a new developer resource dedicated to all that is HTML5, HTML5Rocks.com.


The site is broken up into four main sections:

Interactive Presentation
The presentation everyone is talking about! An interactive slide deck written entirely in HTML5 which demonstrates many of HTML5’s features. It even includes inline examples you can tinker with.

HTML5 Playground
The best way to learn this stuff is to try it out. The Playground is a sandbox area for editing and experimenting with live samples.

Tutorials
We're launching the site with an initial set of nine tutorials covering a bunch of different areas. We’ll continue to add more over time based on your input.

Resources
We've hand-picked some of our favorite tools, reference material, and sites; all generated by the online community. Do check them out. They’ll come in handy when developing your next web app.

We hope HTML5Rocks will help developers put HTML5 to use in the real world, today. We’d love to hear your thoughts on improving the site! Send us a tweet at @ChromiumDev or post to the Chromium HTML5 group with requests for content.

2013, By: Seo Master

seo Race across screens and platforms, powered by the mobile web 2013

Seo Master present to you: Author PictureBy Pete LePage, Chromium team

Cross-posted with the Chromium Blog

You may have seen our recent demo of Racer at Google I/O, and wondered how it was made. So today we wanted to share some of the web technologies that made this Chrome Experiment “street-legal” in a couple of months. Racer was built to show what’s possible on today’s mobile devices using an entirely in-browser experience. The goal was to create a touch-enabled experience that plays out across multiple screens (and speakers). Because it was built for the web, it doesn’t matter if you have a phone or a tablet running Android or iOS, everyone can jump right in and play.
   
Racer required two things: speedy pings and a consistent experience across screens. We delivered our minimal 2D vector drawings to each device’s HTML5 Canvas using the Paper.js vector library. Paper.js can handle the path math for our custom race track shapes without getting lapped. To eke out all the frame rate possible on such a large array of devices we rendered the cars as image sprites on a DOM layer above the Canvas, while positioning and rotating them using CSS3’s transform: matrix().

Racer’s sound experience is shared across multiple devices using the Web Audio API (available in latest iOS and Android M28 beta). Each device plays one slice of Giorgio Moroder’s symphony of sound—requiring five devices at once to hear his full composition. A constant ping from the server helps synchronize all device speakers allowing them to bump to one solid beat. Not only is the soundtrack divided across devices, it also reacts to each driver’s movements in real time—the accelerating, coasting, careening, and colliding rebalances the presence of every instrument.

To sync your phones or tablets, we use WebSockets, which enables rapid two-way communication between devices via a central server. WebSocket technology is just the start of what multi-device apps of the future might use. We’re looking forward to when WebRTC data channels—the next generation of speedy Web communication—is supported in the stable channel of Chrome for mobile. Then we’ll be able to deliver experiences like Racer with even lower ping times and without bouncing messages via a central server. Racer’s backend was built on the Google Cloud Platform using the same structure and web tools as another recent Chrome Experiment, Roll It.

To get an even more detailed peek under the hood, we just published two new case studies on our HTML5 Rocks site. Our friends at Plan8 wrote one about the sound engineering and Active Theory wrote one about the front-end build. You can also join the team at Active Theory for a Google Developers Live event this Thursday, June 13, 2013 at 3pm GMT for an in depth discussion.

Pete LePage is a Developer Advocate on the Google Chrome team and helps developers create great web applications and mobile web experiences.

Posted by Ashleigh Rentz, Editor Emerita
2013, By: Seo Master

seo Gmail for Mobile HTML5 Series: Suggestions for Better Performance 2013

Seo Master present to you: On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices. 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. This week, I'll talk about a few small things you can do to improve performance of your HTML5-based applications. Our focus here will be on performance bottlenecks related to the database and AppCache.

Optimizing Database Performance

There are hundreds of books written about optimizing SQL and database performance, so I won't bother to get into these details, but instead focus on things which are of particular interest for mobile HTML5 apps.

Problem: Creating and deleting tables is slow! It can take upwards of 200 ms to create or delete a table. This means a simple database schema with 10 tables can easily take 2-4 seconds (or more!) just to delete and recreate the tables. Since this often needs to be done at startup time, this really hurts your launch time.

Solution: Smart versioning and backwards compatible schema changes (whenever possible). A simple way of doing this is to have a VERSION table with a single row that includes the version number (e.g., 1.0). For backwards-compatible version changes, just update the number after the decimal (e.g., 1.1) and apply any updates to the schema. For changes that aren't backwards compatible, update the number before the decimal (e.g., 2.0) at which point you can drop all the tables and recreate them all. With a reasonable schema design to begin with, it should be very rare that a schema change is not backwards compatible and even if this happens every month or so, users should get to use your application 20, 30 even 100 times before they hit this startup delay again. If your schema changes very infrequently, a simple 1, 2, 3 versioning scheme will probably work fine; just make sure to only recreate the database when the version changes!

Problem: Queries are slow! Queries are faster than creates and updates, but they can still take 100ms-150ms to execute. It's not uncommon for traditional applications to execute dozens or even hundreds of queries at startup – on mobile this is not an option.

Solution: Defer and/or combine queries. Any queries that can be deferred from startup (or at any other significant point in the application) should be deferred until the data is absolutely needed. Adding 2-3 more queries on a user-driven operation can turn an action from appearing instantaneous to feeling unresponsive. Any queries that are performed at startup should be optimized to require as few hits to the database as possible. For example, if you're storing data about books and magazines, you could use the following two queries to get all the authors along with the number of books and magazine articles they've writen:

SELECT Author, COUNT(*) as NumArticles
FROM Magazines
GROUP BY Author
ORDER BY NumArticles;

SELECT Author, COUNT(*) as NumBooks
FROM Books
GROUP BY Author
ORDER BY NumBooks;


This will work fine, but the additional query will generally cost you about 100-200 ms over a different (albeit less pretty) query like:

SELECT Author, NumPublications, PubType
FROM (
SELECT Author, COUNT(*) as NumPublications, 'Magazine' as PubType, 0 as SortIndex
FROM Magazines
GROUP BY Author
UNION
SELECT Author, COUNT(*) as NumPublications, 'Book' as PubType, 1 as SortIndex
FROM Books
GROUP BY Author
)
ORDER BY SortIndex, NumPublications;

This will return all the entries we want, with the magazine entries first in increasing order of number of articles, followed by the book entries, in increasing order of the number of books. This is a toy example and there are clearly other ways of improving this, such as merging the Magazines and Books tables, but this type of scenario shows up all the time. There's always a trade-off between simplicity and speed when dealing with databases, but in the case of HTML5 on mobile, this trade-off is even more important.

Problem: Multiple updates is slow!

Solution: Use Triggers whenever possible. When the result of a database update requires updating other rows in the database, try to do it via SQL triggers. For example, let's say you have a table called Books listing all the books you own and another called Authors storing the names of all the authors of books you own. If you give a book away, you'll want to remove it from the Books table. However, if this was the only book you owned by that author, you would also want to remove the author from the Authors table. This can be done with two UPDATE statements, but a "better" way is to write a trigger that automatically deletes the author from the Authors table when the last book by this author is removed. This will execute faster and because triggers happen asynchronously in the background, it will have less of an impact on the UI than executing two statements. Here's an example of a simple trigger for this case:

CREATE TRIGGER IF NOT EXISTS RemoveAuthor
AFTER DELETE ON Books
BEGIN
DELETE FROM Authors
WHERE Author NOT IN
(SELECT Author
FROM Books);
END;
We'll get into more detail on triggers and how to use them in another performance post to come.

Optimizing AppCache Performance

Problem: Logging in is slow!

Solution: Avoid redirects to the login page. App-Cache is great because it can launch the application without needing to hit the network, which makes it much faster and allows you to launch offline. One problem you might encounter though, is that the application will launch and then you'll need to hit the network to get some data for the current user. At this point you'll have to check that the user is authenticated and it might turn out that they're not (e.g., their cookies might have expired or have been deleted). One option is to redirect the user to a login page somewhere, allow him to authenticate and then redirect him back to the application. Regardless of whether or not the login page is listed in the manifest, when it redirects back to your application, the entire application will reload. A nicer approach is for the application itself to display an authentication interface which sends the credentials and does the authentication seamlessly in the background. This will avoid any additional reloads of the application and makes everything feel faster and better integrated.

Problem: AppCache reloading causes my app to be slow!

Solution: List as few URLs in the manifest as possible. In a series of posts on code.google.com, we talked about the HTML5 AppCache manifest file. An important aspect of the manifest file is that when the version gets updated, all the URLs listed in the file are fetched again. This happens in the background while the user is using the application, but opening all these network connections and transferring all that data can cause the application to slow down considerably during this process. Try to setup your application so that all the resources can be fetched from as few URLs as possible to speed up the manifest download and minimize this effect. Of course you could also just never update your manifest version, but what's the point of having rapid development if you never make any changes?


That's a brief intro to some performance considerations when developing HTML5 applications. These are all issues that we ran into ourselves and have either fixed or are in the process of fixing in our application. I hope this helps you to avoid some of the issues we ran into and makes your application blazing fast!

We plan to write several more performance related posts in the future, but for now stay tuned for next post where we'll discuss the cache pattern for building offline capable web applications.



Previous posts from Gmail for Mobile HTML5 Series
HTML5 and Webkit pave the way for mobile web applications
Using AppCache to launch offline - Part 1
Using AppCache to launch offline - Part 2
Using AppCache to launch offline - Part 3
A Common API for Web Storage
2013, By: Seo Master

seo Google I/O: Now online, starting with all things Client 2013

Seo Master present to you: The Google Client Team had an exciting and inspiring two days last week at Google I/O. We had the opportunity to talk to developers and have insightful conversations on what we're doing in the realm of HTML 5, Chrome, V8, Native Client, and 3D graphics on the web.

Today we're excited to reflect on these conversations at I/O, and kick off a series of videos and presentations from Google I/O. Starting with the Client track today, session videos and presentations from I/O will be posted online over the course of the next seven days and free to the world, on the Google I/O website.

Chrome: Extensions, Internals, V8 and more

Aaron Boodman gave a great talk on creating extensions for Chrome, and built several extensions live during his talk. I think this reflects our commitment to make it easy to build extensions, and I hope that developers -- not only those in the room, but those around the world who watch the recorded video of Aaron's talk -- will be inspired to create great extensions.

Darin Fisher delved into Chrome internals, managing to cover large swaths of Chrome code, philosophy, and lore without breaking a sweat. Darin's talk is a great way for developers to see that Chrome is more than just a fast browser with a slick UI -- we believe that developers at I/O came away realizing that there is a lot going on behind the scenes that sets Chrome apart.

Mads Ager talked about V8, walking attendees through the reason Google decided to build a new JavaScript engine, how some of the internals of V8 work including hidden classes, inline caching and garbage collection, and recent improvements made to further speed up JavaScript execution in V8. We were glad to present a thought-provoking session for developers, as attendees left the session with impressed and contemplative looks on their faces.

HTML5, Native Client, O3D and moving the web forward

Matt Papakipos, in addition to making an appearance in Wednesday's keynote, gave a great talk on where Chrome is, with respect to HTML5 and the open web platform. He explored what the platform means for developers, how they can use it, as well as the vision going forward. Matt delivered this talk to a packed room - attendees were spilling out to the aisles and doorways in our largest session room at the Moscone Convention Center in San Francisco. We're thrilled and humbled that developers are as excited as we are about the web platform and where we are taking it.

At the session on Native Client, Brad Chen got developers excited about the possibility of running native code as part of their web applications. Brad gave a comprehensive low-down on how Native Client works, and how it can be used to further strengthen the platform and move the web forward.

Vangelis Kokkevis and Gregg Tavares gave a talk on bringing 3D graphics to the web via O3D. Vangelis started the presentation with an overview of the O3D project and its goals and highlighted some its most significant features. Gregg then took over and demonstrated how, in a few simple steps, one can go from a blank HTML page to the beginnings of an entertaining mini-game with only a handfull of calls to the O3D API.

In addition, Henry Bridge led a panel with developers from Large Animal and Crazy Pixel, sharing insights about developing 3D graphics applications using O3D and getting developers excited about 3D on the web. You can also view sandbox video interviews with these two developers (Large Animal, Crazy Pixel) in the Developer Sandbox section, along with many other developers.

Browsers and standards development

To give developers more insight into how standards development and implementation in browsers work, we put together a panel with Jonas Sicking from Mozilla, Charles McCathieNevile from Opera, and myself, moderated by Mike Schroepfer (formerly of Mozilla now at Facebook). At this session, we talked more about the vision advanced by various browsers, and deliberated questions on where the browsers and the web are going.

Beyond the sessions, I/O provided the Client team the opportunity to interact with developers through Fireside Chats, where developers freely asked a broad range of questions. We also staffed Chrome Office Hours, where I/O attendees could stop by with their burning questions about the browser and chat with the team. We got developers excited about Chrome extensions, HTML5, <video>, O3D and more at the the Client developer sandbox pod.

All in all, we're thrilled to have spent two days with developers in conversation about Chrome, the web platform, and a shared future that we are all working so hard to create. We're excited to now bring these conversations to a larger community of developers with our I/O session videos and presentations. If you like, drop us comments through the Google Friend Connect gadget we have enabled on the session web pages - we'd be delighted to hear from you.

2013, By: Seo Master

seo Gmail for Mobile HTML5 Series: A Common API for Web Storage 2013

Seo Master present to you: On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices. 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. Over the last few weeks we've talked about how to use the AppCache functionality of HTML5 to launch an application offline. We discussed the impact that AppCache can have on your mobile web applications, as you enable users to launch your app faster in the face of flaky or slow internet connections. This week, I'll talk about how we're using both HTML5 Structured Storage and the Google Gears Database to make devices tolerate flaky network connections.



Although these technologies allow web applications to cache user data on the mobile device and perform data modifications locally, HTML5 Structured Storage uses an asynchronous model, where the Google Gears Database uses a synchronous model. This difference makes it difficult to develop an application on top of both platforms. We dealt with this problem by creating the Web Storage Portability Layer (WSPL) for Gmail. Coming soon under a liberal open source license to code.google.com/p/webstorageportabilitylayer, WSPL provides a common API that supports an identical asynchronous programming model for both platforms by using a worker thread in Gears. Let's take a look!

The WSPL consists of a collection of classes that provide asynchronous transactional access to both Gears and HTML5 databases. It can be used to execute nested statements within callbacks, create statement templates, and optionally control the synchronous/asynchronous modes of the Gears Database Wrapper. There are five basic classes.

google.wspl.Statement - A parametrizable SQL statement class
google.wspl.Transaction - Used to execute one or more Statements with ACID properties
google.wspl.ResultSet - Arrays of JavaScript hash objects, where the hash key is the table column name
google.wspl.Database - A connection to the backing database, also provides transaction support
google.wspl.DatabaseFactory - Creates the appropriate HTML5 or Gears database implementation

Let's take a look at how we can use this API to perform a simple query, starting with the creation of a Database. Note that you'll need to provide a URL to the worker file hosted from your domain.

var database = google.wspl.DatabaseFactory.createDatabase('db name', 'http://yourdomain/dbworker.js');

You can then execute SQL statements without worrying about the specifics of HTML5 and Gears. Refer to the recent blog posts about AppCache to find steps you can follow to see your database contents using sqlite3.
var statement = google.wspl.Statement('SELECT col from test_table;');
database.createTransaction(function(tx) {
tx.executeAll([statement], {onSuccess: function(tx, resultSet) {
// Statement succeeded.

for(; resultSet.isValidRow(); resultSet.next()) {
window.console.info(resultSet.getRow()['col']);
}
}, onFailure: function(error) {
// Statement failed.
}});
}, {onSuccess: function() {
// After transaction commits, before any other starts.
}, onFailure: function(error) {
// After transaction fails, before any other starts.
}});
I've found that using the Gears database asynchronously will nicely split up the JavaScript execution, allowing event handlers and other code to execute between the callbacks. This can improve the responsiveness of your application if you're using long transactions. You can also use SQL triggers to avoid the read-modify-write pattern that causes "ping ponging" between threads -- either the main thread and Gears worker or the main thread and the HTML5 SQL thread.

That's all I'll show you for now, but you can look for more details about the Web Storage Portability Layer at Google I/O, May 27-28 in San Francisco where we'll be presenting a session on the architecture of a generic application using HTML5. We'll also be available at the Developer Sandbox and are looking forward to meeting you in person. Stay tuned for the next post where we'll talk about improving the performance of HTML5-based web applications.

2013, By: Seo Master

seo Yahoo! Pipes and the HTML5 canvas tag 2013

Seo Master present to you: This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. Today's post is a guest post written by Paul Donnelly and Jonathan Trevor of the Yahoo! Pipes team.

Yahoo! Pipes is a free online service that lets you remix popular feed types (json, xml, rss, and atom) and create data mashups using a visual editor. You can use Pipes to run your own web projects, or publish and share your own web service without ever having to write a line of code. Pipes also allows you to create feeds from web sites that don't provide RSS/XML by extracting data straight from the HTML document. In this post, we'll talk about how the Pipes editor uses the HTML5 canvas tag extensively, challenges we faced using the canvas tag and a few solutions we came up with to address said challenges.

Pipes is widely known for its visual editor that allows you to drag pre-configured modules onto its canvas and wire them together:


We use the canvas tag to create the fluid, draggable wiring to connect modules. The thumbnails of Pipes on the Browse and My Pipes sections aren't jpegs - we use canvas to "draw" them dynamically from the Pipe definition.



Since the iPhone's web browser supports the canvas tag, we were able to use the same code to generate the thumbnails for our iPhone version.

The Pipes editor is where all the visual programming is done. By dragging modules to the workspace, you can set up a visual workflow of what you want processed. To complete the flow, you need to connect the modules in the sequence you want. At the bottom or top of the modules are terminals, where you connect the wires from one to the other. The terminals are typed, meaning you can only connect an output to an input that has the same type.

The canvas tag is a HTML tag that provides a fixed drawing area that can be used to draw graphics. The tag is manipulated using Javascript to create 2D drawing primitives such as lines, circles, polygons and even gradients. While many browsers support the canvas tag natively, some do not. For example, IE does not support canvas natively. To address this, IE uses a canvas wrapper, excanvas (created by Google) to ensure full cross-browser compatibility.

The canvas tag enabled us to leverage the built-in capabilities of CSS and the DOM for the rest of the interface while still providing us with 2D drawing capabilities. We observed a few issues with the canvas tag that developers should be cognizant of when considering to use it in their applications:
  • There are cross-browser issues related to resizing the canvas tag once it's been created. In Firefox you're ok. In Safari, you need to destroy and re-create the region to get the canvas to draw properly. With IE, the region doesn't clear and redraw automatically.

  • In the canvas element you can't say, "this line being drawn should be this class". There is no separation between the presentation and the markup. It has to be programmatically done and it's cumbersome to keep tweaking JS code to change the look and feel of what is being rendered. So how do you tell the canvas what style of wire to draw? We chose to use the styles of the source and target terminals to infer the wire styles in their CSS. We put the configuration of the wire style (color, width, thickness etc..) into the background image filename of each terminal which the JavaScript could parse to create a compatible render style for our canvas wires.

  • Performance rapidly decreases with size, especially with other overlapping DOM elements such as many transparent elements and other canvas tags. There is a tradeoff therefore between using one canvas tag with many wires or one canvas for each wire. The latter worked better for our usage within the Pipes editor.

  • There are no "canvas" events about the "inside" of the canvas, It's just a 2D layer, and mixing DOM elements with canvas has significant event occlusion issues. Even if you are only drawing a wire within the canvas rectangle, anything under the canvas won't see events (mouseover, click etc) as the bounding box acts like any other element. This issue involved the most iterations in our interaction design. Initially we wanted the wires above the modules, but because of the event occlusion that the canvas tag created, we couldn't do a drag/drop (since the targets were always "under" the canvas). Since the wires had to be on the bottom, we then tried making the Pipes' modules themselves semi-transparent. Not only does this give a faded out look to the whole page, but many transparent elements create significant rendering performance issues. We finally picked a solution that kept the wires under the modules and when mouse-overing the canvas containing the wire bounding box, we made the modules connected to either end of the wire in the canvas semi-transparent using animation. This allows parts of the UI to show the wiring flowing around and under modules when the user focuses (by moving the mouse over) on a wire.


If you would like to learn more and talk with us about the pros and cons of canvas and some of the interesting challenges above, visit us at the Developer Sandbox at Google I/O coming up in a couple weeks.

2013, By: Seo Master

seo Gmail for mobile HTML5 Series - Part 3: Using AppCache to Launch Offline 2013

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

2013, By: Seo Master

seo Creating 2D Games with JavaScript & HTML5 2013

Seo Master present to you:
By Dominic Szablewski, creator of the Impact Game Engine

This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.


Impact is a JavaScript game engine that uses the HTML5 Canvas and Audio elements for graphics and sound, instead of relying on any browser plugins. Impact's main focus is on classic 2D games. Examples include the Biolab Disaster Jump'n'Run game and the Z-Type Space Shooter. These games, like many other 2D games, draw sprites in front of multiple background layers.


Each background layer is drawn from a tileset, an image containing all the individual building blocks, and a tilemap, a 2D array that tells the renderer where to draw each of these tiles. Similarly, sprites are drawn from an animation sheet, an image with all the animation's frames.

This technique has proven so efficient and flexible that it was enforced in hardware on early game consoles: the Super Nintendo could not do anything other than draw tiled background maps and sprites. There was no way to directly access single pixels on the screen.

The HTML5 Canvas element is perfectly equipped for these kinds of games. Most importantly, the Canvas API's drawImage() method allows us to draw only a certain part of a tileset or animation sheet to the screen. In Impact, however, you don't have to deal with any of the Canvas API methods directly. Instead, you specify your tilemaps and animation sheets and let the engine handle the details.

This is how you'd create an animation from an animation sheet:


// Each animation frame is 16x16 pixels
var sheet = new ig.AnimationSheet( 'player.png', 16, 16 );

// This creates the "run" animation: it has 6 frames (the 2nd row
// in the image), with each one being shown for 0.07 seconds
var run = new ig.Animation( sheet, 0.07, [6,7,8,9,10,11] );
Similarly, here's the code needed to create and draw a background layer:
// Create a 2D tilemap
var map = [
[5, 3, 4],
[2, 7, 1],
[6, 0, 3]
];

// Specify a layer with a tilesize of 16px and our tilemap
var layer = new ig.BackgroundMap( 16, map, 'tileset.png' );
layer.draw();
You don't have to create these tilemaps by hand. Impact comes with a powerful level editor called Weltmeister, which makes it easy to draw background layers and position your entities (non-static objects in the game world) in your levels.


When drawing on a Canvas, the performance is mostly bounded by the number of draw calls. It is far more efficient to draw one or two very large images than to draw several hundred small ones. This means that drawing background layers tile by tile can be quite slow, especially on mobile devices.

The Impact engine therefore has a special "pre-render" mode that you can enable on background layers. This mode will first draw the tilemap into large chunks of 512x512 pixels when loading a level, and then use these chunks to fill the screen instead of drawing the layer tile by tile. With this technique, you can get good frame rates even for fast-paced games on Android and iOS devices.

Impact also handles sound, input, timing, and much more for you. It's by no means a game engine that can do everything – and it doesn't try to be one – but it's very good at the things it can do.


Come see Impact in the Developer Sandbox at Google I/O on May 10-11.

Dominic Szablewski is the creator of the Impact Game Engine. He recently finished his Bachelor Thesis about HTML5 Gaming and now lives the dream by selling Impact and making games.

Posted by Scott Knaster, Editor
2013, By: Seo Master

seo Gmail for mobile HTML5 Series - Part 2: Using AppCache to Launch Offline 2013

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


2013, By: Seo Master

seo Gmail for mobile HTML5 Series: Using AppCache to Launch Offline - Part 1 2013

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

2013, By: Seo Master

seo Fridaygram: Chrome tools, Goldberg machines, Lehrer songs 2013

Seo Master present to you: Author Photo
By Scott Knaster, Google Developers Blog Editor

If you use Google Chrome and you like to live on the edge, you might want to try Google Chrome Canary. There's a new version of Chrome Canary pretty much every day, and it gets the latest features. Of course, because it's built every day, sometimes it’s not very stable and it falls right off the leading edge it's balanced on. That’s why, for safety, you can install and run the stable version of Chrome alongside the Canary version.

Recent Canary builds have added cool new features to the developer tools section of Chrome. Specifically, you can now test mobile environments by simulating different screen sizes and by emulating touch events using the mouse. These features are on the Settings page of developer tools.


If you haven’t visited Chrome's developer tools before, you might be pleasantly surprised at all the nifty things available there. To get to developer tools, click the Wrench in Chrome, then choose Tools > Developer Tools. Have a look around – if you need a guide, see the documentation.

Some developers make hardware too, and a bunch of them competed in this year’s Rube Goldberg Machine Contest at Purdue University. The winning team broke a record – their own record – by building a machine that takes 300 steps to inflate and pop a balloon. When you consider that 14 people spent 5000 hours on this project, you realize the power of creativity mixed with craziness.

Finally, take a moment to celebrate Tom Lehrer's birthday week by listening to some of his classic tunes. As a math professor / musician / parodist, nobody expresses the spirit of Fridaygrams better than Tom Lehrer.


Fridaygram posts are just for fun. They're designed for your Friday and weekend enjoyment. Each Fridaygram item must pass only one test: it has to be interesting to us nerds. Disclaimer: we do not advocating poisoning pigeons, whether in the park or elsewhere.
2013, By: Seo Master

seo HTML5 and WebKit pave the way for mobile web applications 2013

Seo Master present to you: When I first started at Google, we were building a Java ME email client for the phones of the day. It's an excellent product - still the fastest, slickest way to get your Gmail on many devices because of Java ME's widespread penetration. Yet it always bothered us that this client didn't really leverage the core strength of the desktop Gmail platform: sheer ease of access from anywhere, and constant updates and improvements. To use the client, you have to figure out how to install it and possibly navigate confusing network permission pop-up dialogs, and improvements could only be rolled out a few times a year in upgrades that required every user to download and reinstall their software.

The mobile team started thinking about how we could bring the benefits of the server-side approach to these clients. We started thinking about a world where we could deliver a GUI specified in XML to a Java ME client, enabling us to iterate on the server side and deliver new features that could delight users when they were ready, rather than on a lengthy release cycle. I was especially struck by a friend who said "What I like about Gmail is that it just constantly keeps getting better. It's like waking up to a new little present from Google each month!" We wanted our mobile users to feel the same way, so we felt the logical thing to do would be to build a general client that could be controlled by the server.

Not too long after, the team first saw the new Android browser. Still in its early stages, the Android browser was built on the latest version of WebKit and could render desktop pages with ease. The XHTML, images, JavaScript, and CSS that could be rendered on this platform presented great potential for building very high-end web applications. However, this was ages before Android was due to ship and Android would only be one of many mobile platforms.

Those drawbacks aside, we couldn't help but think that new browsers in Android's league would eventually become a reality. These powerful browsers could have the kind of functionality we needed to build top-notch, offline user interfaces that didn't need to be "installed" by users or "upgraded". Gmail could be Gmail: a constantly evolving way to handle lots of email quickly and efficiently. The only fly in the ointment was the need for Gears: users would have to download a browser plug-in, and most web browsers on mobile devices don't even support that. What we really needed was for Gears to inspire innovation in HTML itself, so that the whole web could move forward.

Enter HTML5. We're very excited about the evolving HTML5 standard because it enables mobile and desktop website designers to deliver the advantages of client-side and server side development to their users simultaneously! New APIs let web applications start offline and store data on the client. The canvas API lets you draw complex user interfaces, or you can use advanced CSS tricks to get the browser to render a rich UI. In addition, the W3C Geolocation API is being adopted and implemented by browser developers, enabling entire new categories of web applications to be built. The benefits are clear: you can develop fantastic new applications, benefit from server-side analytics and iteration to deliver features that your users want, and know that offline functionality keeps things running as the user moves in and out of coverage. Your users can enjoy fast, capable web apps that they can access from any device, without the need to copy their data from place to place or worry about installing software or being online.

We decided to build new versions of mobile Gmail and mobile Calendar on top of this functionality. First, we built a small javascript wrapper around the database functionality in HTML5 and Gears. This wrapper abstracts away the differences between the two APIs, so that our applications are supported on the broadest set of browsers possible while older browsers get updated with implementations of the new offline APIs. We noticed that we weren't the only ones thinking about this: a quick search shows that other developers saw the similarities too. The main difference between the Gears database API and the HTML5 database API is that the Gears API is synchronous, requiring separate worker threads to do the database calls, while the HTML5 database API uses callbacks and is asynchronous. With the wrapper built, we knew our code would run on all high-end mobile browsers today, and look forward to even more distribution as everybody implements HTML5.

We knew we could apply various approaches to building better experiences for Gmail and Calendar. The key principle we kept in mind is an age-old one: KISS. Simply caching responses in the database for re-use is surprisingly effective: you can get a lot of improvement with just a read-only environment. This approach worked well for Calendar, where usage is predominantly read-only and we can rely on the user being online to make edits.

For Gmail, more complexity was needed. A queue of user actions needs to be maintained in the database (in case the user runs out of battery or powers down for their flight). Later, when the device is back online, it can execute that queue of mails to send, archive or delete, and so on.

Having the ability to store your data and actions offline isn't much good if you can't start the application while offline. So besides making use of the database API, we needed a way to get the application itself loaded without an internet connection. The HTML5 specification comes to the rescue here, with an application cache that is capable of storing all resources in your web app so that the browser can load them while offline. This API has just one small drawback: once you've decided you're going to override how HTTP GET works to fetch resources from the application cache, you also commit to never issuing a GET for a resource the cache doesn't know about. The specification contains methods for extending what URIs the cache knows exist, but these entry points are not widely implemented in production browsers. Instead, it's important to use HTTP POST requests for all dynamic data, since POST requests are never cached and therefore do reach the network.

The end result is an incredible thing: a web app that loads offline, and lets you read your Gmail or view your events provided the data have previously been cached. The experience is seamless as you ride the subway or the bus through terrible coverage: your data are ready, quickly, all the time. To see the new Gmail for mobile web app, go to gmail.com from an Android-powered device or iPhone (OS 2.2.1 or above).

Of course we didn't get there without a few hard knocks. As an evolving standard, HTML5 has been fast-changing target and we've skinned our knees and bruised ourselves along the way. So rather than just deliver the fruit of all those bumps and scratches to end users in our own products, we decided we wanted to write a few blog posts to share what we've learned so that others can take advantage of HTML5 as well. In addition, we look forward to opportunities like our upcoming developer conference, Google I/O (May 27-28 in San Francisco, CA) where we'll be hosting a few sessions, to meet you in person and share demos and know-how.

Whether or not you can make it out to Google I/O, stay tuned to the blog for upcoming posts with examples such as how to avoid making your databases too large, handle upgrades gracefully, and tune performance.

2013, By: Seo Master
Powered by Blogger.