Android

Android中對組合模式的應用，可謂是泛濫成粥，隨處可見，那就是View和ViewGroup類的使用。在android UI設計，幾乎所有的widget和布局類都依靠這兩個類。組合模式，Composite Pattern，是一個非常巧妙的模式。幾乎所有的物件導向系統都應用到了組合模式。1.意圖將對象View和ViewGroup組合成樹形結構以表示"部分-整體"的階層(View可以做為ViewGroup的一部分)。組合模式使得使用者對單個對象View和組合對象ViewGroup的使用具有一致性。

Android的廣告平台是很多的，各市場對各平台的接受程度是不一樣的，Android的開發人員如果想整合廣告基本要考慮下面兩個問題：(1)整合什麼廣告，會賺錢？(2)整合什麼廣告，不會被市場拒絕？最終的結果往往是折中的。第一個問題是廣告平台的判斷問題，我沒有發言權去評論，本文主要是針對第二個問題展開。解決方案就是打包應用的不同廣告平台版本，本文接下來逐一展開相關話題。1.

觀察者模式，是一種非常常見的設計模式，在很多系統中隨處可見，尤其是涉及到資料狀態發生變化需要通知的情況下。本文以AbstractCursor為例子，展開分析。觀察者模式，Observer Pattern,是一個很實用的模式，本人曾經接觸到的各種平台以及曾經參與項目中列印模板解譯器中都用到了此模式。1.意圖定義對象間的一種一對多的依賴關係，當一個對象的狀態發生改變時，所有依賴於它的對象都得到通知並被自動更新。熱門詞彙：依賴 發布-訂閱 事件 通知 更新

單例模式，可以說是GOF的23種設計模式中最簡單的一個。這個模式相對於其他幾個模式比較獨立，它只負責控制自己的執行個體化數量單一(而不是考慮為使用者產生什麼樣的執行個體)，很有意思，是一個感覺上很乾淨的模式，本人很喜歡這個模式。android中很多地方都用到了單例模式，本文以IME管理者InputMethodManager為例，展開分析。單例模式，Singleton

模板方法，和單例模式是我認為GOF的23中最簡單的兩種模式。但是我個人對模板方法的經典思想特別推崇，雖然模板方法在大對數情況下並不被推薦使用，但是這種通過父類調用子類的方法，使用繼承來改變演算法的一部分，是物件導向的一種基本認識。打比方說父親有很多理想，就行醫救人吧，但是父親醫術不行，只能靠兒子，兒子長大後遵從父親大志，春風拂面，妙手回春，實現了父親的理想，兒子做的事情早在出生前就定下來了，是父親之前久定好的模板。認識到模板方法的這種思想，父類可以讓未知的子類去做它本身可能完成的不好或者根本完成

備忘錄模式，在工作代碼中，要麼不用，要麼經常用到。舉個例子，程式員喜歡寫代碼，coding,coding,這個時候它的狀態是很high，但是每隔一段時間總要去上一下廁所，狀態是放鬆relax，上完測試歸來後又恢複到high的狀態，繼續coding。這個過程對於身後的老闆來說，它預設同意你離開去上廁所，他也希望你回來後恢複high的狀態繼續工作，但是你在這個過程中上廁所的這件事，他是不需要瞭解細節的，而且做為當事人你也不希望他瞭解你上廁所的細節吧，你只要回來後恢複激情high著繼續工作，老闆應該就

享元模式,給我的感覺就是對象池，緩衝單例對象。java中的享元模式最經典的例子就是String類了，還有一個最容易理解的就是word文檔字元共用的例子，也是享元模式的經典應用。本文對android中的sql編譯類SQLiteCompiledSql說明，展開分析，也是很容易理解的一個例子，其實，android SDK中必然有很多地方需要用到享元模式。享元模式，Flyweight  Pattern,說的嚴重點，一些程式如果不使用享元模式的話，根本不能使用物件導向的方法實現，對象會多的撐爆你的記憶體：

     JSON資料格式，在Android中被廣泛運用於用戶端和網路(或者說伺服器)通訊，非常有必要系統的瞭解學習。     恰逢本人最近對json做了一個簡單的學習，特此總結一下，以饗各位。     為了文章簡明清晰，盡量多列點，少廢話。     參考文檔：http://www.ietf.org/rfc/rfc4627.txt?number=46271.JSON解析   

命令模式，在.net，java平台的事件機制用的非常多，幾乎每天都與之打交道。android中對我印象最深的就是多線程多進程的環境，所以必然大量使用到Runbable,Thread,其實用的就是最簡單的命令模式。命令模式，Command Pattern，把請求封裝為一個對象，多麼巧妙的一個說法啊。1.意圖將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進行參數化，對請求排隊或記錄請求日誌，以及支援可撤銷的操作。熱門詞彙：動作 事物 請求封裝 排隊 打包

本來這篇文章想併到上篇Android學習系列(16)--App列表之圓角ListView中的，但是若是如此就讓大家錯過一篇新的好的文章，著實可惜。上篇中我們使用shape，corners，gradient實現了一個漸層的圓角效果，但是在完文之後的實踐中，我發現有時效果不甚滿意，選中和放手的事件監聽沒有去正確的判斷，然後漸層效果也比較單一，效能也覺得不是很快，不如用圖片來的驚豔和迅速，又懶的去改原來的，所以我又用圖片來實現一個更完美的效果。1.

本文算是一篇漫談，談一談當前幾個流行應用的主介面布局，找個經典的布局我們自己也來實現一個。不是為了追求到底有多難，而是為了明白我們確實需要這麼做。 走個題，android的UI差異化市場依然很大，依然值得去挖掘。 鑄就經典，是為了超越經典！下面我們以下面10個應用來分析比較它們的主介面：1.QQ20112.新浪微博3.鳳凰周刊4.小米讀書5.6.太平洋電腦網7.360衛士8.Camera3609.福士點評網10.挖財1.QQ2011QQ應用最新版本QQ2011

策略模式其實特別簡單（聽到這句話，大家是不是心裡一下子放鬆了？）。比如排序，官方告訴大家我這裡有一個排序的介面ISort的sort()方法,然後民間各盡其能，實現這個排序的方法：冒泡，快速，堆等等。這些方法就是“不同的策略”。然後，某個模組下，需要一個排序方法，但是暫時不能指定具體的sort方法(出於擴充的考慮)，就需要使用ISort介面了。最後，具體什麼情境下，傳入什麼具體的sort方法，實現靈活的排序。這就是策略模式！下面，我們分析Android中的動畫是如何使用原則模式的。1.

對於android開發人員來說起，適配器模式簡直太熟悉不過，有很多應用可以說是天天在直接或者間接的用到適配器模式，比如ListView。ListView用於顯示列表資料，但是作為列表資料集合有很多形式，有Array，有Cursor，我們需要對應的適配器作為橋樑，處理相應的資料（並能形成ListView所需要的視圖）。正是因為定義了這些適配器介面和適配器類，才能使我們的資料簡單靈活而又正確的顯示到了adapterview的實作類別上。適配器模式，Adapter

git是免費的開源的分布式的版本控制系統。我說的直白點，要強調的點是每個git

建造者模式把構造和表示分離開，根據客戶需求生產一個相應的對象。本來呢，我們根據Builder介面實現不同的具體的ConcreteBuilder，就可生產不同的對象了。但是，下面例子的只有一個Builder，所以也沒有介面Builder，也沒有其他的ConcreteBuilder。但是我今天要講的例子太簡單，簡單到都不覺得是建造者模式，但是又有建造者模式的感覺。1.

CV一族，應該很容易理解原型模式的原理，複製，粘貼完後看具體情況是否修改，其實這就是原型模式。從java的角度看，一般使用原型模式有個明顯的特點，就是實現cloneable的clone()方法。原型模式，能快速複製出一個與已經存在對象類似的另外一個我們想要的新對象。1.意圖用原型執行個體指定建立對象的種類，並且通過拷貝這些原型建立新的對象。熱門詞彙：複製 深拷貝 淺拷貝2.結構圖和代碼它的結構圖非常簡單，我們以Intent為例子：Intent的clone方法非常簡單： @Override

本來想下載Android官方原始碼，沒想到android.git.kernel.org維護，不能訪問，非常遺憾，並因此還鬱悶了幾天。 後來轉投MIUI,沒找到它的源碼，不知道它的"超過40萬人社區Team Dev"是什麼意思，求解具體開發人員幾何，都是誰？後來一想，竟然忘記了CyanogenMod這茬，這可是的的確確的開源啊，My Phone一直也在用CyanogenMod系統的，感覺確實不錯。1.準備我得環境如下，VirtualBox 4.1.2.r73507Ubuntu11.10 Beta2

=======================2011-08-26==================================有時候，最難的是堅持；有時候缺少的是信念。=======================2011-08-07==================================從接觸設計模式到如今大概4年左右的時間，一直都想有朝一日定要精通，坐於床頭，側望左右，設計模式的書買了7,8本了，也看了很多參考和視頻，也用到了一些。但是今天我終於停下來，停下來梳理，停下來

公司最近也開始基於android4.0 ICS修改架構了，公司的手機暫時不適合拿回家測試，也沒有kernel的許可權。從個人的角度看，我手上現在有兩部手機，一部是Htc G9 Aria，一部是Samsung I9100

上一篇文章http://www.cnblogs.com/octobershiner/archive/2011/11/06/2237880.html介紹了sensor的基本知識以及一個使用其中加速度感應器擷取資料的例子。  提到過一個問題，就是說感應器重新整理頻率太快，假如我們要做一個UI中，需要根據方向資料繪製一個一個移動的箭頭，那麼就要太過頻繁的重新整理繪製介面，佔用很多的資源，體驗性也會很差，《android