O3D update: New capabilities and expanded compatibility

We're happy to announce that today we shipped a substantial update to O3D, an API for creating rich 3D applications in a web browser. With today's release, we focused on addressing a theme we heard in the requests and feedback from the community: that O3D should run as well as possible on many different types of hardware. Toward that end, we're releasing two new additions: software rendering and feature requirements. If you've already installed the O3D plugin, you should receive these additions automatically.

Software rendering allows O3D to use the main processor to render 3D images if the machine running the app doesn't have supported graphics hardware. While the hardware O3D requires to run in hardware-accelerated mode is fairly modest by today's standards (a DirectX 9, Pixel Shader 2.0 capable graphics card), there are nonetheless PCs that don't meet these requirements, and we think it's important for web apps to run on all machines, regardless of hardware.

Because software rendering is significantly slower than hardware-accelerated rendering, we're also introducing a concept called "feature requirements" that will help minimize how often O3D will have to fall back to software rendering. Feature requirements allow developers to state upfront that their app will require certain hardware capabilities to render properly. If the machine running the app supports those features, O3D will run it fully hardware accelerated; if however, it is lacking any of the required capabilities, O3D will drop into a software rendered mode. Anecdotally, we found that this tiering allows 45 of our 48 samples to now run in hardware-accelerated mode with less capable graphics cards.

Finally, while it has nothing to do with extending hardware support, we're also adding a couple other goodies: a full-screen mode to make O3D apps more absorbing and a community gallery to feature cool demos that use O3D (like Infinite Journey, the first game developed outside Google using O3D). If you've developed an application or sample that would be useful to the O3D community, please be sure to submit it for our team to review for inclusion in the gallery using this form.

By Henry Bridge, Product Manager

Access SimpleXMLElement Object Attributes

PHP simplexml_load_string is a simple way to extract xml data into an object. If you have the following result from calling

$obj = simplexml_load_string($xml);

SimpleXMLElement Object

([@attributes] => Array

([status] => success)

[auth] => SimpleXMLElement Object

([token] => dxoYGmwncmntH07jJGro5h0rxNfE2Ni6


 [seq] => 33)


)

you can access status by

$obj->attributes()->status

Parthiv Patel

Bhaishri Info Solution

Sr. PHP Developer

Limdi Chowk, AT PO. Nar, Di. Anand

Nar, Gujarat

388150

India

pparthiv2412@gmail.com

7383343029

DOB: 12/24/1986

Gmail for Mobile HTML5 Series : Cache Pattern For Offline HTML5 Web Applications

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 the cache pattern for building offline-capable web applications.

I recently gave a talk (preserved YouTube here) about the cache pattern and the Web Storage Portability Layer (WSPL) at Google I/O. It was exciting getting to give a talk at the Moscone Center as previously I had only ever been one of the audience members. The conference seemed to go by in a blur for me as I was sleep-deprived from getting the WSPL to "just good enough" to actually be released. (And some ofyou have already pointed out that I missed several bugs.) In my talk, I provided a general overview of the cache pattern and this post expands on the handling of hit determination and merging server and local changes.

The cache pattern is a design pattern for building an offline-capable web application. We implemented the cache pattern to make Gmail for Mobile tolerant of flaky wireless connections but the approach is generally applicable. Here's how it works. Consider a typical AJAX application. As shown in the diagram, we have a web application with a local model, view and controllers. The user interacts with theapplication and the controller dispatches XmlHttpRequests (XHRs for short) to the server. The server sends asynchronous requests to the application which it inserts into the model.

As shown in this next diagram, in the cache pattern, we insert a cache between the application and the server. Having done so, many requests that would otherwise require a round-trip to the network.

A software cache like this one shares a great deal conceptually with hardware caches. When designing the cache used in Gmail for mobile, we used this similarity to guide our design. For example, to keep our cache as simple as possible, we implemented a software equivalent to a write-through cache with early forwarding and LRU eviction. The cache pattern in general (and consequently our implementation) has four important data flows as shown in the diagram.

• Cached content bound for the UI.
• Changes made to the cache by the user in the UI. These need to be both reliably sent to the server and updated locally in the cache so that reads from the cache for UI updates show the state including user changes.
• The changes recorded in the cache need to be sent upstream to the server as the network connection is available.
• Changes made to the server (like email delivery in the case of Gmail) need to be merged into the contents of the cache.

As shown in the diagram we also need a place to actually write the data. We use the WSPL library to write a cache implementation portable across both Gears and HTML5 databases.

To actually implement these four data flows, we need to decide on a hit determination mechanism, a coherency strategy and a refresh approach.

Hit Determination

At its heart, a cache is a mapping from keys to values: the UI invokes the cache with a key and the cache returns the corresponding element. While this sounds pretty simple, there is an additional source of complexity if the application wants to provide the user with summary listings of some subset of all values available from the server. To provide this feature, the cache needs to contain not only "real" data values but additional "index" values that list the keys (and possibly user-visible summaries) for "data" values. For example, in Gmail for mobile, the cache stores conversations as its "real" data values and lists of conversations (such as the Inbox in Gmail for Mobile) as its "index" values. Keys for index values are computed specially to record what subset of the complete index is cached locally. For example, in Gmail for Mobile, while a user's Inbox may contain thousands of conversations, the cache might contain an index entry whose data values lists metadata for only conversations 1000 through 1100. Consequently, Gmail for Mobile's cache extends keys with the cached range so that a request for metadata for conversations 1101 through1110 would be considered a cache miss.

