Saturday, March 19, 2011

[Gd] Update on GWT support for IE9

| More

Google Web Toolkit Blog: Update on GWT support for IE9

In keeping with the GWT philosophy of making it possible to write no-compromise AJAX in any modern browser, GWT 2.3 (in progress) will support IE9. We're adding a new user.agent property "ie9" and the notion of fallback properties, so any browser-specific bindings not yet implemented in ie9 will fall back to ie8 and show a compile-time warning that a fallback impl was used.



In the mean time, you can tell IE9 to behave as IE8 by inserting the following in the head section of your GWT host page:


<meta http-equiv="X-UA-Compatible" content="IE=8" />

Assuming that IE continues to maintain backward compatibility, you may want to insert the equivalent tag for IE9 once GWT 2.3 ships in order to make your app somewhat future-proof for future IE versions. For more information on document compatibility in Internet Explorer, see http://msdn.microsoft.com/en-us/library/cc288325(VS.85).aspx


The IE9 dev mode issue reported back in Dec is fixed in GWT 2.2.0: http://googlewebtoolkit.blogspot.com/2010/12/support-for-gwt-dev-mode-in-ie-9.html


You can follow the status of known IE9 issues here:


URL: http://googlewebtoolkit.blogspot.com/2011/03/update-on-gwt-support-for-ie9.html

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Dev channel has been updated to 11.0.696.14 for Macintosh, Windows, Linux and Chrome Frame platforms

The following bugs were fixed
  • about:gpu can still launch GPU process even though GPU is blocked by software rendering list (Issue 76115).
  • REGRESSION: After crash, Restore infobar shows up everytime you open a link from external app (Issue 75654 ).
  • App context-menu doesn't disappear even after uninstalling the extension, causes crash when selected (Issue 75662).
  • A known crash (Issue 74777).
  • Fails SPDY-related check (Issue 75657).

You can find out about getting on the Dev channel here: http://dev.chromium.org/getting-involved/dev-channel.



If you find new issues, please let us know by filing a bug at http://code.google.com/p/chromium/issues/entry

Karen Grunberg
Google Chrome
URL: http://googlechromereleases.blogspot.com/2011/03/dev-channel-update_17.html

[Gd] Stable and Beta Channel Updates

| More

Google Chrome Releases: Stable and Beta Channel Updates


The Chrome Stable and Beta channels have been updated to 10.0.648.151 for Windows, Mac, Linux and Chrome Frame.  This release blacklists a small number of HTTPS certificates.  If you find new issues, please let us know by filing a bug. Want to change to another Chrome release channel? Find out how.
 
Jason Kersey
Google Chrome
URL: http://googlechromereleases.blogspot.com/2011/03/stable-and-beta-channel-updates_17.html

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Dev channel has been updated to 11.0.696.12 for Macintosh, Windows, Linux and Chrome Frame platforms

The following bugs were fixed
  • New York Times Chrome app crashes on the Chorme Dev Channel (Issue 75563).
  • Sync login dlg is truncated (Issue 72490 ).
  • Status bar / target URL not shown when hovering over links(Issue 75268).
  • Several known crashes (Issues 75171 and 75443 and 75828).
  • Bookmark focus is not lost when moved away from the bookmark bar (Issue 75367).
  • Tooltips from browser tabs are persisting for too long (Issue 75334 ).
  • Content settings updates don't reflect the current Incognito session(Issue 74466).
  • NewTabPage is not updating when a new theme is applied (Issue 74311).
  • fixed download requests in chrome frame which occur in response to top level POSTs (Issue 73985 ).
  • Chrome locks up on form submit, constantly duplicating autofill settings to blame(Issue 74911).

You can find out about getting on the Dev channel here: http://dev.chromium.org/getting-involved/dev-channel.



If you find new issues, please let us know by filing a bug at http://code.google.com/p/chromium/issues/entry

Karen Grunberg
Google Chrome
URL: http://googlechromereleases.blogspot.com/2011/03/dev-channel-update_15.html

[Gd] Stable and Beta Channel Updates

| More

Google Chrome Releases: Stable and Beta Channel Updates


The Chrome Stable and Beta channels have been updated to 10.0.648.134 for Windows, Mac, Linux and Chrome Frame. This release contains an updated version of the Adobe Flash player. If you find new issues, please let us know by filing a bug. Want to change to another Chrome release channel? Find out how.

Jason Kersey
Google Chrome
URL: http://googlechromereleases.blogspot.com/2011/03/stable-and-beta-channel-updates_15.html

[Gd] Deprecating Tables and Records feeds of the Spreadsheets API

| More

Google Apps Developer Blog: Deprecating Tables and Records feeds of the Spreadsheets API

At Google, we value quality, effective developer products. APIs are something we develop and release often. In support of this, we offer many APIs in our Labs program that allows our users to test APIs in an experimental setting.

After more than two years in service, we have made the decision to deprecate the Table and Record feeds of the Google Spreadsheets API. Having thoroughly tested these feeds and received lots of your feedback, we feel that the functionality provided by these feeds is something much better satisfied by the List and Cell feeds in the API.

Our deprecation plan for these APIs will keep these feeds in service for an additional year from today’s date.

If you are a current user of the Table and Record feeds, we highly recommend that you take the time to migrate over to the List and Cell feeds. Since the List feed works very similarly to the Records feed, this should be a smooth process.

As always, if you have any questions, feel free to use the Spreadsheets API forum.

Posted by Vic Fryzel, Google Spreadsheets API Team

Want to weigh in on this topic? Discuss on Buzz

URL: http://googleappsdeveloper.blogspot.com/2011/03/deprecating-tables-and-records-feeds-in.html

[Gd] Requiring SSL when using Google APIs

| More

Google Apps Developer Blog: Requiring SSL when using Google APIs

As part of an ongoing effort to increase the security around our users’ data, we’ve made some changes to the way requests must be made to some Google APIs. These changes will better protect user data from unauthorized parties. Starting September 9, 2011, this will affect the Google Documents List API, Spreadsheets API, and Sites API. For more information, please see this post on the Google Code blog.

Although we’re initially requiring SSL for only a few APIs, we strongly recommend that you convert all of your API clients as soon as possible to use SSL in order to help protect your users’ data.

Posted by Adam Feldman, Google Developer Team

Want to weigh in on this topic? Discuss on Buzz

URL: http://googleappsdeveloper.blogspot.com/2011/03/requiring-ssl-when-using-google-apis.html

Thursday, March 17, 2011

[Gd] Your Web, Half a Second Sooner

| More

The official Google Code blog: Your Web, Half a Second Sooner

At Google we’re constantly trying to make the web faster — not just our corner of it, but the whole thing. Over the past few days we’ve been rolling out a new and improved version of show_ads.js, the piece of JavaScript used by more than two million publishers to put AdSense advertisements on their web pages. The new show_ads is small and fast, built so that your browser can turn its attention back to its main task — working on the rest of the web page — as soon as possible. This change is now making billions of web pages every day load faster by half a second or more.

The old show_ads did lots of work: loading additional scripts, gathering information about the web page it was running on, and building the ad request to send back to Google. The new show_ads has a different job. It creates a friendly (same-origin) iframe on the web page, and starts the old script with a new name, show_ads_impl, running inside that iframe. The _impl does all the heavy lifting, and in the end the ads look exactly the same. But there’s a substantial speed advantage: many things happening inside an iframe don’t block the web browser’s other work.

How much of an effect this has depends on context: a page with nothing but ads on it isn’t going to get any faster. But on the real-world sites we tested, the latency overhead from our ads is basically gone. Page load times with the new asynchronous AdSense implementation are statistically indistinguishable from load times for the same pages with no ads at all.

The new show_ads is a drop-in replacement for the old one: web site owners don’t need to do anything to get this speed-up. But these dynamically-populated friendly iframes are finicky beasts. For now, we’re only using this technique on Chrome, Firefox, and Internet Explorer 8, with more to come once we’re sure that it plays well with other browsers.

And what if you’ve built a page that loads AdSense ads and then manipulates them in exotic ways not compatible with friendly iframes? (This is the web, after all, land of “What do you mean that’s ‘not supported’? I tried it, and it worked!”) You can set “google_enable_async = false” for any individual ad slot to revert to the old blocking behavior. But if your site loads ads in some tortuous way because you were looking for latency benefits, consider giving the straightforward invocation of show_ads.js a whirl. Because now, we’re fast.

By Michael Kleber, Ads Latency Team
URL: http://googlecode.blogspot.com/2011/03/your-web-half-second-sooner.html

[Gd] Application Stats on Android Market

| More

Android Developers Blog: Application Stats on Android Market

[This post is by Eric Chu, Android Developer Ecosystem. —Dirk Dougherty]

On the Android Market team, it’s been our goal to bring you improved ways of seeing and understanding the installation performance of your published applications. We know that this information is critical in helping you tune your development and marketing efforts. Today I’m pleased to let you know about an important new feature that we’ve added to Android Market called Application Statistics.

Application Statistics is a new type of dashboard in the Market Developer Console that gives you an overview of the installation performance of your apps. It provides charts and tables that summarize each app’s active installation trend over time, as well as its distribution across key dimensions such as Android platform versions, devices, user countries, and user languages. For additional context, the dashboard also shows the comparable aggregate distribution for all app installs from Android Market (numbering in the billions). You could use this data to observe how your app performs relative to the rest of Market or decide what to develop next.


To start with, we’ve seeded the application Statistics dashboards with data going back to December 22, 2010. Going forward, we’ll be updating the data daily.

We encourage you to check out these new dashboards and we hope they’ll give you new and useful insights into your apps’ installation performance. You can access the Statistics dashboards from the main Listings page in the Developer Console.

Watch for more announcements soon. We are continuing to work hard to deliver more reporting features to help you manage your products successfully on Android Market.

URL: http://android-developers.blogspot.com/2011/03/application-stats-on-android-market.html

Wednesday, March 16, 2011

[Gd] Best Practices for User Authentication

| More

The official Google Code blog: Best Practices for User Authentication

By now, many of you have seen our recent announcement regarding 2-step verification for Google Accounts. It’s an optional way of protecting your Google Account from unauthorized access, providing a level of security beyond that of a password alone. The initial announcement did not detail the impact enabling 2-step verification has on programmatic account access from code written against one of Google’s official APIs. We want to go into some more detail regarding the implications of 2-step verification on various authentication (and authorization) techniques, and offer best practices that you as a developer should follow.

There are three forms of authentication supported by almost all of Google’s APIs. AuthSub and OAuth (either version 1 or the newer OAuth 2) are similar web-based authentication mechanisms in which the user logs in on a web page hosted by Google. The other approach to authentication, ClientLogin, relies on your application soliciting the user’s account address and password, and then sending that information to Google.

If your code uses AuthSub or OAuth, then you don’t have to do anything special to accommodate users who have opted-in to 2-step verification. The web-based login flow currently allows users to enter both their normal passwords as well as the additional verification code, and this extra step is transparent to you as the developer.

ClientLogin, however, does not fare as well for accounts that have 2-step verification enabled. There is no concept of an additional verification code in the ClientLogin process, and a user’s account address and password are no longer sufficient for authenticating them once 2-step verification is turned on. If you make a ClientLogin authentication request for such an account, you’ll get back an HTTP 403 error response from our servers with the following in error included in the response body:

Error=BadAuthentication
Info=InvalidSecondFactor

There are two solutions to these failed ClientLogin attempts. The first solution, which does not require changing any existing code, is to ask your users to generate an application-specific password and to provide that, instead of their Google Account passwords, when making your ClientLogin request. You can point your users to this article for a full explanation of how application-specific passwords work.

The second, and recommended, solution requires some work on your part as a developer: moving away from ClientLogin completely, in favor of OAuth 2. If your code runs as part of a web application, then OAuth 2’s web-based login flow is trivial to integrate. Even applications that are installed on a user’s computer or other device can leverage OAuth 2, though. This guide explains how to launch a web browser to handle the login process, and then redirect control back to your application.

While it may take some effort to migrate your code away from ClientLogin, your users will be grateful that you did. Even those who haven’t enabled 2-step verification will benefit from entering their credentials on a web page accessed via HTTPS and hosted by Google, as opposed to sharing their password information directly with your third party code.

By Jeffrey Posnick, Google Developer Relations
URL: http://googlecode.blogspot.com/2011/03/best-practices-for-user-authentication.html

[Gd] Android 3.0 Hardware Acceleration

| More

Android Developers Blog: Android 3.0 Hardware Acceleration

[This post is by Romain Guy, who likes things on your screen to move fast. —Tim Bray]

One of the biggest changes we made to Android in this release is the addition of a new rendering pipeline so that applications can benefit from hardware accelerated 2D graphics. Hardware accelerated graphics is nothing new to the Android platform, it has always been used for windows composition or OpenGL games for instance, but with this new rendering pipeline applications can benefit from an extra boost in performance. On a Motorola Xoom device, all the standard applications like Browser and Calendar use hardware-accelerated 2D graphics.

In this article, I will show you how to enable the hardware accelerated 2D graphics pipeline in your application and give you a few tips on how to use it properly.

Go faster

To enable the hardware accelerated 2D graphics, open your AndroidManifest.xml file and add the following attribute to the <application /> tag:

    android:hardwareAccelerated="true"

If your application uses only standard widgets and drawables, this should be all you need to do. Once hardware acceleration is enabled, all drawing operations performed on a View's Canvas are performed using the GPU.

If you have custom drawing code you might need to do a bit more, which is in part why hardware acceleration is not enabled by default. And it's why you might want to read the rest of this article, to understand some of the important details of acceleration.

Controlling hardware acceleration

Because of the characteristics of the new rendering pipeline, you might run into issues with your application. Problems usually manifest themselves as invisible elements, exceptions or different-looking pixels. To help you, Android gives you 4 different ways to control hardware acceleration. You can enable or disable it on the following elements:

  • Application
  • Activity
  • Window
  • View

To enable or disable hardware acceleration at the application or activity level, use the XML attribute mentioned earlier. The following snippet enables hardware acceleration for the entire application but disables it for one activity:

    <application android:hardwareAccelerated="true">
<activity ... />
<activity android:hardwareAccelerated="false" />
</application>

If you need more fine-grained control, you can enable hardware acceleration for a given window at runtime:

    getWindow().setFlags(
WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED,
WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED);

Note that you currently cannot disable hardware acceleration at the window level. Finally, hardware acceleration can be disabled on individual views:

    view.setLayerType(View.LAYER_TYPE_SOFTWARE, null);

