ios消息推送

1,996 阅读5分钟

之前一篇说了ios推送证书的生成。这是开发推送的基础环境。这次介绍的是怎么去开发。
来几句废话: 苹果的推送相比于安卓的推送,显得更加清晰,简明许多。首先不必考虑那么多厂商配置,其次苹果的送达率要比安卓高,也很快速。所以一旦你开发的Apple能接收到第一条通知栏且流程正常,那么在后续的测试中,就很少会出问题。相比于Android而言,有时厂商通道过来消息会收不到或者延迟时间长,这当然区别于不同的厂商及不同机型。废话不多说,看看怎么做ios的推送。

一、原理介绍

其实更详细的原理介绍在这篇文章,App推送。如果你事先看过这篇,可能理解接下来的介绍会清晰很多,这里原理介绍不多,只是说前后端的代码及关键的参数怎么操作。 iOS的推送涉及个推和苹果APNs推送。

  • 在线,即app在前台打开运行时,消息通过个推通道下发到客户端。
  • 离线,即app在后台、锁屏时,消息将通过个推侧请求对应厂商侧的服务端,由苹果进行推送。

二、服务端选择方案

1、个推选择的是透传消息类型, 即 push_message中的transmission,这里的透传内容不再拘泥于UNIPUSH要求的数据格式,是自定义的内容。个推通道对于ios是不支持通知消息的。实际中,开发者可以跟安卓共用代码,即不用做任何区分。

2、厂商推送,iOS建议选择这种通知消息类型的方式,即 push_channel =》ios=>type选notify,payload是自定义数据,这个数据不必拘束unipush规定数据,aps=>alert=>title,body;这种方式会显示通知栏,客户端点击触发click事件,payload即为客户端获取到的数据。具体的参数参考个推文档去查看,但这几个参数是要特别注意的。注意在下发策略时,参数ios的选择似乎已经不重要了,可以不选择,default做选择就行。

三、客户端的操作

这里要说明的一点是,客户端的对于消息的处理方式跟服务端选择的下发策略及消息类型是至关重要的,所以一定要跟服务端配合好,否则可能会出现,服务端通知下发成功了,但客户端出现的情况会五花八门,很难找到规律去处理。而这篇文章主要解决的问题就是将服务端和客户端统一起来,避免前后端的开发者做到怀疑人生。 第二部分介绍了服务端几个重要的参数,接下来的介绍是建立在第二部分的基础上所做的操作,所以如果服务端的选择是其他方式,那么下面的介绍可能会出现其他不可预知的情况。

  • 1、对于个推透传消息的处理。 如果按照UNIPUSh封装好的数据格式,对于安卓,则会新建通知栏,只触发click事件,但对于iOS,会触发receive事件,所以需要客户端 监听到receive事件时,自建通知栏,但iOS自建通知栏,还会再触发receive事件,所以这里有个aps标识。即自建通知栏的aps值为null,ios通过APNS过来的aps是有值的,所以以此来处理通知栏问题,避免出现通知栏重建循环的问题。 代码如下,仅供参考
plus.push.addEventListener('receive', function(message) {
			console.log('receive接受消息')
			console.log(message)
			var data=message.payload
			console.log(data)
			if(message.aps){//aps下发的消息,应用在前台
				var options={
					title:message.title
				}
				 var localData=data
				 localData.type='Local' //用于做本地创建通知栏的标识
				 console.log(localData)
				 // 新建本地通知栏,还会触发receive事件,但此时的aps为null,以此来对通知栏循环创建的处理;
  	    plus.push.createMessage(message.content,JSON.stringify(localData),options)
			}else if(JSON.parse(message.payload).type =='Local'){
			 	// 本地创建的通知栏所触发的事件,不做任何处理
				console.log('本地创建的消息,不做处理')
			 }else{//这是个推透传过来的消息, 对iOS而言,要处理通过个推过来的透传消息,此时的aps为null,要新建通知栏进行展示
				console.log('个推透传消息过来的数据')
			}
		},false);
  • 2、对于Apns通道的处理。 厂商通道的下发,会展示通知栏。但当在消息有效期内,打开APP时,push_message中的transmission内容还将通过个推通道传递给客户端,此时可在客户端透传回调中的参数pushmessage对象中获取aps属性值来片段是否是APNs下发的内容;这个是比较关键的,在处理receive事件时要注意,不然会出现点击通知栏启动App时,再次新建出通知栏展示。 参考代码如下
plus.push.addEventListener('click', function(message) {
		console.log('click事件')
		console.log(message.payload) //自定义过来的数据
		if(message.aps){//ios点击的厂商推送,离线情况下
			console.log('ios点击事件')
			var data=message.payload
		}else{//android或者是iOS的自建通知栏时,所触发的click事件
			console.log('android点击事件')
			if(plus.os.name=='iOS'){
				var data=JSON.parse(message.payload)
			}else{
				var data=message.payload
			}
	     }
        //对data进行自身的业务处理
})

最后要说明的是,unipush的推送,所涉及到的推送方案,消息类型,参数等要以unipush的文档为主,个推的api作为参考,原因是unipush对某些参数做了处理,所以最后的结果会跟个推文档叙述有不一致的东西。所以推送时,客户端常常会出现各种各样的问题,但大部分关键因素都在于服务端的选择,所以一定要跟服务端去做好沟通,这至关重要.
这篇文章可能小白看了一头雾水,但如果开发者正在试着做unipush的推送,那这篇文章或者对你大有用处。有问题留言评论,看到会回复的。