【正文】 ，這些類型使系統(tǒng)與我們通信的語言（比如在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等消息，注冊中心會(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ā)送，可以分成單播和廣播兩種。廣播的接收者是所有注冊了的符合條件的IntentReceiver。在單播的情況下，即使有很多符合條件的接收者，也只要有一個(gè)出來處理這個(gè)消息就好（恩，個(gè)人看法，沒找到確切條款或抉擇的算法，本來想實(shí)驗(yàn)一下，沒來得及...），這樣的情況很容易理解，當(dāng)你需要修改某個(gè)數(shù)據(jù)的時(shí)候，你肯定不會(huì)希望有十個(gè)編輯器輪流讓你來處理。當(dāng)廣播不是這樣，一個(gè)receiver沒有辦法阻止其他receiver進(jìn)行對(duì)廣播事件的處理。這種情況也很容易理解，比如時(shí)鐘改變了，鬧鐘、備忘錄等很多程序都需要分別進(jìn)行處理。在自己的程序的使用中，應(yīng)該分清楚區(qū)別，合理的使用。數(shù)據(jù)庫操作從我目前掌握的知識(shí)來看，SQLite比較輕量（沒有存儲(chǔ)過程之類的繁雜手段），用起來也比較簡單。實(shí)例化一個(gè)SQLiteDatabase類對(duì)象，通過它的APIs可以搞定大部分的操作。從sample中看，Android中對(duì)db的使用有一種比較簡單的模式，即派生一個(gè) ContentProviderDatabaseHelper類來進(jìn)行SQLiteDatabase對(duì)象實(shí)例的獲取工作?；旧?，ContentProviderDatabaseHelper類扮演了一個(gè)singleton的角色，提供單一的實(shí)例化入口點(diǎn)，并屏蔽了數(shù)據(jù)庫創(chuàng)建、打開升級(jí)等細(xì)節(jié)。在ContentProvider中只需要調(diào)用ContentProviderDatabaseHelper的openDatabase方法獲取SQLiteDatabase的實(shí)例就好，而不需要進(jìn)行數(shù)據(jù)庫狀態(tài)的判斷。URI 像進(jìn)行數(shù)據(jù)庫操作需要用SQL一樣，對(duì)ContentProivder進(jìn)行增刪改查等操作都是通過一種特定模式的URI來進(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格式返回一個(gè)字符串（==!沒聽過的詭異格式...）唯一標(biāo)識(shí)該uri的類型。所謂uri的類型，就是描述這個(gè)uri所進(jìn)行的操作的種類，比如content://xx/a與 content://xx/a/1不是一個(gè)類型（前者是多值操作，后者是單值），但content://xx/a/1和content://xx/a/2 就會(huì)是一個(gè)類型（只是id號(hào)不同而已）。在ContentProvider通常都會(huì)實(shí)例化一個(gè)ContentURIPraser來輔助解析和操作傳入的URI。你需要事先（在static域內(nèi)）為該ContentURIPraser建立一個(gè)uri的語法樹，之后就可以簡單調(diào)用 ContentURIPraser類的相關(guān)方法進(jìn)行uri類型判斷（match方法），獲取加載在uri中的參數(shù)等操作。但我看來，這只是在使用上簡化了相關(guān)操作（不然就需要自己做人肉解析了...），但并沒有改變類型判定的模式。你依然需要用switch...case...對(duì)uri的類型進(jìn)行判斷，并進(jìn)行相關(guān)后續(xù)的操作。從模式來看，這樣無疑是具有強(qiáng)烈的壞味道，類似的switch...case...代碼要出現(xiàn)N此，每次一個(gè) ContentProvider做uri類型的增減都會(huì)需要遍歷修改每一個(gè)switch...case...，當(dāng)然，如果你使用模式（策略模式...）進(jìn)行改造對(duì)手機(jī)程序來說無疑是崩潰似的（類型膨脹，效率降低...），所以，只能是忍一忍了（恩，還好不會(huì)擴(kuò)散到別的類中，維護(hù)性上不會(huì)有殺人性的麻煩...）。增刪改查ContentProvider 和所有數(shù)據(jù)源一樣，向外提供增刪改查操作接口，這些都是基于uri的指令。進(jìn)行insert操作的時(shí)候，你需要傳入一個(gè)uri和 ContentValues。uri的作用基本就限于指明增減條目的類型（從數(shù)據(jù)庫層面來看就是table名），ContentValues是一個(gè) key/value表的封裝，提供方便的API進(jìn)行插入數(shù)據(jù)類型和數(shù)據(jù)值的設(shè)置和獲取。在數(shù)據(jù)庫層面上來看，這應(yīng)該是column name與value的對(duì)應(yīng)。但為了屏蔽ContentProvider用戶涉及到具體數(shù)據(jù)庫的細(xì)節(jié)，在Android的示例中，用了一個(gè)小小的模式。它為每一個(gè)表建一個(gè)基于BaseColumn類的派生類（其實(shí)完全可以不派生自BaseColumn，特別當(dāng)你的表不基于默認(rèn)的自動(dòng)id做主鍵的時(shí)候），這個(gè)類通常包括一個(gè)描述該表的ContentURI對(duì)象和形如 public static final TITLE = “title”這樣的column到類數(shù)據(jù)的對(duì)應(yīng)。從改變上角度來看，你可以修改column的名字而不需要更改用戶上層代碼，增加了靈活性。insert方法如果成功會(huì)返回一個(gè)uri，該uri會(huì)在原有的uri基礎(chǔ)上增加有一個(gè)row id。對(duì)于為什么使用row id而不是key id我想破了腦袋。到最后，我發(fā)現(xiàn)我傻了，因?yàn)镃ontentProvider不一定需要使用數(shù)據(jù)庫，使用數(shù)據(jù)庫對(duì)應(yīng)的表也可以沒有主鍵，只有row id，才能在任何底層介質(zhì)下做索引標(biāo)識(shí)。但，基于row id在刪除和修改操作是會(huì)造成一定的混亂。刪除和修改操作類似。刪除操作需要傳入一個(gè)uri，一個(gè)where字串，一組where的參數(shù)（做條件判定...），而修改操作會(huì)多一個(gè)ContentValues做更新值。著兩個(gè)操作的uri都支持在末尾添加一個(gè)row id。于是混亂就出現(xiàn)了。當(dāng)在where參數(shù)中指明了key id，而在uri中提供了row id，并且row id和key id所指函數(shù)不一致的時(shí)候，你聽誰的？示例代碼中的做法是完全無視r(shí)ow id（無語...），如此野蠻的方式我估計(jì)也只能在示例中出現(xiàn)，在實(shí)際中該如何用，恩，我也不知道。幸運(yùn)的是，我看了下上層對(duì) ContentProvider的刪除操作，其實(shí)都不會(huì)直接進(jìn)行，而是通過調(diào)用Cursor的delete方法進(jìn)行，在這前提下，我想Cursor會(huì)處理好這些東西吧。最后一個(gè)操作是查詢操作，可以想見，查詢的參數(shù)是最多的，包括uri和一組條件參數(shù)。條件參數(shù)類型和標(biāo)準(zhǔn)的sql類似，包括 sort, projection 之類的。從這些參數(shù)到sql語句的生成，可以尋求QueryBuilder類的幫助，它提供了一組操作接口，簡化了參數(shù)到sql的生成工作，哪怕你不懂 sql都完全沒有問題（這話說的我自己都覺得有點(diǎn)懸...）。查詢返回一個(gè)Cursor。Cursor是一