Coherency and Refresh

Perhaps the most complex aspect of the cache implementation is deciding how to get updated content from the server and how to merge server updates with changes made locally. A traditional hardware cache resolves this problem by only letting one processor modify its a cache at a time and have the memory broadcast any changes to all the other caches in the system. This approach cannot work here because the Gmail server can't connect to all of its clients and update their state. Instead, the approach we took for Gmail for Mobile was for the client device regularly poll the server for alterations.

Polling the server for changes such as new email or the archiving of email by the same user from a different device implies a mechanism for merging local changes with server side changes. As mentioned above, Gmail for Mobile is a write-through cache. By keeping all of the modifications to the cache in a separate queue until they have been acknowledged, they can be played back against updates delivered from the server so that the cache contains the merge of changes from the server and the local user. The following diagram shows the basic idea:

The green box in the diagram shows the contents of the cache's write buffer changing over time and the cloud corresponds to the requests in-flight to the server with time advancing from left to right in the diagram. The function names shown in the diagram are from the simplenotes.js

example file in the Web Storage Portability Layer distribution. Here, the user has applied some change [1] and the cache has written it to the write buffer and has then requested new content resulting in query [Q]. The cache prefixes the outstanding actions from the write buffer to the query. Action [1] is marked as needing a resend on some sort of network failure.

Later, the user makes change [2] to the UI which causes the cache to append it to the write buffer in the applyUIChange call. Later still, another query is made and so, the cache sends [1][2][Q] to the server. In the mean time, the user makes yet another change [3]. This is written to the write buffer. Once changes [1] and [2] are acknowledged by the server along with the new cache contents for query [Q], changes [1] and [2] are removed from the write buffer. However, to keep the cache's state reflecting the user's changes, change [3] is applied (again) over top of the result for [Q].

Simplifying the implementation of this reapplication stage is the most important benefit of implementing a write-through cache. By separating the changes from the state, it becomes much easier to reapply the changes to the cache once the server has delivered new content to the cache. As discussed in a previous post, the use of SQL triggers can greatly improve database performance. Whether updating or re-updating, triggers are a great way to make the application of changes to the cache much more efficient.

Cached Content To the UI

The first of the four data flows is delivering content to the UI is reasonably easy: query the cache for the desired content and when the query completes, forward the request to the UI. If you look at the getNoteList_ function from the simplenotes.js example code included in the WSPL distribution, you'll see that the delivering cached content to the UI has the following basic steps:

perform hit determination: deciding if the requested cache contents are actually in the cache.

• create a database transaction, and while in the transaction
• query the database for the desired key
• accumulate the results
• then outside of the transaction, return the result to the UI.

Changes From The UI

The second flow (applyUiChange) is recording changes made by the user to the write buffer. It has a very similar structure

• create a database transaction, and while in the transacation
• write the change to the write buffer
• wait for a trigger to update the state of the cache.

Updates Bound For The Server

As discussed above, once the changes have been written to the write buffer, they still have to be sent to the server. This happens by prepending them to queries bound for the server. The fetchFromServer from the example is responsible for this. As might be familiar by now, the flow is

• create a database transaction and while in the transaction
• query the write buffer for all the entries that need to be sent to the server
• accumulate the entries
• then outside the transaction, send the combination of changes and query to the server

Changes From The Server

Finally, we need to merge the changes from the server into the cache as is done in the insertUpdate method from the example. Here the flow is as follows:

• create a database transaction and while in the transaction
• update the directory
• write the new content into the cache
• touch the changes in the write buffer that need to be re-applied to the cache
• wait for the trigger to complete its update
• then, outside of the transaction, send the response to the UI if it was satisfying a cache miss.

That's a brief intro to the cache architecture as found in Gmail for mobile. We're continuing to improve our implementation of this basic architecture to improve both the performance and robustness of Gmail for mobile. Please stay tuned for follow on blog posts.

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
Suggestions for better performance

By Robert Kroeger, Software Engineer, Google Mobile Team

AdSense for Mobile Applications Beta

Are you developing free iPhone or Android applications? With our new beta product - AdSense for Mobile Applications, you can monetize your mobile applications by showing contextually targeted ads and/or placement targeted ads alongside your application content. We provide you with iPhone and Android SDKs and example applications that request and display AdSense ads. Our SDKs also support DoubleClick ads.

You can show 320x50 text and image ads linked to HTML webpages in your application. These ads are targeted to the keywords that you send us in the AdSense (or DoubleClick) ad request. The keywords must be relevant to your application content. If your application content is loaded from a webpage that is customized for iPhones and Android handsets, then you can also send us the webpage URL for us to target ads. The ads may also be placement targeted which means an advertiser can specifically target to your application.

