近一次弄推送遇到的问题

201703月测试推送踩过的坑

1.测试要切回测试版本链接,看deviceToken是否保存成功 

2.一定要关闭翻墙

3.一定要使用公司的内网连接手机


好久没有单独弄推送这块啦,连申请证书都很不熟悉啦,最近确实也变化了一些,特别是 iOS 10 以后,特此记录下。

  • 推送证书中新增选项的区别
  • 推送时entitlements文件 的增加
  • 下载的证书没有密钥
  • P 12 转 PEM
  • 推送开关何时打开
  • 证书没匹配的的bug
1、Apple Push Notification Authentication Key (Sandbox & Production)Apple Push Notification service SSL (Sandbox & Production) 选项的区别

在生产环境下,push 推送出现下面两个选项,


Apple Push Notification Production

记得以前都是直接选下一个选项的,当然现在推送时也是一样的选下面那个。而对于这个新的选项( Authentication Key)又是什么意思呢?


生成的key

使用它后,可以为我们提供一个 key 给后台,避免我们的推送证书过期的问题 ,它是说这样设置后永远不会过期,除非我们删掉它,但是目前还没用过!

2、注意推送需要增加一个entitlements文件

注意这两步骤,特别是第二步

appName.entitlements
在targets->Capabilities->Push Notifications中打开推送,然后系统会自动帮你写入.entitlements文件,所以不需要自己去手动加。需要注意的是,有人遇到过.entitlements文件没有被加入工程的,这也会产生问题,需要手动把.entitlements加入工程。

<key>aps-environment</key>
<string>development</string>
// <string>production</string>

开发环境下

正式环境下
3、下载的证书没有密钥

下面那个就是没有密钥的情况,上面那个是有密钥的情况

遇到这种情况,通常有两种方式:

  • 自己重新申请一次证书,不管这个证书了
  • 找到申请证书的Mac 会有秘钥,然后就会有了

然而我却是用了我另一个同事的账号和电脑就行了,暂时还不清楚是什么原因,因为之前申请证书的账号和Mac 我并不清楚,但是我发现在那有密钥,此处还有点疑问...

4、 P 12 转 PEM

下载好证书后(分为开发版和正式版)(develop.cer & production.cer), 然后导出 p12。

我记得我之前只要将 cer.p12 给我们后台就好了。
现在却要传两个,需要通过 钥匙链分别导出 cer.p12 和 keyCer.p12


上为证书下为密钥
  • cer.p12 == > cer.pem
    openssl pkcs12 -clcerts -nokeys -out cer.pem -in cer.p12
  • keyCer.p12 ==> keyCer.pem
    openssl pkcs12 -nocerts -out keyCer.pem -in keyCer.p12
  • 合并 cer.pem 和 keyCer.pem == > needCer.pem
    cat cer.pem keyCer.pem > needCer.pem
    然后将 needCer.pem 发给后台,并告诉密码就好了

详细可以看 导出 p12 或 pem 文件,但不要输入错误,像我不小心输入错了,关键是还没提示,最后终于坑了一把我们后台。

5、推送开关何时打开

一般来说,我们设置是推送是重新发版本的时候才打开的,或者说打开推送开关后。

而我这次遇到的这个问题是:测试在不断切换版本时,发现推送不了。实际原因就是推送的开关的,也就是那个我们系统的弹出框 “问你是否允许打开推送的那个开关”,才是真正启动推送接口的问题。

typedef NS_OPTIONS(NSUInteger, UIUserNotificationType) {
    UIUserNotificationTypeNone    = 0,      // the application may not present any UI upon a notification being received
    UIUserNotificationTypeBadge   = 1 << 0, // the application may badge its icon upon a notification being received
    UIUserNotificationTypeSound   = 1 << 1, // the application may play a sound upon a notification being received
    UIUserNotificationTypeAlert   = 1 << 2, // the application may display an alert upon a notification being received
}
 [[UIApplication sharedApplication] currentUserNotificationSettings].types

当然直接保存一个本地 deviceToken , 然后判断 deviceToken 是否存在也可以作为打开推送开关的问题解决,毕竟服务器只要这个 deviveToken 的。

另外以下几种情景最好更新下信息上传给给服务器:

  • 第一次启动时
  • 更换 用户 ID 时
  • 第一次启动不允许通知,后面重新打开通知开关时
  • 更新版本时

这是我们推送,在设置定制化时需要做的。

6、一个打包时遇到

No suitable application records were found. Verify your bundle identifier 'xx' is correct

原因是: 自己的账号和公司的账号混淆了,需要转换下!

备注参考:
https://eladnava.com/send-push-notifications-to-ios-devices-using-xcode-8-and-swift-3/
http://www.saitjr.com/ios/ios-export-remote-notification-p12-pem-file.html


