Question

我对这里的情况感到非常困惑。基本上，我有一个带有2个参数的分支链接。在我的iOS中，它在安装过程中在deeplinkhandler设置中处理。

但是，该链接的工作方式非常不同。我们在手机上安装了TF。应用程序商店还没有版本w分支。

配置如下：

来自我们的chrome：无缝工作，深层链接作品
来自我的手机，iMessage：转到appstore
从他的手机，iMessage：转到应用程序，但深层链接不起作用

所以......

如果它适用于chrome，这是否意味着我的整合工作正确？
为什么它与我的手机和另一部手机的工作方式不同，因为我们有相同的操作系统？
如果主要目标是正确地进行深层链接（比如电子邮件），那么建立一个URL方案会不会更有效，我们肯定知道深层链接会在我们需要的地方找到用户？

编辑：找出问题的一部分：我的设备“已禁用通用链接”

现在，这是因为即使链接看起来有效，也不会调用继续的userActivity！我知道因为它没有显示在我的调试日志中，当我初始化应用程序时，当深层链接看起来不起作用时，我打开应用程序时会触发深层链接。：）

  // This is my method signature, its in an appdelegate EXTENSION.
  // could that be the problem?
  // i am using swift 2.3

  func application(application: UIApplication, continue userActivity: NSUserActivity, restorationHandler: ([Any]?) -> Void) -> Bool {
    application.fuckingComprehensivePrint("application continue in appdelegate")
    return Branch.getInstance().continueUserActivity(userActivity)
  }

编辑2：好的，总而言之，有三个问题

我的设备已停用通用链接
我将方法签名放在扩展名
我的方法签名错了（我使用swift 3.0语法）

我的app中也有URL处理（与分支分开），导致它在某些情况下起作用。

Answer 1

来自Branch的Alex：欢迎来到深层链接的疯狂世界 - 这就是分支存在的原因:)。

回答你的问题：

如果Chrome中的工作正常，则表示您的实施至少部分正确。这是因为在某些情况下，Branch仍然可以使用Chrome方案重定向到Chrome。如果是这种情况，您的应用将打开，而不会右上角的“转发到网络”箭头（这是您只是通用链接的赠品）。根据您的描述（Chrome深层链接，但iMessage没有），听起来您的openURL方法（URI方案链接）已正确配置，但continueUserActivity（通用链接）不是。
由于相同设备上的行为不同，我怀疑您的设备上的Universal Links可能在测试期间的某些时候被禁用。这很容易做到 - 谢谢，Apple - 但也很容易修复：只需将链接粘贴到iOS Notes应用程序中，长按（而不是强制按下）链接，然后选择Open in [app]。
直到iOS 9，URI方案才是事实上的最佳选择。随着Universal Links以及Apple强制采用的变化，URI方案越来越强烈糟糕用户体验（可怕的错误消息，没有后备能力等）。您可以在this blog post中更详细地了解这一点。当尚未安装应用程序时，普通的vanilla URI方案深层链接也无法工作，并且许多应用程序无法将它们识别为有效的可点击链接，因此需要将它们包含在具有重定向的常规http链接中。

分支是一种根本不同的应用内容链接方法。

与包含内容路径的标准链接不同，您可以将分支链接视为唯一令牌，在应用中为您提供无限数量的key:value对（包括 - 如果您真的想要它 - a URI path that can be automatically triggered），以完全相同的方式，在每种情况下。

因此，不需要处理所有不同且不断变化的标准，尝试检测点击链接时是否安装了应用程序，担心用户可能使用哪个应用程序或浏览器打开链接等。，您需要做的就是等待链接密钥的传递。 Branch已将所有这些技术细节抽象出一个单独的框架。

起初在概念上有所不同，但远更灵活，因为您不再仅限于可以存储在URI路径中的数据。

分支深层链接在不同的应用和手机中的工作方式截然不同

1 个答案:

分支是一种根本不同的应用内容链接方法。