Our iPhone SDK is compatible with iPhone OS 3.0, and our Android SDK is compatible with Android 1.5 SDK. The SDKs include a library that can be linked in to your application which exposes methods to fetch and show ads. You must place a maximum of one ad per screen at the top or bottom (see the screenshot from the Backgrounds iPhone application). When a user clicks on the ad in your application, you can choose whether the user should view the advertiser's website in iPhone Safari or a full-screen UIWebView on the iPhone. For Android applications, our API defaults to opening the advertiser's website in the native browser.

To get started with monetizing your iPhone or Android application, sign up today on the AdSense for Mobile Applications website. We can't wait to have you join our beta network!

By Jennifer Lin, Software Engineer, Google Mobile Team

Let's make the web faster

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!



Posted by Urs Hoelzle, SVP, Operations and Bill Coughran, SVP, Engineering

(Cross-posted on the Official Google Blog, and the Google Webmaster Central Blog)

Introducing the Virtual Keyboard API

Inability to input text in native language has been a problem for many non-latin script based languages. This may happen for many reasons. Sometimes, users do not have the keyboard layout for their native language installed in the system they happen to be using (for example, a tourist using an internet cafe in a foreign country). Sometimes, such a keyboard layout is not well developed or not widely available. It is worse for web developers because there is no way they can ensure that their users have access to this very basic input technology.

To address this issue, today, we added Virtual Keyboard API into the Google AJAX Language API. With this API, developers can help their users to input text, regardless if they have the native keyboard layout installed in their Operating Systems or not.

Pic 1: Russian Virtual Keyboard layout

Another advantage is the ability to provide a better user experience for multilingual web sites. For example, on a Russian/Thai bilingual dictionary editing web site, users would type in Russian in the header, and then see a Thai description. With the Virtual keyboard API, developers can load a Russian virtual keyboard layout and bind with all the Russian text fields, and load a Thai virtual keyboard layout and bind them to Thai fields. The Virtual Keyboard API then will automatically swap to the corresponding keyboard layout depending upon the user action.

Sometimes users may not be familiar with the key assignment of their keyboard layout. Virtual keyboard also shows the key assignment inside the page to allow users to input text by either pressing key or by clicking mouse on the virtual onscreen layout.

With this initial release, we are launching 5 language layouts. These are: Arabic, Hindi, Polish, Russian, and Thai.

We plan to roll out support for more keyboard layouts in the future. You can find more details by reading through the class reference and trying the Code Playground samples. Feedback is always welcome in our support forum and IRC channel.

By Manish Bhargava and Frank Tang, Google Internationalization Team

Overriding Controllers and Actions in Magento

I had explained a way to add extra controllers to existing route. Here I am going to explain another method which is used for overriding controllers and actions. Like my each post on tips & tricks, I am going to first explain where the trick is applicable! I am considering that readers of this post are aware of MVC architecture in Magento.

Let me explain the difference between the both tricks. The trick explained in previous post is used when we need additional URLs in same route i.e. additional controllers and actions. I have already explained an example there. Here we need to change the behavior of existing controller and action. For example, when a customer adds a product to shopping cart, addAction of CartController of Mage_Checkout module is called. If we want to override this by My_Checkout, MycartController, myaddAction as similarly as we can override Models and Blocks in our own modules. So the the trick in previous post is used for overloading while the trick here is used for overriding.

Of course, this too can be done just by simple XML configuration (apart from creating custom controllers and actions) but without using route rewriting approach! Let's take a same example above where we want to override action for checkout/cart/add. First create My_Checkout module with MycartController class and myaddAction method defined within it. The way to do this is better explained in this wiki. Then the configuration required in etc/config.xml of My_Checkout module is like below:

<global>

  <routers>

    <checkout> <!-- Mage_Checkout module -->

      <rewrite>

        <cart> <!-- CartController -->

          <to>mycheckout/mycart</to> <!-- My_Checkout module, MycartController -->

          <override_actions>true</override_actions>

          <actions>

            <add> <!-- addAction -->

              <to>mycheckout/mycart/myadd<to> <!-- My_Checkout/MycartController/myaddAction -->

            </add>

          </actions>

        </cart>

      </rewrite>

    </checkout>

  </routers>

</global>

Here we also need configuration to define module front name for My_Checkout module as below:

<frontend>   <!-- It will be admin for overriding admin controller -->

  <routers>

    <mycheckout>

      <use>admin</use>

      <args>

        <module>My_Checkout</module>

        <frontName>mycheckout</frontName>

      </args>

    </mycheckout>

  </routers>

</frontend>   <!-- It will be admin for overriding admin controller -->

Note: The above configuration examples only display portions of config.xml file. Please do not consider it as a complete configuration.

Simple isn't it? Now let's understand how it works. The work flow of this rewrite process is little bit tricky.

