Brew上的應用開發

對於MMI工程師在BREW上的開發需求，往往是以Applet為單位的。Brew上的Applet就是一個應用程式，和Application的概念類似。

大多數Applet都需要UI介面（Daemon程式的需求往往很少），他們往往需要完成一定的功能，所以有邏輯的部分，如計算機程式，就是要處理使用者輸入的資料並給出計算結果；另外，我們需要提供顯示介面和使用者進行互動，越是動感越是絢麗的介面效果越能贏得使用者的喜愛。話說回來，MMI層次上開發的應用，邏輯上大多比較簡單，不需要複雜的演算法。開發人員不必瞭解太多的底層知識和硬體知識，只要有紮實的程式語言開發功底（BREW上多數用C，也有用C++的），基本上都能寫出一般的應用來。另外，邏輯部分的代碼變動性不強，而介面效果在不同的工程間則可以相差很大，還是拿計算機程式來舉例，我們在不同的手機上看到的計算機程式，有的介面效果看上去很一般，而有的則很漂亮，但是他們完成的功能是差不多的。而對於一個公司來講，他們往往希望同一套代碼能夠適應不同工程項目上的需求，這樣可以在很大程度上減少工作量。其實這是客制化的一部分，最理想的客制化是不需要修改代碼，只要替換圖片資源、字串資源和其他一些資源如音頻資源即可達到目的。但是如果差異較大，光靠資源的替換是很難滿足需求的，還是需要修改到代碼的。我們會希望盡量少地改動到邏輯代碼，最好是只需要修改到一些資料，而不用去修改實質性的代碼，而功能邏輯上的一致性給了我們一定的可能。說了這麼多，其實是說：我們在設計的時候盡量考慮通用性，以提高代碼的複用率以及風格變換的簡易性。

目前，在Brew上開發介面，主要使用BUIW。在BUIW中，主要有Form, RootForm, Container, Widget, Decorator, Model等概念。下面簡單介紹一下這些基本概念：

Model：其實Model是一個用來存放資料的結構。它提供專門的介面讓使用者佈建Model的值或得到Model的值。另外Model還負責維護Listener List，並提供介面允許對象監聽它（將Listener加入到Listener List中）。當使用者通過Model提供的設定資料的介面改變Model的值的時候，Model就會逐個給監聽它的Listener對象發送訊息（實際上是直接調用Listener註冊的回呼函數），監聽的對象再做出相應的動作，如使用新設定進來的資料更新畫面等。其實這裡應用了設計模式中的觀察者模式（Abserver Pattern）。Model分很多種，比較常用的有Value Model, Interface Model, Vector Model等，不同種類的Model存放的資料類型不同。一般情況下，一個Widget會關聯上一種Model，並監聽Model資料的改動。

Widget：Widget是BUIW中一個最小的UI元素，可以理解成控制項，比如按鈕(Button Widget)、圖片（Image Widget）、靜態文字框（Static Widget）、可編輯文字框（Text Widget）、捲軸（Scroolbar Widget）等。它們會根據需要關聯Model，如Static Widget，它需要記錄顯示的字串內容，所以會關聯一個Value Model，而對於Image Widget，則關聯Interface Model。一般Model存放的是一些允許使用者佈建或修改的資料，比如一個Static Widget，有的時候顯示“你好”，有的時候顯示“這是一段文本”，這些不確定的可隨時修改的資料就存放在它關聯的Model中。這樣當這些資料更改的時候，Model會通知Widget你需要更新你的長相，和你的資料保持同步了。當然監聽者對於資料的改動也可以做出不同的反應。

Container：一個個Widget建立好之後，它們該怎麼擺放是一個問題。因為Widget只知道自己長什麼樣子，卻不知道自己該站在什麼地方。Container就是Widget的家，它是用來組織管理Widget的，一個個Widget會依次插入到Container合適的位置去（什麼是合適的位置？就是在這個Container中，除了相對於Container的相對位置以外，還有Z軸方向上的疊放次序，也就是說在垂直於螢幕的方向上，Widget之間還是有先後順序的，位於上層的Widget有可能擋住位於其下的Widget，這就是Z-Order的概念）。Widget本身是有大小的，Container本身也是有大小的，所謂大小就是矩形地區的意思。所以位於Container中的Widget與它的Parent Container有一定的位置關係，分別是完全位於Container中、與Container一部分相交和完全位於Container外部。位於Container外部的那部分是肯定不會被顯示出來的，而位於Container內部的那部分如果在其上沒有被其它Widget遮擋住，就可以顯示出來。Container同樣根據定位方式可以分成以下幾種：
        XYContainer，這是一種最簡單的Container，通過Widget的左上方位置和Container的左上方位置的位移量確定Widget的相對位置。這裡水平方向為X方向，向右為正，豎直方向為Y方向，向下為正（一般程式中座標系都是這麼定的）。
        PropContainer：這裡的Prop是Proportion的縮寫，也就是比例的意思。所以PropContainer實際上就是通過給它包含的Widget在空間上按照比例分配大小來實現定位的。PropContainer需要指定是在X方向上的按比例分配還是Y方向上的按比例分配，不能同時在X方向和Y方向按比例分配。PropContainer的好處是在不同解析度的情況下，它都能夠布局得很好。
       ConstrainContainer：這是通過約束來實現定位的Container，Widget可以通過相對於Parent Container的上下左右邊界的距離或者相對於Sibling Widgets邊界的距離進行定位，使用起來比XYContainer和PropContainer都來得複雜，在特殊場合會比較有用，平時一般用得比較少。
        CardContainer：CardContainer很特殊，也很簡單，因為它只考慮Z方向的疊放次序，而忽略X方向和Y方向的位置距離。它就像一疊堆放整齊的紙牌，我們只能看到最上面的一張，而位於下面的是無法看到的。前面提到的3種Container，其實我們都是在X方向和Y方向對它們進行定位，CardContainer根本不需要，所以它最簡單。CardContainer的典型應用是和TabWidget的搭配。
        所有的Container在Z方向的疊放次序都是在插入的時候指定的。另外，我們可以把一個Container看成是一個比較複雜的Widget，因為我們可以通過ISHELL_QueryInterface(, AEEIID_WIDGET,)擷取到與它相應的IWidget*，然後當做是一個簡單的Widget調用WIDGET提供的方法。正因為如此，我們可以把Container作為Child Widget插入到另一個Container中，來實現比較複雜的介面組織。也正因為如此，我們可以把Container作為WID_FORM插入到Form中，作為Form的Widget。若不是如此，介面結構將是多麼單調，所以對於Container來說，它本身可以作為Widget來使用是極具意義的。

Decorator：Decorator和Container類似，也可以往裡面裝入Widget，只是Decorator只能往裡面裝入一個Widget。它也不是用來給Widget布局的，而只是為Widget提供修飾服務的。Decorator同樣可以被看成是一個Widget，通過ISHELL_QueryInterface(, AEEIID_WIDGET,)擷取到與它相應的IWidget*。MMI在開發Applet設計Form的時候，一般不會用到Decorator。它主要在設計某些Widget的時候被用到，如Border Widget, TabWidget, ScrollbarWidget等。所以這裡也不討論其具體用法。

FORM：比較傳統的理解可以這樣認為：每個介面差不多都是一個FORM，正常情況下它包括頂上標題Title、底部的軟鍵SoftKeys和中間的那個ID為WID_FORM的Widget（前面提到過了），這個WID_FORM的Widget是Form中最重要的一部分，設計和建立Form的時候，主要在設計和建立這個Widget（前面說過多數情況下它是Container，裡面可以包含多個Widget和子Container，這種內含項目關聯性是樹形結構）。但是其實也可以這麼理解，其實Form只是儲存著一部分用來顯示的資訊，包括Title, WID_FORM的Widget和Softkeys等相關的資料；另外一部分重要的功能就是處理事件（IFORM 是直接從 IHANDLER繼承下來的，本身沒有增加任何方法），像IFORM_GetWidget(), IFORM_GetRootForm之類的介面實際上都不是IFORM虛函數表中的實現，都只是普通的inline函數。Form的很多功能包括顯示都是依賴RootForm的。

ROOTFORM：比較傳統的理解可以這樣認為：RootForm繼承自Form，基本上每個Applet（只後台啟動並執行Daemon程式除外）都會建立一個屬於自己的RootForm，負責維護應用中所有建立出來的Form。事實上，我們看到的Applet畫面就是RootForm繪製的，也可以理解成我們看到的是RootForm，因為RootForm才真正建立了