Layer types have many other usages that will be described later.

Am I hardware accelerated?

It is sometimes useful for an application, or more likely a custom view, to know whether it currently is hardware accelerated. This is particularly useful if your application does a lot of custom drawing and not all operations are properly supported by the new rendering pipeline.

There are two different ways to check whether the application is hardware accelerated:

If you must do this check in your drawing code, it is highly recommended to use Canvas.isHardwareAccelerated() instead of View.isHardwareAccelerated(). Indeed, even when a View is attached to a hardware accelerated window, it can be drawn using a non-hardware accelerated Canvas. This happens for instance when drawing a View into a bitmap for caching purpose.

What drawing operations are supported?

The current hardware accelerated 2D pipeline supports the most commonly used Canvas operations, and then some. We implemented all the operations needed to render the built-in applications, all the default widgets and layouts, and common advanced visual effects (reflections, tiled textures, etc.) There are however a few operations that are currently not supported, but might be in a future version of Android:

  • Canvas
    • clipPath
    • clipRegion
    • drawPicture
    • drawPoints
    • drawPosText
    • drawTextOnPath
    • drawVertices
  • Paint
    • setLinearText
    • setMaskFilter
    • setRasterizer

In addition, some operations behave differently when hardware acceleration enabled:

  • Canvas
    • clipRect: XOR, Difference and ReverseDifference clip modes are ignored; 3D transforms do not apply to the clip rectangle
    • drawBitmapMesh: colors array is ignored
    • drawLines: anti-aliasing is not supported
    • setDrawFilter: can be set, but ignored
  • Paint
    • setDither: ignored
    • setFilterBitmap: filtering is always on
    • setShadowLayer: works with text only
  • ComposeShader
    • A ComposeShader can only contain shaders of different types (a BitmapShader and a LinearGradientShader for instance, but not two instances of BitmapShader)
    • A ComposeShader cannot contain a ComposeShader

If drawing code in one of your views is affected by any of the missing features or limitations, you don't have to miss out on the advantages of hardware acceleration for your overall application. Instead, consider rendering the problematic view into a bitmap or setting its layer type to LAYER_TYPE_SOFTWARE. In both cases, you will switch back to the software rendering pipeline.

Dos and don'ts

Switching to hardware accelerated 2D graphics is a great way to get smoother animations and faster rendering in your application but it is by no means a magic bullet. Your application should be designed and implemented to be GPU friendly. It is easier than you might think if you follow these recommendations:

  • Reduce the number of Views in your application: the more Views the system has to draw, the slower it will be. This applies to the software pipeline as well; it is one of the easiest ways to optimize your UI.
  • Avoid overdraw: always make sure that you are not drawing too many layers on top of each other. In particular, make sure to remove any Views that are completely obscured by other opaque views on top of it. If you need to draw several layers blended on top of each other consider merging them into a single one. A good rule of thumb with current hardware is to not draw more than 2.5 times the number of pixels on screen per frame (and transparent pixels in a bitmap count!)
  • Don't create render objects in draw methods: a common mistake is to create a new Paint, or a new Path, every time a rendering method is invoked. This is not only wasteful, forcing the system to run the GC more often, it also bypasses caches and optimizations in the hardware pipeline.
  • Don't modify shapes too often: complex shapes, paths and circles for instance, are rendered using texture masks. Every time you create or modify a Path, the hardware pipeline must create a new mask, which can be expensive.
  • Don't modify bitmaps too often: every time you change the content of a bitmap, it needs to be uploaded again as a GPU texture the next time you draw it.
  • Use alpha with care: when a View is made translucent using View.setAlpha(), an AlphaAnimation or an ObjectAnimator animating the “alpha” property, it is rendered in an off-screen buffer which doubles the required fill-rate. When applying alpha on very large views, consider setting the View's layer type to LAYER_TYPE_HARDWARE.

View layers

Since Android 1.0, Views have had the ability to render into off-screen buffers, either by using a View's drawing cache, or by using Canvas.saveLayer(). Off-screen buffers, or layers, have several interesting usages. They can be used to get better performance when animating complex Views or to apply composition effects. For instance, fade effects are implemented by using Canvas.saveLayer() to temporarily render a View into a layer and then compositing it back on screen with an opacity factor.

Because layers are so useful, Android 3.0 gives you more control on how and when to use them. To to so, we have introduced a new API called View.setLayerType(int type, Paint p). This API takes two parameters: the type of layer you want to use and an optional Paint that describes how the layer should be composited. The paint parameter may be used to apply color filters, special blending modes or opacity to a layer. A View can use one of 3 layer types:

  • LAYER_TYPE_NONE: the View is rendered normally, and is not backed by an off-screen buffer.
  • LAYER_TYPE_HARDWARE: the View is rendered in hardware into a hardware texture if the application is hardware accelerated. If the application is not hardware accelerated, this layer type behaves the same as LAYER_TYPE_SOFTWARE.
  • LAYER_TYPE_SOFTWARE: the View is rendered in software into a bitmap