1. When an checkout/cart/add action is going to be dispatched, first it is passed through rewrite process.
2. Rewrite process tries to find global/routers/checkout/rewrite/cart node is found in configuration, where checkout is front name of Mage_Checkout module and cart indicates Mage_Checkout_CartController.
3. If this node is not found, rewrite process is not be continued and returned to dispatch process. So the action is executed normally. Otherwise, rewrite process is continued.
4. Now, under this node, it tries to find whether override_actions node is true or false. By default value of override_actions is true. So if it is not added in configuration, it is considered as true.
5. If override_actions is true, it overrides all actions of Mage_Checkout_CartController with same actions of My_Checkout_MycartController as defined by to node value mycheckout/mycart. For example, if we have defined addAction and indexAction methods inside My_Checkout_MycartController, then it automatically overrides both addAction and indexAction of Mage_Checkout_CartController. In short using to node and override_actions node we can override whole controller instead of individual actions.
6. If actions/add node is defined where, add indicates addAction of Mage_Checkout_CartController, then override_actions node value is not considered and overrides action by value of actions/add/to node which is mycheckout/mycart/myadd i.e. My_Checkout module, My_Checkout_Mycontroller and myaddAction. So we can also override individual actions by this type of configuration.

-By Parthiv Patel

Parthiv Patel

Bhaishri Info Solution

Sr. PHP Developer

Limdi Chowk, AT PO. Nar, Di. Anand

Nar, Gujarat

388150

India

pparthiv2412@gmail.com

7383343029

DOB: 12/24/1986

Google Technology User Groups

My favorite part about Google I/O is the dozens of interesting conversations with developers -- getting a first-hand look at the different things that they are doing with our technologies. That's the spirit of the Google Technology User Groups -- regular meetups where local developers can get together to network and discuss, demo, and hack on Google's many developer offerings.

From lightning talks in Mountain View, to App Engine hackathons in Tokyo, to lectures in Berlin, the GTUGs are a great place to meet fellow developers and learn (or teach) something new.

At Google I/O, there were many folks eager to bring the spirit of the conference back to their hometowns by starting up GTUGs of their own. Since the conference ended, our list of current GTUGs has grown to include this 'baby boomer' generation of chapters. The following are all new groups looking for members and starting to set up their first events.

If there's one near you, check it out! Let the organizers know you're interested; suggest topics for discussion and even offer to do a talk about your own experiences.

Europe
Paris GTUG - http://groups.google.com/group/paris-gtug
Hamburg GTUG - http://www.hamburg-gtug.org
GTUG Munich - http://gtug-muc.org
Istanbul GTUG - http://www.istanbul-gtug.org/
Polish GTUG - http://www.gtug.pl

North America
Tri-Valley California GTUG - http://groups.google.com/group/tv-gtug
Berkeley GTUG - http://www.meetup.com/Berkeley-GTUG/
San Diego GTUG - http://www.meetup.com/sd-gtug/
NYC GTUG - http://sites.google.com/site/nycgtug
New Jersey GTUG - http://nj-gtug.org/
Philly/Delaware GTUG - http://sites.google.com/site/phillygtug/
Boston GTUG - http://groups.google.com/group/boston-gtug
Denver GTUG - http://groups.google.com/group/denver-gtug
Twin Cities GTUG - tc-gtug.org
Austin GTUG - http://sites.google.com/site/austingtug/
Michigan GTUG - http://groups.google.com/group/mi-gtug

MadGTUG - http://madgtug.org
Cleveland GTUG - http://groups.google.com/group/cleveland-gtug

Utah GTUG - http://utahgtug.blogspot.com/
Laguna GTUG - www.laguna-gtug.org
Quebec GTUG - http://groups.google.com/group/gtug-quebec/?pli=1

South America
Chile GTUG - http://groups.google.com/group/gtug-cl
Argentina GTUG - http://groups.google.com/group/gtug-ar

Asia
Kuala Lumpur GTUG - http://sites.google.com/site/gtugkl/
Hyderabad GTUG - http://sites.google.com/site/hydgtug/

Also a big shout-out to our existing chapters:

Silicon Valley GTUG - http://www.meetup.com/sv-gtug (watch the organizers, Kevin and Van, talk about GTUGs at Google I/O)
Pune GTUG - http://pune-gtug.blogspot.com/
Chico GTUG http://www.chico-gtug.org
Berlin GTUG - http://www.berlin-gtug.org
Tokyo GTUG - http://tokyo-gtug.org/


View GTUGs in a larger map

Don't see a chapter near you? Start one! Join our GTUG managers mailing list. Other info at gtugs.org.

By Stephanie Liu, Google Developer Programs

Google I/O Interactive Map: Now with videos + some Open Source goodness!

If you attended Google I/O 2009 a few weeks ago, you may have noticed a kiosk station on the 2nd and 3rd floors of Moscone West labelled 'Interactive Conference Map, powered by Google Maps'. The kiosk simply pointed to a JavaScript Maps API-based interactive map of the venue I created in my 20% time.

Now that all the I/O session videos and presentations are live, we took the opportunity to mash up the videos with our interactive conference map to provide developers with an alternate way to navigate through 80+ keynote and session videos, and bring the action at I/O to life virtually. For example, here are videos of sessions that took place in Room 1 (click the tabs for Wednesday and Thursday sessions). And here's where the keynote sessions took place. Check out where we filmed interviews with I/O sandbox developers on their apps, technical challenges and business best practices.