<think>嗯,用户之前已经询问过关于子仓库和主仓库版本号对应关系的问题,现在遇到了具体的问题:在子仓库提交了更新,但别人说版本号不对,因为没和主仓库对应。需要解决这个问题。 首先,我需要理解用户的具体情况。用户可能在子仓库中进行了修改并提交,但主仓库中仍然指向旧的提交哈希,导致主仓库中的子模块版本没有更新。这时候,其他人在拉取主仓库时,子模块还是旧的版本,所以提示版本号不对。 接下来,用户需要知道如何正确更新主仓库中的子模块指针,以指向子仓库的新提交。同时,可能还需要检查是否有其他步骤遗漏,比如提交主仓库的更改,或者是否有分支管理的问题。 考虑到用户可能不太熟悉git submodule的工作流程,需要分步骤解释操作,并说明每个步骤的作用。例如,如何进入子仓库目录,拉取最新代码,切换分支,然后回到主仓库提交新的指针。此外,可能还需要提醒用户同步更新主仓库,并通知团队成员更新子模块。 另外,用户可能对版本号的概念有误解,比如将标签或分支名当作版本号,而实际上git submodule使用的是具体的提交哈希。因此需要澄清这一点,并解释为什么必须使用提交哈希来确保精确对应。 还需要考虑用户可能遇到的常见问题,例如忘记提交主仓库的更改,或者在协作时其他人没有更新子模块。这时候需要提供相应的命令和解决方法,比如git submodule update --init --recursive,或者如何检查子模块状态。 最后,给出最佳实践,比如每次更新子仓库后都要更新主仓库的指针,使用标签管理版本,以及在协作时的沟通建议。这样用户以后可以避免类似的问题。</think>当子仓库更新后需要与主仓库建立正确的版本对应关系时,请按以下步骤操作: --- ### 一、问题根源诊断 1. **现象确认** - 主仓库中子模块指针仍指向**旧的提交哈希** - 其他开发者执行`git submodule update`时无法获取你的新提交 2. **验证当前状态** ```bash # 在主仓库执行 git submodule status # 输出示例: # -e5f6a7b8c9... lib (v1.2.3) # 旧版本 ``` --- ### 二、解决方案步骤 #### 步骤 1:更新子模块指针 ```bash # 进入子仓库目录 cd path/to/submodule # 确保切换到正确分支(假设是main分支) git checkout main # 拉取最新代码(含你的提交) git pull origin main # 回到主仓库目录 cd .. # 将新提交哈希记录到主仓库 git add path/to/submodule git commit -m "更新子模块到最新版本 $(git -C path/to/submodule rev-parse --short HEAD)" ``` #### 步骤 2:推送关联更新 ```bash # 推送主仓库的提交 git push origin main # 同时需要确保子仓库的提交已推送 git -C path/to/submodule push origin main ``` #### 步骤 3:通知协作者 要求其他开发者执行: ```bash git pull --recurse-submodules # 同时拉取主仓库和子模块更新 # 或分步执行 git pull git submodule update --init --recursive ``` --- ### 三、典型错误场景修复 #### 场景 1:忘记更新主仓库指针 **现象**:子仓库有新提交,但主仓库未记录 **修复**: ```bash # 查看子仓库当前提交 git -C path/to/submodule log -1 --oneline # 输出:a1b2c3d (你的新提交) # 强制更新主仓库指针 git add path/to/submodule git commit --amend # 如果是最一次提交未包含子模块更新 ``` #### 场景 2:分支错位 **现象**:子仓库处于detached HEAD状态 ```bash # 查看子仓库状态 git -C path/to/submodule branch # 输出:* (HEAD detached at a1b2c3d) # 创建临时分支并关联 git -C path/to/submodule checkout -b temp-fix git -C path/to/submodule push -u origin temp-fix ``` --- ### 四、版本对应验证方法 1. **哈希值比对** ```bash # 获取主仓库记录的哈希 git rev-parse HEAD:path/to/submodule # 获取子仓库实际哈希 git -C path/to/submodule rev-parse HEAD # 比对两个哈希是否一致 ``` 2. **可视化工具检测** ```bash git log --graph --oneline --decorate --all # 主仓库提交历史中应显示子模块哈希更新 ``` --- ### 五、预防措施 1. **自动化配置** 在`.git/config`中添加: ```ini [submodule "lib"] update = checkout --force ``` 2. **版本标签联动** ```bash # 子仓库打标签 git -C path/to/submodule tag v1.2.4 # 主仓库同步记录 git commit -am "关联子模块标签v1.2.4" ``` --- ### 六、协作流程图解 ```mermaid sequenceDiagram 开发者A->>子仓库: git push (新提交a1b2c3d) 开发者A->>主仓库: git add submodule + commit 开发者A->>主仓库: git push 开发者B->>主仓库: git pull 开发者B->>子仓库: git submodule update Note right of 开发者B: 自动检出a1b2c3d ``` 通过以上操作可确保子仓库更新与主仓库版本精确对应。关键是要记住:**子仓库的版本更新必须通过主仓库的提交来“盖章认证”**,这与常规的Git仓库独立管理有本质区别。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值