【正文】 vider中只需要調(diào)用ContentProviderDatabaseHelper的openDatabase方法獲取SQLiteDatabase的實例就好，而不需要進行數(shù)據(jù)庫狀態(tài)的判斷。URI 像進行數(shù)據(jù)庫操作需要用SQL一樣，對ContentProivder進行增刪改查等操作都是通過一種特定模式的URI來進行的（ig：content: //provider/item/id），URI的能力與URL類似，具體細節(jié)可以查看SDK。建立自己的ContentProvider，只需要派生 ContentProivder類并實現(xiàn)insert, delete, update等抽象函數(shù)即可。在這些接口中比較特殊的是getType(uri)。根據(jù)傳入的uri，該方法按照MIME格式返回一個字符串（==!沒聽過的詭異格式...）唯一標識該uri的類型。所謂uri的類型，就是描述這個uri所進行的操作的種類，比如content://xx/a與 content://xx/a/1不是一個類型（前者是多值操作，后者是單值），但content://xx/a/1和content://xx/a/2 就會是一個類型（只是id號不同而已）。在ContentProvider通常都會實例化一個ContentURIPraser來輔助解析和操作傳入的URI。你需要事先（在static域內(nèi)）為該ContentURIPraser建立一個uri的語法樹，之后就可以簡單調(diào)用 ContentURIPraser類的相關方法進行uri類型判斷（match方法），獲取加載在uri中的參數(shù)等操作。但我看來，這只是在使用上簡化了相關操作（不然就需要自己做人肉解析了...），但并沒有改變類型判定的模式。你依然需要用switch...case...對uri的類型進行判斷，并進行相關后續(xù)的操作。從模式來看，這樣無疑是具有強烈的壞味道，類似的switch...case...代碼要出現(xiàn)N此，每次一個 ContentProvider做uri類型的增減都會需要遍歷修改每一個switch...case...，當然，如果你使用模式（策略模式...）進行改造對手機程序來說無疑是崩潰似的（類型膨脹，效率降低...），所以，只能是忍一忍了（恩，還好不會擴散到別的類中，維護性上不會有殺人性的麻煩...）。增刪改查ContentProvider 和所有數(shù)據(jù)源一樣，向外提供增刪改查操作接口，這些都是基于uri的指令。進行insert操作的時候，你需要傳入一個uri和 ContentValues。uri的作用基本就限于指明增減條目的類型（從數(shù)據(jù)庫層面來看就是table名），ContentValues是一個 key/value表的封裝，提供方便的API進行插入數(shù)據(jù)類型和數(shù)據(jù)值的設置和獲取。在數(shù)據(jù)庫層面上來看，這應該是column name與value的對應。但為了屏蔽ContentProvider用戶涉及到具體數(shù)據(jù)庫的細節(jié)，在Android的示例中，用了一個小小的模式。它為每一個表建一個基于BaseColumn類的派生類（其實完全可以不派生自BaseColumn，特別當你的表不基于默認的自動id做主鍵的時候），這個類通常包括一個描述該表的ContentURI對象和形如 public static final TITLE = “title”這樣的column到類數(shù)據(jù)的對應。從改變上角度來看，你可以修改column的名字而不需要更改用戶上層代碼，增加了靈活性。insert方法如果成功會返回一個uri，該uri會在原有的uri基礎上增加有一個row id。對于為什么使用row id而不是key id我想破了腦袋。到最后，我發(fā)現(xiàn)我傻了，因為ContentProvider不一定需要使用數(shù)據(jù)庫，使用數(shù)據(jù)庫對應的表也可以沒有主鍵，只有row id，才能在任何底層介質(zhì)下做索引標識。但，基于row id在刪除和修改操作是會造成一定的混亂。刪除和修改操作類似。刪除操作需要傳入一個uri，一個where字串，一組where的參數(shù)（做條件判定...），而修改操作會多一個ContentValues做更新值。著兩個操作的uri都支持在末尾添加一個row id。于是混亂就出現(xiàn)了。當在where參數(shù)中指明了key id，而在uri中提供了row id，并且row id和key id所指函數(shù)不一致的時候，你聽誰的？示例代碼中的做法是完全無視row id（無語...），如此野蠻的方式我估計也只能在示例中出現(xiàn)，在實際中該如何用，恩，我也不知道。幸運的是，我看了下上層對 ContentProvider的刪除操作，其實都不會直接進行，而是通過調(diào)用Cursor的delete方法進行，在這前提下，我想Cursor會處理好這些東西吧。最后一個操作是查詢操作，可以想見，查詢的參數(shù)是最多的，包括uri和一組條件參數(shù)。條件參數(shù)類型和標準的sql類似，包括 sort, projection 之類的。從這些參數(shù)到sql語句的生成，可以尋求QueryBuilder類的幫助，它提供了一組操作接口，簡化了參數(shù)到sql的生成工作，哪怕你不懂 sql都完全沒有問題（這話說的我自己都覺得有點懸...）。查詢返回一個Cursor。Cursor是一個支持隨機讀寫的指針，不僅如此，它還提供了方便的刪除和修改的API，是上層對ContentProvider進行操作一個重要對象，需要仔細掌握（Cursor還可以綁定到view上，直接送顯，并與用戶進行交互，真是程序越往上，封裝越好，工作越機械沒有復雜性了...）。數(shù)據(jù)模型在與界面打交道的Cursor、ContentResolver等數(shù)據(jù)操作層中，大量采用觀察者模式建立數(shù)據(jù)層與顯示層的聯(lián)系。一個顯示層的視圖，可以做成某一種觀察者注冊到Cursor或ContentResolver等數(shù)據(jù)中間層中，在實現(xiàn)底層ContentProvider中，我們需要特別注意在對數(shù)據(jù)進行修改操作（包括增刪改...）后，調(diào)用相應類型的notify函數(shù)，幫助表層對象進行刷新（還有一種刷新方式是從一個view發(fā)起的）?？梢钥吹?Android的整體數(shù)據(jù)顯示框架有點像MVC的方式。Cursor、ContentResolver相當于控制層，數(shù)據(jù)層和顯示層的交互通過控制層來掌管，而且控制層很穩(wěn)定不需要特別定制，通常工作只在定制數(shù)據(jù)層和顯示層空間，還是比較方便和清晰的。通過這學期對安卓的學習，大概了解了以上一些知識，對安卓有了初步的了解，這幾個月給我的東西我想用有形的和無形的兩部分概敘，形的當然就是技術(shù)水平的長進，雖然其中肯定有很多的不足，相信慢慢會體會到。第五篇：智能機交流會總結(jié)智能機交流會總結(jié)在領導的指導下，在聯(lián)通直銷人員的積極籌備與準備下，我們的智能手機交流會終于圓滿的落下帷幕。為了這次交流會能夠圓滿成功的舉行，聯(lián)通直銷成員都是煞費苦心，積極的出謀劃策。從交流會的構(gòu)思、流程…最終到能登“大雅之堂”，都是我們整個團隊共同努力的結(jié)果。在熱烈的交流會上，智能機用戶踴躍提問，講師們坦誠回答，并把自己在使用手機中的“真經(jīng)”毫不保留的傳授給了大家。大家洗耳恭聽，虛心請教，掌聲時起時落！整個交流會在歡快、愉悅的氣氛中圓滿落幕。本次活動的順利進行不僅拉近了學生與聯(lián)通公司之間的距離，更是在一定程度上消除了智能機用戶心中的的迷茫和對未來的種種擔憂。雖然整活動看似沒有什么大漏洞，但是藏在活動內(nèi)部的一些小問題，卻是大家有目共睹的，主要存在以下方面的問題：，雖說大體沒差錯，但細節(jié)方面還是有小的漏洞，例如：人員時間觀念不是太強；就智能機使用人員，素質(zhì)不是太高，垃圾搞得比較亂，最后會場不好打掃，下此再辦活動可以搞一個溫馨小提示。，當然這也是第一次辦，可以慢慢改進；我們大家可以集思廣益從學生角度出發(fā)，把以后的交流會辦的實用，幽默，通過一些手機知識競答等方法，把大家的積極性真正調(diào)動起來，讓他們?nèi)谌肫渲小?當然自己也有很多問題，會前準備的不是很充分，會中又有些緊張，在下次活動中，應該把這些東西系統(tǒng)的寫下來，以便做的更好。4我們可以創(chuàng)建一個城建智能機達人的群，大家可以在上面上傳些實用的手機軟件，歌曲，或自己拍的一些圖片，形成一個社區(qū)，每月會對上傳優(yōu)質(zhì)文件的同學實行抽獎。5在群里面，建一個找工作的平臺，給大家提供一個勤工助學崗位，聯(lián)通公司需要人員時，可以在上面發(fā)帖。6我們搞活動的時候可以在上面征策劃，策劃寫的好的有獎勵。7在每次辦交流會時可以把這些東西宣傳給大家?？偨Y(jié)經(jīng)驗，對于不足的地方我們須認真反思，以便在下一次活動作得更好，讓好的茶泡出更香甜的味道，但總體來說活動進行的還是很成功。