Now, hopefully you enjoyed using the map and are now thinking, "Cool, I want to do something like this for my next event!" (or your college campus, or such). If you are, then good news everyone, I've open sourced the interactive conference map and all relevant resources. Inside the project, you'll also find a how to article outlining the steps I went through to create the map.

If you attended I/O, then I hope you enjoyed it and had time to stop by the conference map kiosk! If not, no worries, just make sure to check out the open source project and see if you can use the code and/or techniques in your next mapping project!

By Roman Nurik, Developer Programs Engineer

Gmail for Mobile HTML5 Series: Suggestions for Better Performance

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.

By Derek Phillips, Software Engineer, Google Mobile

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

Another Round of Deprecation Policies for Labs Graduates

We recently published deprecation policies for a number of APIs that graduated from Google Code Labs. They state how long we'll support each version from when it's deprecated or a newer version is introduced. It will be 3 years for most, but the time period varies a bit from product to product.

• AdWords API terms
• AdSense API terms
• AJAX Feed API terms
• AJAX Language API terms
• AJAX Libraries API terms
• AJAX Search API terms
• Apps APIs terms
• Calendar Data API terms
• Chart API terms
• Health API terms
• Geo APIs terms (Earth API, Mapplets, Maps API, Maps API for Flash, and Static Maps API)
• Secure Data Connector terms

We still need to update the terms for a couple remaining graduates, but should have them all done within the next couple weeks.

By Neel Kshetramade, Google Developer Programs

Nicholas C. Zakas: Speed Up Your JavaScript

Nicholas C. Zakas delivers the seventh Web E^xponents tech talk at Google. Nicholas is a JavaScript guru and author working at Yahoo!. Most recently we worked together on my next book, Even Faster Web Sites. Nicholas contributed the chapter on Writing Efficient JavaScript, containing much of the sage advice found in this talk. Check out his slides and watch the video.



Nicholas starts by asserting that users have a greater expectation that sites will be fast. Web developers need to do most of the heavy lifting to meet these expectations. Much of the slowness in today's web sites comes from JavaScript. In this talk, Nicholas gives advice in four main areas: scope management, data access, loops, and DOM.

Scope Management: When a symbol is accessed, the JavaScript engine has to walk the scope chain to find that symbol. The scope chain starts with local variables, and ends with global variables. Using more local variables and fewer global variables results in better performance. One way to move in this direction is to store a global as a local variable when it's referenced multiple times within a function. Avoiding with also helps, because that adds more layers to the scope chain. And make sure to use var when declaring local variables, otherwise they'll end up in the global space which means longer access times.

Data Access: In JavaScript, data is accessed four ways: as literals, variables, object properties, and array items. Literals and variables are the fastest to access, although the relative performance can vary across browsers. Similar to global variables, performance can be improved by creating local variables to hold object properties and array items that are referenced multiple times. Also, keep in mind that deeper object property and array item lookup (e.g., obj.name1.name2.name3) is slower.

Loops: Nicholas points out that for-in and for each loops should generally be avoided. Although they provide convenience, they perform poorly. The choices when it comes to loops are for, do-while, and while. All three perform about the same. The key to loops is optimizing what is performed at each iteration in the loop, and the number of iterations, especially paying attention to the previous two performance recommendations. The classic example here is storing an array's length as a local variable, as opposed to querying the array's length property on each iteration through a loop.

DOM: One of the primary areas for optimizing your web application's interaction with the DOM is how you handle HTMLCollection objects: document.images, document.forms, etc., as well as the results of calling getElementsByTagName() and getElementsByClassName(). As noted in the HTML spec, HTMLCollections "are assumed to be live meaning that they are automatically updated when the underlying document is changed." Any idea how long this code takes to execute?

   var divs = document.getElementsByTagName("div");
   for (var i=0; i < divs.length; i++) {
       var div = document.createElement("div");
       document.body.appendChild(div);
   }

This code results in an infinite loop! Each time a div is appended to the document, the divs array is updated, incrementing the length so that the termination condition is never reached. It's best to think of HTMLCollections as live queries instead of arrays. Minimizing the number of times you access HTMLCollection properties (hint: copy length to a local variable) is a win. It can also be faster to copy the HTMLCollection into a regular array when the contents are accessed frequently (see the slides for a code sample).

Another area for improving DOM performance is reflow - when the browser computes the page's layout. This happens more frequently than you might think, especially for web applications with heavy use of DHTML. If you have code that makes significant layout changes, consider making the changes within a DocumentFragment or setting the className property to alter styles.

There is hope for a faster web as browsers come equipped with JIT compilers and native code generation. But the legacy of previous, slower browsers will be with us for quite a while longer. So hang in there. With evangelists like Nicholas in the lead, it's still possible to find your way to a fast, efficient web page.

By Steve Souders, Performance Evangelist


Check out other blog posts and videos in the Web Exponents speaker series:

• John Resig: Drop-in JavaScript Performance
• Doug Crockford: JavaScript: The Good Parts
• Steve Souders: Life's Too Short, Write Fast Code (part 2)
  
• PPK: The Open Web Goes Mobile
• Rob Campbell: Debugging and Testing the Web with Firebug
  