The type of layer you will use depends on your goal:

  • Performance: use a hardware layer type to render a View into a hardware texture. Once a View is rendered into a layer, its drawing code does not have to be executed until the View calls invalidate(). Some animations, for instance alpha animations, can then be applied directly onto the layer, which is very efficient for the GPU to do.
  • Visual effects: use a hardware or software layer type and a Paint to apply special visual treatments to a View. For instance, you can draw a View in black and white using a ColorMatrixColorFilter.
  • Compatibility: use a software layer type to force a View to be rendered in software. This is an easy way to work around limitations of the hardware rendering pipeline.

Layers and animations

Hardware-accelerated 2D graphics help deliver a faster and smoother user experience, especially when it comes to animations. Running an animation at 60 frames per second is not always possible when animating complex views that issue a lot of drawing operations. If you are running an animation in your application and do not obtain the smooth results you want, consider enabling hardware layers on your animated views.

When a View is backed by a hardware layer, some of its properties are handled by the way the layer is composited on screen. Setting these properties will be efficient because they do not require the view to be invalidated and redrawn. Here is the list of properties that will affect the way the layer is composited; calling the setter for any of these properties will result in optimal invalidation and no redraw of the targeted View:

  • alpha: to change the layer's opacity
  • x, y, translationX, translationY: to change the layer's position
  • scaleX, scaleY: to change the layer's size
  • rotation, rotationX, rotationY: to change the layer's orientation in 3D space
  • pivotX, pivotY: to change the layer's transformations origin

These properties are the names used when animating a View with an ObjectAnimator. If you want to set/get these properties, call the appropriate setter or getter. For instance, to modify the alpha property, call setAlpha(). The following code snippet shows the most efficient way to rotate a View in 3D around the Y axis:

    view.setLayerType(View.LAYER_TYPE_HARDWARE, null);
ObjectAnimator.ofFloat(view, "rotationY", 180).start();

Since hardware layers consume video memory, it is highly recommended you enable them only for the duration of the animation. This can be achieved with animation listeners:

    view.setLayerType(View.LAYER_TYPE_HARDWARE, null);
ObjectAnimator animator = ObjectAnimator.ofFloat(
view, "rotationY", 180);
animator.addListener(new AnimatorListenerAdapter() {
@Override
public void onAnimationEnd(Animator animation) {
view.setLayerType(View.LAYER_TYPE_NONE, null);
}
});
animator.start();

New drawing model

Along with hardware-accelerated 2D graphics, Android 3.0 introduces another major change in the UI toolkit’s drawing model: display lists, which are only enabled when hardware acceleration is turned on. To fully understand display lists and how they may affect your application it is important to also understand how Views are drawn.

Whenever an application needs to update a part of its UI, it invokes invalidate() (or one of its variants) on any View whose content has changed. The invalidation messages are propagated all the way up the view hierarchy to compute the dirty region; the region of the screen that needs to be redrawn. The system then draws any View in the hierarchy that intersects with the dirty region. The drawing model is therefore made of two stages:

  1. Invalidate the hierarchy
  2. Draw the hierarchy

There are unfortunately two drawbacks to this approach. First, this drawing model requires execution of a lot of code on every draw pass. Imagine for instance your application calls invalidate() on a button and that button sits on top of a more complex View like a MapView. When it comes time to draw, the drawing code of the MapView will be executed even though the MapView itself has not changed.

The second issue with that approach is that it can hide bugs in your application. Since views are redrawn anytime they intersect with the dirty region, a View whose content you changed might be redrawn even though invalidate() was not called on it. When this happens, you are relying on another View getting invalidated to obtain the proper behavior. Needless to say, this behavior can change every time you modify your application ever so slightly. Remember this rule: always call invalidate() on a View whenever you modify data or state that affects this View’s drawing code. This applies only to custom code since setting standard properties, like the background color or the text in a TextView, will cause invalidate() to be called properly internally.

Android 3.0 still relies on invalidate() to request screen updates and draw() to render views. The difference is in how the drawing code is handled internally. Rather than executing the drawing commands immediately, the UI toolkit now records them inside display lists. This means that display lists do not contain any logic, but rather the output of the view hierarchy’s drawing code. Another interesting optimization is that the system only needs to record/update display lists for views marked dirty by an invalidate() call; views that have not been invalidated can be redrawn simply by re-issuing the previously recorded display list. The new drawing model now contains 3 stages:

  1. Invalidate the hierarchy
  2. Record/update display lists
  3. Draw the display lists

With this model, you cannot rely on a View intersecting the dirty region to have its draw() method executed anymore: to ensure that a View’s display list will be recorded, you must call invalidate(). This kind of bug becomes very obvious with hardware acceleration turned on and is easy to fix: you would see the previous content of a View after changing it.

Using display lists also benefits animation performance. In the previous section, we saw that setting specific properties (alpha, rotation, etc.) does not require invalidating the targeted View. This optimization also applies to views with display lists (any View when your application is hardware accelerated.) Let’s imagine you want to change the opacity of a ListView embedded inside a LinearLayout, above a Button. Here is what the (simplified) display list of the LinearLayout looks like before changing the list’s opacity:

    DrawDisplayList(ListView)
DrawDisplayList(Button)

After invoking listView.setAlpha(0.5f) the display list now contains this:

    SaveLayerAlpha(0.5)
DrawDisplayList(ListView)
Restore
DrawDisplayList(Button)

The complex drawing code of ListView was not executed. Instead the system only updated the display list of the much simpler LinearLayout. In previous versions of Android, or in an application without hardware acceleration enabled, the drawing code of both the list and its parent would have to be executed again.

It’s your turn

Enabling hardware accelerated 2D graphics in your application is easy, particularly if you rely solely on standard views and drawables. Just keep in mind the few limitations and potential issues described in this document and make sure to thoroughly test your application!

URL: http://android-developers.blogspot.com/2011/03/android-30-hardware-acceleration.html

[Gd] Last Call for Google I/O

| More

Google Web Toolkit Blog: Last Call for Google I/O

For those of you who were quick to register, we thank you for continuing to support our developer initiatives -- this year's I/O is slated to be one of our best yet. For the rest of our developers, we weren’t kidding when we told you we <3 our developers.


Starting Wednesday, March 16, we will be launching Last Call for Google I/O: A contest that spans 10 days, 10 developer challenges and 100 chances to win tickets to attend the now-sold-out Google I/O 2011.


To participate, see the official Last Call for Google I/O blog post.


The GWT / Developer Tools contest opens Wed Mar 25 at 9am PST.

URL: http://googlewebtoolkit.blogspot.com/2011/03/last-call-for-google-io.html

[Gd] Improving the security of Google APIs with SSL

| More

The official Google Code blog: Improving the security of Google APIs with SSL

We at Google go to great lengths to ensure every step is taken to protect our users’ data. As part of our ongoing effort to improve security everywhere, we will start requiring the use of SSL in many products. Requiring SSL improves security by encrypting data communications between users and Google, better protecting it from being intercepted by a malicious third party.

Some of these changes have already occurred. Many user-facing Google products now allow or require SSL, including encrypting Google web search, defaulting to SSL in Gmail, and requiring SSL in Google Docs. Next on our list is to improve SSL support for our developer facing APIs. For most APIs, our technical documentation, client libraries and code samples already use SSL. Many new APIs and versions will be SSL only. Further, the Google Maps API, which previously offered SSL only to Premier customers, is offering SSL to all developers starting today.

Additionally, beginning September 15, 2011, Google will require that all users of Google Documents List API, Google Spreadsheets API, and Google Sites API use SSL connections for all API requests. Specifically, this change will disallow all HTTP requests, responding with an HTTP 400 Bad Request response. API requests will only be accepted via HTTPS. For example, a request to http://docs.google.com/feeds/default/private/full will no longer pull a list of a user's documents. Instead, a request must be made to https://docs.google.com/feeds/default/private/full.

This change should be transparent if you're using the most recent version of the Google Data client libraries, since they already use SSL for all requests. If you're not using the latest version, then please upgrade as soon as possible. If you're not using our client libraries, then simply change any use of an HTTP URL to its corresponding HTTPS version in your code. Your existing OAuth and AuthSub tokens will continue to work using the HTTPS URLs, even if they were requested with a scope that uses an ‘http://’ scheme.

Although we’re initially requiring SSL for only a few APIs (those whose traffic was already mostly over SSL), we strongly recommend that you convert all your API clients as soon as possible to help protect your users’ data. Check the documentation for each API for more information about that API's SSL support, including the updated Google Documents List API documentation, Google Spreadsheets API documentation, and Google Sites API documentation.

If you have any questions or concerns about this change, please follow up in the forums of the API you are using.

By Adam Feldman, Google Developer Team
URL: http://googlecode.blogspot.com/2011/03/improving-security-of-google-apis-with.html

Tuesday, March 15, 2011

[Gd] Last Call for Google I/O kicks off tomorrow at 9:00 A.M. PDT

| More

The official Google Code blog: Last Call for Google I/O kicks off tomorrow at 9:00 A.M. PDT

As Vic announced last week, we will be kicking off our Last Call for Google I/O contest tomorrow. We will be starting promptly at 9:00 A.M. PDT on March 16th with our Android challenge. As a reminder, here’s the contest schedule again:

March 16 - Android, 9:00 am
March 17 - Chrome, 9:00 am
March 18 - App Engine, 9:00 am
March 21 - YouTube APIs, 9:00 am
March 22 - Game Developers, 9:00 am
March 23 - Google Maps / Geo, 4:00 pm
March 24 - Commerce, 9:00 am
March 25 - Developer Tools / GWT, 9:00 am
March 28 - Accessibility, 4:00 pm
March 29 - Google Apps / Enterprise, 4:00 pm

