前面已經提到過，接收回應包的模式採用的是觀察者，在ios下面，我們可以直接使用nsnotificationcenter（nnc），nnc簡化了觀察者，將觀察物件與乙個全域性唯一的字串繫結在一起，比如我定義登入，獲取資訊，登出三個回應包對應的字串
extern nsstring *const logincommandnotification;
extern nsstring *const queryinfocommandnotification;
extern nsstring *const logoutcommandnotification;
在傳送特定的回應包給nnc之前還需要按照返回的包型別建立乙個物件，這裡使用工廠模式是比較自然的選擇，原因是隨著程式的開發，其回應包的型別肯定會不斷的修改和增加，為了不影響客戶端的**，需要將返回包抽象，由工廠模式負責生產具體返回包
這裡的返回包只需要滿足可以傳送給nnc就可以了，即滿足擁有乙個全域性唯一的字串，於是返回包的抽象類定義如下：
@inte***ce response:nsobject
@property (noatomic, copy, readonly) nsstring *notificationid;
@end
而工廠模式的工廠基類需要滿足按照不同的回應包型別生成不同的特定工廠，而各個工廠將生成不同的回應包（過載基類的方法），定義如下：
@inte***ce responsecreator
// 生成特定的工廠物件
+(responsecreator*)responsecreatorwithtype:(int)type;
// 需要子類過載的方法
-(response*)responsewithdata:(byte*)data withlength:(unsigned)len;
@end
這樣做的好處是當今後需要增加回應包的種類時，只需要新增乙個特定的工廠類繼承responsecreator，過載
-(response*)responsewithdata:(byte*)data withlength:(unsigned)len;@inte***ce responsebuilder:nsobject
@property (nonatomic, retain, readonly) response *response;
-(id)initwithdata:(byte*)data length:(unsigned)len;
-(int)build;
-(responsebuilder*)buildbyte;
-(responsebuilder*)buildshort;
-(responsebuilder*)buildunsigned;
-(responsebuilder*)buildstring;
@end
其中的build***分別解析不同型別的字段，在解析前會檢查待解析資料流的長度，成功解析後資料流的指標（迭代器）向後移動相應的長度，解析失敗將返回nil，各個子類生成器過載build方法生成各自的response
現在再回到前面的傳送回應包的地方，此時回應包已經生成，簡單的執行如下**即可：
[[nsnotificationcenter defaultcenter] postnotificationname:response.notificationid
object:response];
設計iOS平台CS架構客戶端的基本框架 傳送者
最簡單的情況，當加入乙個命令包時，判斷當前網路狀態，若可用，執行命令，若不可用，放入列表中，當檢測到網路可用時，檢查列表中是否有命令包，有的話，開始依次執行 但這裡還有乙個問題需要考慮，當網路斷開以後，與伺服器的邏輯連線是否斷開了，如果是的 相當於未登入的時候 那麼網路再次可用後，列表中的命令包對於...
CS架構客戶端軟體公升級方案
目的 概念 u 整包公升級 軟體功能進行了大範圍的變更，主版本號發生變化，客戶端需要重新安裝。u 補丁包公升級 軟體修復部分bug，功能進行了小範圍調整或變更。u 檔案公升級 軟體的個別檔案進行了細微的調整或bug修復，為最小粒度軟體公升級。框架 客戶端主要由公升級管理主程式和提供公升級功能的底層支...
客戶端架構介紹
這篇文章寫得比較中坑 記錄下 整個客戶端大體上是分為frame和game兩大部分.frame為框架層,通用於所有專案.game是遊戲層,只能寫當前專案才會用到的 frame 說是通用於所有專案有點誇大了,畢竟遊戲型別太多了,商業遊戲引擎都不敢說通用於所有遊戲,但這確實是這部分設計的初衷.其實這部分就...