Apps and Web URLs: Perfect Together | Hacker News Reader

Apps and Web URLs: Perfect Together

joehewitt.com

19 pointsBarkMore24 comments

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.

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?

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.

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."

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.

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.

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

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.

>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.

I love how the industry can spend a decade advocating the separation of form and content, and then in a handful of years go to completely co-mingling the two, at least and especially from the end user perspective.

I disable Javascript out of necessity. Having cleaned enough garbage off of others' computers, and having struggled long enough to pay attention despite the "blinkenlights", I find I really have no alternative.

Your choice, Joe. Fine, although I don't particularly appreciate the snarky rhetoric. (I find the combination of "No offense..." and "you get what you deserve" to be a rhetorical ploy.)

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.

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

Uh, odd. Both Firefox and curl give me the proper content: http://paste.debian.net/plain/134758

Sorry, I'm doing some experimental stuff here. I do UA sniffing to decide whether to render the page on the server (with Node.js) or on the client with Ajax. Crawlers and old browsers get static content, new browsers get JavaScript.

Have you thought about adding a link to a server rendered version (something like same_url+"?script=0") inside a <noscript> area? It'd be easy to implement.

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.

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.

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?

I think the point is to achieve what Android has without waiting for Apple to implement it. Since iOS app devs are stuck with internal URIs, a translation webservice would alleviate the problem.

But this would still require OS level abstraction to even submit the web URLs to the webservice to look up an app-specific URL. Unless I'm missing something.

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.

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?

Here's an example of the problem it solves. I never log into Facebook in Safari because the Facebook app is a much better experience on iOS. Often I tap on links in native apps which go to facebook.com, and then I'm looking at the Facebook login page instead of the content I want to see.

This solution would allow apps (if they choose to use this service) to turn facebook.com URLs into fb:// URLs, and take me where I really want to go when I click those links.

Ideally iOS would provide this URL mapping, as Android does, so that this happened everywhere, not just apps that use this service. I wish Apple would do this. In the mean time, this is one approach we could take.

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.

Reply on news.ycombinator.com