iOS schem与Universal Link 调试时踩坑解决记录

目录
  • 简介
  • AppDelegate和SceneDelegate
  • 问题:在iOS13以上冷启动的时候不会走代理函数!
  • 如果你用了Scheme方式:
    • iOS13之前会走这个代理函数
    • iOS13之后会走
  • 如果你用了Universal Link方式:
    • iOS13之前会走这个代理函数
    • iOS13之后会走
  • 总结

简介

scheme和Universal Link是在iOS中两种可以在网页中点击回跳到自己预定的APP的两种方式。至于这两种方式需要怎么配置,这里就不做详细的介绍了。网上的文章一搜一大堆。今天主要是说一下这次的配置过程中遇到的问题。

AppDelegate和SceneDelegate

SceneDelegate是在iOS13的时候新增的,之前做老项目的迭代更新的时候很少接触这个文件。这回就简单的和它交流一下。

对于这次的交流结论是:当AppDelegate和SceneDelegate两个文件共存的时候,我们不仅仅要关注AppDelegate中的回调函数,还要关注SceneDelegate代理的回调函数,因为在不同的iOS系统下走的文件回调是不一样的。

在iOS13之前通通走AppDelegate,iOS13之后就会走SceneDelegate。

问题:在iOS13以上冷启动的时候不会走代理函数!

上面已经说过在iOS13之前通通走AppDelegate,iOS13之后就会走SceneDelegate。

如果你用了Scheme方式:

iOS13之前会走这个代理函数

- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options{
}

我们只需要在里面多自己相应的逻辑处理就可以了,并且不用关注是冷启动还是APP已经在后台挂起。都能在这里获取到你想要的参数。

iOS13之后会走

- (void)scene:(UIScene *)scene openURLContexts:(NSSet<UIOpenURLContext *> *)URLContexts{
    UIOpenURLContext *urlContext = URLContexts.anyObject
}

这时就会出现问题了,这个函数只有在APP在后台挂起的时候才会走。如果是冷启动的时候,压根不会走这个函数,从而导致我们拿不到那个想要跳转的链接地址。

如果你用了Universal Link方式:

iOS13之前会走这个代理函数

- (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void(^)(NSArray<id<UIUserActivityRestoring>> * __nullable restorableObjects))restorationHandler{
}

我们只需要在里面多自己相应的逻辑处理就可以了,并且不用关注是冷启动还是APP已经在后台挂起。都能在这里获取到你想要的参数。

iOS13之后会走

- (void)scene:(UIScene *)scene continueUserActivity:(NSUserActivity *)userActivity{
}

这时就会出现问题了,这个函数只有在APP在后台挂起的时候才会走。如果是冷启动的时候,压根不会走这个函数,从而导致我们拿不到那个想要跳转的链接地址。

总结

在你使用SceneDelegate的时候不管你是scheme还是Universal Link 都会在冷启动的时候不走代理函数。解决办法有两种:
1.你可以不用SceneDelegate这个文件。这样就可以避免问题的出现。毕竟现在的APP好像并没有强制开发者只用SceneDelegate;
2.在无数次的测试的时候我们会发现在APP冷启动的时候都会走SceneDelegate的

- (void)scene:(UIScene *)scene willConnectToSession:(UISceneSession *)session options:(UISceneConnectionOptions *)connectionOptions

我们可以对这个函数做做文章。 在connectionOptions中有两个属性,一个是URLContexts另一个是userActivities,你再看看对应在SceneDelegate的函数都有对应的形参,所以我们可以在冷启动的时候获取一下相应的参数然后从而达到获取链接参数的目的;

scheme:
UIOpenURLContext *urlContext = connectionOptions.URLContexts.anyObject;
Universal Link:
NSUserActivity *userActivity =connectionOptions.userActivities.anyObject;

以上就是iOS schem与Universal Link 调试时踩坑解决记录的详细内容,更多关于iOS schem Universal Link调试的资料请关注我们其它相关文章!

