Google's New Currency Converter

Google updated the OneBox for currency conversion. Until recently, when you searched for [1 usd in eur] or [200 gbp to peso], Google displayed the result and that was it. The new OneBox includes a graph for historical exchange rates and an interactive tool that lets you select a different currency from a long list or change the value you want to covert and instantly get the result.




A similar tool is available at Google Finance, but it's more convenient to access it from Google Search and you don't need to search for USDEUR to convert US dollars to euros. For some reason, when you search for [currency converter] from the US, Google tries to be helpful and shows that 1 US dollar = 0.6957 euros.

{ Thanks, Aahan. }

Things That Cannot Change

[This post is by Dianne Hackborn, whose fingerprints can be found all over the Android Application Framework — Tim Bray]

Sometimes a developer will make a change to an application that has surprising results when installed as an update to a previous version — shortcuts break, widgets disappear, or it can’t even be installed at all. There are certain parts of an application that are immutable once you publish it, and you can avoid surprises by understanding them.

Your package name and certificate

The most obvious and visible of these is the “manifest package name,” the unique name you give to your application in its AndroidManifest.xml. The name uses a Java-language-style naming convention, with Internet domain ownership helping to avoid name collisions. For example, since Google owns the domain “google.com”, the manifest package names of all of our applications should start with “com.google.” It’s important for developers to follow this convention in order to avoid conflicts with other developers.

Once you publish your application under its manifest package name, this is the unique identity of the application forever more. Switching to a different name results in an entirely new application, one that can’t be installed as an update to the existing application.

Just as important as the manifest package name is the certificate that application is signed with. The signing certificate represents the author of the application. If you change the certificate an application is signed with, it is now a different application because it comes from a different author. This different application can’t be uploaded to Market as an update to the original application, nor can it be installed onto a device as an update.

The exact behavior the user sees when installing an application that has changed in one of these two ways is different:

• If the manifest package name has changed, the new application will be installed alongside the old application, so they both co-exist on the user’s device at the same time.

• If the signing certificate changes, trying to install the new application on to the device will fail until the old version is uninstalled.

If you change the signing certificate of your application, you should always change its manifest package name as well to avoid failures when it’s installed. In other words, the application coming from a different author makes it a different application, and its package name should be changed appropriately to reflect that. (Of course it’s fine to use the same package name for the development builds of your app signed with your test keys, because these are not published.)

Your AndroidManifest.xml is a public API

More than just your package name that is immutable. A major function of the AndroidManifest.xml is essentially to declare a public API from your application for use by other applications and the Android system. Every component you declare in the manifest that is not private (that is whose android:exported state is true) should be treated as a public API and never changed in a way that breaks compatibility.

A subtle but important aspect of what constitutes a break in compatibility is the android:name attribute of your activity, service, and receiver components. This can be surprising because we think of android:name as pointing to the private code implementing our application, but it is also (in combination with the manifest package name) the official unique public name for that component, as represented by the ComponentName class.

Changing the component name inside of an application can have negative consequences for your users. Some examples are:

• If the name of a main activity of your application is changed, any shortcuts the user made to it will no longer work. A shortcut is an Intent that directly specifies the ComponentName it should run.

• If the name of a service implementing a Live Wallpaper changes, then a user who has enabled your Live Wallpaper will have their wallpaper revert to the system default when getting the new version of your app. The same is true for Input Methods, Accessibility Services, Honeycomb’s new advanced Widgets, and so on.

• If the name of a receiver implementing a Device Admin changes, then as with the live wallpaper example, the device admin will be disabled when the application is updated. This also applies to other kinds of receivers, such as App Widgets.

These behaviors are an outcome of how the Intent system is used on Android. There are two main kinds of Intents:

• Implicit Intents only specify “what” they should match, using actions, categories, data, MIME types, and so on. The exact components that they will find are only determined at run-time, by the Package Manager matching it against the current applications.

• Explicit Intents specify a single explicit “who” they should match, through a ComponentName. Regardless of whatever else is in the Intent, it is only associated with the exact manifest package name and class name as given in its ComponentName.

Both of these types of Intents are important to how Android interacts with your application. A typical example of this is how users browse and select live wallpapers.

To let the user pick a live wallpaper, the first thing Android must do is show them a list of the available live wallpaper services. It does this by building an implicit Intent with the appropriate action for a live wallpaper and asking the Package Manager for all services that support this Intent. The result is then the list of live wallpapers shown to the user.

When the user actually selects a specific live wallpaper they want to use, however, Android now must build an explicit Intent that identifies that particular live wallpaper. This is what is handed to the WallpaperManager to tell it which wallpaper to show.

This is why changing the name of the component in your manifest will cause the wallpaper to disappear: the explicit Intent that was previously saved is now invalid because the ComponentName it references no longer exists. There is no information available to indicate what the new name of the component is. (For example consider if your application had two different live wallpaper services the user could select.) Instead, Android must treat that live wallpaper as uninstalled and revert to its default wallpaper.

This is how input methods, device administrators, account managers, app widgets, and even application shortcuts work. The ComponentName is the public unique name of the components you declare in your manifest, and must not change if they are visible to other applications.