All times are listed in PDT

When you visit the site tomorrow morning, you will see a tab in the navigation that reads “Android”--that’s where you will find all of the questions and submission forms for Round I. We’re excited to see what everyone comes up with!

By Monica Tran, Google I/O Team
URL: http://googlecode.blogspot.com/2011/03/last-call-for-google-io-kicks-off.html

[Gd] Making auth easier: OAuth 2.0 for Google APIs

| More

The official Google Code blog: Making auth easier: OAuth 2.0 for Google APIs

One of the most exciting things about the architecture of the web is how easily it supports mashups—URLs, IFRAMEs, XHR, and more make it easy to build great new services on top of building blocks from others. As more and more people use the web for non-public data, we need new techniques to secure those building blocks. That’s where OAuth comes in—an open, standard way for users to grant permission for an application to access part of their account.

Since we announced support for OAuth in 2008, we've seen tremendous usage growth in our APIs that require user authorization, like Calendar and Docs. While the spec isn't completely finalized, Google is pleased to announce our experimental support of an easier way for developers to obtain user authorization for our APIs: OAuth 2.0 with bearer tokens. Whether you use our updated client libraries or just write to the protocol, you should be able to do more with less code.

In addition to supporting a simplified protocol, we're also introducing a simpler, cleaner consent page for OAuth 2.0:


Google believes in open systems that give users value, transparency and control. We hope the OAuth 2.0 protocol helps developers deliver just that: powerful applications that make use of user data without compromising on safety or security. Check out our documentation to get started with OAuth 2.0.

By Andrew Wansley, Google Developer Team
URL: http://googlecode.blogspot.com/2011/03/making-auth-easier-oauth-20-for-google.html

Monday, March 14, 2011

[Gd] Using UX Research to make Google Web Fonts even better!

| More

Google Web Fonts: Using UX Research to make Google Web Fonts even better!

Late in 2010, our team spent hours learning more about our users through surveys and traditional usability methods. In our survey, users spoke up loud and clear - “We want more fonts!” We are working hard to add new fonts with 35 font families added since December. What did users like best about the Google Font Directory? It is easy to use, available, dependable, and it has decent font choices and features... all at a great price - free!


What new features would you like to see added to the Google Font Directory?
More fonts! (More in general, international fonts, basic fonts, more weights/variants, & specific fonts)



What, if anything, do you like best about the Google Font Directory?

During our usability sessions, we were able to see many types of users interact with our web fonts. We identified major user groups and documented their typical workflow. The research we conducted took us to the brainstorming table. Our whole team spent an entire day brainstorming goals and priorities based on user research. The brainstorming day was followed by a design sprint in our Seattle office. Four talented Google designers and other team members spent five full days working through hundreds of mocks and design concepts. Stay tuned for the results of this effort!

So what’s next? More user testing, of course! Our engineers and user experience team have been busy working on ideas from the design sprint, and we are ready to get some feedback. If you would like to help us, sign up here! (QR code provided below.)


Brainstorming involved lots of discussions & lots of stickies!



Hard at work in the design sprint.

Sign up to help us make Google Web Fonts even better!
http://goo.gl/1hmDN

posted by Dawn Shaikh, Senior User Experience Researcher, Google Web Fonts

URL: http://googlewebfonts.blogspot.com/2011/03/using-ux-research-to-make-google-web.html

[Gd] Using UX Research to make Google Web Fonts even better!

| More

Google Web Fonts: Using UX Research to make Google Web Fonts even better!

Late in 2010, our team spent hours learning more about our users through surveys and traditional usability methods. In our survey, users spoke up loud and clear - “We want more fonts!” We are working hard to add new fonts with 35 font families added since December. What did users like best about the Google Font Directory? It is easy to use, available, dependable, and it has decent font choices and features... all at a great price - free!


What new features would you like to see added to the Google Font Directory?
More fonts! (More in general, international fonts, basic fonts, more weights/variants, & specific fonts)



What, if anything, do you like best about the Google Font Directory?

During our usability sessions, we were able to see many types of users interact with our web fonts. We identified major user groups and documented their typical workflow. The research we conducted took us to the brainstorming table. Our whole team spent an entire day brainstorming goals and priorities based on user research. The brainstorming day was followed by a design sprint in our Seattle office. Four talented Google designers and other team members spent five full days working through hundreds of mocks and design concepts. Stay tuned for the results of this effort!

So what’s next? More user testing, of course! Our engineers and user experience team have been busy working on ideas from the design sprint, and we are ready to get some feedback. If you would like to help us, sign up here! (QR code provided below.)


Brainstorming involved lots of discussions & lots of stickies!



Hard at work in the design sprint.

Sign up to help us make Google Web Fonts even better!
http://goo.gl/1hmDN

posted by Dawn Shaikh, Senior User Experience Researcher, Google Web Fonts

