之前一篇說了ios推送證書的生成。這是開發(fā)推送的基礎(chǔ)環(huán)境。這次介紹的是怎么去開發(fā)榆芦。
來幾句廢話：
蘋果的推送相比于安卓的推送谭溉，顯得更加清晰，簡明許多匕积。首先不必考慮那么多廠商配置盈罐，其次蘋果的送達率要比安卓高，也很快速闪唆。所以一旦你開發(fā)的Apple能接收到第一條通知欄且流程正常盅粪，那么在后續(xù)的測試中，就很少會出問題悄蕾。相比于Android而言票顾，有時廠商通道過來消息會收不到或者延遲時間長，這當然區(qū)別于不同的廠商及不同機型。廢話不多說奠骄，看看怎么做ios的推送豆同。
一、原理介紹
其實更詳細的原理介紹在這篇文章含鳞，App推送影锈。如果你事先看過這篇，可能理解接下來的介紹會清晰很多民晒，這里原理介紹不多精居，只是說前后端的代碼及關(guān)鍵的參數(shù)怎么操作。
iOS的推送涉及個推和蘋果APNs推送潜必。
- 在線靴姿，即app在前臺打開運行時，消息通過個推通道下發(fā)到客戶端磁滚。
- 離線佛吓，即app在后臺、鎖屏時垂攘，消息將通過個推側(cè)請求對應(yīng)廠商側(cè)的服務(wù)端维雇，由蘋果進行推送。
二晒他、服務(wù)端選擇方案
1吱型、個推選擇的是透傳消息類型，
即 push_message中的transmission陨仅，這里的透傳內(nèi)容不再拘泥于UNIPUSH要求的數(shù)據(jù)格式津滞，是自定義的內(nèi)容。個推通道對于ios是不支持通知消息的灼伤。實際中触徐，開發(fā)者可以跟安卓共用代碼，即不用做任何區(qū)分狐赡。
2撞鹉、廠商推送，iOS建議選擇這種通知消息類型的方式颖侄，即 push_channel =》ios=>type選notify鸟雏，payload是自定義數(shù)據(jù)，這個數(shù)據(jù)不必拘束unipush規(guī)定數(shù)據(jù)览祖，aps=>alert=>title,body崔慧；這種方式會顯示通知欄，客戶端點擊觸發(fā)click事件穴墅，payload即為客戶端獲取到的數(shù)據(jù)。具體的參數(shù)參考個推文檔去查看，但這幾個參數(shù)是要特別注意的玄货。注意在下發(fā)策略時皇钞，參數(shù)ios的選擇似乎已經(jīng)不重要了，可以不選擇松捉，default做選擇就行夹界。
三、客戶端的操作
這里要說明的一點是隘世，客戶端的對于消息的處理方式跟服務(wù)端選擇的下發(fā)策略及消息類型是至關(guān)重要的可柿，所以一定要跟服務(wù)端配合好，否則可能會出現(xiàn)丙者，服務(wù)端通知下發(fā)成功了复斥，但客戶端出現(xiàn)的情況會五花八門，很難找到規(guī)律去處理械媒。而這篇文章主要解決的問題就是將服務(wù)端和客戶端統(tǒng)一起來目锭，避免前后端的開發(fā)者做到懷疑人生。
第二部分介紹了服務(wù)端幾個重要的參數(shù)纷捞，接下來的介紹是建立在第二部分的基礎(chǔ)上所做的操作痢虹，所以如果服務(wù)端的選擇是其他方式，那么下面的介紹可能會出現(xiàn)其他不可預(yù)知的情況主儡。
- 1奖唯、對于個推透傳消息的處理。
如果按照UNIPUSh封裝好的數(shù)據(jù)格式糜值，對于安卓丰捷，則會新建通知欄，只觸發(fā)click事件臀玄，但對于iOS瓢阴，會觸發(fā)receive事件，所以需要客戶端 監(jiān)聽到receive事件時健无，自建通知欄荣恐，但iOS自建通知欄，還會再觸發(fā)receive事件累贤，所以這里有個aps標識叠穆。即自建通知欄的aps值為null，ios通過APNS過來的aps是有值的臼膏，所以以此來處理通知欄問題硼被，避免出現(xiàn)通知欄重建循環(huán)的問題。
代碼如下渗磅，僅供參考
plus.push.addEventListener('receive', function(message) {
console.log('receive接受消息')
console.log(message)
var data=message.payload
console.log(data)
if(message.aps){//aps下發(fā)的消息嚷硫，應(yīng)用在前臺
var options={
title:message.title
}
var localData=data
localData.type='Local' //用于做本地創(chuàng)建通知欄的標識
console.log(localData)
// 新建本地通知欄,還會觸發(fā)receive事件检访，但此時的aps為null，以此來對通知欄循環(huán)創(chuàng)建的處理仔掸；
plus.push.createMessage(message.content,JSON.stringify(localData),options)
}else if(JSON.parse(message.payload).type =='Local'){
// 本地創(chuàng)建的通知欄所觸發(fā)的事件脆贵，不做任何處理
console.log('本地創(chuàng)建的消息，不做處理')
}else{//這是個推透傳過來的消息起暮， 對iOS而言卖氨，要處理通過個推過來的透傳消息，此時的aps為null负懦，要新建通知欄進行展示
console.log('個推透傳消息過來的數(shù)據(jù)')
}
},false);
- 2筒捺、對于Apns通道的處理。
廠商通道的下發(fā)纸厉，會展示通知欄系吭。但當在消息有效期內(nèi)，打開APP時残腌，push_message中的transmission內(nèi)容還將通過個推通道傳遞給客戶端村斟，此時可在客戶端透傳回調(diào)中的參數(shù)pushmessage對象中獲取aps屬性值來片段是否是APNs下發(fā)的內(nèi)容；這個是比較關(guān)鍵的抛猫，在處理receive事件時要注意蟆盹，不然會出現(xiàn)點擊通知欄啟動App時，再次新建出通知欄展示闺金。
參考代碼如下
plus.push.addEventListener('click', function(message) {
console.log('click事件')
console.log(message.payload) //自定義過來的數(shù)據(jù)
if(message.aps){//ios點擊的廠商推送,離線情況下
console.log('ios點擊事件')
var data=message.payload
}else{//android或者是iOS的自建通知欄時逾滥，所觸發(fā)的click事件
console.log('android點擊事件')
if(plus.os.name=='iOS'){
var data=JSON.parse(message.payload)
}else{
var data=message.payload
}
}
//對data進行自身的業(yè)務(wù)處理
})
最后要說明的是，unipush的推送败匹，所涉及到的推送方案寨昙，消息類型，參數(shù)等要以unipush的文檔為主掀亩，個推的api作為參考舔哪，原因是unipush對某些參數(shù)做了處理，所以最后的結(jié)果會跟個推文檔敘述有不一致的東西槽棍。所以推送時捉蚤，客戶端常常會出現(xiàn)各種各樣的問題，但大部分關(guān)鍵因素都在于服務(wù)端的選擇炼七，所以一定要跟服務(wù)端去做好溝通缆巧，這至關(guān)重要.
這篇文章可能小白看了一頭霧水，但如果開發(fā)者正在試著做unipush的推送豌拙，那這篇文章或者對你大有用處陕悬。有問題留言評論，看到會回復(fù)的按傅。
