Apps and Web URLs: Perfect Together

http://joehewitt.com/2011/10/06/apps-and-web-urls-perfect-together

by BarkMore • 15 years ago

19 24 15 years ago

This has been a feature of Android since launch, it's part of the w3c spec for protocol specific handlers (and is already implemented in Chrome Dev [Google Calendar offered to handle all webcal: links for me]), and it will be better suited via Web Intents in the coming months.

Also, there's really no explaination by the author as to how fb://profile/drivebyacct2 is any better than http://facebook.com/profile/drivebyacct2. Now there will be a landrush of people trying to claim protocol prefixes now too? Why bother, domains are already intrensic enough to online brands, why create a whole new area to deal with? Not to mention user confusion. Yes, that's "eff-bee colon slash slash", "no, don't put www first", etc.

nupark2• 15 years ago

Additionally, as per RFC1378, non-standard schemes should either be registered with IANA, or should start with x-. If Facebook was being a good citizen, they'd register 'fb' (they haven't), or better yet, use 'facebook' or 'x-facebook'.

Also, we don't need a fancy database -- existing vendor's web sites are perfectly capable of sniffing the browser and redirecting to a native app, if it's available -- this is what iTunes does.

lygaret2• 15 years ago

I'm pretty sure you've got his argument backwards:

1. We already _do_ have fb://profile/account, it's the app specific URL registered in the iOS app to open the Facebook app.

2. What he's saying is "Why can't you register http://facebook.com/profile on iOS to open the facebook app?" That would mean that we explicitly _don't_ have a protocol landrush.

3. A solution might be a service that takes a web url, and returns an app url, so that if the web url has an app equivalent, we never have to know it; the app functions as we expect, and we don't introduce something above and beyond the web URLs we know and love.

drivebyacct24• 15 years ago

1. That's iOS and I have no idea why anyone would want that. Like really, what value does that add?

2. Yes, like I said, Android has already implemented that. I think it's a fine idea. I love that I can click on Youtube links and choose to open it in Dolphin, the YouTube app, or the YouTube downloader app.

3. Why would the web service take the URL. Like I already said, model this off of browser protocol handlers and Web Intents. Let web application register as possible handlers, let the application choose whether to open in a webpage, or another web app that is capable of consuming and understanding those URLs (which is exactly how it happens in Android). Again, how is an "app url" any more useful than a regular URL in this regard?

joehewitt4• 15 years ago

I'm just now learning about how Android solves this problem. That's great, but the problem remains on iOS. Protocol handlers in browsers don't help here because the problem has to do with http urls.

If iOS allowed me to launch native apps with http URLs, I would never have written this post. They don't, they only suport custom protocol schemes. I'm trying to lessen the importance of custom protocol schemes here by providing a service to silently map http URLs to the custom URLs so users never see them.

drivebyacct24• 15 years ago

I've asked the question in this same comment thread, but how will this webservice idea solve this problem? Do you not still need an OS or browser level abstraction to look up (every?) url with this webservice to determine if there is an appropriate app specific url? What if I don't want to open the (limited) Facebook app?

kefs• 15 years ago

Why am i required to enable javascript just to read text on Joe Hewitt's blog? No degradation at all? :(

icebraining5• 15 years ago

Not sure what you're talking about, it doesn't need JS. Works fine here with NoScript, and the source clearly shows the content directly in the HTML.

dangrossman• 15 years ago

Not here. The source of this blog post is a script tag that writes a script tag that actually writes the post content. The content isn't in the source.

http://pastebin.com/CXh0nvXm

joehewitt4• 15 years ago

I'm using a fairly experimental JavaScript-driven system right now. It's totally overkill for a blog, but it's my blog and I can do stuff like this for fun. No offense, but if you disable JavaScript, you get what you deserve.

icebraining5• 15 years ago

>you get what you deserve

A more secure and tracking-free experience?

By the way, nothing against that (although I probably won't bother enabling it), but is it doing User-Agent sniffing? Because here in Firefox 6 it loads a normal HTML version.

mcmatterson• 15 years ago

This is so wrong, I don't even know where to begin. The _entire_ point of URLs is that they're just that -- Universal. Requiring a specific application in order to consume a URL is just as asinine as User Agent sniffing to enforce an 'IE Only' policy (and you're lying if you say that ended well).

Perhaps consuming based on Content-Type headers would be a better way to attack this (legitimate) problem. Certainly in the early days of the web, that's how it was done (want to enjoy the latest VRML? Install plugin 'x'). Adding a layer of abstraction on top of URLs that tries to mediate this is just altogether wrong, I think.

Debate welcome. I'm mostly just thinking out loud here.

lygaret2• 15 years ago

See my comment above, but I'm pretty sure you have his argument backwards; we already _do_ have application specific URLs in iOS, and wouldn't it be nice if that weren't the case?

lukejduncan• 15 years ago

On android they are more properly thought of as URI's than URL's. The point of a URI is to give a canonical representation of an object, and an URL represents the location of that object (or representative).

Web intents are great because I can say "I want this song, Android please let the best app respond (which may be a browser)" instead of "I want to access this song via Spotify, even if its not there and it is on X provider that I have access too."

zokier2• 15 years ago

Actually, I think the "official" expansion for URL is Uniform Resource Locator, not Universal. But either way, I believe that it refers to the property of not being tied to Web specifically, but rather any resource in the internet. All URLs require more or less specific application to handle them; web browser for http-URLs, mail client for mailto-URLs etc. I don't think that fb-URL is any worse. You could register your browser to handle them, or use a native application, based on your preference. If Facebook would be forced to use http-URLs then you wouldn't have that choice.

chime• 15 years ago

Here's a site to publish your iOS-specific app URLs: http://www.handleopenurl.com/

Until apps start owning URLs, everyone can publish their app capabilities here and call other apps (like Tweetbot) from their apps.

zokier2• 15 years ago

He says that service-specific URLs are not portable, but I don't see any reason why that would be the case. I mean, most platforms supports registering handlers for arbitrary schemes. The only piece I see missing is the ability to register a web app as a URL handler, but that should be almost trivial to solve. Already if I click a mailto:-link in Firefox, I have the choice of using Gmail, so generalizing that shouldn't be too difficult.

edit: apparently Firefox already does "Web-based protocol handlers", which allow web apps to register arbitrary URL-schemes. So basically only thing needed to make fb-URLs to work with browsers is such handler for the Facebook web app.

edit2: http://zokier.net/fburl/ implements aforementioned fb-URL handler. If you register that page to handle fb://-urls in Firefox, and register Firefox to those urls in Windows, then they function globally correctly.

Apps and Web URLs: Perfect Together

Related Stories