【正文】 vider中只需要調(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是一個(gè)支持隨機(jī)讀寫的指針，不僅如此，它還提供了方便的刪除和修改的API，是上層對(duì)ContentProvider進(jìn)行操作一個(gè)重要對(duì)象，需要仔細(xì)掌握（Cursor還可以綁定到view上，直接送顯，并與用戶進(jìn)行交互，真是程序越往上，封裝越好，工作越機(jī)械沒有復(fù)雜性了...）。數(shù)據(jù)模型在與界面打交道的Cursor、ContentResolver等數(shù)據(jù)操作層中，大量采用觀察者模式建立數(shù)據(jù)層與顯示層的聯(lián)系。一個(gè)顯示層的視圖，可以做成某一種觀察者注冊(cè)到Cursor或ContentResolver等數(shù)據(jù)中間層中，在實(shí)現(xiàn)底層ContentProvider中，我們需要特別注意在對(duì)數(shù)據(jù)進(jìn)行修改操作（包括增刪改...）后，調(diào)用相應(yīng)類型的notify函數(shù)，幫助表層對(duì)象進(jìn)行刷新（還有一種刷新方式是從一個(gè)view發(fā)起的）?？梢钥吹?Android的整體數(shù)據(jù)顯示框架有點(diǎn)像MVC的方式。Cursor、ContentResolver相當(dāng)于控制層，數(shù)據(jù)層和顯示層的交互通過控制層來掌管，而且控制層很穩(wěn)定不需要特別定制，通常工作只在定制數(shù)據(jù)層和顯示層空間，還是比較方便和清晰的。通過這學(xué)期對(duì)安卓的學(xué)習(xí)，大概了解了以上一些知識(shí)，對(duì)安卓有了初步的了解，這幾個(gè)月給我的東西我想用有形的和無形的兩部分概敘，形的當(dāng)然就是技術(shù)水平的長進(jìn)，雖然其中肯定有很多的不足，相信慢慢會(huì)體會(huì)到。第五篇：智能機(jī)交流會(huì)總結(jié)智能機(jī)交流會(huì)總結(jié)在領(lǐng)導(dǎo)的指導(dǎo)下，在聯(lián)通直銷人員的積極籌備與準(zhǔn)備下，我們的智能手機(jī)交流會(huì)終于圓滿的落下帷幕。為了這次交流會(huì)能夠圓滿成功的舉行，聯(lián)通直銷成員都是煞費(fèi)苦心，積極的出謀劃策。從交流會(huì)的構(gòu)思、流程…最終到能登“大雅之堂”，都是我們整個(gè)團(tuán)隊(duì)共同努力的結(jié)果。在熱烈的交流會(huì)上，智能機(jī)用戶踴躍提問，講師們坦誠回答，并把自己在使用手機(jī)中的“真經(jīng)”毫不保留的傳授給了大家。大家洗耳恭聽，虛心請(qǐng)教，掌聲時(shí)起時(shí)落！整個(gè)交流會(huì)在歡快、愉悅的氣氛中圓滿落幕。本次活動(dòng)的順利進(jìn)行不僅拉近了學(xué)生與聯(lián)通公司之間的距離，更是在一定程度上消除了智能機(jī)用戶心中的的迷茫和對(duì)未來的種種擔(dān)憂。雖然整活動(dòng)看似沒有什么大漏洞，但是藏在活動(dòng)內(nèi)部的一些小問題，卻是大家有目共睹的，主要存在以下方面的問題：，雖說大體沒差錯(cuò)，但細(xì)節(jié)方面還是有小的漏洞，例如：人員時(shí)間觀念不是太強(qiáng)；就智能機(jī)使用人員，素質(zhì)不是太高，垃圾搞得比較亂，最后會(huì)場不好打掃，下此再辦活動(dòng)可以搞一個(gè)溫馨小提示。，當(dāng)然這也是第一次辦，可以慢慢改進(jìn)；我們大家可以集思廣益從學(xué)生角度出發(fā)，把以后的交流會(huì)辦的實(shí)用，幽默，通過一些手機(jī)知識(shí)競答等方法，把大家的積極性真正調(diào)動(dòng)起來，讓他們?nèi)谌肫渲小?當(dāng)然自己也有很多問題，會(huì)前準(zhǔn)備的不是很充分，會(huì)中又有些緊張，在下次活動(dòng)中，應(yīng)該把這些東西系統(tǒng)的寫下來，以便做的更好。4我們可以創(chuàng)建一個(gè)城建智能機(jī)達(dá)人的群，大家可以在上面上傳些實(shí)用的手機(jī)軟件，歌曲，或自己拍的一些圖片，形成一個(gè)社區(qū)，每月會(huì)對(duì)上傳優(yōu)質(zhì)文件的同學(xué)實(shí)行抽獎(jiǎng)。5在群里面，建一個(gè)找工作的平臺(tái)，給大家提供一個(gè)勤工助學(xué)崗位，聯(lián)通公司需要人員時(shí)，可以在上面發(fā)帖。6我們搞活動(dòng)的時(shí)候可以在上面征策劃，策劃寫的好的有獎(jiǎng)勵(lì)。7在每次辦交流會(huì)時(shí)可以把這些東西宣傳給大家?？偨Y(jié)經(jīng)驗(yàn)，對(duì)于不足的地方我們須認(rèn)真反思，以便在下一次活動(dòng)作得更好，讓好的茶泡出更香甜的味道，但總體來說活動(dòng)進(jìn)行的還是很成功。