In conclusion: There are some parts of your application that can not change. Please be careful.

Google's Gay Rainbow

It's not the first June when Google changes the search results interface when you search for [gay] and other related terms. While in 2009 and 2010 Google added a colorful bar below the search box, this year there's a rainbow next to the search box.


June is the "Gay and Lesbian Pride Month" and there are many pride parades all over the world. Last year, Google's blog included an article about gay parades and the Google employees who participated.

"Google supports its LGBT employees in many ways: raising its voice in matters of policy, taking a moment to remember the plight of transgender people around the world and going the extra mile to ensure that its employees are treated fairly."

{ Thanks, multilind. }

Google Docs Tests Offline Support, Powered by HTML5

Google Docs team promised to bring back offline support this summer, but some traces of the new offline interface are already available. "I logged into Docs today and saw this! It's not yet functional, but an exciting sign! The code is being pushed," says Owen, a reader of this blog.


Angelo "saw a black bar flash up on screen quickly when loading the DocList of [his] Google Apps account". After a few refreshes, he managed to see the bar that lets you switch to the offline mode. Unfortunately, Google Docs doesn't work offline, at least not yet.

In a recent Reddit thread, a member of the Google Docs team said that "you're going to see offline start to roll out later this summer. We used to have offline with Google Gears, but it became pretty clear that plugins weren't the right approach. We've been reimplementing offline using HTML5 standards like AppCache, File API, and IndexDB We're some of the first webapps that are really putting those standards to the test, so it's taken a while to iron out the kinks."

{ Thanks, Owen and Angelo. }

Google Could Add Face Recognition to Google Profiles

Florian Rohrweck found a lot of interesting things analyzing Google's code. For example, Google Profiles will add an option that will allow Google to recognize your face in other people's photos. Picasa Web's name tags can become global: a new section from your profile titled "photos of you" will list the photos from other people where you are tagged. Google provides an approval mechanism, so you can reject some of the photos. "When a tag is approved, it is linked to your profile, and the photo is added to the 'Photos of you' section."


Google Profiles will include a new tab for videos, a photo editing feature, you'll be able to group your friends in "circles", chat from Google Profiles and add gadgets. There's also a "camera sync" feature that could automatically upload the photos from the "camera" album of a mobile phone or tablet.


As expected, Google Profiles is the place where Google's social efforts are most visible. Buzz will be a back-end service for activity streams and not a standalone service. Google Profiles could eventually replace iGoogle, since it will add support for gadgets and it will include the most interesting items shared by the people you're following.

{ Thanks, Florian. }

Chromification of the Operating System

Three years ago, when Google launched Chrome many people wondered if it will be successful. Chrome became a very popular browser, with more than 160 million active users, but its most important achievement was accelerating the development of all the other browsers and shifting their priorities from adding UI features to removing clutter, making them faster and better suited for running Web apps. Internet Explorer embraced HTML5, Firefox started to update more often, Opera simplified its interface. Google started from the scratch and created a browser for today's Web apps.


For some, Chrome OS may seem pointless. Why buy a notebook that can only run a single program, when you can install Chrome on your existing computer? But why switch from Firefox to a browser that doesn't support advanced extensions? After all, Firefox is a lot more customizable than Chrome since any extension can dramatically alter the interface and integrate with the browser. It turns out that Firefox extensions can sometimes slow down the browser, some use a lot of resources, they're difficult to update and every new major release can break them. Chrome's extensions are less powerful, but they don't slow down the browser, they're easier to develop and to maintain and major new releases rarely break them.

Just like Chrome influenced all the other important browsers, Chrome OS will change the other operating systems. Sandboxing applications can make the operating system a lot more secure, saving your settings and files online allows you to use them from any other computer, Web applications are powerful enough to replace some of the native apps and they don't live on your computer, so they can be constantly updated. Even Windows intends to switch to "Web-powered apps built using HTML5 and JavaScript that have access to the full power of the PC" in the next major release, while still supporting "legacy" apps. It's obvious that most of the apps will eventually migrate to the Web and Chrome OS is better suited to support them because it doesn't have to worry about legacy apps and because it's designed just like a Google Web app: constantly updated, fast, clutter-free. "The future is already here – it's just not evenly distributed," said William Gibson. Chrome OS is ready... when you are.

{ image from the Chrome Comic Book, licensed by Google as Creative Commons }

Google Tests a New Interface

Another day, another Google experiment. This time, Google tests a new search button inspired by Bing and removes the "I'm Feeling Lucky" button from the homepage, probably because it's no longer useful. Google Instant makes the search button unnecessary most of the time, so Google could remove it altogether. It's interesting that the new design emphasizes the search button instead of making it less prominent.


Google's experiment highlights the header of the search results pages and uses gray/red icons and labels in the vertical navigation menu. Another change is that the "cached" and "similar" links are placed in the Instant Preview box, so they're more difficult to find.



All the icons and images for this experiment are available in a sprite.

{ Thanks, Juuso, François and Websonic. }