Google 真的太威了…

安裝說明:
http://code.google.com/apis/analytics/docs/tracking/flashTrackingSetupFlex.html#getTheLibrary
取得library:
http://code.google.com/p/gaforflash/

注意:
GA tracking 的結果，不是及時的!
測試不是能夠直接看到結果的，必須等待幾個小時再到Google Analytics網站看報告。

本篇文章來自MAX2009的session:
How Not to code FLEX

演講者主要說明何謂壞程式碼(bad code)，但也說壞程式碼不一定不好，只要你確定能盡快回來改正他。那何謂壞程式碼?

• Container 元件的誤用：Container元件諸如Box, Canvas, Tile等等，他們的原本目的都是: 排列裡面的子元件。因此只要你不是拿來排版或甚至沒有給予它任何的子元件，就違背原本用意了。
  例子:
  <mx:TextInput/>
  <mx:VBox backgroundImage="blah.png" borderStyle="solid"/> <!-- 你看, 沒有小孩的容器元件-->
• ListBase 元件的誤用: List, TileList, DataGrid 都是用來針對列表物件的選取、排序、renderer回收而生，因此，當你想要製作的元件並不需要這些功能，就不該採用List來處理。
• local model binding: 避免直接將值給UI元件，盡量用local model binding來處理。(按:此方法還可避免元件初始化延遲所帶來的問題)
  ex:
  <mx:script>
  
    //這樣是不好的
    function test():void
    {
       myLabel.text = "hello";
    }
  
  </mx:script>
  <mx:Label id="myLabel"/>
  <mx:Script>
  //用local model binding.
  [Bindable]
  private var helloText:String = "hello";
  </mx:Script>
  <mx:Label id="myLabel" text="{helloText}"/>
• 別把local view event 交由非常上層的元件處理。(按:這裡必須搭配cairngorm microframework 來解釋 )
  元件與元件之間的訊息傳遞，如果能在local就解決，便盡量不要拋到上層的command-frontcontroller 去處理然後又繞回來”原本的元件”。以後維護會很辛苦。
• 不適當的容器元件使用方法:
  如果你發現你的容器元件裡面只有一個子元件(child)，那可能有問題。

• Two dots and you are out.
  兩個參照你就出局囉!

  如果你的程式碼需要進入非常多的子元件，那就有問題了。如下:

  var hey:String = myBox.thisBox.thatBox.rightLabel.text;

  這是一個本質上的問題，應該要封裝這些子元件，若其他元件需要存取裡面的值，應該要透過Event(帶資料出來) 來幫你。

• 自以為的聰明寫法並不好。
  這種情況會發生在複雜的binding寫法，像是:
  <mx:Button id="btn" enabled="{ isCheck &amp;&amp; ( firstBtn.enabled &amp; !secondBtn.enabled) &amp;&amp; (thirdBtn.enabled|| feelGood) }"/>

  應該要用function 去處理這些binding 邏輯:

  <mx:Script>
  private function getEnabled( a:Boolea , b:Boolea , c:Boolean , d:Boolean , e:Boolean ):Boolean
  {
  //邏輯應該在這裡描述啦:
  return a && (b&&!c) &&(d||e);
  }
  </mx:Script>
  <mx:Button id="btn" enabled="{ getEnabled(isCheck,firstBtn.enabled,secondBtn.enabled,thirdBtn.enabled,feeGood) }"/>

因應 XP 開發手法的趨勢，Adobe也推出FlexUnit: Unit test framework。但我個人覺得，Flex主要是關連到UI的，而UI的測試，光靠FlexUnit不夠的，用人測最直接。然而，通常你找不到那個人。

下載地點：Adobe open source project: Flex unit

何謂Unit Test? 簡單地來說：就每個Method當成一個unit(單位)，測試之。在XP的開發過程中，是測試導向開發，什麼是”測試導向”? 就是：每次要寫新功能的時候，不是先寫功能的運作方法，而是先寫『測試該功能的程式』，換言之，我們要以”通過測試”為方向，去開發新功能的程式。因此，我們的開發流程往往是: 先寫空白的功能程式，譬如一個空的方法: getSomeResult()，然後先寫測試碼(test case)，像是: testGetSomeResult() 然後寫上我們”預期的”測試結果，立刻跑一次test runner，當然，不會過關，立刻回頭撰寫getSomeResult()內容，讓它正確通過test case，那麼getSomeResult()即開發完成 。(見下方的步驟)

這樣的好處，除了確保開發出來的功能可以通過測試；往後的重構(refactor)或是需求變更，都可以再次把unit test 列出來跑一次，確保原來的功能沒有毀掉。
使用步驟：

1. 建立TestRunner
2. 寫TestCase/TestSuite並加入TestRunner
3. 跑TestRunner
4. 看結果，修改原始碼，回到(2)

例子：

特別要強調的是，針對Event處理的測試要怎麼寫? 因為Event發出的時間往往有時間差，並不即時。FlexUnit體貼地加上了一個addAsync() 的方法，幫助我們測試event listeners。寫法如下:

Adobe 官方寫的 AS 程式撰寫規則
http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions