第一篇：語文學習心得九(8)班余卓凡
期末語文學習經驗總結
九（8）班余卓凡
這次的語文期末考試中，我取得了比較好的成績，在此想與大家分享一下我學習語文的一點心得。
也許很多同學都覺得語文太麻煩，比較難把握到學好語文的要領。可我卻不這么認為，我覺得學好語文這門學科是有一定方法的。因為它是所有學科中最為基本的課程，因為語文不僅匯聚了我們母語的精華，而且與其他學科也有著千絲萬縷的聯系。在歷史，政治等課中，我們常會看到語文的蹤跡；在語文書中，我們也常會發(fā)現歷史生物的蹤影。所以，只要學會好語文，學其他科時就省事多了。下面，我就給大家談談我的學習方法。
一切知識是以記憶為基礎的，語文學習更是如此。在語文學習中，閱讀和寫作占了很大一部分地位，我相信那些背誦與默寫的內容對于絕大多數同學來說，應該不是難事。正是因為有閱讀和寫作，許多同學在學習語文時才會遇到瓶頸。其實在閱讀上不必花大量的時間，你只要在課堂上聽懂老師講的每一課的內容，下課了，有不明白的地方抓緊時間與老師交流，與同學討論。然后認真做老師布置的每一道閱讀分析題，不隨便敷衍。有了平時充分的鍛煉，考試時一定沒問題。當然最重要的是，考試時遇到的題目是不可能與平常老師講課和作業(yè)一模一樣的，在答題的時候不能存有僥幸心理，應把每道題當做從沒做過的，每個語段當做從沒看過的，認真分析比較，不照搬照抄老師上課的內容，學會自己分析。
講到作文這個語文上的重頭戲，我覺得積累很重要。俗話說：“巧婦難為無米炊?！边@文章之“炊”，就是從字、詞、句之“米”組成的。要到達一般閱讀、書寫水平，你總得記住幾千個漢字；要進一步使文字自然、流暢、華麗、優(yōu)美，你就得記住許多精詞妙句；如要再進一步使文章嚴謹、生動、清晰、新奇，你就得記住許多體式節(jié)構。正像跳舞要掌握基本舞步一樣，只有肚子里滾瓜爛熟地裝上幾十篇范文，才能循歸為圓，依矩成方，進而方圓自如，為其所用。至于文章內容的深淺，風格的高下，那是其他方面的修養(yǎng)，又當別論。也許你會說，這樣背誦別人的文章不是抄襲嗎？這樣想是錯誤的，背誦并不代表要照搬照抄，你可以根據自身需求進行改動，在一次次的修改中，把一篇美文變得更貼合自己的生活，變得更好。
同學們，這就是我的語文學習方法和經驗，我相信，只要做到上面幾點，你就一定能學好語文。還有，同學們，良好的班集體是全體同學的共同進步，不如把你的學習方法也說出來，和大家一起分享，相信我們會成為最優(yōu)秀的班級，這樣，何樂而不為呢？
第二篇：余凡婚禮主持詞
黃義剛、丁春艷婚禮主持流程
1、播放婚紗視頻
2、婚禮倒計時視頻
3、主持人上臺，開場白 尊敬各位來賓
4、新郎新娘登場（新郎西裝、新娘婚紗，安排伴娘）
新郎先登臺，主持人詢問新郎官，心情怎樣，高興嗎，激動嗎 激動那就考考他，新郎今天全身上下都是新的，新理的發(fā)，新刮得胡子，新買的皮鞋，這樣我說哪你指哪，好不好！新襯衣，新領帶，新皮帶，新皮鞋，新西褲，里面穿了條新秋褲?。ㄍ嫘Γ?/p>
認為新郎帥的，有沒有歡呼聲，吶喊聲
新郎非常的帥，所以啊，有一位愛的天使穿上了潔白的婚紗，讓我們將目光轉向愛的彼岸，新郎官，請爭取你幸福的快樂吧。帶著久久期待，帶著悠悠情懷，有情人終成眷屬，我們共同見證這一幸福時刻，朋友們用我們的掌聲歡迎兩位新人隆重登場。登場** 朋友們，認為我們的新娘漂亮的掌聲，非常漂亮的有沒有吶喊聲，認為他們的結合是完美的，掌聲。
5、交換婚戒（握在手心，放在胸前，宣誓，戴戒指，左手無名指，擁抱，親吻）
黃義剛、丁春艷。祝福你們，因為從此刻開始，你們將開始一輩子的 牽手，兩位幸福的愛人，請你們相對而立，雙手相牽，四目相對，感受手心中傳來的溫暖，感受眼神中傳來的關懷。此時此刻愛的使者，為兩位呈上了璀璨的婚戒，兩位幸福的愛人，請各自取出，放于心臟最近的地方。虔誠的為對方許下一個愿望
尊敬的黃義剛先生，你面前這位美麗的姑娘，將是你攜手一生的愛人，從今天起，你將作為丈夫，用你所有的責任、力量和愛，去給他一個溫暖的家，如果你能夠做到，請用你最誠摯的方式，將它許愿與新娘的左手的無名指上，從此將它化作無淚的天使。新郎表白（我愛你）美麗的丁春艷你面前這位帥氣的新郎，將是你一生的倚靠，從今天起，你講作為妻子，用你所有的柔情和愛意，為他苒起一座愛的風帆，如果你能夠做到，請將這枚愛的指環(huán)許愿與新郎左手的無名指上。情定于此，一生一世，2016年1月9日，黃義剛先生、丁春艷小姐正式結為合法夫妻。新郎擁抱并親吻你的愛人吧!
6、敬孝心茶，改口，父母給包（互動游戲，現代，傳統，英文，古代）互動游戲，三鞠躬行禮，先采訪公公，高興嗎？既然你這么高興啊，就要有個表現方式，你知道怎么表達嗎？我現場教你怎樣？？大笑三聲怎樣？ 問婆婆：媳婦漂亮嗎？媳婦美麗嗎？媳婦大方大方？好不好？再來一個要不要？
既然兩位老人對媳婦這么滿意，那么就讓我們的新郎給老人敬上孝心茶。
爸，請喝茶！爸回答：哎…… 爹，請喝茶！媽，請喝茶！娘，請喝茶！
來請兩位新人向爸爸媽媽行禮。一拜父母生育、養(yǎng)育之恩，請行禮 再拜父母，日夜操勞，培養(yǎng)之前，請行禮 祝福父母身體健康，笑口常開，請行禮！
7、點燃同心燭，夫妻對拜，交杯酒（準備同心燭）兩位新人：請相對而立，婚禮是一個全新的開始，婚禮宣告了一個嶄新的二人世界的誕生。他要求兩位新人在以后下相親相愛，相敬如賓！
8、拋手捧花，分享喜氣
9、感謝來賓
10、開宴
第三篇：安卓學習心得
Android學習心得
-----093380117
計算機應用（1）
張峰
1.關于Activity
1.在一個Activity中使用多個View
如果把Activity看作MVC中的Control？它負責管理UI和接受事件（包括用戶的輸入），雖然說一個Activity通常對應一個屏幕，但事實上，我們是可以只用一個Activity管理多個不同的View來實現簡單的邏輯。首先，我們增加一個新的資源描述layout/second.xml。
除了一個“Hello中國”以外，增加一個按鈕可以返回前一個界面。然后，在代碼中我們要為helloTwo增加兩個方法，setViewOneCommand和setViewTwoCommand，分別處理一下在不同界面時，從資源里加載組件并為組件綁定一個事件處理器最后，我們需要在onCreate的時候，也就是啟動后的main界面上設置一下按鈕事件處理器。2.還是回到正道上，多個Activity之間的跳轉
Android中提供一個叫Intent的類來實現屏幕之間的跳轉，按文檔的說法，似乎他們也建議采用這種方法，Intent的用法比較復雜，現在我先看看它最簡單的用法。
這里的跳轉功能用Intent來操作，它的最簡單用法就是用函數setClass()設置跳轉前后兩個Activity類的實例，然后調用Activity自己的startActivity(intent)即可。最后一句finish()表示將當前Activity關掉（如果不關掉會如何？你可以自己試一下看效果，事實上有時我們是不需要關掉當前Activity的）。
然后，我們同樣弄一個Activity類HelloThreeB，代碼與前面的差不多，只是將setClass的兩個參數反一下，這樣就可以簡單地實現在兩個Activity界面中來回切換的功能了。
2.關于 Intent的使用
Intent分為兩大類，顯性的（Explicit）和隱性的（Implicit）。一般來說，intent要定位事件的目的地，無外乎需要以下幾個信息： 1.種類（category），比如我們常見的 LAUNCHER_CATEGORY 就是表示這是一類應用程序。
2.類型（type），在前面的例子中沒用過，表示數據的類型，這是隱性Intent定位目標的重要依據。
3.組件（component），前面的例子中用的是setClass，不過也可以用setComponent來設置intent跳轉的前后兩個類實例。4.附加數據（extras），在ContentURI之外還可以附加一些信息，它是Bundle類型的對象。
其實，如果是在一個應用內部，這種隱性的intent實在有點別扭，個人覺得，這種松藕合的實現方法，只適用于那些較大的系統或者多個不同的應用之間的調用，可手機上又有什么“較大”的系統呢？無非是可以與不同來源的多個應用之間方便地互操作而已，那么會是什么樣的場景呢？比如，給QQ好友發(fā)送gmail郵件，用GoogleMap查找QQ好友所在的位置？看上去挺不錯的。
關于這個ContentProvider，其實還有話說，它主要是的那些看似數據庫操作的方法我們都沒真正去實現呢。不過今天就到這里了，等下回再去研究吧。
3.關于ListActivity
準備一個List對象并借助Adapter就可以構造出一個列表。重載onListItemClick方法可以響應選擇事件，利用第一個參數可以訪問到這個ListView實例以得到選中的條目信息。這里有一點要說明的，就是如果更簡單的話，其實連那個setContentView都可以不要了，Android也會自動幫我們構造出一個全屏的列表。但是本例中我們需要一個TextView來顯示選中的條目，所以我們需要一個layout.mainb描述一下這個列表窗口。
這里需要注意的是那個ListView的ID，是系統自定義的android:list，不是我們隨便取的，否則系統會說找不到它想要的listview了。然后，在這個listview之外，我們又增加了一個TextView，用來顯示選中的條目。
再來說說這里用到的ArrayAdapter，它的構造函數中第二個參數是一個資源ID，ArrayAdapter的API文檔中說是要求用一個包含TextView的layout文件，平臺用它來顯示每個選擇條目的樣式，這里的取值是R.layout.list_row，所以，我們還有一個list_row.xml文件來描述這個布局，相當簡單。
從ArrayAdapter上溯到BaseAdapter，發(fā)現還有幾個同源的Adapter也應該可以使用，象SimpleAdapter和CursorAdapter，還是做個例子來實驗一下吧。
然后，在HelloTwoB中的onCreate函數中，修改代碼，有幾個不同：items的元素是HashMap實例，這是一點變化，然后構造函數除了要求items以外，還要求提供一個string[]來說明用hash表中的哪個字段顯示在列表中，而后是一個資源ID的數組。
因為單純的CursorAdapter是抽象類，所以我用的是它的子類SimpleCursorAdapter，很好理解，先用ContentResolver查詢通訊簿得到一個游標，然后告訴SimpleCursorAdapter要用其中的People.NAME作為顯示項來構造出一個adapter即可。4.關于Dialog
注意到android.app包下除了Dialog（可用于制作復雜的對話框）以外，還包括了幾個系統定義好的對話框類，如DatePickerDialog、TimePickerDialog及AlertDialog。
其中AlertDialog我上回用過一次，基本上就那樣子了，今天看看另外兩個對話框的使用吧。
很簡單的，無非是需要一個OnDateSetListener接口的實現而已，在它里面的dateSet方法中就可以得到選擇的日期了。而TimePickerDialog與DatePickerDialog使用如出一轍。
看看另一個ProgressDialog的用法吧，這個類與AlertDialog一樣包含了多個static的方法，所以使用起來是非常方便的。比如說，如果我們需要用它來表示一個長時間的操作。
5.關于Service和Notification
大略地看了一下android.app下的Service類，覺得它與Activity非常相似，只是要注意幾個地方：
1.生命周期，Service的從onCreate()->onStart(int,Bundle)->onDestroy()顯得更為簡單。但是它的onStart是帶參數的，第一個ID可用來標識這個service，第二個參數顯示是用來傳遞數據的了。比較Activity，傳遞數據的Bundle是在onCreate就帶進入的。
2.Service的啟動由Context.startService開始，其實Activity或者Service都是Context的派生類。結束于Context.stopService()或者它自己的stopSelf()。
3.Service還有一個與Activity不一樣的是它可以由另一個Context去綁定一個已存在的Service。就是這個方法Context.bindService()，被綁定的Service要求是已經onCreate了但可以沒有onStart。在Service類中有個抽象方法getBinder()可以得到這個IBinder對象。關于這方面的細節(jié)，以后再看，這里只做個記錄罷。
4.與Service有關的還有一個安全的問題，可以在AndroidManifest.xml中用
6．GridView與ImageView
簡單一點吧，就瞧瞧那個Grid的效果，Android提供了一個GridView，不過從APIDemo中看來，它似乎與PC上的GRID差別還是挺大的，更像那個IconView的感覺。不知道Android中如何實現表格界面？雖然在移動終端上，表格一般不會有誰使用，大家似乎更傾向于使用ListView，而Android對于ListView則有更簡單的實現ListActivity。
很簡單，只要重載幾個方法就可以了，關鍵是那個getView方法，它負責構建出每個單元格中的對象實例。這里我們構造的是一個ImageView實例。
然后就是同樣的將這個Adapter賦給GridView即可，大家可以看看效果，注意在做這個例子前，先放幾個小圖片到res/drawable目錄下，buildproject一下就可以得到那個R.drawable.a了（這里的a是圖像文件名，如a.png）。
在getView方法中我們使用了ImageView類，這又是一個widget。除了上面用到的幾個方法以外，還有以下幾個方法值得注意： 與圖像來源有關的方法，我們只用了資源文件的方式。
還是習慣性跑題了，其實，我是想通過我對這個類的無數次Debugger跟進，說說它的多線程異步處理的解決策略的。他的基本策略如下： 1.當你實例化一個AsyncQueryHandler類時（包括其子類...），它會單件構造一個線程（后面會詳述...），這個線程里面會構建一個消息循環(huán)。
2.獲得該消息循環(huán)的指針，用它做參數實例化另一個Handler類，該類為內部類。至此，就有了兩個線程，各自有一個Handler來處理消息。3.當調用onXXX的時候，在XXX函數內部會將請求封裝成一個內部的參數類，將其作為消息的參數，將此消息發(fā)送至另一個線程。4.在該線程的Handler中，接受該消息，并分析傳入的參數，用初始化時傳入的ContentResolver進行XXX操作，并返回Cursor或其他返回值。
5.構造一個消息，將上述返回值以及其他相關內容綁定在該消息上，發(fā)送回主線程。
6.主線程默認的AsyncQueryHandler類的handleMessage方法（可自定義，但由于都是內部類，基本沒有意義...）會分析該消息，并轉發(fā)給對應的onXXXComplete方法。
7.用戶重寫的onXXXComplete方法開始工作。
這就是它偷偷摸摸做過的事情，基本還是很好理解的。我唯一好奇的是它的線程管理方式，我猜測他是用的單件模式。第一個AsyncQueryHandler的實例化會導致創(chuàng)建一個線程，從此該線程成為不死老處男，所有的ContentResolver相關的工作，都由該線程統一完成。個人覺得這種解決方式很贊。本來這個線程的生命周期就很難估量，并且，當你有一個ContentProvider的請求的時候，判斷你會做更多的類似操作并不過分。就算錯了，花費的也只是一個不死的線程（與進程同生死共存亡...），換來的卻是簡單的生命周期管理和無數次線程生死開銷的節(jié)約。同時另外一個很重要的問題，他并會涉及到單件中數據同步的問題，每個類都有各自的Handler類，彼此互不干擾，分發(fā)可以分別進行。當多個數據請求的時候，在同一個ContentResolver上進行的可能微乎其微，這就避免了堵塞?？偠灾@套解決辦法和Android的整體設計算是天作之合了。
所以建議，如果你有什么非ContentProvider操作，卻需要異步多線程執(zhí)行的話，模擬一套，是個不錯的策略，當然，具體情況具體分析，生搬硬套是學不好馬列主義的。
7.顯示控件使用
Android的界面顯示同樣也是基于控件的。通常是用View（包括ViewGroup）控件配上XML的樣式來做的。具體細節(jié)不想說了，可以參考 Samples里的ApiDemos/View，和View的Doc，以及Implementing a UI這篇Doc。其他還有很多，感覺算是SDK講述的最多的內容。
從控件的使用上，和網頁的設計類似，盡量用parent_width之類的抽象長度，用Theme來做風格，抽取所有的字串等信息做本地化設計。相關內容參看Implementing a UI就好。
一類比較重要的是數據綁定控件。如果做過ASP.Net會從中看到很多類似的地方。一個支持數據綁定的控件，比如ListView?？梢酝ㄟ^一個 ListAdapter綁定到一個數據源上。ListAdapter是一個抽象類，主要的實現類包括SimpleAdapter和 SimpleCursorAdapter。前者是綁定一個靜態(tài)的Array，后者是綁定一個動態(tài)的Cursor。Cursor前面說過，是一個指向數據源的隨機迭代器，將View綁定到Cursor通常要設置這樣幾個參數。一個是每一行的樣式，稱作Row Layout，其實就是一個普通的Layout的XML文件。還有就是一個列和現實控件的對應關系。那個控件顯示哪個列的值，這是需要配置的。為了定制一個良好的數據顯示控件，最簡單你可以定制很PP的Row Layout，復雜一點就是可以重載綁定控件View，或者是適配器ListAdapter。如果是一個數據顯示密集的應用，且你對UI有些追求，這個工作估計是必不可少的。
一個主要用于顯示數據內容的Activity，可以選擇派生自ListActivity。它提供了一個具有ListView 的Layout，還有simple_list_item_1, simple_list_item_2, two_line_list_item等默認的Row Layout，還有一些比較不錯的API，和可供響應選擇Item的事件?？梢詽M足你比較基礎的需求。如果你覺得只有一個ListView的界面太突兀，你可以為這個ListActivity指定一個Layout，需要注意的是，你需要提供一個id為@android:id/list的ListView控件，避免Activity在內部偷偷尋找該控件的時候失敗。
除了這些要求，做好UI還有注意易用性和效率?？旖萱I是一個比較不錯的選擇，在 Activity中調用setDefaultkeyMode(SHORTCUT_DEFAULT_KEYS)，可以開啟快捷鍵模式，然后你可以將菜單綁定到指定快捷鍵上就OK了。個人覺得Tip也是一個比較重要的東西，但目前觀察看來，這個東西只能夠自己提供了。界面的動態(tài)性有時候是不可避免的，比如說菜單就是一個需要經常根據光標位置提供不同的選項。這個東西Android很人道的考慮到了，你可以參看NodeList這個Sample。它采取的應該是一個靜態(tài)模擬動態(tài)的方式，這樣有助于提高速度。你也可以利用ViewInflate，動態(tài)從一個XML創(chuàng)建一個控件。成本據Doc說很大，不到萬不得已不要使用。
8.Intent消息傳遞
在前面寫Android的ContentProvider時候，可以看到那是基于觀察者模式的一個消息傳遞方法。每一個Cursor、ContentResolver做為一個小的注冊中心，相關觀察者可以在這個中心注冊，更新消息由注冊中心分發(fā)給各個觀察者。而在MFC或Winform中，都會形成一個消息網，讓消息在網中流動，被各節(jié)點使用、吃掉或者在出口死掉。
相比之下，我個人覺得基于Intent的Android核心消息傳遞機制是有所不同的。它應該會有一個全局性的注冊中心，這個注冊中心是隱性的，整個Android系統中就那么一個。所有的消息接收者，都被隱形的注冊到這個中心。包括Activity，Service和IntentReceiver。其實說隱形注冊是不確切的，所有注冊都還是我們手動告訴注冊中心的，只是與傳統的方式不一樣，我們通常不是通過代碼，而是通過配置文件來做。在應用的Manifest中，我們會為一些Activity或Service添加上Intent-filter，或在配置文件中添加
當程序有一個消息希望發(fā)出去的時候，它需要將消息封裝成一個Intent，并發(fā)送。這時候，應該是有一個統一的中心（恩，有可能Android底層實現的時候不是，但簡單這樣看是沒問題的...）接受到這個消息，并對它進行解析、判定消息類型（這個步驟降低了耦合...），然后檢查注冊了相匹配的filter或receiver，并創(chuàng)建或喚醒接收者，將消息分發(fā)給它。這樣做有很多好處。雖然這種傳遞有的時候不如點對點的傳遞快（這有些需要速度的地方，我們看到Android會通過直接通信來做），但有時候又因為它只經過一跳（姑且這么叫吧...），比復雜的流動又要更快。更重要的是，它耦合性低，在手機平臺這種程序組件多變的條件下使用十分適合。并且它可以很容易實現消息的精確或模糊匹配，彈性很大。（我個人曾想在開發(fā)一個C++二次平臺的時候引入這樣的機制，但在C++中，建立一套完整的數據marshal機制不容易，相比之下，用java來做會簡單很多...）
恩，廢話說了很多，具體講講Android中Intent的使用。當你有一個消息需要傳遞，如果你明確知道你需要哪個Activity或者其他Class來響應的話，你可以指定這個類來接受該消息，這被稱為顯性發(fā)送。你需要將Intent的class屬性設置成目標。這種情況很常見，比如startActivity的時候，會清楚當前Activity完了應該是哪個Activity，那就明確的發(fā)送這個消息。
但是，有的時候你并不確定你的消息是需要具體哪個類來執(zhí)行，而只是知道接收者該符合哪些條件。比如你只需要有一個接收者能顯示用戶所選的數據，而不想制定某個具體的方法，這時候你就需要用到隱形發(fā)送（傳統上，我們可能會考慮用多態(tài)，但顯然這種方式更為靈活...）。在Android中，你可以為Intent指定一個action，表示你這個指令需要處理的事情。系統為我們定義了很多Action類型，這些類型使系統與我們通信的語言（比如在Activity里面加一個Main的filter，該activity就會做成該應用的入口點），當然你也可以用于你自己的應用之間的通信（同樣當然，也可以自定義...）。強烈建議，在自己程序接收或發(fā)出一個系統action的時候，要名副其實。比如你響應一個view動作，做的確實edit的勾當，你發(fā)送一個pick消息，其實你想讓別人做edit的事，這樣都會造成混亂。當然只有Action有時候是不夠的，在Android中我們還可以指定catalog信息和type/data信息，比如所有的顯示數據的Activity，可能都會響應View action。但很多與我們需要顯示的數據類型不一樣，可以加一個type信息，明確的指出我們需要顯示的數據類型，甚至還可以加上一個catalog信息，指明只有你只有按的是“中鍵”并發(fā)出這樣的消息才響應。從上面可以看出，Android的Intent可以添加上class, action, data/type, catalog等消息，注冊中心會根據這些信息幫你找到符合的接收者。其中class是點對點的指示，一旦指明，其他信息都被忽略。Intent中還可以添加key/value的數據，發(fā)送方和接收方需要保持統一的key信息和value類型信息，這種數據的marshal在java里做，是不費什么力氣的。
Android的Intent發(fā)送，可以分成單播和廣播兩種。廣播的接收者是所有注冊了的符合條件的IntentReceiver。在單播的情況下，即使有很多符合條件的接收者，也只要有一個出來處理這個消息就好（恩，個人看法，沒找到確切條款或抉擇的算法，本來想實驗一下，沒來得及...），這樣的情況很容易理解，當你需要修改某個數據的時候，你肯定不會希望有十個編輯器輪流讓你來處理。當廣播不是這樣，一個receiver沒有辦法阻止其他receiver進行對廣播事件的處理。這種情況也很容易理解，比如時鐘改變了，鬧鐘、備忘錄等很多程序都需要分別進行處理。在自己的程序的使用中，應該分清楚區(qū)別，合理的使用。
9.ContentProvider數據模型
數據庫操作
從我目前掌握的知識來看，SQLite比較輕量（沒有存儲過程之類的繁雜手段），用起來也比較簡單。實例化一個SQLiteDatabase類對象，通過它的APIs可以搞定大部分的操作。從sample中看，Android中對db的使用有一種比較簡單的模式，即派生一個 ContentProviderDatabaseHelper類來進行SQLiteDatabase對象實例的獲取工作。基本上，ContentProviderDatabaseHelper類扮演了一個singleton的角色，提供單一的實例化入口點，并屏蔽了數據庫創(chuàng)建、打開升級等細節(jié)。在ContentProvider中只需要調用ContentProviderDatabaseHelper的openDatabase方法獲取SQLiteDatabase的實例就好，而不需要進行數據庫狀態(tài)的判斷。URI 像進行數據庫操作需要用SQL一樣，對ContentProivder進行增刪改查等操作都是通過一種特定模式的URI來進行的（ig：content: //provider/item/id），URI的能力與URL類似，具體細節(jié)可以查看SDK。建立自己的ContentProvider，只需要派生 ContentProivder類并實現insert, delete, update等抽象函數即可。在這些接口中比較特殊的是getType(uri)。根據傳入的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域內）為該ContentURIPraser建立一個uri的語法樹，之后就可以簡單調用 ContentURIPraser類的相關方法進行uri類型判斷（match方法），獲取加載在uri中的參數等操作。但我看來，這只是在使用上簡化了相關操作（不然就需要自己做人肉解析了...），但并沒有改變類型判定的模式。你依然需要用switch...case...對uri的類型進行判斷，并進行相關后續(xù)的操作。從模式來看，這樣無疑是具有強烈的壞味道，類似的switch...case...代碼要出現N此，每次一個 ContentProvider做uri類型的增減都會需要遍歷修改每一個switch...case...，當然，如果你使用模式（策略模式...）進行改造對手機程序來說無疑是崩潰似的（類型膨脹，效率降低...），所以，只能是忍一忍了（恩，還好不會擴散到別的類中，維護性上不會有殺人性的麻煩...）。增刪改查
ContentProvider 和所有數據源一樣，向外提供增刪改查操作接口，這些都是基于uri的指令。進行insert操作的時候，你需要傳入一個uri和 ContentValues。uri的作用基本就限于指明增減條目的類型（從數據庫層面來看就是table名），ContentValues是一個 key/value表的封裝，提供方便的API進行插入數據類型和數據值的設置和獲取。在數據庫層面上來看，這應該是column name與value的對應。但為了屏蔽ContentProvider用戶涉及到具體數據庫的細節(jié)，在Android的示例中，用了一個小小的模式。它為每一個表建一個基于BaseColumn類的派生類（其實完全可以不派生自BaseColumn，特別當你的表不基于默認的自動id做主鍵的時候），這個類通常包括一個描述該表的ContentURI對象和形如 public static final TITLE = “title”這樣的column到類數據的對應。從改變上角度來看，你可以修改column的名字而不需要更改用戶上層代碼，增加了靈活性。insert方法如果成功會返回一個uri，該uri會在原有的uri基礎上增加有一個row id。對于為什么使用row id而不是key id我想破了腦袋。到最后，我發(fā)現我傻了，因為ContentProvider不一定需要使用數據庫，使用數據庫對應的表也可以沒有主鍵，只有row id，才能在任何底層介質下做索引標識。
但，基于row id在刪除和修改操作是會造成一定的混亂。刪除和修改操作類似。刪除操作需要傳入一個uri，一個where字串，一組where的參數（做條件判定...），而修改操作會多一個ContentValues做更新值。著兩個操作的uri都支持在末尾添加一個row id。于是混亂就出現了。當在where參數中指明了key id，而在uri中提供了row id，并且row id和key id所指函數不一致的時候，你聽誰的？示例代碼中的做法是完全無視row id（無語...），如此野蠻的方式我估計也只能在示例中出現，在實際中該如何用，恩，我也不知道。幸運的是，我看了下上層對 ContentProvider的刪除操作，其實都不會直接進行，而是通過調用Cursor的delete方法進行，在這前提下，我想Cursor會處理好這些東西吧。
最后一個操作是查詢操作，可以想見，查詢的參數是最多的，包括uri和一組條件參數。條件參數類型和標準的sql類似，包括 sort, projection 之類的。從這些參數到sql語句的生成，可以尋求QueryBuilder類的幫助，它提供了一組操作接口，簡化了參數到sql的生成工作，哪怕你不懂 sql都完全沒有問題（這話說的我自己都覺得有點懸...）。查詢返回一個Cursor。Cursor是一個支持隨機讀寫的指針，不僅如此，它還提供了方便的刪除和修改的API，是上層對ContentProvider進行操作一個重要對象，需要仔細掌握（Cursor還可以綁定到view上，直接送顯，并與用戶進行交互，真是程序越往上，封裝越好，工作越機械沒有復雜性了...）。數據模型
在與界面打交道的Cursor、ContentResolver等數據操作層中，大量采用觀察者模式建立數據層與顯示層的聯系。一個顯示層的視圖，可以做成某一種觀察者注冊到Cursor或ContentResolver等數據中間層中，在實現底層ContentProvider中，我們需要特別注意在對數據進行修改操作（包括增刪改...）后，調用相應類型的notify函數，幫助表層對象進行刷新（還有一種刷新方式是從一個view發(fā)起的）?？梢钥吹?Android的整體數據顯示框架有點像MVC的方式。Cursor、ContentResolver相當于控制層，數據層和顯示層的交互通過控制層來掌管，而且控制層很穩(wěn)定不需要特別定制，通常工作只在定制數據層和顯示層空間，還是比較方便和清晰的。
10.學習感想
通過這學期對安卓的學習，大概了解了以上一些知識，對安卓有了初步的了解，這幾個月給我的東西我想用有形的和無形的兩部分概敘，形的當然就是技術水平的長進，雖然其中肯定有很多的不足，相信慢慢會體會到。
第四篇：實訓心得(張卓凡)
實訓心得
抱著打醬油的心情來到寧波職業(yè)體驗中心，值得開心的事是一起的還有同班同學。我們達到的時候已經時晚上六點多了，開辦典禮才剛剛開始，他們用異樣的眼神看著我們這幾個遲到的同學，很快就這樣一天過去了。
第二天就是馬老師的課了，我無精打采地坐在位子上，因為眼睛不太舒服皺著眉而被馬老師一直關注著。沙漠掘金，我被選為做外交管，我這個人一直不太善于和人交流況且還是一群不太認識的人。因為沒有做好充分的準備，以及沒有認真聽清游戲的規(guī)制，整個隊伍都死在了沙漠之中。通過這個游戲讓我知道一個團隊要有合作精神，其中管理者要勇于承擔和管理整個團隊。馬老師的課內容豐富又精彩。馬紅紅老師用她自己的經驗教導我們理解會計這門課程，雖然我是電子商務專業(yè)的，并不懂會計這一門課程。但是通過馬紅紅老師對我細心的講解，讓我看懂最簡單的科目匯總表，制作利潤表和資產負債表。了解會計最基礎的知識。
我們的班主任呂老師是個健談的人，很有親和力。第一次讓我點名的時候心里愣了一下，結果還是點錯了一個人、忘了一個人的名字，不過在接下去的幾天時間里，大家相處的還是很不錯。在玩卓越圈的時候大家都很努力，不斷縮短時間，雖然還是沒有達到最終的目標但還是挺有成就感?？蓱z的火星哥做的這么多俯臥撐，真是難為他了。
快樂的時間總是過的很快，十幾天在轉眼間就要結束了。很喜歡這里的老師和教課方式，很喜歡在這里遇到的一群好朋友。
第五篇：康凡-學習心得
過渡性學習心得
做個快樂的教師
—讀《給“悲觀的教師”一塊石頭》有感西溪中心小學康凡
今天，我學習了山東省肥城市桃園鎮(zhèn)中心小學李正強老師寫的《給“悲觀的教師”一塊石頭》這篇文章，頗有感觸。
文中先講了一個生活在孤兒院的小男孩，因為命運不公而常感到自卑，于是院長給了小男孩一塊石頭，讓小男孩分別到石頭市場和黃金市場去賣這塊石頭，結果竟有不少人出高價購買。從而校長引導小男孩明白：生命的價值在不同的環(huán)境下會有不同的意義，只要自我珍惜，生命就有價值。接著，李老師從這個故事聯想到現在很多教師像故事中的小男孩一樣，在教學中迷失了方向，整天渾渾噩噩過日子，加深了對教師職業(yè)的倦怠。李老師提出要給這些“悲觀的教師”們一塊石頭，讓他們能從工作中找到自己，看重自己，進而珍惜自己，發(fā)展自己。
教師，站在那永遠的“三尺講臺”上面，面前總是疊放著份份厚重的期待，每天面對的似乎是相同的事情，相同的人，周而復始。時間長了，的確很容易產生職業(yè)倦怠，心情的快樂指數也不容樂觀。因此，我們要尋找快樂，更要享受快樂。
在教學過程中，教師的行為是營造快樂環(huán)境的根本。教師的一舉一動、一言一行，甚至，只是一個小小的眼神，都能體現你對孩子關注與否，都有可能是孩子快樂的源泉。然而，教師的一舉一動、一言一行都不應是可以的做作，而應是自然的流露。所 1
以，教師應該首先是快樂的。怎樣做一名快樂的教師呢？
首先，要熱愛自己的職業(yè)。做一個快樂的教師，要努力使自己成為一團熊熊燃燒的火，用自己這把火去點燃學生求知、求美、求善的火把。做一個快樂的教師，要保持住自己的熱情、熱忱，要努力地挖掘自己所從事的工作的內在價值與趣味性，使自己對工作、事業(yè)有一種日日新、月月新、年年新的感覺，使自己始終保持一種良好的狀態(tài)。當我從學校走向教師崗位時，我覺得，這是陽光下最光輝的職業(yè)。每天，當我走出家門，走進教室時，我的心底充滿了快樂。我始終以教師職業(yè)作為終身職業(yè)的追求。
其次，不要對工作環(huán)境有太多的抱怨，保持樂觀豁達和積極向上的心態(tài)尤為重要。良好的心態(tài)是一種強大的動力，能夠激發(fā)教師強烈的工作熱情，在課堂上樂觀開朗，在工作中充滿活力，在人際交往中盡顯魅力，展現在學生面前的是一個充滿陽光的教師形象，能夠營造出一種輕松積極、和諧愉快的心理氛圍，激發(fā)學生的參與熱情，使課堂彰顯生命活力。要做一名好老師，但不要苛求自己的成績非要超過別人；要做一名好班主任，但不要苛求自己的班級非要年級第一，那樣你累學生更累。處處以他人作為競爭對象使得自己經常處于緊張狀態(tài)。只要孩子們有進步，就知足吧，知足常樂。有了健康的身體和樂觀的心態(tài)，我們就是一個成功者。
第三，有著融洽的同事關系。做教師的都應該清楚，教師的工作效果是具有一定群體性的。所以我們要時刻反省自己是否工作在一個和諧的工作環(huán)境之中，與同事在教學中是否已形成了一
種教育合作的默契；你感覺到你的同事對你的工作是支持還是受制；如果感到工作處處受制，那么不可能是快樂的教師。同事是工作伙伴，有時又是競爭對手，處理好與同事的關系，是我們獲得快樂的必要保證。崗位競爭激烈，保持適度的危機意識是必要的，但是過于緊張，草木皆兵卻大可不必。我們應該調整好心態(tài)，正確對待同事。我們首先必須明白，無論自己再怎么優(yōu)秀，都可能遇到強勁的對手。學歷和資歷固然重要，但最重要的還是個人的人格和實際工作本領。不管為了現實生存還是實現自我價值，我們都要學他人之長，不斷進步，以適應環(huán)境的變化。
第四，生活中要享受教書以外的快樂。雖然我們的職業(yè)是教師，但我們的生活不僅僅是教書。比如，在教書之外，我們要學會生活。以愉快的心情在燈下靜心的讀你喜歡的文字，并將你的讀書心得用恰當的方式轉達給孩子，讓孩子來分享你的快樂。豐富自己的業(yè)余生活和家庭生活，培養(yǎng)廣泛的興趣愛好，合理安排時間，松馳自身緊張的心情，勞逸結合，張弛有度；煩惱時主動與領導、同事、朋友或家人聊聊天，以轉移注意，釋放積郁；平時多學一點心理學知識，以加強心理健康防衛(wèi)，更好地從事教育工作，促進自已身心的健康。
最后，要時刻感覺與孩子相處是快樂的。這種快樂是一種交流的快樂，而不是一種對孩子管制的快樂。我一直努力堅持笑著面對每一天，面對稚氣的孩子們，所以我認為自己是幸福而快樂的，我也認為只有快樂的自己才能勝任今天教師這個職業(yè)。其實在每天的校園里讓自己快樂的理由和方法有很多。布置好一個整
潔明亮的教室欣然笑笑，是一種快樂；上一堂令自己和學生滿意的好課，高興！看到全班的學生做了一次好作業(yè)，真快樂!幫助同事也是一種快樂；把生活的感悟與朋友分享還是一種快樂......幫助別人之后的快樂是溫馨的，努力付出之后的快樂是充實的，收獲成功之后的快樂是甜美的。
當然，真正的快樂也并不是沒有憂慮，只是它不會總被憂慮纏繞；真正的快樂也不是沒有痛苦，只是在短暫的陣痛過后，我們能享受到更令人難忘的快樂。只有真正快樂的教師，才會給孩子真正的快樂。讓我們忘卻心頭的煩惱，淡化自己的得失，不斷追求做老師的快樂。做永遠快樂的教師，給孩子真正的快樂！
點擊咨詢 