Hacker News Reader

Comment by drivebyacct2 | Hacker News Reader

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.

View on HN

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