Skip to main content

[Flex] pureMVC MultiCore with Modules



跟 pureMVC MultiCore & Modules 相處幾天後發現了一個簡易串接流程能互相接聽與發送訊息(其實還有更爛的方法...XD 只是為了能自動化改用這個...)。不能說下面分享的是很好的解法,只能說它應該是個蠻容易理解外加還沒發現有啥嚴重 bug 的方法...

做法其實很簡單,就是 System facade 在 load Module 時,建立一個 Module 專用的 Mediator 並且將 Module 指定給它為其 viewComponent,就可以透過這個 Mediator 串接起來,這樣不管有多少個 Modules 都可以對應一個 ModuleMediator 來處理。這個串接的 Mediator 特別的地方就是它做了雙向註冊,如同轉接國際電話的接線生,因為跟兩邊都有關係,所以可以接聽跟發送兩邊的 Notifications。

請看 Live Demo(Demo 頁點選滑鼠右鍵可以看 source code )

  1. ModuleManager 是寫在 Main.mxml 內而不是跟著 ModuleCommand 一起,原因是在 Flex 3.2 SDK 之後版本為了解掉更嚴重的 Module load & unload memory leak bug.. IModuleInfo 是區域變數的話,就容易被 GC 掉...這不是個 bug 喔!(Adobe 講的...也不知道是真的假的...沒特別研究...)
  2. Module 沒有真正 unload 掉,反正它會反覆載入,就不真的移除了...所以請自助...
  3. System facade 只用 ModuleCommand and ModuleMediator 處理所有的外部 Modules,所以重點都在這兩個 class 內...XD
  4. 為了輸出專案時不會將 Module 一併打包和要統一命名 Module's facade,所以外部的 Module 都需要 implements IModuleComponent interface。
  5. (Edit: 3/4/2009) 由於 System facade 掌握著 Module facade 的名字,如果 System message 需要傳到特定的 Module 也可以很簡單的實現...=P

Comments

  1. 感謝分享,最近剛好在寫pureMVC跟module的溝通,這個範例可學到不少東西

    ReplyDelete
  2. Erin大有試過fabrication嗎?
    http://code.google.com/p/fabrication/
    用這個寫multicore版很方便也很簡潔呢^^

    ReplyDelete
  3. 喔喔~ 有時間來研究一下...=P,謝謝分享捏~~我就是喜歡可以簡潔的寫法...XD

    ReplyDelete
  4. Erin姐姐, 你寫的文章, 好有深度
    有基礎的PureMVC文章可以介紹的嗎

    ReplyDelete
  5. 奶綠哥哥...要基礎的pureMVC文章到他的官網上一堆喔~~^^*

    ReplyDelete
  6. PUREMVC 我也想摸摸看了~~@@

    不過可惜能力還不夠

    我這篇引用到你文章~ 先謝謝了 ^^

    http://blog.corausir.org/programing/ausir-855


    corAusir 程式逗設計 - 提供設計資料與程式設計 -

    http://blog.corausir.org/

    ReplyDelete
  7. 正可惜,demo页面查看不了了。。

    ReplyDelete
  8. Demo 頁還是活的好好的呦...看你用簡體的...所以你可能要透過代理才可以看喔!

    ReplyDelete
  9. 我在公司打开了,这个确实不错,不过不知道跟fabrication有什么区别?最近正在用pureMVC做项目,希望交流下。

    ReplyDelete
  10. 關於 Fabrication 我並沒有花很多時間下去研究,它是用一個加強版 pureMVC 架在原本的架構上,跟一般 pureMVC的工具包不同,它提供完整的架構,所以實作幾乎是綁定在 Fabrication 上...就看你自己選擇囉..我本身是比較愛亂加亂改東西...所以喜歡自己組合工具包...=P

    ReplyDelete
  11. 最近在挑選pureMVC的版本時,遇到了大決擇,
    練習時,使用pureMVC standard的版本做了一個簡單的AddressBook的維護。
    但要實作的系統,是像一個有menubar,多個功能的維護系統。(一般的Windows應用程式)。
    但不知道要用multicore的版本或是standand的版本。
    是不是有什麼經驗可以分享,在挑選版本時的考量呢?
    (目前多個功能,都是用MDI Windows的方式,若menubar被click了,
    再去new 那個MDI Window,這樣的話,是不是跟本就不需要多個ApplicationFacade,
    也不會把多個功能拆成多個Module)

    ReplyDelete
  12. 關於 pureMVC multicore 版本應用程式的開發我最近會找個時間分享一下... 其實 pureMVC standard 就很夠用,但是為了整合部分 modules view 所以使用 multicore 的版本,寫到目前為止我是覺得 shared library 比 module 好用...

    ReplyDelete
  13. 謝謝您的回覆,本來是想使用multicore + pipe + fabrication來做~~想說如果不用module的話,就如你所說的,改用standard來做即可~~

    ReplyDelete
  14. If you need the source code, you can email me.

    ReplyDelete