URL: http://googlewebfonts.blogspot.com/2011/03/using-ux-research-to-make-google-web.html

[Gd] Late in 2010, our team spent hours learning more about our

| More

Google Web Fonts: Late in 2010, our team spent hours learning more about our

Late in 2010, our team spent hours learning more about our users through surveys and traditional usability methods. In our survey, users spoke up loud and clear - “We want more fonts!” We are working hard to add new fonts with 35 font families added since December. What did users like best about the Google Font Directory? It is easy to use, available, dependable, and it has decent font choices and features... all at a great price - free!


What new features would you like to see added to the Google Font Directory?
More fonts! (More in general, international fonts, basic fonts, more weights/variants, & specific fonts)


What, if anything, do you like best about the Google Font Directory?

During our usability sessions, we were able to see many types of users interact with our web fonts. We identified major user groups and documented their typical workflow. The research we conducted took us to the brainstorming table. Our whole team spent an entire day brainstorming goals and priorities based on user research. The brainstorming day was followed by a design sprint in our Seattle office. Four talented Google designers and other team members spent five full days working through hundreds of mocks and design concepts. Stay tuned for the results of this effort!

So what’s next? More user testing, of course! Our engineers and user experience team have been busy working on ideas from the design sprint, and we are ready to get some feedback. If you would like to help us, sign up here! (QR code provided below)

Brainstorming involved lots of discussions & lots of stickies!


Hard at work in the design sprint.

Sign up to help us make Google Web Fonts even better!
http://goo.gl/1hmDN
posted by Dawn Shaikh, Senior User Experience Researcher, Google Web Fonts
URL: http://googlewebfonts.blogspot.com/2011/03/late-in-2010-our-team-spent-hours.html

Sunday, March 13, 2011

[Gd] Reminder about company info

| More

AdWords API Blog: Reminder about company info

We would like to share a friendly reminder for all AdWords API developers to keep company information up to date in your AdWords API Center. It should take less than a minute to update and allows us to deliver better support as well as provide you with critical product updates in a timely manner.

The company information, such as contact email, can be modified in the “AdWords API Center” tab of your My Client Center (MCC) account. Navigate to the “Company Information” section of the page and follow the “Edit” link to make changes.

As always, please post any questions and feedback to the AdWords API Forum.

--Stan Grinberg, AdWords API Team
URL: http://adwordsapi.blogspot.com/2011/03/reminder-about-company-info.html

[Gd] Stopping the Gears

| More

Gears API Blog: Stopping the Gears

Last February, we let you know we were shifting our focus from Gears to HTML5. Over the last year or so, we’ve been working closely with other browser vendors and standards bodies to help define and standardize HTML5 features across browsers, and we’ve worked hard to improve these HTML5 capabilities in Chrome:


  • We implemented support for application caches, which are a great replacement for Gears’ offline features. App caches are already being used by web apps like the NYTimes app in the Chrome Web Store. There is also full-featured debugging support for application caches in Chrome’s developer tools.

  • Together with our friends at Mozilla and Microsoft, we proposed, specified, and implemented the IndexedDB API. This can take the place of the Gears Database API.

  • We implemented the HTML5 File API, which is very similar to the Gears Blob functionality.

  • We implemented the geolocation, notifications, and web worker APIs, which were pioneered by Gears, natively in Chrome.

With all this now available in HTML5, it’s finally time to say goodbye to Gears. There will be no new Gears releases, and newer browsers such as Firefox 4 and Internet Explorer 9 will not be supported. We will also be removing Gears from Chrome in Chrome 12.

The code itself will of course remain open source, and anyone is free to use it.

Our mission with Gears was to enable more powerful web applications. Over 5 releases, we added tons of APIs, enabling everything from offline access to parallel computation. Now that these features have all been adopted by browsers and have official W3C specs, they are available to more developers than we could have reached with Gears alone.

Edit: Corrected timeframe for removing Gears from Chrome.

Posted by Aaron Boodman, Gears Team

URL: http://gearsblog.blogspot.com/2011/03/stopping-gears.html

[Gd] Google Site Search on the Royal Wedding Website

| More

Google Custom Search: Google Site Search on the Royal Wedding Website

Cross posted on the Google Enterprise Blog
 
St. James’s Palace just launched www.officialroyalwedding2011.org, a website celebrating the forthcoming marriage of Prince William and Miss Catherine Middleton. The website is the official information hub for anyone interested in the Royal Wedding, and if you browse the website you might notice something familiar: instant, crisp, and relevant search results powered by Google.




Whether you’re looking for more information about the reception, or are simply curious about who Miss Middleton appointed as her Maid of Honour, Google Site Search will quickly direct you to the most relevant results.

We’re thrilled to be assisting St. James’s Palace with their website search engine. Our congratulations to the happy couple!


Posted by: Rajat Mukherjee, Group Product Manager
URL: http://googlecustomsearch.blogspot.com/2011/03/google-site-search-on-royal-wedding.html