Google Announces Plans To Bake Android-Like Web Intents Into Chrome | Hacker News Reader

Google Announces Plans To Bake Android-Like Web Intents Into Chrome

techcrunch.com

108 pointsjoelhaus45 comments

This is an incredibly cool idea that essentially brings back the concept of a decentralized web. Right now, we have somehow embraced a monolithic web culture were interop goes only in one direction - towards Facebook mainly, closely followed by Google's conglomerate.

Web Intents will level the playing field again, and they make those horrible embedded Facebook/Google+/whatever social networking buttons obsolete by replacing them with something way more powerful.

For a concrete example of the power of Web Intents, consider this: On Android, a browser (whether the stock or an alternative like Dolphin or Firefox) could (and probably will given the architecture / history) offer some local Android Intent handlers as handlers for some Web Intents.

To take the example from the blog post, at the photo storage website you could choose to edit an image and get menu of choices that doesn't just include web app image editors, but also includes native image editors installed on your device. That sounds pretty amazing to me.

Official announcement: http://blog.chromium.org/2011/08/connecting-web-apps-with-we...

Project web page: http://webintents.org/

I think custom URL schemes like: mailto:, tel:, sms:, twitter: are kinda like lightweight intents.

http://developer.apple.com/library/ios/#featuredarticles/iPh...

On the raising side, you're absolutely right. A custom URL scheme generally captures what you want to do (i.e. the intent) not how.

On the handling side, however, on iOS there are limitations that I think make them qualitatively different:

- only one application can handle any given URL scheme

- no mechanism (other than Apple apps win) for choosing between apps that want to handle a URL scheme

- no notion of optionally handling a URL scheme based on its contents (which enables very useful filter-like behavior)

- no notion of "returning" to whatever raised the request (there are schemes to hack around this, but they are limited and brittle)

- built-in support for carrying general payloads (rather than having to encode them in a URL)

There is overlap. I hope HTML5 will dump registerProtocolHandler() and extend Intents API to use scheme in addition to MIME type.

Aren't we all supposed to scream "non standard!!" like we did when IE added behaviors?

I am screaming very loudly.

The fact that Mozilla are working on it alongside Google should quieten the screams, and they do also have a javascript library for IE, Safari, Chrome and FF3.

Back then there was a reasonable fear that behaviours was typical Microsoft 'embrace and extend' move that I don't think is present in this case.

The fact that they are already working with Mozilla is a good sign and it wouldn't be in Google's strategic interests to make this proprietary.

No. Browser makers should actually innovate more. The problem with "non standard" comes only from the instances where IE does standard behavior in a completely idiosyncratic way or not at all. There are tons of interesting things that are not part of any W3C specs. Of course browser developers should be creative. But they should not, as the IE team does again and again, make a lot of proprietary extensions _instead_ of implementing the standard specs that cover the same functionality.

Like when IE added XHR?

http://en.wikipedia.org/wiki/XHR#History_and_support

If you were smart when IE started adding features, you would analyze the feature in question before throwing your hands up and shouting about MS. For instance, XMLHttpRequest was a fricking cool innovation.

MS's problem traditionally has been that it doesn't open the spec for these sorts of things until much later, if at all. This is a tendency Google does not really share when it adds features to Chrome. For instance, before Google officially started working on Web Intents, an employee of theirs and one from Mozilla came up with different ideas for how intents should be handled. They agreed on a preliminary spec and now that spec is open for anyone to implement.

That's exactly it. If we complained about every new feature we'd still be using static pages with blink tags. Google and Firefox are teaming up to implement this features. Look at how Google went about WebGL. They had a competing plugin called O3D but when they saw O3D was working out they dropped it completely and even ported the O3D api to WebGL (which I use now since then). Microsoft of old would just have kept going (hence DirectX instead of continuing to support OpenGL).

Yes, I am also concerned. I hope they go forward with Microsoft and Opera on board.

