iOS自定义URL方案与Universal Links和Android对应方案 [英] iOS custom URL schemes vs. Universal Links and Android counterpart

问题描述

我正在寻找功能，当用户收到消息时，让我们说通过whatsapp应用程序，包含以某个方案（前缀）开头的链接，我的应用程序将在该链接上的用户选项卡时调用。

I'm looking for functionality where when a user receive a message, let's say through whatsapp app, containing a link starting with certain scheme (prefix) my app will be invoked when user tab on that link.

我知道这个功能已经作为自定义URL方案提供，但我现在也注意到Universal Links也有类似的东西，所以自定义URL方案有任何问题，因为我不知道我想使用Universal Links，因为我不希望我的应用被限制在iOS 9。

I understood this feature already available as "custom URL schemes" but I also notice now also Universal Links have similar thing, so is there any issue with "custom URL schemes" , because I don't want to use Universal Links because I don't want my app to be restricted to iOS 9.

此外，它看起来Android也有这个客户URL的功能，但是再次，在最新的Android版本6.0上，它提到了这里他们也有应用链接功能，只适用于Android 6.0，所以两者之间的区别是什么。

Moreover, it looks Android also have this feature of customer URL, but again, on the latest Android version 6.0, it's mentioned here that they also have "App Links" feature which only work on Android 6.0, so again what is the difference between the two.

我不想限制我的应用程序工作只有iOS9或Android 9.所以我猜传统的自定义 URL方案暂时对我来说更具吸引力。

I don't want to restrict my app to work on only iOS9 or Android 9. So I guess the traditional "custom URL schemes" is more attractive for me for the time being.

此外，我想确保自定义URL方案在whatsapp应用程序上的用户选项卡链接时是否有效，或者只有在Web浏览器上的链接时才能使用或邮件。

Also, I want to make sure if "custom URL schemes" will work when user tab n a link on whatsapp app or it will only work if the link on the web browser or mail.

推荐答案

自定义方案的网址在许多Android应用程序中都不会显示为链接（短信，电子邮件，WhatsApp，环聊） ，你的名字），事实上它使你的应用程序无法打开它们。然而iOS不允许定义方案+主机+路径像android一样。

URLs with custom schemes don't get displayed as links in many Android applications (SMS, E-Mail, WhatsApp, Hangouts, you name it), which de facto make them unopenable by your application. iOS however does not allow for defining scheme + host + path like android does.

一个可能的（hacky）解决方案是浏览器嗅探（我知道，邪恶，但对定义良好的行为的非标准扩展也是如此，尤其是如果在第一个地方没有任何东西被破坏，那么你在通过HTTP可到达的URL上公开的资源。

One possible (hacky) solution to this is browser sniffing (I know, evil, but so are non-standard extensions to well-defined behavior, especially if nothing was broken in the first place) at the resource you expose over a URL reachable over HTTP(s).

你可以检查请求是否来自iOS-您提供原生应用程序的平台;然后你必须确保设备安装了你的应用程序（这变得更加丑陋和丑陋;参见这里例如）然后，只有重定向到 yourapp：//你的/你的/ uri - 这会导致提示向用户显示是否要打开应用程序内的地址。 （在iOS 4，Safari浏览器的iPhone 4上测试过。）

You could check if the request origins from the iOS-platform you offer native apps for; then you would have to make sure that the device has your application installed (this is getting uglier and uglier; see here for example) and then, only then redirect to yourapp://the-rest-of-your/uri, which causes a prompt shown to the user whether they want to open the address inside the application or not. (Tested on an iPhone 4 with iOS 8, Safari browser.)

这篇关于iOS自定义URL方案与Universal Links和Android对应方案的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！