Google I/O: Session videos on building apps using the AJAX and Data APIs

One of the best things about attending Google I/O is the chance to meet developers who are using our APIs and interacting with Google technology in ways we could never imagine. Not only was it amazing to see exciting examples of apps built on the AJAX and Data APIs being demoed at the developer sandbox, but it was also interesting to meet other developers who are just starting to use many of our APIs for their specific needs and cool ideas. Hopefully, by making all of our sessions available for free to watch on your own time, many of you who are interested in Google's APIs will get a better understanding of the ways we are making our API offerings easier to use, more efficient and much more feature rich.

Big Announcements & More

One of the most exciting announcements at this year's I/O was the developer preview of Google Wave. After its introduction during the Day 2 keynote, there were three sessions devoted to the Google Wave APIs: Programming With and For Google Wave, Google Wave: Powered by GWT, and Google Wave: Under the hood. We hope you're as excited as we are, and can't wait to see how you use these tools.

Another new product announcement this year was Google Web Elements, which allow you to easily add your favorite Google products onto your own website. There are elements for Google News, Maps, Spreadsheets, YouTube and others, with more to come. Be sure to check out the Day 1 keynote for a complete introduction to the simple copy and paste power of Google Web Elements.

Keeping webmasters in mind, two sessions were all about optimizing your site for search. In one talk, Matt Cutts reviewed real sites that *you* submitted. talking through real-life issues that effect developers when it comes to optimizing their app for search. The other session focused on how to maximize your site, your content, and your application's exposure to search engines.

Javascript & Google AJAX APIs

The session on Custom Search Engines focused on helping your users search the sites and topics that are relevant to you. Nick Weininger discussed some of the ways to embed search and ads onto your site (including the new Custom Search element), then customize the look and feel of the results. Adobe was on hand to show how they're using Custom Search Engines to enhance their products and insert contextual search into the developer's programming workflow. We also announced the launch of the Custom Search gadget for Blogger which gives your blog's visitors the ability to search not just your posts, but web pages linked from your blog, your blog lists, and link lists.

In the session Implementing your Own Visualization Datasource, attendees learned about building a server-side data source compatible with the Google Visualization API, including hearing about the experience from a Salesforce.com expert. Itai Raz also gave a great session on using the Visualization API with GWT and treated the audience to advanced Javascript tricks such as wrapping visualizations as gadgets.

Ben Lisbakken's session detailed some advanced Javascript techniques and then delved into some of great tips and tracks he learned while creating the Code Playground, a tool which can help developers learn about and experiment with many of Google's APIs. Some of the highlights include increasing the security and performance of applications and learning why App Engine is so easy on which to develop.

Jon Kragh of VastRank showed off some neat ways he's Using AJAX APIs to Navigate User-Generated Content, including using Google Maps to display nearby colleges and translating reviews into the viewer's language. Also, Michael Thompson explored the idea of Building a Business with Google's free APIs using example Google Gadgets, Google Gadget Ads, Mapplets, and the Maps API.

Google Data APIs

Jeff Fisher and Jochen Hartmann spoke on the future direction of the YouTube API as it becomes increasingly social. They used two sample applications to demonstrate the use of the activity feeds as well as the new "SUP" feed that allows high traffic websites to monitor YouTube for activity in a scalable manner.

The session about writing monetizable YouTube apps focused on creating applications that allowed access to YouTube videos in creative ways. In the talk, Kuan Yong showed how to expertly navigate through the YouTube API terms of service in order to avoid business pitfalls so that developers can monetize their own apps.

Eric Bidelman and Anil Sabharwal discussed the Document List Data API in detail, highlighting common enterprise use cases such as sync, migration, sharing, and legal discovery. Partners Syncplicity, OffiSync, and gDocsBar showed off compelling demos.

In the talk on the evolution of the Google Data protocol, Sven Mawson outlined all of the new features in the Google Data APIs that will help in the creation of more efficient applications. Two of the new additions included a compact and customizable JSON output and the option to retrieve only the parts of a feed that you want using partial GET.

Monsur Hossain and Eric Bidelman showed how to build a read/write gadget using OAuth and the Google Data JavaScript library. They went through a step by step set of instructions that explained how to set up the gadget code, how to get a token using the OAuth proxy, and how to read and write data to Blogger using the JavaScript library inside of an iGoogle gadget.

Google Geo APIs

Mano Marks and Pamela Fox started with a grab bag session covering the vast spectrum of Geo APIs, discussing touring and HTML 5 in KML, the Sketchup Ruby API (with an awesome physics demo), driving directions (did you know you can solve the Traveling Salesman Problem in Javascript?), desktop AIR applications, reverse geocoding, user location, and monetization using the Maps Ad Unit and GoogleBar. Pamela finished by sneak previewing an upcoming feature in the Flash API: 3d perspective view.

In the session on performance tips for Maps API mashups, Marcelo Camelo announced Google Maps API v3, a latency-oriented rewrite of our popular JS Maps API. Also see Susannah Raub's more in-depth talk about Maps API v3. Then Pamela gave advice on how to load many markers (by using a lightweight marker class, clustering, or rendering a clickable tile layer) and on how to load many polys (by using a lightweight poly class, simplifying, encoding, or rendering tiles). Sascha Aickin, an engineer at Redfin, showed how they were able to display 500 housing results on their real estate search site by creating the "SuperMarker" class.

