咖啡伴侶

http://www.tkk7.com/oathleo/archive/2011/11/28/365009.html
接下來就是實現自定義菜單了

先看結果：


就實現了兩層，沒有考慮多層菜單，菜單項用簡單的button實現，感覺還行

主要的代碼如下：

flash builder4 + eclipse-jee-galileo （也就是3.5，jee集成了web插件，反正用的不多）

當我了解到Flex4那些對我諸多裨益的新特性后, 我便決定轉而使用它。剛開始的時候，我試圖利用在Flex前作中的認識和既有經驗來快速進入狀態。但很快我便發現有時即使面對一些顯而易見的問題我也不得 不求助于API文檔或者運行一些示例程序來弄清這種問題的來龍去脈。根據以往經驗，Flex3 的Halo在處理顯示列表的時候隱藏了大量的實現細節和不良設計。然而一旦你開始使用新的Spark架構后，你就得以近距離的面對這些實現細節—Halo 究竟在私底下干了什么，而且你會體會到為什么說Spark對于顯示列表的處理更為“直白”。

“elements”是一個關鍵性的問題。elements是何物？它同child是否是一回事？剛開始的時候我曾武斷的認為elements不 過是children的另一種說法。通過反復梳理組件中所有的elements和children，我發覺在新的容器類（也包括一些經過改良的傳統容器） 某些似乎是理所當然應該具備的方法消失了。如果沒有getElements()，我該如何獲取elements的數目呢？我能否把 getChildren() 的返回結果作為IVisualElement來對待。這令我十分糾結。

困擾的我于是開始認真閱讀學習API文檔，Flex的源碼以及相關的博客文章。我也曾嘗試解讀一些博主發布的關于Flex4新特性的幻燈片。然而事實證明脫離講解而孤立的看幻燈片作用相當有限。

最后，我拼湊了一些言簡意賅的示例。這些示例將帶領我了解有關elements的全新知識，告訴我那些在新的Spark容器背后發生的故事。

言歸正傳，首先從問題開始。問題一，“應該如何獲得Spark 容器的全部elements？”我曾想當然的認為是通過一個類似Flex3中的getChildren() 的方法。然而實際上我們需要通過兩個Property來達到這個目的：numElements & numChildren 。可以通過對numElements計數的循環語句配合getElementAt() 來實現遍歷容器elements或特定訪問。這種方式還比較直觀。問題二，“element和child的區別何在？”，讓我們來看看兩者的差異。

語義上，element簡單的說就是實現了IVisualElement接口的任意型別。child是指擴展了DisplayObject類的任 意型別。判斷某個組件是element還是child亦或兩者都是的關鍵在于以下幾點。UIComponent(所有Flex組件的基類：譯者注)是由 DisplayObject擴展而來，故所有UIComponent都是DisplayObject，也就是說UIComponent都是 children。UIComponent同時也實現了IVisualElement接口，因而所有的UIComponent也可以被作為 elements看待。但這并不是說所有的DisplayObjects（文中所言的DisplayObject一般指擴展于DisplayObject 的子類，譯者注）都是elements。容器中的DisplayObject對象是該無疑是容器的child。而只有當此DisplayObject對象 同時也實現了IVisualElement接口時它才是容器的element。那么對容器而言，DisplayObject什么情況下是child，什么 情況下又是element？通過示例來認識這個問題。

在首個示例中，我們使用了傳統的Halo容器（這里我們使用的Panel）。Panel擴展與DisplayObject類，所以它可以使用 addChild() 方法。進一步而言，Panel也是Container類的子類（mx.core.Container實現了 IVisualElementContainer接口），它具有addElement() 方法。Container類的IVisualElementContainer接口實現只是基于顯示列表API的門面，所以理論上它和同樣實現了 IVisualElementContainer接口的新式Spark容器具有相同的方法集合。



于是看起來我們可以任意添加children或element到容器中了。事實卻不是這樣。并非任意型別的element都能被添加（此處 element泛指實現了IVisualElement接口的類）容器中。視覺元素（VisualElements）和圖形元素 （GraphicElements）有一些區別視覺元素（VisualElements）實現了IVisualElement接口，而圖形元素 （GraphicElements）實現的是IVisualElement接口的子接口IGraphicElement。IGraphicElement 接口擴展的新特性為容器獲取信息提供了額外渠道。某些elements（圖形元素是其中之一）無法直接添加至Halo的Panel編譯器會告知“這樣的對 象需事先包裝進一個Group容器中”（實際上錯誤提示應該是在運行時出現，不關編譯器什么事：譯者注）。原因馬上揭曉。

接下來的示例中，Panel中有若干個UIComponent，其中包括另一個Halo Panel，一個Spark Panel，幾個Halo Button和幾個Spark Button，以及一個包含有子組件的SkinnableContainer（注意: 包含于SkinnableContainer的組件是只屬于SkinnableContainer的children，不是上級容器Panel的 children）。所有組件都繼承于DisplayObject，所以它們都是“children”。點擊“show children”后可以清楚的了解這一點。進一步而言，所有的組件也都是“element”，因為UIComponent實現了 IVisualElement接口。

看下一個示例。這次我們探討的容器上Spark Group。與前Halo Panel類似，Group繼承于DisplayObjectContainer，它具有addChild() 方法，它同時也實現了IVisualElement接口，所以我們可以用addElement() 方法來IVisualElement對象（elements）。而且Group也接受圖形元素（GraphicElements）,比如 spark.primitives.Rect。要知道Rect是無法直接添加到Halo Panel中的。Group是怎么做到這一點的？原因就在于Group知道如何使用一種優化的方式來呈現圖形元素（GraphicElements）。什 么意思？往下讀。

相對于典型的視覺元素（VisualElements），圖形元素（GraphicElements）與容器的關系更為緊密。其關鍵在于 IGraphicElement接口。上面曾經提到，這個擴展于IVisualElement的接口（此即圖形元素（GraphicElements）可 以通過Group的addElement() 方法來添加至其上的原因所在）。然而由于圖形元素（GraphicElements）不是DisplayObject，所以他們在被“投映”到某個作為他 父對象的DisplayObject前是無法被顯示出來的。基于這個原因，當添加一個“Rectangle”到Group時，需要有 DisplayObject來繪制這個Rectangle。更有效率一點的做法是Group盡可能的復用同一個DisplayObject來繪制多個圖形 元素（GraphicElements）。容器可以使用任何實現了ISharedDisplayObject接口的DisplayObject來繪制圖形 元素（GraphicElements）。第一個示例中的Halo Panel無法使用這種方式來繪制圖形元素（GraphicElements），編譯器會報錯：“必須將其包裝至一個合適的容器中”。而Group支持這 種優化方式，所以能添加圖形元素（GraphicElements）。

另外需要注意的一點是，有些圖形元素（GraphicElements）的繪制由Group提供DisplayObject來完成，也有的是自行 創建專屬的DisplayObject來完成繪制。IGraphicElement接口甚至允許把對象自己創建的DisplayObject交由容器管理 （換而言之就是以child形態添加的DisplayObject會以IGraphicElement的面貌來繪制自己）。

這意味著什么？這意味著在接下來的示例中，children的數目和elements的數目是不一樣的。這個示例使用了與第一個示例相同的組件集 合外，還增加了4個矩形圖形元素（GraphicElements）。所有子對象皆為IVisualElement，但不是都可以稱為children。 幾個矩形是圖形元素（GraphicElements），它們并不繼承于DisplayObject。Group不在乎這點，它知道添加 DisplayObject來繪制這些圖形元素（GraphicElements）。由于幾個矩形的尺寸和角度有所不同，所以Group會創建2個新的 DisplayObject來繪制這4個矩形。很酷吧！



現在來看示例三。我們用一個SkinnableContainer替換先前的Group。SkinnableContainer有和先前相同的子 組件集，它還能利用Skin來增強視覺效果。Skin是SkinnableContainer唯一的child。SkinnableContainer的 默認Skin類由一個矩形和一個被稱為ContentGroup的Group組成。該Group的作用在于規劃出容器內組件的添加位置。

這個示例證明了這樣的事實，即使SkinnableContainer擁有10個elements，但它只有唯一的child：它自己的 Skin。而且這個Skin也只有唯一的child：名為ContentGroup的Group組件。你也許會感到奇怪：為什么Skin的 children不是2個：其一是ContentGroup，另一個是用于繪制作為邊框的Rectangle的DisplayObject？這是因為 Skin類繼承自Group類，而Group只在它確實需要繪制其包容的圖形元素（GraphicElements）時才會添加 DisplayObject，目前的情況下不需要。Skin類具備直接在其上繪制Rect圖形元素（GraphicElements）的能力，這歸功于 Skin類的上級類Group實現了ISharedDisplayObject接口。這意味著它在需要時能作為共享的DisplayObject來繪制圖 形元素（GraphicElements）。Skin負責管理用于呈現圖形元素（GraphicElements）的DisplayObject，在當前 示例中，Skin自己就是用于繪制的DisplayObject！如果你的自定義Skin中有其它的Rectangle，并將該Skin賦予 SkinnableContainer，這種情況下Skin會判斷是否需要更多的DisplayObject來繪制額外的Rectangle。這時你可能 會發現在Skin的children列表中有更多的child。

值得注意的是，示例中SkinnableContainer，它的Skin以及Skin的ContentGroup這三者的element列表的 數目是相同的。通過SkinnableContainer的源碼可以知道，numElement的值實際上來源于與之對應的 CurrentContentGroup的numElement。所以基本上對SkinnableContainer的elements的檢索是被重定向 到它的ContentGroup上的。SkinnableContainer的Skin也有類似行為。它繼承于Group，Group的 numElement的值取自其內部的mxmlContent屬性。該屬性是一個保存了Group可視內容children的數組。這兩個屬性與 Panel的RawChildren屬性十分相似，它用于返回Panel上的所有children而不是getChildren()方法返回的僅僅你添加 到Panel上的那些。



通過以上閱讀，也許起不到撥云見日的效果。但可以讓你明白厘清以下七個類/接口的繼承結構和相互關系是十分有必要的：
1. DisplayObject
2. UIComponent
3. Container
4. IVisualElement
5. IGraphicElement
6. IVisualElementContainer
7. ISharedDisplayObject

一旦你掌握它們之間的關系，你就能明白elements 和children的不同。可以肯定的是我在某些問題的認識和闡述上存在很多謬誤之處。如果你發現了這樣的問題望不吝賜教，在評論處寫下您的正確觀點吧。

請保留：

http://www.tkk7.com/oathleo/archive/2011/09/23/android_Fruit_Ninja.html

android手勢加上了，比如左右滑動
但是用戶經常不能感受到是否滑動了， 效果如圖

對于SurfaceView，事件返回值貌似沒有什么作用


有興趣的朋友可以試試上面的代碼

對于工業生產現場來說，過程實時數據變化很快，數據存儲量很大，如果每個數據都存儲，在經歷不長時間后就會占據大量磁盤空間。一般來說，工業生產的很多數 據是線性變化的，或者是符合某種規律變化的，如果數據庫能夠根據某些條件進行判斷，將某些可忽略的數據，不進行存儲，而當需要查找該數據時，可以通過線性 或步進插值計算出來，就可以大幅度提高存儲效率，同時節約磁盤空間。

    上述描述的情況就是在線數據壓縮。所謂數據壓縮，就是丟棄那些對于在準確重現現場設備（以下稱為測點）歷史曲線時不是必需的測點數據。

    當今，非常流行的數據壓縮算法是由美國OSI軟件公司研發的旋轉門壓縮算法，此算法已經成功地運用在了PI實時數據庫系統當中，此算法主要針對的對象是浮點數數據類型的數據。

    旋轉門壓縮算法分析：

• 部分原文：

    With the swinging door algorithm, a value is stored if a straight line drawn between the last stored value and the next value does not come within the compression deviation specification of all the intermediate points. Two slopes are required to carry out this test. The following figure shows the slopes as they are initialized after a value is stored:

 

Figure1 – Swinging Door slopes after recording a value

    The dotted lines are the two slopes. Let the compression deviation specification be 8. One of the lines is drawn from the last recorded value plus 8 through whichever value maximizes the slope of the line. This is the top dotted line in Figure 1. The other dotted line is drawn from the last recorded value minus 8 through whichever value minimizes the slope of the line. The third line is drawn between the last recorded value and the new value. This is the solid line in Figure 1. The previous value is recorded if the slope of the top dotted line is greater than the slope of the solid line or the slope of the solid line is greater than the slope of the bottom dotted line.

    The algorithm ensures that each discarded value falls within the compression deviation specification of the solid line. The compression deviation specification is also the maximum error in a trend of archived values. The next figure shows the lines after four more values have been received.

    The next figure shows the arrival of a value which causes the previous value to be recorded.

 

Figure 2 – Recording a new value

• 中文解釋：

    對于旋轉門壓縮算法來說，先由上一保存數據項和當前數據項來畫出一條直線（在二維坐標圖上），如果待保存數據項不在當前數據項和上一保存數據項的壓縮偏差范圍之內，則待保存數據項被保存。實驗中還需要兩條斜線（旋轉門）。圖1（Figure 1）中顯示了這兩個旋轉門，傳入系統的第一個測點數據項會直接被保存，否則因為數據庫中沒有被保存的測點數據項就無法確定旋轉門了。

    壓縮偏差是旋轉門壓縮算法中的重要參數，它是人為設定的絕對誤差值，可以簡單的理解為在絕對誤差范圍內，數據被壓縮掉，在絕對誤差范圍外，數據不被壓縮。

    另外，算法的實現還需要計算以下幾個斜率：

   （1）上斜率 K1 =（當前數據項數值 -（上一保存數據項數值 - 壓縮偏差））/（當前數據項時間 - 上一保存數據項時間）

   （2）下斜率 K2 =（當前數據項數值 -（上一保存數據項數值 + 壓縮偏差））/（當前數據項時間 - 上一保存數據項時間）

   （3）中間斜率K =（當前數據項數值 - 待保存數據項數值）/（當前數據項時間 - 待保存數據項時間）

    通過計算壓縮變量上一保存數據項和當前數據項與待保存數據項的斜率來進行壓縮控制。即：

    如果 K2≤K≤K1，待保存數據項被壓縮。

    如果 K<K2或者K>K1，待保存數據項被存儲。

 

算法實現流程如下：

1.第一個數據項處理：直接存入數據庫。

2.第二個數據項處理：計算前后兩數據項的上下兩個斜率，并將上下斜率作為后續判斷的依據。

3.兩個數據項以上處理：計算上中下斜率，進行判斷：（1）如果沒有通過旋轉門壓縮檢測，把上一個數據項信息保存，并將新的上下斜率保存作為后續判斷的依據；（2）如果通過旋轉門壓縮檢測，則不需要保存。

4.循環執行第三步中的壓縮條件判斷。

    start = now;
    upgate=mem+E; 
    downgate=mem-E; 
    k1=-10000; 
    k2=-10000; 
    for(;;) {
     now++;
     mem_old = mem;
     fread(&mem, sizeof(float), 1, fd);
     if(fabs(mem-upgate)>0.001){
      if((mem-upgate)/(now -start)>k1) k1=(mem-upgate)/(now-start); 
       else {
        now=now++;
        fwrite(&mem_old, sizeof(float), 1, fd1);
        break;
       }
      }
      if(fabs(mem-downgate)>0.001){
        if((downgate-mem)/(now-start)>k2) k2=(downgate-mem)/(now-start); 
       else {
        now=now++;
        fwrite(&mem_old, sizeof(float), 1, fd1);
        break;
       }     
      } 
   if(now == maxnum-1) {
        break;
      }
    }

http://cnbeta.com/articles/154387.htm

世上最偉大的十個公式，薛定諤方程排名第六，質能方程排名第五

leoliyuan發布于 2011-09-08 08:49:56|4126 次閱讀 字體：大 小 打印預覽

英國科學期刊《物理世界》曾讓讀者投票評選了“最偉大的公式”，最終榜上有名的十個公式既有無人不知的1+1=2，又有著名的E=mc2；既有簡單的-圓周公式，又有復雜的歐拉公式……

從什么時候起我們開始厭惡數學？這些東西原本如此美麗，如此精妙。這個地球上有多少偉大的智慧曾耗盡一生，才最終寫下一個等號。每當你解不開方程的時候，不妨換一個角度想，暫且放下對理科的厭惡和對考試的痛恨。因為你正在見證的，是科學的美麗與人類的尊嚴。

 

 

這公式賊牛逼了，初中學到現在。目前，人類已經能得到圓周率的2061億位精度。還是挺無聊的。現代科技領域使用的-圓周率值，有十幾位已經足夠了。如果用 35位精度的-圓周率值，來計算一個能把太陽系包起來的一個圓的周長，誤差還不到質子直徑的百萬分之一。現在的人計算圓周率，多數是為了驗證計算機的計算 能力，還有就是為了興趣。

 

No.9 傅立葉變換（The Fourier Transform）

 

 

這個挺專業的，一般人完全不明白。不多作解釋。簡要地說沒有這個式子沒有今天的電子計算機，所以你能在這里上網除了感謝黨感謝政府還要感謝這個完全看不懂的式子。另外傅立葉雖然姓傅，但是法國人。

 

No.8 德布羅意方程組（The de Broglie Relations）

 

 

這個東西也挺牛逼的，高中物理學到光學的話很多概念跟它是遠親。簡要地說德布羅意這人覺得電子不僅是一個粒子，也是一種波，它還有 “波長”。于是搞啊搞就有了這個物質波方程，表達了波長、能量等等之間的關系。同時他獲得了1929年諾貝爾物理學獎。

 

No.7 1+1=2

這個公式不需要名稱，不需要翻譯，不需要解釋。

 

No.6 薛定諤方程（The Schr&ouml;dinger Equation）

 

也是一般人完全不明白的。因此我摘錄官方評價：“薛定諤方程是世界原子物理學文獻中應用最廣泛、影響最大的公式。”由于對量子力學的杰出貢獻，薛定諤獲得1933年諾貝爾物理獎。

另外薛定諤雖然姓薛，但是奧地利人。

 

No.5 質能方程（Mass–energy Equivalence）

 

 

好像從來沒有一個科學界的公式有如此廣泛的意義。在物理學“奇跡年”1905年，由一個叫做愛因斯坦的年輕人提出。同年他還發表了《論動體的電動力學》——俗稱狹義相對論。

這個公式告訴我們，愛因斯坦是牛逼的，能量和質量是可以互換的。副產品：原子彈。

 

No.4 勾股定理/畢達哥拉斯定理（Pythagorean Theorem）

 

 

做數學不可能沒用到過吧，不多講了。

 

No.3 牛頓第二定律（Newton's Second Law of Motion）

 

 

有史以來最偉大的沒有之一的科學家在有史以來最偉大沒有之一的科學巨作《自然哲學的數學原理》當中的被認為是經典物理學中最偉大的沒有之一的核心定律。動力的所有基本方程都可由它通過微積分推導出來。對于學過高中物理的人，沒什么好多講了。

 

No.2 歐拉公式（Euler's Identity）

 

 

這 個公式是上帝寫的么？到了最后幾名，創造者個個神人。歐拉是歷史上最多產的數學家，也是各領域（包含數學的所有分支及力學、光學、音響學、水利、天文、化 學、醫藥等）最多著作的學者。數學史上稱十八世紀為“歐拉時代”。歐拉出生于瑞士，31歲喪失了右眼的視力，59歲雙眼失明，但他性格樂觀，有驚人的記憶 力及集中力。他一生謙遜，很少用自己的名字給他發現的東西命名。不過還是命名了一個最重要的一個常數——e。

關 于e，以前有一個笑話說：在一家精神病院里，有個病患整天對著別人說，“我微分你、我微分你。”也不知為什么，這些病患都有一點簡單的微積分概念，總以為 有一天自己會像一般多項式函數般，被微分到變成零而消失，因此對他避之不及，然而某天他卻遇上了一個不為所動的人，他很意外，而這個人淡淡地對他說，“我 是e的x次方。”

這個公式的巧妙之處在于，它沒有任何多余的內容，將數學中最基本的e、i、pie放在了同一個式子中，同時加入了數學也是哲學中最重要的0和1，再以簡單的加號相連。

高斯曾經說：“一個人第一次看到這個公式而不感到它的魅力，他不可能成為數學家。”

 

No.1 麥克斯韋方程組（The Maxwell's Equations）

積分形式：

 

微分形式：

 

任何一個能把這幾個公式看懂的人，一定會感到背后有涼風——如果沒有上帝，怎么解釋如此完美的方程？這組公式融合了電的高斯定律、磁的高斯定律、法拉第定律 以及安培定律。比較謙虛的評價是：“一般地，宇宙間任何的電磁現象，皆可由此方程組解釋。”到后來麥克斯韋僅靠紙筆演算，就從這組公式預言了電磁波的存 在。我們不是總喜歡編一些故事，比如愛因斯坦小時候因為某一刺激從而走上了發奮學習、報效祖國的道路么？事實上，這個刺激就是你看到的這個方程組。也正是 因為這個方程組完美統一了整個電磁場，讓愛因斯坦始終想要以同樣的方式統一引力場，并將宏觀與微觀的兩種力放在同一組式子中：即著名的“大一統理論”。愛 因斯坦直到去世都沒有走出這個隧道，而如果一旦走出去，我們將會在隧道另一頭看到上帝本人。

launchmode4種模式：
1，standard：
如果從A跳到A，intent5次，task里5個activity；
2，single Top:
如果從A 跳B,再從B跳A，如果此時棧頂為A，則不創建新實例，直接把Intent給A，但如果棧頂不是A，則還要創建A的實例
3，singleTask
如果從A跳B，再從B跳A，無論是否棧頂棧底，只要A在，則將Intent給A，不會創建A的新實例；
4，singleInstance
不同于前3種模式，前3種只是在同一個task的，而實例化的策略不同。這種模式下的activity會單獨存在一個task下。
現成的例子是google地圖。比如我有一個應用是導游方面的，其中調用的google地圖Activity。那么現在我比如按home（后臺 activity onstop，back是finish）鍵，然后到應用列表中打開google地圖，你會發現顯示的就是剛才的地圖，實際上是同一個Activity。
如果使用上面三種模式，是無法實現這個需求的。google地圖應用中有多個上下文Activity，比如路線查詢等的，導游應用也有一些上下文Activity。在各自應用中回退要回退到各自的上下文Activity中。
總結：
1 2：會創建新實例
3 4：不會創建新實例
123：activity的taskid相同
4：activity的taskid不同。被分到單獨一個task中

    popupWindow.setWidth(LayoutParams.WRAP_CONTENT);               
    popupWindow.setHeight(LayoutParams.WRAP_CONTENT);