典型的notification一般有兩種架構，一種是點對點，一種是發布訂閱模型。
主要討論發布訂閱模型。
主要的類如下：
topic，可以發布的話題。包含乙個topic的元資料。
subscription，乙個消費者（可以是系統或者使用者）的乙個訂閱，乙個訂閱可以訂閱乙個topic，並且可以設定一些field來filter該topic，比如只對發布與某個時間段的topic進行訂閱。
notificationmessage，乙個話題訊息的例項。
基於這個機制可以加入edm（event driven model）。加入emd是為了解決如下問題。
考慮乙個簡單的例子，有兩個系統，乙個user，乙個chat，chat是構建在user系統之上的。
當刪除乙個user時，需要考慮到對chat的影響，如user在乙個chat room中則不能刪除user或者強制該user退出該chat room等業務邏輯。傳統上這段邏輯是在user系統中的（無論是code還是通過config）。當新加乙個搭建於user之上新的系統m時，刪除乙個user的動作對新的系統m的影響又得通過改動user系統來完成。
這種方式有如下問題：
１ 系統的依賴關係是顛倒的，user作為乙個底層系統反而要呼叫高層的系統。
２ 由於１的存在，新加系統就會影響底層user系統，user系統不穩定。需要頻繁更改。
本質上乙個事件的產生對系統其它模組的影響應該由受影響的模組來決定，而不是相反。
如果採用notification機制，user在刪除乙個使用者的時候發布乙個deleteuser事件，所有對該事件感興趣的系統監聽到該事件就可以做出對應的動作。這樣就解決了上面的問題。
user系統一旦設計完畢，只要適當的定義user系統可以發布的事件，以後就不需要改動了。
當有新的系統加入，只需要訂閱它對user的哪些事件感興趣就可以把對應的邏輯放在自己的模組裡面，而不影響user系統。
由於notification系統是非同步的，有可能引入一些時序上的問題，如刪掉乙個user一分鐘後才把該user從乙個chat room中踢掉。有必要引入同步的機制來發布訂閱事件。來保證所有訂閱該事件的系統先處理各自的邏輯，然後該事件才真正發生。
Notification的命名方式及定義方法
name of associated class did will uniquepartofname notification 在傳送通知的實現檔案中，按如下方式定義 nsnotificationname const 通知名 text notification 複製 在需要接收改通知的類檔案的頂部按...
Notification 詳細運用
setcontentview r.layout.activity main notificationmanager獲取notification service final notificationmanager notificationmanager notificationmanager gets...
Notification高度問題
最近用到了自定義的notification布局 高度突然顯示不全，是因為在預設情況下低版本只有 builder.setcontent remoteviews 預設高度64 超出則顯示不全 而在api16 以上提供了bigcontenteview builder.setcustombigcontent...