系列文章：[傳送門]
泡泡腳，寫寫部落格，規律生活，睡個好覺，待會看會書。
每天想著問題，問題只會慢慢的清晰。想著想著，慢慢模式就出來了。
推送互動模式
①② 所指的是學生群體
③ 所指的是教師
③ ：教師可以基於http 給伺服器指示，提示伺服器進行操作（push...等）；或是直接在web端進行操作
① ：學生群體接受 push，或是直接檢視某些通知，或是直接檢視富文字，或是然後點選進行（③步驟）
② ： 學生基於http 從伺服器拉去資料
1. 快速開發使用 push 服務。
2. 更多 push 服務的開發及使用功能。
建立應用，獲取 api key 及 secret key，請參考檢視應用金鑰；
把示例（android 專案）匯入 eclipse 工程；
執行示例應用；
登入管理控制台傳送通知；
手機端接收通知。
詳細資料：
下面是效果圖：
#api key : 應用標識，服務端繫結和推送都要用到
#secret key : 應用私鑰，服務端推送時用到
直接上**吧
}/*** 推送廣播訊息(訊息型別為透傳，由開發方應用自己來解析訊息內容) message_type = 0 (預設為0)
* @param
content 推送內容
*/public
static
void
pushbroadcastmessage(string content)
catch
(channelclientexception e)
catch
(channelserverexception e)
}/*** 推送單播訊息(訊息型別為透傳，由開發方應用自己來解析訊息內容) message_type = 0 (預設為0)
* @param
channelid 手機端
* @param
content 推送內容
* @param
userid 手機端
*/public
static
void pushmessagesample(string content, long
channelid,string userid)
catch
(channelclientexception e)
catch
(channelserverexception e)}}
#初始化
#推送廣播訊息(訊息型別為透傳，由開發方應用自己來解析訊息內容) message_type = 0 (預設為0)
* @param content 推送內容
#推送單播訊息(訊息型別為透傳，由開發方應用自己來解析訊息內容) message_type = 0 (預設為0)
* @param channelid 手機端
* @param content 推送內容
* @param userid 手機端
算個工具類吧 沒別的。看書咯，加油大家
路上走來一步乙個腳印，希望大家和我一起。
感謝讀者！很喜歡你們給我的支援。如果支援，點個贊。
APP的服務端
本文主要內容包括 1.緊密耦合 無線介面和web應用緊耦合，web端的修改會影響無線介面，web端的發布導致無線介面被動連帶發布，web端的bug影響無線介面的可用性，反過來也一樣，無線介面的任何變化會影響web應用。2.重複開發 3.穩定性 圖二 系統拆分示意 1.對等隔離 2.統一服務 adap...
APP程序關閉後，服務端如何推送訊息到客戶端
作為服務端的研發人員，要做好一整套的系統，就必須要了解某些客戶端的知識點，比如推送，嚴格來講，這個領域並不完全屬於客戶端。帶著問題去學習，收穫會比較多。問題日常說的推送，是否是僅僅只通過第三方通道推送到客戶端，而不包括服務端通過tcp長連線推送給客戶端，這兩種之間的關係是什麼 什麼是payload?...
移動App服務端架構設計
其實有一點還需要加上，就是對json的壓縮和加密，一來給使用者節約流量，二來防止請求被擷取破解我們的引數。具體先壓縮後加密還是先加密後壓縮這個問題看需求。看到這個架構設計時，你們可能會說如果程式入口掛了，所有的服務都不可以用了。所以這個架構的弱點在程式入口處，因此要有一 多 臺機器做負載，負載的工具...