Mano and Keith presented various ways of hosting geo data on Google infrastructure: Google Base API, Google App Engine, and the just-released Google Maps data API. Jeffrey Sambells showed how ConnectorLocal used the API (and their own custom PHP wrapper) for storing user data.

On the same day as announcing better integration between the Google Earth and Google Maps JS APIs, Roman Nurik presented on advanced Earth API topics, and released a utility library for making that advanced stuff simple.

By Adam Feldman and Brandon Bilinski, Google Developer Team

Everybody's talking: the Social track at Google I/O

I had a great time at Google I/O -- meeting lots of developers from around the world who are interested in developing applications that use social data. In addition to building web applications for traditional social networks like orkut, MySpace and hi5, developers are also looking at enterprise and mobile applications which take advantage of the social graph, gadgets for Google's platforms like iGoogle, Google Calendar and Gmail, and gadgets for the 5 million websites and blogs powered by Google Friend Connect. We had some important questions raised in many of the sessions and also in the fireside chats with containers and app developers. It was exciting to see the whole OpenSocial ecosystem come together to discuss the current status and progress of social technologies, as exemplified by the I/O Developer Sandbox.

All the sessions at Google I/O were recorded, and videos and presentation materials are now available on the Google I/O website. Here's a little more info about the sessions in the social track:

Google and the Social Web
Daniel Holevoet outlined all the ways Google uses social technologies, highlighting those services which allow developers to extend them using the OpenSocial APIs. During his talk, Dan announced the new support for OpenSocial gadgets in Google Calendar, which include hooks into a calendar-specific API for accessing the currently-selected date range. Dan demonstrated the Quartermile OpenSocial application he wrote along with Arne Rooman-Kurrik and showed how the app could be used for different purposes across iGoogle, Gmail and Google Calendar and talked about how it could be used on any website via Google Friend Connect or on traditional social networks supporting the OpenSocial APIs. Of course, Dan didn't get to cover all the exciting news about Google's social initiatives during this talk-- a real-time gadgets API was announced during the Developer Sandbox!

Google Friend Connect Gadgets: Best Practices in Code and Interaction Design
Jonathan Terleski (lead designer on Google Friend Connect) and I presented this session on best practices for building Google Friend Connect (GFC) gadgets for the millions of websites and blogs using GFC today. We gave a brief overview of OpenSocial, followed by some design principles and a basic framework to think about when building GFC gadgets: what are the social objects, how do users contribute them, and how to users consume them? In the last part of the talk, I discussed how to use page context in your gadgets for content, skinning and language while showing some small bits of code to accomplish each. Most importantly, we announced the opening of submissions to the Google Friend Connect gadget directory and support for OpenSocial 0.9 in GFC gadgets.

Beyond Cut and Paste - Deep integrations with Google Friend Connect
In this talk, Arne Roomann-Kurrik and Chris Schalk talked about how they built the Plane Crazy site for flying enthusiasts and the Chow Down site for restaurant connoisseurs as example sites demonstrating how to integrate Google Friend Connect with existing login systems and add social functionality using the REST and RPC APIs. While these sites were built on top of Google App Engine (using Java and PHP), they talked about the other client libraries and raw protocols available for similar integrations. The Chow Down site is already open-sourced, and the Plane Crazy site will be shortly.

Google Friend Connect and the Real World
Patrick Chanezon led this session along with Shivani York, Henry Chan and Srivaths Lakshmi of TIME.com and Paul Berry of HuffingtonPost talking about how they integrated Google Friend Connect into their sites. Both TIME.com and HuffingtonPost used Google Friend Connect to create social lists where you rank the top items from the news, such as "Top 10 Movie Catchphrases" and "The World's Most Famous Swimsuits." Khris Loux, of JS-Kit, concluded the session by addressing why it's a good idea to integrate with Google Friend Connect and how the web is enhanced by having open API access to social data.

Building a Business with Social Apps
Shawn Shen and Chewy Trewhalla, Developer Advocates at Google, and Gerardo Capiel, VP of Product Management for the MySpace Open Platform, led this session showing how developers can make a living by building social apps. Virtual currencies, the recent OpenSocial extension proposal for a virtual currency spec and implementations on hi5, 51.com and other networks were discussed. In talking with a wide variety of developers and preparing this session content, our team learned even more about this industry, and we hope you can too.

Designing OpenSocial Apps for Speed and Scale
How do you use standard web optimization techniques in combination with existing and new features of OpenSocial 0.9 to develop a fast social application which scales efficiently? Arne Rooman-Kurrik and Chris Chabot examined this question in great depth. They took the Quartermile application which they developed and dived into the bandwidth, cpu and monetary savings achieved by applying a variety of optimizations--from image spriting, to data pipelining and proxied content. From the naive implementation to the optimized implementation, they showed how you could improve latency by nearly 70% and drastically reduce the cost of hosting a social application.