Post a Comment

Popular posts from this blog

PureMVC 我也會 [0]

最近感覺 PureMVC 又熱了起來,也剛好好久沒有更新文章了, 就順便將去年底做的企業內訓 PureMVC 課程部分整理寫出來, 要講 PureMVC 當然要先從啥是 MVC 講起: Model-View-Control 出處: 維基百科 MVC ,大概節錄一段: (控制器Controller)- 負責轉發請求,對請求進行處理。 (檢視View) - 介面設計人員進行圖形介面設計。 (模型Model) - 程式設計師編寫程式應有的功能(實作算法等等)、數據庫專家進行資料管理和數據庫設計(可以實作具體的功能)。 其實到 Flash 的世界來講,Model and Control 都是由 .as 處理,而 View 便是 .fla+.as ,為了要鬆綁之間的關係,Event 機制就相當重要。其實每個人對 MVC 的最佳解釋都不同,真的要多練習才會有所領悟。 簡單來說: Model = 餐廳廚房 data: 西餐類 action:依照點菜單做餐點 action: 做完餐點就是將餐點放在出菜口按下通知鈴等服務生來 Control = 服務生 action: 聽到大門歡迎鈴就要說「歡迎光臨」 action: 看到客人揮揮手要去收點菜單 action: 聽到廚房通知鈴看是哪桌的餐點去送菜 View = 餐廳外場 view: 田園式的西餐廳裝潢 action: 客人進門會有歡迎鈴 action: 客人揮揮手叫服務生過來服務,是哪個服務生都無所謂,重點只要會收點菜就行了。 action: 客人收到餐點準備開動 當餐廳要改成外炒店,這時候只需要將大廚換成會中餐廚師,其出的菜就是中式快炒。 當餐廳外場由田園式外觀重新裝潢成華麗感夜店風,其進門的客層也會有所不同。 重點就是當你換掉一個地方時,對其它的部份不會造成太大的影響或者根本無所謂,這就是 MVC 所講求的境界... 一般來說,小專案有沒有必要使用 MVC 就是由各位自己判斷了,當你習慣將程式切分開來,發現 debug 不是一件痛苦的事情時,這時候有沒有強制使用 MVC 倒不是重點,因為你已經養成良好的撰寫習慣。但是開始接觸大型專案配合 team work 時,在沒有一個共用的核心框架前提下,這個專案開發到最後一定會是一個多手多腳的怪物,共用核心框架的價值就在這邊展現,這

[Swift3] weak 與 unowned 關鍵字

雖然在 Swift 中看起來"很像"是不需要煩惱內存管理的問題,不過實際上它還是遵循著自動引用計數 (ARC) 的規則,當一個物件沒有被其他對象引用時會自動被銷毀,如果三魂七魄沒有完全回位的話,就會有個靈體留在現世的空間裡,最經典的範例如下: 閉包(Closure)引用 classClassA { typealias Complete = ()->() var name : String var onComplete : Complete? init(_ name: String){ self.name = name print("Hello I am \(self.name)") onComplete = { print("\(self.name): onComplete!") // --> 閉包引用 self, 計數 + 1 } } deinit { print("deinit: \(self.name)") } } var a : ClassA? = ClassA("A") // --> 引用計數 + 1 a = nil // 2-1 = 1 還剩下 1 所以沒辦法銷毀 ---output------- Hello I am A 由於這邊的 onComplete 宣告為 Optional, 正確的做法要連同 onComplete 一起刪除才可以被回收,若不是 Optional 則會進入無法回收狀態: var b : ClassA? = ClassA("B") b?.onComplete = nil // --> 還好是 Optional 可以設成 nil 計數 - 1 b = nil // 計數 = 0 所以被回收 ---output------- Hello I am B deinit: B 但是做人不需要煩惱太多,這時候就出動 unowned 關鍵字讓物件可以順利被回收: onComplete = { [unowned self] in print