(0)

相关推荐

  • Android界面一键变灰开发深色适配模式编程示例

    目录 深色主题工具类 background_color公用背景色 values/colors.xml 的代码 values-night/colors.xml 的代码 Android 界面一键变灰 java kotlin 深色主题工具类 package com.example.kotlindemo.utils import android.content.Context import android.content.res.Configuration import androidx.appcomp

  • vue3不能使用history.pushState修改url参数踩坑

    目录 前言 问题 追根溯源 解决 前言 在重构我的 vue-use-sync-url(辅助将数据和 url 参数进行同步的工具库)时,遇到了一个使用 window.history.pushState 来修改地址栏的 url 参数的 bug,准确来说是 vue-router 的 bug,下面就来讲讲具体是怎么回事. 问题 场景如下,有一个输入框里面输入了内容,点击搜索按钮使用 window.history.pushState 将数据同步到 url 参数上.然后再点击 go about 按钮跳转到别

  • 示例解析java设计模式七大原则接口隔离原则及优化

    目录 1.什么是接口隔离原则? 2.对应代码 3.改进代码 4.接口隔离原则总结 1.什么是接口隔离原则? 客户端不应该依赖它不需要的接口,即一个类对另一个类的依赖应该建立在最小的接口范围上. 2.对应代码 上面这张图呢,就违反了接口隔离原则.它对应的代码如下: package com.szh.principle.segregation; /** * */ interface Interface1 { void operation1(); void operation2(); void oper

  • 编程开发中99%的研发者都踩过的误区

    目录 01 02 03 04 05 06 07 08 意识不到误区的存在最为离谱: 01 生活中,职场上,游戏里,都少不了正面对喷过:意识太差: 在个人的认知中意识即思维,意识太差即思维中存在的误区比较多: 每个人或多或少都存在思维上的误区: 思维影响行为: 行为效应会带来很多显而易见的问题: 问题多了自然就是各种鸡飞狗跳: 思维误区作为成长的第一大阻力,认清误区并尽快走出,直接决定成长的速度: 误区最妖娆的地方,在于会让人有自我认同的决心,坚定的相信自己思维的正确性: 想要快速的走出误区,就要

  • Storybook 7.0 Beta Vue3踩坑解决记录

    目录 故事背景 坑一: 坑二: 坑三: 总结 故事背景 基于 Vue + Vite + TS 结合 pnpm 的一个 monorepo 项目的组件库文档编写,起初个人是比较倾向于直接使用全家桶系列的 VitePress.无奈公司中其他库文档均使用 Storybook,并且已经升级到最新版本. 好吧,到这里就基本知道了自己要做什么了. 由于之前也没有接触过这个玩意儿,就去看着官网一步步操作去了.坑也就在这里了,谁知道版本上去了,文档却没有做出相应的调整.然后就有了后续一系列的问题.Storyboo

  • iOS schem与Universal Link 调试时踩坑解决记录

    目录 简介 AppDelegate和SceneDelegate 问题:在iOS13以上冷启动的时候不会走代理函数! 如果你用了Scheme方式: iOS13之前会走这个代理函数 iOS13之后会走 如果你用了Universal Link方式: iOS13之前会走这个代理函数 iOS13之后会走 总结 简介 scheme和Universal Link是在iOS中两种可以在网页中点击回跳到自己预定的APP的两种方式.至于这两种方式需要怎么配置,这里就不做详细的介绍了.网上的文章一搜一大堆.今天主要是

  • iOS APP中保存图片到相册时崩溃的解决方法

    环境: iPhone Version 11.0.3 ,  Xcode Version 9.0 问题: 昨天维护APP时,发现拍照后保存图片时应用崩溃,输出如下: This app has crashed because it attempted to access privacy-sensitive data without a usage description.  The app's Info.plist must contain an NSPhotoLibraryAddUsageDescr

  • 详解Vue微信公众号开发踩坑全记录

    本文介绍了Vue微信公众号开发踩坑全记录,分享给大家,也给自己留个笔记. 需求 微信授权登录(基于公众号的登录方案) 接入JS-SDK实现图片上传,分享等功能 现状及难点 采用的Vue框架,前后端分离模式(vue工程仅作为客户端),用户通过域名访问的是客户端,但是微信授权中涉及签名和token校验依赖服务端 JS-SDK需要向服务端获取签名,且获取签名中需要的参数包括所在页面的url,但由于单页应用的路由特殊,其中涉及到IOS和android微信客户端浏览器内核的差异性导致的兼容问题 解决方案

  • 使用Pyinstaller的最新踩坑实战记录

    前言 将py编译成可执行文件需要使用PyInstaller,之前给大家介绍了关于利用PyInstaller将python程序.py转为.exe的方法,在开始本文之前推荐大家可以先看下这篇文章,本文主要给大家介绍了Pyinstaller最新踩坑实战记录,现在网上关于pyinstaller的问题充斥着各种copy过来copy过去的答案,这大概就是各种无脑博客爬虫站最让人讨厌的地方. 而且这方面的问题,stackoverflow也是回答的千奇百怪. 强烈推荐官方文档 http://pythonhost

  • Keras构建神经网络踩坑(解决model.predict预测值全为0.0的问题)

    终于构建出了第一个神经网络,Keras真的很方便. 之前不知道Keras这么方便,在构建神经网络的过程中绕了很多弯路,最开始学的TensorFlow,后来才知道Keras. TensorFlow和Keras的关系,就像c语言和python的关系,所以Keras是真的好用. 搞不清楚数据的标准化和归一化的关系,想对原始数据做归一化,却误把数据做了标准化,导致用model.predict预测出来的值全是0.0,在网上搜了好久但是没搜到答案,后来自己又把程序读了一遍,突然灵光一现好像是数据归一化出了问

  • 微信小程序自定义tabBar的踩坑实践记录

    微信官方文档对自定义 tabBar 的阐述较为潦草,在开发自定义 tabBar 过程中我踩了很多坑,因此在此处做个总结. 我使用 Vant Weapp作为 UI 组件库,下面以此组件库为例. 定义 tabBar 创建自定义 tabBar 文件 创建一个与 /pages 的同级目录,命名为  /custom-tab-bar,注意目录层级与目录命名问题,不可用其他名称命名. 在 /custom-tab-bar 下创建四个文件: index.js index.json index.wxml index

  • Go使用proto3的踩坑实战记录

    开发环境:windows10,golang1.18.2,goland2022.2 最近在写项目时,一些数据类的结构以protobuf文件给定.因此,需要将这些protobuf文件转换为golang代码. 首先,在下载解析protobuf的包的时候就碰到了第一个问题... go get -u github.com/golang/protobuf/protoc-gen-go 在我用上述命令后,终端提示该包已弃用 go: module github.com/golang/protobuf is dep

  • SpringBoot 集成 Jasypt 对数据库加密以及踩坑的记录分享

    前言 密码安全是非常重要的,因此我们在代码中往往需要对密码进行加密,以此保证密码的安全 加依赖 <!-- jasypt --> <dependency> <groupId>com.github.ulisesbocchio</groupId> <artifactId>jasypt-spring-boot-starter</artifactId> <version>3.0.3</version> </depe

  • ShardingJdbc读写分离的BUG踩坑解决

    目录 前言 数据库介绍 1. 常规写完读 2. 在一个 service 里面调用另一个 service 3. 新开一个线程去调用 service2 4. service2 新开一个事务执行 前言 最近公司准备接入ShardingJdbc做读写分离了,老大让我们理一理有没有写完数据立马读的场景,因为主从同步是有延迟的,如果写完读取数据走到从库,而从库正好有延迟,没读取到数据,岂不是造成了生产事故. 今天我们来看看,ShardingJdbc作为一个成熟的框架是怎么处理写完数据立即读取的场景的. 数据

随机推荐