第一篇：安卓初級程式設計師
1、數學、物理、計算機相關專業本科學歷；
2、熟悉計算機體系結構及計算機網路體系結構，瞭解c,c++或javaj2me其中一種語言；
3、對軟體有較大興趣，瞭解面向物件思維，有較強的邏輯思維能力及問題的解決能力；
4、熟悉linux系統編輯環境、測試流程；
5、熟悉tcp/ip、http協議，有作業系統的基礎知識；oracle、mysql、sqlserver等資料庫中至少一種；
6、有較強的溝通能力，並能主動的向上級彙報工作中出現的問題；
職位描述：
-負責公司android專案的軟體開發
職位要求：
-紮實的java語言基礎
-計算機相關專業本科學歷
-具有較好的英文讀寫能力
-有移動平臺開發經驗的優先
-一年以上android手機開發經驗
崗位描述返回公司簡介 3000-3500元
1、數學、物理、計算機相關專業專科或以上學歷；
2、 熟悉計算機體系結構及計算機網路體系結構，瞭解c,c++或javaj2me其中一種語言；
3、對軟體有較大興趣，瞭解面向物件思維，有較強的邏輯思維能力及問題的解決能力；
4、熟悉linux系統編輯環境、測試流程；
5、熟悉tcp/ip、http協議，有作業系統的基礎知識；oracle、mysql、sqlserver等資料庫中至少一種；
6、有較強的溝通能力，並能主動的向上級彙報工作中出現的問題；
軟體測試
崗位職責/待遇/環境：
1、根據開發進度和任務分配，完成相應模組軟體的測試任務；
2、進行編制專案文件和質量記錄的工作；
3、能準確提出和定位軟體缺陷；
4、能勝任迴歸測試的工作；
5、能與開發人員及產品人員有效溝通協作；
6、按時向上級彙報測試進度狀況和資料。
錄用流程：投遞簡歷--初試筆試--錄用簽訂就業協議--內部實訓--上崗
工作地點：本職位工作地點在天津和北京
崗位要求：
1、計算機、通訊、電子、數學等相關專業或者熱愛程式設計，大學專科或以上學歷；
2、熟悉web產品測試，熟悉b/s架構；
3、熟悉軟體功能測試和相容性測試；
4、熟悉軟體開發的過程，有面向物件的軟體開發思想；
5、對主流資料庫如oracle/mysql/sqlserver有一定了解；
6、有較強的溝通能力和獨立思考能力，工作細緻；
7、具有高度的責任心和敬業精神，良好的團隊合作精神。
錄用流程：投遞簡歷--初試筆試--錄用簽訂就業協議--內部實訓--上崗 工作地點：本職位工作地點在天津和北京
第二篇：安卓程式開發程式設計師培訓的真實經歷
安卓程式開發程式設計師培訓的真實經歷
大學畢業後，四年中的苦與樂都伴隨著畢業的鈴聲而漸漸遠去。畢業2年多之後，我輾轉過2個行業，慢慢的，開始對自己的職業方向產生懷疑，看到和自己的同窗之間漸行漸遠，漸漸找不到自己的方向，我開始陷入迷惘。偶然的機會，和同事們交流了解到安卓程式開發程式設計師培訓，和安卓手機現在巨大的發展空間，並通過自己的瞭解和朋友的介紹，我發現這個行業是真正適合我的方向! android 是一個年輕的、有待開發的平臺，它有潛力同時涵蓋行動電話的兩個不同消費群體，甚至可能縮小工作和娛樂之間的差別。於是，我毅然決定辭去原本還不錯的工作，跟我的一個哥們從南方的家鄉來到遙遠的北京。我要來一次：重走青春!
初來到千鋒學習安卓，感受到了與自學安卓程式開發不同的溫馨和暖意。授課老師不僅給你傳授專業的安卓程式開發程式設計師培訓所要掌握的必備知識，而且課後會經常和同學們溝通和交流，並鼓勵和引導大家更好的學習。經過了幾個月的培訓，我們和老師建立了深厚的友誼。老師每天開始上課前，會先複習前一天的知識，做到溫故而知新。然後結合例項，現場演示教授當天的知識。並在課後留下相關的練習，讓我們課後更好的消化和吸收。經過了複習，講解和練習的過程，對知識有了更深的理解。在經過每個階段性學習之後，是專案實戰。我覺得這是個人能力提高最快的時候。老師會給予真實的專案開發文件和案例，採用小組分配的方式，充分調動每一位學員的思考和動手能力，真實體會公司實際的開發場景。
除了自己的堅定選擇，最需要感謝的就是這裡的老師和課程體系，還有我可愛的朝夕相處過共同為了安卓程式開發而拼搏過的同窗們。
我能有今天的一份成績，站在這樣的一個位置，不只是薪資，也不僅僅是在安卓程式開發程式設計師培訓機構學習的短短四個月就能決定的這一切。更主要的是收穫了屬於自己的一個平臺，認識了更多的朋友，讓我有能去挑戰移動網際網路，成為一名真正的安卓程式開發程式設計師，並能在安卓程式開發的路上，開創屬於自己人生中的新起點。
在這裡，勤奮的人們開始了更加勤奮的對目標的追逐。逐漸的，我從一個對android程式開發的初窺，到學會再到深入理解和掌握，繼而贏得一次次反思，每一次都是不斷的充實自己的過程。在這裡學習android程式開發程式設計師培訓的過程中是苦並快樂的，每當解決了一個新的問題，就感覺離自己的夢想又近了一步，也對android程式開發又多了一個更深層次的理解。
第三篇：程式設計師求職信
程式設計師求職信2
釋出時間:2014年09月03日 來源:應屆畢業生求職網
個人簡歷簡歷模板英文簡歷個人簡歷模板求職簡歷
個人簡歷表格簡歷範文簡歷封面簡歷表個人簡歷範文
本文系程式設計師求職信模板，僅供參考。
個人基本資料
出生日期:1982-06-12 性別:女
婚姻狀況:未婚 身高: 釐米
體重: 公斤
求職意向描述_應聘崗位:計算機專業人員/系統分析員/軟體/軟體測試工程師/internet開發工程師/通訊類專業人員
崗位描述:軟體程式設計師，c程式設計師，c++程式設計師，java程式設計師，it客戶銷售人員和行政管理 工作經驗:0 年 期望月薪:
教育背景
畢業學校
重慶郵電學院 最高學歷:本科 專業:電腦科學與技術（軟體工程）電腦水平:優秀 外語語種:英語 外語水平:良好
教育歷程:
畢業於重慶郵電學院
工作簡歷
在校應屆畢業生
個人能力及自我介紹
本人性格樂觀開朗，自信大方，正直不訛，原則性強，直率誠懇，坦然豁達，愛好廣泛。大學四年的刻苦學習生活，德、智、體全面發展。在學習期間嚴格遵守學校各項規章制度，學習態度端正，多次獲得校優秀學生獎學金、“優秀幹部”的稱號。在學習上通過課外學習不斷完善自己。對待工作熱情，與同學關係融洽，積極參加學校文體活動，獲得了一定的成績，受到了老師和同學們的肯定。在這四年中，不僅能讓我在這樣廣闊的知識土壤裡吸取了不少的養份，同時，還培養了我獨立堅韌，團結互助的素質品質，使自己有一定的工作能力，組織能力，社交能力，以及語言溝通能力。
程式設計師求職信模板
釋出時間:2014年07月12日 來源:應屆畢業生求職網
英文求職信模板中文求職信模板個人求職信模板會計求職信模板求職信
求職信範文英文求職信求職信怎麼寫求職信名稱求職信格式
本文系程式設計師求職信模板，僅供參考。
個人基本資料
出生日期:1982-06-12 性別:女
婚姻狀況:未婚 身高: 釐米
體重: 公斤
求職意向描述_應聘崗位:計算機專業人員/系統分析員/軟體/軟體測試工程師/internet開發工程師/通訊類專業人員
崗位描述:軟體程式設計師，c程式設計師，c++程式設計師，java程式設計師，it客戶銷售人員和行政管理 工作經驗:0 年 期望月薪:
教育背景
畢業學校
重慶郵電學院 最高學歷:本科 專業:電腦科學與技術（軟體工程）
電腦水平:優秀 外語語種:英語 外語水平:良好
教育歷程:
畢業於重慶郵電學院
工作簡歷
在校應屆畢業生
個人能力及自我介紹
本人性格樂觀開朗，自信大方，正直不訛，原則性強，直率誠懇，坦然豁達，愛好廣泛。大學四年的刻苦學習生活，德、智、體全面發展。在學習期間嚴格遵守學校各項規章制度，學習態度端正，多次獲得校優秀學生獎學金、“優秀幹部”的稱號。在學習上通過課外學習不斷完善自己。對待工作熱情，與同學關係融洽，積極參加學校文體活動，獲得了一定的成績，受到了老師和同學們的肯定。在這四年中，不僅能讓我在這樣廣闊的知識土壤裡吸取了不少的養份，同時，還培養了我獨立堅韌，團結互助的素質品質，使自己有一定的工作能力，組織能力，社交能力，以及語言溝通能力。
尊敬的領導：
您好！得知貴公司的招聘資訊，我對flash程式設計師一職很感興趣。從大學畢業至今，一直在深圳一家網路公司擔任flash程式設計職務。對flash遊戲課件程式設計有了相當的瞭解和熟悉，我相信我有能力擔當貴公司所要求的flash程式設計任務。
我對計算機程式設計有著非常濃厚的興趣，熟練運用flash動畫及action script2.0程式設計，熟悉flash遊戲開發流程；熟悉photoshop、dreamweaver mx 2014及visual studio 2014等網頁製作工具，熟悉html，有一定的+sql網站建設能力。
面對當今激烈的人才競爭，我很清楚自己知識有限，但我更清楚我有著不甘落後的精神和不斷學習，不斷提高的願望。樂於進取，不怕挫折是我的人生信條，給我一次機會，讓我去實
踐，去闖，去幹，因為能力要在實踐中培養，也終究要在實踐中體現。我信心十足，相信我所具備的專業技能，積累的知識，加上有良好的人際關係，會幫助我掀開生活中的新一頁。 假如我有幸能成為貴公司的一員，我相信我有能力勝任貴公司安排的工作，並願與公司同甘共苦，並將以敬業樂業，深入實際，吃苦耐勞，開拓創新的精神投入到工作當中去。我相信貴公司能給我提供施展才能的另一片天空，而且我也相信我的努力能讓貴公司的事業更上一層樓。感謝您對我的關注！
此致
xxx
2014年11月20日
尊敬的領導：
您好！
我來自xxxxxx學院xxxx系xx技術xx班的學生，我將於明年7月完成大專學業，真正步入社會，開始人生路上的新一段征程。
我這次寫求職信的目的是應聘貴公司的c#程式設計師。
兩年多來，在校領導和老師的引導下，我努力很認真的學好專業知識，訓練專業技能，專業水平每一年都有明顯提高。在校期間，我學習了c語言，java，c#，winform，sqlserver，oracle，有較強的實踐能力。
兩年半的大專生活教我學會了冷靜的思考問題、以及如何面對問題，使我能在人生的座標上找尋適合自己的位置並不斷修整自我，更讓我深刻認識到人要用心地去做每一件事，認真、踏實地面對人生的每一步。所以我誠摯地希望加入你們這支優秀的、富有生命力的群體，在大家的指導和幫助下，共同攜手，在人生的道路上不斷進取。
“天生我材必有用”，後附本人的簡歷，希望貴公司能給我一個發展的平臺，我會好好珍惜它，並全力以赴，為實現自己的人生價值而奮鬥，為貴公司的發展貢獻力量。
此致
敬禮！
該資訊出自應屆畢業生求職網：http://
下面就是一則典型的求職信，讓我們一起來看看怎樣才能寫出一封成功的求職
信。
求職信範例：
xx經理：
您好！
我寫此信應聘貴公司招聘的經理助理職位。我很高興地在招聘網站得知你們的招
聘廣告，並一直期望能有機會加盟貴公司。
兩年前我畢業於首都經濟貿易大學國際貿易專業，在校期間學到了許多專業知識，如國際貿易，國際貿易實務，國際商務談判，國際貿易法，外經貿英語等課程。畢業後，就職於一家外貿公司，從事市場助理工作，主要是協助經理制定工作計劃、一些外聯工作、以及檔案、檔案的管理工作。本人具備一定的管理和策劃能力，熟悉各種辦公軟體的操作，英語熟練，略懂日語。我深信可以勝任貴公
司經理助理之職。
個人簡歷及相關材料一併附上，希望您能感到我是該職位的有力競爭者，並希望
能儘快收到面試通知，我的聯絡電話：139********
感謝您閱讀此信並考慮我的應聘要求！
此致敬禮！
您真誠的朋友：
xxxx年x月x月
第四篇：程式設計師求職信
尊敬的領導：
您好！
感謝您在百忙之中拔冗閱讀我的求職信。揚帆遠航，賴您東風助力！我是廣西大學2014屆軟體工程專業的本科畢業生。值此擇業之際，我渴望能到貴單位供職。希望與貴企業的同事們攜手並肩，共揚希望之帆，共創事業輝煌！
寶劍鋒從磨礪出，梅花香自苦寒來。在大學期間，我以勤勉進取的積極心態，全方位地充實鍛鍊自己，經過學習和磨練，我具備了以下三個方面的品質能力：
一、誠實正直、勤勞務實的人格品質。人格既包括一個人的性格，又包括一個人的道德品質。在大學，我不僅學到了課本里的知識，更領悟到了課堂以外做人做事的道理。優秀的人格品質是一個人內在修養的外在表現。在當下，這是一種文明的社交方式，是順利開展工作、建立良好社交關係的基石。
二、紮實的專業基礎知識和較強的自學能力。具備紮實的c/c++語言基礎，資料結構、演算法等相關知識，對面向物件程式設計有較高層次的認識，具有良好而規範的程式設計習慣和技術文件編寫習慣。我還積極將所學知識學以致用，在業餘時間完成了電信計費系統、playfair和維吉尼亞加密演示系統和俄羅斯方塊的程式碼程式設計。此外，在校期間學習上銳意進取，專業成績優異，以650分通過英語四級，曾多次榮獲國家獎學金及榮獲校優秀學生獎學金。
三、突出的工作能力和強烈的團隊合作精神。學習之餘，我很注重知識與能力的平衡。在校擔任校黨委組織部助理、院實踐調研部部長、支部書記等職務，多次策劃組織或參與校內外的志願活動，如黨員服務月活動、社群電腦培訓、黨員募捐儀式等。這培養了我強烈的責任感、良好的交流溝通能力和組織協調能力，增強了團隊合作意識，同時也使我積累了一些社會經驗。
十年寒窗的求學生涯使我形式了優良的處事作風和先進的思想觀念，並有獨特的思維方式和和諧的人際關係。我時刻注意抓住機會鍛鍊自己，並時刻思索做好工作的方法。我是一個有能力且有團隊精神的人，對工作滿懷熱情，我相信自己能在新環境既定的團隊中做好工作。
期望我能適合您的要求，也期望您選擇我，您的選擇就是我的希望。為了方便您更詳細地瞭解我的情況，請審閱我呈上的簡歷。期望能得到您的迴音！祝貴企業事業蒸蒸日上、碩果累累！
此致
敬禮！
自薦人：**
2014年5月14日
第五篇：安卓學習心得
android學習心得
-----093380117計算機應用（1）張峰
1.關於activity
1. 在一個activity中使用多個view
如果把activity看作mvc中的control？它負責管理ui和接受事件（包括使用者的輸入），雖然說一個activity通常對應一個螢幕，但事實上，我們是可以只用一個activity管理多個不同的view來實現簡單的邏輯。
首先，我們增加一個新的資源描述layout/。
除了一個“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好友傳送gmail郵件，用googlemap查詢qq好友所在的位置？看上去挺不錯的。
關於這個contentprovider，其實還有話說，它主要是的那些看似資料庫操作的方法我們都沒真正去實現呢。不過今天就到這裡了，等下回再去研究吧。
3.關於listactivity
準備一個list物件並藉助adapter就可以構造出一個列表。過載onlistitemclick方法可以響應選擇事件，利用第一個引數可以訪問到這個listview例項以得到選中的條目資訊。這裡有一點要說明的，就是如果更簡單的話，其實連那個setcontentview都可以不要了，android也會自動幫我們構造出一個全屏的列表。但是本例中我們需要一個textview來顯示選中的條目，所以我們需要一個b描述一下這個列表視窗。
這裡需要注意的是那個listview的id，是系統自定義的android:list，不是我們隨便取的，否則系統會說找不到它想要的listview了。然後，在這個listview之外，我們又增加了一個textview，用來顯示選中的條目。
再來說說這裡用到的arrayadapter，它的建構函式中第二個引數是一個資源id，arrayadapter的api文件中說是要求用一個包含textview的layout檔案，平臺用它來顯示每個選擇條目的樣式，這裡的取值是_row，所以，我們還有一個list_檔案來描述這個佈局，相當簡單。
從arrayadapter上溯到baseadapter，發現還有幾個同源的adapter也應該可以使用，象simpleadapter和cursoradapter，還是做個例子來實驗一下吧。
然後，在hellotwob中的oncreate函式中，修改程式碼，有幾個不同：items的元素是hashmap例項，這是一點變化，然後建構函式除了要求items以外，還要求提供一個string[]來說明用hash表中的哪個欄位顯示在列表中，而後是一個資源id的陣列。
因為單純的cursoradapter是抽象類，所以我用的是它的子類simplecursoradapter，很好理解，先用contentresolver查詢通訊簿得到一個遊標，然後告訴simplecursoradapter要用其中的作為顯示項來構造出一個adapter即可。
4.關於dialog
注意到包下除了dialog（可用於製作複雜的對話方塊）以外，還包括了幾個系統定義好的對話方塊類，如datepickerdialog、timepickerdialog及alertdialog。
其中alertdialog我上回用過一次，基本上就那樣子了，今天看看另外兩個對話方塊的使用吧。
很簡單的，無非(請你收藏好 範 文，請便下次訪問WWW.HaoWoRD.com)是需要一個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物件。關於這方面的細節，以後再看，這裡只做個記錄罷。
4.與service有關的還有一個安全的問題，可以在androidmanifest.xml中用<uses-permission>標籤來宣告一個service的訪問許可權，關於android的安全問題也留待以後再解決吧。
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類時（包括其子類...），它會單件構造一個執行緒（後面會詳述...），這個執行緒裡面會構建一個訊息迴圈。
2. 獲得該訊息迴圈的指標，用它做引數例項化另一個handler類，該類為內部類。至此，就有了兩個執行緒，各自有一個handler來處理訊息。
3. 當呼叫onxxx的時候，在xxx函式內部會將請求封裝成一個內部的引數類，將其作為訊息的引數，將此訊息傳送至另一個執行緒。
4. 在該執行緒的handler中，接受該訊息，並分析傳入的引數，用初始化時傳入的contentresolver進行xxx操作，並返回cursor或其他返回值。
5. 構造一個訊息，將上述返回值以及其他相關內容繫結在該訊息上，傳送回主執行緒。
6. 主執行緒預設的asyncqueryhandler類的handlemessage方法（可自定義，但由於都是內部類，基本沒有意義...）會分析該訊息，並轉發給對應的onxxxcomplete方法。
7. 使用者重寫的onxxxcomplete方法開始工作。
這就是它偷偷摸摸做過的事情，基本還是很好理解的。我唯一好奇的是它的執行緒管理方式，我猜測他是用的單件模式。第一個asyncqueryhandler的例項化會導致建立一個執行緒，從此該執行緒成為不死老處男，所有的contentresolver相關的工作，都由該執行緒統一完成。個人覺得這種解決方式很贊。本來這個執行緒的生命週期就很難估量，並且，當你有一個contentprovider的請求的時候，判斷你會做更多的類似操作並不過分。就算錯了，花費的也只是一個不死的執行緒（與程序同生死共存亡...），換來的卻是簡單的生命週期管理和無數次執行緒生死開銷的節約。同時另外一個很重要的問題，他並會涉及到單件中資料同步的問題，每個類都有各自的handler類，彼此互不干擾，分發可以分別進行。當多個數據請求的時候，在同一個contentresolver上進行的可能微乎其微，這就避免了堵塞。總而言之，這套解決辦法和android的整體設計算是天作之合了。
所以建議，如果你有什麼非contentprovider操作，卻需要非同步多執行緒執行的話，模擬一套，是個不錯的策略，當然，具體情況具體分析，生搬
硬套是學不好馬列主義的。
7.顯示控制元件使用
android的介面顯示同樣也是基於控制元件的。通常是用view（包括viewgroup）控制元件配上xml的樣式來做的。具體細節不想說了，可以參考 samples裡的apidemos/view，和view的doc，以及implementing a ui這篇doc。其他還有很多，感覺算是sdk講述的最多的內容。
從控制元件的使用上，和網頁的設計類似，儘量用parent_width之類的抽象長度，用theme來做風格，抽取所有的字串等資訊做本地化設計。相關內容參看implementing a ui就好。
一類比較重要的是資料繫結控制元件。如果做過會從中看到很多類似的地方。一個支援資料繫結的控制元件，比如listview。可以通過一個 listadapter繫結到一個數據源上。listadapter是一個抽象類，主要的實現類包括simpleadapter和 simplecursoradapter。前者是繫結一個靜態的array，後者是繫結一個動態的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的事件。可以滿足你比較基礎的需求。如果你覺得只有一個listview的介面太突兀，你可以為這個listactivity指定一個layout，需要注意的是，你需要提供一個id為@android:id/list的listview控制元件，避免activity在內部偷偷尋找該控制元件的時候失敗。
除了這些要求，做好ui還有注意易用性和效率。快捷鍵是一個比較不錯的選擇，在 activity中呼叫setdefaultkeymode(shortcut_default_keys)，可以開啟快捷鍵模式，然後你可以將選單繫結到指定快捷鍵上就ok了。個人覺得tip也是一個比較重要的東西，但目前觀察看來，這個東西只能夠自己提供了。介面的動態性有時候是不可避免的，比如說選單就是一個需要經常根據游標位置提供不同的選項。這個東西android很人道的考慮到了，你可以參看nodelist這個sample。它採取的應該是一個靜態模擬動態的方式，這樣有助於提高速度。你也可以利用viewinflate，動態從一個xml建立一個控制元件。成本據doc說很大，不到萬不得已不要使用。
nt訊息傳遞
在前面寫android的contentprovider時候，可以看到那是基於觀察者模式的一個訊息傳遞方法。每一個cursor、contentresolver做為一個小的註冊中心，相關觀察者可以在這個中心註冊，更新訊息由註冊中心分發給各個觀察者。而在mfc或winform中，都會形成一個訊息網，讓訊息在網中流動，被各節點使用、吃掉或者在出口死掉。
相比之下，我個人覺得基於intent的android核心訊息傳遞機制是有所不同的。它應該會有一個全域性性的註冊中心，這個註冊中心是隱性的，整個android系統中就那麼一個。所有的訊息接收者，都被隱形的註冊到這個中心。包括activity，service和intentreceiver。其實說隱形註冊是不確切的，所有註冊都還是我們手動告訴註冊中心的，只是與傳統的方式不一樣，我們通常不是通過程式碼，而是通過配置檔案來做。在應用的manifest中，我們會為一些activity或service新增上intent-filter，或在配置檔案中新增<receiver></receiver>項。這其實就相當於向系統的註冊中心，註冊了相關的intent-filter和receiver（這個事情完全可以通過程式碼來做，只是這樣就失去了修改的靈活性）。
當程式有一個訊息希望發出去的時候，它需要將訊息封裝成一個intent，併發送。這時候，應該是有一個統一的中心（恩，有可能android底層實現的時候不是，但簡單這樣看是沒問題的...）接受到這個訊息，並對它進行解析、判定訊息型別（這個步驟降低了耦合...），然後檢查註冊了相匹配的filter或receiver，並建立或喚醒接收者，將訊息分發給它。這樣做有很多好處。雖然這種傳遞有的時候不如點對點的傳遞快（這有些需要速度的地方，我們看到android會通過直接通訊來做），但有時候又因為它只經過一跳（姑且這麼叫吧...），比複雜的流動又要更快。更重要的是，它耦合性低，在手機平臺這種程式元件多變的條件下使用十分適合。並且它可以很容易實現訊息的精確或模糊匹配，彈性很大。（我個人曾想在開發一個c++二次平臺的時候引入這樣的機制，但在c++中，建立一套完整的資料marshal機制不容易，相比之下，用java來做會簡單很多...）
恩，廢話說了很多，具體講講android中intent的使用。當你有一個訊息需要傳遞，如果你明確知道你需要哪個activity或者其他class來響應的話，你可以指定這個類來接受該訊息，這被稱為顯性發送。你需要將intent的class屬性設定成目標。這種情況很常見，比如startactivity的時候，會清楚當前activity完了應該是哪個activity，那就明確的傳送這個訊息。
但是，有的時候你並不確定你的訊息是需要具體哪個類來執行，而只是知道接收者該符合哪些條件。比如你只需要有一個接收者能顯示使用者所選的資料，而不想制定某個具體的方法，這時候你就需要用到隱形傳送（傳統上，我們可能會考慮用多型，但顯然這種方式更為靈活...）。在android中，你可以為intent指定一個action，表示你這個指令需要處理的事情。系統為我們定義了很多action型別，這些型別使系統與我們通訊的語言（比如在activity裡面加一個main的filter，該activity就會做成該應用的入口點），當然你也可以用於你自己的應用之間的通訊（同樣當然，也可以自定義...）。強烈建議，在自己程式接收或發出一個系統action的時候，要名副其實。比如你響應一個view動作，做的確實edit的勾當，你傳送一個pick訊息，其實你想讓別人做edit的事，這樣都會造成混亂。當然只有action有時候是不夠的，在android中我們還可以指定catalog資訊和type/data資訊，比如所有的顯示資料的activity，可能都會響應view action。但很多與我們需要顯示的資料型別不一樣，可以加一個type資訊，明確的指出我們需要顯示的資料型別，甚至還可以加上一個catalog資訊，指明只有你只有按的是“中鍵”併發出這樣的訊息才響應。
從上面可以看出，android的intent可以新增上class, action, data/type, catalog等訊息，註冊中心會根據這些資訊幫你找到符合的接收者。其中class是點對點的指示，一旦指明，其他資訊都被忽略。intent中還可以新增key/value的資料，傳送方和接收方需要保持統一的key資訊和value型別資訊，這種資料的marshal在java裡做，是不費什麼力氣的。
android的intent傳送，可以分成單播和廣播兩種。廣播的接收者是所有註冊了的符合條件的intentreceiver。在單播的情況下，即使有很多符合條件的接收者，也只要有一個出來處理這個訊息就好（恩，個人看法，沒找到確切條款或抉擇的演算法，本來想實驗一下，沒來得及...），這樣的情況很容易理解，當你需要修改某個資料的時候，你肯定不會希望有十個編輯器輪流讓你來處理。當廣播不是這樣，一個receiver沒有辦法阻止其他receiver進行對廣播事件的處理。這種情況也很容易理解，比如時鐘改變了，鬧鐘、備忘錄等很多程式都需要分別進行處理。在自己的程式的使用中，應該分清楚區別，合理的使用。
entprovider資料模型
資料庫操作
從我目前掌握的知識來看，sqlite比較輕量（沒有儲存過程之類的繁雜手段），用起來也比較簡單。例項化一個sqlitedatabase類物件，通過它的apis可以搞定大部分的操作。從sample中看，android中對db的使用有一種比較簡單的模式，即派生一個 contentproviderdatabasehelper類來進行sqlitedatabase物件例項的獲取工作。基本上， contentproviderdatabasehelper類扮演了一個singleton的角色，提供單一的例項化入口點，並遮蔽了資料庫建立、開啟升級等細節。在contentprovider中只需要呼叫contentproviderdatabasehelper的opendatabase方法獲取sqlitedatabase的例項就好，而不需要進行資料庫狀態的判斷。
uri
像進行資料庫操作需要用sql一樣，對contentproivder進行增刪改查等操作都是通過一種特定模式的uri來進行的（ig：content: //provider/item/id），uri的能力與url類似，具體細節可以檢視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中的引數等操作。但我看來，這只是在使用上簡化了相關操作（不然就需要自己做人肉解析了...），但並沒有改變型別判定的模式。你依然需要用...對uri的型別進行判斷，並進行相關後續的操作。從模式來看，這樣無疑是具有強烈的壞味道，類似的...程式碼要出現n此，每次一個 contentprovider做uri型別的增減都會需要遍歷修改每一個...，當然，如果你使用模式（策略模式...）進行改造對手機程式來說無疑是崩潰似的（型別膨脹，效率降低...），所以，只能是忍一忍了（恩，還好不會擴散到別的類中，維護性上不會有殺人性的麻煩...）。
增刪改查
contentprovider 和所有資料來源一樣，向外提供增刪改查操作介面，這些都是基於uri的指令。進行insert操作的時候，你需要傳入一個uri和 contentvalues。uri的作用基本就限於指明增減條目的型別（從資料庫層面來看就是table名），contentvalues是一個 key/value表的封裝，提供方便的api進行插入資料型別和資料值的設定和獲取。在資料庫層面上來看，這應該是column name與value的對應。但為了遮蔽contentprovider使用者涉及到具體資料庫的細節，在android的示例中，用了一個小小的模式。它為每一個表建一個基於basecolumn類的派生類（其實完全可以不派生自basecolumn，特別當你的表不基於預設的自動id做主鍵的時候），這個類通常包括一個描述該表的contenturi物件和形如 public static final title = "title"這樣的column到類資料的對應。從改變上角度來看，你可以修改column的名字而不需要更改使用者上層程式碼，增加了靈活性。 insert方法如果成功會返回一個uri，該uri會在原有的uri基礎上增加有一個row id。對於為什麼使用row id而不是key id我想破了腦袋。到最後，我發現我傻了，因為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發起的）。可以看到 android的整體資料顯示框架有點像mvc的方式。cursor、contentresolver相當於控制層，資料層和顯示層的互動通過控制層來掌管，而且控制層很穩定不需要特別定製，通常工作只在定製資料層和顯示層空間，還是比較方便和清晰的。
10.學習感想
通過這學期對安卓的學習，大概瞭解了以上一些知識，對安卓有了初步的瞭解，這幾個月給我的東西我想用有形的和無形的兩部分概敘，形的當然就是技術水平的長進，雖然其中肯定有很多的不足，相信慢慢會體會到。