最贊回答 / 王飛0123
思路: 服務(wù)器端通過map集合存儲 key value ; 客戶端模擬 mina通信協(xié)議完成 別名數(shù)據(jù)傳遞 ;最后在服務(wù)器端模擬發(fā)送通知的邏輯 ?完成!希望對你有幫助!
2015-07-22
最新回答 / 王飛0123
這個問題 我估計你是被繞進(jìn)去了, 如何標(biāo)識用戶 是你的app 里面用戶可以自己來確定的 ,或者你可以后臺根據(jù)大數(shù)據(jù)分析出該用戶的興趣,區(qū)域 直接找到這些用戶 進(jìn)行批量推送!?
2015-07-22
太好了,成功了。期待繼續(xù)出這么好的課程?。海╇x線消息重新發(fā)送也當(dāng)成普通消息就好,發(fā)送完了客戶端回執(zhí)成功也會再次被刪除的。不需要馬上刪除。
2015-07-10
用synchronized鎖住xmppManager對象,但wait和notifyAll所鎖住的xmppManager好像不是同一個對象吧
2015-07-08
針對這篇課程的一個筆記http://blog.csdn.net/chenzujie/article/details/46674831
2015-06-28
郭神,這一集最后的處理方式,增加shouldSave地方有個邏輯錯誤,當(dāng)用戶從離線到上線重新發(fā)送的notification根本沒有做入庫操作,因此客戶端收到該notification發(fā)送DevilerConfirmIQ給服務(wù)器端的時候,服務(wù)端就刪不了對應(yīng)的數(shù)據(jù),因為數(shù)據(jù)庫沒有這條數(shù)據(jù)。
2015-06-28