The Social Web: An Implementer's Guide
Joseph Smarr, Chief Platform Architect at Plaxo, led this standing-room-only session about the current state of the social web and how "The Web is now social... and the Social Web is now open." He recapped progress made in the last year, with the emergence and increasing adoption of a variety of technologies which make up the Open Stack: Open ID, XRDS-Simple, OAuth, Portable Contacts, OpenSocial. He gave many demos, including demonstrating the death of the "password anti-pattern" leading to a 92% conversion rate on users importing their contacts from sites supporting OpenID+OAuth and Portable Contacts.

Powering Mobile Apps with Social Data
Many people today have a mobile device which has internet access, and they probably use those devices as much (if not more!) than they use their computers. I explored the different ways to use social data from the web to enhance the experience users have with their mobile devices. I demonstrated and dove into the code of three different types of apps -- pure web apps targeted at mobile devices, a web app which uses some native GPS functionality via Google Gears and adding a social scoreboard to the "Divide and Conquer" open source native Android application. I then spoke a bit about the future of mobile development and how the features available between native applications and web applications are beginning to merge with the new HTML5 and W3C standards which provide access to native functionality such as databases, app caches and GPS location data.

OpenSocial in the Enterprise
Social networks are typically thought of as tools for personal communication, but they've increasingly become important in the enterprise world as well. Chris Schalk of Google led this panel along with representatives from IBM, Salesforce.com, Oracle, eXo, SAP and Atlassian to share the ways enterprises have used OpenSocial technology outside of and behind the firewall.

There's a wealth of new information in these presentations which were all prepared especially for Google I/O, including several new announcements. The presenters also developed quite a bit of code for Google I/O, which we'll be releasing as Apache-licensed open source projects over the next couple weeks. Stay tuned to the OpenSocial blog for those releases.

By Ryan Boyd, OpenSocial Team

Google App Engine @ I/O: Java, offline processing, great partners. and more

2009 has been a busy year for the App Engine team, but all along we've looked forward to Google I/O and the excitement it brings to Google's developer community. At I/O last year, App Engine was brand new and many attendees were just getting familiar with the project. Well, what a difference a year makes - this year, in addition to sharing new information about our project, we got to learn about an amazing host of App Engine projects from you, our developers!

First, the big news - we are excited to announce open signups for our Java language runtime. During Wednesday's keynote, Engineering Manager Kevin Gibbs and Product Manager Andrew Bowers demoed the combined power of App Engine and GWT, all with easy deployment from the Eclipse IDE. If you've not tried our new language yet, please head over to the Admin Console to signup, then download the SDK and get programming.

The engineers behind Google App Engine for Java presented two sessions. First, Toby Reyelts and Don Schwarz introduced the new runtime with App Engine: Now Serving Java, including details of how our Java language layer exposes the power of Google's infrastructure. Be sure to check out the interactive game they demo'd with audience participation! Digging a bit deeper, Max Ross showed us The Softer Side of Schemas - how he mapped Java Persistence Standards to App Engine's datastore.

In addition to the new Java runtime, App Engine developer Brett Slatkin previewed some eagerly anticipated functionality: offline tasks. In his talk Offline Processing on App Engine: a Look Ahead, Brett revealed the first few milestones of App Engine's plan for offline processing with our upcoming Task Queue API. Leveraging the power of a web hook (an HTTP request body and URL) as the fundamental unit of execution on the web, this new API will allow you to organize and enqueue tasks for efficient background processing. Stay tuned to the App Engine blog for this feature's launch.

The App Engine team is always eager to share information about our infrastructure and how things work under the hood. Alon Levi kicked things off Wednesday morning with From Spark Plug to Drive Train: Life of an App Engine Request, in which he showed new information about how an application's incoming requests are received, scheduled, and executed by App Engine. Ryan Barrett presented some of the theoretical, yet practical challenges faced by the App Engine team with Transactions Across Datacenters (and Other Weekend Projects). Finally, Brett Slatkin took the stage once again, with Building Scalable, Complex Apps on App Engine, to give you insights on advanced data structures and algorithms.

In addition to the App Engine team, we were thrilled to have App Engine customers and partners present about their experience with the platform:

• The Walk Score team shared their experience combining App Engine with other products in App Engine Nitty-Gritty: Scalability, Fault Tolerance, and Integrating Amazon EC2.
• Ola Bini gave a language implementor's view of our new Java runtime with JRuby and Ioke on Google App Engine for Java.
• Daniel Wilkerson presented distributed database theory in A Design for a Distributed Transaction Layer for Google App Engine.
• Guillaume Laforge from SpringSource did a rapid walkthrough of Groovy and how to write Groovy applications for App Engine with Groovy and Grails in App Engine

Last but not least, more partners joined our Developer Sandbox to share their experience building projects on Google App Engine: 3scale, Best Buy, BuddyPoke, EZAsset, Gigapan, LifeAware, Salesforce.com, SpringSource, and ThoughtWorks.

Thanks for making this year's Google I/O a fantastic success! We have much more in store for 2009, so be sure to watch the App Engine blog for updates!

By Mike Repass, App Engine Team

Java is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries.