【文章內(nèi)容簡(jiǎn)介】 綁定控件View，或者是適配器ListAdapter。如果是一個(gè)數(shù)據(jù)顯示密集的應(yīng)用，且你對(duì)UI有些追求，這個(gè)工作估計(jì)是必不可少的。一個(gè)主要用于顯示數(shù)據(jù)內(nèi)容的Activity，可以選擇派生自ListActivity。它提供了一個(gè)具有ListView 的Layout，還有simple_list_item_1, simple_list_item_2, two_line_list_item等默認(rèn)的Row Layout，還有一些比較不錯(cuò)的API，和可供響應(yīng)選擇Item的事件?？梢詽M足你比較基礎(chǔ)的需求。如果你覺(jué)得只有一個(gè)ListView的界面太突兀，你可以為這個(gè)ListActivity指定一個(gè)Layout，需要注意的是，你需要提供一個(gè)id為@android:id/list的ListView控件，避免Activity在內(nèi)部偷偷尋找該控件的時(shí)候失敗。除了這些要求，做好UI還有注意易用性和效率。快捷鍵是一個(gè)比較不錯(cuò)的選擇，在 Activity中調(diào)用setDefaultkeyMode(SHORTCUT_DEFAULT_KEYS)，可以開(kāi)啟快捷鍵模式，然后你可以將菜單綁定到指定快捷鍵上就OK了。個(gè)人覺(jué)得Tip也是一個(gè)比較重要的東西，但目前觀察看來(lái)，這個(gè)東西只能夠自己提供了。界面的動(dòng)態(tài)性有時(shí)候是不可避免的，比如說(shuō)菜單就是一個(gè)需要經(jīng)常根據(jù)光標(biāo)位置提供不同的選項(xiàng)。這個(gè)東西Android很人道的考慮到了，你可以參看NodeList這個(gè)Sample。它采取的應(yīng)該是一個(gè)靜態(tài)模擬動(dòng)態(tài)的方式，這樣有助于提高速度。你也可以利用ViewInflate，動(dòng)態(tài)從一個(gè)XML創(chuàng)建一個(gè)控件。成本據(jù)Doc說(shuō)很大，不到萬(wàn)不得已不要使用。在前面寫Android的ContentProvider時(shí)候，可以看到那是基于觀察者模式的一個(gè)消息傳遞方法。每一個(gè)Cursor、ContentResolver做為一個(gè)小的注冊(cè)中心，相關(guān)觀察者可以在這個(gè)中心注冊(cè)，更新消息由注冊(cè)中心分發(fā)給各個(gè)觀察者。而在MFC或Winform中，都會(huì)形成一個(gè)消息網(wǎng)，讓消息在網(wǎng)中流動(dòng)，被各節(jié)點(diǎn)使用、吃掉或者在出口死掉。相比之下，我個(gè)人覺(jué)得基于Intent的Android核心消息傳遞機(jī)制是有所不同的。它應(yīng)該會(huì)有一個(gè)全局性的注冊(cè)中心，這個(gè)注冊(cè)中心是隱性的，整個(gè)Android系統(tǒng)中就那么一個(gè)。所有的消息接收者，都被隱形的注冊(cè)到這個(gè)中心。包括Activity，Service和IntentReceiver。其實(shí)說(shuō)隱形注冊(cè)是不確切的，所有注冊(cè)都還是我們手動(dòng)告訴注冊(cè)中心的，只是與傳統(tǒng)的方式不一樣，我們通常不是通過(guò)代碼，而是通過(guò)配置文件來(lái)做。在應(yīng)用的Manifest中，我們會(huì)為一些Activity或Service添加上Intentfilter，或在配置文件中添加項(xiàng)。這其實(shí)就相當(dāng)于向系統(tǒng)的注冊(cè)中心，注冊(cè)了相關(guān)的Intentfilter和receiver（這個(gè)事情完全可以通過(guò)代碼來(lái)做，只是這樣就失去了修改的靈活性）。當(dāng)程序有一個(gè)消息希望發(fā)出去的時(shí)候，它需要將消息封裝成一個(gè)Intent，并發(fā)送。這時(shí)候，應(yīng)該是有一個(gè)統(tǒng)一的中心（恩，有可能Android底層實(shí)現(xiàn)的時(shí)候不是，但簡(jiǎn)單這樣看是沒(méi)問(wèn)題的...）接受到這個(gè)消息，并對(duì)它進(jìn)行解析、判定消息類型（這個(gè)步驟降低了耦合...），然后檢查注冊(cè)了相匹配的filter或receiver，并創(chuàng)建或喚醒接收者，將消息分發(fā)給它。這樣做有很多好處。雖然這種傳遞有的時(shí)候不如點(diǎn)對(duì)點(diǎn)的傳遞快（這有些需要速度的地方，我們看到Android會(huì)通過(guò)直接通信來(lái)做），但有時(shí)候又因?yàn)樗唤?jīng)過(guò)一跳（姑且這么叫吧...），比復(fù)雜的流動(dòng)又要更快。更重要的是，它耦合性低，在手機(jī)平臺(tái)這種程序組件多變的條件下使用十分適合。并且它可以很容易實(shí)現(xiàn)消息的精確或模糊匹配，彈性很大。（我個(gè)人曾想在開(kāi)發(fā)一個(gè)C++二次平臺(tái)的時(shí)候引入這樣的機(jī)制，但在C++中，建立一套完整的數(shù)據(jù)marshal機(jī)制不容易，相比之下，用java來(lái)做會(huì)簡(jiǎn)單很多...）恩，廢話說(shuō)了很多，具體講講Android中Intent的使用。當(dāng)你有一個(gè)消息需要傳遞，如果你明確知道你需要哪個(gè)Activity或者其他Class來(lái)響應(yīng)的話，你可以指定這個(gè)類來(lái)接受該消息，這被稱為顯性發(fā)送。你需要將Intent的class屬性設(shè)置成目標(biāo)。這種情況很常見(jiàn)，比如startActivity的時(shí)候，會(huì)清楚當(dāng)前Activity完了應(yīng)該是哪個(gè)Activity，那就明確的發(fā)送這個(gè)消息。但是，有的時(shí)候你并不確定你的消息是需要具體哪個(gè)類來(lái)執(zhí)行，而只是知道接收者該符合哪些條件。比如你只需要有一個(gè)接收者能顯示用戶所選的數(shù)據(jù)，而不想制定某個(gè)具體的方法，這時(shí)候你就需要用到隱形發(fā)送（傳統(tǒng)上，我們可能會(huì)考慮用多態(tài)，但顯然這種方式更為靈活...）。在Android中，你可以為Intent指定一個(gè)action，表示你這個(gè)指令需要處理的事情。系統(tǒng)為我們定義了很多Action類型，這些類型使系統(tǒng)與我們通信的語(yǔ)言（比如在Activity里面加一個(gè)Main的filter，該activity就會(huì)做成該應(yīng)用的入口點(diǎn)），當(dāng)然你也可以用于你自己的應(yīng)用之間的通信（同樣當(dāng)然，也可以自定義...）。強(qiáng)烈建議，在自己程序接收或發(fā)出一個(gè)系統(tǒng)action的時(shí)候，要名副其實(shí)。比如你響應(yīng)一個(gè)view動(dòng)作，做的確實(shí)edit的勾當(dāng)，你發(fā)送一個(gè)pick消息，其實(shí)你想讓別人做edit的事，這樣都會(huì)造成混亂。當(dāng)然只有Action有時(shí)候是不夠的，在Android中我們還可以指定catalog信息和type/data信息，比如所有的顯示數(shù)據(jù)的Activity，可能都會(huì)響應(yīng)View action。但很多與我們需要顯示的數(shù)據(jù)類型不一樣，可以加一個(gè)type信息，明確的指出我們需要顯示的數(shù)據(jù)類型，甚至還可以加上一個(gè)catalog信息，指明只有你只有按的是“中鍵”并發(fā)出這樣的消息才響應(yīng)。從上面可以看出，Android的Intent可以添加上class, action, data/type, catalog等消息，注冊(cè)中心會(huì)根據(jù)這些信息幫你找到符合的接收者。其中class是點(diǎn)對(duì)點(diǎn)的指示，一旦指明，其他信息都被忽略。Intent中還可以添加key/value的數(shù)據(jù)，發(fā)送方和接收方需要保持統(tǒng)一的key信息和value類型信息，這種數(shù)據(jù)的marshal在java里做，是不費(fèi)什么力氣的。Android的Intent發(fā)送，可以分成單播和廣播兩種。廣播的接收者是所有注冊(cè)了的符合條件的IntentReceiver。在單播的情況下，即使有很多符合條件的接收者，也只要有一個(gè)出來(lái)處理這個(gè)消息就好（恩，個(gè)人看法，沒(méi)找到確切條款或抉擇的算法，本來(lái)想實(shí)驗(yàn)一下，沒(méi)來(lái)得及...），這樣的情況很容易理解，當(dāng)你需要修改某個(gè)數(shù)據(jù)的時(shí)候，你肯定不會(huì)希望有十個(gè)編輯器輪流讓你來(lái)處理。當(dāng)廣播不是這樣，一個(gè)receiver沒(méi)有辦法阻止其他receiver進(jìn)行對(duì)廣播事件的處理。這種情況也很容易理解，比如時(shí)鐘改變了，鬧鐘、備忘錄等很多程序都需要分別進(jìn)行處理。在自己的程序的使用中，應(yīng)該分清楚區(qū)別，合理的使用。數(shù)據(jù)庫(kù)操作從我目前掌握的知識(shí)來(lái)看，SQLite比較輕量（沒(méi)有存儲(chǔ)過(guò)程之類的繁雜手段），用起來(lái)也比較簡(jiǎn)單。實(shí)例化一個(gè)SQLiteDatabase類對(duì)象，通過(guò)它的APIs可以搞定大部分的操作。從sample中看，Android中對(duì)db的使用有一種比較簡(jiǎn)單的模式，即派生一個(gè) ContentProviderDatabaseHelper類來(lái)進(jìn)行SQLiteDatabase對(duì)象實(shí)例的獲取工作?；旧希珻ontentProviderDatabaseHelper類扮演了一個(gè)singleton的角色，提供單一的實(shí)例化入口點(diǎn)，并屏蔽了數(shù)據(jù)庫(kù)創(chuàng)建、打開(kāi)升級(jí)等細(xì)節(jié)。在ContentProvider中只需要調(diào)用ContentProviderDatabaseHelper的openDatabase方法獲取SQLiteDatabase的實(shí)例就好，而不需要進(jìn)行數(shù)據(jù)庫(kù)狀態(tài)的判斷。URI 像進(jìn)行數(shù)據(jù)庫(kù)操作需要用SQL一樣，對(duì)ContentProivder進(jìn)行增刪改查等操作都是通過(guò)一種特定模式的URI來(lái)進(jìn)行的（ig：content: //provider/item/id），URI的能力與URL類似，具體細(xì)節(jié)可以查看SDK。建立自己的ContentProvider，只需要派生 ContentProivder類并實(shí)現(xiàn)insert, delete, update等抽象函數(shù)即可。在這些接口中比較特殊的是getType(uri)。根據(jù)傳入的uri，該方法按照MIME格式