跳到主要内容

iOS中的移动链接

使用QRCode中通常显示的URI，可以通过Android和iOS上的深度链接或通用链接共享该URI来建立连接。e pattern we chose to adhere for a consistent UX across platforms for connection establishment is the following:

  1. Dapp提示用户连接
  2. 用户按下连接按钮，显示iOS兼容钱包列表
  3. 用户被重定向到所选的钱包
  4. 钱包提示用户批准或拒绝会话
  5. 返回Dapp 5a. 钱包提示用户手动返回Dapp 5b. 钱包自动返回到Dapp使用WalletConnectRouter
  6. 用户返回Dapp

当用户需要签名请求时，也会发生类似的情况:

  1. Dapp自动重定向用户到之前选择的钱包

  2. 钱包提示用户批准或拒绝请求

  3. 返回Dapp

    3a. 钱包提示用户手动返回Dapp

    3b. 钱包自动返回到Dapp使用WalletConnectRouter

  4. 用户返回Dapp

iOS Wallet 支持​

iOS在整合方面有更多的注意事项，但我们确保尽可能简单明了。因为它的操作系统不是设计来处理订阅同一个深度链接模式的多个应用程序的，我们设计了QRCode模式，在我们的浏览器上列出支持的钱包，并针对每个钱包指定特定的深度链接或通用链接。

要将您自己的钱包添加到浏览器，请登录您的WalletConnect Cloud帐户。

我们建议在iOS上使用通用链接而不是深度链接，因为它们提供更流畅的用户体验和更少的提示。当dapp在iOS上触发移动连接时，您应该会看到以下链接

# For deep links
examplewallet://wc?uri=wc:94caa59c77dae0dd234b5818fb7292540d017b27d41f7f387ee75b22b9738c94@2?relay-protocol=irn&symKey=ce3a2c7724c03cf1769ba8b1bdedad5414cc7b920aa3fb72112b997d1916266f

# For universal links
https://example.wallet/wc?uri=wc:94caa59c77dae0dd234b5818fb7292540d017b27d41f7f387ee75b22b9738c94@2?relay-protocol=irn&symKey=ce3a2c7724c03cf1769ba8b1bdedad5414cc7b920aa3fb72112b997d1916266f

此外，当dapp触发一个签名请求时，它将击中带有不完整URI的深度链接，这应该被忽略，并被视为无效，因为它只用于自动重定向用户以批准或拒绝签名请求。

# For deep links
examplewallet://wc?uri=wc:00e46b69-d0cc-4b3e-b6a2-cee442f97188@2

# For universal links
https://example.wallet/wc?uri=wc:00e46b69-d0cc-4b3e-b6a2-cee442f97188@2

iOS App链接约束​

当在iOS上使用WalletConnect并触发钱包交互时(例如，当发送交易或签署消息时)，您可能会遇到原生应用程序没有按预期打开而出现浏览器导航的问题。对于某些钱包(如Rainbow)，这将呈现一个备用网站，而其他钱包(如MetaMask)将重定向到App Store。

出现此问题是因为iOS上的应用程序链接只有在遵循以下规则时才会打开本机应用程序:

  • 钱包交互必须由用户发起的事件触发, 例如，在点击处理程序中而不是在页面加载中或在异步回调中。
  • 必须在事件处理程序中尽快触发钱包交互。 之前的任何异步工作(例如，估计气体、解析ENS名称、获取nonce)都应该在事件处理程序触发之前完成。这可能需要您围绕这个约束来设计用户体验，防止用户在准备好之前启动钱包交互，而不是懒惰地完成工作。

注意，即使您自己的代码遵循这些规则，您所依赖的库也可能在触发钱包交互之前运行自己的异步逻辑。 例如 Ethers asynchronously populates transactions before sending them. 下面介绍了已知的解决方法，但是如果您仍然遇到这些问题，您应该向相关的库维护人员提出这些问题。

对于 Ethers v5​

这些都是在使用iOS时避免应用程序链接问题的已知解决方案 Ethers v5.

当发送交易时​

这避免了检索内部块号的异步调用，而ether使用该调用来解析一个完整的TransactionResponse对象。

注意，作为这个优化的结果，sendUncheckedTransaction返回一个模拟事务响应，它只包含hash属性和wait方法。所有其他属性都为null。

  • 交易的to属性应该是一个普通地址，而不是一个ENS名称。

    这避免了在发送过程中自动解析ENS名称的异步调用。

如果您仍然希望支持ENS名称解析，您应该提前手动运行' provider.resolveName '，在用户试图发送交易之前存储结果。不要在事件处理程序中解析ENS名称。

  • 应该设置交易的gasLimit属性。

    这避免了在' sendTransaction '中执行的异步工作，它会在缺少气体限制时自动估计。

如果您仍然想使用来自sendTransaction的相同的gas限制估计逻辑，您应该提前手动运行provider.estimateGas，在用户试图发送交易之前存储结果。不要在事件处理程序中估算gas。

当对合约调用write方法时​

当签名信息时​

  • If the message depends on the result of an asynchronous call (e.g. retrieving a nonce when implementing Sign-In With Ethereum), you should do this work ahead of time, storing the result before the user attempts to sign the message. Do not perform this asynchronous work in the event handler.