Another important difference thus far unmentioned is that IE is a browser for a single platform, and Microsoft traditionally has not done a good job in creating IE features in a cross-platform way. (I'm thinking of ActiveX specifically here.)

If a feature is led by Chrome, Firefox, or Opera you know that any native platform hooks have been designed thoughtfully to work nicely across at least the 3 major desktop platforms.

How well have intents actually worked out in practice on Android? It's been awhile since I spent much time with an Android device but a year or so ago it was very rare that I really wanted a generic utility.

It's convient for lots of things, e.g. if you install a new twitter client suddenly when you take a photograph and want to share it, that app can now show up as a way to share that photo.

It is also convenient for the Google+ client, where you could share with it just like a Twitter or Facebook client on day 1.

Sadly, the Google+ client doesn't share out yet, but hopefully that's coming.

They're all over the place for core functions - whenever you click a "Share" button it will ask which applications can handle the content you want to share and add them to the menu. I've also been prompted to choose whether I want to make phone calls using the built in dialer or Skype, which I presume is using intents as well.

Where I've not see so much use is providing completely new intents, presumably because its so hard to get any sort of agreement on how they should be implemented.

To add another example, alternate launchers hook at least one intent (the one triggered when you press the home button) and possibly more.

Facebook Single Sign-On on Android is implemented via an Intent, though Facebook is obviously a player that developers will follow

Whilst that might be cool technology, I wonder at the user experience and confusion when my mum clicks on the phone icon and all of a sudden this menu appears asking me whether I want to use the phone or skype (obviously I get that the call can be done with either, but mum probably doesn't).

If your mother doesn't have skype installed she wouldn't get this message. If she does, I would presume she knows what skype is for.

Additionally for the big system-level intents there is an "always use this action" which is useful so you don't have to repeatedly tell it to use the phone app to place phone calls.

The iPhone experience is that the system Contacts app is only for calling via the phone system. If you want to call via Skype, you open Skype and then use its embedding of the system address book. It is really quite clunky.

BlackBerry has this also. I can share anything with any app that I have installed (and that can support sharing of some sort). I don't know how this is implemented or if it is even the same principal as this behind the scenes...

'intent' worked well for me. With intents, it took only few lines of code to scan and de-crypt a QR image (thanks to zxing). Without intent, it would have taken weeks to implement such feature.

What happens if the app that provides that intent isn't installed on the user's phone? Are they prompted to install it?

No. The idea behind intents is that the calling app doesn't know (or care) who handles the action. You just fire off a message that says "Hey, someone handle this", and the OS takes care of the rest. You would need to prompt the user to install an app to handle the intent if they don't have one already.

IMO it works really well and is one of the things which sets Android apart from iOS and other OSes in general.

One of the finer points which I really appreciate is how intents can be fine-tuned not only to handle "a image" or "a mp3" or act like a extension/protocol-handler in your desktop OS, but how it can react on parts of a intent, like the domain of a URL.

When someone links to Applications on Android market on a web-page (i.e., a https-link to market.android.com) and I click it on my Android device, I actually get the link "opened" by having Android market app launched and focused on that specific application. Very, very neat.

The same thing can be done for wikipedia readers. A wikipedia link launches your app. In the same way other apps can provide intents for music selection, playback, data-sources, data-consumers and god knows what. Or just have an app become the default for some action on your system by handling the generic intent (i.e. surf the web).

Intents are one of the really good things which makes Android Android. And in case there were any doubts: I think it works out bloody fantastic.

You've highlighted a subtle but important point of the Intent design. Unlike traditional file-handlers, you can say "I might handle this kind of thing" and then watch what flies by and only respond to what you actually care about (e.g. the market only responding to URLs pointing to the Android market). That makes Intents more powerful and more precise than previous approaches to similar problems.

Is there any security hole in this? Can an app register an intent on http and get access to all URLs Browser loads?

Actually, they can. Android browsers register to handle such requests. That's how users can switch between default browsers. Additionally, that's how the YouTube app can register to watch YouTube links. I click on a post on reddit, it links to a youtube video and it pops up and asks if I want to open it with the browser, (Dolphin, xScope) or YouTube.

I want Google Chrome in Android, not the other way around.

Why not both?

Btw Chrome is already on Android. Well, for Google TV at least. It's great that there's this cross-pollination of ideas. Makes for better software.

If Chrome was a proper part of Android; it'd lose one of it's primary strengths, namely seamless automatic updating. Android's constrained by the certification process of carriers, and thus can't move nearly as fast as Chrome can on it's own. Seems like a small thing, but attaching the Chrome name to a browser that can't quite match the real thing would drag down desktop Chrome's reputation.

A more cynical attitude could be that Chrome intends to be it's own platform (see Chrome OS), and the Android team doesn't want to wake up one day and end up as nothing more than the gory bits between Chrome and the hardware (as Windows already is is for some people).

Autoupdating is not possible on any mobile OS I'm aware of, for security reasons. What should happen is Google (and Apple and Microsoft, etc.) need to implement autoupdating at the OS level. With user permission, of course.

And I mean true, silent autoupdating. When a developer publishes a new version of the app it should download the package, then apply the update the next time that application is closed.

As for your cynical observation, I doubt there is any conspiratorial reason for this. I think it has more to do with Android operating more or less like an independent startup inside Google. I think the Android browser would be much better if the Chrome team was behind it.

Android apps have an "allow automatic update" checkbox. If the box is checked, and the new version of the application has the same permissions as the old one, the application auto-updates.

Explain further. I have an Android phone and I don't believe this to be the case (I see updates in the app all the time).

Silent auto-update = No user interaction necessary at all. No notification.

There is notification (and AFAICT, no way to turn it off in the Froyo version on the original Moto Droid), but otherwise, jellicle is correct. Just check the box on the Android Market App page to allow autoupdating.

Would be interested to learn what the "security reasons" are that you referenced above; did you mean the underlying OS? I've always felt that by Appifying more of the core Android OS functions, Google could deliver more timely updates because they would be able to avoid many of the carrier restrictions and awful modifications made by manufacturers (e.g. just include the keyboard as an app that gets shipped with the core OS).

[UPDATE:] Can't reply to georgemcbay, but he stated:

> "this can be disabled"

I've had this set in the market app as you described for a while, but still get notifications when an app has autoupdated. Did I miss something?

Froyo added auto-updates that work as jellicle described (you select it as an option per-app from inside the market app and it'll auto-update those apps that publish new versions whose permissions haven't changed).

It is true that by default you still get notifications for each app update, but this can be disabled (go to the settings in the Market app, set the notifications setting to 'Do not notify me').

While technically this isn't quite the same as Chrome because the user has to disable notifications manually (and the notification option isn't a per app option, but rather for all apps), I think the system in place on Android strikes the right balance for a mobile device.

IIRC, Android was originally its own company that was purchased by Google. Also, Chrome uses WebKit primarily on the suggestion of the Android team.

I like the idea, but is anyone else worried about the user interface? I don't like the thought of any site I happen to drive by registering their ability to handle intents. When it does become time for me to edit a photo, I don't want 50 choices popping up, nearly none of which I remember. And, it seems rife with phishing opportunities.

I'm not sure what the answer is here. I also don't want to be asked every time a site wants to register an intent. If you just make it opt-in, it seems like most users will simply miss the opportunity to do so.

In my opinion, feature creep is starting to bloat Chrome.

Reply on news.ycombinator.com