3 ms·
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 th
by lygaret 15y 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 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.
- drivebyacct2 15y ago1. 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?
- icebraining 15y agoI 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.
- drivebyacct2 15y agoBut 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.